Cobol ARSUUPDZ dynamic exit

[rjchavez]

I'm in the process of upgrading CMOD from 8.5 to 9.5.  We have a report specifications archive exit which is written in Cobol, and had been working flawlessly since release 7.1 of CMOD.  After compiling this exit as usual, I'm encountering ABEND U4088 RC=78.  I think it may be due to an LE issue.  I can see in the dump, that arsuupdt and ARSUUPDX are being invoked.  Once the CSVEXPR module is called (dynamic exit facility) I get the ABEND.  I then tried the supplied 'Assember' version of ARSUUPDZ which was being called without issues.

I hate to have to convert this exit to assembler so, can anyone shed some light on this?  Maybe it's the way that the program is compiled and linked.  Would I have to link it as it indicates in the CMOD Readbook for the APKACIF exit? 

Any help will be appreciated.

[Ed_Arnold]

Robert - the same symptoms were reported by the IBM services team going from V9.0 -> V9.5.

LE Level 2 shot a dump for the U4088 RC78 from the IBM services team and had this to say:

This particular subcode '78' on the U4088 is
pretty unique. I've seen a lot of U4088's but that code is a strange
situation... defined as:
"The Get Next Available Byte service (CEEVGTUN) was invoked when the
stack direction was down."
 
CEEVGTUN is the routine to 'get user nab'... for non-xplink or upstacks
which use a NAB (next available byte) to point the next available stack
up the segment...yet the call was done when in an XPLINK (downstack)
routine. Quite odd.

That's just trivia --- that it's an interesting error.

Now, a possible solution:

SARSINST(ARSUUPDT) and SARSINST(ARSUUPDC) provide the same functionality for the arsuupdt exit.  One is in C and one is in COBOL.  Either one calls the ARSUUPDX program.  The arsuupdt we provide is compiled XPLINK.  I think you'll need to use a non-xplink arsuupdt.

If you compile the COBOL ARSUUPDC, that would be a non-xplink arsuupdt.  That non-xplink arsuupdt would call ARSUUPDX with an upstack environment.  SARSINST(ARSUUPDJ) can be used to compile SARSINST(ARSUUPDC) into the exits/arsuupdt.

Be aware that any maintenance IBM ships to arsuupdt will overwrite the exits/arsuupdt - you'll probably want to use ARS_USER_EXITS_DIR= to have it reside somewhere else but it's not mandatory.

This problem was never closed with a firm answer....it just sort of faded away.

One of the last comments was that ARSUUPDX had to be in dataset SARSEXIT in the STEPLIB concatenation ahead of SARSLOAD.

Hope this helps.

Ed

[rjchavez]

Thanks Ed!  That did the trick!  I recompiled the COBOL version ARSUUPDC using ARSUUPDJ and created a new arsuupdt binary.  Unfortunately, I've run into another issue with a dynamic system exit (RSA.RSADUPDT) written several years ago.  The exit works the FIRST time is called but a subsequent call ABENDs with 0C1-01 due to some wild branch and a '0000000' PSW.  I've been reading dumps, traces, and using DISPLAY in the program but I can't find what the problem is. 

I know home-grown exits are beyond the scope of support but, ANY idea here will help.

Thanks again.

[Ed_Arnold]

Just taking a wild guess...do you use ARSCSXIC anywhere in your compiling/linking?

My RMID for that guy is UI25847.  Do you have that on your 9.5 system?

Ed

[rjchavez]

Yes, it's being used in ARSUUPDC which is part of the compile I performed to recreate arsuupdt.  It has the same RMID as yours.

[rjchavez]

I was able to find where the S0C1 was occurring.  After setting a SLIP trap to capture an SVC dump, it was occurring in a subroutine named ODSSGET being called by the ODSXUPDZ; our report specification archive definition exit.  These exit and subroutine(s) were written several years ago for CMOD release 7.1 and have not had any issues upgrading to 8.4 and 8.5.  The ODSSGET routine is called to OPEN, READ, and CLOSE files including the actual report files.  These traditional MVS services were causing the issue (still not sure why).  I changed the exit to use FOPEN, FREAD, and FCLOSE instead.  This corrected the problem.

[cmodpuser]

What version of Cobol have you compiled ARSUUPDZ dynamic Cobol exit with?
We are have a problem open with IBM on Cobol 5.1 exit - dynamic Cobol exit does not function under 5.1 if you use ARSLOAD in batch for instance to load an AFP report.

[Ed_Arnold]

We did all of our testing at 5.1. 

Just a guess, make sure you have all of the following:

http://www-01.ibm.com/support/docview.wss?uid=swg21651898

Ed

[cmodpuser]

Ed,
We are running a Cobol version of ARSUUPDZ that we got from IBM Services. It is compiled to SARSEXIT. When compiled with Cobol 5.1 the batch arsload job fails with S0C4  and CEE3533S. 

 

[Ed_Arnold]

CMODP - you need to contact services.  The exit may need some major massaging.

Ed

[rjchavez]

What version of Cobol have you compiled ARSUUPDZ dynamic Cobol exit with?
We are have a problem open with IBM on Cobol 5.1 exit - dynamic Cobol exit does not function under 5.1 if you use ARSLOAD in batch for instance to load an AFP report.

We run Cobol 4.2

[cmodpuser]

Ed, We don't have a contract with Services anymore.
What is puzzling here, the exit works for ARSLOAD STC but not for ARSLOAD in batch which we use to process AFP documents.

[Ed_Arnold]

Ed, We don't have a contract with Services anymore.
What is puzzling here, the exit works for ARSLOAD STC but not for ARSLOAD in batch which we use to process AFP documents.

If it works, then great.  If not, then you'll need to debug.  Given what others have seen with that exit when crossing the V9.5 boundary I'm surprised it works at all.

Ed

[cmodpuser]

Ed, We are on 8.4.0.
I tried what you suggested to rjchavez before: compile ARSUUPDC using ARSUUPDJ into non-XPLINK arsuupdt, then recompiled our Cobol ARSUUPDZ with Cobol 5.1.
The AFP load still fails with S0C4 and now the arsload from JES2 spool also fails with S0C4 (that was working with Cobol 5.1 ARSUUPDZ). The abend is now happening in UPDTEXIT instead of our customized ARSUUPDZ.

[Ed_Arnold]

No guesses as to what the problem is.  It'll just have to be debugged.

Ed