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
 

 

S0C7 issued on a CALL statement

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> ABENDS & Debugging
View previous topic :: :: View next topic  
Author Message
RedDevil711

New User


Joined: 04 Jun 2010
Posts: 25
Location: Pune

PostPosted: Sun Feb 01, 2015 3:57 pm    Post subject: S0C7 issued on a CALL statement
Reply with quote

CEE3207S The system detected a data exception (System Completion Code=0C7).
From compile unit MODULE1 at entry point MODULE1 at compile unit
offset +0000F646 at entry offset +0000F646
at address 17142CF6

Now, when i see the compiler listing for this MODULE1 i can see the following assemble instruction
05EF BALR 14,15

Now when i see the main cobol command being issued, it has the following statement
CALL MODULE2 USING PARM

Has anyone faced such an issue before ?
Is it an abend caused when data in PARM may have invalid numeric data.

Thanks for the help
Back to top
View user's profile Send private message

steve-myers

Active User


Joined: 30 Nov 2013
Posts: 461
Location: The Universe

PostPosted: Sun Feb 01, 2015 5:20 pm    Post subject:
Reply with quote

Most of the time the instruction where a failure occurs is the instruction immediately after the actual failed instruction. A BALR 14,15 instruction cannot, essentially by definition, get an S0C7. The only major exceptions are many S0C4 errors where the instruction that failed failed because of address issues detected by the paging hardware.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Sun Feb 01, 2015 5:45 pm    Post subject: Reply to: SOC7 issued on a CALL statement
Reply with quote

Language Environment is pointing at the offset of the actual failing instruction.

You have taken that offset, and located the generated assembler which matches the offset.

As Steve Myers has pointed out, it is impossible, totally impossible, for the instruction you show to have given a data-exception (S0C7). If you have a look at "Storage dump near condition, beginning at location:" you can see, and may get a big clue.

Two likelihoods: you are not looking at the correct listing for the program that is running; your program code has been overwritten by your program, or a program which CALLs it, or a program it CALLs, or something else which is CALLed.
Back to top
View user's profile Send private message
RedDevil711

New User


Joined: 04 Jun 2010
Posts: 25
Location: Pune

PostPosted: Sun Feb 01, 2015 7:27 pm    Post subject:
Reply with quote

Hi Bill and Steve,
Even my thinking is the same that the statement pointed by the generated offset cannot cause this issue.
I am looking at two points now.
One, the parm which is passed to the linked module, has corrupt data or second like steve said, there is an IF condition just after this call and it has a condition placed on a COMP field.
Problem at my firm no xpeditor, have to use display. icon_smile.gif
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Sun Feb 01, 2015 7:52 pm    Post subject: Reply to: SOC7 issued on a CALL statement
Reply with quote

No. LE is giving you the displacement of the instruction that failed, it is not giving you the PSW which contains the Next Sequential Instruction (NSI).

If you paste the "Storage dump near condition, beginning at location:" line we may spot something.

A COMP field will not cause a S0C7. Only a Zoned- or Packed-Decimal (COMP-3).

If you bounce a load of zeros over program code, an F0 is going to be interpreted as an instruction at some point and it is a "decimal" instruction, which can give you a S0C7. Other overwritten values can give S0C7 unexpectedly as well.

I repeat. You either have the wrong listing, or your executable code has been overwritten.

The problem with putting DISPLAY in is that sometimes this will cause the overwriting to be done somewhere else, and you may not get an abend at all. Then you take the DISPLAYs out, and it abends again :-)

You can have the same effect using a debugger if the debugging code is embedded in the code from your program.

You need to confirm you are executing the correct program for the listing you are looking at.

If you are, are you using SSRANGE in that program and all others in the run? If yes, then check the USINGs on CALLs and PROCEDURE DIVISION that you have the correct items in the correct order. Check also the lengths of data in the LINKAGE SECTIONs of the programs to the lengths of the data "passed".

You can sometimes short-circuit this by "what has changed recently" to get an idea where best to start.

