Appears to be tough day with s0c7 in easytrieve

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

We are using easytrieve 6.4 version.Today a a mutistep job went down in production while processing end of quarter tape input file in one step.that step finished up with 16.Further SYSPRINT of that step showed me up following

1031 *******A006 PROGRAM INTERRUPT - CODE 7 (DATA EXCP)

.INTERRUPT OCCURRED AT 0B64 BLOCK 4 FROM EP CA-EASYTRIEVE PLUS 6.4 0311- 1/27/

.INSTRUCTION AT 3B537B94 IS F8F053407018

.FIRST OPERAND ADDRESS 3B5323B0 CONTENTS 0000000000000000000000000000001C

.SECOND OPERAND ADDRESS 3B5300C0 CONTENTS F7

.PSW+4 AT INTERRUPT BB537B9A

Here both operand make me bit curious as the 1031 line in the code's compile listing is var1=var1+1 but from operand I beleive it is trying to add a number to a character.This makes me to beleive that problem is somewhere else in the code.I then searched the occurs clause in code expecting that there could be a table and I saw the module has a table defined with 9999 occurs clause.I then looked back into the last quarter run of the job to see how many records were there last time and see that this time it has got around 900000 more records to process.Which makes me to beleive that there could be table occurs clause problem.This made me nervous for upto what limit I should expand that occur is not known to me.I mean how I should be doing that maths.Or even there could be some other issue also,I have no clue of what this program does and the only person who knows this program seems to be on vaccation.I got the job restarted from next step as I see problem causing step creates some reports.That I can get generated offline for business review after fixing the issue.

I ran that step offline with using PMAP and DMAP tried STATE and FLOW also to pin point the line but it appears that definately its problem somewhere with the occurs.When I ran the job offline it finished up with soc4 but sysprint showed it had s0c7 for the same line 1031.

but with soc4 I got SYSUDUMP also which I did not got when the job abebnded in production.I am wondering for how I should correctly approach this issue.

I see there are 18 crore of records in the 10 concatenated tape input driver file which this module is using.One solution might be expanding the occurs clause but how to do that mathmetics I do not know or might be there could be some other solution possible but as I mentioned this step creates important finanlcial report so without exactly knowing the module purpose I do not want to get it modified and getting some reports created which might have produce some incorrect information somewhere.

Please suggest or let me know if some additinal information is needed.

enrico-sorichetti · Posted: Wed Apr 21, 2010 10:28 pm

nothing can be done until You understand the program logic
ask the powers of Your organizations for the docs of the program in question!

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

that is going to make my day more tougher for getting something which functionally can explain this 8000 ilnes of code.Hm......

Robert Sample · Posted: Wed Apr 21, 2010 10:59 pm

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

Its my mistake of missing not providing the datatype of the var1 its like

VAR1 S 9 N VALUE 0 MASK 'ZZZ,ZZZ,ZZ9'

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

adding up I see this var1 is merely a count field like a variable which should be increased by 1 based on certian condition getting tru with IF condition.

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

I randomly increased the occurs to 15000 from 9999 and now sysprint shows me up different line as follows

1049 *******A006 PROGRAM INTERRUPT - CODE 7 (DATA EXCP)

INTERRUPT OCCURRED AT 0E2C BLOCK 4 FROM EP CA-EASYTRIEVE PLUS 6.4 0311- 4/21/1

INSTRUCTION AT 3B598E5C IS F89944F85F06
FIRST OPERAND ADDRESS 3B503520 CONTENTS 000032003C102079549C
SECOND OPERAND ADDRESS 3B594F66 CONTENTS 04403623000000005010

PSW+4 AT INTERRUPT BB598E62

This time job completed with soc4 and 1049 line in code I see is referring to the assignment of value from table which I changed to 15000 from 9999.it really confusing me.......it takes around 10-15 minutes wall time in getting the program the error.....also I tested this module in with test region file its not failing neither has failed in production ever since installed...also I see the growth in number of records every quarter has been constantly increasing......

Bill O'Boyle · Posted: Wed Apr 21, 2010 11:37 pm

The last byte of your second operand is missing a sign-nibble and a S0C7 is raised.

The instruction object code X'F89944F85F06' indicates -

01) It's ZAP instruction - OP Code F8
02) Both operands are 10-bytes in length (X'99')
03) Operand 1 displacement/base - X'4F8' off register 4
04) Operand 2 displacement/base - X'F06' off register 5

The data at X'F06' off register 5 is not valid packed-decimal.

It's good that EasyTrieve uses a ZAP, because if they used an MVC, the data at the Operand 1 address would be invalid after the MVC completed. You won't get a S0C7 with an MVC.

It's better to find it early (ZAP) than to find it later (MVC), when damage could have already be done, making restoration more difficult.

Bill

William Thompson · Posted: Thu Apr 22, 2010 12:23 am

Put the occurs back to the original value and display/print the var1 prior to the add (temporally omit the mask).
Hex on the displayed value and let us know what it is.

It looks like garbage is in the var1, was it initialized prior to the increment?

Altering the occurs and getting totally different values in the first and second operands of the ZAP may mean that a redefine was not accounted for in your working storage - if it was, the same values for the ZAP and the data would be the same.

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

I put occurs back at 9999 and used diisplay for var1,the var1 at the line where this s0c7 was pointing was in before break para so actually the display were going to the data set where I diverted the report.I see it has got hex like

William Thompson · Posted: Thu Apr 22, 2010 10:30 am

PeterHolland · Posted: Thu Apr 22, 2010 1:47 pm

I didnt see the "occurs" definition statement(s) till now, so I wonder
if that has anything to do with this problem. My guess is that this
problem occurs in a report section.
Added some info about "S" fields, maybe you have to look in that
direction.

Easytrieve Reference Guide

Static Working Storage :

Fields contained in S storage exhibit unique properties during report processing.
S fields are stored in a static working storage area and are not copied onto report
work files. All references to S fields occur at the time the report is actually
formatted and printed. Remember, the format and print operation can occur at
one of two different times; either immediately upon execution of the PRINT
statement or after the processing of work files. With this in mind, you should use
S storage fields for:
Temporary work fields for report procedures
Line annotations controlled from report procedures
Grand total values from which you can calculate percentages.

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

Hello Peter I will be looking into the pointer you provided.

William,
VAR1 is defined in working storage in the beginning of program structure like
VAR1 S 9 N VALUE 0 MASK 'ZZZ,ZZZ,ZZ9'
So I beleive its being initialized with 0 in the very beginning.
Thanks all again for your time.....

raghavmcs · Active User Joined: 14 Jul 2005 Posts: 105

I was able to get this resolved after multiple look and test of the program it appears that there were two problems with this module,probably should fall in regression bug ot may be something else
a)First the occurs was being overrun
b)additionally the subscript variable was also being used,it never abended in rpoduction since last more than 2years..
but anyhow after fixing these two the module produced good reports which business has reviwed and agreed.
Thanks all for your suggestion.