Posted: Sat Sep 17, 2005 10:39 pm Post subject: passing parameters in JCL
Hi Experts,
I have the below requirement:
we have a cobol program which has to be executed indifferent LPARs. based on the LPAR certain parameters in the jcl will change.
currently, we are executing a step in the JCL to find in which LPAR this program is running. Based that we are setting the return code. In the next step we are passing the certain parameters based on the return code of the previous step.Suppose if the LPAR is 1T01, we are setting return code to 1, if LPAR is 1T02 then we are setting the return code to 2 and so on. there are totally 8 LPARs. so in worst case we are setting return code to 8. This is causingthe problems when the job completed. our CA7 is showing that, the job is abended due to the return code is greater than 6.
my question:
is there any other parameter available to use, instead of the return code.
please let me know if more details are required.
Thanks,
Yugee
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Sat Sep 17, 2005 11:20 pm Post subject:
Is there a reason you need to use more than 1 step? Can the program that determines the LPAR also just call the COBOL program? That should only require adding the DD statements from the 2nd step to the 1st step and modifying the program to do the call. If the program finding the LPAR is Rexx running within TSO (IKJEFT01) then it should be a trivial change to the Rexx program to optionaly do the allocaitons and call the COBOL program directly via the TSO CALL command. You didn't specify exactly how you are determining the LPAR name.
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Sun Sep 18, 2005 1:12 pm Post subject:
It looks like the LPAR name comes out of the ECVT (CVT->CVTECVT->ECVTLPNM or try TSO ISRDDN B 10.?+8C?+158) where ECVTLPNM is blank if not in LPAR mode. My system real system this has a correct value, on my 2nd level system it is blank.
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
Posted: Sun Sep 18, 2005 5:08 pm Post subject:
semigeezer,
I tried TSO ISRDDN B 10.?+8C?+158) and on the first line I got the name of the test region. Is this information stored in any of the system variables ? like ZSYSID ? or ZSYSNODE ? Is this information available in option 7.3 from tso?
Kolusu _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
yugee,
You can set the MAX RC for this job to 08 in CA7. It should not abend the job, however this is temporary workaround, not the right way to do things. thanks
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Sun Sep 18, 2005 8:21 pm Post subject:
Kolusu, to tell you the truth, I haven't kept up with what each of those varaiables actually contains. I'd guess that zsysnode is the node you' use on an XMIT command and that is probably maintained by JES. I'm not sure where ZSYSID comes from.
Dialog test variables are all visible in 7.3, but since some of the values from the various places to get a system name can be the same, that alone is not enough to determine the origin of the information. I suspect it is in the books too, but like I said, I just haven't checked lately.
SYSID = SUBSTR(SYSNAME,1,4)
SELECT
WHEN(SYSID='TA01') THEN RCODE='1'
WHEN(SYSID='TA02') THEN RCODE='2'
WHEN(SYSID='TA03') THEN RCODE='3'
END
RETURN(RCODE)
EXIT
----------------------
If you see the JCL, there are certain parameters, i mean LOADLIBs change from one LPAR to another LPAR. suppose if the program is running in 'TA08' then the RETURNCODE will be 8 which is causing the problem.
please suggest me some good approach to handle this situation.
Hi Kolusu,
Thanks for ur suggestion. I think it will solve my problem almost..but in this case i need to have 8 different JCLs. is there any way i can handle this in a single JCL itself..
As per the standards, i can not have all my job statements in the REXX code. and also as part of the change contraol we are having one more step to execute another program in the same job. what i am looking for is, is there any parameter i can pass from REXX code instead of RCODE based on the LPAR. What ever the information u guys have provided is definitely going to help me.thanks a lot for ur suggestions..
Yugee
Joined: 03 Jan 2003 Posts: 1014 Topics: 13 Location: Atlantis
Posted: Wed Sep 28, 2005 12:22 am Post subject:
I don't understand why you want to do this at all since all of the constraints are very artificial (1 job stream for multiple LPARs, invocation through a separate non-TSO JCL step for every program, max RC of 7, etc...) Certainly submitting 8 separate jobs, or having a job step that submits the appropriate job through the TSO SUBMIT command (IKJEFT01) would be easier than trying to fit all this processing into these artificial conditions. But to answer your question, to control the flow of steps in JCL, all you have is the condition code. There are times when using JCL is the correct way to do things. This, apparently, is not one of those times.
So here is the 2nd worse suggestion I've ever made on one of these boards (the worst involved using TSO TEST to dynamically write and execute machine level code like SVCs directly from Rexx). Although technically feasible, rest assured, it is not a serious suggestion!!
If you have to check for more than 8 values using condition codes that can not exceed 7, you can probably use separate steps and treat the return codes as octal. That is a 1st step returns the 1st digit of an octal number and the 2nd step returns the 2nd digit. Then you use COND or IF/THEN logic in the JCL to check the output of 2 steps instead of 1. Then you have up to 64 conditions. Use 3 steps (digits) and you have up to 512 possible conditions.
Yes, this is a ridiculous way to do things, and anyone who put that into production should be fired immediately, but it is theoretically possible.
Oh. And that #1 worst suggestion I mentioned? See 'ISP.SISPCLIB(ISRSVC2X)'. It calls SVCs 26 and 27 from a CLIST. This code was written by a professional lunatic. Don't try this at home
Joined: 03 Dec 2002 Posts: 127 Topics: 0 Location: Europe
Posted: Wed Sep 28, 2005 2:05 am Post subject:
trying to guess who's the lunatic...
Code:
/* Instructions: */
/* This must be run from the TSO TEST ready prompt */
/* Eg: ISRSVC2X NADEL.CLIST PRM903 LOCATE */
/* ISRSVC2X NADEL.CLIST PRM903 OBTAIN */
/* */
Joined: 26 Nov 2002 Posts: 12370 Topics: 75 Location: San Jose
Posted: Wed Sep 28, 2005 7:40 am Post subject:
Yugee,
How about using a SET statement ? You can set a number depending on the lpar , instead of a return code. Once you set the value, then you can just INCLUDE it in the JCL.
Create a PDS member named SETLPAR
Now your REXX will create the member SETLPAR
Code:
SETTING = MSG('OFF')
SYSNAME = MVSVAR(SYSNAME)
SYSID = SUBSTR(SYSNAME,1,4)
SELECT
WHEN(SYSID='TA01') THEN
write to pds member set lpar with the following info
'// SET LPAR=1 '
WHEN(SYSID='TA02') THEN
write to pds member set lpar with the following info
'// SET LPAR=2 '
WHEN(SYSID='TA03') THEN RCODE='3'
write to pds member set lpar with the following info
'// SET LPAR=3 '
...
END
Now you will have another Job which will have the set statement included.
// INCLUDE MEMBER=SETLPAR <==== INCLUDE THE LPAR NUMBER
//*******STEP to extetue the program in TA01 LPAR
// IF &LPAR EQ 1 THEN
//S0200 EXEC PGM=PUTMQMSG
//STEPLIB DD DISP=SHR,DSN=SYSA.MQLOD1.USERAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD1.SCSQAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD1.USERLOAD
//INFILE DD DISP=SHR,DSN=TEST.INPUT.FILE
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// ENDIF
//*******STEP to extetue the program in TA02 LPAR
// IF &LPAR EQ 2 THEN
//S0200 EXEC PGM=KTCMSGFM
//STEPLIB DD DISP=SHR,DSN=SYSA.MQLOD2.USERAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD2.SCSQAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD2.USERLOAD
//INFILE DD DISP=SHR,DSN=TEST.INPUT.FILE
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// ENDIF
//*******STEP to extetue the program in TA03 LPAR
// IF &LPAR EQ 3 THEN
//S0200 EXEC PGM=KTCMSGFM
//STEPLIB DD DISP=SHR,DSN=SYSA.MQLOD3.USERAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD3.SCSQAUTH
// DD DISP=SHR,DSN=SYSA.MQLOD3.USERLOAD
//INFILE DD DISP=SHR,DSN=TEST.INPUT.FILE
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
// ENDIF
**--------like this we have 8 STEPs--------**
// IF &LPAR EQ 8 THEN
//REFABND4 EXEC PGM=ABNDPRGM
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=I
// ENDIF
The IF clause is then expanded during the run time which will result as
Code:
// IF 1 EQ 1 THEN
By doing so you don't have worry about the return codes.
Hope this helps...
Cheers
Kolusu _________________ Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Quick Manuals
Register
Profile
Log in to check your private messages
Log in
