ca.portal.admin

ADS question

Discussion created by ca.portal.admin on Mar 1, 2010
(From a non-ADS programmer.) Is it possible to do ""GET STORAGE"" and ""PUT
STORAGE"" commands in ADS code? I don't see them in the ADS reference guide.

Kay Rozeboom
State of Iowa
Information Technology Enterprise
Department of Administrative Services
Telephone: 515.281.6139 Fax: 515.281.6137
Email: Kay.Rozeboom@Iowa.Gov
"
IDMS 3rd-party providers forum
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP
IDMSVENDOR-L@LISTSERV.IUASSN.COM
IDMSVENDOR-L@LISTSERV.IUASSN.COM
SMTP








Normal

Normal
Re: ADS question
"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
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.

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

Outcomes