Verify APF libraries

[gsg]

We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB. We've compared what is in LINKLIST to what is in APFLIST and came up with a list of datasets that are not in APFLIST, but could need to be APF-Authorized. Is there an easy way to determine if the datasets need to be APF-Authorized? Is there any SMF records that might show if a dataset was previously used as being APF-Authorized?

Thanks in advance.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@listserv.ua.edu with the message: INFO IBM-MAIN

[John McKown]

My first attempt would be to see if any module not in the actual APF list
is marked as APF. You can do this rather easily by browsing each library in
ISPF option 1, then doing a "SORT APF D" on the command line. But this
doesn't guarantee that some other APF linked program does not do a LINK or
LOAD (or XTCL or ATTACH) of one of those modules as a subroutine. In this
latter case, I _think_ you get some sort of a S306 abend on the attempted
access of the module if it is not in an APF authorized library.

--
The temperature of the aqueous content of an unremittingly ogled
culinary vessel will not achieve 100 degrees on the Celsius scale.

Maranatha! <><
John McKown

[R.S.]

W dniu 2014-10-20 o 18:56, gsg pisze:

> We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB. We've compared what is in LINKLIST to what is in APFLIST and came up with a list of datasets that are not in APFLIST, but could need to be APF-Authorized. Is there an easy way to determine if the datasets need to be APF-Authorized? Is there any SMF records that might show if a dataset was previously used as being APF-Authorized?

Regardless of the reason for the change and APF list format you should
perfectly know why each library is on the list.
In most cases it will be "because mama said so", that means it is
documented in product documentation.
For installation-defined libraries you should maintain the
documentation, but on member level.

Note, the "previous use" is very dangerous. Maybe some modules are
called in very specific cases.

HTH

--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kon...@mBank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote.

[Bob Shannon]

> We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB

I'm curious why you are making this change. I view LNKAUTH=LNLKST as a godsend.

Bob Shannon
Rocket Software
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 800.966.3270 ■ +1 781.577.4321
Unsubscribe From Commercial Email – unsub...@rocketsoftware.com
Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_SubscriptionCenter.html
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

[Paul Peplinski]

An audit?

[Mark Zelden]

On Mon, 20 Oct 2014 17:41:44 +0000, Bob Shannon <bsha...@ROCKETSOFTWARE.COM> wrote:

>> We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB
>
>I'm curious why you are making this change. I view LNKAUTH=LNLKST as a godsend.

In general, it seems auditors frown upon that option. I've had to make the change
at several different clients of mine in the past.

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:ma...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/

[John Eells]

00000053fe88ed3...@LISTSERV.UA.EDU (gsg) wrote:
> We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB. We've compared what is in LINKLIST to what is in APFLIST and came up with a list of datasets that are not in APFLIST, but could need to be APF-Authorized. Is there an easy way to determine if the datasets need to be APF-Authorized? Is there any SMF records that might show if a dataset was previously used as being APF-Authorized?

Did you install using ServerPac? If so, Modify System Layout has a View
and Change option that will display whether APF authorization is
required for each data set in the order. It's marked:

APF Required APF Authorization Required (Yes or No)

You would need to repeat this display for every order used for the
products on the system. (For example, you might need to display APF
Required for z/OS, DB2, CICS, IMS, etc.)

For z/OS data sets, there is a table in the Program Directory that
documents those required in the APF list, either implicitly (via
=LNKLST) or explicitly (via =APFTAB). In the z/OS V2.1 level of the PD
it's in Figure 43, which starts on p. 142. The PDF of the V2.1 PD is
here: http://publibz.boulder.ibm.com/epubs/pdf/e0zpdz00.pdf

However, the list in the PD does not address other products' APF
required data sets, only those for z/OS itself. The PD and/or
installation guides for the other products should say whether they have
APF Required data sets.

Hope this helps...

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
ee...@us.ibm.com

