How to 'call' a CICS statement imbedded subprogram?

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

hi,
I want to call a CICS statement imbedded subprogram, how can I achieve this ?
I mean, using 'CALL', instead of 'LINK' or 'XCTL'.

backgroud:
I have a copybook which contains record CMLCHLIN , and the copybook is copied in LINKAGE SECTION of main program program,
as I cannot use below statement:

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

I have modified the main program to use DFHEIBLK and DFHCOMMAREA as the first two parameters in the CALL statement, but it still didn't work...

Peter cobolskolan · Posted: Mon May 07, 2012 5:58 pm

dbzTHEdinosauer · Posted: Mon May 07, 2012 6:11 pm

maybe employ the use of 3.3 Chapter 14. Stack and heap storage found in the Language Environment Programming Guide
here is the Language Environment Programming Reference, when you want syntax.
and last but not least, a link to the LE Oveview

Bill O'Boyle · Posted: Tue May 08, 2012 2:58 am

Please post the first 10-20 lines of the called program's PROCEDURE DIVISION. Don't forget to use code tags.

You've got something mixed up....

Bill Woodger · Posted: Tue May 08, 2012 3:19 am

If you are CALLing a program which uses CICS commands, that program gets translated to have DFHEIBLK and DFHCOMMAREA as the first two items on the PROCEDURE DIVISION USING, so they must also, in the correct order, be the first two items on the CALL USING.

Why can't you do a SET, do you think?

What is so wrong, do you feel, with ordinary CALL USING? If you need then the address of an item passed to the called program, you can get it in the called program just as easily, if only you could get the SET to work.

What doesn't work in your program. You've mentioned it twice, but omitted even the slightest detail.

Bill O'Boyle · Posted: Tue May 08, 2012 3:43 am

Bill,

FWIW, you can have a module that can be CALLED or LINKED-TO and you can determine this programmatically.

As the first line of code, check the value of EIBRSRCE.

If it's equal to the sub-program's name, then you've been LINKED-TO and you need to access the commarea. Otherwise, you've been CALLED and (in our case), we had to access the 3rd-parm as a substitute for the commarea and leave the caller's commarea intact.

Regards,

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

in main program:
linkage section:

Peter cobolskolan · Posted: Tue May 08, 2012 10:48 am

To me it seems that you are complicating your programming, but as you dont show all the code, its not easy to understand what you really are doing.

dbzTHEdinosauer · Posted: Tue May 08, 2012 6:38 pm

1. is the main cobol program invoked in batch or cics?

2. what does the procedure division using statement look like in the main program?

3. cobol CALLed modules in CICS operate under a different Task Control Block as CICS modules in the CALL Chain.

as bill said, your CALL to the cics subprogram sucks.
replace the "address of " with a working storage pointer.

if the COBOL CALL to a CICS module actually works,
then upon return, set the ADDRESS of the copy book to the pointer.

if it is a copybook, and you have to obtain memory (and the same amount every time)
stop being an idiot and define this in working-storage of the mainprogram
and stop this getmain bullshit.

i provided links to LE, which will obtain storage for a task.

i personnally do not think that you can invoke a cics module via a cobol call
and expect cics to process any api calls in the submodule.

but, for argument let us say you can,
you still need to change your passed parms.

pass the pointer to the submodule
and set the linkage section structure to the address of ptr
upon return from the memory acquisition.

Bill Woodger · Posted: Tue May 08, 2012 7:02 pm

dbzTHEdinosauer · Posted: Tue May 08, 2012 7:20 pm

sorry bill, it was not an 'actual' but rather a 'paraphrased' quote.

there are two problems in this topic, assuming the main cobol program is COBOL CALLed from a CICS module.

1. don't think you can

COBOL CALL module A from CICS module 1 (this you can do)
COBOL CALL CICS module 2 from module A and expect CICS API's to function

2. even if 1 is ok (that means that I am wrong about the CALL stuff)
Module A should have a WORKING-STORAGE Pointer,
which is passed to CICS Module 2, populated by a CICS GETMAIN,
the return to Module A, which SETS THE ADDRESS OF linkage-structure TO working-storage Pointer populated by CICS module 2.

Bill Woodger · Posted: Tue May 08, 2012 9:34 pm

No problem with the style of the quote, dbz :-)

The CALL x USING ADDRESS OF y behaves like this:

Cobol tucks tucks the address of your item in a little piece of storage that you have no accesss to. Passing it as a parameter is fine, but attempting to change it in the called program is entirely pointless, as there is no lasting relationship between the tucked-away storage and your definition.

In this instance, since you don't have any storage for that yet, the address would be NULL anyway, so not only useless to the calling program, useless to the called program as well.

Dbz has "pointed" you in the right direction for a fix of that.

I also asked to see the COMPILE LISTING with the PROCEDURE DIVISIONS USING, as you previously showed something which is a source listing yet had the parameters on which the CICS translation would include...

Peter cobolskolan · Posted: Tue May 08, 2012 10:09 pm

An example:

dbzTHEdinosauer · Posted: Tue May 08, 2012 10:43 pm

Peter cobolskolan,
the imbedded stuff works,
but does not resolve the problem.

a non-cics COBOL (not part of the CALLing Load module) module
is invoked from a CICS COBOL module via a COBOL CALL
then the COBOL Module CALLS a CICS Module (again separate load module)
does the GETMAIN and then returns to the COBOL Module
which plays with the area (and I hope CALLS the CICS Module again and FREEs the memory!!!!!)
then eventually returns to the CICS Mainprogram.

dbzTHEdinosauer · Posted: Tue May 08, 2012 10:59 pm

back in my younger days,
and since it would only take 10 minutes to test,
i would try putting the CICS LINK getmain-module
in a copybook and then run it thru the CICS translator generating a translated copybook,
which i would then copy into the pure COBOL module.
i would not be surprised if the RETURN from the getmain-module ended up in the pure cobol module.

and have a batch copy of the copybook for calls to a cobol module that does an LE call for memory.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

below is a part of compile list...

Called sub-program compile list:
linkage section

Peter cobolskolan · Posted: Wed May 09, 2012 9:56 am

Try define/install the called program with CEDA.

dejunzhu · Active User Joined: 08 May 2008 Posts: 390 Location: China

I followed Dick Brenholtz 's advice, and the program is called successfully.

Thanks for your advice on this topic.

dbzTHEdinosauer · Posted: Thu May 10, 2012 8:56 pm

earlier this century,
I stumbled upon the obvious phenomenon that
if you take a (db2/cics/mqs) API and put it in a copy book
translate the copybook (run it thru the appropriate pre-compiler)
and COPY that translated copybook into a pgm that was compiled without pre-compiler,
and if the program was invoked in the appropriate environment,
(CALLed by a CICS module or by a module that was already connected to db2/mqs)
the service (db2/cics/mqs service) could be CALLed (the translated copybook) successfully.

which obviously ended with no end of mischief.

i know/knew that cics sets-up different types of TCB's,
one type for a COBOL CALL invoked module
and
another type for a CICS XCTL/LINK invoked module.
always worried that the different TCB's would get me into trouble
while executing 'foreign' commands. (CICS API CALL from a COBOL CALL invoked module).
but it seems that allocated memory for a task,
is just that,
and that worked.
never had to do much else with the CICS stuff,
mqs was really tricky because the STUBs are necessary
db2 was basically getvariables and timestamps,
(but the db2 required additiionally tricky copybooks.
all host references were to linkage, so that worked out)

Dejunzhu,
keep experimenting and pushing the 'bounds'. and have fun.

Bill Woodger · Posted: Mon May 14, 2012 2:43 pm