On Thu, 19 Feb 2009 01:34:56 +0000, Ted MacNEIL <[email protected]> wrote:
>>I tried with two ids, same pds, different members, same monoplex with no
>surprising results.
>
>Please tell me what's changed!
OPEN.
>
>I did this, and got bad results.
>I'm surprised, since on 1.4, I got what I said.
>What did I do wrong?
>-
The change to add the SYSZDSCB ENQ was around the early to mid 90s IIRC.
Long before anyone heard of OS/390 - let alone z/OS.
Okay... it took me a while, but I found the apar that added the support.
It was even earlier than I thought. DFP/XA 2.3 (HDP2230). APAR OY07766
and the PTF was available 12/14/1987 - UY15908.
APAR Identifier ...... OY07766 Last Changed ........ 99/04/20
DSCB INTEGRITY SUBJECT TO EXPOSURE
Symptom ...... IN INCORROUT Status ........... CLOSED PER
Severity ................... 3 Date Closed ......... 87/11/20
Component .......... 566528413 Duplicate of ........
Reported Release ......... 230 Fixed Release ............ 999
Component Name DFP/XA O/C/EOV Special Notice
Current Target Date .. Flags
SCP ...................
Platform ............
Status Detail: ASSIGNMENT - APAR has been assigned to a
programmer.
PE PTF List:
PTF List:
Release 230 : UY15908 available 87/12/14 (F802 )
Parent APAR:
Child APAR list:
ERROR DESCRIPTION:
IN ORDER TO PROTECT THE INTEGRITY OF THE DSCB OF PDS'S FROM:
1. TWO OR MORE USERS OPEN TO DIFFERENT MEMBERS OF A PDS
DATASET FOR OUTPUT WITH DISP=SHR
*** DOES NOT APPLY TO OPEN FOR UPDAT ( UPDATE )
2. UPDATING THE DATE LAST REFERENCED FIELD IN THE DSCB FOR THE
FIRST ACCESS OF THE DAY WHEN THE FIRST ACCESS OF THE DAY IS
FOR READ (DISP=SHR), ALSO KNOWN AS THE MIDNIGHT PROBLEM.
NOTE: THIS APAR ADDS A RETURN CODE (RC30) TO THE ABEND213
MSGIEC143I ABEND213-30
ADDITIONAL SYMPTOMS: MSGIEB189I
LOCAL FIX:
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: ALL USERS USING PDS DATASETS *
****************************************************************
* PROBLEM DESCRIPTION: CORRUPTION OF A PARTIONED DATASET'S *
* DIRECTORY WHICH THEN GIVES SYMPTOMS *
* OF LOST MEMBERS, DUPLICATE TTRS, OR *
* CORRUPTED MEMBERS OF THE PDS. *
****************************************************************
* RECOMMENDATION: INSTALL THE PTF *
****************************************************************
THIS APAR ADDRESSES TWO PROBLEMS. THE FIRST PROBLEM OCCURS WHEN
A USER ALLOCATES A PDS WITH DISP = SHR AND THEN OPENS A MEMBER
FOR OUTPUT. THE USER KEEPS THE PARTIONED DATASET OPEN THROUGH
MIDNIGHT. ANYTIME AFTER MIDNIGHT, A SECOND USER OPENS THE SAME
DATASET FOR INPUT. THE SECOND OPEN READS THE FMT1 DSCB TO UPDATE
THE DATE-LAST-REFERENCED FIELD. AFTER THAT THE FIRST USER CLOSES
THE DATASET AND CLOSE WRITES BACK THE FMT1 DSCB, THE DS1LSTAR
AND DS1TRBAL FIELDS WOULD THEN GET UPDATED TO REFLECT THE NEW
LOCATION OF THE MODIFIED MEMBER. WHEN THE SECOND OPEN WRITES
BACK THE FMT1 DSCB, THE VALUES OF DS1LSTAR AND DS1TRBAL WILL NOW
GET RESET WITH THEIR OLD VALUES WHICH WOULD, IN EFFECT, LOSE THE
CHANGED MEMBER FROM THE FIRST OPEN. THE SECOND PROBLEM OCCURS
WHEN TWO USERS HAVE ALLOCATED A PDS WITH DISP = SHR AND EACH ONE
OPENS THE DATASET FOR OUTPUT TO WORK ON DIFFERENT MEMBERS. ONE
OF THE USERS UPDATES MAY BE LOST BECAUSE THEY EACH HAVE THE SAME
COPY OF THE DIRECTORY AND THE LAST ONE FINISHED WILL CAUSE THE
DIRECTORY TO REFLECT ONLY HIS CHANGES. IF THE FIRST USER CAUSED
A NEW MEMBER TO BE ADDED, THAT NEW MEMBER WOULD NO LONGER EXIST.
IF THE FIRST USER HAD MODIFIED A MEMBER, ITS DIRECTORY ENTRY
WILL NOW POINT TO THE SECOND USERS MEMBER (DUPLICATE TTR'S).
PROBLEM CONCLUSION:
THE PDS CORRUPTION WILL BE ELIMINATED BY USING TWO NEW RESOURCES
THAT WILL BE ENQUEUED UPON DURING OPEN AND CLOSE PROCESSING.
THESE NEW ENQUEUES WILL BE PERFORMED ONLY IN SOME
CIRCUMSTANCES. MOST OF THE CHANGES ARE INTERNAL TO THE SYSTEM
AND WILL NOT BE NOTICED BY THE END USER WITH ONE EXCEPTION. IF
USERA ALLOCATES A PDS WITH DISP = SHR AND OPENS THE DATASET
FOR OUTPUT AND USERB ALLOCATES THE SAME PDS WITH DISP = SHR
AND ALSO ATTEMPTS TO OPEN THIS DATASET FOR OUTPUT, USERB'S
OPEN WILL NOW FAIL WITH AN ABEND213-30. THIS WOULD HAVE
SUCCEEDED PRIOR TO THE FIX AND ALMOST CERTAINLY WOULD HAVE
CORRUPTED THE DIRECTORY. THE NEW RESOURCES BOTH HAVE THE SAME
MAJOR NAME OF SYSZDSCB. THE MINOR NAMES (RNAME) ARE SIMILAR
AND WORK TOGETHER TO SERIALIZE OUTPUT TO THE PARTITION
DATASET. THE MINOR NAMES CONSIST OF: VOLSER+MODE+DSN WHERE THE
MODE CAN EITHER BE AN "A" OR AN "S". THE RESOURCE WITH MODE
EQUAL TO "S" IS ENQUEUED UPON WHEN A PDS IS OPENED WITH A
DISPOSITION = SHARE (EITHER INPUT OR OUTPUT). THE RESOURCE
WITH MODE EQUAL TO "A" IS ENQUEUED UPON WHEN A PDS IS OPENED
WITH A DISPOSITION = SHARE AND OUTPUT. IF THE "A" MODE
RESOURCE IS NOT AVAILABLE WHEN NEEDED BECAUSE SOME OTHER TASK
HAS OPENED OUTPUT SHARED TO THE PDS, AN ABEND213 RC30 WILL BE
GIVEN TO THE TASK THAT IS NOW REQUESTING THE RESOURCE. ALL "S"
MODE RESOURCE CONTENTION WILL BE HANDLED AUTOMATICALLY.
Note that since SYSZDSCB is ENQed SCOPE=SYSTEMS for
shared DASD, it does not have to be specifically defined
to GRS. The effect of this code will be nullified if
SYSZDSCB is specifically excluded from GRS.
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:[email protected]
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
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
