× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi, Dennis:

OS/400 and i5/OS maintains all of this "cross reference" information in the _Object Information Repository_ (OIR) for each library, but as of today, the operating system does not provide any APIs to allow for direct interrogation or manipulation of the data contained within this repository, except for the DSPPGMREF command. Issuing DSPPGMREF PGM(library/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) effectively "dumps" the entire contents of the OIR for the designated library into a database file that can easily be read and queried.

Your approach of doing a DSPPGMREF for a given *PGM, then reading the *OUTFILE and for each *PGM object contained therein, issuing another DSPPGMREF, and then processing that *OUTFILE, and so on, would work only for a "top-down" approach or a "drill-down" style of analysis that can be used to answer the question "_What objects are used by this program_"?
But, suppose you need to add one more parameter to this program? Then, you will need to ask the question, "_Where are all the places that CALL (use) this program_?" -- the proposed "top-down" recursive method cannot answer this second question.

To answer this second question, you would need to use the approach suggested by several others, to first create a list of all of the objects that comprise this application (usually, all objects in a given library), e.g. DSPPGMREF PGM(library/*ALL) OBJTYPE(*ALL) OUTPUT(*OUTFILE) to a "composite" *OUTFILE (perhaps named based on the name of the application library in question).

Then, use any of the various query tools, including Query/400, QueryManager/400, SQL, or even plain old RPG programs, to perform inquiries over this "composite" DSPPGMREF database, to answer the question, "Where is this object used?". And you might want to create one or more logical files with different keys, or SQL indexes, to speed various searches of the data.

You would also need to update this "composite" database each time any *PGMs are changed or added within that application library, or just run a nightly (or weekly) job to "refresh" the "composite" DSPPGMREF *OUTFILE database.

_SUMMARY_
Create a single large cross-reference database, using DSPPGMREF, and then interrogate that database to find "What objects are used by this program?" and "What programs use (CALL) this program?"

All the best,

Mark S. Waterbury

> Dennis Lovelady wrote:
I was shocked to see that, at V5R3 there is no Retrieve Program References
API that I can find. I do know about DSPPGMREF to an output file, and all
that, but this surprises me. Am I missing some obvious alternative method?
I need to gather together all the objects that are involved with changes to
certain programs. (It quickly gets deeper than that, but that's the
starting point. Most of the rest I have done many times.)


Dennis E. Lovelady
AIM/Skype: delovelady MSN: fastcounter@xxxxxxxxxxxx
<http://www.linkedin.com/in/dennislovelady>
www.linkedin.com/in/dennislovelady --
We don't care. We have each other, on the Internet.
- Dave Barry

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.