Kay,
Intriguing question. The short answer is no, not as easily as in COBOL or =
Assembler.
With that said here are some thoughts:
You can always pre-allocate with an 01 level work record. In this case eve=
ry instance of the task will allocate the maximum amount of memory.
If you are looking to store an array of smaller items then the scratch pool=
will work as long as you don't need addressability to the entire array at =
the same moment. If you do, your work record definition will cause ADS to =
pre-allocate the large memory making the whole read from scratch thing mute=
.
If the dialog only needs a large chunk of storage once in a while and you w=
ant to avoid allocating the maximum storage for every invocation then consi=
der writing a service subroutine routine in COBOL. Let that subroutine mana=
ge its memory, no addressability in ADS.
For 100% ADS, you could use a ""small memory"" ADS mapless dialog and a ""larg=
e memory"" ADS mapless dialog. These dialogs would allocate their memory us=
ing a private work record. These would be identical except for the upper l=
imit occurs in their work record. Your app would call the ""large version o=
nly when necessary. You can't share the work record between the caller and=
subroutine as this would defeat the purpose. So this would be a service s=
ubroutine like the COBOL one.
Calling an assembler routine passing an 01 level, then having the assembler=
routine allocate the storage and fool ADS by swapping out the pointer coul=
d be don but it is a bad idea. Even if it worked you couldn't count on CA =
leaving it that way in future releases. Don't consider this approach unles=
s you can get CA to endorse it.
If you can share what you want to accomplish we might be of more help.
Cheers,
Tom Hebert
ObjEx, Inc.
28248 N Tatum Blvd
Ste B1-268
Cave Creek, AZ 85331
Tel: 01 (908) 813-2866
Fax: 01 (208) 567-1879
email:
Tom.Hebert@obj-ex.com
web:
http://www.obj-ex.com