|
View previous topic :: View next topic
|
| Author |
Message |
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
I have a sub program which has to pass data back to the calling pgm. Is this data has to be in the LS of the sub pgm? and if so, how can I move data to LS from WS without having addressability problem? Mind you that it is using a dynamic call (not a link).
Thanks. |
|
| Back to top |
|
 |
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Felix61 wrote: |
| I have a sub program which has to pass data back to the calling pgm. Is this data has to be in the LS of the sub pgm? |
Yes.
| Quote: |
| and if so, how can I move data to LS from WS without having addressability problem? Mind you that it is using a dynamic call (not a link). |
The procedure division header with a using on it will take care of the addressability, and a move is a move. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Also, if there are any "unexpected" errors encountered in the called sub-program, set the RETURN-CODE SPECIAL-REGISTER accordingly, which can then be interrogated by the Caller. When everything is OK, just set it to ZERO.
FWIW, the RETURN-CODE SPECIAL-REGISTER equates to setting an RC in R15 in Assembler.
Regards, |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
Thanks for the fast reply...  |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
Here is when it causes the problem when I'm testing through the intertest:
When I do this move - MOVE WS-PASS-FIELDS TO DFHCOMMAREA,
or even if I try to move induvidual fields to LS-....
I get the storage violation
| Code: |
01 DFHCOMMAREA.
02 LS-PASS-FIELDS.
05 LS-GROUP PIC X(3).
05 LS-SUBGROUP PIC X(15).
05 LS-VER-AND-REL.
10 LS-VER-REL-NOW PIC X(2).
05 LS-RET-CD PIC X(1).
05 LS-ERR-MSG PIC X(30).
01 LS-CDE-AREA PIC X(487).
PROCEDURE DIVISION USING DFHEIBLK DFHCOMMAREA. |
|
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Quote: |
| I get the storage violation |
In the called or calling program?
What does the call in the calling program look like?
Use "Code"...... |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
Storage problem is in the called program.
In the calling prog it does "call pgmsub using ws-fields" which should come into my LS-PASS-FIELDS (dfhcommarea)
what I showed above is in the called one. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
I guess I'm from the "Old School", but when I first began coding CICS Dynamic Calls (late 80's), I used the following syntax -
| Code: |
CALL WS-SUB-PROGRAM USING DFHEIBLK, DFHCOMMAREA, WS-WHATEVER.
|
In the WS-SUB-PROGRAM (LINKAGE SECTION) I coded -
| Code: |
LINKAGE SECTION.
01 LS-WHATEVER PIC X(????).
|
The sub-program was translated and compiled and the translator will automatically create/insert DFHEIBLK and build a one-byte dummy DFHCOMMAREA.
In the sub-program PROCEDURE DIVISION, I only coded -
| Code: |
PROCEDURE DIVISION USING LS-WHATEVER.
|
The translator will automatically insert DFHEIBLK and DFHCOMMAREA before LS-WHATEVER, resulting in -
| Code: |
PROCEDURE DIVISION USING DFHBLK DFHCOMMAREA LS-WHATEVER.
|
The trick is not to address DFHCOMMAREA, because there may not have been allocated by the Calling program and you'll avoid a S0C4, which is probably the abend being raised. All you really need to do is to address the third parm, LS-WHATEVER. Addressability to DFHEIBLK has already been done for you.
Using this method, there is a way to access this sub-program via a LINK-API or CALL, by giving the sub-program some intelligence, which I'll leave for another time.
Just my .02 cents....
Regards, |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
| Thanks. I'll try it tomorrow. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
The CICS Programming Guide (link at the top of the page) says in section 1.3.4.2:
| Quote: |
Dynamic COBOL call
The CALL statement may pass DFHEIBLK and DFHCOMMAREA as the first two parameters, if the called program is to issue EXEC CICS requests, or the called program can issue EXEC CICS ADDRESS commands. The COMMAREA is optional but if other parameters are passed, a dummy COMMAREA must also be passed. If the called subprogram uses 24-bit addressing and any parameter is above the 16MB line, COBOL issues a message and abends (1033) . |
so I suspect if you have more trouble tomorrow after trying Bill's idea, you may want to post the calling program statement as well as the linkage section and PROCEDURE DIVISION statement of the called program. The requirements appear to depend upon what your called program is doing. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
You are calling a subroutine with one variable?
| Quote: |
| call pgmsub using ws-fields |
And expecting addressability to a second variable?
Try "call pgmsub using DFHEIBLK DFHCOMMAREA ws-fields" and "PROCEDURE DIVISION USING DFHEIBLK DFHCOMMAREA ws-fields"...... |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
| Sorry, I do have these 2 (DFHEIBLK DFHCOMMAREA) just didn't put here... |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
Sorry, I do have these 2 (DFHEIBLK DFHCOMMAREA) just didn't put here... |
Not to beat a dead horse or anything, but why do people insist on posting what they think is relevant instead of everything that is part of their problem? Let the people who have done these things a few times go through the data -- we can sift wheat from chaff! By not posting the exact data, you risk leading everybody down a side path that could so easily have been avoided by posting the original code from the start. |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Felix61 wrote: |
| Sorry, I do have these 2 (DFHEIBLK DFHCOMMAREA) just didn't put here... |
Dang, newbees.... 
Put in the called program, when first 'awakened' move the using addresses to a comp fields compatible with pointers and display them. See where the move is going. |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
| Well, the calling program is not that important to me. I do the subprog, and as I explained, I can't move fields into LS area so the'd be passed back up. That was the original queshtion. I think that Bill has a point here. Will test tomorrow and see. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
| Well, the calling program is not that important to me |
it should be, that is what defines the linkage in the CALLed module.
1. there is the old way of a COBOL CALL, where the normal cics control blocks are passed (and received - by running the CALLed program thru the CICS precompiler - even if there are no CICS API CALLs made).
and
2. the CALLing program populates a structure that is passed (only thing passed) to the CALLed program - which is not run thru the CICS Precompiler, because why would you COBOL CALL a program that is going to issue CICS API CALLs?
suggest you look at other sub-programs at your shop and see what convention they are using, and copy the same.
once you have determined how your site codes, return here and members can offer advice - based on your requirement, which you do not seem to understand. |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
I checked other programs and they do similar to what Bill stated earlier. I guess I'll have to wait until the calling program is ready and than see how they'll run togather instead of just run subpgm by CECI...
Thanks. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
Felix,
Because you're CALLING the sub-program from a main-program, you won't be able to directly test this sub-program using CECI. You can only access it using a CICS-API, such as a LINK.
Regards, |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| Bill O'Boyle wrote: |
| Because you're CALLING the sub-program from a main-program, you won't be able to directly test this sub-program using CECI. You can only access it using a CICS-API, such as a LINK. |
Huh? If the sub-program has EXEC CICS commands in it, yes, you will be able to directly test it. |
|
| Back to top |
|
|
Felix61
New User
Joined: 09 Apr 2009
Posts: 14
Location: NJ
|
|
|
|
| ceci link prog(prog) |
|
| Back to top |
|
|
CICS Guy
Senior Member
Joined: 18 Jul 2007
Posts: 2146
Location: At my coffee table
|
|
|
|
| CICS Guy wrote: |
| If the sub-program has EXEC CICS commands in it, yes, you will be able to directly test it. |
| Felix61 wrote: |
| ceci link prog(prog) |
The remark was not directed to you, but the called sub-program, not calling program..... |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If the sub-program is being passed three parms, with the third parm representing the actual data (IE: LS-WHATEVER) and DFHCOMMAREA representing the commarea of the Caller (which he's not going to touch), then I'm confused.
This would only prove that he can address the DFHCOMMAREA data and not the third-parm data, which is where the S0C4 was being raised.
Regards, |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
I guess I misunderstood and that Felix is going to wait until the calling (main) program is completed, then he'll use CECI to LINK to the calling program, which will CALL the sub-program.
I thought he was going to attempt to access the sub-program directly using CECI and that's where is I was scratching my head.
OK (CECI <---> Calling Program <---> Sub-Program) makes sense.
Regards, |
|
| Back to top |
|
|
|
|
