HP3000-L Archives

February 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Rudderow, Evan" <[log in to unmask]>
Reply To:
Rudderow, Evan
Date:
Mon, 5 Feb 1996 09:36:00 EST
Content-Type:
text/plain
Parts/Attachments:
text/plain (32 lines)
Hi all,
 
Has anyone out there run into this client/server gotcha?  And, if so, how
did you work around it?
 
The background is that we have a number of systems (HP3000, HP9000, Vax) as
servers; now, if you log on to one of these systems in a session, you'll get
a nice welcome message which details the downtime schedule..  This past
Sunday some users of one of the client/server applications that's in
development came in to work on the pilot; they were unable to do so: getting
pretty wacky errors that misdirected both them and Help Desk personnel as to
the real problem.
 
The real problem was that the HP9000 server for that application was down:
as per the posted_on_the_welcome_screen downtime schedule.
 
As we move forward and deploy more C/S applications, I see the opportunity
for this problem to get worse: C/S app users, since they don't log on to the
server with a "terminal" session, never see the welcome message describing
the downtime errors.  And depending upon the capabilities of the underlying
transport mechanisms, ODBC drivers, and database networking products, they
may well receive a bogus and/or deceptive message about what exactly is
wrong.  It seems to me that, being that it's 1996, there ought to be *some
way* to return an informative -- and correct --message to the user apprising
him that the system is down.
 
Hence my question about whether anyone else has tackled this yet...
 
Regards.
 
 -- Evan

ATOM RSS1 RSS2