0

I have encountered an issue recently while processing a CICS transaction. My CICS transaction is calling a chain of dynamically linked COBOL modules. The transaction runs fine for the first time after the PGM-A load is new copied into the region. When I try to process the transaction for the second time, I keep getting CEE3DD abend saying the module not found for PGM-B which is being called from PGM-A. IF I do a new copy for PGM-A in CICS, the transaction again runs fine.

Something is wrong with the CICS setup or memory but I am not able to figure it out. PGM-A is working fine in batch processing. PGM-B has no issues when it is called from any other PGMs except PGM-A. Can someone share some thoughts on what may be wrong with this?

Michał Turczyn
  • 32,028
  • 14
  • 47
  • 69
Mo_Salah
  • 1
  • 1
  • I would suggest you to refer this link https://bonkersjots.blogspot.com/2018/07/static-and-dynamic-call-in-cobol-and.html. Please let us know what compiler options are being used and the type of the CALL statement in the program. I got ABEND 3501 when I tried to link the object code of PGMB with PGMA without link-editing PGMB separately. – Srinivasan JV Jul 18 '18 at 08:52
  • I resolved the abend by compilin and link-editing PGMB. In your case, I suspect the load module to be missing. – Srinivasan JV Jul 18 '18 at 09:07
  • If I do a newcopy PGM-A, it runs fine. So, how could be PGM-B load missing? And more importantly, it shows some junk value instead of pgm name when the CALL command is issued. Something like Load Module "..@.." not found. I would have expected atleast it would say load module "pgm-b" not found. – Mo_Salah Jul 18 '18 at 13:01

3 Answers3

3

To invoke your program via CICS, it must be compiled with the NODYNAM option.

It admittedly seems counter-intuitive, but using the DYNAM option will cause CICS stubs to be loaded, instead of your intended programs, and result in the CEE3501S condition.

So, compile your programs with the NODYNAM option to avoid this error condition.

See the following links for additional info:

https://www.ibm.com/support/knowledgecenter/en/SSGMCP_5.3.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3_cobol_subprog_rules.html

http://www-01.ibm.com/support/docview.wss?uid=swg21054079

Rich Jackson
  • 301
  • 1
  • 5
  • Rich, The main CICS-COBOL pgm is compiled with nodynam option but there is huge chain of calls for processing and all the cobol only modules are compiled with dynam option. And this has been working fine for many years. It is only recently this pgm is showing such behavior. – Mo_Salah Jul 18 '18 at 17:58
1

Does PGM-A use "CALL VARIABLE" to invoke PGM-B? If so check the contents of VARIABLE on the second run (the contents of that variable will probably be reported in the error message. The contents of the variable may be overwritten by a bug in PGM-A. That might explain why the program always fails after the (seemingly) succesful run and after a newcopy.

Fred
  • 31
  • 3
0

Converting this from dynamic to static worked. But the question remains why it was not working with dynamic linking.

Mo_Salah
  • 1
  • 1