Looking for mainframe shops Lexington/Cincinnati

[Joel M Ivey]

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 to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would LE not trap?

[Charles Mills]

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.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Saturday, August 26, 2017 5:42 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why would LE not trap?

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 runopts, will the other options work 
anyway?

Obviously, there are many ways to specify run time options; it is not totally 
clear to me, which ways take precedence ...

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would LE not trap?

[Charles Mills]

> 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?

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Bernd Oppolzer
Sent: Saturday, August 26, 2017 5:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Why would LE not trap?

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 at most customers, a S0Cx drives the Signal 
> routine, 100% of the time.
>
> But one customer has twice gotten a S0C4 and in both cases we got an 
> old-fashioned SYSUDUMP with no Signal. I don't know if we came through 
> the ESTAEX exit or not. The ESTAE exit logic is not at all complex so 
> some subtle bug is unlikely. The reported S0C4 is in the main logic, 
> not in the ESTAE recovery. The fact that it is consistent at one 
> customer leads me to think it is an environmental factor, not a logic error.
>
> There are no LE options in PARM= or CEEOPTS.

don't know, but:

isn't there a third place where LE options come from?
Maybe a installation default?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[Paul Gilmartin]

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 directories and PDS(E)s, ISRDDN MEMBER reports only members
in PDS(E)S even though similarly named members exist earlier in the 
concatenation and
are found by BLDL.  IBM just doesn't follow through on its own good ideas.

Try:
o Renaming the JEM clist in SYSPROC.
o Issue JEM on the Edit command line.

If you get the same error, there's a bogus JEM elsewhere.
If you get UNKNOWN COMMAND, the mystery deepens.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would LE not trap?

[Bernd Oppolzer]

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 runopts, will the other
options work anyway?

Obviously, there are many ways to specify run time options;
it is not totally clear to me, which ways take precedence ...

Kind regards

Bernd



Am 26.08.2017 um 23:26 schrieb Bernd Oppolzer:


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 at most customers, a S0Cx drives the Signal
routine, 100% of the time.

But one customer has twice gotten a S0C4 and in both cases we got an
old-fashioned SYSUDUMP with no Signal. I don't know if we came 
through the

ESTAEX exit or not. The ESTAE exit logic is not at all complex so some
subtle bug is unlikely. The reported S0C4 is in the main logic, not 
in the
ESTAE recovery. The fact that it is consistent at one customer leads 
me to

think it is an environmental factor, not a logic error.

There are no LE options in PARM= or CEEOPTS.


don't know, but:

isn't there a third place where LE options come from?
Maybe a installation default?

I would take a look at your own installation; IIRC some of the LE reports
shows all LE options in effect and where they come from, and there should
be a third source besides PARM and CEEOPTS, that is:
installations defaults. And maybe the installation defaults are 
TRAP(OFF) ??


My former customer would have used TRAP(OFF) ... because he had his
own ESPIE and ESTAE routines (at least before that problem with the S0C8s
due to the wrong C code generation occured). And he would well used this
as an installation default.



Environment is STC, current release of z/OS (not sure exact version but
probably V2R1).

What should I be looking for? What would effectively override TRAP(ON)?
Would SDWACLUP ever be set on a vanilla S0C4?

It's at a customer and the S0C4 is extremely infrequent so "try this/try
that" is not an option. Why my own ESTAE? So I can deal with 
unrecoverable

ABENDs, which LE will not. Why NOSPIE? So everything comes through the
ESTAE.

Charles

--
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: Message IRX0006I running an edit macro CLIST

[CM Poncelet]

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 invoke an edit macro in Clist, e.g. in batch, is of the
form:

code the Clist to invoke the edit macro ...
  PROC 0  DJSNAME(SPP.JOBSCAN)
/* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
  CONTROL END(ENDO) NOMSG NOFLUSH
  ISPEXEC VPUT PARMSTR SHARED  /* store whatever PARMSTR is for macro */
  ISPEXEC EDIT DATASET('') MACRO()
  ISPEXEC VGET RC SHARED /* get the macro RC from shared pool */
  ... finish off the Clist ...
  EXIT CODE()
 
