Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Why moves will not cause S0C7 abend?

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Wed Sep 14, 2011 2:50 pm    Post subject: Why moves will not cause S0C7 abend?
Reply with quote

Hello Experts,

Today I executed a cobol code and I was expecting a S0C7 but it went fine.

Code:

 IDENTIFICATION DIVISION.       
PROGRAM-ID. ROHITPGM.           
ENVIRONMENT DIVISION.           
DATA DIVISION.                 
WORKING-STORAGE SECTION.       
                               
01 WS-A PIC X(4) VALUE '9999'. 
01 WS-B PIC 9(4) COMP-3.       
01 WS-C PIC X(5) VALUE 'ABCDE'.
01 WS-D PIC 9(5) COMP-3.       
01 WS-E PIC X(5) VALUE 'ABC12'.
01 WS-F PIC 9(5) COMP-3.       
01 WS-G PIC 9(5) COMP-3.       
                               
PROCEDURE DIVISION.             
1000-MAIN-PARA.                 
     INITIALIZE WS-G.           
     INITIALIZE WS-B WS-D WS-F.
     MOVE WS-A TO WS-B.         
     DISPLAY "WS-B = "WS-B.     
     MOVE WS-C TO WS-D.         
     DISPLAY "WS-D = "WS-D.     
     MOVE WS-E TO WS-F.         
     DISPLAY "WS-F = "WS-F.     
     IF WS-F = WS-G             
        DISPLAY 'INSIDE IF '   
     ELSE                       
        DISPLAY 'INSIDE ELSE'   
     END-IF.                   
     MOVE 'F4F6F' TO WS-E.     
     MOVE WS-E TO WS-G.         
     DISPLAY 'HELLO'.           
     DISPLAY WS-G.             
1000-MAIN-PARA-EXIT.           
     EXIT.                     
     STOP RUN.                     


The Output :

Code:
 WS-B = 9999   
4EE6C474FFFF4444
062020E099990000
----------------
 WS-D = 12345   
4EE6C474FFFFF444
062040E012345000
----------------
 WS-F = 12312   
4EE6C474FFFFF444
062060E012312000
----------------
 INSIDE ELSE   
4CDECCC4CDEC4444
0952945053250000
----------------
 HELLO         
4CCDDD4444444444
0853360000000000
----------------
 64666         
4FFFFF4444444444
0646660000000000


Thanks !
Back to top
View user's profile Send private message

enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10203
Location: italy

PostPosted: Wed Sep 14, 2011 2:59 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

if You look at the generated assembler code
You will/might find that only CHAR instructions are used ( CLC, MVC and friends)

generally moves will not cause abends ( only arith operations will )
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Wed Sep 14, 2011 3:43 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

Generating the pseudo-assembler is a useful suggestion, then you will see exactly what is happening.

Also, looking at the Cobol manuals should give you an understanding.

Your INITIALIZEs are pointless, as before you do anything with those fields, they are the target of MOVEs, so their previous value is entirely irrelevant.

The 9999 is the easiest. In the MOVE, Cobol treated the field as Zoned Decimal, and you get the 9999 in your comp-3. Unsigned, as your COMP-3 is unsigned, so you get the 9F in the last byte of your COMP-3.

Where you have put alphabetic characters, they will again be treated as Zoned Decimal, the Zone part is ignored for the MOVE, so you get something that turns up as a number, which if you look at it exactly matches the Number part of the EBCDIC code for the letters you have chosen.

