COBOL calls to PL/I
Josep Lluís
operating system IBM OS/390 2.4. I've been looking in my COBOL manuals
and it seems that this is possible but I don't found how and if there
are some restrictions (sure) and rules. Thank you very much and sorry by
the english level.
fic...@sulzer.de
Interlanguage Communication depends on this issue.
The Doc where the relevant information is located e.g. for PL/1 V2R3
has the code: OS PL/I Version 2 Programming Guide Release 3
Document Number SC26-4307-02
You may find it on IBM's web site.
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Jeffery Swagger
> I need information about how to call PL/I programs from COBOL in
>operating system IBM OS/390 2.4. I've been looking in my COBOL manuals
>and it seems that this is possible but I don't found how and if there
>are some restrictions (sure) and rules. Thank you very much and sorry by
>the english level.
>
You need to be looking in the Language Environment manuals. I don't
remember now whether it's a separate manual or in the Programming Guide
but there is a lot of information about Inter-Language Communication
(ILC) in the LE library.
----
Jeff
Hiroshima 45, Chernobyl 86, Windows 98
Fitz Michael
> I need information about how to call PL/I programs from COBOL in
>operating system IBM OS/390 2.4. I've been looking in my COBOL manuals
>and it seems that this is possible but I don't found how and if there
>are some restrictions (sure) and rules.
The most important thing is that you declare the entry of the PL/1-Procedure
with OPTIONS(COBOL).
You have only a limited set of parameter types you can pass direct, namely:
DEC FIXED(m,n) <--> PIC S9(m-n)V9(n) COMP-3 with m <= 15
BIN FIXED(15) <--> PIC S9999 COMP
BIN FIXED(31) <--> PIC S999999 COMP
CHAR(n) <--> PIC X(n)
Structures should be passed with OPTION(MAP) and declared as NOALG (COBOL
usually doesn`t pad to proper alignments).
Under normal circumstances all parameters are passed as reference, eg changing
any value will pass back to COBOL.
You cannot return a value (to not forget this, you should code your PL/1-Proc
with "RETURNS()").
For performance reasons you should call any PL/1-proc from the main COBOL-prog
(the PL/1-Environment will be built up during the first call of a PL/1-routine
and kept until the calling COBOL-Routine terminates). If your logic requires the
call in some (deeper) subroutine, you should call some dummy-PL/1 (just
returning immediately) in your main-routine.
Hope that helps.
CUL8R!
Ing. Michael Fitz
A-2410 Hainburg; Carnuntumstr. 21
<st...@lords.com> <mf...@aon.at>
=== PGP-Key on request ===
michael...@winterthur.ch
"Josep Lluís" <jlluis...@hotmail.com> wrote:
> I need information about how to call PL/I programs from COBOL in
> operating system IBM OS/390 2.4. I've been looking in my COBOL manuals
> and it seems that this is possible but I don't found how and if there
>
> the english level.
>
>
Take a look at IBMs ILC Manual
Language Environment for OS/390&VM Writing ILC Applications
SC28-1943-04
Chapter 10. Communicating between COBOL and PL/1
hope it helps
Michael
daniel...@winterthur.ch
"Josep Lluís" <jlluis...@hotmail.com> wrote:
> I need information about how to call PL/I programs from COBOL in
> operating system IBM OS/390 2.4. I've been looking in my COBOL manuals
> and it seems that this is possible but I don't found how and if there
> are some restrictions (sure) and rules. Thank you very much and sorry by
>
> the english level.
>
Hi Josep,
In addition of the other replies whitch are absolutely correct, some remarks.
First of all, the called PL/I needs a PROC statement with the COBOL option:
xxxx: PROC (yyy) OPTIONS(COBOL);
Since such a program cannot be called from PL/I you should code one stub
module with this statement per each module to be called. This stub now calls
the real PL/I module which does the work.
The PL/I-module can be called dynamcally (compiler-option DYNAM or 'call
identifier') or can be linked to the COBOL. The PL/I module with 'OPTIONS
COBOL' can call PL/I or Assembler-modules dynamically (via 'FETCH') or can be
linked together. You can even call COBOL-modules from such PL/I!
If your COBOL-PL/I runs under LE/370, both modules must be linked with LE/370
instead of the COBOL II and the PL/I library. Your COBOL must be at least VS
COBOL II, the PL/I at least optimizing compiler version 2.
You find the ILC manual for Language Environment online at
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/Shelves/CEE1BK2A
(read the 'Writing ILC Applications' manual).
If you still use the traditional runtime, the manuals are at
http://ppdbooks.pok.ibm.com:80/cgi-bin/bookmgr/bookmgr.cmd/Shelves/IBMOSH05
(read the 'Programming Guide').
Cheers
Daniel
fic...@sulzer.de
Doc-No SC26-4307-02
4.4.4 Invoking PL/I Routines from COBOL or FORTRAN
You must identify the entry points in a PL/I procedure that are to be invoked
from COBOL or FORTRAN by specifying the appropriate options in the
corresponding PROCEDURE or ENTRY statement. You can also specify options
that suppress remapping of data aggregates.
Because of the way the PL/I environment is preserved, you may not use the
COBOL DYNAM and ENDJOB options when invoking a PL/I PROCEDURE.
COBOL This specifies that the entry point can only be invoked by a COBOL
routine.
FORTRAN
This specifies that the entry point can only be invoked by a FORTRAN
routine.
NOMAP
This specifies that a dummy argument is not created; the COBOL or FORTRAN
aggregate argument is passed directly
to PL/I.
NOMAPIN
This specifies that if a dummy argument is created, it is not initialized
with the values of the aggregate argument.
NOMAPOUT This specifies that, if a dummy argument is created its values are
not assigned back to the aggregate argument on return. You should use the
NOMAPIN and NOMAPOUT options if initializations are not required and program
efficiency is important, since they allow the compiler to omit unnecessary
initialization code.
Parameter list You can specify the parameter or parameters to which the
NOMAP, NOMAPIN, or NOMAPOUT options apply in a list. If you do not specify a
list, the option is applied to all parameters.
You should note the following points when you code the PROCEDURE or ENTRY
statement:
You can use only one of the options MAIN, COBOL, or FORTRAN in the same
statement. You can use one or more
of the options NOMAP, NOMAPIN, or NOMAPOUT in the same statement.
If the parameters for the procedure include strings, areas, or arrays, you
must specify the lengths, sizes, or bounds
for these as integers.
You cannot specify the RETURNS option for any entry point invoked by a
COBOL routine.
Specifying NOMAPIN and NOMAPOUT for the same argument is equivalent to
specifying NOMAP for that argument;
that is, no dummy argument is created.
NOMAP, NOMAPIN, and NOMAPOUT are effective only for structures passed from
COBOL and arrays passed from
FORTRAN.
Examples:
1. P1: PROC(A,B,C) OPTIONS(FORTRAN
NOMAPIN(C) NOMAPOUT(A));
DCL A(3,4) FLOAT BIN(20),
B FIXED BIN(31),
C(5,6) FLOAT DEC(6);
2. P2: PROC(R,S,T) OPTIONS (FORTRAN
NOMAP);
3. P3: PROC(X,Y) OPTIONS(COBOL NOMAPIN(X)
NOMAPOUT(Y));
DCL 1 X, 2...2...3...,
1 Y, 2...2...3...;
Kelly Bert Manning
(fic...@sulzer.de) writes:
> Example from "PL/1 Programming Guide"
> Doc-No SC26-4307-02
>
> 4.4.4 Invoking PL/I Routines from COBOL or FORTRAN
>
> You must identify the entry points in a PL/I procedure that are to be invoked
> from COBOL or FORTRAN by specifying the appropriate options in the
> corresponding PROCEDURE or ENTRY statement. You can also specify options
> that suppress remapping of data aggregates.
So far I haven't seen anyone mention that you have have multiple entry points
to the same PL/I routine, for different calling enviroments.
Eg.
entry: proc options(...
entryC: proc options(cobol...
entryF: proc options(fortran...
I've been doing COBOL<=>PL/I since 1977.
There used to be an enormous performance hit if you called the PL/I
subroutine from a COBOL subroutine, so I'd code a entryZ entry point just
before the final END and tell people to call it once from the COBOL mainline
during initialization. That seems to be obsolete advice under LE370, but
anyone on an older system may want to consider it.
The PL/I environment would be created the first time a PL/I routine was
called, but would only include the COBOL subroutine that called it. When
control percolated back up to whatever called the COBOL subroutine the PL/I
environment would get torn down, only to be recreated the next time the PL/I
routine was called. Calling any PL/I routine from the mainline avoided this.
The routine didn't have to do anything, so it could return immediately.
>
> You cannot specify the RETURNS option for any entry point invoked by a
> COBOL routine.
That's the only time I've ever had to code an interface stub, to return a
PL/I function result in a formal parameter for a COBOL calling program.