Dynamically called subroutines in CICS/TS 1.1.1

[Janice Rank]

Listers,
We are working on creating dynamically called subroutines in our VSE 2.6.2
guest sharing environment for the first time. We have the process working
fine in batch, but when we try to use it in our CICS/TS 1.1.1 region, we
keep getting an 0C4/AKEA displaying on the console and an ASRA abend returns
from the program. We know it is abending sometime during the call by using
CEDF to step through the programs.
Right now we have a test program that is pared down to the bare minimum of a
working storage field for the dynamic subroutine name, a text field for
display, a linkage section parm list for the data being passed to and
returned from the sub-routine (currently no data being passed and only a
text field being returned), and a procedure division that consists of
EXEC CICS SEND TEXT FROM (START-CALL-LINE)
LENGTH (150)
FREEKB
ERASE
END-EXEC.

MOVE 'TST05OL' TO DYNAMPGM-SUBROUTINE
CALL DYNAMPGM-SUBROUTINE USING CALL-PASS-PARM-AREA

EXEC CICS SEND TEXT FROM (CALL-PASS-PARM-AREA)
LENGTH (150)
FREEKB
ERASE
END-EXEC.
All the subroutine does is move the text 'LOAD OUTPUT DATA' to the
CALL-PASS-PARM-AREA and returns to the calling program using a GOBACK.
We are compiling both the calling program and the subroutine with the
NODYNAM option per the instructions in the CICS Application Programming
manual. Can anyone give us any clues as to what is causing us to get the
program check and abend?
Thanks,
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com

[Ward, Garry]

Are both the calling and called programs defined in the CSD for the
CICS in question?

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf
Of Janice Rank
Sent: Wednesday, October 27, 2004 1:10 PM
To: VSE Discussion List
Subject: Dynamically called subroutines in CICS/TS 1.1.1

Listers,
We are working on creating dynamically called subroutines in our VSE
2.6.2 guest sharing environment for the first time. We have the process
working fine in batch, but when we try to use it in our CICS/TS 1.1.1
region, we keep getting an 0C4/AKEA displaying on the console and an
ASRA abend returns from the program. We know it is abending sometime
during the call by using CEDF to step through the programs.
Right now we have a test program that is pared down to the bare minimum
of a working storage field for the dynamic subroutine name, a text field
for display, a linkage section parm list for the data being passed to
and returned from the sub-routine (currently no data being passed and
only a text field being returned), and a procedure division that
consists of
EXEC CICS SEND TEXT FROM (START-CALL-LINE)
LENGTH (150)
FREEKB
ERASE
END-EXEC.

MOVE 'TST05OL' TO DYNAMPGM-SUBROUTINE
CALL DYNAMPGM-SUBROUTINE USING CALL-PASS-PARM-AREA

EXEC CICS SEND TEXT FROM (CALL-PASS-PARM-AREA)
LENGTH (150)
FREEKB
ERASE
END-EXEC.
All the subroutine does is move the text 'LOAD OUTPUT DATA' to the
CALL-PASS-PARM-AREA and returns to the calling program using a GOBACK.
We are compiling both the calling program and the subroutine with the
NODYNAM option per the instructions in the CICS Application Programming
manual. Can anyone give us any clues as to what is causing us to get
the program check and abend?
Thanks,
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com



Confidentiality Warning: This e-mail contains information intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient or the employee or agent responsible for delivering it to the intended recipient, any dissemination, publication or copying of this e-mail is strictly prohibited. The sender does not accept any responsibility for any loss, disruption or damage to your data or computer system that may occur while using data contained in, or transmitted with, this e-mail. If you have received this e-mail in error, please immediately notify us by return e-mail. Thank you.

[Michael Rosinger]

Jan,

I found this blurb in the CICS/TS Application Programming Guide:

You must always use the NODYNAM compiler option (the default) when you

compile a COBOL program that is to run with CICS, even if the program
issues
dynamic calls.

And this in the LE/VSE Programming Guide:

COBOL
The following sections describe support for calls compiled under
different versions
of COBOL compilers.
COBOL/VSE
Static and dynamic calls between COBOL/VSE and VS COBOL II programs
are
supported as follows:

v Called programs can contain any command or facility supported by
CICS for
COBOL.

