MVSFORUMS.com

[arunarao]

I have a online CICS program A which is compiled with a NODYNAM option.
It calls a batch program B. Program B is compiled with a DYNAM option.

Program A calls B via a Identifier. i.e
CALL WS-B Using B-PARM

WS-B has a value 'B' in the working storage. (So this makes it a Dynamic call right? )

I am facing a problem while running program A in online. It is failing to determine the address of B module. The B-PARM variables also have 'Address Undefined' messages. The CICS abend code is 3501.

Could somebody please help me out with this??

[German Castillo]

Hello arunarao,

Your post suggest that something needs to be clarified, One regarding with calls, other regarding with parms, let's go one step at the time.

Calls, either static or dinamic are not determined by a compiler option. The compiler option Dynam/NoDinam only directs the compiler to consider as default one type or the other. The application programmer can allways override this setting.

Static calls by definition are calls made to an (external) defined program which is link-edit in the same load module as the calling program, that's why it is defined as 'static'. Dinamics, on the other hand, doesn't have to be part of the calling load module itself, please, note that even a statically linkedited module can still be called dinamically, but do not let this fact confuse you.

Application programs, generally have these form of calls, in its own syntax:
CALL 'SUBPRG' .... or
CALL VAR-PRG; where VAR-PRG contains the Called program name

Look that if you select the first choice, it will allways call the same program, no matter what, so now it is time for you to decide to use the NODYNAM compiler option to put your called program into your load module, what the compiler does is to set the proper machine code into your object deck which tells the compiler to 'solve' this issue by bringing up the module beign called into your load.

Next, the second choice comes in, and the very first thing you should notice is that the VALUE of the variable can change at any time during execution of the program, you may not ven know which program you are going to call, this may open several opportunities for an application programmer. The inmediat4e consequence is that you are not going to have anything link-edit with your load module, else (Which one? )

Parameters can be passed between programs, no matter whether they are statically or dinamically called, the usual way is what you have alredy described in your post, the 'normal' way to set addresability to them in a cobol program is by coding your Procedure division statement poinint towards them and (usually) setting a map area to those parms in your linkage section, something like this:
LINKAGE SECTION.
01 PARMS.
...
PROCEDURE DIVISION USING PARMS.

A similar procedure should be done for assembler programs, but you will have to set addresability yourself by chaining from GPR 1 upon entrance to your module (Or at least save that pointer for future reference), something like this

L R3,0(R1) R3 should be your base regs for parms
...


Once you understand this, you are ready for the next step... CICS Calls

CICS needs to have some control areas set up in order to have your programs ready to execute, at least your front end program, the one attached to the trancsaction Id, why? becouse, upon entrance to a program directly from CICS, the internal CICS modules sets them for you! If you want to use any CICS services, you should make your program aware of it! Several things happen in this point, I am not going to describe them all, but your program is provided with addressing to two control block, and the EIB (Execution Interface Block) is the most important. Other issues can be LE related, including abends that come in the form of 40XX.

You, as an application programmer should not worry about this, since you are supposed to PRE-COMPILE your source deck, and it is the duty of the pre-compiler to set addressing to thjose areas on your behalf.

Now, since CICS pre-compiler s setting addresability to its CICS parms, what are you going to do with yourts? Simple answer. use CICS keyword COMMAREA with LINKS, Use TEMP storage queues... This doesn't mean that you can not use calls, either static or dinamic ones, you can certainly do, beasring all thins in mind. For example, if your called program does not need to issue any CICS command, treat it as if it where a Batch call, that is use PROCEDURE DIVISION USING.....

Last but not least is the issue of Performance vs Maintenance. Several authors have different opinions regarding the use of them, but they tend to agree in this:

Performace of an application is generally better in static called modules. The reason is that there is not any extra I/O involved in the call, since the whole module is already loaded into storage.

Maintenance is better for dinamically called modules, since you do not have to recompile all the callers of a module being modified, ensuring allways the execution of the latest version of it.
_________________
Best wishes,

German Castillo

[arunarao]

Hello German Castillo,

thanks for your reply. but my problem still remains as is...
Like you had pointed out, my called program was statically link edited but called dynamically.

The called program is a normal batch program without any CICS commands. So it does have a PROCEDURE DIVISION USING <parms> statement coded in it.

Whereas the calling program is a CICS program with CICS statements coded in it. I know that a call to another CICS program needs to be done via a LINK. However a batch program can be called using a normal CALL statement.

Now then, the calling program is statically link edited. However it calls the batch program dynamically. (i.e . the program doesn't have the called program's load. )
During the execution of the calling program, it is unable to determine the address of the called program. The linkage section variables have 'Unknown Address' message. What could be the reason for this is the Question.

any help on this will be highly appreciated.

[German Castillo]

The easiest way around it would be to call it statically, since you already have it staticaly link-edited

But Your problem could be related with the load of the called module, as opposed to addresing its parms, Correct me if I am wrong but could it be possible that you are getting a message like XXXXXX was not found?.

It seems that in the case of Cobol dynamic calls, Language Environment tries to LOAD the invoked module prior to transfer control to it. Another approuch could be to have the module in the search path (DFHRPLs, Step/Task Libs, Link/LPA), If you make it Reentrant it would be better, but this is not mandatory.
_________________
Best wishes,

German Castillo