automated test jcl
kishore swargam
I am involved in developing an automated test
environment.We are trying to develop some tool which
will pull production Jobs from Librarian and put them
in the dynamically created PDS of the user.Then
we have to develop some panels using rexx.When these
panels or rexx programs are invoked there should be a
default setting for these panels for job card
information , control card overrides , proc step file
overrides, symbolics , proc parameters etc. I will
appreciate if somebody can send me coding for doing
all or atleast some of these.Thanks in advance.
kish.
overrides,
__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Dave Salt
I'm not sure what your production JCL looks like when compared to test JCL,
but in our environment the two are COMPLETELY different. So much so that we
don't even attempt to copy/modify/submit production JCL. Instead, all of our
test JCL is kept in skeleton libraries. We then have REXX programs that
display ISPF panels and the values entered on those panels are substituted
in the skeletons to generate the appropriate JCL.
If you copy production JCL it would not be in skeleton format, which makes
it more difficult to substitute values you'd want to use in your test
environment. And it wouldn't make sense to copy the JCL and convert it to
skeleton format just so it could be converted back to JCL again.
If I were you I wouldn't be too concerned about keeping two copies of the
JCL (i.e. skeletons for the test environment and real JCL for the production
environment). Testing is done first, so if people want to test their
programs and JCL changes are required, they HAVE to have someone update the
skeletons before they can test it. Then, part of the hand-over package is
the production JCL so it can hardly get forgotten. In addition, it could be
generated from the skeletons and modified to suit the production environment
so it's not a lot of effort. We've been doing it this way for years and with
great success, but maybe someone has a different suggestion? Anyway, hope
that helps.
Dave Salt
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
Harrington, Mark
My response is that, when I was working at blue cross/blue shield of
washingtonm state during y2k we would need to test production jcl in the
test environment(s). I was a Q.C. person at the time (not my real Forte I
just wanted to work in wahsington st.) and instead of me spending two weekes
to change 100 jobs to the test environment specs, I developed a series of
rexx exec's that would change all of the jcl in a particular library
symbolics, form names,job cards,joblibs etc to the desired test
environment(which was input as an argument). I used a "template" for each
test environment. So what used to take two weeks now took 10 minutes. These
were very easy to write and the only thing that needed to be debugged were
the templates due to jcl format exceptions. i would send these to you if you
wish but they are not for your shop so im not sure how much good they would
do you. But if this is what you has in mind it might perhaps be a good
starting point.
m.h.
Gardiner, Roy
>
> I'm not sure what your production JCL looks like when compared to test
> JCL,
>
> We've been doing it this way for years and with
> great success, but maybe someone has a different suggestion?
>
test to production; further, I've seen sites where there are tests in the
code to check whether it's running in test or production and to do different
things. I suspect that people who quite happily would run JCL for the first
time in production would throw up their hands in horror at the program code
example. But why? It's the same challenge.
JCL is code like any other and should IMO go through the same
testing cycles, and program code should under no circumstances have tests to
check if it's test or production. The same reasoning applies -- running
untested stuff for the first time in production.
One approach in JCL is to use procedures, with different invocation
for test and production. This is of course not risk-free - the production
invocation JCL could be wrong - but certainly reduces it.
Roy Gardiner
The Royal Bank of Scotland plc ('the Bank') is regulated by the Financial
Services Authority and is a member of The Royal Bank of Scotland Marketing
Group. The only packaged products (life policies, unit trusts and other
collective investment schemes and stakeholder and other pensions) the Bank
advises on and sells are those of the Marketing Group, whose other members
are Royal Scottish Assurance plc and Royal Bank of Scotland Unit Trust
Management Limited, both regulated by the Financial Services Authority.
The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered
Office: 36 St Andrew Square, Edinburgh EH2 2YB.
Agency agreements exist between members of The Royal Bank of Scotland Group.
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message from
your computer. Internet e-mails are not necessarily secure. The Royal Bank
of Scotland plc does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the onward
transmission, opening or use of this message and any attachments will not
adversely affect its systems or data. No responsibility is accepted by The
Royal Bank of Scotland plc in this regard and the recipient should carry out
such virus and other checks as it considers appropriate.