Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
Yet, SDB appears to have filled in BLKSIZE for a data set that was never opened. SDB determines the blocksize twice. At allocation time, even if the dataset was never opened, it calculates the blocksize from the supplied RECFM and LRECL. Then it sets a flag saying that it did so. At OPEN time, if that flag is set, and if the RECFM or LRECL in the DCB is different from the values provided at allocation time, it recalculates the blocksize. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
Paul Gilmartin wrote: It's more complicated than that. I wrote a little assembler program. I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate an old DCB, I did: XCDCBDSORG,DCBDSORG In the JCL: //SYSUT2 DD SYSOUT=(,),RECFM=VB,LRECL=125 I then did: OPEN (SYSUT2,OUTPUT) PUT SYSUT2,TEXT CLOSE SYSUT2 ... with no error, and successful write to SYSOUT. Where did BLKSIZE come from? Again, are the rules clearly stated somewhere? I don't think SYSOUT is the best (or even a good) way to test these rules. JES2/JES3 SSI allocation and OPEN routines may have been (but probably never were) 100% compatible with DFP (or whatever its predecessor was called) way back when they were written, but DFP has evolved a lot since then. JES hasn't. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
I remember, in the seventies, that a person told me that DCBD block was built taking and overlaping information, in this order, from 1) VTOC 2) JCL 3) DCB macro in PROGRAM So I think we need to know the source of a program (IEBGENER or others) to have all the information (is BLKSIZE parameter coded in program macro DCB?) I did more test about and SDB appears to be in effect, for SMS and NO-SMS files, when the program does the OPEN macro and this OPEN is for OUTPUT, provided the values in VTOC/JCL are BLKSIZE=0 and on information is provided by DCB macro. Below is the program to test this. angel luis domínguez bbva - spain ---oooOooo--- BLKTEST INICIO 12,COMEN='OBTIENE EL BLKSIZE DE FICHERO TIPO=NORENT * LAR3,INFILE USING IHADCB,R3 SLR R7,R7 LHR7,DCBBLKSI CVD R7,WORKD UNPK WORKA(5),WORKD+5(3) OIWORKA+4,X'F0' MVC LBWTO1+8+25(5),WORKA LBWTO1 WTO '+EL BLKSIZE DE INFILE ES X. ' * OPEN (INFILE,(OUTPUT)) LAR3,INFILE USING IHADCB,R3 SLR R7,R7 LHR7,DCBBLKSI CVD R7,WORKD UNPK WORKA(5),WORKD+5(3) OIWORKA+4,X'F0' MVC LBWTO2+8+25(5),WORKA LBWTO2 WTO '+EL BLKSIZE DE INFILE ES X. ' * CLOSE (INFILE) FIN CR,TIPO=NORENT * *RESERVA DE AREAS * WORKADSCL5 WORKDDSD INFILE DCB DDNAME=INFILE,DSORG=PS,MACRF=PM * DCBD DSORG=PS END -Mensaje original- De: Edward E. Jaffe [mailto:[EMAIL PROTECTED] Paul Gilmartin wrote: It's more complicated than that. I wrote a little assembler program. I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate an old DCB, I did: XCDCBDSORG,DCBDSORG In the JCL: //SYSUT2 DD SYSOUT=(,),RECFM=VB,LRECL=125 I then did: OPEN (SYSUT2,OUTPUT) PUT SYSUT2,TEXT CLOSE SYSUT2 ... with no error, and successful write to SYSOUT. Where did BLKSIZE come from? Again, are the rules clearly stated somewhere? I don't think SYSOUT is the best (or even a good) way to test these rules. JES2/JES3 SSI allocation and OPEN routines may have been (but probably never were) 100% compatible with DFP (or whatever its predecessor was called) way back when they were written, but DFP has evolved a lot since then. JES hasn't. -- - | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | - -- 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 _ Mensaje analizado y protegido, tecnologia antivirus www.trendmicro.es ... DISCLAIMER . This message and its attachments are intended exclusively for the named addressee. If you receive this message in error, please immediately delete it from your system and notify the sender. You may not use this message or any part of it for any purpose. The message may contain information that is confidential or protected by law, and any opinions expressed are those of the individualsender. Internet e-mail guarantees neither the confidentiality nor the proper receipt of the message sent. If the addressee of this message does not consent to the use of internete-mail,pleaseinform usinmmediately. . AVISO LEGAL La presente comunicación y sus anexos tiene como destinatario la persona a la que va dirigida, por lo que si usted lo recibe por error debe notificarlo al remitente y eliminarlo de su sistema, no pudiendo utilizarlo, total o parcialmente, para ningún fin. Su contenido puede tener información confidencial o protegida legalmente y únicamente expresa la opinión del remitente. El uso del correo electrónico vía internet no permite
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Kevin Clark why is the date 6/1/2005 Because there is no 5/32/2005? -jc- -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
why is the date 6/1/2005 Because there is no 5/32/2005? But January was so long ago - does anyone still care -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
In a recent note, Edward E. Jaffe said: Date: Tue, 31 May 2005 23:37:51 -0700 Paul Gilmartin wrote: It's more complicated than that. I wrote a little assembler program. I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate an old DCB, I did: XCDCBDSORG,DCBDSORG In the JCL: //SYSUT2 DD SYSOUT=(,),RECFM=VB,LRECL=125 I then did: OPEN (SYSUT2,OUTPUT) PUT SYSUT2,TEXT CLOSE SYSUT2 ... with no error, and successful write to SYSOUT. Where did BLKSIZE come from? Again, are the rules clearly stated somewhere? I don't think SYSOUT is the best (or even a good) way to test these rules. JES2/JES3 SSI allocation and OPEN routines may have been (but probably never were) 100% compatible with DFP (or whatever its predecessor was called) way back when they were written, but DFP has evolved a lot since then. JES hasn't. A rule is tested by anything that appears to supply a counterexample. If JES is an exception to the rule, then that exception should be stated in Using Data Sets where the rule is documented. It's all too complicated, too poorly documented, and what documentation there is is scattered in too many places. This may be partly the outcome of design by APAR. Various utilities originally supplied default BLKSIZEs that thwarted operation of SDB. These were repaired by APAR, e.g. OW43702. This broke existing customer code, and additional compensating APARs were created, in this case OW46399. There may have been various others. In combination, such APARs extended the rules, but it appears that such changes were not reflected back to the manuals. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In a recent note, Greg Price said: Date: Wed, 1 Jun 2005 14:16:51 +1000 Well, here's my theory: Does this have to be done by theory and/or experiment, or is it made clear in the documentation? I believe theory/experiment/doco all agree on how the system behaves here. The theory reference is due to me not having access to the current source of IEBGENER. I'd say your outline of the SYSUT2 DCB Open exit (which need bear no similarity to the exit for SYSPRINT) sounds pretty right. I was going to suggest that experiments with SYSOUT are not relevant to illustrate DCB processing, but Ed J said it first. Hence my passing remark about a real line printer. Allocating a real unit record device takes the dummied up DCB facade of JES ACB processing out of the picture. IOW, I was trying to think of a device where QSAM/BSAM could be used that was not TAPE or DASD to illustrate a currently available non-SDB example. Programs that will abend with S013-34 when the output file is on TAPE or DASD will often not abend when the output is directed to SYSOUT because of its forgiving nature. I haven't done much JES3, but JES2 does not seem to care about DCBBLKSI remaining zero at all (it still remains zero after OPEN whereas SDB will put a non-zero value in it). I have not checked the doco re your point about the exit getting control before or after the SDB is filled in. Experiment indicates that the exit ends before the OPEN-time SDB is supplied. Therefore, a run-of-the-mill IEBGENER step can produce different output blocksizes depending on something as simple as whether DSORG=PS is specified in the JCL or not. It's been a while, but IIRC I used to have ACS routines which set DSORG=PS for DASD data sets whenever a null DSORG was found at creation time. For data sets that were never opened this used to allow recognition that they were empty as well as HSM migration. But yes, if the DCB blocking has been determined by the user or by allocation-time SDB, IEBGENER's DCB Open exit has nothing to do about setting the output blocksize. My surmise about allocation-time SDB is really just me parroting back the publicity around at the time SDB was introduced. Since behaviour matched what I was told I've never checked the manuals on it. I expect DFSMS: Using Data Sets to talk about the OPEN-time SDB, and DFSMS: Implementing System Managed Storage (SC26-7407-02) to talk about the DADSM end of things including allocation-time SDB. I suppose it might be nice if each had a pointer to the other if they don't already. Cheers, Greg -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
From: Paul Gilmartin ...APARs extended the rules, but it appears that such changes were not reflected back to the manuals. This is a general beef now. TNLs are consigned to history. Nowadays, changes (e.g. DOC) introduced by APAR/PTF are only reflected *forward* (from current/next) into the manuals. Pisses me off severely that I have to seek out current level (say 1.6) manuals on the net to analyse messages I see on z/OS 1.4. Shane ... -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
In a recent note, Greg Price said: Date: Wed, 1 Jun 2005 22:40:25 +1000 Well, here's my theory: Does this have to be done by theory and/or experiment, or is it made clear in the documentation? I believe theory/experiment/doco all agree on how the system behaves here. The theory reference is due to me not having access to the current source of IEBGENER. If the documentation were adequate, there would be no need for access to the source code. I was going to suggest that experiments with SYSOUT are not relevant to illustrate DCB processing, but Ed J said it first. Hence my If JES performs DCB processing, it's relevant. The relevant information should be supplied at least in a JES-specific manual, and Using Data Sets should contain at least a cross reference to it. I have not checked the doco re your point about the exit getting control before or after the SDB is filled in. Experiment indicates that the exit ends before the OPEN-time SDB is supplied. I have found no statement that clarifies this. Again, with proper documentation experiment would be unnecessary. I expect DFSMS: Using Data Sets to talk about the OPEN-time SDB, and DFSMS: Implementing System Managed Storage (SC26-7407-02) to talk about the DADSM end of things including allocation-time SDB. I suppose it might be nice if each had a pointer to the other if they don't already. The data sets in my tests all appear to be non-SMS (At least ISPF 3.4.I shows no Management class, Storage class, nor Data class information.) Yet, SDB appears to have filled in BLKSIZE for a data set that was never opened. I had hoped that non-SMS would simplify things by leaving one more component out of the process. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
In a recent note, ibm-main said: Date: Wed, 1 Jun 2005 22:43:05 +1000 ...APARs extended the rules, but it appears that such changes were not reflected back to the manuals. This is a general beef now. TNLs are consigned to history. Nowadays, changes (e.g. DOC) introduced by APAR/PTF are only reflected *forward* (from current/next) into the manuals. Pisses me off severely that I have to seek out current level (say 1.6) manuals on the net to analyse messages I see on z/OS 1.4. The word back was my bad choice. I don't believe they got reflected in any direction. From my PMR on the problem I experienced: =* -5695DF102 - 01/04/25-19:56- *** ... I suppose we could also change the documentation, but I'm not ready for that yet. I'd like to first see if there's any additional fallout from OW46399. OS/390 2.9. April 2001. Does the doc yet reflect the changes? -- gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
Paul Gilmartin wrote: In a recent note, Greg Price said: I expect DFSMS: Using Data Sets to talk about the OPEN-time SDB, and DFSMS: Implementing System Managed Storage (SC26-7407-02) to talk about the DADSM end of things including allocation-time SDB. I suppose it might be nice if each had a pointer to the other if they don't already. The data sets in my tests all appear to be non-SMS (At least ISPF 3.4.I shows no Management class, Storage class, nor Data class information.) Yet, SDB appears to have filled in BLKSIZE for a data set that was never opened. I had hoped that non-SMS would simplify things by leaving one more component out of the process. IIRC, SDB's only intersect with SMS is a requirement that the SMS address space be active. -- .-. | Edward E. Jaffe|| | Mgr, Research Development| [EMAIL PROTECTED]| | Phoenix Software International | Tel: (310) 338-0400 x318 | | 5200 W Century Blvd, Suite 800 | Fax: (310) 338-0801| | Los Angeles, CA 90045 | http://www.phoenixsoftware.com | '-' -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
... Yet, SDB appears to have filled in BLKSIZE for a data set that was never opened. ... If you allocated it under ISPF, it was opened. ISPF ALLOC opens and closes all datasets. Also, you don't need SMS to implement SDB. We had SDB about a year before we wrote any ACS. [EMAIL PROTECTED] -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In reaction to the recent DUMMY and ISPLOG BLKSIZE=0 thread, I did a test with the following: //GENEREXEC PGM=IEBGENER //SYSPRINT DD DISP=(NEW,CATLG), // DSN=SYSUID..IEBGENER.SYSPRINT, // DCB=(RECFM=FBA,LRECL=121,BLKSIZE=0), // UNIT=SYSDA,SPACE=(TRK,1) (Note this is SYSPRINT, not SYSUT2.) The characteristics of the created data set are: Data Set Name . . . : user.IEBGENER.SYSPRINT General Data Current Allocation Volume serial . . . : TSO002 Allocated tracks . : 1 Device type . . . . : 3390Allocated extents . : 1 Organization . . . : PS Record format . . . : FBA Record length . . . : 121 Block size . . . . : 121Current Utilization 1st extent tracks . : 1 Used tracks . . . . : 1 Secondary tracks . : 0 Used extents . . . : 1 This BLKSIZE does not appear to be the SDB supplied value (a similar test with IDCAMS REPRO gives 27951). It has been my perception that it is IBM's policy to allow SDB to operate on utility output rather than forcing a BLKSIZE in the utility's code. Should this be reported to IBM? (And how is Utilities Development likely to react in view of the recent waffle on the IEBGENER PARM='SDB=YES' default waffle?) -- gil Try again with DSORG=PS added to the DCB attributes. I don't have a book detailing SDB requirements nearby, but I seem to recall that the DSORG must be PS and known to data management in time to apply SDB. -- Bob Wright - MVS Service Aids -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
In a recent note, Bob Wright said: Date: Tue, 31 May 2005 11:45:55 -0400 Try again with DSORG=PS added to the DCB attributes. I don't have a book detailing SDB requirements nearby, but I seem to recall that the DSORG must be PS and known to data management in time to apply SDB. Bingo! That makes the difference. I'm somewhat surprised; I would have believed that the call to OPEN supplies all information necessary to determine DSORG, and SDB takes effect fairly late in the OPEN process (after the DCB EXIT), when DSORG should have been fixed. And puzzled further that REPRO causes SDB to be applied. I suppose the difference might be that REPRO places DSORG in the DCB before OPEN whereas IEBGENER doesn't. (Would PO work as well as PS?) Thanks, gil -- StorageTek INFORMATION made POWERFUL -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In a recent note, Bob Wright said: Date: Tue, 31 May 2005 11:45:55 -0400 Try again with DSORG=PS added to the DCB attributes. I don't have a book detailing SDB requirements nearby, but I seem to recall that the DSORG must be PS and known to data management in time to apply SDB. Bingo! That makes the difference. I'm somewhat surprised; I would have believed that the call to OPEN supplies all information necessary to determine DSORG, and SDB takes effect fairly late in the OPEN process (after the DCB EXIT), when DSORG should have been fixed. And puzzled further that REPRO causes SDB to be applied. I suppose the difference might be that REPRO places DSORG in the DCB before OPEN whereas IEBGENER doesn't. (Would PO work as well as PS?) Thanks, gil You're welcome. I thought that we'd bumped into something like that in the course of some service aids development where we had an old DCB that didn't specify DSORG, leaving that for a DCB OPEN exit to supply. I have no idea why IEBGENER would be going that route, but it certainly needs to be available to OPEN before a DCB OPEN exit to implement SDB. -- Bob Wright - MVS Service Aids -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
... I seem to recall that the DSORG must be PS and known to data management in time to apply SDB ... The DSORG can also be PO. I've used it for years, that way. [EMAIL PROTECTED] -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
why is the date 6/1/2005 -- Original message -- ... I seem to recall that the DSORG must be PS and known to data management in time to apply SDB ... The DSORG can also be PO. I've used it for years, that way. [EMAIL PROTECTED] -- 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 -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
Bob Wright wrote: You're welcome. I thought that we'd bumped into something like that in the course of some service aids development where we had an old DCB that didn't specify DSORG, leaving that for a DCB OPEN exit to supply. I have no idea why IEBGENER would be going that route, but it certainly needs to be available to OPEN before a DCB OPEN exit to implement SDB. Well, here's my theory: Once a DD for a NEW disk data set has the following DCB attributes 1) RECFM specifying fixed-length or variable-length records, 2) LRECL more than zero 3) DSORG of PS or PO 4) BLKSIZE of zero THEN a System-Determined Blocksize (SDB) is placed into the data set labels during data set creation, way before OPEN happens. In fact, OPEN won't happen if PGM=IEFBR14, for example. SDB will not occur unless the DSORG is known to be PS or PO. During OPEN the DSORG _must_ be known, so SDB gets another chance to run if BLKSIZE=0 is still true (for PS and PO). Re IEBGENER, it seems that IEBGENER will use any valid blocksize in the data set labels before OPEN, including an SDB set during data set allocation, for the SYSPRINT file. I'd guess that IEBGENER has a DCB OPEN exit on SYSPRINT which, when it gets control, checks the BLKSIZE value in the DCB. If it is zero then BLKSIZE is set to LRECL (ie. 121). Logic such as this is very useful for preventing OPEN abends where no DCB attributes are coded in the JCL for new data sets while still allowing the BLKSIZE to be overridden by the data set labels or JCL, especially on systems with SDB. It may even mean that IEBGENER's SYSPRINT could be allocated to a *real* line printer without coding any DCB parameters in the JCL, and it would still work. (Haven't tried this one. g) (S013-34 is the usual abend for when BLKSIZE=0 persists, IIRC.) But it does mean that SDB at OPEN-time will never occur in this case. (I suppose the exit could be changed to check for a TAPE or DASD file, and leave BLKSIZE=0 if it is, but the business case for this may not be strong. IEBGENER, being part of DFP, knows that SDB is present. A 3rd party utility, designed for any MVS ever, would have to check that SDB is present. Hang on, that's another thread. Don't mention the PLO instruction. I mentioned it once, but think I got away with it.) In summary, SDB gets two opportunities to run: 1) during allocation, 2) during OPEN, but only for TAPE or DASD when DSORG is PS or PO. Cheers, Greg P. -- 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
Re: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
In a recent note, Greg Price said: Date: Wed, 1 Jun 2005 14:16:51 +1000 Well, here's my theory: Does this have to be done by theory and/or experiment, or is it made clear in the documentation? Once a DD for a NEW disk data set has the following DCB attributes 1) RECFM specifying fixed-length or variable-length records, 2) LRECL more than zero 3) DSORG of PS or PO 4) BLKSIZE of zero THEN a System-Determined Blocksize (SDB) is placed into the data set labels during data set creation, way before OPEN happens. In fact, OPEN won't happen if PGM=IEFBR14, for example. My experiments confirm this, as far as I've probed. This introduces an unfortunate incompatibility -- the DCB OPEN exit is thereby mostly disabled for setting BLKSIZE. In particular, how does IEBGENER allow BLKSIZE to be specified in the SYSUT2 DD statement, but copied from SYSUT1 if omitted from DD? I had imagined that it was simply done in the DCB EXIT -- IF BLKSIZE==0 THEN Copy from SYSUT1. In summary, SDB gets two opportunities to run: 1) during allocation, 2) during OPEN, but only for TAPE or DASD when DSORG is PS or PO. It's more complicated than that. I wrote a little assembler program. I did not supply RECFM, LRECL, or BLKSIZE in the DCB macro. To simulate an old DCB, I did: XCDCBDSORG,DCBDSORG In the JCL: //SYSUT2 DD SYSOUT=(,),RECFM=VB,LRECL=125 I then did: OPEN (SYSUT2,OUTPUT) PUT SYSUT2,TEXT CLOSE SYSUT2 ... with no error, and successful write to SYSOUT. Where did BLKSIZE come from? Again, are the rules clearly stated somewhere? In: Title: z/OS V1R5.0 DFSMS: Using Data Sets Document Number: SC26-7410-03 I see: # 3.2.3.1.2 z/OS V1R5.0 DFSMS: Using Data Sets 3.2.3.1.2 System-Determined Block Size If you do not specify a block size for the creation of a data set, the system attempts to determine the block size. ... The system determines the block size for a data set as follows: 1. OPEN calculates a block size. [ ... ] (Much abridged, but) There is no suggestion that SDB operates before OPEN, but a crude experiment seems to show this is so, as you surmised. It fails to make clear whether SDB operates before or after the DCB exit. It fails to describe the operation of SDB for SYSOUT data sets, but an experiment seems to show it's effective for SYSOUT. Etc. -- gil -- StorageTek INFORMATION made POWERFUL -- 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
