Strange Abend 2

[claudeb]

Hello,
I get an abend after this :
MOVE ZERO TO C-AMOUNT.
This field is defined as:
C-AMOUNT PIC S9(9)V99 COMP-3.
i tried to do a display just before this instruction and it worked. The problem is this instruction but i don't see why.
Thanks for giving me a hint to explore.

 

[slade]

Hi Claude,

Also put a display AFTER the move. If you don't get O/P THEN you know that the move caused the ABEND. With only the one display you only know that the ABEND occurred SOMWHERE after the MOVE. I can't see the MOVE causing the abend if all is as you state. The MOVE clears the receiving field before the zero is ADDED to it, so what's in the field is irrelevant. I'll go out on a limb and say that's not where the abend is occurring.

Regards, Jack.

 

[slade]

Correction:

"SOMWHERE after the MOVE" should be:
"SOMWHERE after the DISPLAY"

Jack

 

[claudeb]

Hello Slade,
I could find the source of this problem.
Program A calls program B using global variables X Y and Z.
In the old version (production environment) only X and Y were used. So , we had an old program A using X and Y, and a new program B looking for X, Y and Z. We have only the old object but not the source. I had the same abend in the test environment (i copied production and rerun the job). but when i put the new program B too, every thing worked fine.i had no reason to put it in; it was just to trace the displays i put in the programs. (don't give me any credit)
the message i got when it abended:
CEE3204S THE SYSTEM DETECTED A PROTECTION EXCEPTION
I looked up the meaning of CEE3204S

Explanation: your program attempted to access a storage location to which it was not authorized.
Programmer Response: Check your application for these common errors:
 Using the wrong AMODE to reference storage
 Trying to use a pointer that has not been set
 Trying to store data into storage reserved for the system
 Using an invalid index to an array
I put all this because it might help someone in the future.
Thanks a lot

 

[Crox]

Usually this situation causes a 0C4 abend.

In fact when a MOVE ZERO TO .... causes an abend, it has to be exactly this reason: trying to access storage that is not yours.

Depending on your compile-parameters it can also happen when you use an out-of-range subscriptor for a table.

Also when the working-storage field of the calling program is smaller than the linkage section field of the called program and the called program uses a part of it that is not defined in the calling program.... but(!).... in the mainframe environment if you have a called module that goes behind the parm-field of the calling program and if there is enough working-storage defined behind that parm-field to support that, the called module can destroy the values of the working-storage of the calling program.

It can be very difficult to solve those kinds of problems. For example if the parm-field is a small field, behind it there is a table and after that the subscriptor fields. Suppose the called program changes the value of the subscriptor fields which causes also an abend, it can be difficult to understand that the call to the called program has anything to do with the strange value of the subscriptor field.

Therefore it is smart to use the rules of defensive programming. One of those rules is better to define the parms for the called programs at the end of your working-storage. One other is to put subscriptors in front of a table and put one filler between with the size of one element because subscriptor 0 without subscript-range check (ssrange) will cause to access the area just in front of a table.....

etc. etc.

I hope somebody finds this helpful.

Regards,

Crox

 

[claudeb]

wow !
what do you mean by :
[but(!).... in the mainframe environment if you have a called module that goes behind the parm-field of the calling program and if there is enough working-storage defined behind that parm-field to support that, the called module can destroy the values of the working-storage of the calling program.]

could you give me an example.thanks a lot crox.

 

[slade]

Hi Claude,

Here's what happens:

Caller pgm.

01 put-ans-here pic x.
01 other-ws-data pix x.

move zero to other ws-data
call sub-pgm using put-ans-here

Called pgm.

linkage sect.

01 his-ans pic xx.
(Notice that he defined the field as 2 bytes)

move 'AB' to his-ans
goback

Upon return from the called pgm the caller's other-ws-data will contain the B of AB, not 0.

Jack

 

[Crox]

exactly. It can even be much more complicated!

 

[claudeb]

you said it can be more complicated !!!!
i can't wait for that .
Thanks a lot for taking the time to explain.

 

[slade]

Hi Claude,

P.S. to my prev post. What I stated is probably the WORST thing that can happen, because there is no abend. That B may be used to giive misleading O/P or, if it's a switch, cause the caller pgm to take the wrong path.

On the otherhand, if ws-other-data was defined as PIC 9 and when it's used, an abend my result in some situations.

Regarding what Crox said about subscripted tables:

That's one of the disadvantages of subs vs indexes. If the index goes beyond the limit of the table a 0C4 results (I think) while a sub may corrupt the data in WS or even the PDiv (I think) giving an 0C1(maybe) later on when that part of the pgm is executed. If put-ans-here is the last item in WS, you'll get an 0C4 if you're moving data. That's just a partial list of what can happen. As Crox said, it gets complicated.

If anyone can confirm or debunk those "I think"s and "maybe"s I'd appreciate it.

Regards, Jack.

 

[Crox]

Hi,

as far as I know it is not possible in IBM-mainframe COBOL to overwrite working-storage and damage a procedure/instruction-area but I agree you can get a S0C1 of it... perhaps some FD stuff can be touched.

I know that some programmers in old-basic environments did just that: write some machine-code in storage and activate it with a kind of call.

To Claudeb: you don't want to experience those complex problems because it can be extremely difficult to solve them.

In Slade's example if the field other-ws-data is important to decide what kind of processing has to be done and the calling program continues to do the wrong things, it can be difficult to determine that all the problems are only caused by an unexpected change of other-ws-data by the called module. You can imagine that people don't expect this to happen and are looking for other things.

If you have subscriptors which are overwritten in this way, the wrong element of a table will be processed or some elements will not be processed at all. If the program has run and your conclusion is that some elements of the table are not processed, you will probably search for wrong logic in increasing the subscriptor ... but you will never find it in the calling program because there is nothing wrong there.....

I saw people spending more than a week together trying to solve problems like this. It is very convenient to be asked to help them, knowing for sure that you shouldn't look for all the normal things - because they did those kind of searching - and that their main problem is that they are having difficulties to defeat the original assumptions while you get the credits for solving the problem in a short time. Looking for unmeant changes of important fields or even creating defensive working-storage area's can help you.

If a good program works ok for a long time and suddenly it is not functioning anymore, look if some of the called modules are changed.

By the way, it can be convenient to define an extra filler in the interface area because if called modules are used by more and more programs and if you want to change something, it is convenient not to have to change all the calling programs.

There are lots of books written about COBOL and how to develop programs but you never see one that tells you about all the problems and how to prevent them, what defensive programming is all about, what good mainainable concepts are, things like that but also about all the dirty tricks you can do if you are in a hurry and you want to force things to work, translated directly from Dutch to English you can call them crowbar techniques... But I don't know the right word for that.... Do you?

If a sponsor stands up to finance this new book....

I hope this is helpful.

With Friendly Regards,

Crox

 

[slade]

Hi Crox,

If I recall my Principals of Operation correctly, any area in your "protect key" can be changed, including the Procedure Div (that's how you can get an 0C1, by overlaying an Op Code or 2). Generally, "protect keys" are associated to initiators, but thats an old concept. Maybe, with the advent of Virtual Storage things have changed.

Regards, Jack.

 

[Crox]

Hi Jack,

Perhaps you can try to implement the execution of some machine instructions this way...

Some great kind of hacking....

I am not an IBM mainframe assembler programmer so it is difficult to know if this is possible. I guess at the MVSHELP site people can give the answer at once. I am glad that I had never an abend in which the instructions were changed by accident in this way. Claudeb is interested...

Regards,

Crox

 

[slade]

Hi Crox,

That's a good idea. I'll ask them.

Recards, Jack.

 

[Crox]

The answer on MVS is at:

http://mvshelp.com/ubb/Forum1/HTML/000907.html

I think the answer about the REUS option makes sense! In on-line environments where you make your program REUSABLE, you will not overwrite instructions, because your working-storage is separated from the rest.

I hope everybody is satisfied now...

Greetings,

Crox

 

[RonaldB]

Gentlemen,

i troubleshooted a program a while ago (IBM mainframe environment) where two tables were defined in WS right after eachother.
The program produced unexpected results, but didn't abend. It took me quite a while to figure out that data was read from the first table, and because the subscript went out of range, after that data was read from the NEXT table!!! They so happened to contain exactly the same type of identifier, with the same sort of contents, but with a very different meaning...
Just a little story to emphasize that STRANGE things can happen...

Regards,
Ronald.

 

[claudeb]

i must admit it is a little bit over my head. i need time to chew and digest the whole thing. thanks to all.