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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
