Re: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 Assembler.

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 ""large memory"" ADS mapless dialog. These dialogs would allocate their memory using 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 unless 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