v If the called program has been translated by the CICS translator,
calling
programs must pass the EIB and COMMAREA as the first two parameters on

the CALL statement.


--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Janice Rank]

Garry,
We checked and yes, they are both defined in the CSD.
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com
-----Original Message-----

Are both the calling and called programs defined in the CSD for the CICS

in question?

-----Original Message-----

Listers,
We are working on creating dynamically called subroutines in our VSE
2.6.2 guest sharing environment for the first time. We have the process

working fine in

batch, but when we try to use it in our CICS/TS 1.1.1 region, we keep

getting an 0C4/AKEA

displaying on the console and an ASRA abend returns from the program.
We are compiling both the calling program and the subroutine with the

NODYNAM option per the >instructions in the CICS Application Programming
manual. Can anyone give us any clues as to >what is causing us to get the
program check and abend?

Thanks,
Jan Rank
DBA
Mutual Protective Insurance Company

[Ron Ashley]

Do you have state and flow defined in the subroutine. This will not work for
CICS/TS but will work in batch.

Ronald Ashley

256-535-1269


-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU]On Behalf Of
Janice Rank
Sent: Wednesday, October 27, 2004 1:23 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


Garry,
We checked and yes, they are both defined in the CSD.
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com
-----Original Message-----

Are both the calling and called programs defined in the CSD for the CICS

in question?

-----Original Message-----

Listers,
We are working on creating dynamically called subroutines in our VSE
2.6.2 guest sharing environment for the first time. We have the process

working fine in

batch, but when we try to use it in our CICS/TS 1.1.1 region, we keep

getting an 0C4/AKEA

displaying on the console and an ASRA abend returns from the program.
We are compiling both the calling program and the subroutine with the

NODYNAM option per the >instructions in the CICS Application Programming
manual. Can anyone give us any clues as to >what is causing us to get the
program check and abend?

Thanks,
Jan Rank
DBA
Mutual Protective Insurance Company

[Janice Rank]

Michael,
The last info you found was our problem. Since we had no EXEC CICS commands
in the subroutine we were compiling the program only one time to use in both
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can make
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

Post by Michael Rosinger
COBOL
The following sections describe support for calls compiled under
different versions
of COBOL compilers.
COBOL/VSE
Static and dynamic calls between COBOL/VSE and VS COBOL II programs
are
v Called programs can contain any command or facility supported by
CICS for
COBOL.
v If the called program has been translated by the CICS translator,
calling
programs must pass the EIB and COMMAREA as the first two parameters on
the CALL statement.
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Michael Rosinger]

Jan,

Now you have my curiosity up. According to what I read in the CICS Application
Programming Guide, the implication is that if you don't issue any command level
CICS commands, you don't have to pass the EIB and COMMAREA. We don't have many
CICS programs here, but I know that we have some older VS-Cobol programs still
working that issue static calls to a sub-routine that is used *both* by CICS and
batch. So, your desire to have one program for both seems legitimate. If it
isn't executing any CICS commands or accessing any CICS storage areas, why
should you have to reference the EIB and/or COMMAREA? Seems like there should be
a solution for what you want to do.

Have you verified everything listed in the "Rules governing methods of calling
subprograms" on pages 27-29??

I would suggest you keep digging. Seems to me that what you want to do should
work.

Post by Janice Rank
Michael,
The last info you found was our problem. Since we had no EXEC CICS commands
in the subroutine we were compiling the program only one time to use in both
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can make
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

Post by Michael Rosinger
COBOL
The following sections describe support for calls compiled under
different versions
of COBOL compilers.
COBOL/VSE
Static and dynamic calls between COBOL/VSE and VS COBOL II programs
are
v Called programs can contain any command or facility supported by
CICS for
COBOL.
v If the called program has been translated by the CICS translator,
calling
programs must pass the EIB and COMMAREA as the first two parameters on
the CALL statement.
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Frank Swarbrick]

You should not need to use the CICS translator. We have several batch
routines that are not passed through the CICS translator and they work just
fine in both CICS 2.3 and CICS TS. In fact, if you *do* use the translator
you must pass the EIB and COMMAREA as the first two parms. In other words:

DYNAMPGM-SUBROUTINE has not gone through the translator:
CALL DYNAMPGM-SUBROUTINE USING CALL-PASS-PARM-AREA

