XRef by Subprogram


i would like to read XRef-Data from my own Program. Is there a Userexit or something else which i could use to get all Children of a Source. E.g.

A Program P01 which calls S01 via callnat and I01 via INCLUDE and use D01 via Parameter using and so on. Now i would see something like the following:

P01 - S01 - Callnat
P01 - I01 - Include
P01 - D01 - Parameter

Is there a Subprogramm which i could use?

Greeting Sascha

AFAIK there is no subprogram to achieve this.

What do you want to do with the results? LIST XREF direct commands do all you want, if you are interested in the list. You can save a set of the used/called copycodes/data areas/subprograms and so on. With this set you can then work (edit, catalog, and so on). In NSPF you can even issue a command “L * SET=n” to work on this set.

Once I wrote a release management application that depended on XREF. When a program was checked in, it analyzed the dependent objects and recataloged these objects. It even worked with steplibs. Programs that resided in a lower steplib were copied into the release library (the highest steplib) and recataloged. This also worked with version forks.

It is not easy to analyze the dependent objects with a self made program. Dependencies reside in different attributes and the structure of the xref data is not easy to understand. It was very hard work!

Many developers shy away from writing against SYSDIC-XREF directly but due to limitations of what’s been supplied by the vendor we have. Once you gain a basic understanding of how SYSDIC-XREF is laid out, It’s not that difficult. After the prereqs of having XREF data turned on and generating a SYSDIC-XREF DDM, I would suggest the following:

  1. SYSDIC-XREF is driven by a key N-LIB-PGM (A32) PRD441 may be (A20) if you have an older version. I’m assuming to make it compatible across platforms they got rid of the binarys. The layout of the field is:
    DBID N5
    FNR N5
    SEQ N3

DBID and FNR reflect which FUSER your objects are cataloged on.
LIBRARY and PROGRAM well you know what they are
REC-TYPE defines what type of XREF data is stored on that record. The types can be found in the extended description of the file SYSDIC-XREF in Predict.
SEQ defines the number of records you may have for a rec-type. For example you may be accessing a file that has 70 fields being used. Each record may only hold 60 fields so you would have 2 records for that type.

If you browse through the fields in SYSDIC-XREF in PREDICT they are loaded with info. To do this go to direct command ‘MA EL’ and select browse function and enter field N-PGM and file SYSDIC-XREF.

N-PGM is a MU field and kind of like a superdesc. It’s made up of the first byte being a usage type and the rest is the used program. So if you wanted to see all the programs that used subprogram XYZ you would write the following:


this would give you all the Natural objects that have a CALLNAT to XYZ in them.

In order to get use to what you have on SYSDIC-XREF I would suggest running this program and you can pick and choose different fields to look at. Keep in mind that this is not all the fields on the file but gives you an idea.

#DBID = 6
#FNR = 18

  • #REC-TYPE = ?
  • #REC-SEQ = ?

REDEFINE N-LIB-PGM(#D(N5) #F(N5) #LIB( A8 ) #PGM( A8 ) #R(N3) #S(N3))

  • ESCAPE                                                       
    DISPLAY #D / #F #LIB / #PGM #R #S
  • DA-VIEW( 1:3 )
  • N-VIEW /
    N-PGM( 1:8 )
  • N-FIELD( 1:60 )

I don’t mention this to bring up a long discussion around accessing the SYSDIC-XREF file directly but just want you to know that it’s not as hard as some make it out to be. You just need the basic understanding of the record layout and how to access which PREDICT documentation does a pretty good job at giving you what you need.

This will give you a start if you want to take this direction.

Mark Olson
EDS/Marathon Oil

[quote="Wilfried B

Thank you Mark this very good example. I had to build SYSDIC-XREF first, because the DDM didn’t exist. But now i could run your Example and it looks very nice!!!