IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

JCL MULTIPLE STEP EXECUTION QUERY


IBM Mainframe Forums -> JCL & VSAM
Post new topic   This topic is locked: you cannot edit posts or make replies.
View previous topic :: View next topic  
Author Message
Susanta

Active User


Joined: 17 Nov 2009
Posts: 126
Location: India

PostPosted: Sat Jul 30, 2016 1:17 pm
Reply with quote

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?

Code:
//XYZ8S901 JOB 1234 "JOB" ,CLASS=X,MSGCLASS=Y,REGION=0M,
//            NOTIFY=&SYSUID,TIME=(2,0)
//S1 EXEC PGM=IEFBR14
//D2 DD DSN=MY.FILE,DISP=(NEW,CATLG,DELETE),
//      SPACE=(TRK,(100,100),RLSE),
//      DCB=(RECFM=FB,LRECL=10,BLKSIZE=1000),UNIT=UNITDEV
//*
//S2  EXEC PGM=IEFBR14
//D1 DD DSN=MY.FILE,DISP=(MOD,DELETE,DELETE),SPACE=(TRK,0)



tHANKS in advance..
[/code]
Back to top
View user's profile Send private message
Willy Jensen

Active Member


Joined: 01 Sep 2015
Posts: 712
Location: Denmark

PostPosted: Sat Jul 30, 2016 3:47 pm
Reply with quote

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.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Sat Jul 30, 2016 5:45 pm
Reply with quote

You are laboring under two falsehoods.
  • IEFBR14 always terminates with RC = 0. There is no concept of “no return code.” All programs end with a return code.
  • This JCL will fail if the system cannot allocate or delete MY.DS.
    Code:
    //S1      EXEC PGM=IEFBR14
    //S1DS     DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
    //             DSN=MY.DS
    //S2      EXEC PGM=IEFBR14
    //S2DS     DD  DISP=(,CATLG),UNIT=UNITDEV,SPACE=(TRK,(100,100)),
    //             DCB=(RECFM=FB,LRECL=10,BLKSIZE=1000),DSN=*.S1.S1DS
    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.
Back to top
View user's profile Send private message
Willy Jensen

Active Member


Joined: 01 Sep 2015
Posts: 712
Location: Denmark

PostPosted: Sat Jul 30, 2016 6:49 pm
Reply with quote

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]
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Sat Jul 30, 2016 7:44 pm
Reply with quote

Of course the OP's JCL will fail if the data set exists. IEFBR14 is never entered because of the JCL error.

In case you didn't notice, my JCL switches the OP's two steps.
Back to top
View user's profile Send private message
Susanta

Active User


Joined: 17 Nov 2009
Posts: 126
Location: India

PostPosted: Sat Jul 30, 2016 8:17 pm
Reply with quote

Thanks.. ..both Willy/Steve..

now i understand ..a specific step can produce non zero return code only if it executes idcams/cobol/proc .. is this true..

is there any thumb rule to know type of steps that can produce other than 0 RC and
not a flush.
Back to top
View user's profile Send private message
Akatsukami

Global Moderator


Joined: 03 Oct 2009
Posts: 1788
Location: Bloomington, IL

PostPosted: Sun Jul 31, 2016 12:46 am
Reply with quote

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).
Back to top
View user's profile Send private message
Susanta

Active User


Joined: 17 Nov 2009
Posts: 126
Location: India

PostPosted: Sun Jul 31, 2016 2:47 am
Reply with quote

thanks a lot ..it was enlightening.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Sun Jul 31, 2016 5:44 am
Reply with quote

Susanta wrote:
now i understand ..a specific step can produce non zero return code only if it executes idcams/cobol/proc .. is this true..

All programs "return" a return code. The return code, and what it means, is up to the program. A very rough guide -

  • 0 - Program did everything that was requested, no errors or warnings.
  • 4 - A warning of some sort was encountered. The program took some sort of default action to continue execution.
  • 8 and 12 - The program encountered a severe problem. Some, or perhaps all, tasks were not completed.
  • 16 - A severe error was encountered that prevented the program from doing much of anything.
Why 0, 4, 8 and 16? I have a theory, but not here.
Susanta wrote:
is there any thumb rule to know type of steps that can produce other than 0 RC and
not a flush.
No.
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1041
Location: Richmond, Virginia

PostPosted: Mon Aug 01, 2016 6:32 am
Reply with quote

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.
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Mon Aug 01, 2016 7:12 am
Reply with quote

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.
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Mon Aug 01, 2016 8:58 am
Reply with quote

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.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Mon Aug 01, 2016 12:22 pm
Reply with quote

Quote:

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.


That is an assumption, based on nothing.

If one uses branch tables, one knows if the return code is a multiple of 4 AND the maximum return code returned.
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Wed Aug 03, 2016 11:20 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Thu Aug 04, 2016 12:20 pm
Reply with quote

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).
Back to top
View user's profile Send private message
steve-myers

Active Member


Joined: 30 Nov 2013
Posts: 917
Location: The Universe

PostPosted: Thu Aug 04, 2016 1:09 pm
Reply with quote

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).
I ran this JCL twice -
Code:
//AJOB JOB ...
//S1      EXEC PGM=IEFBR14                                   
//THEDS    DD  DISP=(MOD,DELETE),UNIT=SYSALLDA,SPACE=(TRK,0),
//             DSN=&SYSUID..XX.DATA                           
//S2      EXEC PGM=IEBGENER                                   
//SYSPRINT DD  SYSOUT=*                                       
//SYSIN    DD  DUMMY                                         
//SYSUT1   DD  DISP=SHR,DSN=&SYSUID..XX.CNTL                 
//SYSUT2   DD  DISP=(,CATLG),UNIT=SYSDA,SPACE=(TRK,(1,1)),   
//             DCB=(RECFM=FB,LRECL=80,DSORG=PS),DSN=*.S1.THEDS
First run -
Code:
IEF236I ALLOC. FOR XXXXXXJ S1
IGD101I SMS ALLOCATED TO DDNAME (THEDS   )
        DSN (XXXXXX.XX.DATA                              )
        STORCLAS (USER) MGMTCLAS (        ) DATACLAS (        )
        VOL SER NOS= FUSR19
