Writing COBOL Programs with Little or No Specs 1

[oldcoboler]

Does anyone have any suggestions about writing Cobol programs with little or no specs ?

I.e. I'm in the middle of a complex conversion project that has a multitude of business rules that are creating some logjams for a CIS - PeopleSoft conversion effort.

The Cobol programs are essentially throw away programs in a VSE/ESA environment which convert the current data into a format that can be handled by PeopleSoft in an AIX environment.

The last programming assignment they gave me ended up being a simple two-level control break or so it seems. I asked the technical lead (who works for the same consulting firm as I do) for a little help. Instead he just took over the program and made the coding change in about two hours.

Just wondering if some of the other Cobol veterans like MarcLodge and 3GM, etc. have any war stories to tell.

Heck, two weeks after I started my last contract consulting gig at WorldCom I was writing my own specs ! Now I'm kind of lost. It's a major southeast utility that has some rather hosed up business rules and no real business analysts.

Still trying to hang in there up in TN.

Oldcoboler

 

[pipk]

hey oldcoboler

you weren't one of the ones claiming for dodgy expenses at worldcom were you?

 

[Crox]

Hi Oldcoboler,

The most relaxed way to work with undocumented source is using documentation creating software like tools from Cornerstone (

http://www.cornerstone.nl)

or DocGen.

What I sometimes do by hand is reading the source and making a structure like JSP or VSP, depending on the people where I am working for.

Spaghetti sources are difficult in all cases. Cornerstone is busy creating a restructuring program that eliminates the goto's in several languages also for COBOL. You should ask them about that if the product is ready yet if you have to deal with spaghetti.

Regards,

Crox

 

[Dimandja]

Hi Oldcoboler,

Having done contracting work for years myself, I can understand your frustrations.

But, look at it this way. As a contractor, you are often called upon to put out a fire, not to babysit a system. This means that the situations you will encounter as a contractor are usually less than ideal.

As a contractor, you are expected to require very little help. And yes, you are expected to deliver very good code with, often, no written specs. Contractors are expected to be resourceful, and requiring no training from their clients. This is why contractor clients are expected to disburse "dodgy" paychecks.

Talking about written specs, this is essentially a dying art form, I am sorry to say. And I think there are a couple of reasons for that.

First, the clients quite often prefer not to rely on written specs to validate their application designs. Their resources are usually centered around code development - or code line counting . This has led to several "Rapid Application Development" tools - for demo/spec validation purposes. Incidentally, Visual Basic was purposefully designed as a RAD tool.

Lastly, the methodology for spec writting was never formalized accross the different schools of system design; think Warnier/Orr, etc... This means that two designers are each perfectly capable of writting specs that the other cannot decipher.

Dimandja

 

[ceh4702]

We dont have system analysts and Application Developers in our shop, we do it all on the fly more or less. You are lucky they do not change their mind half way through the job. It can be hard to write programs when you don't know the file system that well. The only thing that is guaranteed in life is change. If you do not like my post feel free to point out your opinion or my errors.

 

[k5tm]

"Visual Basic was purposefully designed"

I think that is a very RADical statement!
Tom Morrison

 

[oldcoboler]

Thanks everyone for your comments and war stories.

The latest news on my consulting gig is that yesterday the technical lead for the consulting firm I work for had my mainframe password revoked. I was accused of writing some bad code, etc.

I talked to the project manager and told her exactly what coding changes I made and backed it up with a MS Word document which showed the coding changes.

You see, in our current shop there is no version control, or tools such as Librarian, etc. to store source code so if you don't put your initials on a coding change then anything goes. Anybody can booger up your source if they want.

It's loosy goosy wild west anything goes, seat of the pants programming.

The code is spaghetti and screwy.

The SPL DBA said that one of the other utility mainframe to AIX conversion projects he worked on they just dumped all the data from the legacy system into unformated text files.

Then they reformattted the data, developed the parent-child relationships from a database standpoint and that was it. No Cobol conversion programs were used.

Our current problem is we have only one so called business analyst. Also we are trying to convert too much all at once. Residential, commercial, industrial, all customers all at once.

But hey, AMS is getting the big bucks to manage this project so you would think they would know what to do. But alas, they are somewhat clueless and continue to support the artificial target deadlines.

We are supposed to go live in September but June 2003 is probably more realistic.

The programming requirements change constantly.

By the way the technical lead was stripped of his responsibilities and my mainframe access should be restored by tomorrow. At least they never took away my AIX driver's license so I had something to tool around in.

Hope y'all don't mind this wordy diatribe.

I will just have to make the best of a crappy situation.

It's still better than unemployment.

Have a good weekend everyone and thanks !

Oldcoboler

 

[MarcLodge]

Hey All,
I'm not sure I understand this concept: Specification. I've always asked somebody what they want, then half way thru coding, confirmed with his/her colleague, then half way through re-coding, confirmed with the original specifier, then half way through re-designing the whole thing, given up and written it properly!

Seriously though, always, always, always, get something written/typed/emailed that you can refer back to if/when it goes belly up. It doesn't matter whether it is a fully functional spec or a couple of thoughts written down on the back of a cigarette packet, it's something that you can use to back up your rational path.

Marc

 

[oldcoboler]

Thanks again Marc for the good closing commentary.

It was the best post yet.

In fact, I did see that one of the other remaining contractors at the job site recieved an e-mail description (specs) of what he was supposed to do with his programming assignment.

I never did so that's part of the reason my contract expired today. Now it's back to unemployment comp for up to another five months or so with the federal extension.

I'm going on vacation for a few weeks to clear my head and await another gig or just retire for good.

Have a good weekend y'all,

Oldcoboler

 

[AustinOne]

Oldcoboler:

I'm not sure this is kosher in this forum, but how could I get a copy of your resume?

 

[oldcoboler]

AustinOne,

Thanks for resume inquiry.

I'll take a chance that you might have a lead on another contract gig.

I read some of your other posts and you mentioned AcuCobol.

It turns out that back in 1999 I used AcuCobol in an HP-Unix conversion project for the NYCTA. I happen to have an AcuCobol manual too.

Just send an e-mail message with your return e-mail address to dcwilk@earthlink.net.

I will zap my resume back to you then.

If I don't recieve an e-mail message from you then I'll assume there has been a problem.

Oldcoboler
(Who really isn't that old, it's just a handle !)