|
View previous topic :: View next topic
|
| Author |
Message |
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
We have this error at every time, even if the file is correctly sorted :
| Quote: |
ICE071A B INVALID RETURN CODE FROM EXIT E35 - RC=4, CASE=S1
ICE751I 1 DE-K10929 D5-K05352 C4-K90000 D3-K10929 D7-Q91626 E8-K11698
ICE052I 0 END OF DFSORT
IGZ0026W The SORT-RETURN special register was never referenced, but the
current
operation in program ARDJ110E on line number 2317 was
unsuccessful.
|
What does it mean exactly ?
ARDJ110E is a COBOL program in which return code is forced to zero, else the step falls down at every time. 
The problem occurs when there is not enough space in workspace because, in this case, the process falls down, but several steps after ! |
|
| Back to top |
|
 |
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
In DFSORT terms: Your COBOL program is using an E35 that deletes all of the records (no SORTOUT). But when DFSORT tells the E35 that there are no more output records, the E35 is passing back RC=4 (delete record) instead of RC=8 (do not return). RC=4 is invalid in this situation.
I don't know COBOL, so I can't tell you what you're doing wrong in the COBOL program. Maybe somebody else can.
You could probably bypass the error using:
| Code: |
//DFSPARM DD *
OPTION EXITCK=WEAK
/*
|
which will tell DFSORT to accept the invalid RC=4 as if it were RC=8. But that will mask the error in the COBOL program which may not be the best strategy. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Do you have access to the source code that is running in the E35 exit? It may be assembler or COBOL or maybe even something else.
Please post the SORT code in the COBOL program (unless the only COBOL is the E35 exit code).
Also, please post the JCL & control statements for this step. |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
Hello,
Here is the source COBOL I'm examining.
I have noticed that INPUT procedure names a section and OUTPUT procedure a paragraph ; it's not very nice  but could it be the reason of RC=4 ?
On Monday, I'll try to send you the JCL.
I don't understand "that deletes" because there's no delete in the program :
| Quote: |
Your COBOL program is using an E35 that deletes all of the records (no SORTOUT). But when DFSORT tells the E35 that there are no more output records, the E35 is passing back RC=4
|
|
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
| The "delete" is the COBOL E35's way to tell DFSORT that it is handling the output records itself rather than passing them back to DFSORT. As far as DFSORT is concerned, the COBOL E35 is deleting each record passed to it. But as far as the COBOL E35 is concerned, it's processing those records. It's just the way the interface works. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Might you be able to post the code from the E35 exit (please see below)?
If i was working on this program, i'd first make a copy to experiment with.
With the copy, i'd re-sequence the sections and paragraphs - the way they now are will not confuse the compiler, but it may confuse people.
This
| Code: |
SORT FIC-SORTWK-T ASCENDING DAM-CLEF-K OF ERG-SORTWK-T
DAM-STA-CAP-DT OF ERG-SORTWK-T
DAM-STA-CAP-CD OF ERG-SORTWK-T
INPUT PROCEDURE 1500-TRT-FORMAT
THRU 1999-FIN-INPUT
OUTPUT PROCEDURE 2000-TRT-TASSEMENT
THRU 2999-FIN-OUTPUT
2000-TRT-TASSEMENT SECTION. |
does not follow with
| Quote: |
I have noticed that INPUT procedure names a section and OUTPUT procedure a paragraph ; it's not very nice but could it be the reason of RC=4 ?
|
Note that the "2000-TRT-TASSEMENT SECTION" follows the 9000-paras.
After the sort, this "PERFORM 3000-AD-FIN" is issued. 3000-AD-FIN is in the input procedure section. This may work, but i always execute "input procdure" code while processing the "input procedure" and the same with "output procedure" code.
Please make sure all of the code is in the appropriate section and run with the "new" code. If anything is needed in both the input and output procedure, your best bet is to move it to another section. The same is true of the PERFORM 3000-AD-FIN code.
While this may seem off-base - how do we know there actually is some E35 exit code being used (other than the error message)? From my experience the cobol/"internal sort" gets "bent" when it is interrupted - most often an 0c4 is shown, but other things have occured.
We're here when you have new info  |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
What do you call the "code from the E35 exit" ?
| Quote: |
Might you be able to post the code from the E35 exit (please see below)?
|
There's no code but the COBOL program I sent.
I Think your idea is very good an close to mine : in fact, Input procedure should be closed after thru, but the section himself is not closed when 3000-AD is performed ; so, if that's true, the procedure output could give a RC=4... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Searchman,
This "the E35 exit " is from the error info you posted
| Quote: |
ICE071A B INVALID RETURN CODE FROM EXIT E35 - RC=4, CASE=S1
ICE751I 1 DE-K10929 D5-K05352 C4-K90000 D3-K10929 D7-Q91626 E8-K11698
ICE052I 0 END OF DFSORT
IGZ0026W The SORT-RETURN special register was never referenced, but the
current
operation in program ARDJ110E on line number 2317 was
unsuccessful.
|
What is the code just before and after "line number 2317"? The code you posted does not have the line numbers generated by the compiler - typically it won't due to the compiler generating new line numbers at compile time (with copybooks expanded, or pre-compiler syntax expanded).
I'm suspicious that there is an "exit routine" actually being used. If the cobol code did something "bad" but not completely "fatal", there may be strange manifestations.
There should be more info in your output - messages from the sort. There may be a "dd statement missing" message - if there is, put one into the jcl and re-run (it will most lilkely be a "sysout" dataset.
I'll check back later today. |
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
| Quote: |
| I'm suspicious that there is an "exit routine" actually being used. |
IIRC, the input and output procedures for the COBOL SORT are the E15 and E35 exits to the SORT. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
My bad - i should have said a "separate bit of code" for the E35 exit.
And yup, i believe the i/p and o/p procedures behave like exit routine code. The big difference being that in an internal sort, the COBOL run unit is "in charge" and with an external sort using one or both of those exits, the sort is "in charge". |
|
| Back to top |
|
|
Frank Yaeger
DFSORT Developer
Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA
|
|
|
|
I'm not sure what the point about the E35 exit is. When you use a COBOL SORT verb, COBOL generates an internal E35 exit that it uses to interface with DFSORT. That's the E35 exit I'm talking about.
A separate COBOL E35 exit is a different animal - it would require passing the name of the E35 exit to DFSORT in a MODS statement.
In the Programmer Response for ICE071A, it says:
| Quote: |
| In a COBOL-invoking program containing an input or output procedure, check that control passes through the end of the input procedure before the output procedure is entered, and through the output procedure before the sort is ended. |
I don't know COBOL so I don't know what it means, but perhaps it applies here. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Frank,
Yes - it does.
| Quote: |
| but perhaps it applies here. |
The problem (IMHO) is that the COBOL code is not properly structured (that was some of the earlier discussion). As i mentioned earlier, using code that is not in the proper "section" most often causes an 0c4.
The chat about the E35 was to confrim that there was no external E35 code and that we were all on the same page. Sorry if it was mis-leading.
Once all of the code is used only in the proper sections i believe the posted issue will be resolved. |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
Yes, I confirm, there's no 35 exit but the COBOL program.
I'll test tomorrow with section in place of paragraph in 1999-FIN-INPUT
as in 2999-FIN-OUTPUT, and check code around line number 2317.
Note that cobol reference manual don't specify procedure name 1 and procedure name 2 must be of same type (both paragraph or both section) |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Please review the previous info. If i recall correctly, both your input and output procedures refer to a section not a paragraph. It gets confusing as the numbering scheme is not consistent.
As was also pointed out previously, the input procedure and output procedure are executed as though they were "exits". There is a mechanical and an external difference, but they work within the "exit reoutines".
Also, if memory serves, it is the code that "crosses sections" that is causing the problem(s). Make sure that all of the code is executed in the proper section. |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
I've run the program modified (without section)
it's still the same
| Quote: |
ICE071A B INVALID RETURN CODE FROM EXIT E35 - RC=4, CASE=S1
ICE751I 1 DE-K10929 D5-K05352 C4-K90000 D3-K10929 D7-Q91626 E8-K11698
ICE052I 0 END OF DFSORT
IGZ0026W The SORT-RETURN special register was never referenced, but the current
operation in program ARDJ110E on line number 2317 was unsuccessful.
|
About line 2317 :
| Quote: |
2314
2315 * TRI INTERNE
2316
2317 SORT FIC-SORTWK-T ASCENDING DAM-CLEF-K OF ERG-SORTWK
2318 DAM-STA-CAP-DT OF ERG-SORTWK
2319 DAM-STA-CAP-CD OF ERG-SORTWK
2320
2321 *--* NARS6003
2322 INPUT PROCEDURE 1500-TRT-FORMAT
2323 THRU 1999-FIN-INPUT
2324 OUTPUT PROCEDURE 2000-TRT-TASSEMENT
2325 THRU 2999-FIN-OUTPUT
|
Step of JCL run :
| Quote: |
//** STEP ARVPCAF PGM=ARDJ110E ** ID=CAF
//************************************
//ARVPCAF EXEC PGM=ARDJ110E
//* COND=((1,EQ,&EXCAF),(51,LT,FROM),(51,GT,TO))
//SYSOUT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSOUA DD SYSOUT=*
//SYSDBOUT DD SYSOUT=*
//*
//ARDJ1001 DD DSN=PAR0.ARV10A56(0),DISP=SHR
//*
//ARDJ1002 DD DSN=EXDU.SCI.ARDJ1034,DISP=(NEW,CATLG,DELETE),RECFM=FB,
// LRECL=130,SPACE=(TRK,(3386,1355),RLSE),
// DATACLAS=MULTIVOL,STORCLAS=STDGDG,MGMTCLAS=GDGML1
//*
//*ORTCNTL DD DSN=EXPL.PREP4.PARMFIX2(SORTCN08),DISP=SHR
//SORTCNTL DD DSN=SARA.PBG0.JCL.MC(SORTCN08),DISP=SHR
//*
//* FICHIER DES COMPTES DE GESTION
//CPTGEST0 DD DSN=PAR0.ARGEST10,DISP=SHR
//*
//CPTGEST DD SUBSYS=(BLSR,'DDNAME=CPTGEST0','HBUFND=200','HBUFNI=50',
// 'RMODE31=ALL','MSG=I')
//*
//SPI2TAB DD DSN=PSP0.CICS.SPIU0000,DISP=SHR,
// AMP=(AMORG,'BUFND=50','BUFNI=10')
|
|
|
| Back to top |
|
|
William Thompson
Global Moderator
Joined: 18 Nov 2006
Posts: 3156
Location: Tucson AZ
|
|
|
|
Searchman,
Did you read what Frank wrote:
| Frank Yaeger wrote: |
In the Programmer Response for ICE071A, it says:
| Quote: |
| In a COBOL-invoking program containing an input or output procedure, check that control passes through the end of the input procedure before the output procedure is entered, and through the output procedure before the sort is ended. |
|
It is a fairly strong indication that your program is mis-behaving.
Try some displays at entry and exit form the input and output procedures to see if it is cutting corners. |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
Hi,
The forum has been unavailable for a few hours...
About the E35 Pb, I've found the solution! It's a bug in the output procedure (so, E35) :
| Quote: |
* PERFORM UNTIL DAM-CLEF-K OF WS-REC-MVT-OUT = HIGH-VALUE
PERFORM UNTIL DAM-CLEF-K OF WS-SORTWK = HIGH-VALUE
MOVE WS-SORTWK TO WS-REC-MVT-OUT
PERFORM 2100-RETURN-MVT |
The sentence in commentary is the wrong one (in prod)
Test is made with WS-REC-MVT-OUT instead of WS-SORTWK, that's the bug. Then, one RETURN is done after the last one (which moves H-V, see below) this causes the OUTPUT PRODEDURE to be interrupted with RC=4.
| Quote: |
2100-RETURN-MVT.
-------------------
RETURN FIC-SORTWK-T INTO WS-SORTWK AT END
MOVE HIGH-VALUE TO WS-SORTWK.
|
Note there's no problem with sections and paragraphs even if it is bad writing !
Conclusion : the importance of return code to be tested !
Question : about return codes : where (link) can I find return codes of RETURN and RELEASE and more generally VSAM ? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Yup, until now, the last i was able to access the site was late Sunday evening. Sorry to be delinquent
I'm suspicious that there may be something (at least) questionable with the code. What kind of "return code" are you looking for? After implementing several thousand internal sorts on many platforms, i have never tested "return codes" after a RELEASE or a RETURN. With the RETURN, there is an AT END i've used every time, but nothing else. Once the code proceeds beyond the SORT statement, it is a good idea to check SORT-RETURN to ensure there was a successful sort.
It sounds like your SORT terminated with the equivalent of a "read after end-of-file". Because it happened inside the sort, sort intercepted the abend and abnormally ended sorting (the program may have created the desired output, but the sort detected a problem).
What is in your SORTCNTL member (just curious)?
What kind of VSAM info are you looking for?
Good to hear you've found the bug |
|
| Back to top |
|
|
Searchman
New User
Joined: 28 Dec 2006
Posts: 80
Location: France
|
|
|
|
You're right, it's no use to test inside the output (or input) procedure because, as you say
| Quote: |
| Because it happened inside the sort, sort intercepted the abend and abnormally ended sorting |
, juste after the return too much, the process cannot continue indide the output procedure. So, the control of sort-return must be done after the sort instruction.
In SARA.PBG0.JCL.MC(SORTCN08), there is one card :
| Quote: |
OPTION FILSZ=E80000
|
About return codes I meant, after OPEN, CLOSE, READ, WRITE, etc.
do you know a link ? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I believe you can find everything you want from the sections in the COBOL manual, VSAM Services for DFSMS, and the DFSORT manual - all are linked to from the "Manuals" link at the top of the page.
If there are other topics you are interested, let me know. |
|
| Back to top |
|
|
|
|
