Hi, Tom:
Here is a technique to consider:
1. Create a user space in the library where these objects (*PGMs and
*SRVPGMs) reside, to contain any "related data" you want to store.
2. Store a "reference" to this user space and the offset within that
space, via QLICOBJD, into some of these fields:
Compiler (13)
Object control level (8)
PTF (7)
APAR (6)
User defined attribute (10)
For example, store the 10-character object name of a *USRSPC in the
"User defined attribute", plus a 24-bit offset into that user space, as
a hexadecimal character string (6 digits), in the APAR field (recall
that a *USRSPC is limited to 16 MB and 24-bits will address all 16 MB)..
This technique uses a "header" at the start of the user space to keep
track of the next available position within the user space, so that as
new information is about to be added, the program retrieves this "next"
position, adds the size of the needed space, and then updates this
header with the new "next" position. Use the CMPSWP MI instruction to
ensure that two jobs or threads do not update this header at the same
time. Always update the header before inserting data at the newly
allocated offset.
Store the information you need into this "related data" user space at
that offset. This *USRSPC must reside in the same library as the
programs that refer to it.. This way, so long as the *USRSPC and any
*PGMs or *SRVPGMs that refer to it are saved and restored together (e.g.
via SAVLIB and RSTLIB), this linkage will still work, even across a
"save/restore" boundary (even if saved and restored on different systems.)
At runtime, call QUSROBJD to retrieve the "User defined attribute" to
use as the name of the user space, and retrieve the "APAR" and convert
from hex to binary to use as the offset within the user space. Call
QUSPTRUS to obtain a pointer to that user space, and use pointer
arithmetic to add the offset to get a pointer to the related data.
With this method, you could store very large amounts of "related data"
for one or more *PGMs (or *SRVPGMs) in the library; all related data is
stored into the same user space (up to 16 megabytes per user space). If
more space is needed, create another *USRSPC, and store the name of that
user space and the offset within that user space into the same fields in
those additional *PGMs or *SRVPGMs.
This approach is viable for both OPM and ILE *PGMs, and for ILE
*SRVPGMs, and pretty much ANY OS/400 object type.
All the best,
Mark S. Waterbury
> Tom Liotta wrote:
Tom Liotta wrote:
An OPM COBOL (for example) *PGM can have info stored in its 'associated
space' and later retrieved. The info can survive program calls as well
as saves/restores (important). For some purposes, this is extremely handy.
Is there a similar function available for ILE?
The Add Associated Space Entry (QbnAddAssociatedSpaceEntry) API is
similar to the Store Program Associated Space (QCLSPGAS) API, but seems
to work on modules before they're bound into programs. Once the program
is created, no further additions/changes seem possible.
The reason this comes to mind is the future charges for OPM compilers
separate from ILE. It'd be a challenge to justify buying an OPM license
for such a small element. I have 'a way' around it, but it'd be best to
know a 'real' method.
Thanks for any suggestions.
Nothing? Anyone?
Bueller? Bueller?
Sigh.
Tom Liotta
midrange.com
