Page 2 of 3

Re: usage of JOBRC parameter

PostPosted: Tue May 22, 2012 9:18 am
by ibmmf4u
Hi Dick,

I completely agree with you. But there were the cases where the connection timed out in step010 and it got connected in another attempt of step020. In this scenario the job fails even though it ran fine in step020. we just wanted to avoid such kind of failures by looking into one of the succesfull return codes of the job.

Hi Akatsukami,

I was yet to use the same but don't know where and how to use the parameter. When i tried using it on the job card it was giving me an error
"UNKNOWN KEYWORD "JOBRC" SPECIFIED IN OPERAND OF "JOB" " the one which i earlier posted . So wanted to know where and how it can used properly.

Re: usage of JOBRC parameter

PostPosted: Tue May 22, 2012 9:27 am
by dick scherrer
Hello,

"Someone" needs to determine why these timeouts occur. . . What happens when there is a bad traffic day and all 3 fail?
Does the process get changed to try 6 times?

I believe if this approach continues and is propogated to more processes, there will be lots of "opportunities" to deal with crisis.

Re: usage of JOBRC parameter

PostPosted: Tue May 22, 2012 4:15 pm
by Akatsukami
ibmmf4u wrote:Hi Akatsukami,

I was yet to use the same but don't know where and how to use the parameter. When i tried using it on the job card it was giving me an error
"UNKNOWN KEYWORD "JOBRC" SPECIFIED IN OPERAND OF "JOB" " the one which i earlier posted . So wanted to know where and how it can used properly.

The JOBRC parameter certainly goes on the JOB card. I think that it is time that you showed your JCL...and some evidence that your site is indeed running z/OS V1.13.

Re: usage of JOBRC parameter

PostPosted: Tue May 22, 2012 6:19 pm
by BillyBoyo
I hope that R at the end of the version of z/OS you quoted doesn't mean you are telling us the Syncsort version by accident :-)

Re: usage of JOBRC parameter

PostPosted: Wed May 23, 2012 12:30 am
by ibmmf4u
Hi Dick,

If it fails all the three times then its a genuine reason of failure and we shall look into it . But in this scenario we are getting paged even it ran fine in second or third step and failed in first step. I guess if the process is changed to 6 times we shall be getting the same abend even if it went fine in one of the steps. our aim is to eliminate the failure by setting up the return code if it passes in one of the three steps.

Thanks a lot .

Hi Akatsukami,

We are currently using z/OS 01.13.00 version in our shop. Pasted below were the screen shots of the same , when i do an 'c' i can find the current release which tells us the version which we are using. The code i was keep on trying the same job by placing the JOBRC parameter on the job card which i mentoined earlier

Operating System   z/OS 01.13.00   PUT1112 RSU1204 MH1204 CL0512




Tutorial    ---------- z/OS 01.13.00 ISPF ----------    Tutorial 
Option ===>                                                      
                                                               
Select option for information about the desired release or 
press    ENTER    for current release information.               
                                                                  
Current Release Changes                                       
1     z/OS 01.13.00 ISPF                                          
                                                           
Previous Release Changes                                       
2     z/OS 01.12.00 ISPF                                          
3     z/OS 01.11.00 ISPF                                          
4     z/OS 01.10.00 ISPF                                          
5     z/OS 01.09.00 ISPF                                          
6     z/OS 01.08.00 ISPF                                          
7     z/OS 01.07.00 ISPF                                          



Thanks,


Hi Bill,

Ha ha :D Nope. I was refering to the z/OS 1.13 version :) ;)

Thanks,

Re: usage of JOBRC parameter

PostPosted: Wed May 23, 2012 1:03 am
by dick scherrer
Hello,

It appears i was not clear enough in my last reply. My point was/is that the timeouts need to be resolved. . . I did NOT mean to imply that more "just in case steps" should be added to the process.

The systems i support send hundreds of files (or retrieve them) every day and i'm not aware of any timeouts. If an entire remote is "down" (i.e. for maintenance or whatever), the connection will fail rather than timeout.

Re: usage of JOBRC parameter

PostPosted: Wed May 23, 2012 1:09 am
by dick scherrer
Hello,

Re-reading this entire topic, i believe there is no reason to use JOBRC. . . Maybe i've misunderstood.

If what is wanted is to end the process when any of the ftp steps is successful, why not just do cond= testing. The second and third steps would be skipped if the first step was successful. The 3rd step sould be skipped if the second step was successful. If the third step failed, the page would be issued.

As i mentioned, maybe there is something i don't yet understand.

Re: usage of JOBRC parameter

PostPosted: Wed May 23, 2012 2:58 am
by MrSpock
For what it's worth, I noticed today that we're also on z/OS V1R13. I was just trying out the JOBRC parameter as well as instream data within a cataloged procedure. Neither seems to work as documented, so I'm wondering if the installs allow the systems programmers to either disable these or override them.

I did notice that now you get a message like

$HASP165 JOB1 ENDED AT LPAR MAXCC=0000 CN(INTERNAL)

with the four-digit MAXCC code.

Re: usage of JOBRC parameter

PostPosted: Wed May 23, 2012 3:11 am
by MrSpock
Just tried the same stuff on our Development/UAT LPAR, and son of a gun it works. Will have to dabble around a little bit with it.

Re: usage of JOBRC parameter

PostPosted: Thu May 24, 2012 12:00 am
by ibmmf4u
Hi Dick,

Thanks for your inputs. The process is FTP'ing a file to destination it is using a proc to do this. The proc contains of three steps which does the same FTP in all the three steps in case of a failure of other.Now if there's an FTP failure in STEP010 a Return code of more than zero will be issued(there might be some reason behind stating the server not available for that fraction of seconds) and it will be retried in next stop.If it passes through that step (say STEP020 ) our job is failing as it's picking up the maximum return code of the failed STEP010 in the earlier attempt.

Now that we are trying to fix this by overriding the retrun code of the job with the help of JOBRC parameter which got intorduced in z/OS 1.13 version.

Hi Spock,

Thanks a lot . Can you let me on how to use this parameter in our JCL. Pasted below is the code that i have been working on.

JOB:-
=====================================
//xxxxxxxx JOB (xxxx,XXXXXX,,,),'JOB RC',CLASS=H,           
// NOTIFY=&SYSUID,REGION=16M,MSGCLASS=U,JOBRC=(STEP,PROCTST[.STEP030])
//PROCLIB JCLLIB ORDER=PROC.DATASET                               
//STEP060 EXEC PROCTST                                               


PROC:-
=====================================
//STEP010  EXEC PGM=IEFBR14                 
//STEP020  EXEC PGM=IEBGENER               
//SYSOUT   DD   SYSOUT=*                   
//SYSPRINT DD   SYSOUT=*                   
// IF (STEP010.RC = 0 | STEP020.RC = 0) THEN
//STEP030  EXEC PGM=IEFBR14                         
 // ENDIF                                   



Kindly help me out with this.

Thanks in advance!!!!

Hi Akatsukami,

Above pasted is the code that i have been working on.

Thanks,