@Peter, not arguing with you, and not asking you to support the unsupported, just trying to understand the general LNKLST topic.
> could be different for another address space's LNKLST I understand how different A/S's could have different LNKLSTs due to a pending LNKLST update. But isn't LNKAUTH= an IPL option that would therefore necessarily be consistent and stable across A/S's? Or am I missing some consideration? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Friday, May 26, 2017 6:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Setting of LNKAUTH available to a program? The IPA contains the specification. No documentation is, or likely ever will be, provided about the values you might find there. The field is an interface for extracting data (if any) that was specified during IPL. That's not to say that you're likely to get it wrong, or that things are likely to change in that area, but it's not impossible (there are no plans to change). If you want a programming interface for determining the state of the option, then you really ought to ask for one. Mark's code is not correct, by the way, in identifying the LNKAUTH option (APFTAB or LNKLST). You can look in the source of CSVDLCB in SYS1.MACLIB and see that the PL/X for the bit that his code is checking has the following: 5 DlcbAPF BIT(1), /* Only valid when "Active", indicates that the entire LNKLST concatenation is authorized. Can use to set DEBAPFIN @L1A*/ This applies only to the LNKLST for this address space (so could be different for another address space's LNKLST) and does mean what the commentary says. The wording is not necessarily the same as meaning that LNKAUTH=LNKLST is in effect. And it still remains a fact that it is not a programming interface. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