[Chase, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Mark Zelden
>
> On Mon, 20 Oct 2014 17:41:44 +0000, Bob Shannon <bsha...@ROCKETSOFTWARE.COM> wrote:
>
> >> We're making the change from LNKAUTH=LNKLST to LNKAUTH=APFTAB
> >
> >I'm curious why you are making this change. I view LNKAUTH=LNLKST as a godsend.
>
> In general, it seems auditors frown upon that option. I've had to make the change at several
> different clients of mine in the past.

Seems reasonable to me. Consider the case of placing a load library of mostly installation-written COBOL batch programs into the LNKLST to avoid having to code perhaps thousands of //STEPLIB or //JOBLIB statements in the "nightly batch run". Would you really want those programs to be APF-authorized?

-jc-

**********************************************************************
Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person.

[Barry Merrill]

The only references to APF status that I can find in all records processed
by MXG, SMF and others are:

-A flag in RACF Unload file (RAC900: USS RACF BASIC RECORD)

APF CHAR 4 APF BIT ON?

Two fields in SMF 92 subtype 15 (TY9215: OMVS EXTENDED SECURITY CHANGES)

SMF92ANA CHAR 1 $HEX2.0 NEW*APF*AUTH*WAS*ON
SMF92AOA CHAR 1 $HEX2.0 OLD*APF*AUTH*WAS*ON

Barry


Herbert W. “Barry” Merrill, PhD
President-Programmer
MXG Software
Merrill Consultants
10717 Cromwell Drive
Dallas, TX 75229
ba...@mxg.com

http://www.mxg.com - FAQ has Most Answers
ad...@mxg.com – invoices/PO/Payment
sup...@mxg.com – technical
tel: 214 351 1966 - expect slow reply, use email
fax: 214 350 3694 – prefer email, still works

[Peter Relson]

>Consider the case of placing a load library of mostly
>installation-written COBOL batch programs into the LNKLST
>to avoid having to code perhaps thousands of //STEPLIB or
>//JOBLIB statements in the "nightly batch run".
>Would you really want those programs to be APF-authorized?

Of course not, but making a data set APF-authorized is not sufficient to
bestow APF-authorization upon a program that is the target of EXEC PGM=.
That requires AC=1. And that could be checked before adding such a data
set to the LNKLST. That is a reason why, naturally, it is very important
not to have modules mismarked as AC=1.

Putting such a data set into the LNKLST with LNKAUTH=LNKLST does, however,
mean that if an authorized program asks to fetch such a module (perhaps to
LINK to it), that fetch will be granted. That is a danger of marking any
data set as APF-authorized that should not be.

FWIW, if you just want to see if your APF list completely has all of the
LNKLST libraries, you could capture the output of DISPLAY PROG,LNKLST and
DISPLAY PROG,APF then sort and compare. That will at least give you an
idea (although the APF entries may show volume, and the LNKLST entries
could have a data set alias whereas the APF entry is supposed to be the
"real" data set name).

Peter Relson
z/OS Core Technology Design

[Elardus Engelbrecht]

Barry Merrill wrote:

>-A flag in RACF Unload file (RAC900: USS RACF BASIC RECORD)
> APF CHAR 4 APF BIT ON?

Sorry, I don't find it in my RACF books. Not in SMF unload or RACF unload chapters either. Where is that documented?

Just curious if you don't mind, please.

>Two fields in SMF 92 subtype 15 (TY9215: OMVS EXTENDED SECURITY CHANGES)

>SMF92ANA CHAR 1 $HEX2.0 NEW*APF*AUTH*WAS*ON
>SMF92AOA CHAR 1 $HEX2.0 OLD*APF*AUTH*WAS*ON

Are you refering to

SMF92AOLDGENVALSECBYTE and SMF92AOLDAPFAUTHC and / or

SMF92ANEWGENVALSECBYTE and SMF92ANEWAPFAUTHC ?

These above names are coming from SMF book.

Many thanks.

Groete / Greetings
Elardus Engelbrecht

[Walt Farrell]

On Tue, 21 Oct 2014 07:13:50 -0500, Elardus Engelbrecht <elardus.e...@SITA.CO.ZA> wrote:

>Barry Merrill wrote:
>
>>-A flag in RACF Unload file (RAC900: USS RACF BASIC RECORD)
>> APF CHAR 4 APF BIT ON?
>
>Sorry, I don't find it in my RACF books. Not in SMF unload or RACF unload chapters either. Where is that documented?
>
>Just curious if you don't mind, please.

He's referring to the type 0900 "database unload" record created by the IRRHFSU utility from the RACF Downloads page at
http://www-03.ibm.com/systems/z/os/zos/features/racf/downloads/irrhfsu.html

--
Walt

[Elardus Engelbrecht]

Walt Farrell wrote:

>He's referring to the type 0900 "database unload" record created by the IRRHFSU utility from the RACF Downloads page at
> http://www-03.ibm.com/systems/z/os/zos/features/racf/downloads/irrhfsu.html

Yes! That is that! Many thanks for kindly helping out.

I totally forgot about that little goodie.

Many thanks again.

Groete / Greetings
Elardus Engelbrecht