Re: IF statement, I don't understand this

In article <1143781234.779764.202290@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Richard <riplin@xxxxxxxxxxxx> wrote:
When I use 88 levels, I like their names to have the same root as the
data-name to which they apply, .e.g.

One of the reasons that I dislike 88 levels is that sometimes I need to
search for all uses of a variable using, say, grep, and the 88 levels
hide this usage. Certainly if the condition names were qualifed this
would avoid the problem entirely, but how would one guarantee that it
had been done in every case.

It might be done the same way that many things in many shops 'had been
done in every case', enforced by standard and code review. This is
insufficient? Welcome to the human race, where nothing is absolutely
certain in every case, including this statement.

Using the root name on the condition does
allow searching as long as the root is sufficiely unique.

But I tend to not use 88 levels at all because the various values are
still in the program even if they are localised and not in PD. I
prefer to have such data values in a 'decode file' which can be
modified by the user as required to suit changing needs.

For example the 'interest-bearing' example should (IMHO) be done by
having the interest rate in a file where authorized people can change
it and you find out if this is interest bearing or not by testing the
rate for zero. If the attribute of 'not interest bearing' is actually
not related to a zero rate then some other flag in the record should
say 'Y' or 'N' (or equivalent). Building codes such as 11, 21, 31, 41
into the program in PD or in 88s is just not good practice, except for
generating programmer job security.

Hmmmmm... leaving aside the quasi-religious war of 'No Hardcoded Values in
the Procedure Division versus No Hardcoded Values in Working-Storage' this
brings up the difficulties of *any* sort of maintenance. If the values
are in the code then the code will need to be maintained, an unpleasant
prospect. If the values are in files then the files have to be
maintained... and I've found that ensuring accurate routine file
maintenance can be almost as difficult as ensuring routine program
maintenance. I cannot count how many times I've heard:

'This report's all wrong, the values are off, your program must have
screwed up!'

'Let me see... the program hasn't been compiled in several years... ahhhh,
there it is, you ran it using last month's parameters/values, you didn't
change them to this month's.'

'Well... don't let it happen again!'

DD

.

Relevant Pages

  • Re: IF statement, I dont understand this
    ... not related to a zero rate then some other flag in the record should ... and I've found that ensuring accurate routine file ... maintenance can be almost as difficult as ensuring routine program ... arguing configuration files versus hard-coded values is hard. ...
    (comp.lang.cobol)
  • Re: BBCs Pegasus spaceship
    ... >>assorted rotating restaurants on various tall towers. ... >shut down for extended maintenance every six months or so. ... >going to be more like the shaft bearing on a ship, ... providing room for internal maintenance access.) ...
    (sci.space.policy)
  • Re: XTR V-Brake bearing lubrication
    ... >it mean that these bearing need no maintenance (cleaning/ lubricating)? ... After playing with the arm, it got loose, but now ... Everything needs maintenance. ...
    (rec.bicycles.tech)
  • Re: BBCs Pegasus spaceship
    ... >>A central bearing (howsoever slow rotating) for a large station is ... >>going to be more like the shaft bearing on a ship, ... >>for years on end, without significant maintenance. ... Touch-twice life. ...
    (sci.space.policy)