There is an LLA monitor called MODULE FETCH MONITOR you can get from IBM for
free (as in beer), and it displays all of the linklist libraries and what
modules are being used. You are intended to start it at IPL time and let it
run until you shutdown, and while it's up you can look at not only
Modify tso class in jess to keep the joblog. Your operators can print it
for you to review the error
ITschak
בתאריך יום ו׳, 6 במרץ 2020, 1:08, מאת Jesse 1 Robinson <
jesse1.robin...@sce.com>:
> From the dawn of time, it was deucedly difficult to find the cause of a
> JCL error during TSO
Back in Ye Olde Days I had such a problem (very annoying when users would call
the support desk about these things).
We had a modified IKJEFLD that allowed overrides of PROCs and accounts without
requiring UADS entries.
What I did would call the accounting system to verify that the account was
On Thu, 5 Mar 2020 21:07:32 -0500, Tom Conley wrote:
>
>..., I've used the following JCL
>for years to check out procs that fail (typically my STC sysout goes to
>the bit bucket):
>
>//IBMUSERC JOB 'IBMUSER',
>// CLASS=A,
>// NOTIFY=,
>//
On 3/3/2020 12:37 PM, Charles Mills wrote:
I will try COPYGRP and COPYGROUP. What's the difference? The description is
word for word the same.
The big difference (and reason it was invented) is COPYGROUP supports
member name masking whereas COPYGRP does not.
STEPLIBing it seems the simplest, but if for some reason that is not possible,
then you likely have to follow your module update with an LLA REFRESH or LLA
UPDATE command. The TSO ISRDDN suggestion can provide module size (assuming it
differs from the old version) using the M option.
HTH,
On 3/5/2020 5:10 PM, Baldeva Prasad wrote:
Problems in APPLY-CHK of RSU2001 on z/OS2.3 on z14.
While trying to Apply-Chk RSU2001 on z/OS2.3, I am getting the following error
messages:--
Has anyone seen a similar issue in their environment.
Does anyone have an idea on what could be causing
On 3/5/2020 6:08 PM, Jesse 1 Robinson wrote:
From the dawn of time, it was deucedly difficult to find the cause of a JCL
error during TSO logon. Then several releases ago, we were treated to a 'fix'.
The error would be displayed on the user's screen, allowing the problem to be
corrected
If your TSO JES2 definition has the output go to a queue in JES2 that is not
purged immediately, that is where I typically look.
Other option is to review the SAF setup for the TSO Logon Proc and then test
the Logon proc in your TSO Session. Or use a JCL Scanner to verify the proc
the user is
>From the dawn of time, it was deucedly difficult to find the cause of a JCL
>error during TSO logon. Then several releases ago, we were treated to a 'fix'.
>The error would be displayed on the user's screen, allowing the problem to be
>corrected within seconds. Yesterday we had such a
Problems in APPLY-CHK of RSU2001 on z/OS2.3 on z14.
While trying to Apply-Chk RSU2001 on z/OS2.3, I am getting the following error
messages:--
Has anyone seen a similar issue in their environment.
Does anyone have an idea on what could be causing this or a Resolution for the
issue.
Will
Problems in APPLY-CHK of RSU2001 on z/OS2.3 on z14.
While trying to Apply-Chk RSU2001 on z/OS2.3, I am getting the following error
messages:--
Has anyone seen a similar issue in their environment.
Does anyone have an idea on what could be causing this or a Resolution for the
issue.
Will
One would hope that testing would be via STEPLIB.
On Thu, 5 Mar 2020 14:39:31 -0500 Charles Mills wrote:
:>Sometimes you make a code change, and the problem is no better, so you wonder
"did I screw up the code change or am I still running the old code?"
CharlesSent from a mobile; please
On Thu, 5 Mar 2020 14:39:31 -0500, Charles Mills wrote:
>Sometimes you make a code change, and the problem is no better, so you wonder
>"did I screw up the code change or am I still running the old code?"
>CharlesSent from a mobile; please excuse the brevity.
>
Wouldn't it be nice if one could
Sometimes you make a code change, and the problem is no better, so you wonder
"did I screw up the code change or am I still running the old code?"
CharlesSent from a mobile; please excuse the brevity.
Original message From: Binyamin Dissen
Date: 3/5/20 11:07 AM (GMT-05:00)
Hi Dean,
z/XDC's "LOAD" command loads a module into
storage according to the same default rules that
all other processes would follow, and then it
produces a two part report from which you can
discern which instance got LOAD'd to you (when multiple instances exist).
Example. Suppose I
On Thu, 5 Mar 2020 13:20:38 + "Nai, Dean" wrote:
:> Anyone know a way to see if a linklst load mode is being used? We made a
userexit change and I wanted to see if it was using the new load module and not
the old one
thanks
Don't understand why the userexit is relevant. Assuming you
Hi Chris,
Let me check XDC..thanks
Dean
On 3/5/20, 9:59 AM, "IBM Mainframe Discussion List on behalf of Chris Parker"
wrote:
> EXTERNAL: Do not open attachments or click on links unless you recognize and
> trust the sender.
>
>Hi Dean,
>
>I don’t know what type of tooling you
Hi Dean,
I don’t know what type of tooling you have. So, I'm not sure exactly what to
suggest. If you have an eyecatcher in the module that you can verify, you
could use the tso test or testauth command specifying the load module as the
entry program and then just dump the location and
Hi Larre,
No luck. I’m thinking this is something that can’t be found. Thanks for the
response.
Dean Nai
Senior z/OS Systems Programmer
Technical Services Group
Department of Information Technology
State of New Hampshire
27 Hazen Drive
Concord, NH 03301
work: 603-271-1529
Dean -
...how about using the TSO ISRDDN command followed by LOAD module_name ...?
Larre Shiller
US Social Security Administration
“The opinions expressed in this post are mine personally and do not necessarily
reflect the opinion of the US Social Security Administration and/or the US
GIM43501S ** THE CALL TO THE BPX1WRT SERVICE FAILED WHEN PROCESSING
/Service/zos24/OS240809.content/S0933.ROOT.100.pax.Z. THE RETURN
CODE WAS '0085'X AND THE REASON CODE WAS 'EF01604E'X.
GIM49011S ** AN ERROR OCCURRED WHILE CREATING ARCHIVE FILE
Howdy,
Anyone know a way to see if a linklst load mode is being used? We made a
userexit change and I wanted to see if it was using the new load module and not
the old one…thanks
Dean
>
--
For IBM-MAIN subscribe /
I was wrong about the
BAR DS 0D
...
END BAR
case. I had glossed over what "END BAR" meant.
I do agree with Charles and Gil from earlier:
If you have "END BAR" then the normal entry point for the module will
locate BAR, not offset 0
If you have "ALIAS BAR" then the alias will locate
24 matches
Mail list logo
