OnDemand User Group
Support Forums => z/OS Server => Topic started by: rjchavez on September 19, 2015, 08:01:55 AM
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
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 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 (http://www-01.ibm.com/support/docview.wss?uid=swg21651898)
Ed
-
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.
-
CMODP - you need to contact services. The exit may need some major massaging.
Ed
-
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
-
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, 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
-
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.
-
No guesses as to what the problem is. It'll just have to be debugged.
Ed
-
For anyone following this thread, the final disposition of the S0C4 is in the following Technote:
http://www-01.ibm.com/support/docview.wss?uid=swg21972988
Ed
-
I have been struggling to get this resolved and am hoping someone has been there and done that.
We are going from V9.0 to V9.5, using the ODSXUPDZ in V9.0 is working just fine with the ARS.RSADUPDT exit.
I compiled the ARSUUPDC using the supplied ARSUUPDJ JCL and deployed to the /bin/exits
I made minor changes to ARSUUPDC to display/debug some info and update a value to confirm it passes the updates out to the MVS exit RSA.ARSUUPDT.
ARSUUPDC - in OMVS
working storage
copy arsuupda.
…
call ARSZUXPL-MODFCNP using by reference ARSUUPDA
returning rc
My understanding is this call to ARSZUXPL-MODFCNP triggers the MVS exit RSA.ARSUUPDT
ODSXUPDZ - MVS
Linkage Section.
copy ARSUUPDA.
…
Procedure Division using
by reference ARSUUPDA.
The logging/debug of the MVS exit shows that the ARSUUPDA values are received and then updated successfully.
However the OMVS Exit ARSUUPDA logging/debug shows it doesn’t see the values modified by MVS exit.
In MVS – Display the results
Code
String ' ARSUUPDA-UPDATE = ' Pic-X8-2-98
' / X''' Pic-X200(1:8) ''''
delimited by size into SYSOUTZ-DATA.
Results
ARSUUPDA-UPDATE = 00000001 / X'00000001'
In OMVS
Display "UPDATE Value: " ARSUUPDA-UPDATE upon syspunch
Results
UPDATE Value: 000000000 UPDTEXIT
Is there some other step I need to turn on to ensure the values are read correctly in ARSUUPDC after ODSXUPDZ.
I will admit I am not an experienced COBOL programmer so if there is something you think might help, please suggest anything