Mark, >Not very often that I would disagree with both Chris and Barabara, but a >quick test on a sandbox system I have that still runs JES2 inits tells me >that batch jobs running in an init do indeed pick up a the new LNKLST set >(without using SETPROG LNKLST,UPDATE).
It is surprising to me that a new lnklst dataset should work without lnklst,update. But maybe IBM changed some of the internal processing. Peter? My understanding was that the linklst set of an address space is pointed to from the assb (in private of an address space, only getmained when the address space is created). Normal setprog define processing defines a new linklist set but does not update that pointer. Updating it is restricted to lnklst update. Hence a not-restarted-asid should always point to the 'old' linklist set and be unaware of a new set. As far as I know, that was the way it worked up to zos 1.6. (I haven't done any checking on 1.8.) And given the PDSE problem with lnklst update a few years back (which is supposedly finally fixed in 1.7) dynamic lnklst changes were very much frowned upon here (I had reported a common storage overlay that occured several days *after* the lnklst update, caused by PDSE code, and until Jim Mulder picked it up and noticed the significance IBM level 2 including US lvl2 told me it was our own fault for using the update in the first place.) But the few times I used it 1.2 and 1.4, I had to restart all initiators to pick up the changed linklist data sets. As for the original problem (abend106), guess I would want to look at a dump. :-) Best regards, Barbara -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