and code the macro as a separate member  ...
  ISREDIT MACRO  /* specify no parms if invoked by a Clist */
  CONTROL END(ENDO) NOMSG NOFLUSH
  ISPEXEC VGET PARMSTR SHARED  /* get the macro parms from shared pool */
  ...  ...
  ... save whatever the macro (MAX)CC is, as e.g. RC ...
  ISPEXEC VPUT RC SHARED  /* store whatever the RC is for Clist */
  ISREDIT END  /* return to Clist */
 
Both the Clist and edit macro should be members of a PDS on DDNAME=SYSPROC.HTH, 
CP  

 



On 26/08/2017 20:48, 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
>
>
> 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 8:27 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Message IRX0006I running an edit macro CLIST
>>
>> 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)
>> /* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
>>   CONTROL END(ENDO) NOMSG NOFLUSH
>>   ISREDIT MACRO (PARMSTR)
>>
>> Of course there is no closing '*/' in line 2, but it's a CLIST, not a Rexx.
>> The CLIST was last modified in 2007 according to ISPF stats. What appears to
>> be exactly the same CLIST works fine on other sysplexes. The z/OS maintenance
>> level (RSU1705) is the same on working and nonworking plexes. I have looked
>> in SYSEXEC libraries and in other SYSPROC libraries for a bogus copy of this
>> exec; nothing found. The CLIST library is VB; member is unnumbered, so data
>> starts in column 9.
>>
>> What might cause a CLIST to be misinterpreted as Rexx?
>>
>>
>>
>> .
>> .
>> J.O.Skip Robinson
>> Southern California Edison Company
>> Electric Dragon Team Paddler
>> SHARE MVS Program Co-Manager
>> 323-715-0595 Mobile
>> 626-543-6132 Office <= NEW
>> robin...@sce.com
> --
> 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: Why would LE not trap?

[Bernd Oppolzer]

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 at most customers, a S0Cx drives the Signal
routine, 100% of the time.

But one customer has twice gotten a S0C4 and in both cases we got an
old-fashioned SYSUDUMP with no Signal. I don't know if we came through the
ESTAEX exit or not. The ESTAE exit logic is not at all complex so some
subtle bug is unlikely. The reported S0C4 is in the main logic, not in the
ESTAE recovery. The fact that it is consistent at one customer leads me to
think it is an environmental factor, not a logic error.

There are no LE options in PARM= or CEEOPTS.


don't know, but:

isn't there a third place where LE options come from?
Maybe a installation default?

I would take a look at your own installation; IIRC some of the LE reports
shows all LE options in effect and where they come from, and there should
be a third source besides PARM and CEEOPTS, that is:
installations defaults. And maybe the installation defaults are 
TRAP(OFF) ??


My former customer would have used TRAP(OFF) ... because he had his
own ESPIE and ESTAE routines (at least before that problem with the S0C8s
due to the wrong C code generation occured). And he would well used this
as an installation default.



Environment is STC, current release of z/OS (not sure exact version but
probably V2R1).

What should I be looking for? What would effectively override TRAP(ON)?
Would SDWACLUP ever be set on a vanilla S0C4?

It's at a customer and the S0C4 is extremely infrequent so "try this/try
that" is not an option. Why my own ESTAE? So I can deal with unrecoverable
ABENDs, which LE will not. Why NOSPIE? So everything comes through the
ESTAE.

Charles

--
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: Why would LE not trap?

[Charles Mills]

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 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? Because we have learnt the
hard way.
We're using a vendor product that chose to install it own ESTAEX upon the
init call from the application. Not only did it install its own ESTAE, it
did also cancel LE's ESPIE (which has the same effect as running with
TRAP(ON,NOSPIE)). It deregisters its ESTAE when the application call the
termination function. In-between, the application run, and eventually calls
some vendor product interface, but also does all the normal programming
stuff under LE.
Installing an own ESTAE is not supported by LE! That's what the manual says.
It seemed to work but actually there are situation when you get into trouble
with thus setup. We learnt this step by step and from discussion I had with
IBM LE people. Finally, I succeeded in convincing the vendor to change their
product, and now they use the LE supported way to get notified about
problems, namely the CEEEXTAN user exit.


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).


