Barry Schwarz wrote:
On Fri, 25 Aug 2017 22:41:35 -0400, Thomas David Rivers
wrote:
The ATTACH (or ATTACHX) macro is used to create
a subtask - but it requires (basically) a separate
load module...
Is there a mechanism to create a subtask within
the currently loaded load-module?
Yo
IDENTIFY EP=MYSUB,ENTRY=SUBENTRY
ATTACH EP=MYSUB,...
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Thomas David Rivers
Sent: Saturday, August 26, 2017 03:35
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Create subtask w/out a load module
On Sat, 26 Aug 2017, at 10:35, Thomas David Rivers wrote:
> Thanks for the pointer! But I think EPLOC specifies
> the address of the name.. the name is still an 8-byte load
> module name...
No, it's the name of the required entry-point.
A load module can have multiple named entry-points, t
I sure wish there was a way to ATTACH to an address, or that IDENTIFY
allowed me to create an ad-hoc name/address. I maintain a small
subroutine package that seems to have found its way into every kind of
situation that can cause IDENTIFY to fail. Most are purely the fault
of programming in the
OK, this is a weird one. We have an old CLIST that runs as an ISPF edit macro.
On one sysplex only, this CLIST fails with a *Rexx* error message:
IRX0006I Error running JEM, line 2: Unmatched "/*" or quote
The actual line being complained about is included here:
PROC 0 DJSNAME(SPP.JOBSCAN)
/
How is the macro invoked? On the SYSPLEX in question, do all users
experience the problem? For a user who does, are any ALTLIBs in effect when
the error occurs?
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
>
Macro is invoked by simply typing JEM on the command line. I have not found any
user for whom it works today. (I was not the original reporter.) No ALTLIBs in
effect at error time.
FYI JEM is a JCL validation product that we have run for decades in just this
way.
.
.
J.O.Skip Robinson
Southe
On 2017-08-26, at 10:21, Jesse 1 Robinson wrote:
> Macro is invoked by simply typing JEM on the command line. I have not found
> any user for whom it works today. (I was not the original reporter.) No
> ALTLIBs in effect at error time.
>
> FYI JEM is a JCL validation product that we have run f
>What should I be looking for? What would effectively override TRAP(ON)?
Would SDWACLUP ever be set on a vanilla S0C4?
>Why my own ESTAE? So I can deal with unrecoverable ABENDs, which LE will not.
>Why NOSPIE? So everything comes through the ESTAE.
Dangerous path, you chose. Why do I say this?
Hi Bill,
have you tried login with ARCCATGP and do a DELETE NSCR ??
HTH, A.Cecilio
2017-08-21 12:21 GMT+01:00 Rodatz, William J <
william.rod...@labor.alabama.gov>:
> Hi,
>
> I want to thank everyone who responded to my inquiry regarding the
> deletion of migrated datasets. It looks like all of
Hi Tom,
I guess you need:
FC 4017 Cluster Cleanup can be run. FC 4017 is required if the removed
cluster is going to be reused. A Cluster Cleanup removes the previous data
from cache and
returns the cluster to a usable state, similar to a new TS7700 from
manufacturing, keeping the
existing feature
Did you use ISRDDN and search for JEM? Just to verify what you see.
Only time I see this is when a CLIST is on SYSEXEC
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Saturday, August 26, 2017
Would seem to be quite simple to have an EP with code:
L 15,0(,1)
LA1,4(,1)
BR15
Then you plist would have as the first word the EP of the targeted code.
On Sat, 26 Aug 2017 10:48:38
The trace table in the SYSUDUMP should show if the ESTAE(x) got control.
But why do you want your ESTAE to do when the abend is unrecoverable (such as
CANCEL/DETACH)? Some failures will not go thru an ESTAE at all.
On Fri, 25 Aug 2017 16:08:09 -0400 Charles Mills wrote:
:>I have a C++ program c
That would be great if that module (IEFBR15?) was part of the system.
But if I could package a separate module with this thing, there would
be no issue anyway.
sas
On Sat, Aug 26, 2017 at 4:36 PM, Binyamin Dissen
wrote:
> Would seem to be quite simple to have an EP with code:
>
>
How is your subroutine getting control?
If it is standalone or linked to the application, it can IDENTIFY a part of
itself.
The only time this would not work is if you code is loaded into a getmained
area.
On Sat, 26 Aug 2017 16:53:05 -0400 Steve Smith wrote:
:>That would be great if that mod
On Sat, 26 Aug 2017 15:27:21 +, Jesse 1 Robinson
wrote:
>OK, this is a weird one. We have an old CLIST that runs as an ISPF edit macro.
>On one sysplex only, this CLIST fails with a *Rexx* error message:
>...snipped...
>
>What might cause a CLIST to be misinterpreted as Rexx?
What DDNAME d
Am 26.08.2017 um 19:31 schrieb Peter Hunkeler:
Note that we're a COBOL shop, and COBOL allows operations that loose
significant digits in numbers. This causes troubles when the decimal
overflow program mask is set, which it is if C code is also part of
the application (implicit or explicit).
-
Thanks. No COBOL in this picture.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Saturday, August 26, 2017 1:31 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Why would LE not trap?
>What should I be looki
Am 25.08.2017 um 22:08 schrieb Charles Mills:
I have a C++ program compiled with
#pragma runopts( POSIX(ON),TRAP(ON,NOSPIE),NOEXECOPS )
I have my own ESTAEX. On an ABEND, if SDWACLUP is not set, I percolate,
presumably to LE's ESTAE and it drives my C Signal catcher.
It works. In testing, and
FWIW
(a) The "ISREDIT MACRO" should be the *1st* executable statement; there
should be no "PROC 0 " in edit macros - unless the edit macro
is actually embedded in the Clist (a bit unusual).
(b) Anyquotes should be enclosed in both '/*' and '*/' open/closing
chars, even in Clist.
The usual way to
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ceeam00/spetro.htm
Interesting:
For C++ applications, the following values are not allowed for compilation:
* NOEXECOPS | EXECOPS
* NOREDIR | REDIR
* NOARGPARSE | ARGPARSE
if NOEXECOPS is not allowed on #pragma run
On Sat, 26 Aug 2017 12:48:56 -0700, Lizette Koehler wrote:
>Did you use ISRDDN and search for JEM? Just to verify what you see.
>
>Only time I see this is when a CLIST is on SYSEXEC
>
ISRDDN is badly broken. I've reported this and received WAD. If a DDNAME is a
mixed
cocatenation of UNIX dire
> isn't there a third place where LE options come from?
Yes, absolutely, there are installation defaults. Several sets: CICS, POSIX, I
have forgotten what all. I guess that is part of my question here: aren't they
defaults? Is there any way installation "stuff" of some sort overrides #pragma?
C
Interesting about NOEXECOPS. Not sure what I was trying to accomplish there.
> if NOEXECOPS is not allowed on #pragma runopts, will the other options work
> anyway?
I assure you this works 100% of the time in testing, and at most customers, so
the NOEXECOPS is at least generally not hurting us
Would appreciate info on zos shops in Lexington KY and Cincinnati OH, for
possible relo.
What mainframe shops are there???
Thanks,
Joel
Columbia SC
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email
26 matches
Mail list logo
