How to end a CICs transaction 1

[MarcLodge]

The system I am working on has been designed to pass a commarea of greater than 32K by specifying a length of 0. This is a slightly dodgy practice, but does work. There is nothing that I can do to change this or this design.

I am attempting to call a top level Cobol/CICS transaction from a batch Cobol program using the CICS external interface EXCI. This bit is working fine. This top level cobol program EXEC CICS LINKS to other programs which exploit this greater than 32k limit.

When my top level Cobol CICS program issues the CICS RETURN statement in order to pass control back to the batch CICS program, everything abends with 0C4 exception error, because CICS has got it addressing in a mess.

I am under the impression that the only reason it works in the online environment is because the front end is a PC and the connecting infrastructure is not CICS (Interworking I think).

So my question is, is there anyway to stop a Cobol CICS transaction other than a return statement. Alternatively, if anybody has run across this before and knows a way round it, I'd be grateful for help.

Regards,

Marc

 

[stevexff]

Marc

It's got nothing to do with how the transaction ends, it's what it's doing that is the problem...

The reason it works online and not through EXCI is because you have a COMMAREA length of 0. Online, you are all in the same address space, so you can pass a pointer to an area with an incorrect length and get away with it. The target program just picks up the start address, ignores the length and processes it (although this is a storage violation waiting to happen).

Over EXCI, the calling program is in another address space. The EXCI interface picks up the COMMAREA you specify in your batch program (including the length), sends it across to CICS, and constructs a copy of it in the CICS address space. With the length you specify, in this case zero. It then invokes your program, passing it a pointer to the copy of the COMMAREA. You then proceed to write all over it, ignoring the length, causing either a storage violation or in this case a protection exception (S0C4).

Hope this helps

 

[MarcLodge]

Steve,
the batch CICS program calls the Cobol CICS transaction (the top level program) passing a less than 32K commarea and the correct length parameter. It's further on down the chain of linked programs that the skulduggery with the commarea occurs. There is absolutely nothing I can do about this, it's been designed that way, and I'm stuck with it, for the time being at least.

The abend occurs when the top level program attemps to issue a CICS RETURN statement and pass control back to the batch CICS program.

I understand why it's happening, but think that I am lumbered by the restrictions of the design into not being able to go down this path.

Unless anybody knows of a way to get CICS to stop, doing all updates, but not attempt to pass control back to the batch program!

 

[stevexff]

Marc

It might be worth checking the called modules on the CICS side to see if they are 31-bit (AMODE 31, RMODE ANY). EXCI requires 31-bit code, so it may be a mismatch int this area.

Steve

 

[gregsimpson]

Steve,

an excellent repsonse as regards addressing etc.

MArc,

Interworking is a propietary product know only to the people where you work. Coincidentally Steve knows about it too, as until recently he worked there too. Not sure it's worth mentioning in other posts though. Not sure what you mean on your post by

Unless anybody knows of a way to get CICS to stop, doing all updates, but not attempt to pass control back to the batch program.

Greg

 

[stevexff]

Greg/Marc

It is worth looking at the addressing modes, as the problem only seems to manifest itself during return processing. Check for 24-bit code linked with the wrong RMODE, incorrect transaction and program definitions, and even calling programs with the wrong number or order of parameters, as this can cause corruption of the LE/370 storage chains.

Try Xpediting it through, and if all else fails have a look at the dump.

 

[MarcLodge]

Greg, Steve,
Didn't realise that interworking was so unknown outside of our organisation. Because it is so well known there I assumed it was well used in the outside world.

I've xpeditered it, and it definitely abends on the CICS RETURN. As far as I can see all the programs in the chain are compiled and linked correctly, and I have been told by a CICS guy up north that the passing of commareas greater than 32K will cause an addressing problem on return. The nuisance is that I can set the breakpoints in Xpediter, kick off the batch job, drop into CICs to pick up the run, and follow it right the way through. All DB2 updates are performed OK, and it is only when it hits the return to the batch program that it all goes wrong.

I have come up with a temporary work around that I'd like to run past you chaps. The batch program calls a CICs stub program passing multiple accounts. For each account, the main application is looped through, and at the end, the stub program recognises that it has been called by a batch CICs program (unique EIBTRMID) and rather than returns, issues a STOP RUN. I've tested this out, and it works. The updates are applied, but the batch job receives an unusual return code.

This is NOT a technique that is going to be run in anywhere other than test, but I just wondered what your thoughts are on this rather dodgy practice.

Marc

 

[stevexff]

Marc

There must be a way around this. Can you confirm the sequence of events that I am assuming?

1. Batch program EXEC CICS LINKs to a CICS program, passing a less-than 32K COMMAREA.
2. Called program calls other modules, using the aforementioned dodgy practices with COMMAREAs.
3. Called program stores a response in the original COMMAREA to return to the batch program
4. EXEC CICS RETURN goes belly-up.

I can see a couple of places where things could go wrong.

At (2), does the sub-program getmain (or have in working storage) the oversize COMMAREA? Or does it just re-use the one passed in from the batch program via linkage, overwriting the end of it?

At (3), I assume you are summarising the oversized COMMAREA from the subprograms in some way, to make it fit into the sub-32k COMMAREA passed by the batch program, otherwise you may be overwriting the end of it.

Steve

 

[MarcLodge]

Steve,
You've got the gist of it correct.
1. Batch program EXEC CICS LINKs to a CICS program, passing a less-than 32K COMMAREA.
2. Called program A EXEC CICS LINKS program B passing OK sized commarea.
3. Called program B EXEC CICS LINKS to program C passing a > 32K commare and a length of 0. Called program C runs and may or may not link to other programs with or >32K and 0, or proper sized commarea and length.
3. Called programs finish OK and chain their way back passing data as required.
4. Called program A receives control back and issues an EXEC CICS RETURN. It abends on this statement