Re: Regarding RBINTCOD
If the issuer of ESTAE(X) was system key (0-7), the SDWA is obtained from subpool 230 (high private, not subject to the region limit). For user key, the SDWA is obtained from subpool 0 (low private, subject to the region limit), so R0=12 is more likely for this case, Especially if the abend being handled is due to region exhaustion. There is no 1M between 2047M and 2048M, since both of those values are considerably higher than what could ever be available, after you subtract the 16M that is below 16M, and whatever is the size of ENUC+ELPA+ECSA+ESQA. No limits are bypassed, and currently, nothing is reserved. I have been recently working on implementing on an idea I had 20 years ago to maintain a minimum area between the current top of low private and the current bottom of high private, so that low private cannot go into this area, and if high private intrudes more than halfway into this area, VSM initiates a cancel of the job. That would help to reduce 40D-10 abnormal memterms when RTM2 can't get storage below 16M for the IHARMPL, and reduce situations where we can't obtain an SDWA for a system key ESTAE(X). It would also help with the situation that Seymour Metz mentions now and then, that anyone can easily memterm an initiator by running a simple program that SYNCHes to itself infinitely (since that will exhaust private storage below 16M with PRBs). For example, this is what happens currently: CMN JOB00022 IEF403I SYNCHSLF - STARTED - TIME=03.15.45 CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.49 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = YES CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=002 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=COMPID=SC1CJ,COMPON=CONTENTS SUPERVISOR,ISSUER=CSVFR R,878-000C IN IGVVSERR+0F82. INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEA045I AN SVC DUMP HAS STARTED AT TIME=03.15.50 DATE=01/31/2024 FOR ASID (0028) ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 QUIESCE = NO *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP30 *DUMPID=002 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:49 * ERROR ID = SEQ00019 CPU00 ASID0028 TIME03.15.49.8 *ID = SC1CJ:878-000C IN IGVVSERR+0F82. CMN JOB00022 IEA794I SVC DUMP HAS CAPTURED: DUMPID=003 REQUESTED BY JOB (SYNCHSLF) DUMP TITLE=ABEND=40D,RC=10,COMPON=RTM2,COMPID=SCRTM,ISSUER=IEAV TRT2,MEMTERM - UNRECOVERABLE ABEND FAILURE INSUFFICIENT RESOURCES FOR OPTIMIZE=YES PROCESSING CMN IEF402I INIT FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 CMN IEF402I SYNCHSLF FAILED IN ADDRESS SPACE 0028 SYSTEM ABEND S40D - REASON CODE 10 *CMN *IEA911E COMPLETE DUMP ON SYS1.DUMP31 *DUMPID=003 REQUESTED BY JOB (SYNCHSLF) *FOR ASID (0028) *INCIDENT TOKEN: UTCPLXHD CMN 01/31/2024 03:15:50 CMN JOB00022 $HASP310 SYNCHSLF TERMINATED AT END OF MEMORY CMN STC4 $HASP310 INIT TERMINATED AT END OF MEMORY CMN STC00023 IEF403I INIT - STARTED - TIME=03.15.56 But with a minimum area of 50K below 16M, and 1M above 16M, CMN JOB00024 IEF403I SYNCHSLF - STARTED - TIME=03.19.21 CMN JOB00024 IEF450I SYNCHSLF SYNCHSLF - ABEND=S822 U REASON=0004 TIME=03.19.26 CMN JOB00024 IEF404I SYNCHSLF - ENDED - TIME=03.19.26. So maybe that will get into the next release after z/OS 3.1. Jim Mulder -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Perryman Sent: Tuesday,
Auto: Timezone Database and POSIX
Je suis absent le 31 janvier 2024. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Timezone Database and POSIX
From a recent thread elsewhere (read with no subscription): Time Zone Database https://www.iana.org/time-zones https://mm.icann.org/pipermail/tz/2024-January/025094.html Since the next POSIX will require support for TZDB Zone names in the TZ environment variable, be more careful about phrases like “POSIX-like TZ strings” in comments and documentation. Call them “POSIX.1-2017-like TZ strings” instead, to make it clearer that they’re the traditional POSIX form like TZ='GMT0BST,M3.5.0/1,M10.5.0' instead of the TZDB form like TZ='Europe/London'. Will z/OS follow this common convention (already used by Java)? If not, will Unix System Services UNIX branding expire? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: How can I determine the User Name associated with the current Batch JOB RACF ID?
Great point. CICS is a good example. Connect:Direct is another. On 1/30/2024 3:21 PM, Jon Perryman wrote: You can get it from ACEEUNAM. The intended interface is likely one of the RACROUTE variants (EXTRACT?). Also keep in mind multi-user address spaces and that you are referencing the correct ACEE. MUSAS can occur in unexpected places. E.g. Just because your TSO address space is single user does not mean embedded TSO in my products address space is single user. -- 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: How can I determine the User Name associated with the current Batch JOB RACF ID?
> >You can get it from ACEEUNAM. > > >The intended interface is likely one of the RACROUTE variants (EXTRACT?). Also keep in mind multi-user address spaces and that you are referencing the correct ACEE. MUSAS can occur in unexpected places. E.g. Just because your TSO address space is single user does not mean embedded TSO in my products address space is single user. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
On Tue, 30 Jan 2024 20:05:50 +0200, Binyamin Dissen wrote: >:>Jon P did write what I meant. Answer: no, it just makes it a lot more likely >that the storage obtain for the SDWA will succeed. > >Sad. I believe abend recovery R0=12 is virtually unheard of when SDWA is above the line. Realize that REGION=2048M is not valid and 2047M is the max. I suspect that IBM reserves this last 1M for situations like this. Additionally, running out of 2GB of storage is very rarely from <1K storage obtains. SDWA is small and enough storage should be available. Far more concerning would be S878 abend recovery. Does abend recovery automatically bypass storage limits during S878 abend recovery? If not, is there a mechanism to bypass it temporarily? I've used STORAGE OBTAIN,COND=YES and when it fails, percolate it to IBM recovery. For common recovery in product environments, this is not the best solution but it works most of the time. -- 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?
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: Regarding RBINTCOD
On Tue, 30 Jan 2024 13:17:15 + Peter Relson wrote: :> :>Are you implying that an ESTAE(X) routine with SDWALOC=31 is guaranteed an :>SDWA and there is no reason to check R0 for 12 and alternate code paths? :> :>Jon P did write what I meant. Answer: no, it just makes it a lot more likely that the storage obtain for the SDWA will succeed. Sad. -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel -- 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: [ISPF-L] Replacement for LMAC program in ISPF 3.1
It was written by Doug Nadel while he was working at IBM so it was definitely the IBM PL/X. My guess is that the code dynamically creates the ISPF line command table and then hooks it in dynamically using control blocks, or ???, that Doug knew as he was in ISPF development. Unfortunately that interface has not been exposed for the rest of us. Lionel B. Dyck <>< Github: https://github.com/lbdyck “Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden -Original Message- From: 'Paul Gilmartin' via ISPF discussion list Sent: Tuesday, January 30, 2024 9:46 AM To: ispf-l-l...@nd.edu Subject: Re: [ISPF-L] Replacement for LMAC program in ISPF 3.1 On 1/29/24 23:16:53, Pedro Vera wrote: > If I had this problem, I would browse the load module and search for '5.8' > and use AMASPZAP to modify the text to an acceptable value. > . Bypass a validity check!? The authors may have had a reason to code that. But it may have been only that they were unable to test at a higher level. > Likewise, I might use the dis-assembler that is part of Hi-Level assembler > and look at the source that it produces. And fix that source. > . PL/X? Was this an IBM product? Or a licensed vendor? > On Monday, January 29, 2024 at 1:17:28 PM UTC-8 mark wrote: > > Bummer! Line macro support works but it was missing one thing at the > time. I don’t even recall for sure, maybe it was GLOBAL_LINE_COMMAND_TABLE > which I see now. I also recall opening a requirement for whatever it was. I > still use LMAC, but some of my sandbox LPARs are using a line macro called > LINEMAC and I also supply the table – LINETBL in XMI format on my web site > and CBT file 434. -- gil -- You received this message because you are subscribed to the Google Groups "ISPF discussion list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ispf-l-list+unsubscr...@nd.edu. To view this discussion on the web visit https://groups.google.com/a/nd.edu/d/msgid/ispf-l-list/7e4965bc-543f-4e06-91fb-433e3a3f4930%40AIM.com. -- 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: Replacement for LMAC program in ISPF 3.1
After looking into it the code is in a load module that appears to have been written in PL/X. There are no visible constants for either 5.8 or 7.9 that could be zapped. CBTtape file 961 by Yves Colliard is an excellent replacement with many build in edit line commands. It isn't the same as LMAC as it isn't dynamic but it would be worth investigating. Lionel B. Dyck <>< Github: https://github.com/lbdyck “Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are.” - - - John Wooden -Original Message- From: IBM Mainframe Discussion List On Behalf Of Schmitt, Michael Sent: Monday, January 29, 2024 1:19 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Replacement for LMAC program in ISPF 3.1 ISPF has 3 variables that an application can interrogate for the version: ZOS90RL, ZISPFOS, and ZENVIR. The fact that the edit says the ISPF version must be between 5.8 and 7.9 makes me suspect it is using ZENVIR. What is in the ISPF ZENVIR variable on your z/OS 3.1 system? For example, on a z/OS 2.4 system it is 'ISPF 7.4MVS TSO'. I'm wondering if the high release is a real requirement. You might try zapping the program to change or bypass the edit, so that it can run, and see what happens. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Billy Ashton Sent: Monday, January 29, 2024 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Replacement for LMAC program in ISPF 3.1 Hello, we just turned on z/OS 3.1, and its component ISPF 3.1 here. Now, I just saw when editing a member that my LMAC program (from Doug Nadel originally) no longer works, and gives me a message: LMAC005 You must be running an ISPF version greater than 5.8 and less than 7.9 to run LMAC. How should I deal with this? A quick look on the web indicated that I should use the utility function to define each line command to a macro. I currently have 85 macros in my single Rexx driver, and cannot imagine splitting this and going through that. Do I have any way to drive my single macro program like I had before with LMAC? Thank you and best regards, Billy Ashton -- 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 -- 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
Re: How can I determine the User Name associated with the current Batch JOB RACF ID?
You can get it from ACEEUNAM. The intended interface is likely one of the RACROUTE variants (EXTRACT?). At least in the past (I don't know if still true), there are cases where the ACEE might be what, very loosely, is referred to as encrypted in which case it would not be readable as-is. It's not truly encrypted such that you need some cryptography to decrypt it, but the intent is that the security product know what to do to provide you the "decrypted" info Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Regarding RBINTCOD
Are you implying that an ESTAE(X) routine with SDWALOC=31 is guaranteed an SDWA and there is no reason to check R0 for 12 and alternate code paths? Jon P did write what I meant. Answer: no, it just makes it a lot more likely that the storage obtain for the SDWA will succeed. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
