View previous topic :: View next topic
|
Author |
Message |
ravi_chella2000
New User
Joined: 18 Dec 2006 Posts: 8 Location: India
|
|
|
|
How can variable length files be handled in OS/VS cobol? |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Multiple length 01s or a variable length 01 under the FD. |
|
Back to top |
|
|
Sahoo
New User
Joined: 08 Jun 2006 Posts: 53
|
|
|
|
The actual problem is given below:
Program Name : ABC
Select abc assign to abcfile
Recording mode is V
block contains 0 records
Record contains 2036 characters
Data Record is abc-record
FD abc-Record PIC X(2036)
....
Linkage section
01 REC-area PIC X(2036)
Procedure division using REC-AREA
READ abc
Move abc-Record to REC-AREA
...
The JCL is like this..
mainpgm is the main program. ABC programs called by Mainpgm
Step01 EXEC PGM=Mainpgm
Abcfile DD DSN=INFILE1,DISP=SHR
DD DSN=INFILE2,DISP=ShR
When this program executes in Non LE, thsi runs fine.. But when it executes in LE it fails with S0C4. The statement that fails after processing some records is the Move statement...
What is the soultion for this...
We tried with the options given by you.But it does not work.. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
So this is not about reading VB files, but moving data to linkage in a called program and the differences between a non-LE and an LE environment, correct? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Is this a called module? |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
My first guess (not an LE expert but used to play one at my last job...grin...) might be that the storage locations might not be compatable?
Maybe if the calling prog addresses above the line while the sub does it below, wouldn't that be a s0c4?
Comparing the AMODEs might point out a problem..... |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Sorry about the previous question - i misread the original post.
Both programs have been recompiled LE? Do they use the same compile jcl?
Would you include the "CALL" from mainpgm? |
|
Back to top |
|
|
ravi_chella2000
New User
Joined: 18 Dec 2006 Posts: 8 Location: India
|
|
|
|
AMODE and RMODE is not the problem. Because it processes some records from the input file...
You can see the RUn JCL.. The input file is a concatenation of INFILE1 and INFILE2...
When we copy both INFILE1 and INFILE2 ton INFILE3 and give only INFILE3 as input, it goes fine...
Yes.. All the modules are compiled in LE.. ABC is a called module from main program. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Stange.....
Maybe it's time to look at the dump. |
|
Back to top |
|
|
Sahoo
New User
Joined: 08 Jun 2006 Posts: 53
|
|
|
|
Let me know what type of dump and how to get that dump you require.. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Sahoo wrote: |
Let me know what type of dump and how to get that dump you require.. |
The s0c4 produces a dump you require. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hmmmm,
If you reverst the concatenation and run a test with INFILE2 first and INFILE1 second does the abend still occur?
From the processing that is done before the abend, can you tell if the abend occurs when the first input ends/second input begins? |
|
Back to top |
|
|
Sahoo
New User
Joined: 08 Jun 2006 Posts: 53
|
|
|
|
Yes.. it completes first input file...It reads some records from the second input file..
If you change the concatenation order... Same thing happens... |
|
Back to top |
|
|
ravi_chella2000
New User
Joined: 18 Dec 2006 Posts: 8 Location: India
|
|
|
|
SOC4 dump that was sought. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Yes.. it completes first input file...It reads some records from the second input file.. |
Is the abend in or at the end of the first block in the second file?
Could you post the CALL from mainpgm as well as the "REC-AREA" definition from mainpgm?
Is "REC-AREA" in mainpgm near or at the end of WORKING STORAGE? If it is, you might try with a 20k filler behind it.
It sounds like some of storage got "walked on" when the "open" for the second file occurred. |
|
Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006 Posts: 3156 Location: Tucson AZ
|
|
|
|
Code: |
A storage reference exception occurred during execution of program PCRFYE14. The expected completion code is S0C4.
******************************************* * Analysis of Error * *******************************************
The system completion code of 0C4 is issued when the program attempts to use storage that is not accessible.
*** List of Probable 0C4 Causes ***
- Missing or incorrect DD statement
- Check system messages from abending step.
- Tried to reference record area before file opened.
- Indexing or subscripting outside defined limits.
- Linkage section incorrectly placed or omitted.
- Linkage section referenced without coding using clause on 'PROCEDURE DIVISION' or 'ENTRY' statement.
- Mismatched parameter list between calling program and subroutine.
- STOP RUN or GOBACK used in sort input procedure or output procedure.
- PERFORM or GOTO outside of section from sort input procedure or output procedure.
The IBM message that corresponds to the condition is:
CEE3204S The system detected a protection exception (System Completion Code=0C4). ******************************************* * Error Location * *******************************************
The next sequential instruction to be executed in program PCRFYE14 was at displacement 0000073C.
The program was compiled on 18 DEC 2006 and is 000009E8 bytes long.
It is part of load module PCRCD801.
The module was loaded from JOBLIB library K9900P.STGT@Y.DISP.#001350.NLB .
The module was link edited on 18 DEC 2006 and is 000181D8 bytes long. |
Interesting, a newly compiled version?
You have the displacement, take a look. |
|
Back to top |
|
|
|