View previous topic :: View next topic
|
Author |
Message |
selvius
New User
Joined: 11 Sep 2004 Posts: 5
|
|
|
|
I need help resolving a s0c4 reason code 10 (segemt translation) abend.
We have been using this assembler program for 20 years. Over the weekend our system people upgraded the system preparing for the new release of zos. Now this 20 year old program is abending.
We do not have the source code for this program. I am hoping it can be fixed by setting some parameter on the linkage editor and relinking it.
We are running on the following environment;
z/OS 01.08.00 JES version JES2
Here is a copy of the message.
Code: |
SYSTEM COMPLETION CODE=0C4 REASON CODE=00000010
TIME=04.10.47 SEQ=02166 CPU=0000 ASID=0089
PSW AT TIME OF ERROR 078D2000 0000C6BA ILC 4 INTC 10
ACTIVE LOAD MODULE ADDRESS=000076F0 OFFSET=00004FCA
NAME=WAAPDSUT |
Any help will be appreciated.
Selvius
Edited: Please use BBcode Tags when You post some code, that's rather readable, Thanks...Anuj |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Sounds like either an AMODE, RMODE or both error condition.
Is this a sub-program called by a HLL (such as COBOL)?
If so and you're passing a parmlist to this sub-program, the COBOL caller needs to be compiled using option DATA(24) to ensure below-the-line addressability for the sub-program.
Assembler programs of 20+ years and older were probably linked as below-the-line, as this was quite common, due to OS/VS COBOL also being linked below-the-line.
HTH....
Bill |
|
Back to top |
|
|
selvius
New User
Joined: 11 Sep 2004 Posts: 5
|
|
|
|
Bill,
This is the main program on the excute statment in the jcl. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
The utility at the heart of Your misfortunes is the WAAPDSUT utility, which EDS wrote and used.
I heard once, but cannot confirm
that it was meant for EDS use only and not left at the customer at the end of the contract
the reasons.... You just found one |
|
Back to top |
|
|
selvius
New User
Joined: 11 Sep 2004 Posts: 5
|
|
|
|
enrico,
Thanks for you comment.
As I understand it, the upgrade to zos may be forcing some rule regarding registers and how storage is used. I was hoping by relinking I could get by.
PS... You sound like you have had some experience with WAAPDSUT?
Selvius |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
No, relinking will not help
check with Your support about the SWA placement for the old system and the new one
( jes2 parmlib startup member )
if in the old one the location was below and in the new one the location is above
then You might have the solution
the parameter can be changed with a command an You can test on the fly |
|
Back to top |
|
|
selvius
New User
Joined: 11 Sep 2004 Posts: 5
|
|
|
|
enrico,
I am checking with our system people to see if the jes2 parm changed.
As an old computer operator I am somewhat familiar with SWA. I know the SWA can be set at the time the initiator is allocated. Can the SWA location be changed through? Is there some other was to change SWA without getting system people involved?
Selvius |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
it can be changed at class level with a $T cmmand
it' s just a guess, worth to try,
20 years ago the programs would do their own control block chasing
and the chase for allocated dnames is usually a good point to start from |
|
Back to top |
|
|
selvius
New User
Joined: 11 Sep 2004 Posts: 5
|
|
|
|
RESOLVED....
I wrote an assembler shell to handle I/O. I then dropped the WAAPDSUT code inside the shell and then assembled as a new program. |
|
Back to top |
|
|
kevinolive
New User
Joined: 04 Dec 2008 Posts: 1 Location: Winston Salem, NC, USA
|
|
|
|
We have the same issue but it wasn't discovered until Wednesday (12/3) and our implementation to z/os 1.9 *was* scheduled for 12/7. The code to this solution would help us meet our year end deadline and get it implemented 12/14.
KevinOlive |
|
Back to top |
|
|
Homer Monts
New User
Joined: 27 Jun 2008 Posts: 4 Location: Columbia, SC
|
|
|
|
selvius
Can you provide the logic you used behind the 'shell' that will make WAAPDSUT work under z/OS 1.9? My company has quite few executions of this program (as I can only imagine with other companies that EDS has 'touched' over the years). I have replaced some with SYNCSORT, SAS, ASM and EZT+ routines but I miss being able to do 'down and ditry' file manipulation with this program. Been using it for 20+ years and hate to have to give it up!!
Thanks for any information you can supply!!
Homer |
|
Back to top |
|
|
Clive Adams
New User
Joined: 04 Jun 2009 Posts: 1 Location: Australia
|
|
|
|
The problem with WAAPDSUT was brought on by the change associated with IBM APAR OA22679. As a result of this, SVC 24 (used to find the devtype) no longer retained the R1 contents on return from the SVC. WAAPDSUT tries to update a value based on R1 after the SVC, and as it has changed and points to non-authorised storage, it gets the S0C4.
IBM have told me via ETR 49238,101,616 that this problem "may" be resolved by PTF UA90499, but they do not have confirmation as yet.
In the mean time I have created a simple zap which fixes the problem. Here it is:
//SUPZAP EXEC PGM=AMASPZAP
//SYSLIB DD DISP=SHR,DSN=LoadlibContainingWaapdsut
//SYSPRINT DD SYSOUT=*
NAME WAAPDSUT WAAPDSUT
VER 4E34 4770,8E9A
REP 4E34 1814,0700
/* |
|
Back to top |
|
|
Cindy Grosse
New User
Joined: 25 Jun 2009 Posts: 1 Location: Minnesota
|
|
|
|
Thank you for the zap.
My load module is dated 3/6/1981 and is x'5800' long.
I had to change the displacements a bit for my version.
VER 4EAC 4770,8EEA
REP 4EAC 1814,0700
This is really helped me out. I feel crippled without WAAPDSUT. |
|
Back to top |
|
|
Homer Monts
New User
Joined: 27 Jun 2008 Posts: 4 Location: Columbia, SC
|
|
|
|
Thanks for the zap! It's nice to have this old utility back up and running!
The version I have has a link date of 91.149 and is X'59D0' in size. The offsets for this version are....
NAME WAAPDSUT WAAPDSUT
VER 507C 4770,8EEA
REP 507C 1814,0700 |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
Hi,
Can you tell me how are you translating the size of WAAPDSUT into the offset.
The size in my system of WAAPDSUT is x'5910'
TIA |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
i am still not sure how to modify this proposed AMASPZAP solution to fit in my case.
Can anyone help me out how to find out the displacement and what to verfy and what to replace that with?
Thanks |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
since it looks like that there are many versions of that program around
the zaps posted were applicable to programs with the quoted sizes.
if the size of Your program is different the zap might work as might not !
if that is the case You will have to rework the zap
using ispf browse the load module and find all the occurences of the instruction "47708EEA"
after You have found it run an AMASPZAP with the DUMPT command to get a
dump of module in order to finf the address and build the proper ZAP |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
thanks enrico ...
i found out the correct ZAP .... and that solved my problem as well
however i do have one final question
Why are we replacing "4770,8EEA" with "1814,0700". Or what is the significance of "1814,0700". |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10886 Location: italy
|
|
|
|
the x'18' op code is a LR ( load register )
the x'07' op code is a no operation ( NOPR to be picky ) |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
thanks a bunch enrico.... |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Quote: |
Your waist-line may be increasing, but you can't blame it on expanding universe |
OK, But; Can i blame it on global warming. . .? |
|
Back to top |
|
|
Homer Monts
New User
Joined: 27 Jun 2008 Posts: 4 Location: Columbia, SC
|
|
|
|
Hi Tia
There was no 'method' I used when I determined the offset for my copy of WAAPDSUT. It was just a shot in the dark. I ran a AMASPZAP DUMPT against the load module and searched the output for 47708E (this was a common in every other zap and there was only one occurance in my case). Then I recorded the offset and content for my search string (including) the byte in the load module after my search string. That's how I came up with the VER string information '4770,8EEA'. Your string should look like
VER (your offset) 4770,8E (next byte from dump).
REP (your offset) 1814,0700
Like I said, it's a shot in the dark. It just happened to work. Let me know whether or not it works. If it does please post your zaps on here and maybe we can cover another of the many copies of this program floating around all over the world.
Good luck!!
Homer |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
dick scherrer wrote: |
Quote: |
Your waist-line may be increasing, but you can't blame it on expanding universe |
OK, But; Can i blame it on global warming. . .? |
lol .... only if you get majority votes in a poll |
|
Back to top |
|
|
er_neo
New User
Joined: 10 Jan 2006 Posts: 18 Location: Indore
|
|
|
|
thanks a ton Homer for the explanation .... i did managed to find the ZAP after doing analysis of previous ZAPs.
Here is mine
NAME WAAPDSUT WAAPDSUT
VER 4FBC 4770,8EEA
REP 4FBC 1814,0700
Size of my load was x'5910'
Thanks,
Bharat Saxena
P.S.
And by the way "tia" was "Thanks In Advance" ... |
|
Back to top |
|
|
Homer Monts
New User
Joined: 27 Jun 2008 Posts: 4 Location: Columbia, SC
|
|
|
|
er_neo
Glad that you got a zap to work. I can only imagine how many versions of this program are floating around out there. I used to have the source code for WAAPDSUT and many old EDS utilities from a company I worked for in the 80's. Somehow I lost them over the years and I sorely wish I had them back. Ripping through the code for these programs taught me so many assembler tricks!! If anyone out there has any links to old EDS code, please let me know!! |
|
Back to top |
|
|
|