Obscure Systems in my Past

[Kurt Weiske]

Posting about the Pick system I worked on reminded me of another weird
system I worked on.

This was back in the mid '90s. The head of IT wanted a single-source
solution for the entire network. We ended up with underpowered HP Vectra
486 desktops, HP ethernet switches, and HP/9000 (I believe) system
running HP/UX and Informix, and Portable Netware, a port of the Netware
Core Protocols as an application under UNIX.

We used a document tracking system who's name I've since forgotten that
used the Informix database to store documents under the PNW layer. It
It comprised the most expensive, slowest network I've ever supported.

After the system crashed, you'd need to run FSCK on the UNIX file
system, repair the database, then run a separate utility on the virtual
Netware file system.

Oh, and just for kicks, the WAN ran on frame relay, with a 256kb/sec
backbone and 64kb/sec nodes starred off of the backbone. When employees
from another branch would come to our office to work on a project, their
home drives and login scripts were mapped to the remote server that was
over 2 already saturated 64kb/sec links - and guess who they
complained to?

All printing was tracked by client and billed back, so any unbilled
printing raised eyebrows. Luckily, I found an unused HP Laserjet 4 with
some ungodly amount of pages on the fuser (those printers were workhorses!)
and could print all of my BBS manuals without worry.



--- MultiMail/Win v0.52
--- Synchronet 3.20a-Win32 NewsLink 1.114
* realitycheckBBS - Aptos, CA - telnet://realitycheckbbs.org

[vallor]

On Thu, 20 Jun 2024 06:57:00 -0700, "Kurt Weiske"

Post by Kurt Weiske
Posting about the Pick system I worked on reminded me of another weird
system I worked on.
This was back in the mid '90s. The head of IT wanted a single-source
solution for the entire network. We ended up with underpowered HP Vectra
486 desktops, HP ethernet switches, and HP/9000 (I believe) system
running HP/UX and Informix, and Portable Netware, a port of the Netware
Core Protocols as an application under UNIX.
We used a document tracking system who's name I've since forgotten that
used the Informix database to store documents under the PNW layer. It It
comprised the most expensive, slowest network I've ever supported.
After the system crashed, you'd need to run FSCK on the UNIX file
system, repair the database, then run a separate utility on the virtual
Netware file system.
Oh, and just for kicks, the WAN ran on frame relay, with a 256kb/sec
backbone and 64kb/sec nodes starred off of the backbone. When employees
from another branch would come to our office to work on a project, their
home drives and login scripts were mapped to the remote server that was
over 2 already saturated 64kb/sec links - and guess who they complained
to?
All printing was tracked by client and billed back, so any unbilled
printing raised eyebrows. Luckily, I found an unused HP Laserjet 4 with
some ungodly amount of pages on the fuser (those printers were
workhorses!)
and could print all of my BBS manuals without worry.

Very reminiscent of c. 1991, when the campus library computer
was an HP9000/835 running HP\UX 8, with the card catalog as
a Pick application. (Pick ran as a Unix process.) I was
a student worker in Computing Services at the time.

At the time, there was a new application making waves
on the Net called "hytelnet", which was a simple curses
application that let people choose telnet or gopher
commands from a menu -- say, to connect to the UC Berkeley
card catalog system over the Net. The HP9000 had a modem
bank, so for many home users, this was their first
view of the Net.

Nobody thought about telnet's escape character, or its ability
to invoke a shell, so there was a party of Unix, um, "enthusiasts"
taking place on the filesystem. I changed the telnet escape character
to something that couldn't be typed, and that ended that.

In 1992, I used the Manchester Computing Centre's boot/root floppy
set to put Linux on a spare HP Vectra RS/20, which became
a popular student-access "Unix" host. Will have to save
that story for another post.

[Lawrence D'Oliveiro]

Nobody thought about telnet's escape character, or its ability to invoke
a shell, so there was a party of Unix, um, "enthusiasts" taking place on
the filesystem. I changed the telnet escape character to something that
couldn't be typed, and that ended that.

Nowadays you could stick them in a “guest” container, where they couldn’t
do any real mischief.

Back in the previous decade, before I knew what “containers” were, some
friends and I were setting up Linux systems for public use at a community
centre. One of them turned on Ubuntu’s “guest” feature, which was pretty
tightly locked down--you couldn’t see any other users on the filesystem.
And the whole account was wiped when you logged out.

Just to add to the fun, it assigned a new unique user ID to the next guest
session. I don’t know what happened after it hit the maximum available
user ID, whether it cycled around or not. We never got that far.

[Lynn Wheeler]

Post by Kurt Weiske
Posting about the Pick system I worked on reminded me of another weird
system I worked on.

801/RISC ROMP chip ran CP.r implemented in PL.8 ... was going to be used
for displaywriter follow-on. When displaywriter follow-on got canceled
(word processing moving to ibm/pc), they decided to pivot to the unix
workstation market and got the company that did AT&T Unix port of IBM/PC
for PC/IX, to do one of ROMP (PC/RT and AIX). The issue was what to do
with the 200 PL.8 programmers.

They decideded to do VRM, a sort of virtual machine implementation in
PL.8 and told the unix port company it would be faster & simpler if
instead of porting to real ROMP ... it would be simpler&faster if they
ported to psuedo virtual machine VRM interface instead (one downside for
unix market, was that new device drivers required both unix/aix C driver
and a VRM PL.8 driver).. Then to help justify the VRM, they also got
Pick port to the psuedo virtual machine VRM interface (and could run
concurrently)

Note IBM ACIS had a few people in the process of doing a UCB BSD port to
(mainframe) 370 when they were told to instead port to PC/RT (bare
machine w/o VRM), ... which took enormously less resources and
enormously less time than either VRM or AIX.

[Lawrence D'Oliveiro]

Post by Kurt Weiske
After the system crashed, you'd need to run FSCK on the UNIX file
system, repair the database, then run a separate utility on the virtual
Netware file system.

Absolutely commonplace back then. Aren’t you glad journalling filesystems
are commonplace nowadays?

Even database crashes don’t seem to be as big a deal any more.