Re: When is a stack used in real life?

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 05/10/04 

Date: 9 May 2004 17:21:56 -0700

Gunnar G <debian@comhem.se> wrote in message news:<%P7nc.58533$mU6.237516@newsb.telia.net>...
> Hello.
>
> I need some help to find an interesting programming exerise.
> We are going to study the stack, and therefor I'm looking for an
> interesting real world example where a stack is natural to use to handle
> the data.
>
> It's not hard to find an example, one would be to simulate my desk and me
> shuffling paper, (since there are of course large piles of paper) but that
> would hardly be interesting.
>
> Any good ideas?
>
> TIA,
> Gunnar.

Reinsurance is insurance provided by large insurance firms (such as
Lloyd's) to insurance companies that have in turn underwritten large
amounts of risk. The original underwriters in turn purchase
reinsurance concepts.

In the 1970s, I was assigned to fix a horrible Cobol program written
for a reinsurance firm that was failing, and I discovered that some of
the input contracts were reinsuring reinsurance contracts at two or
more levels. The Cobol program, upon reading the second contract, had
no way of returning to the reinsured contract because it read each
contract's data into a simple "work area".

The solution was to simulate a stack using the OCCURS DEPENDING ON
clause of Cobol and a separate stack pointer.

Another practical, business application was Bill of Material
Processor, a precursor application to today's MRP systems which in the
1970s were being written by consultants in Cobol and BAL for any
number of midsized Chicago firms. Again, the programmers, typically
untrained in formal computer science, would either not implement an
assembly with subassemblies as a stack, or would reason that it made
no sense to have more than a small, finite number of levels without
consulting the user.

Many of the practical applications of stacks are today folded within
commericial packages. For example, an org chart drafting program uses
a stack.

The stack for many years was underused because IBM mainframe
architecture up to and including the 360 and 370 did not use a stack
for its call mechanism, meaning that even assembler programmers for
IBM mainframes did not learn about stacks. Instead, the IBM 360 had 16
"general purpose registers" and it was the responsibility of the
subprogram and its caller to manage saving and restoring these
registers.

European theorists have suggested that American praxis disregarded the
stack because it implies that a process, or indeed a worker, might do
subtasking and in American factories and offices, work-to-rule implies
that the employee should not deeply subtask. For example, in the movie
Erin Brockovich, Erin goes off for a week to find out why a real
estate file has medical bills in it, and on returning to the office,
she's summarily fired.

The stack and its depth imply a mystification of even the simplest
problem, and we can speculate (or at least I can) that American
management fears that deep problem analysis might be goofing off.

Of course, the Pentium architecture and the C language put paid to the
notion that we can get by without stacks. But on the whole, they are
more applicable to programming language translation and call
mechanisms than MIS programming.