What bank would allow people to change JCL without control? Or to
implement a 'typeo' in production without testing? Certainly not the
bank I work for.
If every z/OS machine in the world had this option installed next
Tuesday, absolutely nothing would break until someone changed
something, code or JCL.
In stable environments where nothing changes, well, nothing would
change -- no worries.
In more dynamic environments you again have two possibilities --
changes are tested for correctness or they are not. Only in the final
case is there even a risk of error. A SOC4 or a harmless overlay might
occur -- no worries and an easy fix or a dont-care. Or the program
might not recognize the 'typeo' on the JCL parm and offer a "Unknown
Parameter" error.
In the final case -- untested changes with a harmful parm overlay --
well, you were already playing Russian roulette by not testing your
changes -- you just shot yourself in the foot. Of course, if you make
a habit of not testing changes your feet are full of holes already.
[EMAIL PROTECTED]
I'm a guru, not a god. That is a completely different career path.
On May 23, 2005, at 6:33 PM, John Krew wrote:
I have to agree with Patrick and Peter on this. I am a bit bewildered
by the attitude of those on
the list that have pooh-poohed their down-to-earth objections with
such academic-sounding
observations as "well, there would be an insignificant number of
programs showing that kind of
behavior".
I guess they have never worked for a bank ...
John Krew
----- Original Message -----
From: "Patrick O'Keefe" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Monday, May 23, 2005 9:47 PM
Subject: Re: PARM=
On Sat, 21 May 2005 00:13:14 -0400, Joe Zitzelberger
<[EMAIL PROTECTED]>
wrote:
On May 20, 2005, at 5:16 PM, Peter Hunkeler wrote:
How many of the programs designed to run in batch are coded to cope
with longer than 100 byte parms? ...
Many programs are. ...
Ok. So Peter asked the wrong question. Forget about those that are
designed for the long parms. What about all the gazillion programs
that
are not? All the accounting programs, manufacturing support programs,
time accounting programs, etc.; the home grown life-blood of industry
(or
at least that part still on MVS).
Imagine some typo in the JCL makes the PARM longer than 100, say 102
bytes. ...
You have put the cart before the horse. None of your existing,
functional, JCL passes a parm longer than 100 bytes ...
...
The fix is simple. Just don't pass more than a program is expecting.
Today, that is a certain error (JCL error), tomorrow it will still be
an error (program not expecting error). Either way it is an error.
Nothing in this change can break a program that is currently working
correctly today.
He said "... typo ...". Passing the additional data is unintentional.
Fine. It's an error. Only in one case you get a JCL error. In the
other case you get in incorrectly executing problem that may or may
not
abend. It may meerly produce a totally bollixed General Ledger for
the
month. No problem unless your company cares about money.
Pat O'Keefe
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
