>It may perhaps be time to restate the obvious. > >LINKLST has come to be used in situations remote from its original >narrow focus, which was to improve real and virtual program-fetch >performance from certain system datasets. > >It does this well, but it was never intended that volatile program >libraries---those some of the members of which are frequently >replaced---be included in it.
'Frequently replaced': Because IBM insists on the customer having this-or-that ptf installed before they even look at the problem? Which still requires IPL if the dataset is in the IPL linklist, as we have learned. So much for 24/7/365. >The natural, appropriate update time for LINKLST is IPL time, Some >sysprogs in some shops may well be able to cheat on this in some >situations; but the competence and judg[e]ment required to do so are >personal; and these cheats should not be institutionalized; in >particular, their use should never be delegated to people of 'junior >understanding'. They should probably not even be talked about much. Unfortunately, not enough happens for sysprogs to even *want* to use an IPL to update linklist datasets. For PDSs, the shutdown application - remove from lla - remove lnklst enq - update dataset - compress - return to lla - return lnklst enq - restart application works quite well. If I try to tell my colleagues that they should generate a different linklist for such a change and *not* use update jobname(*) on it to get rid of the old linklist they will refuse. Every time. Because the mechanism/concept that is behind the linklist switch is awkward in a real-world-environment. The implications are generally not really understood. And if the linklist dataset is a PDSE, then all bets are off, because what goes on behind the scenes with PDSEs is even less understood generally. And to think that PDSEs are the only things that can run on EAVs in the extended space! I am hated here when I try to enforce no secondary space or IPLs for changes to linklist datasets. And only the fact that we had a common storage overlay caused by PDSE code two days after a setprog update,jobname(*) (that IBM refused to look at under the guise of "you used a command you shouldn't") enabled me to ban update jobname(*) in this installation. >So far as I can judge from what has been posted here, the real problem >is not an arcane, PDSE-related one. It is that some libraries that do >not belong there have made their way into LINKLST. Because vendors and IBM demand to have their datasets it put into LINKLIST. Partly because they don't support ISPLLIB and dynamic steplib is frowned upon by IBM, too. Partly because vendors and components other than those supported by Peter Relson have no clue about the impacts of having datasets in linklist. Now what came first, the hen or the egg? Since usage has changed, the way it works should have been changed, too. I don't hold my breath. Barbara ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
