Another luxury: get some people to perform a walk-through of the just the documentation. You can include folks who don't even know the language, COBOL or otherwise.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: Monday, May 11, 2020 12:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: OT: But COBOL is the problem? CAUTION EXTERNAL EMAIL Don't forget change logs. I once had to pick up documentation from someone who was into racing was in a coma for several years. I helped to instill in me the idea that you do the documentation first, and that if you need to revise the design or code, you revise the documentation first. In my dreams - most managers consider it a luxury. The "Take the money and run" culture doesn't help either. That said, good tools (not just the language) can make life easier and bad tools can increase the likelyhood of errors. But no language or IDE is so good that it can defend you from mismanagement. "Inexpensive, quick, reliable: pick two." And that's if you're lucky. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List [IBM-MAIN@LISTSERV.UA.EDU] on behalf of Dan at Poodles [poodles...@sbcglobal.net] Sent: Monday, May 11, 2020 1:56 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: But COBOL is the problem? From 46 years of experience, these problems can be mostly traced to little, if any, documentation. Is there correct system documentation? Is there correct file/data base documentation? Is there correct operational documentation? Is there correct program documentation? Are the programs documented externally (this is what this program does) and internally (explaining in excruciating detail every action taken). Have standards been established and strictly followed? Yea, I know all of this is a pain in the a$$, but who's going to support the code should the author(s) get run over by a bus? Detailed internal program documentation is also a great tool to review the author's logic and assumptions. It forces programmers and managers to re-think and re-verify everything. This lack of documentation can always, always, be traced to pi$$ poor management. Just because a project is completed in record time and under budget does not mean the project is a success. More likely than not, the poor souls tasked with supporting these systems are left with a nightmare. They pick up the crap they inherited and simply add more. What the hell, that was good enough before. Quick and dirty one-time shots should never be placed into production. Yet, I've seen this occur way too often. Whatever programming languages are used to write code is completely irrelevant. It's all about the documentation. -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of scott Ford Sent: Monday, May 11, 2020 11:04 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: But COBOL is the problem? Seymour, Yes sir no balance between Money and quality of life per se. I feel computer languages are our tools to get the job done. But one has to plan , work the plan, basically execute it. This is how I learned working IBM in NYC ...it works IMHO.. Scott ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
