Validating TSO node id in Job

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

Nic Clouston · Posted: Thu May 05, 2016 7:14 pm

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.

prino · Posted: Thu May 05, 2016 8:46 pm

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.

Nic Clouston · Posted: Fri May 06, 2016 12:52 am

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.

Rohit Umarjikar · Posted: Fri May 06, 2016 1:10 am

Welcome!!
You must have separate jcllib for test jobs other than production one.
So provide

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).

.

Rohit Umarjikar · Posted: Fri May 06, 2016 1:22 am

RahulG31 · Active User Joined: 20 Dec 2014 Posts: 446 Location: USA

Rohit Umarjikar · Posted: Fri May 06, 2016 2:04 am

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.

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:

Rohit Umarjikar · Posted: Fri May 06, 2016 10:10 am

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.

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

Willy Jensen · Posted: Fri May 06, 2016 2:34 pm

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:

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.

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

Rohit Umarjikar · Posted: Fri May 06, 2016 7:19 pm

enrico-sorichetti · Posted: Fri May 06, 2016 7:27 pm

and ...