Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service
exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
Should I attempt this from a conversational boot, or would that not help?
Thanks, Mark.
On Thu, 15 Sep 2011, hvlems at zonnet.nl wrote:
The output of
$ mc ncp show circ ewa-0 char
will tell you whether it worked: the attribute service must have the value enabled.
If that is not the case check:
$ mc ncp list circ ewa-0 char
The service enabled value must be present and reboot the system to make it effective.
You'll see decnet opcom messages only on OPA0 or on a terminal where the command $ REPLY/ENABLE was entered. Hans
Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service
exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
Should I attempt this from a conversational boot, or would that not help?
Thanks, Mark.
On Thu, 15 Sep 2011, hvlems at zonnet.nl wrote:
The output of
$ mc ncp show circ ewa-0 char
will tell you whether it worked: the attribute service must have the value enabled.
If that is not the case check:
$ mc ncp list circ ewa-0 char
The service enabled value must be present and reboot the system to make it effective.
You'll see decnet opcom messages only on OPA0 or on a terminal where the command $ REPLY/ENABLE was entered. Hans
Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
Should I attempt this from a conversational boot, or would that not help?
Thanks, Mark.
On Thu, 15 Sep 2011, hvlems at zonnet.nl wrote:
The output of
$ mc ncp show circ ewa-0 char
will tell you whether it worked: the attribute service must have the value enabled.
If that is not the case check:
$ mc ncp list circ ewa-0 char
The service enabled value must be present and reboot the system to make it effective.
You'll see decnet opcom messages only on OPA0 or on a terminal where the command $ REPLY/ENABLE was entered. Hans
Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service
exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
** Dumping error log buffers to HBVS unit 0
**** Unable to dump error log buffers to remaining shadow set members
** Error log buffers not dumped to HBVS unit 100
Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service
exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
** Dumping error log buffers to HBVS unit 0
**** Unable to dump error log buffers to remaining shadow set members
** Error log buffers not dumped to HBVS unit 100
Circuit EWA-0, Line synchronization lost
NCP>
**** OpenVMS Alpha Operating System V8.3 - BUGCHECK ****
** Bugcheck code = 000003C4: SSRVEXCEPT, Unexpected system service exception
** Crash CPU: 00000000 Primary CPU: 00000000 Node Name: SLAVE
** Supported CPU count: 00000001
** Active CPUs: 00000000.00000001
** Current Process: NETACP
** Current PSB ID: 00000001
** Image Name: DSA0:[SYS0.SYSCOMMON.][SYSEXE]NETACP.EXE;1
*** keyboard not plugged in...
** Dumping error log buffers to HBVS unit 0
**** Unable to dump error log buffers to remaining shadow set members
** Error log buffers not dumped to HBVS unit 100
> (since the file system is different -- most systems used the one first done in DOS-11).
That don't make sense. You only write a device driver for the TU56. File system issues are handled at another level. With VMS, you use EXCHANGE if you want to access something with DOS-11 format.
The same is true in RSX as well, except there you use FLX. But it worked perfectly fine to create an ODS-1 formatted TU56 tape. Although it wasn't the fastest disk... :-)
Also, as I recall, he added some things that were previously done only on the PDP-10:
"overlapped seek" (set the tape moving, read a block number, calculate the time to get
to the right block, then select the other drive to do some I/O) and the "flap" operation
(unmounts the tape by doing a reverse read and deselect, allowing the tape to be wound
all the way onto the reel and off the other spindle).
I have a multiuser OS for the PDP-8 which do the same thing. Works pretty ok. Well, almost the same thing anyway. It just does it for seeks on the tape, but not allowing concurrent operations on another tape. But you don't want to have a polling driver do a seek on a multiuser OS, and one of the interfaces for the DECtape on a PDP-8 was so stupid and simple that you could only do polling work.
I never actually saw it in action but the above is what I recall being told.
I wonder what Andy Goldstein is doing now? I have no doubt that he probably did those things anyway. He was also responsible for TECO being included with VMS, including porting it to native code for VAX (and I believe Alpha), as well as creating a callable version of TECO in VMS.
Lovely attitude. :-)
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
I never actually saw it in action but the above is what I recall being told.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
I never actually saw it in action but the above is what I recall being told.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of hvlems at zonnet.nl
Sent: Tuesday, August 23, 2011 2:00 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Can we hook this up to a VAX or something?
Interesting, that a TU56 was supported by VMS. How did that become possible? Is it because the driver for the TU58 also happened to work for the TU56, possibly assisted by some SYSGEN magic to configure UB vector and addresses?
------Origineel bericht------
Van: Paul_Koning at Dell.com
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: RE: [HECnet] Can we hook this up to a VAX or something?
Verzonden: 23 augustus 2011 19:48
I can't remember whether the RK05 was supported by VMS?
No, not AFAIK but the RL02 (either on an RL11 or the RB730) was.
But did it work? There were some strange old devices that worked on VMS even though not "supported" -- the TU56 (real DECtape) comes to mind.
paul
Verzonden vanaf mijn draadloze BlackBerry(r)-toestel
