Pushing this up again .... Anybody with a guess? Thanks, Beat
On Mon, 1 Sep 2014 06:58:19 -0500, Beat Gossweiler <[email protected]> wrote: >Hi Peter, > >EATTR settings are the same (blank) for both DataClasses. When allocating with >either DataClass, IEHLIST shows EATTR=NS and ISPF shows no 'Extended >Attributes' line in the Data Set Information panel. > >When allocating with explicit EATTR=NO on the DD-Statement (using the same >DataClasses), IEHLIST shows EATTR=NO and the ISPF Data Set Information panel >shows 'Extended Attributes NO', but the behaviour is still the same for each >DataClass (one is OK, one is not OK). > >I've attached the LISTVTOC output for 4 cases as follows: >T601386.ISIS71.SYSPRIN1: Allocated with DataClass SNN (1 Record) >T601386.ISIS71.SYSPRIN2: Allocated with DataClass SNNSV (all Records) >T601386.ISIS71.SYSPRIN3: Allocated with DataClass SNN, EATTR=NO in JCL (1 >Record) >T601386.ISIS71.SYSPRIN4: Allocated with DataClass=SNNSV, EATTR=NO in JCL (all >Records) > >The only difference I can see between the OK and the not-OK datasets is the >last block pointer, which shows track 4 for the OK cases and track 0 for the >not-OK cases. > >Any other ideas? > >Thanks, Beat > > > >On Sat, 30 Aug 2014 11:03:58 +0200, Peter Hunkeler <[email protected]> wrote: > >>Hi Beat, >>I've had numerous problems with weird behavior of the software when >>datasets were allocated on EAV volumes with the data set extended >>attribute (EATTR) set to "Opt" and the software was not prepared for >>this. EATTR=OPT allows the data set to reside in the extended >>addressability are ov EAV volumes. Needs new DSCB formats, has >>different record addressing (more bits for the cylinder), and >>probably more. >> >>Fact is that IBM as well as vendor software is not always well >>prepared to deal with this. Depending on how "deep" the software >>dives into the I/O business, it may or may not work. If it doesn't, >>the resulting false behaviour does not point you directly to >>EATTR=OPT. >> >>EATTR is another parameter set by the DataClass. Data sets with >>EATTR=OPT do show this in ISPF's data set information panel. >> >>Can you verify the EATTR settings in both DataClasses you mentioned? >> >> >>-- >>Peter Hunkeler >> >> >>Beat Gossweiler wrote on August 23: >> >> > I'm investigating a mysterious problem with a vendor product (batch >> > program called from JCL) writing to SYSPRINT, which shows the >> > following symptoms: >> > >> > 1) When allocating SYSPRINT to SYSOUT, I can see all expected records >> > (messages) in the spool file (-> OK) >> > >> > 2) When allocating to an SMS managed PS dataset (DISP=(NEW,CATLG)) >> > with our default DataClass, the dataset only contains the last record >> > of what was written to spool in case 1 (-> Not OK) >> > >> > 3) When allocating to a temporary dataset (which is not SMS managed), >> > the temporary dataset contains all the records which were written to >> > spool in case 1 (-> OK) >> > >> > 4) When allocating to a SMS managed PS dataset (DISP=(NEW,CATLG)) >> > with a different DataClass, the cataloged dataset contains all the >> > records which were written to spool in case 1 (-> OK) >> > >> > - the vendor is not able to reproduce my symptoms on his z/OS system >> > - the vendor product runs in an LE environment >> > - I don't know what access method is used for SYSPRINT by the product >> > - I suspect the product uses more than one DCB from different threads >> > to write concurrently to SYSPRINT (i.e. the last message comes from a >> > separate unit of work). This might be wrong, but why would it work >> > (consistently) with certain types of DASD datasets? >> > >> > - the major difference I can see between the two DataClasses in use >> > is that the working DataClass does not specify space constraint >> > relief, but I have to further investigate for differences. >> > >> > >> > Can anybody provide me with a clue on where to look further for the >> > root cause of this problem? Getting more detailed information about >> > the techniques used in the product from the vendor is not an option >> > at this point of time. >> > >> > Thanks for any hints >> > Beat >> >>---------------------------------------------------------------------- >>For IBM-MAIN subscribe / signoff / archive access instructions, >>send email to [email protected] with the message: INFO IBM-MAIN > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > SYSTEMS SUPPORT UTILITIES---IEHLIST > PAGE 1 >DATE: 2014.244 TIME: 13.39.44 > CONTENTS OF VTOC ON VOL DWA011 <THIS IS AN SMS MANAGED VOLUME> >---------------DATA SET NAME---------------- SER NO SEQNO DATE.CRE >DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE >T601386.ISIS71.SYSPRIN1 DWA011 1 2014.244 >00.000 2014.244 1 PS VB 00 22978 >SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOC EXTEND LAST >BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) >S 22974 TRKS 15 4 2 >31076 1 3 2 >EATTR >NS > EXTENTS NO LOW(C-H) HIGH(C-H) > 0 1636 0 1636 4 > ----ON THE ABOVE DATA SET,THERE ARE 0 > EMPTY TRACK(S). > > SYSTEMS SUPPORT UTILITIES---IEHLIST > PAGE 1 >DATE: 2014.244 TIME: 13.40.10 > CONTENTS OF VTOC ON VOL DWA005 <THIS IS AN SMS MANAGED VOLUME> >---------------DATA SET NAME---------------- SER NO SEQNO DATE.CRE >DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE >T601386.ISIS71.SYSPRIN2 DWA005 1 2014.244 >00.000 2014.244 1 PS VB 00 22978 >SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOC EXTEND LAST >BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) >S 22974 TRKS 15 0 1 >58004 0 7 7 >EATTR >NS > EXTENTS NO LOW(C-H) HIGH(C-H) > 0 561 0 561 0 > ----ON THE ABOVE DATA SET,THERE ARE 0 > EMPTY TRACK(S). > > SYSTEMS SUPPORT UTILITIES---IEHLIST > PAGE 1 >DATE: 2014.244 TIME: 13.40.24 > CONTENTS OF VTOC ON VOL DWA003 <THIS IS AN SMS MANAGED VOLUME> >---------------DATA SET NAME---------------- SER NO SEQNO DATE.CRE >DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE >T601386.ISIS71.SYSPRIN3 DWA003 1 2014.244 >00.000 2014.244 1 PS VB 00 22978 >SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOC EXTEND LAST >BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) >S A 22974 TRKS 15 4 2 >31076 0 3 45 >EATTR >NO > EXTENTS NO LOW(C-H) HIGH(C-H) > 0 866 0 866 4 > ----ON THE ABOVE DATA SET,THERE ARE 0 > EMPTY TRACK(S). > > SYSTEMS SUPPORT UTILITIES---IEHLIST > PAGE 1 >DATE: 2014.244 TIME: 13.40.33 > CONTENTS OF VTOC ON VOL DWA003 <THIS IS AN SMS MANAGED VOLUME> >---------------DATA SET NAME---------------- SER NO SEQNO DATE.CRE >DATE.EXP DATE.REF EXT DSORG RECFM OPTCD BLKSIZE >T601386.ISIS71.SYSPRIN4 DWA003 1 2014.244 >00.000 2014.244 1 PS VB 00 22978 >SMS.IND LRECL KEYLEN INITIAL ALLOC 2ND ALLOC EXTEND LAST >BLK(T-R-L) DIR.REM F2 OR F3(C-H-R) DSCB(C-H-R) >S A 22974 TRKS 15 0 1 >58004 0 13 33 >EATTR >NO > EXTENTS NO LOW(C-H) HIGH(C-H) > 0 1012 14 1012 14 > ----ON THE ABOVE DATA SET,THERE ARE 0 > EMPTY TRACK(S). > > > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
