FW: Linking to program on Z/OS

[Bodoh John Robert]

All,

I have a slight problem. I have a REXX exec that is going to by used by several users. It runs in ISPF. The REXX exec invokes an assembler initialization program that pre-loads some assembler written REXX functions and have them stay resident while the REXX program runs. The problem is how do I invoke the initialization program from my load library such that the load modules it loads will remain loaded after the initialization program returns to the REXX program. My understanding is that if I invoke the initialization program through a TSO command like "CALL MYLIB.LOAD(INITIAL)" the CALL command processor is actually ATTACHED as a subtask and the loaded REXX functions would be deleted from memory once the CALL command ented. LINKMVS does not seem to support specifying a data set for the program to be linked to. Because these users are not sophisticated, they would not know how to, nor should they, get out of ISPF, and use the TSOLIB command to allocate my load library.

I feel I'm out of options. Does anyone have a suggestion.

John

----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX

[Steve Comstock]

On 5/11/2012 9:19 AM, Bodoh John Robert wrote:
> All,
>
> I have a slight problem. I have a REXX exec that is going to by used by
several users. It runs in ISPF. The REXX exec invokes an assembler
initialization program that pre-loads some assembler written REXX functions and
have them stay resident while the REXX program runs. The problem is how do I
invoke the initialization program from my load library such that the load
modules it loads will remain loaded after the initialization program returns to
the REXX program. My understanding is that if I invoke the initialization
program through a TSO command like "CALL MYLIB.LOAD(INITIAL)" the CALL command
processor is actually ATTACHED as a subtask and the loaded REXX functions would
be deleted from memory once the CALL command ented. LINKMVS does not seem to
support specifying a data set for the program to be linked to. Because these
users are not sophisticated, they would not know how to, nor should they, get
out of ISPF, and use the TSOLIB command to allocate my load library.
>
> I feel I'm out of options. Does anyone have a suggestion.
>
> John

Hmm. How about your REXX exec using REXX call instead of TSO
call to invoke the assembler routine?

call initial

that is, do _not_ put quotes around nor ADDRESS TSO in front of
the CALL statement.


In your REXX exec you may need to first use LIBDEF to add your load
library to the ISPLLIB concatenation.

Not sure, but might be worth trying.

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html

[Paul Gilmartin]

On May 11, 2012, at 09:19, Bodoh John Robert wrote:
>
> I have a slight problem. I have a REXX exec that is going to by used by several users. It runs in ISPF. The REXX exec invokes an assembler initialization program that pre-loads some assembler written REXX functions and have them stay resident while the REXX program runs. The problem is how do I invoke the initialization program from my load library such that the load modules it loads will remain loaded after the initialization program returns to the REXX program. My understanding is that if I invoke the initialization program through a TSO command like "CALL MYLIB.LOAD(INITIAL)" the CALL command processor is actually ATTACHED as a subtask and the loaded REXX functions would be deleted from memory once the CALL command ented. LINKMVS does not seem to support specifying a data set for the program to be linked to. Because these users are not sophisticated, they would not know how to, nor should they, get out of ISPF, and use the TSOLIB command to allocate my load library.
>

My understanding is that "CALL MYLIB.LOAD(INITIAL)" ATTCHes INITIAL
with MYLIB.LOAD as a TASKLIB. This contains half the solution to
your problem. Break your EXEC into two parts. The first merely
does the "CALL MYLIB.LOAD(INITIAL)". The second, which does the
bulk of your processing can be invoked by INITIAL via the Rexx API.

-- gil

[Bodoh John Robert]

Steve,

The only solution that I can come with is to do the following:

1. Use LIBDEF in my REXX so that I call call my assembler initial program.
2. call my program using a REXX CALL statement and pass the data set name and member name of the load module that contains the functions I want to be resident.
3. The initial program would dynamically allocate the load module data set, open it, and load the functions using the load module data set DCB.

John

[Steve Comstock]

On 5/11/2012 12:20 PM, Bodoh John Robert wrote:
> Steve,
>
> The only solution that I can come with is to do the following:
>
> 1. Use LIBDEF in my REXX so that I call call my assembler initial program.
> 2. call my program using a REXX CALL statement and pass the data set name

> andmember name of the load module that contains the functions I want
> to be resident.

Well, not exactly; with LIBDEF adding the library, your REXX call
should just call the member

> 3. The initial program would dynamically allocate the load module data set,
> open it, and load the functions using the load module data set DCB.
>
> John

Which is what I suggested (except for the correction on point 2). Does it work?

[Bodoh John Robert]

I'm doing dynamic allocation in the initial program...takes a while

John

-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Steve Comstock
Sent: Friday, May 11, 2012 2:32 PM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] FW: Linking to program on Z/OS

On 5/11/2012 12:20 PM, Bodoh John Robert wrote:
> Steve,
>
> The only solution that I can come with is to do the following:
>
> 1. Use LIBDEF in my REXX so that I call call my assembler initial program.
> 2. call my program using a REXX CALL statement and pass the data set name
> andmember name of the load module that contains the functions I want
> to be resident.

