APF is defined in SYS1.PARMLIB(PROGxx) according to the installation defined concatenation in IEASYSxx. The result of that concatenation determines the set of APF libraries unless modified after IPL by SETPROG APF. Entries in PROGxx are of two types:
APF ADD DSN(dsn-1) SMS APF ADD DSN(dsn-2) VOL(volser) If 'SMS' is coded, then the library can be located anywhere, but it must be SMS defined. There can only be one dsn-1 because SMS does not allow duplicates in a system. If VOL(volser) is coded, then the library must be located on that specific volume. There can be multiple entries for dsn-2; as long as one entry matches dsn-2 in STEPLIB, then it is APF; otherwise not. APF is not indicated anywhere in the intrinsic definition of a library. No bit in catalog nor in VTOC nor anywhere else outside of the list of APF libraries built and managed by z/OS. At any moment a library may or may not be APF according to the current list, which may have additions or deletions or (effectively) updates since that last time it was checked. As complicated this may sound, APF can be determined/diagnosed by inspection with relative ease. It's not rocket surgery. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Saturday, November 19, 2016 2:05 PM To: [email protected] Subject: (External):Re: Which STEPLIB concatenation is not authorized? On Sat, 19 Nov 2016 08:30:39 -0500, Peter Relson wrote: > >I assume that the subject of this thread should have been "Which data >set in the STEPLIB concatenation is not APF-authorized". > Me, too. And if that information were available the adress space could remain authorized as long as modules were loaded only from authorized catenands, and the failure of authorization could report "which data set", at least by catenand ordinal. >The DEB is build during OPEN. That processing examines the APF status >of every individual data set forming the concatenation. If any data set >is found that is not APF-authorized, then the DEB is marked as not APF >authorized (bit DEBAPFIN). (I think the bit is initialized "on" and >then simply turned off when a non-APF-authorized data set is found). By >the time "load" is being done, the information about an individual data >set is long gone. > I'll accept that as almost true. But BLDL (I assume LOAD uses that or something similar) needs to find the directories to search. I'm trying to RTRM and understand. I guess it can examine DEBAMLNG bytes in DEBEXTNM to find the first extent of each catenand which must contain the directory. But that's not enough to really identify the data set; only unit and address. Bummer. The pain customers endure because storage was so expensive a half-century ago that 32 bytes couldn't be spared for flags indicating which extents belong to authorized data sets. >CSVAPF is the programming interface for querying if an individual data >set is APF-authorized. To do it completely correctly, you have to know >if the data set is SMS-managed. > I've seen the SMS dependency mentioned earlier in this thread. Why? is it that APF is indicated in the DSCB for non-SMS and elsewhere for SMS? And I found nothing in the DEB about PDSE or UNIX files although BPAM now supports UNIX directories in mixed concatenations. How are those represented? Major and minor device numbers? It must be documented somewhere, even if only "The following N bytes are not GUPI." Hmmm. If I were to ALLOCATE a UNIX directory with DSORG=PS, RECFM-F,LRECL=256; could I read it as a PDS directory? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
