HP3000-L Archives

March 1997, Week 3

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:
Nick Demos <[log in to unmask]>
Reply To:
Nick Demos <[log in to unmask]>
Date:
Wed, 19 Mar 1997 18:45:52 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (55 lines)
Nick Demos wrote:
> Well, I guess its war story time.

Alright, if everyone else is going to participate, here's my $0.02:

> My introduction to the HP3000 came in 1977 with the Series II (I knew
> I could gray-hair you guys).
Jeff Kell wrote:

Mine was in 1976, but at the ripe old age of 17.  Had HP2000 in 1975.

We were pressed by terminal limits on Series IIs.  Despite advise to the
contrary, we ended up with 64 terms on one Series II.  I devised a system
in '79 that replaced the JSMAIN/CI process tree - one batch job could
run a number of terminals.  Rather than the "process tree" approach of
MPE it did more of a Unix execv() call - separate process for login,
command selection, and applications with the "father" process handling
the transitions.  Our COBOL code was written around an in-house terminal
I/O package which was tweaked to talk to arbitrary files, not just
$stdin/$stdlist (this was before CIOR and stdin/list redirection).  If
any packrats have the 1981 Orlando user group proceedings, lookup my
paper on TERMNET.  Similarly, having these sessions under a common
process allowed us to do IPC before IPC was available using a shared
data segment to pass data between processes.
-----------------------------------------------------------------------------------------------------------

Something about great minds...................... is appropriate
here.  Our original design called for a master process for
terminal I/O (remember we had a special front end, so it
really came over one pipe) and dispatching, an Image
handler, a log file handler (the log file used for end  of day
processing and recovery), and one created process for each
 active POS terminal.   That last proved to eat up a lot of
CPU resource in task switching and we approached the
limit of active processes.  We therefore put the terminal
processing code in procedures.  To maintain where we were
we called special subroutine which stored its exit in a terminal
table.  Thus we could keep track of where we were for each
terminal and do away with the per terminal/process
approach. Requests for Image I/O and Logging I/O were
queued in extra data segments do we could process
completelya synchronous (including  credit card processing
with Big Blue when they were up!).

By the way, we processed in the BS queue - code length was
short so why not go to an I/O point (avoided process switching
overhead.  We also had normal HP terminals connected, which
ran in the CS queue.

Worked like a champ.

Regards,

Nick Demos

ATOM RSS1 RSS2