If you want to get an Abend, S0C7, you have to be more creative with your data. Try with assorted symbols from your keyboard. You should be able to get S0C7 if you understand valid Zoned Decimal formats (for the move, the Zone is ignored, the Numeric part has to be 0-9 and the Sign has to be A-F. If you arrange differently, you should achieve your S0C7.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Wed Sep 14, 2011 4:14 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

Follow on:

Your program is a good example of how easy it is to get bad data into a system.

Once the alpha characters from a PIC X have been moved to a numeric field, you are lost. They look like ordinary numbers, if, at times, outside the range you expect for a field, if you are lucky.

If you had used the NUMERIC test on your fields, only the first MOVE would have been carried out (assuming you coded the test/move combination correctly).

Just because a field is not NUMERIC, does not mean it will cause an S0C7.
Back to top
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Wed Sep 14, 2011 4:16 pm    Post subject:
Reply with quote

Hi All,

Thanks for the response.

I was able to get the S0C7 after changing the PIC clause of the COMP-3 variables from :

Changed To:

Code:

01 WS-A PIC X(4) VALUE '9999'.
01 WS-B PIC S9(4) COMP-3.     
01 WS-C PIC X(5) VALUE 'ABCDE'.
01 WS-D PIC S9(5) COMP-3.     
01 WS-E PIC X(5) VALUE 'ABC12'.
01 WS-F PIC S9(5) COMP-3.     
01 WS-G PIC S9(5) COMP-3.     


Changed From:
Code:

01 WS-A PIC X(4) VALUE '9999'.   
01 WS-B PIC 9(4) COMP-3.         
01 WS-C PIC X(5) VALUE 'ABCDE'. 
01 WS-D PIC 9(5) COMP-3.         
01 WS-E PIC X(5) VALUE 'ABC12'. 
01 WS-F PIC 9(5) COMP-3.         
01 WS-G PIC 9(5) COMP-3.         
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Wed Sep 14, 2011 10:20 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

And are you happy now?

We're not going to get much further without you showing us the pseudo-assembler generated by the Cobol compiler.

Why? Well, with numeric stuff, the compiler options, especially NUMPROC, mean what is generated can be very different from one option to another.

On top of that, I can't say that I have ever moved a PIC X to a COMP-3.

One day, support or maintenance guys are going to be looking at your programs because of some problem or other. If you want to make things difficult for them, you will have used this sort of MOVE, so that they have to stop and wonder "what the heck does that do"? It might even be you doing the wondering.

If you want to know why there was no S0C7 before and a S0C7 now, post the generated code.

If you want my advice, don't ever do this "for real".
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu Sep 15, 2011 12:51 am    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

This is bugging the heck out of me.

Did you take my advice about removing the intialises? Bad move. I've only now noticed that the cute little IF is using WS-G which, despite my assertion, is not getting set to anything.

That would get you a damn S0C7. My fault, if it is that. Sorry. Plus serves me right to continue thinking about it.

I'm trusting your output.

With the unsigned version, you are getting "correct" numeric values in your comp-3 fields.

I can think of no way, at all, that just changing the sign in this instance would cause a S0C7. All the "signs" are valid, all the "numerics" are valid in your examples.

The generated code, if we ever see it, is probably along the lines of PACK, OR the sign, AND the left-most byte for the 4-digit comp-3. Nothing there to S0C7 even if data bad enough, which it isn't. I think it could do it all "in place".

Would the DISPLAY bomb if you got bad-enough data? I don't think so, but maybe we'll see.

The IF (yes, that one) is the only genuine potential (I think) for S0C7.

Now, with your first example, it really does depend on NUMPROC. With NOPFD (normal default) you would see a CLC generated, as enrico surmised. No S0C7 there. With PFD, you would see a CP - Compare Packed, potential for S0C7.

Except, none of your examples would cause a S0C7.

So, you took my (sloppy) advice. WS-G has an indeterminate value (likely binary zeros). With NOPFD no abend on unsigned fields ("sign-fixing/-rectification" for unsigned fields, CLC generated for compare). With NOPFD for signed fields, CP generated and abend S0C7.

With PFD, no sign-fixing, CP for unsiged fields, abend S0C7. With signed fields, CLC generated, no abend. "Correct" route through IF taken by accident.

I suggest WS-G should have a VALUE ZERO added to the definition. If you want it later to be zero again, what is wrong with MOVE ZERO?

'Nuff.
Back to top
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Thu Sep 15, 2011 9:37 pm    Post subject:
Reply with quote

Hi Bill,

I didn't check the post today morning. I will get back to you tomorrow on this.
One thing I will like to mention is that S0C7 is still not coming.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Thu Sep 15, 2011 10:04 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

Hi,

We will need to know your setting for the NUMPROC compiler option. You should be able to locate this easily on the output listing.

Tell us that, and we can make S0C7. Then you generate the pseudo-assembler.

You'll need some different data. What you have so far just isn't bad enough.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Fri Sep 16, 2011 4:00 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

Rohit,

You might want to consider the "Junk Buster".

If you CALL it with WS-A, the length set to 56, "chunk" set to 8 in the control block then it will display the hext values of all your fields for you*.

You can do the call more than once, if you want before/after(s).


*Assuming it works on a mainframe :-)
Back to top
View user's profile Send private message
rgupta71

Active User


Joined: 21 Jun 2009
Posts: 160
Location: Indore

PostPosted: Tue Sep 27, 2011 12:15 pm    Post subject:
Reply with quote

Hi Bill,

The value for the NUMPROC compiler option is NUMPROC(MIG).Below is the pseudo assembler. I have made 1 line modification to get S0C7 but was not successful.

Code:

IDENTIFICATION DIVISION.                                       
PROGRAM-ID. ROHITPGK.                                           
ENVIRONMENT DIVISION.                                           
DATA DIVISION.                                                 
WORKING-STORAGE SECTION.                                       
                                                               
