In a recent note, Kurt Quackenbush said: > Date: Wed, 11 Oct 2006 09:28:20 -0400 > > Sounds like you didn't try APPLY CHECK before running the APPLY, and > therefore you've got stuff left over in the target zone. Probably an > element entry got updated in the target zone during the first APPLY. > Rejecting the USERMOD from the global zone does not cleanup the target zone. > Ouch! So it updates the element's SYSLIB (or whatever) subentry in the element's target zone entry without even determining whether it can allocate the data set? And then when the user supplies a corrected SYSMOD it attempts to allocate the data set before updating the SYSLIB subentry? I could imagine a more robust design.
Could the user recover by providing a DD statement in JCL for the bogus DDNAME for one APPLY which would correct the CSI for the future? -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
