|
View previous topic :: View next topic
|
| Author |
Message |
venkaraj
New User
Joined: 05 May 2016
Posts: 3
Location: India
|
|
|
|
Hi,
I need your help in this requirement.
I have a job which has 4 steps. STEP01, STEP02, STEP03 and STEP04. STEP01 and STEP02 are data process steps, STEP03 check the output of STEP02 and if it is empty, STEP04 will not be executed, else it will be executed. STEP04 send the output to external server for verification
While doing testing, by mistake if they forget to comment out STEP04, test results too will go to external server, which causes issues, even though testing is done in TEST region.
The requirement is that when this job runs in production region say TSOP, all 4 steps to be executed, and when it runs in test region say TSOD, STEP04 should not be executed.
I tried with manual validation by giving a // SET and IF condition, but business is not confident on this as the tester may forget to change the value in SET which results in again results going to external server.
How can I give a // SET by reading TSO environment and prevent STEP04 being suppressed from execution in test region say TSOD instead of manually modifying the value.
When I invoke the job in TEST region, SET command should recognize TEST region and STEP04 should be suppressed.
When it normally runs in PRODUCTION region, SET command should recognize PRODUCTION region and should be executed.
Can this be done using some utilities.
Can somebody provide help in this regard for the changes required in the job.
Thanks in advance |
|
| Back to top |
|
 |
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
Moved - as it has nothing to do with employment opportunities.
Simply have a different procedure in your testing region that does not have the thrd and fourth steps in it. |
|
| Back to top |
|
|
prino
Senior Member
Joined: 07 Feb 2009
Posts: 1316
Location: Vilnius, Lithuania
|
|
|
|
| In STEP03 add an additional bit of code to retrieve the jobname and assuming that production jobs are usually named quite differently from test jobs, set a returncode that stops STEP04 from being executed it run in a test region. |
|
| Back to top |
|
|
Nic Clouston
Global Moderator
Joined: 10 May 2007
Posts: 2454
Location: Hampshire, UK
|
|
|
|
| Even simpler - have steps 3 and 4 coded in an INCLUDE member in production and the corresponding member in test would be a simple comment to the effect that those 2 steps are not required in test for the reason stated. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
Welcome!!
You must have separate jcllib for test jobs other than production one.
So provide
| Code: |
| COND.stepname=(0,LE) |
to the proc like symbolic, this will ensure the step won't run.
I am surprised you don't have a proc and just direct JCL has the steps , so add this to the steps that you don't want to execute in test. |
|
| Back to top |
|
|
RahulG31
Active User
Joined: 20 Dec 2014
Posts: 446
Location: USA
|
|
|
|
Usually, there is a symbolic as a high level qualifier for datasets. Even if you are using the same production Proc for testing, you need to change that qualifier.
Now, you can have the address/directory location of external server in a dataset. Since, this information is static, you can have different values in Production dataset and Test dataset and that let's you run all the steps (and send the output to some internal test server).
. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
| Now, you can have the address/directory location of external server in a dataset. Since, this information is static, you can have different values in Production dataset and Test dataset and that let's you run all the steps (and send the output to some internal test server). |
There is more work and people got to be involved in to do so and why to waste resource for nothing as I don't think they want to see those FTP files in test otherwise they would have done that far back. Also there is a chance to use production server details instead of test in those control cards. but yeah He has now couple of choices to opt for. |
|
| Back to top |
|
|
RahulG31
Active User
Joined: 20 Dec 2014
Posts: 446
Location: USA
|
|
|
|
| Quote: |
| Also there is a chance to use production server details instead of test in those control cards. |
If somebody changes Test server details to Production server details then that is a deliberate action and Not a mistake we are trying to avoid.
. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
haha, I have seen people mistakenly copying prod server details to QA/test and forget to change latter to point QA server 
btw , I think in my shop such pushing of files to production servers are not allowed, the RACF level block or something. TS may wants to see that with the support staff out there to see how can that be blocked so that even somebody does the job fails right away in authenticating the user. |
|
| Back to top |
|
|
boyti ko
New User
Joined: 03 Nov 2014
Posts: 78
Location: Malaysia
|
|
|
|
You can make a simple Rexx program to output and check if it's TSOP or TSOD using this code:
Also in that Rexx, give a certain return code for TSOP and/or TSOD. Then base on the return code of the step with the Rexx program, you may run or not run the succeeding step. |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
There are couple of things
1. Why are you not using proc instead of just jcl?
2. if you are using production proc then you must have different JCL lib for all your test jobs which are calling production proc, if you don't have then why or if you have then WHy are you ignoring COND parameter?
3. Talk to your transmission group (if you have any )they will tell you how to block pushing files to external server in production from test region.
Unless you fix these points it is usless to write any code or conditions around this problem as on a bigger scale it shows that there is no process in place at your shop and other procedures runs in test region are at high risk. |
|
| Back to top |
|
|
venkaraj
New User
Joined: 05 May 2016
Posts: 3
Location: India
|
|
|
|
Thanks for all your suggestion. Changing proc and JCL Libraries may not be taken care by resources. They will just submit the job.
I found in SAS there is an automatic macro variable SYSTCPIPHOSTNAME which contains the details of host name and it is different for each regions. In SAS program if I use %PUT &SYSTCPIPHOSTNAME, I am able to see the details, but when I try to assign this to a normal variable, it is throwing error. I gave the following
HOST = '&SYSTCPIPHOSTNAME; and this failed
I tried with CALL SYMPUT('HOST',&SYSTCPIPHOSTNAME); and this too failed.
Can some SAS expert give suggestion how to get the value in SYSTCPIPHOSTNAME into a SAS variable. This will help me in trapping the execution by just include this SAS program before the step to be trapped....
Thanks |
|
| Back to top |
|
|
Willy Jensen
Active Member
Joined: 01 Sep 2015
Posts: 736
Location: Denmark
|
|
|
|
Perhaps overkill for this, but I have implemented a more general approach. The following REXX program will run the parameter, either by setting the code directly, or by evaluating the parameter:
| Code: |
if datatype(arg(1))='NUM' then exit arg(1)
signal on syntax
signal on error
Interpret "cc=("arg(1)")"
Exit cc=0
Syntax:
Error:
exit 99
|
Now create a procedure like this.
| Code: |
//SETRC EXEC PGM=IKJEFT1B,PARM='SETRCX &P'
//SYSEXEC DD DISP=SHR,DSN=your.exec.lib
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD DUMMY
|
And run it:
| Code: |
//T1 EXEC SETRCX,P='MVSVAR(SYSNAME)=SYSA'
|
rc=0 -> system is indeed SYSA |
|
| Back to top |
|
|
Abid Hasan
New User
Joined: 25 Mar 2013
Posts: 88
Location: India
|
|
|
|
Maybe another approach; DFSORT has been allowing SYSVARs to be used as symbolics for a long while, rig up a simple DFSORT which tests your SYSVAR's value using a simple conditional check; please note that you'll have to use SYMNAMES to set the SYSVAR. Use this conditional check in DFSORT to set a return-code; test this return code in the steps in question; bypass or execute - your choice.
Another approach (only if you've z/OS 2.1 or higher), JCL can use SYSVAR as symbolics; test it with REXX/DFSORT or a tool/prog of your choice, set an RC, and test the RC in steps you want executed/bypassed (something similar to Mr. Jensen's solution).
Hth. |
|
| Back to top |
|
|
venkaraj
New User
Joined: 05 May 2016
Posts: 3
Location: India
|
|
|
|
Thanks everybody. Even though the developer/tester/user may not change entire proc to comment out the step, for sure they have to change the job id in the job card to run the job in test environment as it will not accept production job id.
With this approach, I managed to create a small sas program to validate the first 8 character of SYSJOBID automatic macro and if it is not equal to production job id, then it will suppress execution of STEP04 in test region. Same job when it runs in production run, the job id matches and it continue to execute the STEP04. With this approach I hope user/tester/developer need not do bulk of change in the job/proc.
Our application will not allow using REXX in production region.
Thanks |
|
| Back to top |
|
|
Rohit Umarjikar
Global Moderator
Joined: 21 Sep 2010
Posts: 3076
Location: NYC,USA
|
|
|
|
| Quote: |
Changing proc and JCL Libraries may not be taken care by resources
|
untrained Robots.
| Quote: |
| With this approach, I managed to create a small sas program to validate the first 8 character of SYSJOBID automatic macro and if it is not equal to production job id, then it will suppress execution of STEP04 in test region. Same job when it runs in production run, the job id matches and it continue to execute the STEP04. With this approach I hope user/tester/developer need not do bulk of change in the job/proc. |
Too dangerous to go with this approach, what if a new prod region gets added tomorrow, you will simply lose the file and again change this logic and keep doing as and when a new region adds up. most importantly,you need to have a proper process in place which is the cause of such issues and it will be there till you don't create separate jcls for test and prod regions keeping the same proc though. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10889
Location: italy
|
|
|
|
and ...
| Quote: |
While doing testing, by mistake if they forget to comment out STEP04, test results too will go to external server, which causes issues, even though testing is done in TEST region.
|
sooner or later they will have to test that things get shipped over  |
|
| Back to top |
|
|
|
|
