tso rexx calls cobol calls cobol -> splat 
Author Message
 tso rexx calls cobol calls cobol -> splat

I'm trying to call a COBOL subroutine (actually DB access) from a COBOL
program that's called from a REXX program called from the TSO command
line. I got the first call to COBOL to get there by LIBDEFing a
concatenation of loadlibs on the ISPLLIB ddname, but the second call
gets an ABEND 806 reason code 4, which means the first COBOL did a LINK
that didn't find the module, or didn't have a relevant search path in a
relevant ddname.

Anyone know what I'm doing wrong or not doing right here?

--
Patrick Herring at work ("clearly not" ~ Ed.)
disclaimer ~ "the appearance is BT but the essence is me"
"Ockham's razor is so sharp, I bought the whole argument"



Tue, 06 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat
Patrick Herring writes ...

Quote:
>I'm trying to call a COBOL subroutine (actually DB access) from a COBOL
>program that's called from a REXX program called from the TSO command
>line. I got the first call to COBOL to get there by LIBDEFing a
>concatenation of loadlibs on the ISPLLIB ddname, but the second call
>gets an ABEND 806 reason code 4, which means the first COBOL did a LINK
>that didn't find the module, or didn't have a relevant search path in a
>relevant ddname.

>Anyone know what I'm doing wrong or not doing right here?

A couple of possibilities, but the most helpful suggestion is to try using the
TSOLIB command. Before you run the first COBOL program, from the READY prompt,
issue

tsolib act da(_your_load_lib)

If your subroutine is in a different library from your calling program,
"_your_load_lib" should identify the load lib where the subroutine is.

Another thing to consider: are you using an LE version of COBOL? This may
require the LE runtime libs to be included in your LIBDEFs.

Hope this helps.

