On 21-Oct-2015 07:30 -0500, Gord Hutchinson wrote:
Is there a QSYS2 catalog for objects on 7r1? I'm looking for a way
to extract object creation and change information that's quicker than
DSPOBJD to an outfile.
Google so far hasn't been my friend. The closest I can find is
the OBJECT_STATISTICS table function.
I find that for generic object types, using the Display Object
Description (DSPOBJD) request with output direct to an Output File
(OUTFILE) suffices generally; and yes, at a snail-like pace ;-)
Although that /slow/ effect is often mostly a side effect of faulting
[unused objects into memory], and a side effect of *still* there being
no capability on the command [or the APIs] to ask that no
object-size-information is returned\included in the output; e.g.
OBJSIZINFO(*NO), or instead to suggest that just an estimate is
acceptable via OBJSIZINFO(*EST). That is something for which, although
with some other side effects that could be documented, would be a
massive improvement; especially so, the Database feature for every
DataBase *FILE (DBF) would not have to always drill-down and dynamically
sum all the sizes of the composites, and each time having done-so could
post an estimate and /staleness/ factor in the *FILE object to be
reviewed on requests asking for the estimated-size instead of the actual
size [which is temporal anyhow, as there could be concurrent increments
happening].
Another improvement to the DSPOBJD [and similar listing interfaces,
would be an Omit Object Type (OMTOBJTYPE) capability plus selection by
Object Attribute (OBJATR) and similarly an Omit Object Attribute
(OMTOBJATR); at least an OBJATR() could be especially helpful, mimicking
the capabilities of the FILEATR() on Display File Description (DSPFD) to
limit from which objects details are gathered, or similar to the Program
Attribute (PGMATR) on the Work With Programs (WRKPGM) to limit the list].
Anyhow, is there something specific that can be articulated about
making that request, for which the request is deemed too slow? Is the
issue solely the amount of data produced in writing and consumed by
reading excessive? As I recall, that could be reduced, even if not all
the work that is performed to gather that info.
Depending on what needs to be extracted and what eventually needs to
be done, there may be alternatives that can be suggested, specifically
for how they might assist for the particular task; but the OP reveals
nothing specific, just a desire for something that is not DSPOBJD. More
generally I could offer that using what is described in the following,
should enable an [possibly immense, depending on the specifics]
improvement over using either of DSPOBJD or OBJECT_STATISTICS:
Requesting object information via the OBJD0100 Format "Basic
information (fastest)" of the Retrieve Object Description (QUSROBJD) API
for which no size information is included [but both the Creation and
Last Changed date\time information are included], is probably going to
be the quickest means to limit the data to just those attributes.
[
https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/qusrobjd.htm]
However doing that still requires the [list of the] object names must
still be generated.
Both the list and the "Basic Information" can be obtained in one
request using the OBJL0300 format "Basic object information" of the List
Objects (QUSLOBJ) API. Or that listing API can be used to generate
solely the list of names using the OBJL0100 format "Object names
(fastest)", and then defer to the QUSROBJD, perhaps only for retrieving
information of objects for which knowingly the information is desirable,
despite the inclusion of the object in an overly generic listing; i.e.
if the listing API includes the info, that info is gathered for every
entry, whereas the names\type-only listing, no additional work is done.
[
https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/quslobj.htm]
Though I have not [or just do not recall having] coded to the Open
List of Objects (QGYOLOBJ) API, that API appears to enable a keys-based
request for information, such that the returned information can be
explicitly pared to only the desired values [e.g. key=0304 asking to
return a CHAR(8) with "Creation date and time" and key=0305 asking to
return a CHAR(8) with "Change date and time"].
[
https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/qgyolobj.htm]
Like the names\type-only capability of the QUSLOBJ API, the
Materialize Context (QusMaterializeContext) API can similarly provide a
list of names and types [though type\subtype vs external object type];
that can similarly be paired with the QUSROBJD against any specific
object name\type from the generated list. That method is probably the
closest one can get to the fastest means available; that is the minimal
overhead for the listing request, as the documentation suggest, is
effectively the slightly indirect access to what those list APIs use,
being the Materialize Context (MATCTX) MI instruction to which the API
redirects for documentation of inputs\outputs.
[
https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/apis/qmatctx.htm]
[
https://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rzatk/MATCTX.htm]
midrange.com
