On Fri, 28 Mar 2008 11:35:54 -0500, Paul Gilmartin wrote: >In an earlier contribution, you mentioned that JES holds no ENQ >on the PROCLIBs. That sounds terribly dangerous. Why would they >design it that way?
Yes, I believe it is very dangerous for JES2 to not hold an ENQ for its data sets. Some months ago, I submitted the following requirement to JES2 through my marketing rep, and a similar one through the JES2 Project at SHARE. To the best of my knowlege, there has been no formal response to this requirement, but from conversations at SHARE on this issue, I believe the requirement is "understood" (which is always a good first step). Here's how I phrased my requirement to JES2 regarding this issue: "Today by default, JES2 does not participate in standard z/OS data set serialization (an ENQ on MAJOR SYSDSN, MINOR data.set.name). As a result, by default, it is possible for a user to delete an in-use JES2 PROCLIB data set without notification that the data set is in use. If the user codes JES2 PROCLIBs in JES2's JCL, the next start of JES2 will fail with a JCL error. Today, JES2 depends only upon knowledgeable users to avoid inadvertent deletion of data sets critical to the operation of JES2. To protect customers from an inadvertent error causing a system outage, JES2 should use standard z/OS facilities to protect via ENQ its PROCLIB data sets. "Because of the value NODSI in the IBM default PPT entry for program HASJES20, any DD statement coded in the SYS1.PROCLIB(JES2) JCL is unprotected by ENQ. NODSI is defined as follows: "If NODSI is specified, the system still issues an ENQ for all data sets requested by the program. However, the ENQ is released before the problem program is started." So, the protection exists as the system starts JES2, but is released after step initiation and before control is passed to HASJES20. "Further, JES2 extends its "no ENQ" philosophy by specifying S99NORES for Dynamic PROCLIB data sets JES2 allocates via SVC 99. Because of the use of S99NORES, even if the customer overrides the PPT entry for HASJES20 to specify DSI, JES2 does not hold an ENQ for any of these data sets. The z/OS Allocation component describes the responsibilities for the use of S99NORES as follows: "Note: Data sets being allocated are normally serialized via ENQ with MAJOR name SYSDSN, MINOR name -data set name-. When S99NORES is set, there is NO data set serialization and multiple tasks may reference or update the data set simultaneously, resulting in unpredictable effects. It is the responsibility of the authorized program setting S99NORES to provide the necessary serialization." It is the opinion of the author of this requirement that JES2 provides no facility to provide the necessary serialization, as specified by the documentation for S99NORES. "Originally, OS/390 and MVS did not hold an ENQ for system link list data sets. More than ten years ago, IBM added such ENQ protection for system link list data sets. IBM also, in 1997, added the SETPROG LNKLST,UNALLOCATE command to allow the user to release this ENQ protection in the event a same- named data set required some sort of maintenance. "Further, about seven years ago (in the OS/390 2.10 timeframe) IBM enhanced DFP to add support for the authorized rename of apparently in-use data sets. This authorization is based upon FACILITY class STGADMIN.DPDSRN.nnn and allows a user who presumably knows what he is doing to rename a data set otherwise protected by an ENQ. This capability is documented in manual 'z/OS Using Data Sets'. "More than a decade ago, IBM decided that it was important to protect the system link list data sets with an ENQ. It is time for JES2 to do the same. Doing so would help customers avoid outages which are caused by the deletion of non serialized but critical and in-use data sets needed by JES2. "Twenty years ago, JES2 systems programmers were "god" at most shops. Today, in light of HIPPA, SOX, and other government regulations, the author of this requirement has only READ authority to several JES2 PROCLIB data sets, while other non-systems programmer staff have ALTER authority. It is no longer sufficient to rely upon knowlegable sysprogs to protect JES2 - ENQ is required. "This exposure has resulted in a multi-system outage for the author of this requirement. A JES2 PROCLIB data set, shared by every JES2 in the sysplex, was deleted by an individual RACF-authorized to do so. Some hours later, after the DASD extent containing the deleted PROCLIB's directory was reused by another data set, every batch job and TSO Logon attempt within the entire sysplex failed due to I/O Error in BLDL. A Hot Start of JES2 failed with a JCL error due to the missing data set. It was only pure chance that the JES2 sysprog was still logged on to TSO prior to the I/O Errors starting which allowed for a relatively non-disruptive recovery from this problem - the JES2 JCL was changed to remove the deleted PROCLIB, and JES2 hot-started on every LPAR. Had the JES2 sysprog not been logged on, there may have been no RACF authorized user still able to use the system, which would have made recovery much more problematic. "As a result, this customer has implemented DSI for the HASJES20 PPT entry, and has had this value in effect for two years. "Now, as this customer moves to take advantage of JES2 features to further protect JES2 from damage by taking advantage of Dynamic PROCLIB within JES2 startup parms, this user is losing the protection afforded by DSI in the HASJES20 PPT entry, because of JES2's use of S99NORES." Brian ---------------------------------------------------------------------- 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
