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
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
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
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
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
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
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
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
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
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 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.
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
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
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
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
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
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
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
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?
>
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
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
>
>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
22 matches
Mail list logo
