Instruction Set Evolution 
Author Message
 Instruction Set Evolution


> [...]
> >In the 70's I worked in a shop that after any crash or power failure
> >they would IPL a stand alone program that searched through core on the
> >MVT system and closed off all files that were OPEN at the time of the
> >crash. This was part of there backup/recovery system. Real hadny trick
> >for journal data sets.

> Maybe so, but it in the case of a system crash it seems counter
> to the long-standing IBM philosophy that dictates _not_ flushing
> unwritten buffers during the quasi-CLOSE performed during
> abnormal termination.  How do you know that buffer contents are
> reliable?

> /b
> --
> Bill Manry  -  IBM Products Division  -  Oracle Corporation USA
> These are my opinions, not necessarily Oracle's.

Good question. Since it was the beginning of my career I wasn't involved
in it. Didn't understand it very well either.


Beyond Software, Inc.       http://www.*-*-*.com/
"Transforming Legacy Applications"

Sun, 11 Feb 2001 03:00:00 GMT  
 Instruction Set Evolution
Sorry if I post this too many times, but it is still my favorite IBM
machine story.  Also, EX discussion is still going on.

The reason for the EX exception, so that an EX can't execute another
EX instruction, is that in a previous IBM machine EX could execute EX.

If an EX executed itself, a loop that could not be broken by power off/
power on reset was created.  Hint:  the program counter was in magnetic
core memory.

Sometimes nonvolatile memory is a disadvantage.

-- glen

Mon, 12 Feb 2001 03:00:00 GMT  
 Instruction Set Evolution


>IBM provided the standalone program for IMS to close out its log tapes
>after a power failure, so it must not have been counter to IBM philosopy
>at the time.  IMS did get caught with there shorts down when bipolar
>memory came out on the 370/145.  Their recommended recovery with the
>standalone program no longer worked, and they had to take an APAR on it.
>Interesting hardware dependency in software design.

A power failure is different from a system crash: software corruption
generally isn't involved.  Under similar reasoning, the automatic close
of open DCBs/ACBs for a task that terminates normally _does_ flush
unwritten buffers.  Normal termination isn't the same as a power failure
but the parallel is clear.  Still, there are some messy issues involved
in flushing access method buffers.  When using QSAM locate mode output,
for example, there is no easy way to determine if the application has
moved data into the area whose address was returned by the last PUT

As someone else pointed out, just getting the correct EOF hardened to
the media might be useful for recovery.  That has a lot less risk than
writing potentially corrupted data to the file, and might be reasonable
even after a software-related crash.

Bill Manry  -  IBM Products Division  -  Oracle Corporation USA
These are my opinions, not necessarily Oracle's.

Mon, 12 Feb 2001 03:00:00 GMT  
 Instruction Set Evolution


> This is a characteristic of core memory - it was possible to restart a
> program after a power failure because memory contents had been
> preserved. It wasn't trivial, but it could be done.

And that is also why a few us the started as operators either learned
or knew where to find the console sequence to ripple memory.  We
use to a 1400 emulater on a 360/30 that would fail at least once every
4 or 5 months.  A quick "ripple" and reIPL always solved the problem.

As a "tale from the past," I was called one night around 4am were this
was the problem.  The operator said he couldn't find the handbook so
I told him the sequence over the phone.  Now the only reason I know
this is because HE told me about when I got in that morning.  I had not
woken up when he called and managed to recite the stuff in my sleep...


Mon, 12 Feb 2001 03:00:00 GMT  
 [ 109 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 

Powered by phpBB® Forum Software