Well, not exactly; with LIBDEF adding the library, your REXX call
should just call the member

> 3. The initial program would dynamically allocate the load module data set,
> open it, and load the functions using the load module data set DCB.
>
> John

Which is what I suggested (except for the correction on point 2). Does it work?

[Jeremy Nicoll - ls mainframes]

Bodoh John Robert <John.Rob...@IRS.GOV> wrote:

> Does anyone have a suggestion.

mydsn = left(theloaddsn,44) /* so buffer is always 44 bytes long */
address linkpgm 'INITIAL mydsn' ; initrc = rc

--
Jeremy C B Nicoll - my opinions are my own.

[Ken MacKenzie]

Hi, does anyone have much experience with the REXX compiler?

I'm trying it out for a developer, who for various reasons cannot access
it himself.

I have two execs, which I did not write, let's call them A and B. B's
only function is to output messages and A calls B repeatedly. In order to
establish B's availability, A issues a straightforward TSO command: B. If
B gives RC=0 then it knows it's OK and continues, otherwise it exits with
RC=8.

I have compiled A and B as CEXEC and everything worked OK. Now I want to
try compiling as OBJECT but when I do, the first B command (as above)
fails with RC non zero and I can't see how to force B into the picture so
that A can find it.

Does this make sense? Does anyone have any ideas?

[Steve Comstock]

On 5/14/2012 6:59 AM, Ken MacKenzie wrote:
> Hi, does anyone have much experience with the REXX compiler?
>
> I'm trying it out for a developer, who for various reasons cannot access
> it himself.
>
> I have two execs, which I did not write, let's call them A and B. B's
> only function is to output messages and A calls B repeatedly. In order to
> establish B's availability, A issues a straightforward TSO command: B. If
> B gives RC=0 then it knows it's OK and continues, otherwise it exits with
> RC=8.
>
> I have compiled A and B as CEXEC and everything worked OK. Now I want to
> try compiling as OBJECT but when I do, the first B command (as above)
> fails with RC non zero and I can't see how to force B into the picture so
> that A can find it.
>
> Does this make sense? Does anyone have any ideas?

Try something like this:

//------------ JOB -----------
//CANDL EXEC REXXL,STUB=MVS
//PLKED.SYSIN DD DISP=SHR,DSN=your_object_library(QRDRS)
//LKED.SYSLMOD DD DISP=SHR,DSN=your_load_library

1. The choices for STUB= are: MVS, CPPL, CALLCMD, EFPL, CPPLEFPL
I would guess you want MVS or CALLCMD; may take some experimenting,
and EFPL might be viable for you

2. You can probably make the PLKED.SYSIN a temporary
file passed from a previous step in the same job that
does a compile and places the object deck in the
temporary file

3. Your exec names must be 7 characters or less in length

--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-355-2752
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
+ Training your people is an excellent investment

* Try our tool for calculating your Return On Investment
for training dollars at
http://www.trainersfriend.com/ROI/roi.html

[Ken MacKenzie]

Thanks Steve.

Since this was my first real outing with the compiler, I was struggling in
the dark. I eventually compiled A with STUB=CPPL and left B as
interpreted. B actually contains an INTERPRET instruction, which
generated the following message, which doesn't make sense to me:
EAGREX1300E Error 13 running compiled program, line nn: Invalid character
in program

With A as a load and B as interpreted (it only displays messages) the
users saw a runtime and cputime improvement over A being interpreted.

Not sure about your comment about names being limited to 7 though, the
exec in question has an 8-character name.



From:
Steve Comstock <st...@TRAINERSFRIEND.COM>
To:
TSO-...@VM.MARIST.EDU
Date:
14/05/2012 14:34
Subject:
Re: [TSO-REXX] REXX Compiler Question
Sent by:
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>

[Steve Comstock]

On 5/17/2012 4:57 AM, Ken MacKenzie wrote:
> Thanks Steve.
>
> Since this was my first real outing with the compiler, I was struggling in
> the dark. I eventually compiled A with STUB=CPPL and left B as
> interpreted. B actually contains an INTERPRET instruction, which
> generated the following message, which doesn't make sense to me:
> EAGREX1300E Error 13 running compiled program, line nn: Invalid character
> in program

That is a little strange, but it's hard to diagnose
with the information available.

>
> With A as a load and B as interpreted (it only displays messages) the
> users saw a runtime and cputime improvement over A being interpreted.
>
> Not sure about your comment about names being limited to 7 though, the
> exec in question has an 8-character name.

Well, my notes say that if you use the REXXL procedure,
it generates binder control statements that include
generating names by prefixing your program name with a
$ then truncating to 8 characters.

However, the notes go on to say:

"If you code your own job, you can use your own naming
convention and not be restricted to seven character module
names"

So I should have provided more background / information.