If you can read a dump, produce a dump beyond what LE gives you. Everything you need to find out what has happened at that point is there. If it is overwriting, finding out when it happened can be more problematic.

But first, confirm that the executing program is the exact one that matches your listing you have used to track the offset provided by LE to an instruction in the generated pseudo-assembler from the COBOL program.
Back to top
View user's profile Send private message
RedDevil711

New User


Joined: 04 Jun 2010
Posts: 25
Location: Pune

PostPosted: Mon Feb 02, 2015 1:38 pm    Post subject:
Reply with quote

Hi Bill,
Here is the storage dump near the abend
Code:
Storage dump near condition, beginning at location: 171D96A0
  +000000 171D96A0  C2F5F5F3 F3F0C240 5C5C5C5C C2F5F5F1  F0F14040 5C5C5C5C C2F5F4F1 F2F04040
!B55330B ****B55101  ****B54120  !



Code:
Parameters, Registers, and Variables for Active Routines:
  CEEHDSP (DSA address 00090628):
    UPSTACK DSA
    Saved Registers:
      GPR0..... 00090DD0  GPR1..... 00090A84  GPR2..... 00092268  GPR3..... 00090B14
      GPR4..... 16F044D8  GPR5..... 0007E038  GPR6..... 16E3D410  GPR7..... 00090F20
      GPR8..... 96F033CA  GPR9..... 00092626  GPR10.... 00091627  GPR11.... 16EFF6B8
      GPR12.... 00088B88  GPR13.... 00090628  GPR14.... 8007F0EA  GPR15.... 96F2C9E8
GPREG STORAGE:
  Storage around GPR0 (00090DD0)
    -0020 00090DB0  170D6640 00000CB1 41C3C5C5 00000000  00030C87 59C3C5C5  !... .....CEE.......g.CEE.......Y!
    +0000 00090DD0  C3969584 89A38996 95409799 968385A2  A2899587 409985A2  !Condition processing resulted in!
    +0020 00090DF0  40A38885 40A49588 81958493 85844083  96958489 A3899695  ! the unhandled condition.       !
  Storage around GPR1 (00090A84)
    -0020 00090A64  40404040 40404040 40404040 40404040  40404040 40404040  !                                !
    +0000 00090A84  00090DD0 00090E20 00092268 00092268  00090B10 00091030  !...........................8....!
    +0020 00090AA4  00000000 00000000 000AF710 172C0938  00090F20 172EE860  !..........7...........Y-.0......!
  Storage around GPR2 (00092268)
    -0020 00092248  F6000000 00000008 F1F7F1F4 F2C3C6F6  00000009 4EF0F0F0
    +0000 00092268  00000000 00000000 00000000 00000000  00000000 00000000
    +0020 00092288 - +00003F 000922A7             same as above
  Storage around GPR3 (00090B14)
    -0020 00090AF4  0008E018 00000004 172ED038 0000D758  00089630 16E3D410
    +0000 00090B14  00000000 00000003 00090C50 00000000  16F0336A 00000000
    +0020 00090B34  00000000 0007E038 0008EDF8 0008EC18  172EE856 172C0938
  Storage around GPR4 (16F044D8)
    -0020 16F044B8  D4C41733 503020E8 5870D4E0 5030701C  98E1D220 9835D230
    +0000 16F044D8  000030F8 000030F8 D200D5AD 8002D200  AEE92002 D200D5AD



