MVSFORUMS.com Forum Index MVSFORUMS.com
A Community of and for MVS Professionals
 
 FAQFAQ   SearchSearch   Quick Manuals   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

DISPLAY makes difference with SOC4?

 
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming
View previous topic :: View next topic  
Author Message
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Fri Dec 12, 2003 10:00 am    Post subject: DISPLAY makes difference with SOC4? Reply with quote

Hi,
Im running PROG1 which has got 19 subroutines. Basically this is to migration to LE370. In LE370, when I run PROG1, it abends with SOC4. I found the program which abends, when i give DISPLAY statement to find location, it executes successfully. I removed DISPLAY statement one by one to find which DISPLAY statement makes it successful and found one. I haven't found any issue like this so far. Could you tell me if there anything clicks?

Thanks
Chandru
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Fri Dec 12, 2003 10:44 am    Post subject: Reply with quote

Chandru,

I don't think DISPLAY statements has got anything to do with your abend.can you please post the exact error message(starts CEEXXXX). I beleive that it has something to do with the compile options of the subroutine.

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Fri Dec 12, 2003 11:18 am    Post subject: Reply with quote

Kolusu,
I also think, DISPLAY statement does nothing. But I tried all the way to find solution, but couldn't. When run thru xpediter, it works fine.

I'm getting
CEE3204S The system detected a protection exception (System
Completion Code=0C4).

--Chandru
Back to top
View user's profile Send private message
hari_uss
Beginner


Joined: 19 Dec 2002
Posts: 78
Topics: 6
Location: Trivandrum, India

PostPosted: Fri Dec 12, 2003 2:12 pm    Post subject: Reply with quote

Chandru,

May be you have unequal number of parameters between the main program and subprograms. That is, you have the total length of communication area same, but number of parameters coded in CALL USING in main program and LINKAGE SECTION of subprogram are different? If that is the case, try to make them same (you might want to replace some FILLERs in linkage section of subprogram with variables like LK-FILLER1, LK-FILLER2 etc).

Not sure whether it will work, but may be worth a try.

Hari.
Back to top
View user's profile Send private message Send e-mail
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Fri Dec 12, 2003 2:35 pm    Post subject: Reply with quote

chandroo,
This is just a wild guess, but worth a try. Before you added any of display statements , the pgm might be pulling the subroutine from an OLD loadlib. Now once you add the display statements and compiled it , it is picking the latest version and there by you are not having any problem.The old loadlib must be compiled with a different AMODE

So check your steplib concatenation and check if the above mentioned is true.

Code:


CEE3204S The system detected a protection exception (System Completion 
       Code=0C4).                                                       


Baiscally you get that message when your program attempted to access a storage location to which it was not authorized. some of the common appliction errors are :

  • 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


So first check all the subroutines AMODE.Make sure that all of them are either 24 or 31.

Also as hari mentioned check if the subroutine was changed recently. If it was indeed changed then check the linkage section.

Hope this helps...

cheers

kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
vani
Beginner


Joined: 28 May 2003
Posts: 51
Topics: 30

PostPosted: Sun Dec 14, 2003 11:18 pm    Post subject: Reply with quote

Hi,

I too am having the same problem of CEEDUMP.

I have 8 subroutines and a main program. This is a C-Db2 application.
wherein I will only precompile and compile all the subroutines and linkedit all the 8 subroutines while compiling the main. Then do a bind and run the application.

Its throwing the below error, please help it out.

CEE3204S The system detected a protection exception (System Completion Code=0C4)
From entry point IBuffer::removeRef() at statement 386 at compile unit
+00000058 at address 0D968610.
Back to top
View user's profile Send private message
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Tue Jan 06, 2004 2:59 pm    Post subject: Reply with quote

Kolusu/Hari,
Sorry for the delayed response. I tried all possible ways as mentioned above, but no change. Now I have found other solution to fix SOC4.
Currently DD statement for output file is-
//TAPEOD DD DUMMY.
When I change add DCB parameter for this DD statement as given below works fine.
//TAPEOD DD DUMMY,
// RECFM=VB,LRECL=63,BLKSIZE=23476

Could you please tell why this difference is? I thought when we say DUMMY, there will not be any IO operation take place, so it doesn't matter to code DCB parameters, but it does matter. Could you please explain and send me link for this issue.
Expecting your valuable reply.

Thanks
Chandru
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Tue Jan 06, 2004 3:27 pm    Post subject: Reply with quote

Chandru,

Can you post the FD entry for the file TAPEOD?

Thanks,

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Tue Jan 06, 2004 3:39 pm    Post subject: Reply with quote

Actually we have IO handler assembler routine for all IO processing, so please find all of them.
File description for TAPEOD:
Code:

FD    OPC9704-FILE                                   
      BLOCK CONTAINS 0 RECORDS                       
      LABEL RECORDS ARE STANDARD                     
      RECORDING MODE IS V                           
      RECORD VARYING FROM 47 TO 65 CHARACTERS       
        DEPENDING ON TAPEOD-RLH                     
      DATA RECORDS ARE TAPEOD-MAX-REC TAPEOD-MIN-REC.
