Re: GTF Woes
The message explanation is correct (actually it leaves out an additional valid possibility which is a VSAM DSORG; I will get that updated). While being correct, it is highly missleading. The first two sentences of the Explanation as well as the System Programmer Response talk about a missing DD statement, not about attributes. So does the message text. Why not say the data set has incorrect attributes, right in the message text? Peter Hunkeler CREDIT SUISSE -- 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: GTF Woes
In a message dated 6/13/2006 4:23:58 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: There is no limit on the number of device numbers as of z/OS 1.3. That is good news, but I think the official doc is down-level. I found the limit of 256 to which I referred in z/OS V1R6.0 MVS Diagnosis: Tools and Service Aids. IO=SSCH=(DEVCLASS=,DEVCLASS=,devnum1[,devnumm [,devnum256]) All the references to maximum number of devices that I could find in the book either state explicitly or imply 256. I tried 272 device numbers on a z/OS 01.05.00 HBB7708 system, and it worked. Bill Fairchild -- 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: GTF Woes
Peter Hunkeler wrote on 06/14/2006 08:09:32 AM: While being correct, it is highly missleading. The first two sentences of the Explanation as well as the System Programmer Response talk about a missing DD statement, not about attributes. So does the message text. Why not say the data set has incorrect attributes, right in the message text? It looks like AHL084I and a few friends went into GTF in the early 1990s. There is no message that talks about the failure of the tests in question for a specific ddname. AHL084I is produced because, after filtering out ddnames that could not be used on the basis of the tests described, no candidates remain. It is possible that AHL084I was the consequence of forgetting an output ddname entirely. Your suggestion, interpreted in this context, is to add a new message that points at ddname IEFRDER or GTFOUTaa and says something specific about them. We'll add that to a (long) list of things that might improve service aids, reduce confusion using them, and reduce the number of PMRs that result. 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: GTF Woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Wright Peter Hunkeler wrote on 06/14/2006 08:09:32 AM: While being correct, it is highly missleading. The first two sentences of the Explanation as well as the System Programmer Response talk about a missing DD statement, not about attributes. So does the message text. Why not say the data set has incorrect attributes, right in the message text? It looks like AHL084I and a few friends went into GTF in the early 1990s. There is no message that talks about the failure of the tests in question for a specific ddname. AHL084I is produced because, after filtering out ddnames that could not be used on the basis of the tests described, no candidates remain. It is possible that AHL084I was the consequence of forgetting an output ddname entirely. Your suggestion, interpreted in this context, is to add a new message that points at ddname IEFRDER or GTFOUTaa and says something specific about them. We'll add that to a (long) list of things that might improve service aids, reduce confusion using them, and reduce the number of PMRs that result. Yes, please. Issuing a message that says, in effect, that no DDNAME was found when at least one of the DDNAMEs documented as required is present, is false and misleading. -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: GTF Woes
Thanks. At least it is on a list :-) Peter Hunkeler CREDIT SUISSE -- 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: GTF Woes
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/14/2006 08:29:11 AM: In a message dated 6/13/2006 4:23:58 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: There is no limit on the number of device numbers as of z/OS 1.3. That is good news, but I think the official doc is down-level. I found the limit of 256 to which I referred in z/OS V1R6.0 MVS Diagnosis: Tools and Service Aids. IO=SSCH=(DEVCLASS=,DEVCLASS=,devnum1[,devnumm [,devnum256]) All the references to maximum number of devices that I could find in the book either state explicitly or imply 256. I tried 272 device numbers on a z/OS 01.05.00 HBB7708 system, and it worked. The oversight of not updating the book was corrected in the z/OS 1.7 version of the book. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: GTF Woes
In a message dated 6/14/2006 3:01:59 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: The oversight of not updating the book was corrected in the z/OS 1.7 version of the book. Now that I have the 1.7 version of the book, I can see that 256 has been replaced with unlimited. Thanks for the explanations. Bill Fairchild -- 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
GTF Woes
Hi, All, Given the following proc (z/OS 1.5): //GTF PROC MEMBER=GTFVTAM //* //IEFPROC EXEC PGM=AHLGTF,PARM='MODE=EXT,DEBUG=NO,TIME=YES', // REGION=8M,TIME=1440 //IEFRDER DD DSNAME=SYS1.GTFTRACE,DISP=OLD //SYSLIB DD DSNAME=SYS1.PARMLIB(MEMBER),DISP=SHR ... with PARMLIB member GTFVTAM containing: TRACE=USR,RNIO /* Why do I get these messages: AHL084I NO DD STATEMENT WAS FOUND FOR A GTF OUTPUT DATA SET. AHL016I GTF INITIALIZATION UNSUCCESSFUL ??? TIA, -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: GTF Woes
You might want to increase the buffers something like ,PARM='BLOK=3M,DEBUG=NO,TIME=YES' Why not do that then try again and see if the PROC is coming from the PROCLIB you expect. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 A)bort, R)etry, I)nfluence with large hammer. This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: GTF Woes
Is SYS1.GTFTRACE DSORG=PS? You might try allocating a new dataset. //IEFRDER DD DSNAME=SYS1.TRACE,UNIT=SYSDA,SPACE=(TRK,20), // DISP=(NEW,CATLG,DELETE) Chase, John [EMAIL PROTECTED] To Sent by: IBM IBM-MAIN@BAMA.UA.EDU Mainframe cc Discussion List [EMAIL PROTECTED] Subject .EDU GTF Woes 06/13/2006 09:40 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .EDU Hi, All, Given the following proc (z/OS 1.5): //GTF PROC MEMBER=GTFVTAM //* //IEFPROC EXEC PGM=AHLGTF,PARM='MODE=EXT,DEBUG=NO,TIME=YES', // REGION=8M,TIME=1440 //IEFRDER DD DSNAME=SYS1.GTFTRACE,DISP=OLD //SYSLIB DD DSNAME=SYS1.PARMLIB(MEMBER),DISP=SHR ... with PARMLIB member GTFVTAM containing: TRACE=USR,RNIO /* Why do I get these messages: AHL084I NO DD STATEMENT WAS FOUND FOR A GTF OUTPUT DATA SET. AHL016I GTF INITIALIZATION UNSUCCESSFUL ??? TIA, -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: GTF Woes
John, According to the explanation of message AHL084I, your data set SYS1.GTFTRACE, referenced by DD-statement IEFRDER does not have either PS or PSU organization. It's actually very precise about that. I used http://www-03.ibm.com/servers/eserver/zseries/zos/bkserv/lookat/ as I always do when a post with a questioned message appears - and, well, I vaguely recognise what the topic is. Chris Mason - Original Message - From: Chase, John [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Tuesday, 13 June, 2006 4:40 PM Subject: GTF Woes Hi, All, Given the following proc (z/OS 1.5): //GTF PROC MEMBER=GTFVTAM //* //IEFPROC EXEC PGM=AHLGTF,PARM='MODE=EXT,DEBUG=NO,TIME=YES', // REGION=8M,TIME=1440 //IEFRDER DD DSNAME=SYS1.GTFTRACE,DISP=OLD //SYSLIB DD DSNAME=SYS1.PARMLIB(MEMBER),DISP=SHR ... with PARMLIB member GTFVTAM containing: TRACE=USR,RNIO /* Why do I get these messages: AHL084I NO DD STATEMENT WAS FOUND FOR A GTF OUTPUT DATA SET. AHL016I GTF INITIALIZATION UNSUCCESSFUL ??? TIA, -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: GTF Woes
It looks good to me. Perhaps there is something wrong with your SYS1.GTFTRACE. Do you get the same results allocating a new data set? Regards, Kevin -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: Tuesday, June 13, 2006 7:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: GTF Woes Hi, All, Given the following proc (z/OS 1.5): //GTF PROC MEMBER=GTFVTAM //* //IEFPROC EXEC PGM=AHLGTF,PARM='MODE=EXT,DEBUG=NO,TIME=YES', // REGION=8M,TIME=1440 //IEFRDER DD DSNAME=SYS1.GTFTRACE,DISP=OLD //SYSLIB DD DSNAME=SYS1.PARMLIB(MEMBER),DISP=SHR ... with PARMLIB member GTFVTAM containing: TRACE=USR,RNIO /* Why do I get these messages: AHL084I NO DD STATEMENT WAS FOUND FOR A GTF OUTPUT DATA SET. AHL016I GTF INITIALIZATION UNSUCCESSFUL ??? TIA, -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 -- 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: GTF Woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Neubert, Kevin (DIS) It looks good to me. Perhaps there is something wrong with your SYS1.GTFTRACE. Do you get the same results allocating a new data set? 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. -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: GTF Woes
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
Re: GTF Woes
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Robert Wright 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. Ahhh For some reason I had the misconception that the defaults were DSORG=PS and RECFM=U. Now that the output dataset has been properly defined, the JCL also works when reusing the dataset via DISP=OLD. [ snip ] 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. ... Kewl! We should have z/OS 1.7 up by 4th qtr this year. -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: GTF Woes
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. I don't remember that it ever did not. I have always used preallocated data sets. Works fine. I test-allocated a new one with directory blocks = 0, no record format, no record length, no block size, and data set name type = blank. After I ran GTF against this file, the attributes have been changed to DSORG=PS, RECFM=VB, LRECL=27994, and BLKSIZE=27998. Many enhancements have been made to GTF since I first began to use it extensively ca. 1988; e.g., you can now have more than one instance of GTF at the same time in one MVS image. In 1988 the second one started would ABEND. A summary I/O trace has been added. If you trace with IOP or SSCHP, you can now specify up to 256 different device numbers, and in 1988 the limit was 50. You can also trace I/O now by device class, which was not possible in 1988. Kudos to the GTF developers and their enlightened management. Bill Fairchild Check out AOL.com today. Breaking news, video search, pictures, email and IM. All on demand. Always Free. -- 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: GTF Woes
Chase, John wrote: 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. It still does on my z/OS 1.7 system. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] 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: GTF Woes
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 06/13/2006 03:14:51 PM: Many enhancements have been made to GTF since I first began to use it extensively ca. 1988; e.g., you can now have more than one instance of GTF at the same time in one MVS image. In 1988 the second one started would ABEND. A summary I/O trace has been added. If you trace with IOP or SSCHP, you can now specify up to 256 different device numbers, and in 1988 the limit was 50. You can also trace I/O now by device class, which was not possible in 1988. Kudos to the GTF developers and their enlightened management. There is no limit on the number of device numbers as of z/OS 1.3. More than one instance of GTF in an MVS image was new in z/OS 1.6. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: GTF Woes
More than one instance of GTF in an MVS image was new in z/OS 1.6. I'm a little curious about this one. I was told (over 20 years ago) that, due to architectural constraints, only one instance of the monitor instruction could run. I had a few times (same era -- I haven't been involved with GTF in over 15 years) where I could have run two (or more) traces and solved problems in parallel rather than sequentially. . -teD Marching to the beat of a different flute -- 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: GTF Woes
Ted MacNEIL wrote: More than one instance of GTF in an MVS image was new in z/OS 1.6. I'm a little curious about this one. I was told (over 20 years ago) that, due to architectural constraints, only one instance of the monitor instruction could run. I had a few times (same era -- I haven't been involved with GTF in over 15 years) where I could have run two (or more) traces and solved problems in parallel rather than sequentially. As implemented right now in z/OS, PER is system wide and not changed when address space switching occurs (though that should be technically feasible). But, what's to stop multiple GTFs in z/OS 1.6 and higher from processing a single PER event? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] 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: GTF Woes
In a message dated 6/13/2006 5:19:09 P.M. Central Standard Time, [EMAIL PROTECTED] writes: But, what's to stop multiple GTFs in z/OS 1.6 and higher from processing a single PER event? The old bugaboo was that PER put you in serial or single step mode and timing problems went away only to reoccur when you turned it off by stopping GTF. Took really expert PSR days or weeks to nail them even with direct numbers to level 3. -- 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: GTF Woes
Edward Jaffe wrote on 06/13/2006 06:18:52 PM: As implemented right now in z/OS, PER is system wide and not changed when address space switching occurs (though that should be technically feasible). But, what's to stop multiple GTFs in z/OS 1.6 and higher from processing a single PER event? Nothing. Each instance of GTF is treated as an independent agent, capable of using software filtering to disregard events of no interest to it. It sees all events that are of interest to any active instance of GTF, so running multiple instances is certainly going to incur higher monitoring costs. The rationale for supporting this is that a large, complex system may have several nagging problems, and it should be possible to decide to collect data targetted to solving each of them - if you're willing to pay in the coin of the realm - performance degradation. 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: GTF Woes
Ted MacNeil wrote on 06/12/2006 08:00:00 PM: I'm a little curious about this one. I was told (over 20 years ago) that, due to architectural constraints, only one instance of the monitor instruction could run. I had a few times (same era -- I haven't been involved with GTF in over 15 years) where I could have run two (or more) traces and solved problems in parallel rather than sequentially. If you have occasion to use GTF now, you have the option available to attack the problems in parallel. As I responded to Ed Jaffe, each instance of GTF sees all events for which monitor call is enabled for any instance and must perform software filtering. The cost of quite unlike monitoring criteria is obviously higher than running each with focus, but it is a decision that should be left in the hands of the installation rather than a restriction imposed by the control program. 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: GTF Woes
should be left in the hands of the installation rather than a restriction imposed by the control program Hey! I'm not complaining! This is a good thing. Mind you, as I've said, I haven't been directly involved in GTF in over 15 years. Of course, if you could allow the output dsn to go intO extents and not wrap? . -teD Marching to the beat of a different flute -- 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: GTF Woes
Ted MacNeil wrote on 06/12/2006 08:00:00 PM: Mind you, as I've said, I haven't been directly involved in GTF in over 15 years. Of course, if you could allow the output dsn to go intO extents and not wrap? We've done better than that. VSAM linear data sets are now supported. That means you can stripe them and store well more than 4G in it if data rate and wrap time warrant. 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