- If you run with TRAP(ON,NOSPIE), then your own ESTAE must recognize that
an S0CA ABEND from a COBOL statement is *not* a problem, and your code must
resume the COBOL code. Not easy, believe me. 
In addition, this may become a total performance killer. Assume, (and we
have seen sucht jobs) that a COBOL program has some code that causes decimal
overflow (loosing significant digits). This is intentional, and proper COBOL
coding. Assume such an overflow happens thousands of times during the batch
run. Further, C code is also involved, so the decimal overflow program mask
bit is set. 
The result: COBOL code causes thousands of decimal overflows (00A program
checks). There is no ESPIE, which can handle this with a short path length.
Program check handler takes a shapshot of the system trace table in
anticipation that a dump might be taken, then it percolates to RTM, which
invokes ESTAE routines. Even if the ESTAE knows how to handle this COBOL
decimal overflow, it takes endless time to take the snapshot of the system
trace, depending on the trace table size. WE have 15MB per processor and
this leads to an elapsed time to take the snapshot of 0.2 to 0.5 seconds !!
A nightmare, the application just never completes.  


- If you run with TRAP(ON,SPIE), which you can't inhibit, because
PARM='/TRAP(ON,SPIE) would override your #pragma TRAP(ON,NOSPIE), then LE's
ESPIE will get control for program check, and, LE may decide this is an
unrecoverable error. According to the LE lab people, LE's error handler may
choose not to percolate to (what it thinks is its own ESTAE), but to cancel
the ESTAE and terminate. However, LE, not knowing there is another ESTAE in
front of its own, cancels you product's ESTAE. So, your product will not get
notified about the error. LE's ESTAE, which is still in place, will gain
control and terminate the application.


I understand this does not help much in finding the problem with that one
customer.
LE's documentation is not harsh enough in saying you own ESTAEs and ESPIEs
can cause troubles. Of course, this is only if the product installs the
ESTAE/ESPIE at the beginning of the application, and cancels it at the end.
If you call some code that installs its own recovery, does its job,
deinstalls its own recovery, and returns, then that should be fine, and not
interfere with LE.


 The vendor of our product has change it code an all those problems are
gone.


--
Peter Hunkeler  

--
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: Why would LE not trap?

[Bernd Oppolzer]

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).

- If you run with TRAP(ON,NOSPIE), then your own ESTAE must recognize that an 
S0CA ABEND from a COBOL statement is *not* a problem, and your code must resume 
the COBOL code. Not easy, believe me.
In addition, this may become a total performance killer. Assume, (and we have 
seen sucht jobs) that a COBOL program has some code that causes decimal 
overflow (loosing significant digits). This is intentional, and proper COBOL 
coding. Assume such an overflow happens thousands of times during the batch 
run. Further, C code is also involved, so the decimal overflow program mask bit 
is set.
The result: COBOL code causes thousands of decimal overflows (00A program 
checks). There is no ESPIE, which can handle this with a short path length. ...


We had similar problems in the 1990s.

Our insurance applications, written mostly in PL/1, used the 0CA and 0C8 
program

masks, so that decimal and binary overflows didn't go undetected.

This worked fine, even with C modules called.

But suddenly, in the 1990s, a C compiler version arrived, where certain 
operations
(like modulo) were implemented using arithmetic left shifts, which led 
to 0C8 abends,
if the 0c8 mask bit is set. Of course, the 0C8 mask bit was never set in 
a pure C environment,

but in our environment involving PL/1 FIXEDOVERFLOW, it was.

Instead of repairing the C code generation (which would have been 
natural from my point
of view, given the fact that the previous C compiler did it right), IBM 
did two things:


- first they discussed with us, that it is not OK to set the 
FIXEDOVERFLOW condition, when

calling C from PL/1

- and then they changed LE, so that the 0C8s are handled by the LE error 
handler,

which is a performance nightmare.

Because we have interface modules, that get control between each 
(external) call between
two modules, and the interfaces know about the programming languages of 
caller and callee,
we decided to switch off the 0C8 mask bit there, and to restore it, when 
returning to PL/1.


Kind regards