IEF142I XXXXXXJ S1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I XXXXXX.XX.DATA                               DELETED,   DDNAME=THEDS
IEF373I STEP/S1      /START 2016217.0207
IEF374I STEP/S1      /STOP  2016217.0207 CPU    0MIN 00.01SEC SRB    0MIN 00.00S
IEF236I ALLOC. FOR XXXXXXJ S2
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I DMY  ALLOCATED TO SYSIN
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
        DSN (XXXXXX.XX.DATA                              )
        STORCLAS (USER) MGMTCLAS (        ) DATACLAS (        )
        VOL SER NOS= FUSR32
IEF142I XXXXXXJ S2 - STEP WAS EXECUTED - COND CODE 0000
IEF285I   XXXXXX.XXXXXXJ.JOB92528.D0000101.?           SYSOUT
IGD104I XXXXXX.XX.CNTL                               RETAINED,  DDNAME=SYSUT1
IGD104I XXXXXX.XX.DATA                               RETAINED,  DDNAME=SYSUT2
IEF373I STEP/S2      /START 2016217.0207
IEF374I STEP/S2      /STOP  2016217.0207 CPU    0MIN 00.06SEC SRB    0MIN 00.00S
IEF375I  JOB/XXXXXXJ /START 2016217.0207
IEF376I  JOB/XXXXXXJ /STOP  2016217.0207 CPU    0MIN 00.07SEC SRB    0MIN 00.00S
Second run -
Code:
IEF236I ALLOC. FOR XXXXXXJ S1
IGD103I SMS ALLOCATED TO DDNAME THEDS
IEF142I XXXXXXJ S1 - STEP WAS EXECUTED - COND CODE 0000
IGD105I XXXXXX.XX.DATA                               DELETED,   DDNAME=THEDS
IEF373I STEP/S1      /START 2016217.0207
IEF374I STEP/S1      /STOP  2016217.0207 CPU    0MIN 00.01SEC SRB    0MIN 00.00S
IEF236I ALLOC. FOR XXXXXXJ S2
IEF237I JES2 ALLOCATED TO SYSPRINT
IEF237I DMY  ALLOCATED TO SYSIN
IGD103I SMS ALLOCATED TO DDNAME SYSUT1
IGD101I SMS ALLOCATED TO DDNAME (SYSUT2  )
        DSN (XXXXXX.XX.DATA                              )
        STORCLAS (USER) MGMTCLAS (        ) DATACLAS (        )
        VOL SER NOS= FUSR11
IEF142I XXXXXXJ S2 - STEP WAS EXECUTED - COND CODE 0000
IEF285I   XXXXXX.XXXXXXJ.JOB92529.D0000101.?           SYSOUT
IGD104I XXXXXX.XX.CNTL                               RETAINED,  DDNAME=SYSUT1
IGD104I XXXXXX.XX.DATA                               RETAINED,  DDNAME=SYSUT2
IEF373I STEP/S2      /START 2016217.0207
IEF374I STEP/S2      /STOP  2016217.0207 CPU    0MIN 00.07SEC SRB    0MIN 00.01S
IEF375I  JOB/XXXXXXJ /START 2016217.0207
IEF376I  JOB/XXXXXXJ /STOP  2016217.0207 CPU    0MIN 00.08SEC SRB    0MIN 00.01S
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.
Back to top
View user's profile Send private message
Abid Hasan

New User


Joined: 25 Mar 2013
Posts: 88
Location: India

PostPosted: Thu Aug 04, 2016 1:37 pm
Reply with quote

Hello Mr. Myers,

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.

Code:

//TEST     JOB 1234,'JOB',CLASS=A,MSGCLASS=X,REGION=0M,     
//         NOTIFY=&SYSUID                                   
//S1 EXEC PGM=IEFBR14                                       
//D2 DD DSN=XXXX.YYYY,DISP=(NEW,CATLG,DELETE),               
//      SPACE=(TRK,(100,100),RLSE),                         
//      DCB=(RECFM=FB,LRECL=10,BLKSIZE=1000)                 
//*                                                         
//S2  EXEC PGM=IEFBR14                                       
//D1 DD DSN=XXXX.YYYY,DISP=(MOD,DELETE,DELETE),SPACE=(TRK,0)



********************************* 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'.
Back to top
View user's profile Send private message
Rohit Umarjikar

Global Moderator


Joined: 21 Sep 2010
Posts: 3048
Location: NYC,USA

PostPosted: Thu Aug 04, 2016 5:17 pm
Reply with quote

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.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Thu Aug 04, 2016 6:39 pm
Reply with quote

when a topic does not reach a conclusion after a reasonable number of replies
it should be locked !
and now it is.
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   This topic is locked: you cannot edit posts or make replies. View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts INCLUDE OMIT COND for Multiple values... DFSORT/ICETOOL 5
No new posts Replace Multiple Field values to Othe... DFSORT/ICETOOL 12
No new posts RC query -Time column CA Products 3
No new posts Return codes-Normal & Abnormal te... JCL & VSAM 7
No new posts Capturing Job Execution Information All Other Mainframe Topics 3
Search our Forums:

Back to Top