To add a bit to what Peter said, I'll repeat what I said in a private
note: We do not test our software with data sets in the link list that
are not intended to be present there. I'll further add that we
generally do not even design our software to tolerate running in that
environment.
So in many ways, making certain that data sets that don't belong in them
is not in those lists is as important as making sure the things you need
*are* in them. If IBM Development doesn't know what will happen,
neither do you...
This is why I asked the OP why it was thought necessary to add SCEELKED
to the link list. I want to be sure we don't somehow document,
somewhere, that it should be.
[email protected] (Peter Relson) wrote:
<snip>
In general, it is a bad idea to put any data set (or module) in the LNKLST
unless the owner has indicated that it is OK to do so. Otherwise you could
be introducing a system integrity problem. The system rule is that
authorized programs must load things only from authorized concatenations,
and that (by default) the LNKLST is treated as an authorized concatenation
even if the individual data sets are not APF-authorized (this is the
LNKAUTH=LNKLST system parameter, as contrasted with the LNKAUTH=APFTAB
system parameter). Not every program is written to be safe if invoked in
an authorized state. Stronger, it seems likely that a huge percentage of
programs that were not specifically intended for authorized environments
are indeed not safe if invoked in an authorized environment.
<snip>
--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
[email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
