RE: COBOL source evaluations

New Message Reply Date view Thread view Subject view Author view Other groups

Subject: RE: COBOL source evaluations
From: Wakser, David (David.Wakser@infocrossing.com)
Date: Tue Jul 08 2008 - 11:38:36 EDT


John:

	Yes, a VERY good idea - but because of the "politics" involved,
having a "product" would reduce the quarreling; that way, applications
could not say "we don't take direction from the systems people". So, a
product would be best!

David Wakser 

-----Original Message-----
From: owner-vse-l@Lehigh.EDU [mailto:owner-vse-l@Lehigh.EDU] On Behalf
Of John Mycroft
Sent: Tuesday, July 08, 2008 11:34 AM
To: VSE Discussion List
Subject: Re: COBOL source evaluations

Can't point you at an automated tool to do it but I can assure you that
the job can be well worth doing.  I did it for a customer in NZ who was
thinking of upgrading from a 4361 to a 4381 (this wasn't last week!) and
changing less than a dozen lines in their data division of their longest
running program avoided the upgrade.  Their #1 sin was using DISPLAY for
subscripts to make it easier to debug the not-infrequent dumps the
program produced.

John Mycroft

Wakser, David wrote:
> All:
> 
> 	Is anyone aware of any products that will "read" COBOL source 
> programs and evaluate the performance-related items. For example: 
> point out inefficient numeric formats (e.g. DISPLAY fields instead of 
> COMP-3 or COMP), inefficient verbs (e.g. where SEARCH might be more 
> efficient that SEARCH), inefficient file access methods (e.g. opening 
> a file for I/O when it is only used to read), etc. etc. I have a 
> client that has thousands of programs, most with embedded "COPY" 
> statements of both WORKING-STORAGE entries and PROCEDURE DIVISION 
> code, who really needs help in this area.
> 
> 	Does such an animal exist?
> 
> David Wakser


New Message Reply Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b25 : Tue Aug 19 2008 - 17:35:07 EDT