Re: How competent are we?

On Wed, 16 Jul 2008 14:54:49 +0800, "billious" <billious_1954@xxxxxxxxxxx> wrote:

Robert wrote:
On Wed, 16 Jul 2008 12:18:16 +0800, "billious"
<billious_1954@xxxxxxxxxxx> wrote:

Changes in file layout are easy if IO is isolated in called programs.
Old programs, without recompiling, get the old v1.0 layout; new
programs that ask for it get the v2.0 layout. Isolating the Data
Layer is common practice in client server. I used to do it on ALL my
mainframe sysstems. I converted one mission critical system from VSAM
to database-like VSAM just by rewriting data layers. Old programs
thought the file structures hadn't changed.

Oooh - that's a big IF. Should be in bold red 72pt caps.

The system in question was written in ACU COBOL on a micro system, derived
from a WANG system derived from a 1970s IBM system. It had been designed by
an accountant and maintained by "graduates" of the new school.

Their priority was firmly in the "make it look good" department - so the
users had to choose the printer for EVERY printout EVERY time. There had
been no attempt at data-analysis so the SINGLE SKU record contained such
things as purchase-order history, sales-history and current stock figures
FOR EACH BRANCH in an array. As the number of branches had increased, the
problems with record-locking had also increased (for some unknown reason.)
Their solution was to simply ignore I/O errors in the programs that were
most commonly-used (matrix-level 0?) There had been frantic attempts to
implement proper record-locking procedures - pity the programmers had no
idea of what they were doing - there were READ NO-LOCKs even on read-only
files; it was just another example of "apply the curing mantra and all will
be well" without actually UNDERSTANDING what the locking business was all
about. Ask the guru, and his solution will be applicable in all
circumstances.

The guru would be right if he said 'let the database take care of it' rather than 'only a
genius like me understands locking.'

There were also traces of earlier expansions - the occasional limit of 8
branches scanned in the loop rather than the current 15 branches. No idea of
setting a symbolic constant if you had to follow the accountant's path to
damnation - just "15" repeated possibly hundreds of times in each program.

Suppose the number of branches, 15, was in a copybook. Adding branch 16 would require
blanket-recompiling 650 programs. You'd be a fusspot about the magnitude of testing 650
programs. That's not a solution, that's an automated Band-Aid.

The object was of course to implement more branches. Every new branch needed
a new individual despatch-docket program - and each of the existing
despatch-docket programs had to be adjusted to recognise the new branch.
None of this new-fangled idea of finding branch details in a file like for
instance address-details or the array-index for the branch - oh no, each
reference was made to an individually-named field; SMITHTOWN-INVENTORY, not
INVENTORY(BRANCH-INDEX).

No no. The right solution is to get rid of all fixed-length arrays. Make branch the key of
a file or database table.

If you want to get fancy, make each branch a leaf in a tree structure. Or use hashes to
join multiple tables containing branches. The PhD will love you for that. It's really not
necessary because databases do that for you under the covers.

Management's understanding may be exemplified by their monthly sales-figures
report, lines of branch, columns of sales-category. The assistant general
manager claimed that the grand total balanced with the actual banking. All
of the columns added up correctly, all of the rows added up correctly. Pity
that the major two sales categories for the headquarters "branch" showed
zero sales, but they should have been about 40% of the total - not an
insignificant hole. He claimed that these figures were "suppressed." Er - in
that case, the total wouldn't balance with the banking - and I'd just
changed the program to add a new branch - no sign of suppressing the
figures, they could only have been misallocated. But that's the way the
report had been for years - so therefore it had to be correct.

There was once a tax advantage to misallocating overhead, but it went away 30 years ago.
There could still be a personal advantage in that the favored branch managers get bigger
bonuses.

So - good theory about isolating Data Layers. Studying for a PhD, are you?
;)

I've worked on systems that evolved as you described. For example, supermarkets
classically have four departments -- grocery, meat, produce and non-food. It's small
enough to keep in an array. Then they add deli, flowers and photo for a total of seven.
Then they add pharmacy, liquor and sandwich, etc, etc. One day you have twenty
departments, with more on the way.

That wouldn't happen if data structures had been designed in normalized form from the
beginning.

As I've said here, design should be top down. That company's systems were designed bottom
up and their people are still thinking bottom up, evidenced by your concerns over record
locking and arrays. Bottom up design gets you so far before it breaks down due to
exponentially increasing coupling (complexity). It sounds like that company's systems
crossed the threshold more than a decade ago.

The solution is not more of the same, poured on harder. That's what got them into this
condition. The solution is to start over with a top down design. The challenge is doing
it while the system is in flight. The only way to do that is with data layers or logical
views capable of simulating the old data structure. Then rewrite programs one at a time
over a year or two. This isn't theory, I've done it many times.
.

Relevant Pages

  • Re: Puppy Mastiff wants to Nip at Faces
    ... in my first college textbook on structured programming. ... they did was loop through an array to show how you could easily ... design, PIC code, and real time programming. ...
    (rec.pets.dogs.behavior)
  • Re: Antenna computor programs and pitfalls
    ... This is an "antenna designing" program. ... judgement and skill in antenna design, ... Can I hold a 5 meter by 4 meter array flat enough to ... number of pulses are by far superior toi any other computor program. ...
    (rec.radio.amateur.antenna)
  • Re: Programming Dilemma
    ... Since you mention Visio, I'll point out that one option is Visio itself ... Our MetaDraw control is another component you might consider. ... g) Scroll or zoom the entire layout ... > My boss wants me to design a fairy basic Electronic Digital ...
    (comp.programming)
  • Re: Improving Word 2007
    ... <to move the Borders button from Design to Layout. ... Table Design to Table Layout? ... then recreate a custom group that contains the commands you want to show. ...
    (microsoft.public.word.docmanagement)
  • Re: Newbie Question : Board level design
    ... Do you have any actual layout tools in mind? ... requirements of the board are clear, the electrical design requirements ... App notes live in a perfect, ... other chips onboard, what is the first thing you go searching for? ...
    (sci.electronics.basics)