10+ years ago I created a generic process that allows you to parameterize 99% of your jcl including control cards. Using this method you can parameterize everything except the job card and an include member. This was before my *nix days so I didn't know about sed. But basically, the key to my process is a program that's kinda like a VERY simple version sed.
The neat thing about this is that you can run the exact same control cards and the exact same jcl except the control card in all environments instead of needing a copy for each, which is what I've seen in every shop I've worked in.
So far, every time I've introduced this to the 'gurus' at whatever place I'm working, I get the funny look and "you can't do that". But in fact where it's been used it works well and takes the sting out of doing things like changing a set of jobs to point to test instead of production, etc. Also, this allows for the jcl that gets to production to be the same jcl that has been used all the way from unit test.
My process is very simple and generic, and uses cobol instead of clist or rexx, that going from one environment to another takes a matter of minutes(assuming the naming conventions are reasonable). Plus it doesn't take some fancy syntax to learn like batch file-aide, etc.
I know there are all sorts of cool things you can do now(e.g. submit a job via ftp) that you couldn't do then.
My question is what methods have you seen to modify control cards 'on the fly'? Or is there even a utility now that does such a thing.
10+ years ago I created a generic process that allows you to parameterize 99% of your jcl including control cards. Using this method you can parameterize everything except the job card and an include member. This was before my *nix days so I didn't know about sed. But basically, the key to my process is a program that's kinda like a VERY simple version sed.
The neat thing about this is that you can run the exact same control cards and the exact same jcl except the control card
'control card' should be 'job card'
Quote:
in all environments instead of needing a copy for each, which is what I've seen in every shop I've worked in.
So far, every time I've introduced this to the 'gurus' at whatever place I'm working, I get the funny look and "you can't do that". But in fact where it's been used it works well and takes the sting out of doing things like changing a set of jobs to point to test instead of production, etc. Also, this allows for the jcl that gets to production to be the same jcl that has been used all the way from unit test.
My process is very simple and generic, and uses cobol instead of clist or rexx, that going from one environment to another takes a matter of minutes(assuming the naming conventions are reasonable). Plus it doesn't take some fancy syntax to learn like batch file-aide, etc.
I know there are all sorts of cool things you can do now(e.g. submit a job via ftp) that you couldn't do then.
My question is what methods have you seen to modify control cards 'on the fly'? Or is there even a utility now that does such a thing.
We developed the same tecnique here. We use it in our test environment to create multiple logical environments.
Using this method we can run the same job with multiple DB2 plans, CICS regions, SORT cards, ADABAS input parameters etc.
It was written in pure REXX, and it works great !!!
O.
Yeah, I've seen REXX implementations. But the ones I've seen weren't generic and needed to be modified if something changed such as some new type of thing you'd want to use a parameter for.
And a downside is that I've on lots of projects where there weren't any rexx folks
But that's still a home grown solution like mine so maybe there isn't a better solution.
I'm curious though, does the method you use actually create different jobs, control cards, etc for each environment and those get executed? And if I made a job that used IROCK as a symobolic parameter that will have the value TY, PRD, or SYST depending on the envrinment, would the REXX need to be modified?
One job, one control card that is generated at the start of the job.
The REXX is never modified.
O.
So I'm curious how it handles this situation. I know of a friend who has such a REXX implementation but it can't handle this so maybe if you tell me the gist of how it works there, I can pass it on...
Suppose I had a PROC, not instream, with this in a sort card:
INCLUDE COND=(1,4,CH,EQ,C'V_ENV')
and I want the value of 'V_ENV' to by 'TEST', 'SYST', or 'PROD' based on the environment I'm running in. So that the sort card that gets used in test looks like this:
INCLUDE COND=(1,4,CH,EQ,C'TEST')
Will your setup handle this? And how? Does is go through and read the control card dd statements to figure out what needs to be changed?
