Re: GTF trace for a JCL error?
Our system had 7 days. On Tue, Jan 30, 2024 at 12:57 PM Paul Gilmartin < 042bfe9c879d-dmarc-requ...@listserv.ua.edu> wrote: > On Tue, 30 Jan 2024 14:41:59 +, Allan Staller wrote: > > > >You need to look at the JES output to determine the error. > >Use the following command > >S taskname,,,MSGCLASS=x where x is a held sysout class. > > > >HTH, > > > Wouldn't it be a good Idea to have a class for "Delete after one hour"!? > > I've often wanted that. > -- > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
On Tue, 30 Jan 2024 14:41:59 +, Allan Staller wrote: > >You need to look at the JES output to determine the error. >Use the following command >S taskname,,,MSGCLASS=x where x is a held sysout class. > >HTH, > Wouldn't it be a good Idea to have a class for "Delete after one hour"!? I've often wanted that. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Have (or create from sandbox) a simple/failsafe version of the VTAN proc. Export the spool files and import into sandbox or other lpar. I suspect there are sufficwnt breadcrumbs in a standalone dump. Test changes to VTAM proc by running it via a job before you shutdown. > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Ten Eyck > Sent: Tuesday, January 30, 2024 10:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: GTF trace for a JCL error? > > [EXTERNAL EMAIL] > > Dave, > > It was VTAM that would not come up due to a JCL error. We could not sign on > to that LPAR and access JES. I was researching if I could see the JCL error > via a > GTF trace. Sounding like I will not be able to do that. > > In this case, starting the VTAM STC again with S , SUB=MSTR would > write the JCL error to the console. > > The issue has been resolved, just researching what other methods I could have > used… > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Dave, It was VTAM that would not come up due to a JCL error. We could not sign on to that LPAR and access JES. I was researching if I could see the JCL error via a GTF trace. Sounding like I will not be able to do that. In this case, starting the VTAM STC again with S , SUB=MSTR would write the JCL error to the console. The issue has been resolved, just researching what other methods I could have used… -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Run a job with //STEP EXEC procname Presumably it will experience the same JCL error > -Original Message- > From: IBM Mainframe Discussion List On > Behalf Of Peter Ten Eyck > Sent: Tuesday, January 30, 2024 6:31 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: GTF trace for a JCL error? > > [EXTERNAL EMAIL] > > Under z/OS 2.4. > > I have a STC when started, fails with the following error in the SYSLOG: > > IEE132I START COMMAND DEVICE ALLOCATION ERROR > > Looking at the STC output in JES, there is a JCL error in the proc (dataset > not > found). > > Is there a way to "see" the JCL error without looking at the JES output? > > I have been researching and running a GTF trace with no success "seeing" the > JCL error, not sure what GTF trace options to turn on or if it is possible to > see > that JCL error via a GTF trace. > > Is it possible to see that JCL error in a GTF trace, if so, what options > (parms) do > I need to run with? > > > > Note: We had an issue with VTAM not coming up on a LPAR and we were > unable to access JES to see the JCL error. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Thanks for the tip, in this case, S ,sub=MSTR works. As in, writes the IEFA107I JCL error to the console. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
You're going to be a bit stuck without VTAM up. Does the proc in question live in a dataset allocated to IEFPDSI in MSTJCLxx? If so, you might be able to issue S proc,SUB=MSTR and see the corresponding IEF196I messages on the console. Andy Styles -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Ten Eyck Sent: Tuesday, January 30, 2024 2:31 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GTF trace for a JCL error? [Some people who received this message don't often get email from 04d3761a18a7-dmarc-requ...@listserv.ua.edu. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] *** This email is from an external source - be careful of attachments and links. Please report suspicious emails *** Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC95000. Telephone: 0131 225 4555. Lloyds Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 2065. Telephone 0207626 1500. Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC327000. Telephone: 03457 801 801. Lloyds Bank Corporate Markets plc. Registered office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 10399850. Scottish Widows Schroder Personal Wealth Limited. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales no. 11722983. Lloyds Bank plc, Bank of Scotland plc and Lloyds Bank Corporate Markets plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and Prudential Regulation Authority. Scottish Widows Schroder Personal Wealth Limited is authorised and regulated by the Financial Conduct Authority. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is a wholly-owned subsidiary of Lloyds Bank Corporate Markets plc. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH has its registered office at Thurn-und-Taxis Platz 6, 60313 Frankfurt, Germany. The company is registered with the Amtsgericht Frankfurt am Main, HRB 111650. Lloyds Bank Corporate Markets Wertpapierhandelsbank GmbH is supervised by the Bundesanstalt für Finanzdienstleistungsaufsicht. Halifax is a division of Bank of Scotland plc. HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland no. SC218813. This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments. Telephone calls may be monitored or recorded. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Classification: Confidential You need to look at the JES output to determine the error. Use the following command S taskname,,,MSGCLASS=x where x is a held sysout class. HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Ituriel do Neto Sent: Tuesday, January 30, 2024 8:39 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GTF trace for a JCL error? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Hi, You can check the jobclass definitions of your STCs by issuing $DJOBCLASS(STC),LONG or looking into SDSF at JC screen. Probably the outdisp is (PURGE,PURGE). In this case, you may change it to (HOLD,HOLD) to see the JCL. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 30 de janeiro de 2024 às 11:31:17 BRT, Peter Ten Eyck <04d3761a18a7-dmarc-requ...@listserv.ua.edu> escreveu: Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Hi, You can check the jobclass definitions of your STCs by issuing $DJOBCLASS(STC),LONG or looking into SDSF at JC screen. Probably the outdisp is (PURGE,PURGE). In this case, you may change it to (HOLD,HOLD) to see the JCL. Best Regards Ituriel do Nascimento Neto z/OS System Programmer Em terça-feira, 30 de janeiro de 2024 às 11:31:17 BRT, Peter Ten Eyck <04d3761a18a7-dmarc-requ...@listserv.ua.edu> escreveu: Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GTF trace for a JCL error?
Classification: Confidential Nope! -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Ten Eyck Sent: Tuesday, January 30, 2024 8:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: GTF trace for a JCL error? [CAUTION: This Email is from outside the Organization. Unless you trust the sender, Don’t click links or open attachments as it may be a Phishing email, which can steal your Information and compromise your Computer.] Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ::DISCLAIMER:: The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
GTF trace for a JCL error?
Under z/OS 2.4. I have a STC when started, fails with the following error in the SYSLOG: IEE132I START COMMAND DEVICE ALLOCATION ERROR Looking at the STC output in JES, there is a JCL error in the proc (dataset not found). Is there a way to "see" the JCL error without looking at the JES output? I have been researching and running a GTF trace with no success "seeing" the JCL error, not sure what GTF trace options to turn on or if it is possible to see that JCL error via a GTF trace. Is it possible to see that JCL error in a GTF trace, if so, what options (parms) do I need to run with? Note: We had an issue with VTAM not coming up on a LPAR and we were unable to access JES to see the JCL error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