01 WS-A PIC X(4) VALUE '9999'.     BLW=00000+000         4C     
01 WS-B PIC S9(4) COMP-3.          BLW=00000+008         3P     
01 WS-C PIC X(5) VALUE 'óBóDE'.    BLW=00000+010         5C     
01 WS-D PIC S9(5) COMP-3.          BLW=00000+018         3P     
01 WS-E PIC X(5) VALUE 'ABC12'.    BLW=00000+020         5C     
01 WS-F PIC S9(5) COMP-3.          BLW=00000+028         3P     
01 WS-G PIC S9(5) COMP-3.          BLW=00000+030         3P     
                                                               
PROCEDURE DIVISION.                                             
1000-MAIN-PARA.                                                 
     INITIALIZE WS-G.              13                           
     INITIALIZE WS-B WS-D WS-F.    8 10 12                     
     MOVE WS-A TO WS-B.            7 8                         
     DISPLAY "WS-B = "WS-B.        8                           
     MOVE WS-C TO WS-D.            9 10                         
     DISPLAY "WS-D = "WS-D.        10                           
     MOVE WS-E TO WS-F.            11 12                       
     DISPLAY "WS-F = "WS-F.        12                           
     IF WS-F = WS-G                12 13                       
        DISPLAY 'INSIDE IF '                                   
     ELSE                                                       
        DISPLAY 'INSIDE ELSE'                                   
     END-IF.                                                   
     MOVE 'F4F6F' TO WS-E.         11                           
     MOVE WS-E TO WS-G.            11 13                       
     DISPLAY 'HELLO'.                                           
     DISPLAY WS-G.                 13                           
1000-MAIN-PARA-EXIT.                                           
     EXIT.                                                     
     STOP RUN.       
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Tue Sep 27, 2011 12:33 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

That's not the pseudo-assembler. Check the manual for how to list the code generated by the compiler. All you have here is the inline DMAP and references to the lines where the data-names are generated.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7236

PostPosted: Tue Sep 27, 2011 3:32 pm    Post subject: Reply to: Why S0C7 is not coming?
Reply with quote

What your program demonstrates so far is that if you let bad data get into your system, it can hang around until you do something that requires the use of instruction which will fail on the packed data, will cause an S0C7 - plus, not all data that "looks" bad, is "bad" as far as 370 instructions are concerned.

A PACK instruction will not cause an S0C7, nor will an UNPACK. Even for the DISPLAY statements you are probably just getting an UNPACK to turn it back into something that gives you the output of the DISPLAY.

Even the IF can be unproblematic, but you have a better chance there. Try your funny characters in WS-E.

Any sort of calculation with WS-D, assuming you have chosen your funny characters correctly, will cause a S0C7. All your other values are just not bad enough even to make a calculation get a S0C7. The answer will be nonsense, because the starting-point is nonsense, but you will not get a S0C7.

If you have rubbish inputs from a file external to your system, they can get incorporated into your system and in cases not cause a S0C7, in other cases cause a S0C7. For every numeric field from an external system, use a NUMERIC test before relying on the content of the field, and do whatever the analyst decides you should do if not NUMERIC. Just using the data is not acceptable. If you have a GUARANTEE that the fields will always be numeric, test them anyway and "user" abend if not. Don't let bad data into your system. You have demonstrated what can happen (things just trundle along as "normal"), so don't let it happen to your systems from now on.

For the actual specifics to your question in this example we'd need to see the generated code, but it will still come down to the answer that the instructions used are either not capable of producing a S0C7, or, possibly in the case of the IF, the data you have provided to the field is not capable of producing a S0C7.

You can never just say "that field looks like crap, it will S0C7"(*), because there are many situations where "crap" just won't do that - but it is still crap, so you have to trap-the-crap yourself for all external numeric data.

(*) you can say this only when you know what will and won't cause a S0C7 with particular data and particular instructions (and particular compiler options, which can generate different instructions depending on the value of option chosen).

EDIT: enrico alluded to all this in his response to you initial post.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts IMS BMP program causes 878 system abend Artemk IMS DB/DC 7 Tue Nov 22, 2016 8:26 pm
No new posts abend sort based on count records in ... anatol DFSORT/ICETOOL 5 Mon Oct 17, 2016 10:10 pm
No new posts hot to get details when "EXEC CI... Andi1982 CICS 11 Tue Sep 20, 2016 5:01 pm
No new posts S213-14 ABEND explantion Apurva Mehta JCL & VSAM 5 Thu Jul 07, 2016 10:56 pm
No new posts How to determine where is error in ab... jackzhang75 PL/I & Assembler 13 Fri Apr 15, 2016 2:01 am


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us