Gregg Levine <gregg.drwho8 at gmail.com> writes:
>Hello!
>Magic word is "Gack!". Now I place you. I asked Dave what was with the
>name on the Vax, and he confirmed it was yours. I wondered why it was
>named after a second stage booster back from our years of sending
>stuff into space, Think of the term, "Atlas-Agena" and you'll get my
>reasoning.
It was named after a star in Beta Centauri. ;)
>Dave was that the one who finally brought up the terminal server?
>Oddly enough I have here three Model 90 terminal servers, but they are
>the L Plus ones.
When I arrived, there was a sparsely populated DEChub90 with a DECrepeater,
IIRC (maybe it was a DECswitch) and a DECserver-90TL. Steve was working on
getting the server image onto on of Dave's systems to MOP load it. Because
I live close, I offered to run home and bring a couple of DECserver-90Ms as
they can boot off of their own flash. I also brought some tools as my case
with my VLC. Tools as I offered to make people MMJ cables once again and I
threw in the VLC just in case. The in case proved to be a smart move. My
VLC had VMS V7.3, DECnet/V and TCPIP Services, as well as a stockpile many
MOP load images. Plugged in the VLC, booted it, defined the DECserver-90TL
by its ethernet address, and voila!
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Gregg Levine <gregg.drwho8 at gmail.com> writes:
>Hello!
>Holy Mackerel. Steve, I was there, and saw that island of Dec in a
>world of stuff. (Well one of many) . Which of the two were you again?
>I met the fellow who goes by the handle of Vaxman, but I'm guessing
>that you were the other fellow I spoke to who confirmed that
>everything was working after a fashion.
I don't remember. My mind's a blank.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hey,
I picked up this thing nobody could particularly identify...
BF05 V1.0D Copyright 08-Dec-82
BF05>E=Editor,S=Set-up,P=Pass-thru,T=Test,H=Help
BF05>
Any ideas what the hell it IS or what the editor commands are?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Try sampling from this page (follow links for more goodies):
http://www.quadibloc.com/comp/pan08.htm
/P
On Mon, Apr 20, 2015 at 11:52:45AM +0100, Mark Wickens wrote:
> I know this question has been asked many times in the past and I'm
> probably being lazy for not looking hard enough but does anyone have
> a quick link to the colours of DEC that I can use on a web page -
> rather than resort to a scanning effort.
>
> I'm thinking here about the colour of the orange/grey binders, the
> blue and orange used in the PDP and VAX era paint schemes.
>
> Thank you
>
> Mark.
>
> --
>
> DECtec mailing list
> http://dectec.info
>
> To unsubscribe from this list see page at: http://dectec.info/mailman/listinfo/dectec_dectec.info
I just scored a TSZ08 but it's differential SCSI. Amazingly, I found
a DWZZB-AA
SE to DE converter a few years ago, which I am hoping still works (I'll
find out soon). The issue is that this is the first time I played with DE
SCSI and have nothing else.
Question 1. Anyway on know what the DEC cable number was for a 68 pin
(male each end) SCSI cable? I think its BN31G-02 [i.e. this has the right
connects on the end]. Any one know if that is correct. I think I have
source for a couple of them. Also, I assume I need a differential SCSI
terminator [everything I have now is SE]. Any idea what the DEC # was for
the proper terminator.
What I believe I need to need to connect it is:
SCSI Single Ended (SE) HBA with 68 pin female: <--- 68 pin male
-------------- 68 pin male -> DWZZB-AA SE side with 68 pin female
TSZ08 Differential (DE) SIDE A with 68 pin female: <--- 68 pin male
-------------- 68 pin male -> DWZZB-AA A DE side with 68 pin female
TSZ08 Differential (DE) SIDE B with 68 pin female: Differential SCSI
Terminator 68 pin male
Johnny Billquist <bqt at softjar.se> writes:
>On 2015-04-15 19:47, Brian Schenkenberger, VAXman- wrote:
>> Johnny Billquist <bqt at softjar.se> writes:
>>
>>> On 2015-04-15 19:17, Brian Schenkenberger, VAXman- wrote:
>>>> Dave McGuire <mcguire at neurotica.com> writes:
>>>>
>>>>> On 04/15/2015 11:58 AM, Johnny Billquist wrote:
>>>>>> Seems to me you are just hitting the problems with the Linux DECnet
>>>>>> code, since that has pretty much only been tested against VMS, and
>>>>>> probably are breaking the protocol all over the place...
>>>>>> I know that transferring stream files from VMS to RSX works fine, with
>>>>>> RSX converting them to variable length records.
>>>>>> Like I said before, I have had essentially no luck in using Linux DECnet
>>>>>> against RSX systems. Not only file transfers, but things like PHONE also
>>>>>> do not work.
>>>>>
>>>>> Yes, it looks like that's what's going on. That sucks. I would love
>>>>> to pick up the maintenance of that code, but I don't know DECnet
>>>>> internals at all and would be starting from scratch there. I know I
>>>>> could handle the code, but the required time to come up to speed is an
>>>>> obstacle.
>>>>
>>>> I have, printed, all DECnet (circa Pase IV) specs here; however, they are
>>>> on-line if you Google them.
>>>
>>> Speaking of that, I became curious about a couple of details of the DAP
>>> protocol when I was fixing the RSX implementation a while ago.
>>> There are a couple of fields in that protocol that identifies the remote
>>> operating system and remote file system, and obviously there are a whole
>>> set of values these can have. I'd like to update those tables, but do
>>> anyone have an fairly recent, authoritative source?
>>> Also, RSX implements DAP V7.1, while VMS has DAP V7.2. Does anyone know
>>> what the differences are?
>>
>>
>> The DAP spec. V5.6.0 says:
>>
>> 0 - Illegal
>> 1 - RT-11
>> 2 - RSTS/E
>> 3 - RSX-11S
>> 4 - RSX-11M
>> 5 - RSX-11D
>> 6 - IAS
>> 7 - VAX/VMS
>> 8 - TOPS-20
>> 9 - TOPS-10
>> 10- RTS-8
>> 11- OS-8
>> 12- RSX-11M+
>> 13- COPOS/11 (TOPS-20 Front End)
>>
>> I checked in LIB.REQ on VMS V8.4 and there are only symbolic definitions for
>> the first 5:
>>
>> literal NMA$C_SYS_RST = 1; ! Rsts
>> literal NMA$C_SYS_RSX = 2; ! Rsx family
>> literal NMA$C_SYS_TOP = 3; ! Tops-20
>> literal NMA$C_SYS_VMS = 4; ! Vms
>> literal NMA$C_SYS_RT = 5; ! RT-11
>
>That was even less than what RSX knows...
>In NFT or RSX, I can see the following:
>1 - RT-11
>2 - RSTS/E
>3 - RSX-11S
>4 - RSX-11M
>5 - RSX-11D
>6 - IAS
>7 - VAX/VMS
>8 - TOPS-20
>9 - TOPS-10
>10 - RTS-8
>11 - OS-8
>12 - RSX-11M+
>13 - COPOS/11 (TOPS-20 frontend)
>14 - P/OS
>15 - VAXELAN
>16 - CP/M
>17 - MS-DOS
>18 - Ultrix-32
>19 - Ultrix-11
>20 - DTF/MVS
>
>And I discovered that Windows NT seems to have the number 25, but I have
>no idea about 21-24.
>
>And for filesystems, RSX knows:
>1 - RMS-11
>2 - RMS-20
>3 - RMS-32
>4 - FCS-11
>5 - RT-11
>6 - No file system
>7 - TOPS-20
>8 - TOPS-10
>9 - OS-8
>10 - RMS-32S
>11 - CP/M
>12 - MS-DOS
>13 - Ultrix-32
>14 - Ultrix-11
>15 - DTF/MVS
I've had my head deep in the RMS internals and I should have recalled this.
The XAB (eXtrended Attributes Block) defines:
literal XAB$K_RT11 = 1;
literal XAB$K_RSTS = 2;
literal XAB$K_RSX11S = 3;
literal XAB$K_RSX11M = 4;
literal XAB$K_RSX11D = 5;
literal XAB$K_IAS = 6;
literal XAB$K_VAXVMS = 7;
literal XAB$K_TOPS20 = 8;
literal XAB$K_TOPS10 = 9;
literal XAB$K_RTS8 = 10;
literal XAB$K_OS8 = 11;
literal XAB$K_RSX11MP = 12;
literal XAB$K_COPOS11 = 13;
literal XAB$K_P_OS = 14;
literal XAB$K_VAXELN = 15;
literal XAB$K_CPM = 16;
literal XAB$K_MS_DOS = 17;
literal XAB$K_ULTRIX_32 = 18;
literal XAB$K_ULTRIX_11 = 19;
literal XAB$K_RMS11 = 1;
literal XAB$K_RMS20 = 2;
literal XAB$K_RMS32 = 3;
literal XAB$K_FCS11 = 4;
literal XAB$K_RT11FS = 5;
literal XAB$K_NO_FS = 6;
literal XAB$K_TOPS20FS = 7;
literal XAB$K_TOPS10FS = 8;
literal XAB$K_OS8FS = 9;
literal XAB$K_RMS32S = 10;
literal XAB$K_CPMFS = 11;
literal XAB$K_MS_DOSFS = 12;
literal XAB$K_ULTRIX32_FS = 13;
literal XAB$K_ULTRIX11_FS = 14;
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Dave McGuire <mcguire at neurotica.com> writes:
>On 04/15/2015 11:58 AM, Johnny Billquist wrote:
>> Seems to me you are just hitting the problems with the Linux DECnet
>> code, since that has pretty much only been tested against VMS, and
>> probably are breaking the protocol all over the place...
>> I know that transferring stream files from VMS to RSX works fine, with
>> RSX converting them to variable length records.
>> Like I said before, I have had essentially no luck in using Linux DECnet
>> against RSX systems. Not only file transfers, but things like PHONE also
>> do not work.
>
> Yes, it looks like that's what's going on. That sucks. I would love
>to pick up the maintenance of that code, but I don't know DECnet
>internals at all and would be starting from scratch there. I know I
>could handle the code, but the required time to come up to speed is an
>obstacle.
I have, printed, all DECnet (circa Pase IV) specs here; however, they are
on-line if you Google them.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Johnny Billquist <bqt at softjar.se> writes:
>On 2015-04-15 19:17, Brian Schenkenberger, VAXman- wrote:
>> Dave McGuire <mcguire at neurotica.com> writes:
>>
>>> On 04/15/2015 11:58 AM, Johnny Billquist wrote:
>>>> Seems to me you are just hitting the problems with the Linux DECnet
>>>> code, since that has pretty much only been tested against VMS, and
>>>> probably are breaking the protocol all over the place...
>>>> I know that transferring stream files from VMS to RSX works fine, with
>>>> RSX converting them to variable length records.
>>>> Like I said before, I have had essentially no luck in using Linux DECnet
>>>> against RSX systems. Not only file transfers, but things like PHONE also
>>>> do not work.
>>>
>>> Yes, it looks like that's what's going on. That sucks. I would love
>>> to pick up the maintenance of that code, but I don't know DECnet
>>> internals at all and would be starting from scratch there. I know I
>>> could handle the code, but the required time to come up to speed is an
>>> obstacle.
>>
>> I have, printed, all DECnet (circa Pase IV) specs here; however, they are
>> on-line if you Google them.
>
>Speaking of that, I became curious about a couple of details of the DAP
>protocol when I was fixing the RSX implementation a while ago.
>There are a couple of fields in that protocol that identifies the remote
>operating system and remote file system, and obviously there are a whole
>set of values these can have. I'd like to update those tables, but do
>anyone have an fairly recent, authoritative source?
>Also, RSX implements DAP V7.1, while VMS has DAP V7.2. Does anyone know
>what the differences are?
The DAP spec. V5.6.0 says:
0 - Illegal
1 - RT-11
2 - RSTS/E
3 - RSX-11S
4 - RSX-11M
5 - RSX-11D
6 - IAS
7 - VAX/VMS
8 - TOPS-20
9 - TOPS-10
10- RTS-8
11- OS-8
12- RSX-11M+
13- COPOS/11 (TOPS-20 Front End)
I checked in LIB.REQ on VMS V8.4 and there are only symbolic definitions for
the first 5:
literal NMA$C_SYS_RST = 1; ! Rsts
literal NMA$C_SYS_RSX = 2; ! Rsx family
literal NMA$C_SYS_TOP = 3; ! Tops-20
literal NMA$C_SYS_VMS = 4; ! Vms
literal NMA$C_SYS_RT = 5; ! RT-11
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Hey folks. I'm moving some text files to an RSX system via DECnet
under Linux. The files on the RSX system are not readable; I get
"illegal record size" when trying to type them.
Has anyone hit this? I assume there's a simple solution..
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