Cheers,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Tue, 06 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat
What COBOL compiler (and run-time) are you using?  Using ISPF services and
LINKS requires not-only the RENT compiler (not just link-edit) option - but
also requires at least the COBOL/370 compiler.  If you have COBOL for OS/390
& VM, read the section on ISPF programs (in either the Migration Guide or
the Programming Guide - I can't remember which) about new support for ISPF
"multi-tasking".
Quote:

>I'm trying to call a COBOL subroutine (actually DB access) from a COBOL
>program that's called from a REXX program called from the TSO command
>line. I got the first call to COBOL to get there by LIBDEFing a
>concatenation of loadlibs on the ISPLLIB ddname, but the second call
>gets an ABEND 806 reason code 4, which means the first COBOL did a LINK
>that didn't find the module, or didn't have a relevant search path in a
>relevant ddname.

>Anyone know what I'm doing wrong or not doing right here?

>--
>Patrick Herring at work ("clearly not" ~ Ed.)
>disclaimer ~ "the appearance is BT but the essence is me"
>"Ockham's razor is so sharp, I bought the whole argument"



Tue, 06 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat


Quote:
>I'm trying to call a COBOL subroutine (actually DB access) from a COBOL
>program that's called from a REXX program called from the TSO command
>line. I got the first call to COBOL to get there by LIBDEFing a
>concatenation of loadlibs on the ISPLLIB ddname, but the second call gets
>an ABEND 806 reason code 4, which means the first COBOL did a LINK that
>didn't find the module, or didn't have a relevant search path in a
>relevant ddname.
>Anyone know what I'm doing wrong or not doing right here?

You're not really doing anything wrong, you just bumped into the harsh
LIBDEF ISPLLIB reality, as described in "ISPF Services Guide"; I quote:

  If the SELECT program service is invoked using ISPEXEC SELECT
PGM(MYPROG), MYPROG is considered a member of the load libraries specified
with LIBDEF ISPLLIB. If MYPROG then transfers control by using MVS
contents supervision macros such as ATTACH, LINK, LOAD, or XCTL, any new
requested program that exists only in the LIBDEF data set is not found,
and an 806-04 abend occurs.  This is because ISPF links to MYPROG, and MVS
is not aware of the load library defined using LIBDEF ISPLLIB.

There are several solutions to this problem, none of them perfect.  The
simplest one is to replace PGM(MYPROG) with CMD(MYPROG); if MYPROG doesn't
{*filter*}on it, you should be OK.




Tue, 06 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat
...

Quote:
> A couple of possibilities, but the most helpful suggestion is to try
> using the TSOLIB command.

According to my ref this tells TSO about libraries, but the call that's
failing is not under TSO's sway even though the first call was.

Quote:
> Another thing to consider: are you using an LE version of COBOL? This
> may require the LE runtime libs to be included in your LIBDEFs.

I've got the runtime libs in.

--
Patrick Herring at work ("clearly not" ~ Ed.)
disclaimer ~ "the appearance is BT but the essence is me"
"Ockham's razor is so sharp, I bought the whole argument"



Sat, 10 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat

Quote:

> What COBOL compiler (and run-time) are you using?  Using ISPF services
> and LINKS requires not-only the RENT compiler (not just link-edit)
> option - but also requires at least the COBOL/370 compiler.  If you
> have COBOL for OS/390 & VM, read the section on ISPF programs (in
> either the Migration Guide or the Programming Guide - I can't remember
> which) about new support for ISPF "multi-tasking".

I'm using a Cobol2 compiler with Cobol3 run-time, which works and I
didn't choose it! I've the run-time lib in the concatenation. The first
call to Cobol from Rexx does work so I'd guess the Cobol3 compiler isn't
entirely necessary.

Multi-tasking? What, really?

--
Patrick Herring at work ("clearly not" ~ Ed.)
disclaimer ~ "the appearance is BT but the essence is me"
"Ockham's razor is so sharp, I bought the whole argument"



Sat, 10 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat
...

Quote:
> You're not really doing anything wrong, you just bumped into the harsh
> LIBDEF ISPLLIB reality, as described in "ISPF Services Guide"; I
> quote:

>   If the SELECT program service is invoked using ISPEXEC SELECT
> PGM(MYPROG), MYPROG is considered a member of the load libraries
> specified with LIBDEF ISPLLIB. If MYPROG then transfers control by
> using MVS contents supervision macros such as ATTACH, LINK, LOAD, or
> XCTL, any new requested program that exists only in the LIBDEF data
> set is not found, and an 806-04 abend occurs.  This is because ISPF
> links to MYPROG, and MVS is not aware of the load library defined
> using LIBDEF ISPLLIB.

Now why am I not surprised? Thanks for finding what I was looking for in
the oh-so-clearly-organised-IBM-manuals.

Quote:
> There are several solutions to this problem, none of them perfect.  
> The simplest one is to replace PGM(MYPROG) with CMD(MYPROG); if MYPROG
> doesn't {*filter*}on it, you should be OK.

You mean doing the Rexx->Cobol call as a TSO command so that the
Cobol->Cobol call still knows about the libraries? I'm not explicitly
using SELECT - I'm calling from Rexx using linkpgm, also I'm passing
linkage which doesn't expect a length half-word, and I can't change it.

I assume one of the less desireable solutions is to put the loadlibs
into my TSO account's STEPLIB, not sure if the sysadmins would allow
that.

Any others?

--
Patrick Herring at work ("clearly not" ~ Ed.)
disclaimer ~ "the appearance is BT but the essence is me"
"Ockham's razor is so sharp, I bought the whole argument"



Sat, 10 Feb 2001 03:00:00 GMT  
 tso rexx calls cobol calls cobol -> splat


Quote:
>> A couple of possibilities, but the most helpful suggestion is to try
>> using the TSOLIB command.
>According to my ref this tells TSO about libraries, but the call that's
>failing is not under TSO's sway even though the first call was.

TSOLIB doesn't tell TSO about load-libs, it tells TSO to tell
Contents-supervision, the MVS component in charge of loading and managing
load-modules.  As a consequence, TSOLIB-activated load-libraries are
searched whenever a module is loaded during the TSO session, regardless of
the environment (REXX, ISPF, COBOL, etc).

Bottom line: try TSOLIB and if it works for you, use it.

TSOLIB's main restriction is that you can't invoke it while in ISPF.  If
you can't accommodate that, then I suggest that you bring the problem up




Sat, 10 Feb 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. COBOL calling C calling COBOL

2. COBOL calling C calling COBOL

3. Reentrant Cobol from TSO Call - Is it possible?

4. calling TSO-Commands from COBOL

5. AS/400 Cobol trying to call an ILE Cobol function in a service progam - Please help

6. Calling a non-COBOL program from a COBOL program on OS/390

7. Calling Cobol from C (Microfocus Cobol)

8. Visual Age cobol calling Micro Focus cobol

9. Eztrieve calling a COBOL call module?

10. COBOL II calls to OS/VS COBOL programs in batch

11. Call Rexx from COBOL

12. rexx program calling cobol program

 

 
Powered by phpBB® Forum Software