[no subject]

2020-06-30 Thread William Pechter via cctalk


Re: [HECnet] VAX/VMS 3.0 Distribution Available for Download

2020-03-21 Thread William Pechter via cctalk
This brings me back to the days on the installation team in February 1982.  I 
was installing 2.0 and 2.2.  I seem to remember VMS 3.5 supporting the 86xx 
systems.  Anyone have docs? 

Sent from pech...@gmail.com

-Original Message-
From: Ray Jewhurst 
To: hec...@update.uu.se
Cc: "General Discussion: On-Topic and Off-Topic Posts" , 
simh , John Dundas 
Sent: Sat, 21 Mar 2020 8:35
Subject: Re: [HECnet] VAX/VMS 3.0 Distribution Available for Download

From 1982 I see. I know that this will run on the 780/785 but what about
the other VAX-11s or the 8600? I am purely a simulator and have never used
the real thing and I am not sure what years the models in question were
released. Sorry if my questions seem ignorant.

Ray

On Sat, Mar 21, 2020, 8:08 AM Supratim Sanyal  wrote:

> John Dundas' distribution of VAX/VMS version 3.0 (April 1982) can now be
> downloaded from my Dropbox.
>
> The SYSTEM password is MANAGER.
>
> Note: Dropbox does not force you to create an account, if you look
> carefully you will see a "Continue to view" link at the bottom of that
> pop-up.
>
> Here's what it boots into:
>
>
>VAX/VMS Version V3.0 26-APR-1982 16:21
>
>
> PLEASE ENTER DATE AND TIME (DD-MMM-  HH:MM) 21-MAR-2020 11:58
> %JBC-I-NEWQUEUE, new queue file created
> %OPCOM, 21-MAR-2020 11:58:34.51, logfile initialized by operator OPA0
>  logfile is SYS$MANAGER:OPERATOR.LOG
>Login quotas - Interactive limit=64, Current interactive value=0
>SYSTEM   job terminated at 21-MAR-2020 11:58:39.91
>
> Username: SYSTEM
> Password:
>  Welcome to VAX/VMS version V3.0
> $
> $
>
> Grab it from https://bit.ly/vaxvms30
>
> Regards,
> Supratim
>
> --
> Supratim Sanyal, W1XMT
> 39.19151 N, 77.23432 W
> QCOCAL::SANYAL via HECnet
>
>


Re: cctalk Digest, Vol 60, Issue 1

2019-09-01 Thread William Pechter via cctalk
Re:Re: So what the heck did I just pick up?

My guess is some type of interface between 1970's vintage Storage
Technologies gear and some test equipment and the
Tape subsystem.  Perhaps a bus switch.