DYNAMPGM-SUBROUTINE has gone through the translator:
CALL DYNAMPGM-SUBROUTINE USING DFHEIBLK DFHCOMMAREA CALL-PASS-PARM-AREA

The only time you'd want to do the latter is if the subroutine issues EXEC
CICS commands. And, of course, if the program is meant to work in batch
also then this is not very likely.

As for why it's not working I don't really know... There must be some other
issue.



---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Michael,
The last info you found was our problem. Since we had no EXEC CICS
commands
in the subroutine we were compiling the program only one time to use in
both
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can
make
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

Post by Michael Rosinger
COBOL
The following sections describe support for calls compiled under
different versions
of COBOL compilers.
COBOL/VSE
Static and dynamic calls between COBOL/VSE and VS COBOL II programs
are
v Called programs can contain any command or facility supported by
CICS for
COBOL.
v If the called program has been translated by the CICS translator,
calling
programs must pass the EIB and COMMAREA as the first two parameters on
the CALL statement.
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Gerry Palmer]

Janice,

You should be able to create a single "dual use" subroutine. I've done this
with both static and dynamic calls in OS/390 & zOS CICS, and I think it
should work the same way in VSE. Your subroutine. of course, cannot contain
any EXEC CICS statements or any batch file I/O or any restricted "batch
only" verbs.

Your subroutine does need to adhere to the linkage requirements for CICS,
but as long as you're not really using any of the EIB or DFHCOMMAREA fields
in the subroutine code, you can pass dummy EIB and DFHCOMMAREA addresses
from the batch caller.

First, your subroutine will have to be set up to satisfy the CICS linkage
requirements. You'll define the passed parameters in the Linkage Section
just as you always do, and you'll have to declare the parms on the
PROCEDURE DIVISION USING statement:

LINKAGE SECTION.

01 MY-SUBROUTINE-PARMS.
05 MY-FIELD-ONE PIC X(10).
05 MY-FIELD-TWO PIC S9(4) COMP.

PROCEDURE DIVISION USING DFHCOMMAREA,
MY-SUBROUTINE-PARMS.

Note that you need not define any EIB or DFHCOMMAREA fields in the Linkage
Section. You can, if you wish, include a one-byte DFHCOMMAREA as the first
field in the Linkage Section, but you don't have to. You do need to declare
DFHCOMMAREA as the first element on the Procedure Division USING statement.

