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
Johnny Billquist <bqt at softjar.se> writes:
>On 2015-04-15 12:43, Brian Schenkenberger, VAXman- wrote:
>> Johnny Billquist <bqt at softjar.se> writes:
>>
>>> On 2015-04-15 06:58, Dave McGuire wrote:
>>>> On 04/14/2015 12:24 PM, Johnny Billquist wrote:
>>>>> On 2015-04-14 04:53, Dave McGuire wrote:
>>>>>>
>>>>>> 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..
>>>>>
>>>>> I have never had any luck at all transferring files from Linux to RSX.
>>>>>
>>>>> That said, what do you see if you do a DSP <file> under RSX?
>>>>
>>>> Just got back from road trip #1, only have a moment, will get back to
>>>> this in the morning. Here is the DSP output:
>>>>
>>>> $ dsp forth.mac
>>>>
>>>> DU:[10,1]FORTH.MAC;1
>>>> Size: 139./144. Created: 15-APR-2015 00:54
>>>> Owner: [001,010] Revised: 15-APR-2015 00:55
>>>> File ID: (5601,10,0) Expires: <none_specified>
>>>> File protection: System:RWED, Owner:RWED, Group:RWED, World:R
>>>> File organization: Sequential
>>>> File attributes: Allocation=144, Extend=0
>>>> Record format: Stream, maximum 255 bytes
>>>> Record attributes: Carriage return
>>>
>>> Cool. So the first, and most obvious, problem, is that the file is
>>> indeed in stream format. So no ordinary RSX tool will touch it with a
>>> five foot pole...
>>
>> Really? So, we surely HAVE come a long way baby with VMS RMS! Still, any
>> stream format is a ridiculously lame way to differentiate records IMHO.
>
>Yes. Good and bad - RMS is very much embedded within VMS.
>In RSX, RMS is a library that you link in to any programs that wants it.
>And it's not the only kid in town. You also have FCS, which is a
>simpler, smaller library. The file formats are compatible between FCS
>and RMS, as far as FCS capabilities cover them. FCS do not handle
>indexed files, nor stream files.
>
>And all RSX tools use FCS. (Long story, but FCS was around before RMS
>even existed, and RMS is an optional component, so it might not even
>exist on all RSX systems.)
>
>>> Had you been pulling it from Linux to RSX, and initiated to transfer
>>>from the RSX side, you can tell NFT exactly what format you want for the
>>> file on the local side, when the remote side is a stream format file.
>>> Not sure Linux can do that if you do the transfer from the Linux side.
>>>
>>> My next suggestion is to read up on RMSCNV, on how to convert the file.
>>> I can never remember exactly how to use it, so I have to read every time
>>> I want to, but it can convert the file to another format for you.
>>
>> I can't comment there either; however, if VMS CONVERT help is needed, I'm
>> available.
>
>I believe that VMS CONVERT is pretty much the same deal as RMSCNV, but I
>bet the exact syntax differs. :-)
>
>> And now, back to RMS CDC.
>
>I know "RMS", and I know "CDC", I just can't place them in the same
>sentence. I must be missing something...
I'd bet that if you Googled RMSCDC, you'd get your answer.
It's an effort I've been working on since mid-2009 to allow Attunity to get
access to changed data in RMS files by VMS applications using RMS (indexed
file data was the primary goal but no file format or record format has been
excluded). Some fun (not really, a real head-scratcher it's been) recently
when my RMS CDC code was stressed tested with a 32 processor Itanium blade.
FYI, what I provide is the VMS magic seen in this "graphic" in the gray box
on the left.
http://www.attunity.com/sites/default/files/content/Attunity%20Stream%20for…
There's nothing specific to Attunity's process/products. RMSCDC is simply
a log (a sequential record log of all RMS data changes. It's coordinated
in a cluster environment too, so that in the shared file environment of the
OepnVMS cluster, nothing is logged out of sync.
--
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 06:58, Dave McGuire wrote:
>> On 04/14/2015 12:24 PM, Johnny Billquist wrote:
>>> On 2015-04-14 04:53, Dave McGuire wrote:
>>>>
>>>> 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..
>>>
>>> I have never had any luck at all transferring files from Linux to RSX.
>>>
>>> That said, what do you see if you do a DSP <file> under RSX?
>>
>> Just got back from road trip #1, only have a moment, will get back to
>> this in the morning. Here is the DSP output:
>>
>> $ dsp forth.mac
>>
>> DU:[10,1]FORTH.MAC;1
>> Size: 139./144. Created: 15-APR-2015 00:54
>> Owner: [001,010] Revised: 15-APR-2015 00:55
>> File ID: (5601,10,0) Expires: <none_specified>
>> File protection: System:RWED, Owner:RWED, Group:RWED, World:R
>> File organization: Sequential
>> File attributes: Allocation=144, Extend=0
>> Record format: Stream, maximum 255 bytes
>> Record attributes: Carriage return
>
>Cool. So the first, and most obvious, problem, is that the file is
>indeed in stream format. So no ordinary RSX tool will touch it with a
>five foot pole...
Really? So, we surely HAVE come a long way baby with VMS RMS! Still, any
stream format is a ridiculously lame way to differentiate records IMHO.
>Had you been pulling it from Linux to RSX, and initiated to transfer
>from the RSX side, you can tell NFT exactly what format you want for the
>file on the local side, when the remote side is a stream format file.
>Not sure Linux can do that if you do the transfer from the Linux side.
>
>My next suggestion is to read up on RMSCNV, on how to convert the file.
>I can never remember exactly how to use it, so I have to read every time
>I want to, but it can convert the file to another format for you.
I can't comment there either; however, if VMS CONVERT help is needed, I'm
available.
And now, back to RMS CDC.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
Does anyone have the sources (I need the sources, not just binaries) for
either the PDP-11 Pascal or Modula-2 compilers? It's probably on some DECUS
tape somewhere, but I'm hoping someone can save me the trouble of searching.
BTW, I have the sources (and working binaries) for the VAX/VMS Modula-2
compiler if anybody wants it. The VAX version was adapted from the PDP-11
version, and I'd like to find the original if I can.
Thanks,
Bob