The clue is the STC Red and Black property number on the back -- that mates
the Storage Tek (then Storage Technologies Corp.
colors in their early days... So it's either something they purchased or
bought.  The vintage look and 64 bit width makes me figure
it was either some kind of tape bus switch/diag panel for manufacturing or
field service use.

64 bits wide would be 2x32 bit word size.

Perhaps they built a diag box that sat before the IBM channel to let them
debug tape data transfers.  The other thought is some kind of  key to tape
alternative keypunch system...

Bill


--
  d|i|g|i|t|a|l had it THEN.  Don't you wish you could still buy it now!
 pechter-at-gmail.com

**
>


Re: PDP-11/45 RSTS/E boot problem

2019-02-14 Thread William Pechter via cctalk
> Message: 2
> Date: Wed, 13 Feb 2019 15:03:41 -0500
> From: Paul Koning 
> To: Jay Jaeger , "General Discussion: On-Topic and
>     Off-Topic Posts" 
> Subject: Re: PDP-11/45 RSTS/E boot problem
> Message-ID: 
> Content-Type: text/plain;    charset=us-ascii
>
>
> > On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk
>  wrote:
> >
> > ...
> > Maybe that story about FE's using Unix as a test to confirm operation
> > even when diagnostics said the machine was OK was not so much just a
> > legend?
>
> It still fels like a legend.  My experience with DEC field service
> engineers is that they used the diagnostics.  In the PDP-11 era, Unix
> knowledge around DEC was pretty sparse, especially early on when it
> could be found only in the Telephone Products Group (Armando
> Stettner).  RSTS would be more plausible, but I never saw that in the
> hads of FS engineers either.
> By and large diagnostics would find problems. I've seen a number in
> the 1970s, including a messy data path failure in the 11/45 MMU where
> we (college students) did the initial diagnosis while the FS engineer
> was on his way. My suspicion is that things not solved by diagnostics
> would be escalated to the "wizard from Maynard". And they'd probably
> start replacing whole subsystems. I've seen that once, when our
> college RSTS-11 system (11/20, 16 DL-11 lines) was crashing on average
> once a day for months. DEC brought in several of those "wizards". The
> "fix" was to replace the 11/20 by a "spare part" -- an 11/45 with more
> memory, a DH11, and RSTS/E. Decades later I was told that the wizards
> actually pinned the blame on the college FM broadcast transmitter,
> about 200 feet down the hall from the computer center. That may well
> be, though I didn't heard that at the time. RSTS did get used in
> manufacturing, at Final Assembly & Test sites like Westminster MA and
> Salem NH, where PDP-11 systems large enough to run RSTS/E were
> subjected to a load test of exerciser programs running under that OS.
> The way it was explained to us is that a system that would be happy
> with such a test would also be happy with any customer application.
> It's not clear if that was because RSTS would load things more than
> most, or was more finicky about hardware glitches than most, but it
> certainly was the practice for quite some time. Of course, not all
> PDP-11 configurations could be tested that way. paul

I guess the experience in NJ was a bit different since AT had two
dedicated Field Service offices who handled their sites including Bell Labs.

I was on the Commercial/Government side from 81-86 and we didn't get to
play with RSTS on customer sites at all (but sometimes we got to play in
the in-house machines in Princeton or on our own hardware).

It was a bit different in the Vax side since many diags were run under
VAX/VMS and as a brand new hire I was doing Vax installs -- including
installing the VMS 2.x and 3.x on 11/780's and 11/750's at install time.

If they had paid for software installation -- the software guys would
wipe and reinstall.
If not we left the pack and prayed the customer wouldn't wipe the diags
that we installed on the disk when we build the VMS pack.  Realistically
the only thing the customer needed to do after we got done was tweak the
systen parameters, check the swap etc. and lay on the layered products
like languages.

Things got much more interesting when the VMS3.x and 4.x got CI780's and
HSC50's.  That was more involved than the easy VMS 2.x-3.x install.

As far as the 11/70's -- I'm building a pidp1170... My last 11/70
install was around 84 or so when I put in a late DECDatasystem 570 blue
11/70 with the FCC Cabinets at AT in Freehold.

As far as the Wizard from Maynard -- one story from my branch support
guy (rumored to be about his
brother on the 11/70 line in (I think in Westminster MA... not Salem or
other NH plants) had an intermittant 11/70 that would crash every couple
of days and they could run all the diags and DEC X11 with no issues. 
They called over their in-house wizard who ran toggle-in programs from
the front panel -- playing the switches like piano keys with both
hands.   After about a half hour his comment was "Clean the terminator
fingers."

Machine ran like a SOB once the gold fingers were cleaned.

Weirdest 11/70 mess I had was after I left DEC to work for a third party
maintenance group.  Their regional support was in Dallas.  I was in NJ. 
They couldn't find their support guy so they rushed me on a plane to
Chicago to work with two techs who were babysitting a mess they had no
clue on.

The site was WW Granger in Skokie and I arrived at 3AM...  They had a 5
or 6 story warehouse which was a totally robotic automated site picking
water heaters and other industrial equipment from what looked like an
over-sized 6 floor tape library.  Two 11/34's running RSX11 ran the
picker.  One was down for weeks.  Their 11/70 was half disassembled with
two techs working on it.  They were VAX trained at a 

Re: [TUHS] Ultrix Tape: Block Size?

2018-10-16 Thread William Pechter via cctalk
DEC Tape II was the serial driven TU58.
The TK50 was CompacTape or something like that.  It was the predecessor of a 
number of square tapes...

See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape

Bill

-Original Message-
From: Paul Winalski 
To: Clem Cole 
Cc: The Eunuchs Hysterical Society , cctalk@classiccmp.org
Sent: Tue, 16 Oct 2018 13:14
Subject: Re: [TUHS] Ultrix Tape: Block Size?

On 10/15/18, Clem Cole  wrote:
> #$%^ - they >>weren't<< like DECtape from a reliability standpoint ...
> ᐧ
The original DECtape was extremely reliable.  Not so the TK50.
Calling it "DECtape II" was an insult to the original DECtape.  The
problem wasn't so much the drive itself, but the controller.  In an
effort to reduce costs, DEC used a controller that had insufficient
buffering capability for a streaming, block-replacement tape device
such as the TK50.  TK50s were prone to both data-late and overrun
errors.

The block size is almost certainly 512 bytes.

-Paul W.