View previous topic :: View next topic |
Author |
Message |
coolman Intermediate
Joined: 03 Jan 2003 Posts: 283 Topics: 27 Location: US
|
Posted: Mon Aug 21, 2006 2:33 pm Post subject: Authority to execute Load Modules |
|
|
I'm facing an interesting challenge
Say, you have a job with a no. of steps executing different programs including transmissions. I do not want to run these transmission steps. The one way to do it is condition out the steps you don't want to. But the problem with this approach is say you have a job with over a 1000 lines, it becomes difficult to do it for a lot of these steps and programmers at my shop tend to forget doing it causing a lot of issues that a production file getting overwritten or a production dataset gets printed causing unnecessary confusion.
Now, is there an alternative to doing this -
1. Like for example, when the TSO ID submitting the job is not the production scheduler id, remove the authority to execute the load modules like FTP, Connect Direct Steps etc...
2. Code SDSF exits to parse the job and comment out the unwanted steps
These were some things that came to my mind but I haven't done anything on this before - Can you all please give suggestions and ideas so that I can take it forward.
________
The Henry Ford picture
Last edited by coolman on Sat Feb 05, 2011 1:50 am; edited 1 time in total |
|
Back to top |
|
|
superk Advanced
Joined: 19 Dec 2002 Posts: 684 Topics: 5
|
Posted: Mon Aug 21, 2006 2:52 pm Post subject: |
|
|
#1 sounds good (suprised that they even have that authority to begin with). |
|
Back to top |
|
|
Bithead Advanced
Joined: 03 Jan 2003 Posts: 550 Topics: 23 Location: Michigan, USA
|
Posted: Mon Aug 21, 2006 3:22 pm Post subject: |
|
|
Is this meant to test job streams without actually transmitting the data? If so, you can add a joblib to the job in test and then create dummy FTP and Connect Direct executables that are simply GOBACKs. We do this for Disaster Recovery testing.
I would assume that you would get an error if the user does not have security which should flush the job. |
|
Back to top |
|
|
coolman Intermediate
Joined: 03 Jan 2003 Posts: 283 Topics: 27 Location: US
|
Posted: Mon Aug 21, 2006 3:30 pm Post subject: |
|
|
Yes Bithead, that's exactly the purpose. But the problem is adding a joblib in test - We'll have to do it for every job in the job stream. And on top of it, here are a few problems:
1. If a user unwantedly remove this joblib , then we have the same problem.
2. Everytime a job or proc gets changed, the programmers would check out the latest job from prod and that means this joblib has to be added everytime
The workaround I'm looking at here is even if the user misses doing his part, the transmission shouldn't happen (not necessarily flush out), but even if it does a dummy transmission or anything of that kind, that would solve the purpose.
My MVS Sysprogs are too busy to help me with their ideas..Huh..
________
cannabis seeds
Last edited by coolman on Sat Feb 05, 2011 1:51 am; edited 1 time in total |
|
Back to top |
|
|
dz Beginner
Joined: 02 Apr 2006 Posts: 26 Topics: 0
|
Posted: Tue Aug 22, 2006 8:55 am Post subject: |
|
|
We have a similar situation here (related to FTPing/not FTPing file based on a date), and here is how we've solved it. We have a special all-purpose DB2 table, where we keep various parameters for different runs. One of them is related to the date after which a given file should be FTPed. It also has actual FTP commands. Then, we DB2 unload from that table where date > <specified date> (in your case, it could be where used id = <authorized used ID>). So, FTP cards are only built for those files that do need to be transmitted.
Hope this helps... |
|
Back to top |
|
|
|
|