Page 1 of 1

Analysing a COBOL Program

PostPosted: Thu Oct 25, 2012 2:29 pm
by raghuvanshi
Hi,

I was asked in interview how would you analyze a COBOL program?
I gave the ans as there are many kind of analyses -:
Requirement analysis
Root cause analysis
Impact Analysis
Problem / logic analysis

but in general we talk about problem finding in a program
and told him we would first go in for a procedure division and check what the paragraphs are doing in the division and document it paragraph by paragraph
and will finally put displays if i have to find out the program is giving the output as.

Any suggestions on this are welcome!

Re: Analysing a COBOL Program

PostPosted: Thu Oct 25, 2012 2:43 pm
by Pandora-Box
Frankly, I wouldn't ask "How do you analyse" to Person having exp of 2 yrs ( Apologies if you are more than that )

To get the job done in much faster pace if the program was not written by me I would go stright to the person and ask him what it does

You have more debugging tools available in market which eases you to traverse through the code with actual data which you can analyse even complex programs easily

Atleast for me it is a bad question to ask in interview may be you could only test any resource by giving him some live data to analyse upon

Also you should post this question in "Interview questions" forum

Re: Analysing a COBOL Program

PostPosted: Thu Oct 25, 2012 3:08 pm
by BillyBoyo
It was such a broad question, you'd have to ask the interviewer what, specifically, was meant by it, because it could mean any one (or more) of what you've suggested, or something else.

Is the program well-written? Poorly-written? Unknown as no-one has looked at it yet? Batch? Database? "Back" or "middle" from e-commerce? What? Are any sub-programs, or calling programs to be considered?

You are "allowed" to ask questions back. Sometimes the reason for an interviewer asking a broad question is to see if you can do that in a reasonable manner.

It is possible to look at any program and "analyse" it in its own terms, but the results will likely be much less useful than if the purpose is known.

Re: Analysing a COBOL Program

PostPosted: Thu Oct 25, 2012 10:59 pm
by raghuvanshi
Thanks Premkrishnan and yes I have 2.2 years of exp and I am afraid I am having no knowledge about debugging tools.I told them the same too that would talk to the person who wrote the code and got a reply that what if that guy is not there.4 persons were taking my interview and I felt more like I was giving a presentation than interview.

Re: Analysing a COBOL Program

PostPosted: Thu Oct 25, 2012 11:04 pm
by raghuvanshi
Thanks for your suggestion BillyBoyo.

Re: Analysing a COBOL Program

PostPosted: Fri Oct 26, 2012 9:46 pm
by Ed Goodman
First, find the poor guy that touched it last, then hound them until they admit they know about it, then ask them what it does.

Re: Analysing a COBOL Program

PostPosted: Fri Oct 26, 2012 10:11 pm
by Akatsukami
Ed Goodman wrote:First, find the poor guy that touched it last, then hound them until they admit they know about it, then ask them what it does.

:D

But more seriously, this course of action is not without peril. In our MVS->Enterprise PL/I conversion project a few years back, the project team had to establish ownership of some thousands of programs. Some had not been touched in decades. Some of the analysts who had last touched them had since been promoted to director or AVP. They were generally not pleased when they got e-mails reading "hai susie r u goin 2 take ownership of program p1234? pls reply it is URGENT!!!"

Re: Analysing a COBOL Program

PostPosted: Mon Oct 29, 2012 8:20 pm
by Ed Goodman
lol!
"hai susie r u goin 2 take ownership of program p1234? pls reply it is URGENT!!!"

That's how I pick up chicks.