|
View previous topic :: View next topic
|
| Author |
Message |
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
Hi Everyone,
We got abend ABEND=S000 U0016 REASON=00000000 084 when trying to copy a file using syncsort which is created in step 1 with proper attributes(which shown in bold) and using the same file in step02 as input . In step01, while copying, it show as 4 exceptions while copying which we do not know what it is and we are not sure whether it is the reason for the abend. In step 02, we see the attributes for the file are listed as blank (which is shown in bold) and we do not know the reason for that too.
JCL:
//STEP01 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTIN DD DSN=&MCP0..ABCDD006.CONF.BKUP.FILE(+1),DISP=SHR
// DD DSN=&MCP0..ABCDD006.MOBIUS.RPT(+1),DISP=SHR
//SORTOUT DD DSN=&MCP0..ABCDD006.CONF.MOBIUS.FILE(+1),
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,10),RLSE),
// DCB=*.SORTIN
//SYSIN DD DSN=&CTLPFX..CARDLIB(MCP0COPY),DISP=SHR
//STEP02 EXEC MCP0VDRS,
// VDRS=&MCP0..ABCDD006.CONF.MOBIUS.FILE(+1),RPT=D006
//STEP02.SORTOUT DD SYSOUT=(Y,MCP0D006),DCB=*.SORTIN
//*
Below is the JESYSMSG
STEP01:
SORTIN : RECFM=FB ; LRECL= 3500; BLKSIZE= 17500
SORTIN : DSNAME=MCP0.MCP0D006.CONF.BKUP.FILE.G0001V00 (FIRST OF 2)
SORTOUT : RECFM=FB ; LRECL= 3500; BLKSIZE= 17500
SORTOUT : DSNAME=[b]MCP0.ABCDD006.CONF.MOBIUS.FILE.G5889V00
5,856K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
0 BYTES RESERVE REQUESTED, 5,856K BYTES USED
SYNCSMF CALLED BY SYNCSORT; RC=0000
SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
SORTIN : EXCP'S=2,UNIT=3390,DEV=7589,CHP=(5051525354555859,1),VOL=C80758
SORTOUT : EXCP'S=2,UNIT=3390,DEV=7622,CHP=(5051525354555859,1),VOL=C80445
TOTAL OF 4 EXCP'S ISSUED FOR COPYING
STEP02***************************************************************
CARD TO COPY. ***
***************************************************************
LDS=COPY
SYSDIAG= 2484641, 4566304, 4566304, 4352550
6,884K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
0 BYTES RESERVE REQUESTED, 992K BYTES USED
32K BYTES OF EMERGENCY SPACE ALLOCATED
SORTIN DCB RECFM REQUIRED
SORTIN : RECFM= ; LRECL= ; BLKSIZE=
SORTIN : DSNAME=MCP0.ABCDD006.CONF.MOBIUS.FILE.G5889V00 SYNCSMF CALLED BY SYNCSORT; RC=0000
SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
We need to resolve this abend and we need a solution to prevent this abend in future. Any help is appreciable. |
|
| Back to top |
|
 |
