Hi Rob, What I meant to say is that when the programmer came to me he said that when he ran the same job with the same program, only changing the JCL to move this output dataset from SMS managed disk to tape or to non-SMS managed disk, the blocking factor changed. To wit:
Run 1 - result is blocked dataset at half track: //VSF DD DSN=TEST.DATASET.NAME, <<< DSN HLQ pointing to SMS disk // DISP=(NEW,CATLG,DELETE), //* UNIT=VTS, // UNIT=SYSDA, <<<< send to disk // SPACE=(CYL,(5,20),RLSE), // DCB=MDCB.TEST.DATASET.NAME Run 2 - result is dataset with 200 byte blocks: //VSF DD DSN=TEST.DATASET.NAME, <<< DSN HLQ pointing to VTS tape // DISP=(NEW,CATLG,DELETE), // UNIT=VTS, <<<< send to tape //* UNIT=SYSDA, //* SPACE=(CYL,(5,20),RLSE), // DCB=MDCB.TEST.DATASET.NAME Run 3 - result is dataset with 200 byte blocks: //VSF DD DSN=NONSMS.DATASET.NAME, <<< DSN HLQ pointing to non-SMS disk // DISP=(NEW,CATLG,DELETE), //* UNIT=VTS, // UNIT=SYSDA, <<<< send to disk // SPACE=(CYL,(5,20),RLSE), // DCB=MDCB.TEST.DATASET.NAME The only difference in the 3 runs was where he was sending the output of this DD card. The result of sending //VSF to SMS disk was that it was half track blocked, sending the //VSF to either tape or to non-SMS disk resulted in the dataset being not blocked. Also, per an offline response, I checked my DEVSUPxx members and I don't have COPYSDB or TAPEBLKSIZELIM defined. Rex -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Rob Schramm Sent: Tuesday, June 14, 2022 10:44 PM To: [email protected] Subject: [EXTERNAL] Re: SMS confusion on when system determined blocksize is used Pretty sure the Using Data Sets should describe what is happening. I do not understand is the Non-sms data set that you say is unblocked. What does that even mean? If it is on disk and QSAM .. it is blocked. SDB should work regardless of SMS or non-sms as long as blksize=0 and the other caveats in the SDB section are met. Also.. you say that the Tape data set is unblocked.. I question that as well. But I don't see that you included the data set information for the non-sms and the tape data sets. Rob. On Tue, Jun 14, 2022 at 6:07 PM Pommier, Rex <[email protected]> wrote: > Hi list, > > I had a strange one thrown to me from a developer and I'm hoping > somebody can point me to something to explain why this is happening. > Environment is z/OS 2.4 and Cobol 6.3,pretty vanilla. I've read > through SDB explanations in several manuals but haven't found the > explanation as to why this is happening. > > We have a Cobol program with record length 200, and the developer > inadvertently omitted the BLOCK CONTAINS 0 RECORDS clause which > according to the Cobol manual says the file is supposed to be > unblocked. Developer runs the program in batch using a DD card like > this for the unblocked dataset. > > //VSF DD DSN=TEST.DATASET.NAME, > // DISP=(NEW,CATLG,DELETE), > //* UNIT=VTS, > // UNIT=SYSDA, > // SPACE=(CYL,(5,20),RLSE), > // DCB=MDCB.TEST.DATASET.NAME > > The only DCB information provided is in the MDCB statement which looks > like this: > > % XT Device Dsorg Recfm Lrecl Blksz > ---------------------------------------------- > MDCB.TEST.DATASET.NAME > 0 ? 0 3390 FB 200 0 > > Sorry for the lack of formatting, BLKSIZE=0, LRECL=200, RECFM=FB. > > If he runs his job with the DD card as above, going to an SMS managed > dataset, he gets half track blocking. If he runs it changing it to > UNIT=VTS, he gets an unblocked dataset, and if he runs it against DASD > with an unmanaged dataset name, he also gets it unblocked. Definitely > makes it look like something in the SMS configuration, however, our > SMS dataclas that this dataset falls under does not specify to use SDB > that I could find. So my questions are how to explain what's > happening here? Why does the MDCB specification of SDB seem to > override the Cobol program in the case of the SMS managed dataset but > the Cobol program overrides the MDCB for the non-SMS datasets? > > TIA, > > Rex > > ---------------------------------------------------------------------- > The information contained in this message is confidential, protected > from disclosure and may be legally privileged. If the reader of this > message is not the intended recipient or an employee or agent > responsible for delivering this message to the intended recipient, you > are hereby notified that any disclosure, distribution, copying, or any > action taken or action omitted in reliance on it, is strictly > prohibited and may be unlawful. If you have received this > communication in error, please notify us immediately by replying to > this message and destroy the material in its entirety, whether in electronic > or hard copy format. Thank you. > > > ---------------------------------------------------------------------- > 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 ---------------------------------------------------------------------- The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