The trick, then, is that you have to compile that subroutine as a CICS
module (preprocessor, etc.). That compile process will insert the DFHEIBLK
(and a dummy one-byte DFHCOMMAREA if you didn't explicitly code it) in the
subroutine's Linkage Section and will prepend the DFHEIBLK to the Procedure
Division USING statement.

Then you have to supply the correct parameter list from both the batch and
online programs when calling the subroutine.

As with the subroutine, your online caller will need to go through the
normal CICS compile process, and which will generate the DFHEIBLK (and a
dummy one-byte DFHCOMMAREA if you don't explicitly code it) in the Linkage
Section. You'll define the "real" parameters the subroutine needs in the
Working Storage section, and load them with the appropriate data before
issuing the subroutine CALL. Then on the CALL, you pass the addresses of
the required parameters:

CALL 'DUALSUB' USING DFHEIBLK,
DFHCOMMAREA,
WS-SUBROUTINE-PARMS.

The batch caller will go through a normal batch compile. The CALL still
needs to pass a three-parameter address list, but since you aren't really
using the DFHEIBLK or DFHCOMMAREA fields in your subroutine, you can pass
the addresses of dummy fields. Just define "dummy" EIB and Commarea fields
in the batch caller's Working Storage section, and point to those in the
batch program's call:

WORKING-STORAGE SECTION.

01 WS-DUMMY-DFHEIBLK PIC X.
01 WS-DUMMY-DFHCOMMAREA PIC X.
01 WS-SUBROUTINE-PARMS.
05 WS-FIELD-ONE PIC X(10).
05 WS-FIELD-TWO PIC S9(4) COMP.

And the batch program's CALL will be:

CALL 'DUALSUB' USING WS-DUMMY-DFHEIBLK,
WS-DUMMY-DFHCOMMAREA,
WS-SUBROUTINE-PARMS.

Give it a try and let us know the results!


--
»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«
Gerry Palmer
***@mindspring.com
»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«

[Ron Ashley]

That is true. Some IBM book states that to.

Ronald Ashley

256-535-1269


-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU]On Behalf Of
Janice Rank
Sent: Wednesday, October 27, 2004 2:30 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


Michael,
The last info you found was our problem. Since we had no EXEC CICS commands
in the subroutine we were compiling the program only one time to use in both
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can make
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

Post by Michael Rosinger
COBOL
The following sections describe support for calls compiled under
different versions
of COBOL compilers.
COBOL/VSE
Static and dynamic calls between COBOL/VSE and VS COBOL II programs
are
v Called programs can contain any command or facility supported by
CICS for
COBOL.
v If the called program has been translated by the CICS translator,
calling
programs must pass the EIB and COMMAREA as the first two parameters on
the CALL statement.
--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[k***@comcast.net]

Jan ...

This is not true. I have subroutines used by both batch and online applications with only a single copy of the program. All of the callers are COBOL for VSE so there are no compatibility issues. I also catalog a .OBJ version of the program so batch application can also use static linkage if desired.

--
Kevin Corkery
Independent Consultant
Voorhees, New Jersey

-------------- Original message --------------

Post by Janice Rank
Michael,
The last info you found was our problem. Since we had no EXEC CICS commands
in the subroutine we were compiling the program only one time to use in both
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can make
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

[R***@aol.com]

<<Not very pretty, because that means we have to keep two versions of the
code, but we can make it work.>>

Write your subroutines in assembler. Then you wouldn't HAVE to keep 2 copies.


Robert Botsis
Kroger Co.
513-745-5487
(I read and I remember,
I do and I understand)

[Janice Rank]

Kevin,
If you only keep one copy then do you keep both your batch and online phase
members in the same library or how do you concatenate your libraries to find
the object code?


Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com



_____

From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
***@comcast.net
Sent: Wednesday, October 27, 2004 3:31 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


Jan ...

This is not true. I have subroutines used by both batch and online
applications with only a single copy of the program. All of the callers are
COBOL for VSE so there are no compatibility issues. I also catalog a .OBJ
version of the program so batch application can also use static linkage if
desired.

--
Kevin Corkery
Independent Consultant
Voorhees, New Jersey


-------------- Original message --------------

Post by Janice Rank
Michael,
The last info you found was our problem. Since we had no EXEC CICS

commands

Post by Janice Rank
in the subroutine we were compiling the program only one time to use in

both

Post by Janice Rank
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can

make

Post by Janice Rank
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

[Kevin Corkery]

My CICS library is always searched but the batch library is lower in the
search chain in my CICS partitions, i.e. so these programs as kept in the
default library but are still able to be loaded in CICS.

Kevin P Corkery
Independent Consultant
Voorhees, New Jersey

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
Janice Rank
Sent: Wednesday, October 27, 2004 4:37 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


Kevin,
If you only keep one copy then do you keep both your batch and online phase
members in the same library or how do you concatenate your libraries to find
the object code?


Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com



_____

From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
***@comcast.net
Sent: Wednesday, October 27, 2004 3:31 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


Jan ...

This is not true. I have subroutines used by both batch and online
applications with only a single copy of the program. All of the callers are
COBOL for VSE so there are no compatibility issues. I also catalog a .OBJ
version of the program so batch application can also use static linkage if
desired.

--
Kevin Corkery
Independent Consultant
Voorhees, New Jersey


-------------- Original message --------------

Post by Janice Rank
Michael,
The last info you found was our problem. Since we had no EXEC CICS

commands

Post by Janice Rank
in the subroutine we were compiling the program only one time to use in

both

Post by Janice Rank
batch and online without the EIB or COMMAREA data. We changed the compile
to translate the program for CICS and now it works. Not very pretty,
because that means we have to keep two versions of the code, but we can

make

Post by Janice Rank
it work.
Thanks to you and Garry for your help! This list is invaluable!
Jan Rank
DBA
Mutual Protective Insurance Company

[Janice Rank]

Robert,
Shop standard is COBOL/LE. No other programming language is allowed. Since
we run VSE as a guest sharing member under VM I even had to get special
permission to use REXX routines for alot of the automation of my DB2
maintenance because our DB2 database is on VM.
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com


_____

From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
***@aol.com
Sent: Wednesday, October 27, 2004 3:29 PM
To: VSE Discussion List
Subject: Re: Dynamically called subroutines in CICS/TS 1.1.1


<<Not very pretty, because that means we have to keep two versions of the
code, but we can make it work.>>

Write your subroutines in assembler. Then you wouldn't HAVE to keep 2
copies.


Robert Botsis
Kroger Co.
513-745-5487
(I read and I remember,
I do and I understand)

[g***@escape.net.au]

Frank hit the nail on the head and beat me to it.

Post by Frank Swarbrick
You should not need to use the CICS translator. We have several batch
routines that are not passed through the CICS translator and they work just
fine in both CICS 2.3 and CICS TS. In fact, if you *do* use the translator
you must pass the EIB and COMMAREA as the first two parms.

Regards,
Garry Hasler
VM/VSE Systems Programmer
APC - Perth,WA

[Janice Rank]

Thanks to everyone that replied to our request for help on the dynamically
called subroutine. All of your ideas helped us to determine what the issue
was. It turns out that we did not have the batch phase library in our
concatenation for our CICS regions, this had never been an issue in the past
because we only used static subroutines.
Our compile of the subroutine using the CICS translator put it into the CICS
library and masked the issue. We brought CICS down, added the batch library
at the bottom of the concatenation of libraries and removed the CICS version
of the subroutine just to make sure that this was truly the issue. The
subroutine now works fine in both batch and CICS with the single copy.
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com

[Michael Rosinger]

Jan,

Thanks for the update. I am glad you brought this issue to the list because,
honestly, I did not know that dynamically linked sub-routines were supported in
the world of CICS. I may need to make use of that in the near future.

One other suggestion.... and this may have identified your problem right away.
For dynamic CALLs, using the "ON EXCEPTION" clause will trap the condition of
the phase not being found when the CALL is executed in run-time. We have a
programming standard that requires the use of ON EXCEPTION whenever dynamic
linking is being used. It can save a lot of head-scratching.

Post by Janice Rank
Thanks to everyone that replied to our request for help on the dynamically
called subroutine. All of your ideas helped us to determine what the issue
was. It turns out that we did not have the batch phase library in our
concatenation for our CICS regions, this had never been an issue in the past
because we only used static subroutines.
Our compile of the subroutine using the CICS translator put it into the CICS
library and masked the issue. We brought CICS down, added the batch library
at the bottom of the concatenation of libraries and removed the CICS version
of the subroutine just to make sure that this was truly the issue. The
subroutine now works fine in both batch and CICS with the single copy.
Jan Rank
DBA
Mutual Protective Insurance Company

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Jose L. Flores]

