Good stuff !
I also have a caveat.

When I went to SSA school (in Chicago), I was told that BPCS has these RULES, which the SSA software designers had adhered to 85% of the time. That means there are potential exceptions to every rule, probably undocumented when Infor inherited BPCS. Also many companies have had in-house, and external, people doing modifications. Their adherence to BPCS rules are often closer to zero percent.

When you copied into your test library, you designated objects RCO and RCOL*.
In the version of BPCS I used to work on, in addition to logical files named whatever then L and a number, we also had J and a number, and other exceptions to naming standards.
J and a number meant join-logicals, where the logical contained content from more than one BPCS file.
That was in the documentation from SSA, so I presume it did not come from some modifications.

I cannot now remember the IBM DSP command I used to use, which listed all the LF connected to a PF, and what libraries the LF were in.

I used to GO CMDREF then dump some BPCS lib to an *OUTFILE, then later encase a cluster of libraries containing BPCS software into a single dump, to be sent to JOBQ from a menu, or regenerated in non-busy times. One application of this was to compare new capture to a prior capture, to identify what software & other objects, had been updated, added, deleted, and other statistics, in the interim. The fact that some program worked with some LF did not necessarily mean that was the rule in our shop. The *OUFILE provided statistics on what was actually going on.

Then we can query what software is accessing a particular file, sub-program, or other interest, and HOW it is accessing it, either direct vs. PF, or thru what logical, and whether the content is being updated or not.


Caveat - this approach only identifies software with fixed access, from the designated libraries, where we have access to the source code.
Some software has access which is defined at time of access, using pathways not detected by GO CMDREF.

Alister Wm Macintyre (Al Mac)
Linked In https://www.linkedin.com/in/almacintyre
Panama Papers group: https://www.linkedin.com/groups/8508998


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-2021 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.