vasanthz
Global Moderator
Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India
|
|
|
|
Hello,
From the data you have shown, it appears that the 1st step ran fine.
2nd step is however a PROC (no PGM=) So we cannot know what that proc detail is. MCP0VDRS maybe site specific procedure.
| Quote: |
| it show as 4 exceptions while copying which we do not know what it is and we are not sure whether it is the reason for the abend. |
Its is not 4 exceptions, It is 4 times the Execute Channel path macro was called. It is only an information and not an error.
In simple terms, Whenever your program needs to read data or write data it will issue a call to execute channel path macro.
I think there are other access methods, but not relevant to this topic now.
Regards, |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Why chop off the message references?
It is probably this:
| Code: |
| SORTIN DCB RECFM REQUIRED |
Can't really tell if it is, or why it is, or how to fix it. If you can't either, you'll have to post the expanded JCL and the full sysout from the step. In the Code tags, please. |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
Bill, You are correct.I apologise. By mistake I deleted the 3 lines while copying and pasting. Please find below the full message.
SORT FIELDS=COPY
WER276B SYSDIAG= 2484641, 4566304, 4566304, 4352550
WER164B 6,884K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 992K BYTES USED
WER146B 32K BYTES OF EMERGENCY SPACE ALLOCATED
WER189A SORTIN DCB RECFM REQUIRED
WER108I SORTIN : RECFM= ; LRECL= ; BLKSIZE=
WER073I SORTIN : DSNAME=MCP0.ABCDD006.CONF.MOBIUS.FILE.G5889V00
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER449I SYNCSORT GLOBAL DSM SUBSYSTEM ACTIVE
When I searched the error code WER189A, I got the below description for that error code
WER189A ddname DCB RECFM REQUIRED
EXPLANATION: The RECFM was not specified on the indicated input
DD statement, nor was it available in the DSCB on disk nor the tape
label, and the TYPE operand was not specified on the RECORD control
statement.
We did not specify RECFM explicitly as we gave DCB=*.SORTIN in the JCL and thinking that the file attributes will be decided by the input file. Do we need to mention the RECFM explicitly?. Is this the reason for this abend?. |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
| Vasanth, Thanks for your information. The proc is site specific as you mentioned. I think Bill got the problem. It will be helpfull if you can provide some more information on that. |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
Bill,
when I did some research, I found that when we do not specify DISP parameter in SORTIN or if we specify DCB parameters in SORTIN, we get the error as 'SORTIN DCB RECFM REQUIRED'.
I have given the expanded code below which is a proc using this dataset to send the report to repository. But, when I see the SORTIN in below expanded code, the parameters are correct. We have given DISP=SHR. Do we need to change the DISP parameter to (OLD,DELETE) or some other options ?
P02//********************************************************************
P02//* VDRSTEP - THIS STEP CREATES COPIES OF REPORTS FOR MOBIUS
P02//* THIS STEP IS RESTARTABLE.
P02//********************************************************************
P02//MCP0VDRS PROC MCP0=,
P02// VDRS=,
P02// CTLPFX=NDVR.PROD,
P02// RPT=
P02//*
P02//VDRSSTEP EXEC PGM=SORT
P02//SORTIN DD DSN=&MCP0&VDRS,DISP=SHR
P02--SORTIN DD DSN=MCP0.ABCDD006.CONF.MOBIUS.FILE(+1),DISP=SHR
P02//SORTOUT DD SYSOUT=(Y,NLP0&RPT),DCB=*.SORTIN (<--RPT-IDS ARE 'NLP'
P02--SORTOUT DD SYSOUT=(Y,NLP0D006),DCB=*.SORTIN (<--RPT-IDS ARE 'NLP'
P02$/VDRSSTEP.SORTOUT DD SYSOUT=(Y,MCP0D006),DCB=*.SORTIN
P02$/* |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
You need to post the sort control statements.
If all you want to do is copy a file, yo do not need to specify the info for the output file - it will be copied from the input.
Is this a new process or has some old processed been changed to get to the failure? |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
Hi Dick,
This is the existing job which failed last week with the error message i posted earlier. After that too this job is runing multiple times without any failure and without any changes. We do not know why that failure happens on that particular instance. sort card is nothing but to simply copy the records.
SORT FIELDS=COPY
Regards
Rajesh |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
My guess is that is has to do with the step that creates the +1 Sortin file.
When no data gets written to this file, the dcb information is NOT populated properly, becuase the dcb information is not coded in the jcl.
Just a guess based on limited information provided by ts. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hi Rajesh,
Suggest you copy the JCL to be:
| Code: |
//SORTOUT DD DSN=&MCP0..ABCDD006.CONF.MOBIUS.FILE(+1),
// DISP=(NEW,CATLG,DELETE),
// SPACE=(CYL,(100,10),RLSE) |
When doing a straight COPY, SORT will use the input DCB for the output if Nothing is specified. |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
| Thanks for the suggestion Dick. My question is that job is running succcessfully without any code changes. But it failed only on that particular instance with the error message 'SORTIN DCB RECFM REQUIRED'. If I remove the DCB=*.SORTIN parameter in SORTOUT will help to resolve this issue or it's just a coding standard to follow?. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
There used to be a television show here in the US many years ago.
They played a game called: 'One of these things is not like the other'
That is the game you have here. What is different about the time(s) it fails vs. the times it works?
Just changing something may not fix the issues, especially since you do not know what the issue is. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
I agree with Dave's guess.
Look at the content/definition of that SORTIN dataset for the times it fails. Compare to a time it succeeds. I'd suspect something like "already known to contain data so step bypassed" and then output from the bypassed step goes into your step.
Like Dick, I don't like the (+1) with SHR. I'd restructure the JCL into more than one separate job to avoid that being coded. It could be interesting to see your re-start instructions... |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| If I remove the DCB=*.SORTIN parameter in SORTOUT will help to resolve this issue or it's just a coding standard to follow?. |
It might help with the problem - i do not know for sure.
I would make sure i used JCL that has a better history of success. As in - these days, SORT will propogate dcb info when cophying a file. And SORT or not, +1 and SHR just isn't done . . . At least no where that i've supported. |
|
| Back to top |
|
|
Rajesh Haridoss
New User
Joined: 22 Feb 2014
Posts: 16
Location: India
|
|
|
|
Thanks Everyone for your suggestions.
Bill,
I do not see any message '"already known to contain data so step bypassed" which you mentioned. We are using this (+1),SHR in many jobs and only this job got failed that too in a particular instance. After that when we resubmitted without any code changes, it went fine and is running after that without any issues. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| We are using this (+1),SHR in many jobs and only this job got failed that too in a particular instance. |
That does NOT mean it has been done well . . .
Suggest you look at several of the JCL streams posted here in the forum and see how many times you find (+!) and SHR on the same DD statement. |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
How about this -
| Code: |
//MAKEGDG EXEC PGM=...
//NEWGDG DD DISP=(,CATLG),DSN=GDGINEX(+1),...
//USEGDG EXEC PGM=...
//OLDGDG DD DISP=SHR,DSN=GDGINDEX(+1) |
The actual status of the data set in the USEGDG DD statement is OLD since the exclusive status is forced by the NEWGDG DD statement on the MAKEGDG step, but many programmers will use DISP=SHR in the OLDGDG DD statement out of habit. Regardless of the data set status, you have to use +1 in the USEGDG step to get the correct data set.
Obviously, if the USEGDG step is run as a separate job executed after the job with the MAKEGDG step completes, the +1 won't work; you have to use 0. |
|
| Back to top |
|
|
|
|