Bernd

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[Walt Farrell]

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 do you find the CLIST in on the system where it fails? What DDNAME 
is it in on a system where it works?

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Binyamin Dissen]

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 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:
:>>
:>>  L 15,0(,1)
:>>  LA1,4(,1)
:>>  BR15
:>>
:>> Then you plist would have as the first word the EP of the targeted code.
:>>
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Steve Smith]

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:
>
>  L 15,0(,1)
>  LA1,4(,1)
>  BR15
>
> Then you plist would have as the first word the EP of the targeted code.
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Why would LE not trap?

[Binyamin Dissen]

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 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 at most customers, a S0Cx drives the Signal
:>routine, 100% of the time.
:>
:>But one customer has twice gotten a S0C4 and in both cases we got an
:>old-fashioned SYSUDUMP with no Signal. I don't know if we came through the
:>ESTAEX exit or not. The ESTAE exit logic is not at all complex so some
:>subtle bug is unlikely. The reported S0C4 is in the main logic, not in the
:>ESTAE recovery. The fact that it is consistent at one customer leads me to
:>think it is an environmental factor, not a logic error.
:>
:>There are no LE options in PARM= or CEEOPTS.
:>
:>Environment is STC, current release of z/OS (not sure exact version but
:>probably V2R1).
:>
:>What should I be looking for? What would effectively override TRAP(ON)?
:>Would SDWACLUP ever be set on a vanilla S0C4?
:>
:>It's at a customer and the S0C4 is extremely infrequent so "try this/try
:>that" is not an option. Why my own ESTAE? So I can deal with unrecoverable
:>ABENDs, which LE will not. Why NOSPIE? So everything comes through the
:>ESTAE.
:>
:>Charles 
:>
:>--
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Binyamin Dissen]

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 -0400 Steve Smith  wrote:

:>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 client code, but there's
:>nothing I can do about that.
:>
:>In "normal" programs, IDENTIFY will likely do what you want.
:>
:>sas
:>
:>On Sat, Aug 26, 2017 at 7:07 AM, Jeremy Nicoll
:> wrote:
:>> 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, though
:>> of course only has one load-module / member name.
:>>
:>> In the simplest case, the entry-point is at the very start of a load
:>> module, and EP-name is then the same as the load-module name
:>> but (clearly) if there's more than one they can't all be at  the same
:>> place or have the same name.
:>>
:>>
:>>> Perhaps there is no way around it?  You just have to have another load
:>>> module?
:>>
:>> I don't see why.  I wouldn't expect a second copy to be loaded unless
:>> the load modue's attributes made it non-reentrant, non-sharable etc.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[Lizette Koehler]

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 8:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Message IRX0006I running an edit macro CLIST
> 
> 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)
> /* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
>   CONTROL END(ENDO) NOMSG NOFLUSH
>   ISREDIT MACRO (PARMSTR)
> 
> Of course there is no closing '*/' in line 2, but it's a CLIST, not a Rexx.
> The CLIST was last modified in 2007 according to ISPF stats. What appears to
> be exactly the same CLIST works fine on other sysplexes. The z/OS maintenance
> level (RSU1705) is the same on working and nonworking plexes. I have looked
> in SYSEXEC libraries and in other SYSPROC libraries for a bogus copy of this
> exec; nothing found. The CLIST library is VB; member is unnumbered, so data
> starts in column 9.
> 
> What might cause a CLIST to be misinterpreted as Rexx?
> 
> 
> 
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office <= NEW
> robin...@sce.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IBM TS7720 Secure Data Erase

[Toni Cecil]

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 codes in place. Both feature codes are one-time use
features.

In terms of cache, you can only delete lvols with Purge from the z/OS side,
scratch on RMM (or on other tape mgmt), scratch on TCDB and if the library
on ISMF has  eject=PURGE than execute the ejects cmds.

HTH, A.Cecilio

2017-08-11 19:30 GMT+01:00 Tom Sims :

> One of my clients is retiring an old TS7720 and wants to guarantee the
> residual data is completely erased before it leaves the premises.
>
> Can someone out there tell me if the "Secure Data Erase" feature works
> with internal hard drives as the physical media, as well as with take
> cartridges?
>
> Thanks in advance,
>
> Tom Sims
>
> (Speaking only for myself...).
>
> --
> 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: Removing Catalog Entries for Datasets That Do Not Exist

