Home > Archive > Cobol > July 2004 > Scripts and Utilities easier to promote than programs was: Re: Combining
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Scripts and Utilities easier to promote than programs was: Re: Combining
|
|
| Clark F. Morris, Jr. 2004-07-27, 3:55 am |
| docdwarf@panix.com wrote:
> In article <GcGdna7lLq4iMGvd4p2dnA@giganews.com>,
> JerryMouse <nospam@bisusa.com> wrote:
>
>
>
> ... and suffer the move-to-Prod overhead associated with moving a program
> into Prod that I was hoping to avoid... and have to modify the JCL for
> that existing program's step to address the files in question, as well.
>
> DD
>
Your comment about it being easier to put program code in a utility into
production rather than a new program rings true and is a  indictment
of our field. With Sort Symbols, the ICETOOL can be relatively clear
but most IBM mainframe sorts that have logic in them (INCLUDE or OMIT,
report generation, etc.) quickly get to be obscure as ****. Somehow
"2,9,CH" or "2,9,NU" doesn't tell me as much as SOCIAL-SECURITY-NO or
even the cryptic SSN. If you were coding this on the HP-UX system using
SYNCSORT with the ability to have true field names (and even the use of
COBOL copybooks) I might have a different opinion about maintainability.
However you are still putting program logic into production with
decisions being made in the utility and that should have to go through
the same review process as a program. Complex INCLUDE/OMIT statements
can be error prone and the comments may or may not be adequate to let
the poor soul who inherits the statement know what the SORT is doing.
| |
| docdwarf@panix.com 2004-07-27, 8:55 am |
| In article <ce4d8u$f98$1@news.eusc.inter.net>,
Clark F. Morris, Jr. <cfmtech@istar.ca> wrote:
>docdwarf@panix.com wrote:
>
>Your comment about it being easier to put program code in a utility into
>production rather than a new program rings true and is a indictment
>of our field.
What might be to one person's sorrow could be to another person's mirth,
Mr Morris... I see the situation as mere acknowledgement of what
experience has taught me. Nobody I know of thinks it 'a indictment'
when a creative tax-accountant discovers and exploits a loop-hole in the
regulations... *especially* the client to whom the benefit accrues.
>With Sort Symbols, the ICETOOL can be relatively clear
>but most IBM mainframe sorts that have logic in them (INCLUDE or OMIT,
>report generation, etc.) quickly get to be obscure as ****.
Aye... and when folks tell me 'Oh, it ain't nothin', just another
SORTstep' I usually respond 'That makes me step back a pace; SORT's an
incredibly powerful and subtle tool and I've seen folks run some rather
complicated systems using it.'
>Somehow
>"2,9,CH" or "2,9,NU" doesn't tell me as much as SOCIAL-SECURITY-NO or
>even the cryptic SSN. If you were coding this on the HP-UX system using
>SYNCSORT with the ability to have true field names (and even the use of
>COBOL copybooks) I might have a different opinion about maintainability.
This was part of the joy of Mr Yaeger's example; the comments, although
simple, made it clear to... well, at least me.
>However you are still putting program logic into production with
>decisions being made in the utility and that should have to go through
>the same review process as a program.
'Should be' ain't 'is'... hence my exploitation.
DD
|
|
|
|
|