Home > Archive > Cobol > January 2007 > Analysis tools for Cobol
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Analysis tools for Cobol
|
|
| A.Serebrenik@tue.nl 2007-01-11, 6:55 pm |
| Dear all,
I wonder whether there are analysis tools for Cobol? I'm particularly
interested in freeware, shareware or commercial tools that can be
freely downloaded for evaluation purposes.
I do now that some code counters can analyse Cobol and that Visustin
can derive flowcharts/UML-like activity diagrams.I'm interested in:
- more advanced code metrics (McCabe, Halstead, ...)
- coding style violations, potential bugs and best/worst practices
- multiple-module visualisations (more like UML message sequence charts
or class diagrams)
I also wonder whether there are some papers linking Cobol code metrics
with testing effort, presence of bugs and maintainability.
Best regards,
Alexander Serebrenik
| |
| Alistair 2007-01-11, 6:55 pm |
| All of the tools that you want are available at a price on the internet
if you do a search for them.
To count code: count the number of lines and deduct the number of
comment lines.
There is an online program analyser which provides the flowchart that
you s . It is limited in the freebie form.
Code editors are available which can colour code your code to highlight
errors, etc. Some can even aid in completing the code lines quickly.
See Codewright, etc.
For code metrics then you may like to look at FPA (function point
analysis). I'm a little suspicious of FPA as I think it simplifies a
systems' complexity but it does provide a standard measure as to how
complex a system may be.
For best/worst coding standards: avoid the ALTER and GO TO verbs. There
are probably documents available on the net, if you use "cobol
standards", available to you.
For potential problems: there are so many; ranging from incompetent
programmers to a mis-understanding as to how to test a program for
being numeric... the subject is so broad.
Real Programmers don't use UML charts. But Real Programmers use IBM
Assembler and not Cobol!
There are plenty of documents which relate Cobol code to metrics,
testing effort and bug occurrence. As a rule of thumb: every program
contains a bug; the bigger the program then
the more bugs there are yet to be found. As to maintainability: if it
is difficult to read then it will be difficult to understand.
DO A SEARCH ON GOOGLE AND LOOK FOR YOURSELF.
A.Serebrenik@tue.nl wrote:
> Dear all,
>
> I wonder whether there are analysis tools for Cobol? I'm particularly
> interested in freeware, shareware or commercial tools that can be
> freely downloaded for evaluation purposes.
>
> I do now that some code counters can analyse Cobol and that Visustin
> can derive flowcharts/UML-like activity diagrams.I'm interested in:
> - more advanced code metrics (McCabe, Halstead, ...)
> - coding style violations, potential bugs and best/worst practices
> - multiple-module visualisations (more like UML message sequence charts
> or class diagrams)
>
> I also wonder whether there are some papers linking Cobol code metrics
> with testing effort, presence of bugs and maintainability.
>
> Best regards,
> Alexander Serebrenik
| |
| A.Serebrenik@tue.nl 2007-01-12, 3:55 am |
| Dear Alistair,
Thank you for your contribution. Believe me, I've searched on Google.
None of the tools I've found - with two notable exceptions mentioned
before - provides an evaluation version. I'm not ready to pay for
something as long I have not evaluated it myself.
Best/worst practices and potential bugs: I'm looking for tools that can
detect them and not for general guidelines. Such tools exist for C and
Java and I hoped that something was also available for Cobol.
Best regards,
Alexander
P.S. Being rude is not a good way to welcome a new member.
Alistair schreef:
[color=darkred]
> All of the tools that you want are available at a price on the internet
> if you do a search for them.
>
> To count code: count the number of lines and deduct the number of
> comment lines.
>
> There is an online program analyser which provides the flowchart that
> you s. It is limited in the freebie form.
>
> Code editors are available which can colour code your code to highlight
> errors, etc. Some can even aid in completing the code lines quickly.
> See Codewright, etc.
>
> For code metrics then you may like to look at FPA (function point
> analysis). I'm a little suspicious of FPA as I think it simplifies a
> systems' complexity but it does provide a standard measure as to how
> complex a system may be.
>
> For best/worst coding standards: avoid the ALTER and GO TO verbs. There
> are probably documents available on the net, if you use "cobol
> standards", available to you.
>
> For potential problems: there are so many; ranging from incompetent
> programmers to a mis-understanding as to how to test a program for
> being numeric... the subject is so broad.
>
> Real Programmers don't use UML charts. But Real Programmers use IBM
> Assembler and not Cobol!
>
> There are plenty of documents which relate Cobol code to metrics,
> testing effort and bug occurrence. As a rule of thumb: every program
> contains a bug; the bigger the program then
> the more bugs there are yet to be found. As to maintainability: if it
> is difficult to read then it will be difficult to understand.
>
> DO A SEARCH ON GOOGLE AND LOOK FOR YOURSELF.
>
>
>
>
> A.Serebrenik@tue.nl wrote:
| |
|
| In article <1168584542.889287.253570@11g2000cwr.googlegroups.com>,
A.Serebrenik@tue.nl <A.Serebrenik@tue.nl> wrote:
>Dear Alistair,
>
>Thank you for your contribution. Believe me, I've searched on Google.
Believe me, I saw no indication of this in your original posting.
>None of the tools I've found - with two notable exceptions mentioned
>before - provides an evaluation version. I'm not ready to pay for
>something as long I have not evaluated it myself.
Believe me, I saw no list of offices you'd contacted regarding tools where
representatives of the organisation refused you an evaluation copy.
[smip]
>P.S. Being rude is not a good way to welcome a new member.
Coming into a newsgroup and making a request without showing any
indication of previously-attempted efforts on your part ('I searched using
the Altavista engine and terms "(a) and (z)", I contacted Knurblesoft and
they told me they don't speak to anyone who does not have signing
authority for invoices of a minimum of (n)(units of currency)' is, in my
limited experience, often a good way to earn a response of 'please do your
own homework/job' on the UseNet.
DD
| |
|
| Dear Alexander,
You might want to read this paper on Cobol minefield detection:
http://www.cs.vu.nl/~nveerman/resea...d/minefield.pdf
With best regards,
Niels
A.Serebrenik@tue.nl wrote:
> Dear all,
>
> I wonder whether there are analysis tools for Cobol? I'm particularly
> interested in freeware, shareware or commercial tools that can be
> freely downloaded for evaluation purposes.
>
> I do now that some code counters can analyse Cobol and that Visustin
> can derive flowcharts/UML-like activity diagrams.I'm interested in:
> - more advanced code metrics (McCabe, Halstead, ...)
> - coding style violations, potential bugs and best/worst practices
> - multiple-module visualisations (more like UML message sequence charts
> or class diagrams)
>
> I also wonder whether there are some papers linking Cobol code metrics
> with testing effort, presence of bugs and maintainability.
>
> Best regards,
> Alexander Serebrenik
>
| |
| Alistair 2007-01-12, 6:55 pm |
|
A.Serebrenik@tue.nl wrote:
> Dear Alistair,
>
> Thank you for your contribution. Believe me, I've searched on Google.
> None of the tools I've found - with two notable exceptions mentioned
> before - provides an evaluation version. I'm not ready to pay for
> something as long I have not evaluated it myself.
Then you are in a Catch-22 situation.
>
> Best/worst practices and potential bugs: I'm looking for tools that can
> detect them and not for general guidelines. Such tools exist for C and
> Java and I hoped that something was also available for Cobol.
The best tool for catching bugs such as bad practices, etc., is a code
review by other programmers. There are tools available which can detect
unexecutable code (ie code which can never be entered). There is an
extension to ISPF which can do this and Compuware used to use
XA-Systems which restructures code (quite nicely as it goes) and can
detect dead code.
You will still have a serious problem: if you don't pay then it is
unlikely that you will get a free trial. However, Compuware did
restructure a program for me as a worst case example. Hence the fact
that I am impressed.
>
> Best regards,
> Alexander
>
> P.S. Being rude is not a good way to welcome a new member.
As some people on this site will attest; I can be a lot ruder!
[color=darkred]
>
> Alistair schreef:
>
| |
| Howard Brazee 2007-01-12, 6:55 pm |
| On 12 Jan 2007 10:09:55 -0800, "Alistair"
<alistair@ld50macca.demon.co.uk> wrote:
>The best tool for catching bugs such as bad practices, etc., is a code
>review by other programmers. There are tools available which can detect
>unexecutable code (ie code which can never be entered). There is an
>extension to ISPF which can do this and Compuware used to use
>XA-Systems which restructures code (quite nicely as it goes) and can
>detect dead code.
It's not that uncommon to have unexecutable code on purpose. Comment
out the PERFORM but leave the old code for documentation or because
you think it will be needed in the future.
| |
| Alistair 2007-01-13, 6:55 pm |
|
Howard Brazee wrote:
> On 12 Jan 2007 10:09:55 -0800, "Alistair"
> <alistair@ld50macca.demon.co.uk> wrote:
>
>
> It's not that uncommon to have unexecutable code on purpose. Comment
> out the PERFORM but leave the old code for documentation or because
> you think it will be needed in the future.
True. But this can be confusing to the unaware. Other niceties are
leaving code in situ with comments to remove after a certain date
(usually in the past).
| |
| Donald Tees 2007-01-13, 9:55 pm |
| Alistair wrote:
> Howard Brazee wrote:
>
> True. But this can be confusing to the unaware. Other niceties are
> leaving code in situ with comments to remove after a certain date
> (usually in the past).
>
I have code less than two years old with so many lines of commented out
code that it obscures the meaning of whats left. I've taken, lately, to
deleting whole blocks of it when I'm in the module.
Donald
| |
| William M. Klein 2007-01-18, 6:55 pm |
| I haven't read thru the entire thread yet, but have you told us which operating
system/environment you plan on RUNNING this tool on? Also what compiler are you
using?
I know that there are MANY such tools for IBM mainframe COBOL; some run on the
mainframe and some run on the PC (or workstation).
As far as FREE or evaluation copies, this may also depend on who would BUY any
evaluation copy - if you "like it. If you are an independent developer you may
have problems getting "evaluation" copies, but if you work in a large mainframe
COBOL shop, I think you could get an evaluation copy from almost any of the
vendors.
--
Bill Klein
wmklein <at> ix.netcom.com
<A.Serebrenik@tue.nl> wrote in message
news:1168554202.999021.225720@p59g2000hsd.googlegroups.com...
> Dear all,
>
> I wonder whether there are analysis tools for Cobol? I'm particularly
> interested in freeware, shareware or commercial tools that can be
> freely downloaded for evaluation purposes.
>
> I do now that some code counters can analyse Cobol and that Visustin
> can derive flowcharts/UML-like activity diagrams.I'm interested in:
> - more advanced code metrics (McCabe, Halstead, ...)
> - coding style violations, potential bugs and best/worst practices
> - multiple-module visualisations (more like UML message sequence charts
> or class diagrams)
>
> I also wonder whether there are some papers linking Cobol code metrics
> with testing effort, presence of bugs and maintainability.
>
> Best regards,
> Alexander Serebrenik
>
|
|
|
|
|