[Toni Cecil]

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 the responses have
> suggested using IDCAMS with the DELETE and NOSCRATCH control statements.  I
> tried that last week.  I ran the job again this morning.  Below is the job
> log and the control statements I used.  As you can see, a call is made to
> DFHSM to do a recall prior to deletion.
>
> DELETE -
>  EH.FP78.RESBHSFL -
>  NOSCRATCH -
>  NONVSAM
>
>
> ICH70001I WR99900  LAST ACCESS AT 05:52:53 ON MONDAY, AUGUST 21, 2017
>  $HASP373 IDCAMS1  STARTED - INIT D- CLASS Y- SYS 9121
>  IEF403I IDCAMS1 - STARTED - TIME=05.57.52
>  ARC0050A DFSMSHSM IS NOT ACTIVE - START DFSMSHSM
>  ARC0051A JOB IDCAMS1  WAITING FOR DFSMSHSM TO RECALL DSN=EH.FP78.RESBHSFL
> *06 ARC0055A REPLY 'GO' OR 'CANCEL'
>
> Thanks again for the responses.
>
> Bill
>
> -Original Message-
>
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rodatz, William J
>
> Sent: Friday, August 18, 2017 10:41 AM
>
> To: IBM-MAIN@LISTSERV.UA.EDU
>
> Subject: Removing Catalog Entries for Datasets That Do Not Exist
>
>
>
> Hello Everyone,
>
>
>
> Recently I discovered some datasets with "MIGRAT" as the volser.  These
> datasets had been migrated with DFHSM many years ago.  My organization is
> no longer running the product.  I am attempting to remove the dangling
> catalog entries which appears to be challenging.  The pubs say to use
> IEHPROGM with the SCRATCH function if (1) the dataset is non-SMS managed
> and (2) you know the dataset's volser prior to migration.  I don't what the
> original volser was and I don't know why it matters.  The catalog entry has
> only the dataset name and "MIGRAT" for the volser.
>
>
>
> When I execute IEHPROGM, I get messages denoting that DFHSM is not
> active.  I am unable to move past this point.
>
>
>
> Does anyone have an idea how the catalog entries can be removed?  Any
> input would be greatly appreciated.
>
>
>
> Thank you.
>
>
>
> Bill
>
>
> --
> 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

AW: Why would LE not trap?

[Peter Hunkeler]

>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? Because we have learnt the hard 
way.
We're using a vendor product that chose to install it own ESTAEX upon the init 
call from the application. Not only did it install its own ESTAE, it did also 
cancel LE's ESPIE (which has the same effect as running with TRAP(ON,NOSPIE)). 
It deregisters its ESTAE when the application call the termination function. 
In-between, the application run, and eventually calls some vendor product 
interface, but also does all the normal programming stuff under LE.
Installing an own ESTAE is not supported by LE! That's what the manual says. It 
seemed to work but actually there are situation when you get into trouble with 
thus setup. We learnt this step by step and from discussion I had with IBM LE 
people. Finally, I succeeded in convincing the vendor to change their product, 
and now they use the LE supported way to get notified about problems, namely 
the CEEEXTAN user exit.


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).


- If you run with TRAP(ON,NOSPIE), then your own ESTAE must recognize that an 
S0CA ABEND from a COBOL statement is *not* a problem, and your code must resume 
the COBOL code. Not easy, believe me.
In addition, this may become a total performance killer. Assume, (and we have 
seen sucht jobs) that a COBOL program has some code that causes decimal 
overflow (loosing significant digits). This is intentional, and proper COBOL 
coding. Assume such an overflow happens thousands of times during the batch 
run. Further, C code is also involved, so the decimal overflow program mask bit 
is set.
The result: COBOL code causes thousands of decimal overflows (00A program 
checks). There is no ESPIE, which can handle this with a short path length. 
Program check handler takes a shapshot of the system trace table in 
anticipation that a dump might be taken, then it percolates to RTM, which 
invokes ESTAE routines. Even if the ESTAE knows how to handle this COBOL 
decimal overflow, it takes endless time to take the snapshot of the system 
trace, depending on the trace table size. WE have 15MB per processor and this 
leads to an elapsed time to take the snapshot of 0.2 to 0.5 seconds !! A 
nightmare, the application just never completes.