01    TAPEOD-MAX-REC.                               
  05   FILLER                  PIC X(63).           
01    TAPEOD-MIN-REC.                               
  05  FILLER                  PIC X(47).         
 

Values passed to open TAPEOD:
Code:

 MOVE 63 TO IOCA-LOGICAL-REC-LENGTH.               
 MOVE 'OPEN    ' TO IOCA-IO-REQUEST-TYPE.         
 MOVE 'O' TO IOCA-MODE-FOR-OPEN.                   
 MOVE 'TAPEOD' TO IOCA-DDNAME.                     
 MOVE 'DQF-OPC97-TAPEOD' TO IOCA-LOGICAL-RECORD-ID.
 CALL 'IOHSTUB' USING IOCA IOWA-RECORD.           
 IF IOCA-IOH-ERROR-CODE NOT = '000'               
      PERFORM 0805-IOH-OPEN-ERROR.           

Values passed to write TAPEOD:
Code:

P-WRITE-TOD.                                             
    IF MISC-BULK-SW-PRO = ALL '1'                       
        GO TO P-WRITE-TOD-EXIT.                         
    MOVE 'WRITE' TO IOCA-IO-REQUEST-TYPE.               
    MOVE 'DQF-OPC97-TAPEOD' TO IOCA-LOGICAL-RECORD-ID.   
    MOVE 'S' TO IOCA-MODE-FOR-ACCESS.                   
    MOVE 'F' TO IOCA-DIRECTION.                         
    MOVE TAPEOD-RLH TO IOCA-LOGICAL-REC-LENGTH.        ----> 059 moved to TAPEOD-RLH.
    MOVE SPACES TO IOWA-RECORD.                         
    MOVE 'TAPEOD' TO IOCA-DDNAME.                       
    MOVE TAPEOD-REC TO IOWA-RECORD.                     
    CALL 'OPC9719' USING IOCA IOWA PARM                 
        RECOVERY-COMMUNICATIONS-AREA PRINT-RECORDS       
        OPC97-LINKAGE.                                   
P-WRITE-TOD-EXIT.                                       
    EXIT.               

--Chandru
Back to top
View user's profile Send private message
kolusu
Site Admin
Site Admin


Joined: 26 Nov 2002
Posts: 12376
Topics: 75
Location: San Jose

PostPosted: Tue Jan 06, 2004 4:03 pm    Post subject: Reply with quote

Chandru,

When you specify RECORD CONTAINS 0 CHARACTERS and the BLOCK CONTAINS 0 CHARACTERS clause is specified (or omitted), the block size is determined at run time from the DD parameters or the data set label of the file. For output data sets, with either of the above conditions, the DCB used by Language Environment will have a zero block size value. If you do not specify a block size value, the operating system might select a System Determined Block Size (SDB).

I am guessing that since you are using a common routine which can be used for different file lengths, the routine is expecting the dcb parameters from the JCL.

Now lets us test something here. Do you have any other file in the same program where you are actually writting instead of dummying it out? If you do have just remove the dcb parameters for that file and run it. Let us know what you find

Thanks

Kolusu
_________________
Kolusu
www.linkedin.com/in/kolusu
Back to top
View user's profile Send private message Send e-mail Visit poster's website
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Wed Jan 07, 2004 8:37 am    Post subject: Reply with quote

Kolusu,
I removed DCB from other file as you said, which is also causeing abend. But still I'm not clear how it is working when we concatenate SYS1.COB2LIB, why it doesn't expect DCB parameters when we concatenate SYS1.COB2LIB. I couldn't provide correct reason for this issue. Because this issue is not documented in the manual for LE migration.

--Chandru
Back to top
View user's profile Send private message
chandhroo
Beginner


Joined: 02 Dec 2002
Posts: 36
Topics: 13

PostPosted: Tue Jan 13, 2004 5:51 am    Post subject: Reply with quote

Hi,
Finaly found the solution for this issue. We raised this issue to IBM support team and got following response. Hope it will help you.

Quote:

According to the VS COBOL II Application Programming Language Reference Release 4 (GC26-4047-07) under the heading "OPEN Statement" sub heading "Format 1 (QSAM or SAM Files)" it states the following

OUTPUT Permits opening the file for output operations. This phrase can be specified when the file is being created.

Note: The OUTPUT option should NOT be specified for a file that:

- Contains records. The file will be replaced by new data.

- Is defined with a DD dummy card when running under MVS. Unpredictable results may occur.
So from the above documentation you should not be opening a file as OUTPUT that is defined with a DD DUMMY as unpredictable results can occur. NOTE this is also and documented restricting with Enterprise
COBOL.

I would recommend that you change your application to actual write to a file or remove writing to the dummy file all together. Under LE you can make the change of adding the DCB information, but since it is
documented that you should not be opening a file as OUTPUT that is defined as DD DUMMY it is possible that some future maintenance with cause your job to fail all the time if DCB information is coded or not.



Thanks
Chandru
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic   printer-friendly view    MVSFORUMS.com Forum Index -> Application Programming All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


MVSFORUMS
Powered by phpBB © 2001, 2005 phpBB Group