- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
first cobol wtf!
Admin
If both switches were supposed to be set to "N", why didn't this happen all the time? Apparently, the instructions given weren't identical to the routine normally used. Had his boss never followed his own instructions before?
Admin
Clearly, they didn't know the proper way to appease it's Machine Spirit. The Omnissiah is disappointed.
Admin
So let me get this right.
a) Herschel added some code which allowed the database updates to be bypassed.
b) He implemented this via inverted logic, wherein it did not do that damaging update of the database if set to Yes. (And the worse thing where he did not make it impossible to run together the two things that when run together destroyed the universe.)
c) He didn't test it.
d) He gave the exactly opposite instructions to the newbie to what he should have given him, so that when following the instructions as provided by his mentor, the precise sequence of actions occurred that should never have happened.
e) When everything went wrong, he tried to blame the newbie for his appalling mistakes.
A classic TDWTF of the old school.
Admin
I understand that the code here was a new thing that was added 5 minutes before Coyne was let loose on it. Presumably beforehand, a more intricate bodge needed to be done to the code to prevent those updates from happening -- the flag setting was a simplification of that specifically for a newbie'ss benefit..
Admin
I don't understand the circumstances. Why didn't they just re-run the print job from the printer queue, without running the Cobol report again? Why didn't they just redirect or tee the printer device to a file, so they can print it again from this file? Input-output-section in Cobol: FILE_CONTROL. SELECT Printer ASSIGN TO "LPT1". Why couldn't they just modify this line and replace LPT1 with a file name instead?
Admin
As it has been mentioned, the COBOL program runs on a mainframe. Assumption: On systems like MVS (or any OS under the control of VM) it should have been possible to use a spool file that had to be manually deleted after a successful printer run - or kept as long as a re-run of printing was required. Printer output is typically spooled. Even if the problem program thinks it is directly addressing a printer (not entirely uncommon), a regular file would be used. And regular files could be printed easily as needed, even in parts.
This nicely fits into all the things done wrong so far, with addition of not having daily backups of information... Not being familiar with what a mainframe OS can do is a WTF. Not having a "tee" command or a "LPT1" isn't an excuse. ;-)
Admin
Um. Because it's running on the mainframe, and mainframe operating systems(1) don't treat devices like special files in the UNIX style.
This whole discussion recalls a thing that startled me and my fellow students in our "Software Engineering" class back in 1988. We were doing a series of mock exercises based on a real project, and it startled us to discover that something we assumed was possible (because contemporaneous machines, PCs running DOS, the CDC Cyber 815 in the big room over there, the same PCs running Microsoft XENIX, etc. could all do it) was not possible on the operating system running on an old IBM System/1 mainframe.
What thing? Well, um, calling some equivalent of open / creat / fopen to create a new file on the fly and open it for write. That wasn't possible on the System/1.
(1) IBM zSystem mainframes are the spiritual descendants of the System/360s of the 1960s, to the extent that binaries compiled back then on your System/360 Model 67 (2) will run natively on a brand-new zSystem, with just an API translation layer. The hardware will, nonetheless, run Linux compiled for System/390.
(2) The first computer to run, for customer workloads, what we would today call a hypervisor. In 1967. There is nothing new under the sun.
Admin
Um. Because it's running on the mainframe, and mainframe operating systems(1) don't treat devices like special files in the UNIX style.
This whole discussion recalls a thing that startled me and my fellow students in our "Software Engineering" class back in 1988. We were doing a series of mock exercises based on a real project, and it startled us to discover that something we assumed was possible (because contemporaneous machines, PCs running DOS, the CDC Cyber 815 in the big room over there, the same PCs running Microsoft XENIX, etc. could all do it) was not possible on the operating system running on an old IBM System/1 mainframe.
What thing? Well, um, calling some equivalent of open / creat / fopen to create a new file on the fly and open it for write. That wasn't possible on the System/1.
(1) IBM zSystem mainframes are the spiritual descendants of the System/360s of the 1960s, to the extent that binaries compiled back then on your System/360 Model 67 (2) will run natively on a brand-new zSystem, with just an API translation layer. The hardware will, nonetheless, run Linux compiled for System/390.
(2) The first computer to run, for customer workloads, what we would today call a hypervisor. In 1967. There is nothing new under the sun.
Addendum 2019-02-11 09:14: Bah, double-post, sorry.
Admin
CR: There was no printer queue. When I learned COBOL in the 1970's, it was on a "mainframe" with 128 KB of memory - you didn't have the memory to create a printer queue. I suppose that many COBOL implementations have been updated to make use of billion KB memory and all the useful things that have been added to operating systems since the 70's (including better printers), but this wasn't one of them.
Now, if I had to maintain that system, I would always redirect any long report to a disk file and print that. But I hope I'm smarter than the guru that wrote that code snippet, and then sent the new guy out with the wrong instructions!
Admin
Re-directing that output might require revising the code to change print statements to disk writes, but this code has been around for a long time. This could have been done anytime in all those years.
Admin
How do you eat an elephant? One bite at a time.
How do you learn a new code base for your new job? Oh, you have to devour the entire thing all at once before you can even begin to do anything productive.
Admin
Yes, change it to disk output. Make it a temp file that will persist until next run. IEFBR14 Delete and reallocate it with plenty of secondary extents at beginning of job. IEBGENER it to SYSOUT as last step of job. The dataset will last until the next run. If the output was trashed at the printer, (or lost or destroyed) rerun the IEBGENER step. You can also set up GDG's and have them kicking around for weekly, monthly, historical. We did stuff like this constantly back in the day. One company I was consulting at finally had enough and management issued an order rewrite ALL reports to disk. This was mostly JCL work, but occasionally there could be an issue with Carriage Control that could only be fixed with COBOL (or Assembler) code changes.Took a few months but they never had to rerun a report again. When lasers came to the market, reports were rarely if ever trashed anymore, but there are always human reprint requests and it was no longer dangerous to do so.
Admin
If this is on a mainframe most of time you make changes to the JCL used to run the job, not to the source code itself.
Admin
Calling a Series/1 a mainframe is flattering for the Series/1 much less so for real mainframes. Interestingly, or frighteningly depending on your POV, a 2016 US government report said a Series/1 minicomputer was still part of the US nuclear command and control systems.
Admin
Another thing to remember is, COBOL definitely pawed through all the records and edited/updated them as needed. If you're not familiar with it, then think of it either as a "Active Record" pattern for Ruby on Rails and/or Visual Basic, or the Map/Reduce jobs on Hadoop.
Backends are different, but very similar work loads and mental models.
In fact, Hadoop "Big Data" follows the exact same kind of logic and "file format" as good old mainframes. Like Steve said, there's nothing new under the sun.
Admin
Even if I'm the senior in the situation and have done it a thousand times, when I'm doing something potentially very destructive I get someone else to double check before I hit enter.
Admin
Even if I'm the senior in the situation and have done it a thousand times, when I'm doing something potentially very destructive I get someone else to double check before I hit enter.
Addendum 2019-02-11 12:18: Something not so destructive, like accidentally hitting a comment submit button twice, not so much :-)
Admin
Don't say something is "absolutely wrong" because there'll be people who will want to argue and say that it depends on the situation and it is sometimes right the right thing to do and the world isn't black and white and you should keep an open mind and they have done it themselves without ill effect and never give a demonstrable counterexample.
Admin
That's absolutely wrong.
Admin
Fair enough. It's been a little while since I learned that about the Series/1 OS, and we didn't get to touch the actual machine, and I'm once again guilty of relying on faulty memory rather than verifying it. Bah.
Admin
It's not a real WTF without blame-gaming from somebody who was responsible for the issue. Usually it falls to management not to put a Junior on a potentially-data-losing script.
But the true golden turd for me is where the person who develops the script and provides the wrong instructions blames the failure on the Junior they put on it.
Admin
The real non-WTF is "'I followed the boss' instructions' actually worked as a valid defense."
Admin
Explanation might be warranted. The job did in fact print into the JES spool, and the report should have been able to be reprinted. But only if the printer detected the paper jam and stopped, which would have allowed The Operators to reset and reprint the report when the paper problem was corrected. The problem was, when the paper jammed, the printer didn't detect the problem. So that report, and several others, were printed onto a strip of paper 1/8 inch high. Excuse me, more like a strip of holes 1/8 inch high. As each report "successfully" completed (heavy on the quotes around the word successful) JES dutifully deleted the spool. After all you don't need the report occupying disk anymore once successfully printed.
Admin
the first part of this reminded me of a story about a printer that worked perfectly WHEN WATCHED but would always crash if someone tried to print more than 50 pages and did NOT watch it. it turned out to be a static buildup problem, and people usually LEANED ON the printer when watching it, which grounded it! even more embarrassing was the revelation that this problem had been fixed BEFORE, but came back when the printer was moved to a different location!
Admin
Oh, I'm sure the junior had some guy double-check with him that he had set both variables to 'N' as instructed. Whether he did or not had no influence on what ensued.
Admin
I was expecting "objectively terrible" to link to https://theoatmeal.com/comics/printers.