Home > Archive > Cobol > September 2006 > Re: EBCDIC to ASCII OPTCD=Q? (JCL)
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 |
Re: EBCDIC to ASCII OPTCD=Q? (JCL)
|
|
| Robert Jones 2006-09-20, 6:55 pm |
|
Clark F Morris wrote:
messages snipped
> I have noticed the same syndrome. Somehow those in charge don't
> realize that JCL (OCL/shell script/command language of choice or
> affliction), utility control statements and similar artifacts are code
> that may be making business decisions. In the case of sort control
> statements like INCLUDE/OMIT, the decisions can be made in a really
> obscure way. If companies really cared about documentation and
> auditablity, they would have only COBOL/PL1/other language sorts and
> not an easily changed and obscure bunch of control statements running
> the sorts.
>
Surely the most appropriate action is to apply testing, audit and
documentation standards to JCL, utilities, etc in the same way as
programs. One could perhaps have an approved list, so that the
organisation's personnel can be reasonably expected to be familiar with
them and have access to the relevant manuals for debugging, etc.
Writing several hundred lines in place of just a few seems like
overkill.
Robert
| |
| Clark F Morris 2006-09-20, 6:55 pm |
| On 20 Sep 2006 12:06:41 -0700, "Robert Jones" <rjones0@hotmail.com>
wrote:
>
>Clark F Morris wrote:
>
>messages snipped
>
>
>Surely the most appropriate action is to apply testing, audit and
>documentation standards to JCL, utilities, etc in the same way as
>programs. One could perhaps have an approved list, so that the
>organisation's personnel can be reasonably expected to be familiar with
>them and have access to the relevant manuals for debugging, etc.
>Writing several hundred lines in place of just a few seems like
>overkill.
I agree that the suggested course should be undertaken. However, most
mainframe sorts that I have seen use the field displacement, length
and type in specifications rather than field names. I understand that
ICETOOL from IBM and Visual Syncsort improve on this. Syncsort for
HP-UX also can use copy books and will allow you to write something
that can be read and understood 6 months later. However a COBOL
program can be fairly minimal in actual coding through the use of
copybooks and can in many cases allow consolidations. We are not in a
world of 64K partitions or 512K regions anymore.
>
>Robert
|
|
|
|
|