Ronald R Horner wrote:
>
> In the old days, when you had a working storage section that could
> only be 32767 sectors,  programs that did a lot of table processing
> used these intrinsics to get extra segments.  GETDSEG asks the
> system for 1 more segment.  DMOVIN and DMOVOUT moves data in and out
> of that extra segment.

Actually that is 32767 16-bit words, or just under 64K bytes.  Your
process stack consumed some space (system area below DB) so you ended
up with somewhere around 31000 16-bit words (I forget MAXDATA value).

The data segment could be up to 32K words.  It could be private to
your process, or shared within a process tree.  On the classic 3000
it was an 'efficient' way to gain more data storage without resorting
to a work file or other workaround.

> In a sense, you create a table with system resources.  On the
> classics that was fine because you were not getting much.  Now days,
> you perform a GETDSEG and the new systems give you an extra 4 gig of
> working storage space.  That is on top of the 4 gig your program was
> given in the first place.  The more data segments a program has, the
> more the system hurts.  This is why it's not a good thing to do.

This is also an exaggeration.  You initially get NMSTACK+NMHEAP worth of
data, but generally speaking, you only address a "quad" at a time
with the default short pointer instructions.

GETDSEG and friends are still largely in CM, not NM, so the same
limitations exist on sizes.  You don't go grabbing 4 gigs here either.
Memory space is 'extensible' to 4 gigs within your address space but
VSM doesn't go allocate 4 gigs just because you open a new space.

GETDSEG and friends are "not ideal" in native mode because they are
still largely in CM.  If you simply need a big array, allocate it in
your program itself.  If you need shared memory space, use a mapped
file.  GETDSEG is no longer the optimum solution, but if you have a
system with a mix of CM/NM code, it is an option.

Lund has replacements for the ***DSEG routines that operate on mapped
files in one of their toolboxes (Developer's Toolbox?).  These will
give you NM performance with the same model as the DSEG routines, but
without having to convert your code to support another paradigm.

Jeff Kell <[log in to unmask]>