Hi Al
regarding below jcl , need to know if second step S1 will get FLUSHED or not in case MY.FILE all ready exists. MY QUERY IS WHAT HAPPENS WHEN S1 GIVES RC > 0 . WILL IT CAUSE REST OF THE STEPS FLUSHED?
Why don't you just try it?
Anyway, the S1 stop will not get a RC, it will get FLUSHED because of duplicate dataset, causing the rest of the job to be flushed as well. If you want a RC you will need a program to test the existence of the dataset - IDCAMS springs to mind.
As written here, it does not matter if MY.DS exists before the job is run. See the discussion of DISP=MOD in the JCL Reference manual for your z/OS release.
The JCL in S2 does not specify RLSE. That's because RLSE is not a data set attribute; it only applies to the step and DD statement that populates the data set; S2 does not populate the data set.
Steve-myers, you are definitely wrong here. The reason you get rc 0 in the IEFBR14 is that you have DISP=(MOD,DELETE) in S1, OP had DISP=NEW.
I tried the OP's JCL and the result is definitely a FLUSH:
[code]
12.16.52 JOB09265 IEF403I ZZZ1 - STARTED - TIME=12.16.52
12.16.53 JOB09265 - --TIMINGS (MINS.)-- -----PAGING COUNTS----
12.16.53 JOB09265 -STEPNAME PROCSTEP RC EXCP CONN TCB SRB CLOCK SERV WORKLOAD PAGE SWAP VIO SWAPS
12.16.53 JOB09265 -S1 FLUSH 0 0 .00 .00 .0 0 SYSTEM 0 0 0 0
12.16.53 JOB09265 IEF453I ZZZ1 - JOB FAILED - JCL ERROR - TIME=12.16.53
12.16.53 JOB09265 -ZZZ1 ENDED. NAME-ZZZ TOTAL TCB CPU TIME= .00 TOTAL ELAPSED TIME= .0
12.16.53 JOB09265 $HASP395 ZZZ1 ENDED
------ JES2 JOB STATISTICS ------
30 JUL 2016 JOB EXECUTION DATE
10 CARDS READ
45 SYSOUT PRINT RECORDS
0 SYSOUT PUNCH RECORDS
3 SYSOUT SPOOL KBYTES
0.00 MINUTES EXECUTION TIME
1 //ZZZ1 JOB (1),'ZZZ', JOB09265
// CLASS=A,MSGCLASS=X,REGION=32M,TIME=NOLIMIT,COND=(5,LT)
//*
2 //S1 EXEC PGM=IEFBR14
3 //D2 DD DSN=XX.ZZZ.FILE,DISP=(NEW,CATLG,DELETE),
// SPACE=(TRK,(100,100),RLSE),
// DCB=(RECFM=FB,LRECL=10,BLKSIZE=1000),UNIT=UNITDEV
//*
4 //S2 EXEC PGM=IEFBR14
5 //D1 DD DSN=XX.ZZZ.FILE,DISP=(MOD,DELETE,DELETE),SPACE=(TRK,0)
ICH70001I XX LAST ACCESS AT 12:16:38 ON SATURDAY, JULY 30, 2016
IEF344I ZZZ1 S1 D2 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
IGD17001I DUPLICATE DATA SET NAME ON VOLUME SYSXU1
FOR DATA SET XX.ZZZ.FILE
IGD17101I DATA SET XX.ZZZ.FILE
NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
[code][/code]
Joined: 03 Oct 2009 Posts: 1787 Location: Bloomington, IL
A wide variety of utilities can produce non-zero return codes. To the left, a lot of programs written by developers don't, apparently because letting a test executioner, an operator, or an auditor know what is going on takes all the excitement out of software development.
Bottom line: Know what you're executing. Read the fine manuals (and the source).
Joined: 31 Oct 2006 Posts: 1050 Location: Richmond, Virginia
The reason RC's are 0, 4, 8, ..., is because a Branch assembler language command occupies 4 bytes. The Branch commands for each condition (no error, warning, error, etc.) are adjacent in an assembler program, and a Branch on Condition branches to one of them depending on the situation, and the one branched to therefore branches to the code to handle that situation.
I hope I haven't garbled this too much - it's been almost 50 years.
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Phrzby Phil wrote:
The reason RC's are 0, 4, 8, ..., is because a Branch assembler language command occupies 4 bytes. The Branch commands for each condition (no error, warning, error, etc.) are adjacent in an assembler program, and a Branch on Condition branches to one of them depending on the situation, and the one branched to therefore branches to the code to handle that situation.
I hope I haven't garbled this too much - it's been almost 50 years.
Well, that was the theory. What Phrzby left out was the concept that any program called by JCL could also be called by some other program. It might look like this -
Code:
CALL XXX
B *+4(15)
B ... RC = 0
B ... RC = 4
B ... RC = 8
B ... RC = 12
B ... RC = 16
In practice, rarely used, for several reasons.
Concern that the actual RC was not a multiple of 4.
Concern the actual RC was greater than the size of the branch table.
Joined: 06 Jun 2008 Posts: 8700 Location: Dubuque, Iowa, USA
Susanta, I think you have a very simplified view of what can be a very complicated topic. The SMF manual discusses some of this in the type 30 Completion record mapping:
Quote:
Step completion code:
X'0ccc' indicates system abnormal end of task (abend) in the job step where ccc is the system abend code. (See z/OS MVS System Codes.)
X'8ccc' indicates user abend in the job step where ccc is the user abend code.
X'nnnn' indicates normal completion where nnnn is the contents of the two low-order bytes in register 15 at termination.
X'0000' indicates one of the following: •The job step was flushed (not processed) because of an error during allocation or in a preceding job step.
•Start of changeThe job step terminated with an abend code ending in X'0D'. In this case, SMF30SCC contains the value from the low-order two bytes of the TCBCMPC field, which may contain zeros.End of change
•Normal job completion with a return code of 0.
Use this field in conjunction with the job/step termination indicator field, SMF30STI.
Job completion code:
X'0ccc' indicates system ABEND in the last job step where ccc is the system abend code. (See z/OS MVS System Codes.)
X'8ccc' indicates user abend in the job step where ccc is the user abend code.
X'nnnn' indicates normal completion where nnnn is the contents of the two low-order bytes in register 15 at termination.
X'0000' indicates one of the following (see note): •The last job step was flushed (not processed) because of an error during allocation or in a preceding job step.
•Start of changeThe job step terminated with an abend code ending in X'0D'. In this case, SMF30SCC contains the value from the low-order two bytes of the TCBCMPC field, which may contain zeros.End of change
•Normal job completion with a return code of 0.
Use this field in conjunction with the job/step termination indicator field, SMF30STI.
Note: When a step in a multi-step job terminates abnormally, the subsequent steps, whether executed or flushed, do not propagate the step abend code for processing this record. The code appears in the step termination record (subtype 4). In this case, the field, SMF30SCC, can contain X'nnnn' or X'0000'. If an abend occurred in the job, the job termination indicator (bit 7 in the SMF30STI field).
Bit Meaning when set
0 SMF30UAB - User abend
and the SMF30STI referenced in this quote is defined with:
Quote:
Step/Job termination indicator
Bit Meaning when set
0 Reserved
1 Canceled by exit IEFUJV.
2 Canceled by exit IEFUJI.
3 Canceled by exit IEFUSI.
4 Canceled by exit IEFACTRT.
5 Step is to be restarted.
6 If zero, then normal completion. If 1, then abnormal end of task (abend). If step completion code equals 0322 or 0522, then IEFUTL caused the abend. If step completion code equals 0722, then IEFUSO caused the abend.
7 If zero, then normal completion. If 1, then step was flushed.
8 EXCP counts might be incorrect because the record did not include all the DD statements.
9 Previous interval record was not written because an error occurred. The cumulative count might be incorrect because the counters were cleared.
10 EXCP sections were not merged from the interval to the step record or from the step to the job record.
11 Step completed with a “post execution” error. Post-execution errors include a failure that occurred because the ALLOCxx parmlib member specified CATLG_ERR FAILJOB(YES).
12 Step completed due to z/OS UNIX exec function request.
13 JOB abnormally ended because of COND= condition on the JOB card. This flag will be set on in the subtype 5 job termination record only.
14 Job was evicted via the $EJnn,STEP,HOLD or equivalent command. This bit is set for subtype 4 (step end) records only.
15 Reserved.
I think , it varies as per site installation, I did not investigate te deciding factor as yet but for me I got no errors or none of the step FLUSHED. If the dataset exists for S1 then it will be scratched and recataloged.
An afterthought, before the step actually flushes due to 'NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG', TS's JCL won't execute due to various JCL errors (if the JCL is copied as-is from the first post and executed).
Aside, when the errors are fixed, and the DS being used in the first step is catalogued prior execution of the posted JCL, the first step (IEFBR14) does 'FLUSH' with the aforementioned message, there is still a return code set: RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
Curious question here, IEFBR14 will return a '0' by default, whereas the storage management subsystem (please correct me if I have it wrong here) which will try to catalog the DS has returned a CC=8, why does the step still reflect a 'FLUSH' instead of a customary '8'; or have I got the concepts all messed up.
@Rohit, JESYSMSG should reflect the actions taken by JES, if the DS is indeed SCRATCHED, it should show; though it'd be a bit contrary to the JCL Reference definition of (NEW,CATLG).
Joined: 30 Nov 2013 Posts: 917 Location: The Universe
Abid Hasan wrote:
An afterthought, before the step actually flushes due to 'NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG', TS's JCL won't execute due to various JCL errors (if the JCL is copied as-is from the first post and executed).
Aside, when the errors are fixed, and the DS being used in the first step is catalogued prior execution of the posted JCL, the first step (IEFBR14) does 'FLUSH' with the aforementioned message, there is still a return code set: RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
Curious question here, IEFBR14 will return a '0' by default, whereas the storage management subsystem (please correct me if I have it wrong here) which will try to catalog the DS has returned a CC=8, why does the step still reflect a 'FLUSH' instead of a customary '8'; or have I got the concepts all messed up.
@Rohit, JESYSMSG should reflect the actions taken by JES, if the DS is indeed SCRATCHED, it should show; though it'd be a bit contrary to the JCL Reference definition of (NEW,CATLG).
To some extent Mr. Hasn is wrong. Without SMS. the system allocates a new data set, runs the user program, than catalogs the data set. With SMS, the system allocates and catalogs the data set, then runs the user program.
Thank you for clarifying on the SMS vs non-SMS processing hierarchy.
Your shared JCL will 'always' create the DS: XXXXXX.XX.DATA (under normal execution) on completion because of the DELETE in S1 and subsequent catalog in S2. Since the programs have executed clean, a CC 0 is returned.
Query here was a little different though; using TS's JCL as-is 'and FLUSHing' S1, even though a RC 8 is returned by SMS why does the step still show a FLUSH and not a higher RC.
********************************* TOP OF DATA **********************************
ICH70001I ABCDEF LAST ACCESS AT 12:06:25 ON THURSDAY, AUGUST 4, 2016
IEF344I TEST S1 D2 - ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
IGD17101I DATA SET XXXX.YYYY
NOT DEFINED BECAUSE DUPLICATE NAME EXISTS IN CATALOG
RETURN CODE IS 8 REASON CODE IS 38 IGG0CLEH
IEF272I TEST S1 - STEP WAS NOT EXECUTED.
IEF373I STEP/S1 /START 2016217.1207
IEF032I STEP/S1 /STOP 2016217.1207
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
VIRT: 0K SYS: 0K EXT: 0K SYS: 0K
ATB- REAL: 32K SLOTS: 0K
VIRT- ALLOC: 12M SHRD: 0M
IEF375I JOB/TEST /START 2016217.1207
IEF033I JOB/TEST /STOP 2016217.1207
CPU: 0 HR 00 MIN 00.00 SEC SRB: 0 HR 00 MIN 00.00 SEC
******************************** BOTTOM OF DATA ********************************
JESMSGLG reflects the below; notice the 'NOT_EXECUTED_STEP_TABLE' it shows S1 as not-executed, which means that even before the IEFBR14 processing could happen, SMS encountered an error and stopped any further execution of the job, which is also evident from JESYSMSG:
Code:
IEF403I TEST - STARTED
-
-JOBNAME STEPNAME PROCSTEP RC EXCP
-TEST S1 FLUSH 0
IEF453I TEST - JOB FAILED - JCL ERROR
-TEST ENDED. NAME-JOB
-NOT_EXECUTED_STEP_TABLE BEGIN
-JOBNAME STEPNAME PROCSTEP STEPNO
-TEST S1 1
-TEST S2 2
-NOT_EXECUTED_STEP_TABLE END
$HASP395 TEST ENDED
Edit: On further thought, answering my own question; since the step S1 didn't run following SMS error, and a step RC is actually the executed program's RC, hence the 'FLUSH'.
Abit, I know where to look and that is what I said by looking JES MESSAGES and what I have said is being tested and no theory talk, look for you installation guide why wasn't it same as mine rather what could be possible deciding parameters that would scratch and recatalog the DS if exist already, you site support staff should be able to explain.
