On 16-Jul-2014 12:34 -0500, Buck Calabro wrote:

In for a penny... The OIR can be got at with MI.

Though probably [hopefully] the *QDIDX and *OIRS objects, and I believe the *LIB object also, are system-domain objects. Addressing those objects would require the MI program to be system-state; or depending on the version\release installed, the value of the QSECURITY system value at or below 30.

MI programming is handled on the C list here at Midrange.com.

Note: The older archived discussions, with some topics mentioning the Object Information Repository (OIR), remain on the archived MI400 list. However I am not aware of any code examples that traverse the index and\or the space to locate any of the Text, Service, Save/Restore, Attribute, or Usage information of a particular object.

The transition to having MI discussion on the C400 list was somewhat recent, so its archive probably has a dearth of topics related to the Machine Interface (MI) [instructions and programming].

For a cheesy workaround, try DMPSYSOBJ.

Dump System Object (DMPSYSOBJ) of the object [a *DTAARA in this example], or of the *LIB in which the object resides? DMPOBJ could be easier, given the command is directed toward external objects, not the ability also to access internal objects; in either case, to get a formatted dump of the Library or the [Data Area] object.

But either request, if directed against the object, will AFaIK still require a minimum of a *SHRRD lock; the dump will likely include a line of text "OBJECT-LOCKED" to indicate the object can not be accessed, per inability to allocate. If the object could be dumped when locked exclusively elsewhere, then that output includes much more succinct and easily located and more easily processed data, due to a record with ".TEXT-" denoting the Text Description attribute; and that is always following a /section/ header record with "OIR DATA-". But parsing the OIR Space and OIR Index object data in the dump output from the library is likely to be complicated. Plus a delay for processing increases the opportunity for incorrect information to arise from transitory\temporal issues, as well as expending a lot in /work/ for what might much more easily be /resolved/ by just mimicking the OS, simply presenting the symbolic text "*IN USE" instead of the actual TEXT() attribute :-)

FWiW, the DMPSYSOBJ is nicer for limiting the overall dump output from the dump of the *LIB object, to include just the OIR portions of the data; one or both of the following [but dividing into two requests likely enables yet again, the potential for incorrect output due to concurrency because the object could be deleted and recreated betwixt]:



Return to Archive home page | Return to MIDRANGE.COM home page