MOVE SPACES TO WS-MESSAGE.
MOVE 'SUCCESS :) ' TO WS-MESSAGE.
EXEC CICS SEND TEXT
EXEC CICS RETURN
Problem - Program A calls B. B is supposed to send a map and go return in pseudoconversational mode. If the user presses PF3 it should return control to A. But this is not happening as soon as A calls B, B returns control back to A.
I know it may seem confusing. If you guys could see any mistake in the code, Please advice? I don't have Xpeditor to debug it.
Joined: 06 Jun 2008 Posts: 8280 Location: Dubuque, Iowa, USA
Okay, major confusion here -- there is a reason the Code button exists just below the subject line. Click it, paste your code, click it again.
In the meantime, you say tx JI51 maps to program A. This program checks DFHCOMMAREA length for zero, sends a map, then returns to JI51. When the enter key is hit, program A receives the map and links to program B -- using a COMMAREA. The key code in program B is
IF EIBCALEN = 0
MOVE LOW-VALUES TO FIS544O
MOVE 'FIRST TIME' TO WS-COMMAREA
IF EIBAID = DFHPF3
We know EIBCALEN is not zero in program B ... because you passed a COMMAREA from program A. Fail the IF test.
We know EIBAID is not DFHPF3 ... because you required an ENTER key to get to this point in program A. Fail the IF test.
The only thing left to do is PERFORM B0006-RETURN-PARA.
Warning: you've got multiple COMMAREA lengths, yet you only check EIBCALEN against 0. You're begging for problems -- if you have 2 lengths, check for each or I predict protection exceptions in your future.
I have two programs A (transid JI51) and B(transid JI52). A is calling B through LINK
The basic mistake in your program is
1. The "Linked program " can not run with its own TRANSID. It will work under the "Main Program's TRANSID".
2. The "Linked program" can issue a simple RETURN statement only.
eg. EXEC CICS RETURN END-EXEC.
No TRANSID or COMMAREA are permitted. Even though there are such statements in your program, CICS will simply ignore it and passes control to the main program. So the Linked program can not work in pseudoconversational mode. To work in pseudoconversational mode you have to use XCTL or RETURN statement to invoke another program.
As Robert Sample pointed out, You're begging for problems .
Apart from Robert Sample pointed out, the errors you have committed
You are ignoring MAPFAIL condition. You must HANDLE MAPFAIL condition. If you are not handling MAPFAIL, the program will ABEND if a mapfail condition occurs.
Joined: 06 Jun 2008 Posts: 8280 Location: Dubuque, Iowa, USA
Raghu: there's a link to manuals at the top of the page. If you read the CICS Language Reference and Programming Guide, you will find that LINK accepts COMMAREA and the COMMAREA can be used to pass data between the calling and called program. The linked program can have its own TRANSID or not -- CICS won't care. Although I haven't tested this, from the Programming Guide if the linked program issues a RETURN with TRANSID, the TRANSID will not be invoked until control has returned to the calling program and then back up the chain to the transaction associated with the terminal. Once that original transaction does a return, the TRANSID takes effect -- but if the COMMAREA has been deleted in the meantime, the TRANSID will be cleared.
Further, from the Programming Guide on the RECEIVE MAP:
occurs if the data to be mapped has a length of zero or does not contain a set-buffer-address (SBA) sequence. It applies only to 3270 devices. The receiving data area contains the unmapped input data stream. The amount of unmapped data moved to the user's area is limited to the length specified in the LENGTH option. The input map is not set to nulls.
This condition also arises if a program issues a RECEIVE MAP command to which the terminal operator responds by pressing a CLEAR or PA key, or by pressing ENTER or a PF key without entering data.
Default action: terminate the task abnormally.
Ignoring the MAPFAIL makes perfect sense in some cases. As long as the program expects zero bytes of data to be returned, there's no need to have a HANDLE CONDITION MAPFAIL. Perhaps there's an if test for the CLEAR key -- which would definitely work better by ignoring the MAPFAIL.
You are right. While LINKing to a program we can use COMMAREA. The data will be received in the LINKAGE SECTION of the "Linked" program. While control is passing to the "Linker", a RETURN statement is enough to pass the data to the "Linker".No need of a COMMAREA. Whatever data available in the LINKAGE SECTION of the "Linked" program can be passed to the "Linker" provided, the length of the data is matching.
The Linked program can also have a TRANSID. This can be used in other way also. The Linked program can be invoked separately with TRANSID. So there must be some condition checking in the beginning of the program to use the program as independent program as well as sub-program. Suppose the a program is defined as a sub-program which is working under another program, then that program need not have a TRANSID.
As per the requirement I did not went deep into the details.
Regarding MAPFAIL, I considered only PROGA. Because in PRGOB there is no receive map statement. As per the program PROGB, the ELSE part alone will be executed.
Within that ELSE and END-IF there is no receive map statement.
And I considered this program is written by a CICS beginner because of the program structure. So more description is not given.
If the CLEAR KEY is pressed, no matter what ever statements coded in the program, the screen will be erased, otherwise send the map again. No data will be transmitted to the program. If a receive statement is executed, then a MAPFAIL condition will raise. To avoid this situation, HANDLE AID can be used in the beginning of the program.
The real problem here is, the PROGA calls PROGB and immediately after linking PROGB, control is gained by PROGA. This is because of the program structure. The only statement executed in PROGB is
PERFORM B0006-RETURN-PARA and the statements in that paragraph .
That will pass control to PROGA.