Re: ADS question

Discussion created by ca.portal.admin on Mar 1, 2010

Intriguing question. The short answer is no, not as easily as in COBOL or

With that said here are some thoughts:

You can always pre-allocate with an 01 level work record. In this case
every 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
want to avoid allocating the maximum storage for every invocation then
consider writing a service subroutine routine in COBOL. Let that subroutine
manage its memory, no addressability in ADS.

For 100% ADS, you could use a ""small memory"" ADS mapless dialog and a ""larg=
memory"" ADS mapless dialog. These dialogs would allocate their memory usin=
a private work record. These would be identical except for the upper limit
occurs in their work record. Your app would call the ""large version only
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
subroutine 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 could
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=
you can get CA to endorse it.

If you can share what you want to accomplish we might be of more help.


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