cobol mantenance levels 
Author Message
 cobol mantenance levels

Does anyone know the industry standard for the number of lines of MVS
cobol a programmer should be able to maintain?  I have seen a  number of
7-8000 LOC per year per programmer for writing new code but what about
maintaining code?
--
ADavieCrockett

--== Sent via Deja.com http://www.*-*-*.com/
---Share what you know. Learn what you don't.---



Sat, 10 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:

> Does anyone know the industry standard for the number of lines of MVS
> cobol a programmer should be able to maintain?  I have seen a  number of
> 7-8000 LOC per year per programmer for writing new code but what about
> maintaining code?

Interesting question.  There are lots of variables involved.  I could
maintain 10-100 times as much code in a well structured, well understood
environment than I could in an environment with huge old programs which
have had their spagetti code modified a hundred times and where the
business environment is not clearly defined.

Of course, it also depends on what maintenance needs to be done.
Changing the printed output of a form to match a new requirement doesn't
require much work.  Finding out why January's run didn't get the figures
desired for a report (while February's worked fine) takes much more
time.

Having a good testing environment with lots of data helps considerably
too.

Which takes longer to maintain:
     MOVE "abcdefghijk"    TO REPORT
or
     MOVE "abcdefgjijk"
                     TO REPORT

One example is twice as many lines as the other.



Sat, 10 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:
>Does anyone know the industry standard for the number of lines of MVS
>cobol a programmer should be able to maintain?  I have seen a  number of
>7-8000 LOC per year per programmer for writing new code but what about
>maintaining code?

The number of lines of code you produce or maintain is completely irrelevant
to any measurement of a programmers ability. Anyone trying to put a number
on it is guessing with accuracy worse than a federal agency. The number is
irrelevant and cannot be measured with any amount of accuracy. These people
trying to create this standard are looking for a way to quantify human
intuitive ability. They management is simply looking for a way to reduce the
amount of money they have to pay their programmers by tying their salary to
a variable which is mostly dependant on how they decide to assign projects
and to whom they are assigned. Without any consideration for the intuitive
ability of the individual.

This is just a good example of how management "thinks" everything can be
quantified.



Sat, 10 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:

> Does anyone know the industry standard for the number of lines of MVS
> cobol a programmer should be able to maintain?  I have seen a  number of
> 7-8000 LOC per year per programmer for writing new code but what about
> maintaining code?
> --
> ADavieCrockett

Simple answer,  really good code that was incredibly well
designed.  Infinite.

Incredibly bad code written by semi trained monkeys.  7-8000 lines
of code per year, they have to rewrite everything.

The next variable is the state of change that the code is under.
If new features are being introduced weekly (as per any real live
system) then the new features would require typically MORE time
than the original code (ie 3,000 lines).  The reason is a good
coder will work to restructure the logic possibly reducing the
line count as they make changes, a bad coder put additional code
on top of additional code with no concern for structure and you
end up with a total rewrite after a few years anyway.

The answer is there is no real answer.
Ken



Sun, 11 Nov 2001 03:00:00 GMT  
 cobol mantenance levels


Quote:

>Does anyone know the industry standard for the number of lines of MVS
>cobol a programmer should be able to maintain?  I have seen a  number of
>7-8000 LOC per year per programmer for writing new code but what about
>maintaining code?
>--
>ADavieCrockett

>--== Sent via Deja.com http://www.deja.com/ ==--
>---Share what you know. Learn what you don't.---

Wasn't this Microsofts initail problem with IBM? IBM wanted to charge by
LOC, and Microsoft thought it this should be the other way around; Less code
for the same job means (probably) more efficient & faster code, right?

Antal



Mon, 12 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:

>Wasn't this Microsofts initail problem with IBM? IBM wanted to charge by
>LOC, and Microsoft thought it this should be the other way around; Less
code
>for the same job means (probably) more efficient & faster code, right?

That's probably why NT is so "fast" and has such "low" demands for
hardware...

Cheeske



Mon, 12 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:

(snip)

> >Does anyone know the industry standard for the number of lines of MVS
> >cobol a programmer should be able to maintain?  I have seen a  number of
> >7-8000 LOC per year per programmer for writing new code but what about
> >maintaining code?
> >--
(snip)

> Wasn't this Microsofts initail problem with IBM? IBM wanted to charge by
> LOC, and Microsoft thought it this should be the other way around; Less code
> for the same job means (probably) more efficient & faster code, right?

Right, but Micro$oft managed to overcome that sort of thinking.

Bill {*filter*} <g>



Mon, 12 Nov 2001 03:00:00 GMT  
 cobol mantenance levels
I have seen between 150,000 to 500,000 lines of code supported
per person, depending on system quality, and amount of
time-wasting imposed by the organisation. Significant
enhancements would require extra people.

Tim Josling

Quote:

> Does anyone know the industry standard for the number of lines of MVS
> cobol a programmer should be able to maintain?



Wed, 14 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:

>The reason is a good
>coder will work to restructure the logic possibly reducing the
>line count as they make changes, a bad coder put additional code
>on top of additional code with no concern for structure and you
>end up with a total rewrite after a few years anyway.

I guess I work with bad coders.  I know I work with bad coders.
Last week I found about a hundred lines of code that could be
replaced with one single-line statement.

Geez, haven't they bothered to open the Cobol manual
to see what commands are available?



Thu, 15 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:


> >The reason is a good
> >coder will work to restructure the logic possibly reducing the
> >line count as they make changes, a bad coder put additional code
> >on top of additional code with no concern for structure and you
> >end up with a total rewrite after a few years anyway.

> I guess I work with bad coders.  I know I work with bad coders.
> Last week I found about a hundred lines of code that could be
> replaced with one single-line statement.

> Geez, haven't they bothered to open the Cobol manual
> to see what commands are available?

Sometimes people are unfamiliar with the latest COBOL functions.  We're
moving to COBOL for MVS and I showed someone a function (someone on this
NG mentioned to me), which probably saved him that much code.  He didn't
know we had a manual for COBOL for MVS.  I can often code 100 lines of
code more quickly than I could find a current manual (all of my manuals
are older).  And of course, code could have been written before the
function was available.

Still, I wish our shop would have a meeting to review new features with
all COBOL programmers.  Just knowing about them is usually sufficient.



Sat, 17 Nov 2001 03:00:00 GMT  
 cobol mantenance levels


[snippage]

Quote:
>> Geez, haven't they bothered to open the Cobol manual
>> to see what commands are available?

>Sometimes people are unfamiliar with the latest COBOL functions.

Extend this simple truism to shops where IGYCRCTL (Cobol '85) is the
'newest' compiler.  Multiply by the number of people who are *proud* to
say 'I've been doin' things the exact same way for the past 35 years!'
Stir gently and season with the salt from tears of frustration.

[snip]

Quote:
>I can often code 100 lines of
>code more quickly than I could find a current manual (all of my manuals
>are older).

I gave up bringing manuals to jobsites (I know they are available on CD
but I've been too cheap to spring for them... and besides, a manual is
*supposed* to be paper and dog-eared!)

Quote:
>And of course, code could have been written before the
>function was available.

>Still, I wish our shop would have a meeting to review new features with
>all COBOL programmers.  Just knowing about them is usually sufficient.

Hmmmmm... this sounds like a necessary co-ordination of personnel
(programmers) and resources (available COBOL features)... I wonder which
branch of the organisation is responsible for such things?

Pfah.

DD



Sat, 17 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:
>Still, I wish our shop would have a meeting to review new features with
>all COBOL programmers.  Just knowing about them is usually sufficient.

Gee, Howard, how about a class? We're just a few miles down the road from you
and we have a spiffy two day class that covers all the changes in COBOL from
'85 on, including some labs to get some hands on experience.

Check our web site (see signature), follow links to Topics, COBOL, and look at
"Beyond COBOL II"; contains course description, links to course objectives,
links to detailed course outline.

Cheers,

Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com

256-B S. Monaco Parkway
Denver, CO 80224
USA



Sat, 17 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

Quote:



> > >The reason is a good
> > >coder will work to restructure the logic possibly reducing the
> > >line count as they make changes, a bad coder put additional code
> > >on top of additional code with no concern for structure and you
> > >end up with a total rewrite after a few years anyway.

> > I guess I work with bad coders.  I know I work with bad coders.
> > Last week I found about a hundred lines of code that could be
> > replaced with one single-line statement.

> > Geez, haven't they bothered to open the Cobol manual
> > to see what commands are available?

> Sometimes people are unfamiliar with the latest COBOL functions.  We're
> moving to COBOL for MVS and I showed someone a function (someone on this
> NG mentioned to me), which probably saved him that much code.  He didn't
> know we had a manual for COBOL for MVS.  I can often code 100 lines of
> code more quickly than I could find a current manual (all of my manuals
> are older).  And of course, code could have been written before the
> function was available.

> Still, I wish our shop would have a meeting to review new features with
> all COBOL programmers.  Just knowing about them is usually sufficient.

COBOL for MVS manuals are available from IBM on your web browser!
Her is the site: http://mvshelp.com/ref01.htm

Pete



Sat, 17 Nov 2001 03:00:00 GMT  
 cobol mantenance levels

illuminated comp.lang.cobol thusly:

Quote:
> Extend this simple truism to shops where IGYCRCTL (Cobol '85) is the
> 'newest' compiler.  Multiply by the number of people who are *proud* to
> say 'I've been doin' things the exact same way for the past 35 years!'

35 years ago was before Cobol had the PICTURE clause.  I don't think it
had PERFORM either, just ALTER.  
--
R B |\  Randall Bart

n r |\  1-614-308-9307      Please reply without spam       I Love You
d t ||\ Have you solved http://users.aol.com/PanicYr00/Sequence.html ?
a    |/ MS^7=6/28/107             Let's sing about the Year 2000 Bugs:
l    |\             http://users.aol.com/PanicYr00/SongMiscellany.html
l    |/ Has anyone in Washington DC read the US Constitution?


Wed, 21 Nov 2001 03:00:00 GMT  
 cobol mantenance levels
No, Bart,

PERFORM, ALTER, AND GO TO were there from the beginning.  "store address and
go" or R U were common
assembly or maching functions then.

Warren Simmons

Quote:

> illuminated comp.lang.cobol thusly:

> > Extend this simple truism to shops where IGYCRCTL (Cobol '85) is the
> > 'newest' compiler.  Multiply by the number of people who are *proud* to
> > say 'I've been doin' things the exact same way for the past 35 years!'

> 35 years ago was before Cobol had the PICTURE clause.  I don't think it
> had PERFORM either, just ALTER.
> --
> R B |\  Randall Bart

> n r |\  1-614-308-9307      Please reply without spam       I Love You
> d t ||\ Have you solved http://users.aol.com/PanicYr00/Sequence.html ?
> a    |/ MS^7=6/28/107             Let's sing about the Year 2000 Bugs:
> l    |\             http://users.aol.com/PanicYr00/SongMiscellany.html
> l    |/ Has anyone in Washington DC read the US Constitution?



Wed, 21 Nov 2001 03:00:00 GMT  
 
 [ 15 post ] 

 Relevant Pages 

1. Migrating IBM COBOL from old levels to newer levels

2. Help with Microfocus personal cobol and Microfocus Level II cobol

3. ENTRY-LEVEL COBOL TEST

4. CA-Mission Viejo-Entry Level Cobol programmer

5. Looking for Entry-Level PC Cobol Compiler

6. SEEKING ENTRY LEVEL COBOL IN SEATTLE/PORTLAND METRO AREA

7. entry level cobol programmer

8. Entry-Level Cobol Prog.

9. COBOL MVS/CSP Intermediate Level Programmers

10. Entry-Level Cobol Prog.

11. entry-level COBOL Programmers

12. entry-level COBOL Pro

 

 
Powered by phpBB® Forum Software