View previous topic :: View next topic
|
Author |
Message |
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
I have the following piece of JCL:
Code: |
//PSTEP005 EXEC PGM=ICETOOL
//TOOLMSG DD SYSOUT=*
//DFSMSG DD SYSOUT=*
//IN DD DISP=SHR,DSN=COXDAVI.JOBDATA.EXTRACT
//TOOLIN DD DISP=SHR,DSN=COXDAVI.ICETIN
//**** *TOOLIN DD *
//**** * SET RC=0 IF THE 'IN' DATA SET IS EMPTY, OR
//**** * SET RC=4 IF THE 'IN' DATA SET IS NOT EMPTY
//**** COUNT FROM(IN) EMPTY RC4
//*********************************************************************
//* SENDING AN EMAIL USING IDCAMS UTILITY
//**********************************************************
//* NOTE: INPUT FILES NEED TO BE THE SAME LRECL *
//************************************************
// IF PSTEP005.RC = 4 THEN
//SMTPMAIL EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD DISP=SHR,DSN=COXDAVI.JSCAN.HEADER.MSG
// DD DISP=SHR,DSN=COXDAVI.JOBDATA.EXTRACT
//SYSUT2 DD SYSOUT=(B,SMTPPROC)
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// ENDIF
//******************************************************************
// IF PSTEP005.RC = 4 THEN
//CLEAR EXEC PGM=IEBGENER
//SYSIN DD DUMMY
//SYSUT1 DD DUMMY,DCB=COXDAVI.JOBDATA.EXTRACT
//SYSUT2 DD DSN=COXDAVI.JOBDATA.EXTRACT,DISP=OLD
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// ENDIF
//*
|
When the return code is 4, I want to go ahead and do the last two steps. This works fine.
When the return code is 0, I receive the following:
Code: |
-
-STEPNAME PROCSTEP RC EXCP CONN TCB
-STEP01 STEP01 00 675 473 .00
-STEP01 PSTEP005 00 26 7 .00
-STEP01 SMTPMAIL FLUSH 0 0 .00
-STEP01 CLEAR FLUSH 0 0 .00
|
This is a good result.
My question is: If PSTEP005 ends with 00 as above, is there a way to NOT have the system indicate the FLUSH results as above ?
Thanks for any assistance with this question.
Dave |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
No way that i'm aware of. . .
The steps were flushed and are being reported as such. I believe that to do otherwise (even if some wanted this) would be incorrect. |
|
Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
Hi Dick,
The reasoning behind this request is that rc of 4 means that there is data in the COXDAVI.JOBDATA.EXTRACT file that will be emailed to our Production Support folks so that they can discuss the data ( errors in Jobscan ) with the Applications staff doing the scan. RC of 0 means that the scan is clean and no further action is necessary. The PSTEP005 is just indicating whether the file is empty or not, and setting the appropriate RC out of PSTEP005.
Dave |
|
Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
Thanks for looking at the question anyway. Dick is correct to say why the FLUSH indicator is set ( because it really is flushing through the last two steps - not executing them - on RC of 00 ).
Still pertinent to the question: Does anyone know how to manipulate the return code indicator whether it is a numeric value or something like " FLUSHED " ? |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
The "return code indicator" is set by the system and once set cannot be reset.
This is the same type of question as when somone wants to change the value of the return code of some previous step (which also cannot be done). |
|
Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
I am just about to give up on this idea.
However, being stubborn, I would like to ask if ICETOOL can conditionally stop the execution of a job ? I have already tried MODE STOP, but that doesn't act externally on the rest of the steps in the job.
Should I close this out and start a new question on the DFSORT/ICETOOL forum ? I have unsuccessfully searched that already and come up with nothing that will do what I want done. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
I would like to ask if ICETOOL can conditionally stop the execution of a job ? |
As far as i know, ICETOOL, SORT, DFDSS, IDCAMS, and others ad infinitum can cause an abend and still not produce what you have described as the goal.
If a job has n steps and step n-4 abends, all of the steps will still be visable in that output. . . 'Cause that is the way it is designed. . .
Why is this an issue? What business requirement might this address?
Quote: |
Should I close this out and start a new question on the DFSORT/ICETOOL forum ? I have unsuccessfully searched that already and come up with nothing that will do what I want done. |
The replies will still not be what you want. . . You need to keep focus that the system is working exactly as intended.
One way to do what you want is to run a predecessor job that does a "look ahead" and determines if the last 2 steps should run or not and then submit a "full" job or a job minus the last 2 steps thru the Internal Reader (there are multiple topics about using the Internal Reader in the forum). Adds a bunch of unneeded complexity for no actual value and may waste some amount of system resources, but it would prevent the current FLUSH presentation. . . |
|
Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
It is an issue to me due to the fact that the first step is actually JCL for the Jobscan proc that controls batch and foreground scans off the validation panels as well as Edit macro scans. Within that proc, I am running a COBOL program which checks site standards against Application Development staff's JCL. If any validation errors occur, they get written to a file in the code, then I take that file ( after using ICETOOL to check for empty or not empty ) if not empty into a SMTPPROC email step. The issue comes when these developers call and say " My job doesn't look right. I ran and got no errors on the scan, but the job itself didn't end right. Two steps flushed ". See ? I am trying hard to keep this as uncomplicated as I can for the developers. Perhaps I won't be able to do so. If that's the case, so be it. I write a nice email explaining what's happening with their batch scans and move on.
The batch comes out of a user's online session dealing with validation panels off ISPF, but I appreciate your comments on a look-ahead job. Sounds like it would work in a regular batch stream quite well.
Yep, I appreciate keeping my eye on what's important, and that the system works as designed with the flush. As I explained above, I am trying to find a way to not see the flush steps.
I will try briefly over at ICETOOL and see what shakes out.
Thanks Dick for your attention to my question. I appreciate it.
Dave |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Quote: |
I will try briefly over at ICETOOL and see what shakes out. |
Please refrain from posting the same question in multiple forums. See posting guidelines. |
|
Back to top |
|
|
coxdavi
New User
Joined: 12 Mar 2009 Posts: 30 Location: usa
|
|
|
|
Terry, this question in this forum was concerning JCL and how to achieve what I want through controlling JCL. The reason I want to go over to ICETOOL is because I feel maybe ICETOOL has the capability to do what I want to get done, and this forum came up dry. In my mind, there is enough of a separation between JCL and ICETOOL to justify asking two different questions in two separate forums which are both applicable to my questions. I hope that moderators will see that I am not playing games here, and am really trying to get something done. If not, then I will do something else. It is a fine set of forums with a lot of knowledge that has already helped me several times, and I would not want to be in a position of being banned. Thanks again for your concern.
Dave |
|
Back to top |
|
|
|