Listing for the same from LIST :
Code:
  020832  CALL
   00F5FA  4100 76B0               LA    0,1712(0,7)             I105-PA
   00F5FE  5000 32A8               ST    0,680(0,3)              TS2=0
   00F602  58E0 9190               L     14,400(0,9)             BLL=4
   00F606  4100 E000               LA    0,0(0,14)               Z003-PA
   00F60A  5000 32AC               ST    0,684(0,3)              TS2=4
   00F60E  9680 32AC               OI    684(3),X'80'            TS2=4
   00F612  D207 32B0 5501          MVC   688(8,3),1281(5)        TS2=8
   00F618  58F0 C038               L     15,56(0,12)             CBL=2
   00F61C  DC07 32B0 FFB9          TR    688(8,3),4025(15)       TS2=8
   00F622  D203 32B8 5984          MVC   696(4,3),2436(5)        TS2=16
   00F628  4100 32B0               LA    0,688(0,3)              TS2=8
   00F62C  4120 32A8               LA    2,680(0,3)              TS2=0
   00F630  5000 32BC               ST    0,700(0,3)              TS2=20
   00F634  5020 32C0               ST    2,704(0,3)              TS2=24
   00F638  4110 32B8               LA    1,696(0,3)              TS2=16
   00F63C  182E                    LR    2,14
   00F63E  5830 905C               L     3,92(0,9)               TGTFIXD
   00F642  58F0 3100               L     15,256(0,3)             V(IGZCF
   00F646  05EF                    BALR  14,15
   00F648  5810 9128               L     1,296(0,9)              BL=1
   00F64C  40F0 1008               STH   15,8(0,1)               RETURN-
020833  IF
   00F650  5800 20BA               L     0,186(0,2)              Z003-RE
   00F654  4900 A498               CH    0,1176(0,10)            PGMLIT
   00F658  4780 B406               BC    8,1030(0,11)            GN=438(
Back to top
View user's profile Send private message
Nic Clouston

Global Moderator


Joined: 10 May 2007
Posts: 1715
Location: UK

PostPosted: Mon Feb 02, 2015 2:56 pm    Post subject:
Reply with quote

You should know by now to use code tags when posting data like this. I have 'coded' it for you. Do it yourself in future.
Back to top
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Mon Feb 02, 2015 3:10 pm    Post subject: Reply to: SOC7 issued on a CALL statement
Reply with quote

Code:
C2F5F5F3 F3F0C240 5C5C5C5C C2F5F5F1  F0F14040 5C5C5C5C C2F5F4F1 F2F04040


Definite Code-overwrite. Storage which has been stepped upon. Here is your executable code, in character format:

Code:
B55330B ****B5191  ****B541


Whatever that is (which you may recognize) it isn't program-code. There is plenty there to cause a "decimal" instruction to be executed.

So, compiler option SSRANGE can tell you (by causing an abend) if you go outside the bounds of a table. Check the CALL USING and PROCEDURE DIVISION USING as already suggested, order and length of the items.

A tip for knowing exactly what program is running, which compile output it was, is:

Code:
01  W-WHEN-COMPILED PIC X(8)BX(8).

...

First time into the program:

MOVE WHEN-COMPILED TO W-WHEN-COMPILED
DISPLAY
        "[Your-program-name] compiled on "
        W-WHEN-COMPILED


The output will exactly match the date/time on the compile listing. If feared that the program will still be running in the 22nd Century, use FUNCTION ( WHEN-COMPILED ) instead.

Edit: Just noticed I didn't need to do the translation :-)
Back to top
View user's profile Send private message
RedDevil711

New User


Joined: 04 Jun 2010
Posts: 25
Location: Pune

PostPosted: Mon Feb 02, 2015 7:44 pm    Post subject:
Reply with quote

Hi Bill,
Thanks a lot. Got the issue.
There was an array used at the end of the program which was out of bounds for a previous input record icon_sad.gif.

Can you please guide me to the books/links where i can learn analysing CEEDUMP like this, it will help me a bit, adding display's and debugging is quite a pain icon_sad.gif
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 -> ABENDS & Debugging All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts -913/-911 Deadlock during UPDATE stat... NoSleep319 DB2 5 Fri Nov 18, 2016 12:37 am
No new posts Cobol EZASOKET call to SETSOCKOPT fails Andi1982 COBOL Programming 6 Thu Oct 06, 2016 7:12 pm
No new posts Strange EXEC function call in z/VM Willy Jensen CLIST & REXX 3 Wed Oct 05, 2016 2:07 pm
No new posts COBOL DB2 - CALL statement - high CPU... TS70363 DB2 15 Sun Sep 11, 2016 6:07 am
No new posts Converting NULL column into NOT NULL ... Raghu navaikulam DB2 5 Sat Aug 06, 2016 3:45 pm


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