- If you run with TRAP(ON,SPIE), which you can't inhibit, because 
PARM='/TRAP(ON,SPIE) would override your #pragma TRAP(ON,NOSPIE), then LE's 
ESPIE will get control for program check, and, LE may decide this is an 
unrecoverable error. According to the LE lab people, LE's error handler may 
choose not to percolate to (what it thinks is its own ESTAE), but to cancel the 
ESTAE and terminate. However, LE, not knowing there is another ESTAE in front 
of its own, cancels you product's ESTAE. So, your product will not get notified 
about the error. LE's ESTAE, which is still in place, will gain control and 
terminate the application.


I understand this does not help much in finding the problem with that one 
customer.
LE's documentation is not harsh enough in saying you own ESTAEs and ESPIEs can 
cause troubles. Of course, this is only if the product installs the ESTAE/ESPIE 
at the beginning of the application, and cancels it at the end. If you call 
some code that installs its own recovery, does its job, deinstalls its own 
recovery, and returns, then that should be fine, and not interfere with LE.


 The vendor of our product has change it code an all those problems are gone.


--
Peter Hunkeler

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[Paul Gilmartin]

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 for decades in just this 
> way. 
>  
Does the DDLIST MEMBER function perhaps show an unexpected instance of JEM?

For diagnosis, temporariy rename JEM and replace it with:
/* Rexx */
signal on novalue
trace R
parse source .

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[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
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of retired mainframer
Sent: Saturday, August 26, 2017 9:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Message IRX0006I running an edit macro CLIST

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
> Sent: Saturday, August 26, 2017 8:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Message IRX0006I running an edit macro CLIST
> 
> 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)
> /* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
>   CONTROL END(ENDO) NOMSG NOFLUSH
>   ISREDIT MACRO (PARMSTR)
> 
> Of course there is no closing '*/' in line 2, but it's a CLIST, not a
Rexx. The CLIST was last
> modified in 2007 according to ISPF stats. What appears to be exactly 
> the
same CLIST
> works fine on other sysplexes. The z/OS maintenance level (RSU1705) is 
> the
same on
> working and nonworking plexes. I have looked in SYSEXEC libraries and 
> in
other
> SYSPROC libraries for a bogus copy of this exec; nothing found. The 
> CLIST
library is VB;
> member is unnumbered, so data starts in column 9.
> 
> What might cause a CLIST to be misinterpreted as Rexx?


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Message IRX0006I running an edit macro CLIST

[retired mainframer]

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
> Sent: Saturday, August 26, 2017 8:27 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Message IRX0006I running an edit macro CLIST
> 
> 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)
> /* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
>   CONTROL END(ENDO) NOMSG NOFLUSH
>   ISREDIT MACRO (PARMSTR)
> 
> Of course there is no closing '*/' in line 2, but it's a CLIST, not a
Rexx. The CLIST was last
> modified in 2007 according to ISPF stats. What appears to be exactly the
same CLIST
> works fine on other sysplexes. The z/OS maintenance level (RSU1705) is the
same on
> working and nonworking plexes. I have looked in SYSEXEC libraries and in
other
> SYSPROC libraries for a bogus copy of this exec; nothing found. The CLIST
library is VB;
> member is unnumbered, so data starts in column 9.
> 
> What might cause a CLIST to be misinterpreted as Rexx?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Message IRX0006I running an edit macro CLIST

[Jesse 1 Robinson]

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)
/* COPYRIGHT DIVERSIFIED SOFTWARE SYSTEMS, INC., 1991,1993.
  CONTROL END(ENDO) NOMSG NOFLUSH
  ISREDIT MACRO (PARMSTR)

Of course there is no closing '*/' in line 2, but it's a CLIST, not a Rexx. The 
CLIST was last modified in 2007 according to ISPF stats. What appears to be 
exactly the same CLIST works fine on other sysplexes. The z/OS maintenance 
level (RSU1705) is the same on working and nonworking plexes. I have looked in 
SYSEXEC libraries and in other SYSPROC libraries for a bogus copy of this exec; 
nothing found. The CLIST library is VB; member is unnumbered, so data starts in 
column 9.

