, but draw some ire from people who
think their favorite OS runs on a (non-IBM) mainframe.
Mark Post
-Original Message-
From: Dale Strickler [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 9:25 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
-snip-
The Linux on zOS
Well, actually, so do I, but we're a vanishing species.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Paul Hanrahan
Sent: Tuesday, October 28, 2003 6:12 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
I do
-Original
access faults.
Recovery is only as good as the language framework allows it to be.
Compilers insulate you from the data and the hardware, and
reduce your level
of control over how errors are handled.
But that's part of what you're buying by using a compiler
in the first
place: Not to have
I tend to disagree with the language being of a lot of importance. But at
the same time it can be. I have work in many real time OS, many home brew
and some WindRiver stuff. All on critical systems, test equipment for
nuclear reactors, air planes and such. The Linux on zOS is new to me but
At 09:25 AM 2003_10_29, you wrote:
I agree completely, but I come from an Assembler background where you HAD
to sanity check EVERYTHING. The volume of buffer overflow issues in C
programs boggles my mind. Even after I started
coding in C, I still maintained a similar level of paranoia regarding
) To: [EMAIL PROTECTED]
[EMAIL PROTECTED]cc:
Sent by: Linux onSubject: Re: [LINUX-390] Memory access
faults.
390 Port
[EMAIL PROTECTED]
IST.EDU
Strickler
Sent: Wednesday, October 29, 2003 9:25 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
I tend to disagree with the language being of a lot of
importance. But at
the same time it can be. I have work in many real time OS,
many home brew
and some WindRiver stuff
On Wed, 2003-10-29 at 08:31, Dale Strickler wrote:
This is good *IF* it is not a critical system. If the application is
moving billions of financial transactions around the world and it costs
brokers millions of dollars for every minute of down time just stop
everything, and let someone fix
]
lesoft.com cc:
Sent by: Linux on Subject: Re: [LINUX-390] Memory
access faults.
390 Port
[EMAIL PROTECTED]
ST.EDU
10/29/2003 09:31
AM
So what SHOULD the application do about something like that?
The answer goes back to that point I made in an earlier item
about data integrity. If you don't KNOW what the field is supposed to
contain, stop everything, report the failure, and let someone
fix it. It seems inconvenient, but in
Well, given that I work for a financial institution, I can say that in many cases
stopping everything is exactly what DOES happen. Charging ahead, knowing you're
dealing with potentially
corrupted data and not knowing the extent of the problem, is irresponsible.
Aside from the financial
in the spirit of Halloween.
Vlad Dracul effectively demonstrated the use of pointers.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
John Campbell
Sent: Wednesday, October 29, 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
I recall
Campbell
Sent: Wednesday, October 29, 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
I recall the words of one sage:
Never test for an error you don't know how to handle.
I've also heard a story about NASA's message switching network (when
At 10:10 AM 2003_10_29, you wrote:
Well, given that I work for a financial institution, I can say that in
many cases stopping everything is exactly what DOES happen. Charging
ahead, knowing you're dealing with potentially
corrupted data and not knowing the extent of the problem, is irresponsible.
to Master Yoda )
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf
Of
John Campbell
Sent: Wednesday, October 29, 2003 9:52 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
I recall the words of one sage:
Never test for an error
]
et.att.net cc:
Sent by: Linux on 390Subject: Re: [LINUX-390] Memory
access faults.
Port
[EMAIL PROTECTED
things didn't go exactly as planned.
The last 5% accounts for 90% of the cost.
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Dale Strickler
Sent: Wednesday, October 29, 2003 10:36 AM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults
For
instance a nuke plant run off of one Window NT box that could
give a 'Blue
Screen of death' would be a REALY bad system design...
Thought that would
be an example of a system deciding to 'stop' and alert the user when
something went wrong.
In that case, it had better NOT abort, but go
]
Subject: Re: [LINUX-390] Memory access faults.
Gregg,
I pre-date them that toys. I did a lot of time on Sigma-9s and
UNIVAC 1100s...
Though I *have* done terminal enemalators for MS-DOS
(in TASM) so I
have some experience doing assembler language.
Additionally
At 10:58 AM 2003_10_29, you wrote:
Okay, in that sense, I agree. The more general point, however, is that if
a decision comes down to availability vs. data integrity, integrity wins.
Absolutely integrity wins!
snip
The last 5% accounts for 90% of the cost.
Amazingly very true.
(An other,
Port [mailto:[EMAIL PROTECTED] On Behalf Of Dale
Strickler
Sent: 29 October 2003 17:37
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
At 10:58 AM 2003_10_29, you wrote:
Okay, in that sense, I agree. The more general point, however, is that if
a decision comes down to availability vs
That telephone operator played by Lily Tomlin, if I recall correctly... ;)
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
John Cassidy
Sent: Wednesday, October 29, 2003 12:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults
) To: [EMAIL PROTECTED]
[EMAIL PROTECTED]cc:
Sent by: Linux onSubject: Re: [LINUX-390] Memory access
faults.
390 Port
[EMAIL PROTECTED]
IST.EDU
10/29
At 12:35 PM 2003_10_29, you wrote:
Who is Enstine ??
Oops fingers and brain not connecting today... Einstein as in Albert!
-Dale
Catching the fault with sigaction does not give you much opportunity to correct and
continue. In fact it seems that you cannot continue from the signal handler. I don't
have access to a Linux system, but I tried ignoring the fault on our z/OS Unix system,
and the process went into an infinite
On Tue, 2003-10-28 at 13:32, Fargusson.Alan wrote:
The problem with laying this at the feet of the application programmer
is that they are not perfect, and when the program fails it actually
the end user that suffers.
Yes, but do you have a better suggestion?
I mean, in the common case, you
The problem with laying this at the feet of the application
programmer is that they are not perfect, and when the program
fails it actually the end user that suffers.
Unfortunately, that's about the only place it *can* go. Users can't (or
shouldn't be able to) change the code on the fly, or,
-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
Adam Thornton
Sent: Tuesday, October 28, 2003 2:43 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
On Tue, 2003-10-28 at 13:32, Fargusson.Alan wrote:
The problem with laying this at the feet
anyway?
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of
David Boyes
Sent: Tuesday, October 28, 2003 2:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
The problem with laying this at the feet of the application
programmer
On Tuesday, 10/28/2003 at 01:43 CST, Adam Thornton
[EMAIL PROTECTED] wrote:
In any event, what *is* the correct behavior?
+--+
|Application Failure |
| Program XYZ has failed. Because it did |
| not register for automatic failure
making sure
he feels their pain and fixes it!
Fargusson.Alan
[EMAIL PROTECTED] To: [EMAIL PROTECTED]
tb.ca.gov cc:
Sent by: Linux on Subject: Memory access faults
On Tue, 2003-10-28 at 14:31, Alan Altmark wrote:
| surrounding the failure. Feel free to |
| curse and pound on the desk in anger.|
| It won't help. Really. |
I find that it helps quite a lot, myself.
It doesn't help me get my job done any quicker, but I feel better.
?).
-Original Message-
From: Adam Thornton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 11:43 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
On Tue, 2003-10-28 at 13:32, Fargusson.Alan wrote:
The problem with laying this at the feet of the application programmer
Altmark
Sent: Tuesday, October 28, 2003 3:32 PM
To: [EMAIL PROTECTED]
Subject: Re: [LINUX-390] Memory access faults.
On Tuesday, 10/28/2003 at 01:43 CST, Adam Thornton
[EMAIL PROTECTED] wrote:
In any event, what *is* the correct behavior
in VisualBasic, although VB is written in C, so I
guess that doesn't prove anything.
-Original Message-
From: David Boyes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 11:52 AM
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
The problem with laying this at the feet
On Tue, 2003-10-28 at 14:54, Fargusson.Alan wrote:
The answer to this may be: it depends.
In a batch program it is probably best to abort the program.
In a windowing environment it might be best to ask if the user wants
to continue. Timesharing users might want an option to tell programs
to
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
On Tue, 2003-10-28 at 14:54, Fargusson.Alan wrote:
The answer to this may be: it depends.
In a batch program it is probably best to abort the program.
In a windowing environment it might be best to ask if the user wants
to continue
I do
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Hall,
Ken (IDS ECCS)
Sent: Tuesday, October 28, 2003 3:06 PM
To: [EMAIL PROTECTED]
Subject: Re: Memory access faults.
Recovery is only as good as the language framework allows it to be.
Compilers
I was thinking of batch in z/OS terms, ware there is a distinction. If
the OS does not have this distinction then you would treat
batch and interactive the same for error handling.
That's one of the things I always thought was superior about the TOPS-20 and
VMS batch systems. Batch and
39 matches
Mail list logo
