Re: MVS/TSO Doc

Subject: Re: MVS/TSO Doc
From: doc -at- edwordsmith -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Sat, 19 Mar 2005 23:29:06 -0800


On Tuesday 15 March 2005 15:11, jsokohl -at- mac -dot- com wrote:
> Hi all,
>
> I've taken a mind-numbingly frustrating job that requires me to (ugh!)
> document COBOL programs and functionality. Of course, in 14 years in this
> biz, I've never worked with COBOL. So, I'm kind of a stranger in a strange

You're in the rarified area of legacy systems. I don't have any resources for
you, but I had a front-row seat for such a project once. I was the IT tech
writer for a phone company when they decided to move their billing system off
of costly mainframes onto nice new, cheap multi-processor Sequent/Dynix
machines (based on Intel CPUs, fwiw).

This business and technical objective was compelling on paper, but the work
(as I observed it) bore an uncanny resemblance to your description. Progress
was slow.

Of course, none of the staff at that time (mid-1990s) had any idea what the
legacy stuff did, because it was never documented, and then it was orphaned
when the developers moved on. Rarified is a good word to describe the dollar
value of an hour of a contract programmer's time when that system needed
attention. Having one such specialist on the re-engineering team would have
sucked the budget dry, so the project's management looked for other options.

They eventually landed a couple of contract analysts with some COBOL skills,
who then kibbitzed and palavered with each other and the staff's C/C++
developers, for months and months, while slogging through COBOL and gathering
steam (and confidence) in resolving what the legacy system was doing.

Note that they did all of this among themselves, with no formal attempt to
document the old system (which would have been a prodigious waste, as it was
going out of production). Whatever they learned about the old system was
rolled into definitions of the new system's requirements.

As tech writer, I was on the periphery of the code part of the project,
attending their meetings and capturing mass quantities of whiteboard diagrams
and discussions, which eventually became some of the fodder for the new
requirements and system documentation.

Good luck finding (or becoming one of) those analysts of the arcane business
code :-)

Ned Bedinger
Ed Wordsmith Technical Communications





^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

WEBWORKS FINALDRAFT - EDIT AND REVIEW, REDEFINED
Accelerate the document lifecycle with full online discussions and unique feedback-management capabilities. Unlimited, efficient reviews for Word
and FrameMaker authors. Live, online demo:
http://www.webworks.com/techwr-l

Your Ad Here! Have a product or service you'd like to get some attention for? Use this space to get the word out! Contact lisa -at- techwr-l -dot- com for more details.

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- techwr-l -dot- com
Send administrative questions to lisa -at- techwr-l -dot- com -dot- Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.



Previous by Author: Re: Anyone have a copy of the IEEE standards for software engineering ?
Next by Author: Re: How To Choose A Good TW Was Re: Giving a surprise test to interviewees?
Previous by Thread: MVS/TSO Doc
Next by Thread: PDF Conference in Orlando


What this post helpful? Share it with friends and colleagues:


Sponsored Ads