Hi! I would like to ask if a COBOL program can be called from a Natural program. It would be a big help if you can teach me how.
Thanks!
MJ,
Yes, Natural can call a COBOL program with a CALL statement. For more details and learning please look at this:
[url]http://techcommunity.softwareag.com/ecosystem/documentation/natural/nat426mf2/sm/call.htm[/url]
You will get an example of Natural calling COBOL.
Thanks Ats!
I actually already tried doing this but my natural program still cannot do the call.
I asked our administrator to check if there are natural configuration items that need to be defined (as described in the CALL documentation you sent me) and they said:
As far as natural configuration is concerned, there is no need to define the Cobol program in the CSTATIC parameter since we call the external programs dynamically. It is enough that the program is defined in CICS. As for the Natural programming portion, there are additional statement(s) you need to include. Please see Natural documentation on the SET CONTROL parameters related to external program calling.
I did not see the SET CONTROL command in the sample programs. So I was wondering if this is also necessary. Thanks!
MJ,
Here are the more details:
I see SET CONTROL should be specified (not sure if at Natural programme level, but Natural CICS interface!)
Natural Admin Experts - Can you please shade additional light?
Here are the sample programs I am trying to run in order to test the call to COBOL from a natural program:
Natural program:
DEFINE DATA LOCAL
1 #PARMS
2 #CARRID1 (A3)
2 #CARRID2 (A3)
END-DEFINE
*
MOVE ‘AAA’ TO #CARRID1
MOVE ‘BBB’ TO #CARRID2
CALL ‘IWAYEVTB’ #PARMS
DISPLAY #CARRID1 #CARRID2
*
END
Cobol program:
ID DIVISION.
PROGRAM-ID. IWAYEVTB.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
LINKAGE SECTION.
01 INPUTB.
05 CARR1 PIC X(3).
05 CARR2 PIC X(3).
PROCEDURE DIVISION USING INPUTB.
MAINLINE.
MOVE ‘CCC’ TO CARR1
MOVE ‘DDD’ TO CARR2
EXIT PROGRAM.
On run, this gives me:
DFHAC2206 17:11:19 CICSIPO2 Transaction NATT failed with abend 4038. Updates to local recoverable resources backed out.
a) your COBOL is NOT a CICS program, but a ‘batch’ program.
So you either have to code SET CONTROL ‘P=LS’ or NCIPARM parameter SLCALL=YES must be set in order to use standard linkage conventions (BALR R14,R15) rather than CICS linkage conventions (EXEC CICS LINK).
b) However: I cannot repro the 4093 problem.
so what is your operating system and what is your CICS version? and what Natural CICS version?
MJ,
You may also want to find the cause of 4038. Look at where ever you have the CESE transient data queue pointing (usually pointing to SYSOUT, so you may have to browse CICS output in SDSF or similar product). There will be a message that tells out the cause of the abend (like a resource not defined).
Hi MJ,
I’ve just tried your test, and this is the result (I ran everything in BATCH I should admit):
Page 1
#CARRID1 #CARRID2
CCC DDD
I think you just need to replace EXIT PROGRAM by STOP RUN since your COBOL program is NOT a CICS program as Klaus Kraft fairly mentioned.
I did not use any SET CONTROL in my NATURAL program
Hope it will help you.
Regards,
NK
Hi everyone!
Thanks for the replies…
The version we are using for Natural is 4.1.4 and we are using
CICS 2.3.
I do not know CICS and although I had experience using COBOL online, but I do not know the configuration behind it (i.e., my previous client’s architecture is already configured to be able to run COBOL online). We need to be able to call COBOL programs from transactional online Natural programs that’s why I am trying to test this simple program.
I tried using P=V or P=LS but I still get the same results. 
Is there something I should modify in my COBOL compiler?
@Nikolay: Lucky you!!! I will try your suggestion and get back to you on this. Thanks!!!
@Nikolay!
Using STOP RUN did not solve the problem.
That’s what I suspected: yr problem is related to NCI and CICS versions:
a) NCI 4.1 is out of support by SAG.
b) CTS 2.3 is out of support by IBM since Sept 30, 2009.
The problem would not exist in recent NCI and CICS versions.
And this is the problem: prior to CTS 3.1 it was not possible to have LE enabled CICS programs written in assembler language; but in order to CALL a 3gl program via standard linkage conventions you have to be LE enabled. This was quite tricky in NCI 4.1 and did not have the full functionality as we have now in NCI 4.2:
- you have to re-install NCI according to the instructions as documented in #README in the NCI source library.
- you have to have a 3gl front-end program calling Natural, see #README.
- you have to code SET CONTROL ‘P=LS’ in your Natural program prior to the CALL statement.
.
Alternatives:
Upgrate Natural and CICS versions.
Or make your COBOL batch program a CICS program.
Thanks Klaus!
However, the same versions are used to call C programs from Natural, that is why our IT is thinking that since this is possible, we should be able to call COBOL from Natural as well.
In terms of CICS programming you mean, turn my batch COBOL program into a COBOL CICS program?
actually the programming language nearly is irrelevant, the key is LE.
if a C batch program works, a COBOL or PL/1 program should also work.
Actually I can repro the abend 4038: this happens when batch COBOL is invoked via EXEC CICS LINK.
Using SET CONTROL ‘P=LS’ resolves the 4038 abend in my system.
.
re CICS program:
this means preprocessing COBOL thru CICS pre-compiler and using CICS techniques to obtain the NAT parms via CICS COMMAREA or CICS TWA.
Thanks Klaus!
I guess my testing ends here since I need someone who knows CICS to be able to make this work in our case.
I agree with Klaus about LE. What we found in an IMS environment was that both Natural and Cobol wants to be the leader.
Natural ran in a LE=off mode, and it was easy to call Natural from Cobol as Cobol ran LE=on. The interesting thing comes in when NATICU/XML is available. LE=on is a requirement and Natural could not be called anymore as LE was a problem.
The syntax is easy CALL ‘COBOLpgm’ parms.
In the background is also a library CONAT, investigate the contents of it.