John Chase wrote on 06/13/2006 11:51:07 AM: > When I deleted SYS1.GTFTRACE and changed the JCL to allocate a new one > (DISP=(,CATLG)), it worked fine. Didn't know that GTF doesn't support > preallocated dataset for output any more, because ISTR that it used to. > > Oh, the "old" GTFTRACE dataset was VB with BLKSIZE=8192 and LRECL=8188; > the "new" iteration is VB,LRECL=27994,BLKSIZE=27998.
The check that is failing for you is for DSORG, not RECFM. You probably preallocated the data set via an IEFBR14 step in JCL. The data set never gets opened in that situation, and it keeps the default DSORG of undefined. If you shift to using IEBGENER or an equivalent that opens the data set for output using sequential access methods and just turns around an closes it, you'll find it has acquired DSORG=PS as an attribute. GTF has been doing this check since the early 1990s. As of z/OS V1R6 it will also tolerate DSORG=VS at that point in its logic. Later on during GTF initialization there will be some checks that, if it is VSAM, it better be a linear data set with CISIZE of 32K. Linear data set support was added to exploit VSAM support for striping. We'd been seeing more and more GTF and CTRACE external traces sprayed across a bunch of conventional data sets that DFSMS thinks are unrelated, data sets that must be put back together using IPCS COPYTRC before the trace originally requested makes sense again. Striping one linear data set increases the capacity without introducing the awkward step in the middle. 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
