dick scherrer wrote:
However, if this happens, it says there are no proper standards or they are not being followed. . .
Absolutely right, and unfortunately it was the former. At the heart of that problem, the company was a bit "cheap". In development, we had no spare time or people, in production control, the same. Production releases (the final load modules and the JCL) got no testing. None. Zilch. The JCL was "not so bad", as mostly, if there was a problem, it would fail immediately. On the bigger systems (I worked on the smaller ones, only 50-200 cobol modules per load module) you could be four hours into a production run and, S806.
Now, this would come about due to an error in the release procedure (release forms were usually only filled-in at the last minute, and someone might miss off a module in haste, and sometimes Frank had hundreds of modules to promote, and would miss one (or two).
No money for more people for production testing. Release process entirely manual, and just treated as the last thing you do to get something live.
At least what we didn't do, was loose sources...
I'll give you another example of how cheap they were. When we moved to MVS, we used ISPF. What could we do on option 7? Run UCC1. Nothing else. Why? "TSO takes up too many resources for developers to use".
dick scherrer wrote:I have this vision of some evil/mad scientist-type developer saying "Heh, heh, heh - now where can i hide this one. . .".
Now, later, in financial environments, this is exactly what all the auditors wanted to know we couldn't
be doing. I know they wouldn't have liked "call data-name". They'd ask me, "how can you show me that this is the program that is being used"? With call data-name, I'm not sure I could.