MVSFORUMS.com

[RonB]

1) It doesn't matter whether or not program ABCDTT is defined in the PPT - since you are NOT invoking it via an EXEC CICS command ( e.g. EXEC CICS LINK ).
2) Since you are NOT invoking the ABCDTT program via an EXEC CICS command, a NEWCOPY, even if successful, would not be of any help in solving your problem.
3) Since you're attempting to invoke ABCDTT via a DYNAMIC CALL, the module must reside in either a JOBLIB or STEPLIB that is assigned to the CICS Region in the JCL which brings the region up ( if a STEPLIB is supplied, JOBLIB will NOT be searched, if present ), OR in one of the libraries in the LPA. If you don't want to, or can't, update the JOBLIB, STEPLIB, or LPA, you COULD either call it explicitly and statically link it with the calling module, or invoke it via an EXEC CICS command ( but then you need to be aware that CICS will add parameters to the CALL USING parameter list.
4) The abend code 4038 occurs because of lots of different reasons. One of which is using a STOP RUN in a CICS program. There are, of course, many others.
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

[MFdigger]

Hi Ron

I copied the load ABCDTT into the dataset where it is defined in the STEPLIB DD in JCL which brings up the CICS region.
and tried running the transaction, but facing the same error message

I commented out the cobol statements calling ABCDTT in the main program, and tried executing the transaction but
facing with the same error message

I'm not sure why its showing up the same error message that it cannot find the load module ABCDTT in spool, when I commented out
the cobol code calling that module

Is it some thing that the program is not getting refreshsed in CICS memory?
I tried using the NEWC command but its not working and showing the message as - Transaction 'NEWC' is not recognized.

Am I missing some thing here, can somebody please advice
_________________
Tx
Digger

[MFdigger]

Hi Ron,

I could able to resolve the refreshing the CICS program using the command
CEMT S PROG(PROGRAM NAME) NEW

but I'm still not able to figure out why its not able to identify the load module of the dynamically called program


_________________
Tx
Digger

[RonB]

By any chance is ABCDTT only an ENTRY point or CSECT ( or PROGRAM-ID ) name in a load module that has a member name in the STEPLIBother than ABCDTT? For example, a program compiled as ABCD which contains entry points of ABCDRR and ABCDTT. If so, a dynamic CALL will not work - ever - for an ENTRY point or CSECT name that is different from the library member name. Dynamic calls must always point to the member name in the executable library.
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

[MFdigger]

Hi Ron,

ABCDTT is the only name in the load library.

As you mentioned in your previous post

[RonB]

LPA is the LINK PACK AREA, and it is best thought of as a core-resident concatenation of libraries that contain the most-used, system-wide, global subroutines, utilities, etc. Normally, only systems support folks have the authority to add/delete/update members in the libraries contained in the LPA.
Again, since you are not using CICS services to access the ABCDTT module, it really doesn't matter whether CICS would or would not look for it in the LPA libraries.
If member ABCDTT really DOES exist in one of the libraries allocated to STEPLIB in the JCL used to bring up the CICS region, then I am frankly at a loss to explain why LE services cannot find the module.
_________________
A computer once beat me at chess, but it was no match for me at kick boxing.

[MFdigger]

Ron,

Do we have to pass DFHEIBLK, DFHCOMMAREA as the mandorty params to dynamically called program. I tried that too but was facing with the same error that its not able to find the load for ABCDTT.
_________________
Tx
Digger

[dbzTHEdinosauer]

in the cics jcl there is a DFH??? rmp pmr or something, anyway, that is where application libraries are mentioned. if you can't recognize it, then go to your test cics jcl and find the pds where your test application loads are (you would know the test cics library). anyway, I think that is where the loads need to be.

JCL lib and step lib are for CICS modules (dfh--)

but, not being a cics tech support type, (where is CICS_GUY anyway?) I am not sure if your called load needs to be there or the dfh... thing that I can't remember (and too lazy to look up, sorry).

you only need the dfheiblk and dfhcommarea in linkage of a CICS invoked module (xctl,xlink....).

if your CALL statement does not include them, then you don't need them in the using phrase of the PROCEDURE DIVISION statement.

but, if you ran this CALLed program thru a cics pre-translator, your stuck with the dfheiblk.
no need to cics translate a module that has no cics instructions and is invoked via a CALL.

don't give up on this though. this methodology allows you to have sub-modules (functional modules) that can be invoked in batch and CICS, thus saving the idiot 'dual-module' mentality (which in all fairness was used before people realized we could invoke a cobol/mvs CALL from a cics module.

Bill Boyle will help you address the LE problems. It maybe that the LE routines that you are invoking are not the CICS run time (there is a difference between the CICS runtime LE and Batch.).
_________________
Dick Brenholtz
American living in Varel, Germany

[Terry_Heinze]

Looking for DFHRPL? Relocatable program library?
_________________
....Terry

[warp5]

Removed, overlooked the second page.