I believe that the only other issue in using dynamically called subroutines
is that they would get loaded into partition getvis space and the storage
would not be released.

-jose-

.---------------------------------------
. Jose L. Flores
. Arden Mayfair Inc.
. ***@gelsons.com
.---------------------------------------



| -----Original Message-----
| From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU]On Behalf Of
| Michael Rosinger
| Sent: Thursday, October 28, 2004 5:55 AM
| To: VSE Discussion List
| Subject: Re: Dynamically called subroutines in CICS/TS 1.1.1
|
|
| Jan,
|
| Thanks for the update. I am glad you brought this issue to the
| list because,
| honestly, I did not know that dynamically linked sub-routines
| were supported in
| the world of CICS. I may need to make use of that in the near future.
|
| One other suggestion.... and this may have identified your
| problem right away.
| For dynamic CALLs, using the "ON EXCEPTION" clause will trap the
| condition of
| the phase not being found when the CALL is executed in run-time. We have a
| programming standard that requires the use of ON EXCEPTION
| whenever dynamic
| linking is being used. It can save a lot of head-scratching.
|
| Janice Rank wrote:
|
| > Thanks to everyone that replied to our request for help on the
| dynamically
| > called subroutine. All of your ideas helped us to determine
| what the issue
| > was. It turns out that we did not have the batch phase library in our
| > concatenation for our CICS regions, this had never been an
| issue in the past
| > because we only used static subroutines.
| > Our compile of the subroutine using the CICS translator put it
| into the CICS
| > library and masked the issue. We brought CICS down, added the
| batch library
| > at the bottom of the concatenation of libraries and removed the
| CICS version
| > of the subroutine just to make sure that this was truly the issue. The
| > subroutine now works fine in both batch and CICS with the single copy.
| > Jan Rank
| > DBA
| > Mutual Protective Insurance Company
| > ***@mutualprotective.com
|
| --
| Michael Rosinger
| Systems Programmer/DBA
| Computer Credit, Inc.
| 640 W. 4th Street
| Winston-Salem, NC 27101
| voice : 336-761-1524
| fax : [phone]
| email : mrosinger at cciws dot com
|
|
|

[Kevin Corkery]

In CICS the program gets loaded into the program DSA so it's not a problem.
In batch there's not much of an issue of releasing the program but COBOL
does support the ability to cancel the program if it does become a problem.

Kevin P Corkery
Independent Consultant
Voorhees, New Jersey

-----Original Message-----
From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU] On Behalf Of
Jose L. Flores
Sent: Thursday, October 28, 2004 1:22 PM
To: VSE Discussion List
Subject: RE: Dynamically called subroutines in CICS/TS 1.1.1


I believe that the only other issue in using dynamically called subroutines
is that they would get loaded into partition getvis space and the storage
would not be released.

-jose-

.---------------------------------------
. Jose L. Flores
. Arden Mayfair Inc.
. ***@gelsons.com
.---------------------------------------



| -----Original Message-----
| From: owner-vse-***@Lehigh.EDU [mailto:owner-vse-***@Lehigh.EDU]On Behalf
| Of Michael Rosinger
| Sent: Thursday, October 28, 2004 5:55 AM
| To: VSE Discussion List
| Subject: Re: Dynamically called subroutines in CICS/TS 1.1.1
|
|
| Jan,
|
| Thanks for the update. I am glad you brought this issue to the list
| because, honestly, I did not know that dynamically linked sub-routines
| were supported in
| the world of CICS. I may need to make use of that in the near future.
|
| One other suggestion.... and this may have identified your problem
| right away. For dynamic CALLs, using the "ON EXCEPTION" clause will
| trap the condition of
| the phase not being found when the CALL is executed in run-time. We have a
| programming standard that requires the use of ON EXCEPTION
| whenever dynamic
| linking is being used. It can save a lot of head-scratching.
|
| Janice Rank wrote:
|
| > Thanks to everyone that replied to our request for help on the
| dynamically
| > called subroutine. All of your ideas helped us to determine
| what the issue
| > was. It turns out that we did not have the batch phase library in
| > our concatenation for our CICS regions, this had never been an
| issue in the past
| > because we only used static subroutines.
| > Our compile of the subroutine using the CICS translator put it
| into the CICS
| > library and masked the issue. We brought CICS down, added the
| batch library
| > at the bottom of the concatenation of libraries and removed the
| CICS version
| > of the subroutine just to make sure that this was truly the issue.
| > The subroutine now works fine in both batch and CICS with the single
| > copy. Jan Rank DBA
| > Mutual Protective Insurance Company
| > ***@mutualprotective.com
|
| --
| Michael Rosinger
| Systems Programmer/DBA
| Computer Credit, Inc.
| 640 W. 4th Street
| Winston-Salem, NC 27101
| voice : 336-761-1524
| fax : [phone]
| email : mrosinger at cciws dot com
|
|
|

[Frank Swarbrick]

We don't do this (CALL...ON EXCEPTION), but it certainly sounds like a good
idea.

Another thing that made me not think that the phase not being found was the
problem was that I would expect an abend 3503 for this situation, which
corresponds with LE error message "CEE3503S The load request for phase
phase-name was unsuccessful." Jan's original message says she got an
0C4/AKEA. I wonder why this is?

Frank
Jan,

Thanks for the update. I am glad you brought this issue to the list
because,
honestly, I did not know that dynamically linked sub-routines were supported
in
the world of CICS. I may need to make use of that in the near future.

One other suggestion.... and this may have identified your problem right
away.
For dynamic CALLs, using the "ON EXCEPTION" clause will trap the condition
of
the phase not being found when the CALL is executed in run-time. We have a
programming standard that requires the use of ON EXCEPTION whenever dynamic
linking is being used. It can save a lot of head-scratching.

Post by Janice Rank
Thanks to everyone that replied to our request for help on the

dynamically

Post by Janice Rank
called subroutine. All of your ideas helped us to determine what the issue
was. It turns out that we did not have the batch phase library in our
concatenation for our CICS regions, this had never been an issue in the past
because we only used static subroutines.
Our compile of the subroutine using the CICS translator put it into the CICS
library and masked the issue. We brought CICS down, added the batch library
at the bottom of the concatenation of libraries and removed the CICS version
of the subroutine just to make sure that this was truly the issue. The
subroutine now works fine in both batch and CICS with the single copy.
Jan Rank
DBA
Mutual Protective Insurance Company

--
Michael Rosinger
Systems Programmer/DBA
Computer Credit, Inc.
640 W. 4th Street
Winston-Salem, NC 27101
voice : 336-761-1524
fax : [phone]
email : mrosinger at cciws dot com

[Janice Rank]

Listers,
I have a further update/question. As I stated we now have a single version
of a dynamically called subroutine working in both CICS and batch, but have
now run into another issue. When we try to dynamically call a sub-routine
containing DB2 SQL statements it works fine in batch, but again goes down
with the dreaded 0C4/AKEA. We still have no EXEC CICS statements in the
sub-routine.
We are looking into using the ON EXCEPTION, but have found that one of our
compiler options may have to change to use it. This is what is stated in
the COBOL VSE Migration Guide (which was referenced from dynamic call
information found in the COBOL FOR VSE/ESA manual). "For COBOL/VSE programs
running under CICS, the ON EXCEPTION/OVERFLOW
clause of the CALL statement is enabled for programs compiled with the
NOCMPR2 compiler option."
My question is - how will this affect batch programs. Since we are trying
to use the same subroutine in both batch and online we would have to compile
batch programs with the same compiler option turned on.
Thanks for any insight,
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com

[Frank Swarbrick]

Are you saying that you use CMPR2? And if so, in which case? (Batch or
CICS.)

CMPR2 should pretty much never be used. Here's a quote from the Migration
Guide:
- When should you use the CMPR2 option?

Use the CMPR2 option when a program written for VS COBOL II
Release 2 does not produce the expected results under NOCMPR2,
or does not compile successfully due to changes in language
elements. You can also use CMPR2 when compiling DOS/VS COBOL
programs that meet the COBOL 74 Standard and do not use any
unsupported language elements or invalid language.

Note: NOCMPR2, supporting the COBOL 85 Standard, is the
strategic standard for IBM COBOL compiler.

At our shop we have the compiler set so that CMPR2 is not even allowed.
Basically, "ON EXCEPTION/OVERFLOW" is from the COBOL 85 standard, and CMPR2
appears to restrict you to the COBOL 74 standard, if I understand this
correctly. Considering that dynamic calls were not available under DOS/VS
COBOL (COBOL 74) I don't see how you could do them using CMPR2.

Actually, looking into it further (and remembering something I believe I
have read) there was a version of VS COBOL II (Release 2) that did not yet
support COBOL 85. It seems to have been some interim version between DOS/VS
COBOL (COBOL 74) and VS COBOL II Release 3(?) (COBOL 85). We never had it
at our shop, so I don't know much more about it... I guess it could be that
Release 2 supported dynamic calls but did not support ON EXCEPTION, which is
from the COBOL 85 standard. But that's just a guess.

Hope this helps at least a bit.



---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
Listers,
I have a further update/question. As I stated we now have a single version
of a dynamically called subroutine working in both CICS and batch, but have
now run into another issue. When we try to dynamically call a sub-routine
containing DB2 SQL statements it works fine in batch, but again goes down
with the dreaded 0C4/AKEA. We still have no EXEC CICS statements in the
sub-routine.
We are looking into using the ON EXCEPTION, but have found that one of our
compiler options may have to change to use it. This is what is stated in
the COBOL VSE Migration Guide (which was referenced from dynamic call
information found in the COBOL FOR VSE/ESA manual). "For COBOL/VSE programs
running under CICS, the ON EXCEPTION/OVERFLOW
clause of the CALL statement is enabled for programs compiled with the
NOCMPR2 compiler option."
My question is - how will this affect batch programs. Since we are trying
to use the same subroutine in both batch and online we would have to
compile
batch programs with the same compiler option turned on.
Thanks for any insight,
Jan Rank
DBA
Mutual Protective Insurance Company
***@mutualprotective.com