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.
http://archive.midrange.com/mi400/
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].
http://archive.midrange.com/c400-l/
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]:
DMPSYSOBJ TheLib *MCHCTX OBJTYPE(*LIB) OFFSET(30) /* *OIRS x/1952 */
DMPSYSOBJ TheLib *MCHCTX OBJTYPE(*LIB) OFFSET(20) /* *QDIDX x/0E90 */
midrange.com