What might cause a CLIST to be misinterpreted as Rexx?



.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office <= NEW
robin...@sce.com


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Steve Smith]

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 client code, but there's
nothing I can do about that.

In "normal" programs, IDENTIFY will likely do what you want.

sas

On Sat, Aug 26, 2017 at 7:07 AM, Jeremy Nicoll
 wrote:
> 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, though
> of course only has one load-module / member name.
>
> In the simplest case, the entry-point is at the very start of a load
> module, and EP-name is then the same as the load-module name
> but (clearly) if there's more than one they can't all be at  the same
> place or have the same name.
>
>
>> Perhaps there is no way around it?  You just have to have another load
>> module?
>
> I don't see why.  I wouldn't expect a second copy to be loaded unless
> the load modue's attributes made it non-reentrant, non-sharable etc.
>
> --
> Jeremy Nicoll - my opinions are my own.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
sas

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Jeremy Nicoll]

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, though 
of course only has one load-module / member name.  

In the simplest case, the entry-point is at the very start of a load
module, and EP-name is then the same as the load-module name
but (clearly) if there's more than one they can't all be at  the same 
place or have the same name.  


> Perhaps there is no way around it?  You just have to have another load 
> module?

I don't see why.  I wouldn't expect a second copy to be loaded unless 
the load modue's attributes made it non-reentrant, non-sharable etc.

-- 
Jeremy Nicoll - my opinions are my own.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Create subtask w/out a load module?

[Richard Rogers]

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?

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?
>>
>>
>
>You can specify the entry address using the EPLOC operand.
>
>  
>
Hi Barry!

  Thanks for the pointer!   But I think EPLOC specifies
 the address of the name.. the name is still an 8-byte load  module name...

   From the ATTACH macro description:

  
   EP=entry name
   EPLOC=entry name addr
   DE=list entry addr
  Specifies the entry name, the address of the entry name, or the
  address of the name field of a 62-byte entry name list. The entry
  name is constructed using the BLDL macro. When EPLOC is coded,
  entry name addr points to an eight-byte field. When the name is
  less than eight characters, left-justify the name and pad with
  blanks on the right to make up the eight characters.`

 (DE is a BLDL directory list result from looking up a name in a PDS
 directory.)

I'm trying to think of how to start a TCB that invokes a function within my
own load module.

One approach would be to have a tiny "helper" load module that accepted a
parameter that was the function's address;  ATTACH would attach that helper
load module, which would then indirectly invoke the function.

That's good enough - but now I want to eliminate the "helper" load module.

Perhaps there is no way around it?  You just have to have another load
module?

 - Thanks -
- Dave Rivers -

-- 
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
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: Create subtask w/out a load module?

[Thomas David Rivers]

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?
   



You can specify the entry address using the EPLOC operand.

 


Hi Barry!

 Thanks for the pointer!   But I think EPLOC specifies
the address of the name.. the name is still an 8-byte load
module name...

  From the ATTACH macro description:

 
  EP=entry name

  EPLOC=entry name addr
  DE=list entry addr
 Specifies the entry name, the address of the entry name, or the
 address of the name field of a 62-byte entry name list. The entry
 name is constructed using the BLDL macro. When EPLOC is coded,
 entry name addr points to an eight-byte field. When the name is
 less than eight characters, left-justify the name and pad with
 blanks on the right to make up the eight characters.`

(DE is a BLDL directory list result from looking up a name in a PDS
directory.)

I'm trying to think of how to start a TCB that invokes a function
within my own load module.

One approach would be to have a tiny "helper" load module that accepted
a parameter that was the function's address;  ATTACH would attach
that helper load module, which would then indirectly invoke the function.

That's good enough - but now I want to eliminate the "helper" load module.

Perhaps there is no way around it?  You just have to have another load 
module?


- Thanks -
   - Dave Rivers -

--
riv...@dignus.comWork: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN