"sokolov@alpha.CES.CWRU.Edu" "Michael Sokolov" wrote:
>
>   In my previous posting I have said that VAXstations appear to be closer
>to VAXservers than to MicroVAXen and asked why is it so. Instead of an
>answer to the latter question, I have got a reminder that "when going from
>one "family" to another, things may not remain consistent". Believe me, I
>have learned that quite well by now. I guess that I haven't stated my
>question very clearly, so I'll give it another try. First look at KA650-
>based Q-bus systems. KA650 has two versions that differ only in one bit in
>the EPROM. One is used in MicroVAXen and one was used in VAXservers. _For
>some reason_ KA650-based VAXstations use the version used by VAXservers and
>NOT the one used by MicroVAXen, as if VAXstations are closer to VAXservers
>than to MicroVAXen. The "_for some reason_" part above is what I'm trying
>to get an answer to.

The purpose of "server" systems was to provide cheap compute power while denying 
interactive access. You could buy, for example, a VAX 6000 Model 210 and a 
licence for OpenVMS for various numbers of interactive users, more users 
required more money. But if you wanted to use a VAX 6000 Model 210 as a boot 
server for a bunch of workstations in a cluster, you didn't really want more 
than one interactive login (for system management purposes). So you could get 
the much cheaper VAXserver 6210 (I forget the exact name). This was, as you 
might guess, based on the same CPU board (KA62A) as the VAX 6000-210, but with a 
single bit different in the EPROM so the OS could easily tell it was a VAXserver 
and not a full blown VAX; this made it easy to prevent you cheating on the 
licence.

Originally DEC only licensed workstations for one user (plus one more for system 
management work only, IIRC). So using a KA650-B in a VAXstation 3200/3500 made 
sense. Otherwise you could just buy the *cheaper* workstation and use it as a 
full blown departmental VAX: after all, if you ripped out the graphics cards 
there would be no way for the OS to know.

Now with the KA41/KA42 series much the same reasoning applies. A KA41-B 
(VAXserver) is cheaper than a KA41-A (MicroVAX) and the same applies to the 
KA41-E versus KA41-D and since the distinction is done in hardware it is harder 
to fool than if it had been done in software. A K42-B is always a workstation so 
there is no need for any variant. When you boot a KA42-B as a non-wrokstation 
(i.e. with the S3 console switch up) the OS reports it as a VAXserver. (So there 
are two different VAXserver 3100 systems, and I don't know which was actaully 
shipped if you ordered a VAXserver 3100, I would guess a KA41-B but I don't 
know).

>One is used in MicroVAXen and one was used in VAXservers. Now "bookmark"
>the location of that bit in the KA41 EPROM and look at the same location in
>the _KA42_ EPROM. I'm sure that you'll find the value that on KA41
>signifies a VAXserver (that's why VMS considers a KA42 with a serial
>console to be a VAXserver 3100). The same question as for KA650: why? What
>is it that makes KA42-B be closer to KA41-E than to KA41-D? Please don't
>tell me that KA41-D and KA41-E differ only in one bit in the EPROM and that
>KA42 is quite different. Believe me, I have learned that by now. This

The location in EPROM is reported as the internal register XSID (extended SID). 
The meaning of the various portions of the XSID varies from platform to platform 
(much as most of the SID does) so the bit in KA41 that means VAXserver may or 
may not correspond to a similar bit in the KA42 or KA650 etc. So there is no 
easy way in software to look at the XSID and check a single bit regardless of 
platform and decide whether your are a server or not.

>   Correct me if I'm wrong, but I think that in the strictest sense the
>term "MicroVAX" means a VAX whose central processing unit is implemented in
>a single integrated circuit. Whenever one wants to refer to such a VAX

I'd agree that the term "MicroVAX" can be used to refer to a group of machines 
that includes MicroVAX and VAXstations. However, the single-chip definition 
doesn't really work: the CPU in a MicroVAX 3500/3600 and a VAX 6000 Model 210 is 
the same.

The VAX 4000-300 was going to be called a MicroVAX until someone in marketing 
decided it should be a VAX 9presumably because it might sell better).

The MicroVAX 3100-90 uses a KA50, the VAX 4000-100 uses a KA52. The boards are 
identical. With the appropriate command at the console (documented in the 
service manual somewhere) you can turn one into the other (magically conjuring 
up a DSSI interface is a little harder however :-)

>VAXservers seems to be their licensing status. As far as I understand, the
>ID bit in the EPROM is there only to inform the OS of this status. Since
>(also as far as I understand) VAXstations don't have the same licensing
>status as VAXservers, I thought that they shouldn't have the ID bit setting
>that's supposed to uniquely identify the VAXservers. However, both 3100s
>and 3500s clearly indicate that they do, and therefore something is wrong
>in my understanding. _This_ is what I'm asking you to clarify.

I see the problem ... you're trying to understand marketing! Stop now before you 
suffere irreversible damage :-) There are (at least) two parts to identifying a 
VAX from a software point of view, the SID and the XSID. The SID was architected 
such that the most significant byte tells you the family (VAX-1178x, VAX-11/750, 
VAX 86x0 etc.) and the rest of the bits are defined by whoever built the family. 
So the difference between a VAX-11/780 and a VAX-11/785 is a single bit and the 
difference between a VAX 8600 and a VAX 8650 is also a single bit, but not 
necessarily the same bit! When the MicroVAXes came along things became harder. 
The SID is an architected internal register and has to exist on all 
implementations. With potentially many systems based on the same chip (e.g. 
CVAX, NVAX etc.) there were going to be lots of systems with the same SID (since 
the SID is usually handled on chip). So all CVAX systems have an SID of 
0Axxxxxx (hex), all Rigel systems have an SID of 0Bxxxxxx (hex) etc. The XSID 
was invented as a mechanism to distinguish the various systems. For each family, 
the XSID values are assigned to allow each system to be uniquely identified 
(well, almost always uniquely). And these XSID values are stored in an EPROM 
somewhere so that different systems based on the same chipset can have different 
XSIDs.

>   I wrote:
>> What IS the difference between "a workstation" and "a microvax"? People
>> were suggesting to me that it's licensing.
>   You responded:
>> Correct (or you could call it marketing instead.
>              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   But the licensing of DEC proprietary OSes is involved here too. As
>Gunnar has pointed out, the different versions require different VMS
>licenses, and VMS does enforce this.

This is true - VMS does this because the marketing people decided it was a good 
idea. Selling a MicroVAX II for $60K and a VAXstation II for $30K (OK, I'm 
making up the numbers) would tempt people to look at the difference; I presume 
that marketing needed a solution that would allow selling single-user 
workstations relatively cheaply without eroding the price-premium of the 
non-workstations.

>   As far as I can understand from Gunnar's posting, the VAXstation VMS
>license is higher than the VAXserver one, and the MicroVAX one is even
>higher (the highest). If I understand it correctly, a VAXserver node is
>intended to serve other nodes and not be logged into directly. Therefore,
>it allows at most one user to log in directly, which is necessary for
>maintenance. If this is correct, it's understandable why the VAXserver
>license is the lowest. Now imagine a VAX model that has all three versions,

All correct, AFAIK. 

>   The 2000, on the other hand, doesn't have a VAXserver version.
>Therefore, a converted VAXstation 2000 has to be a MicroVAX 2000, which
>means that the conversion raises the license class. If the license class
>decision were made only on the basis of the console selection, attaching a
>BCC08 cable to the DB9 connector (which, I assume, is what all NetBSD users
>do on VS2000s) would increase the license class of the machine. No good for
>DEC. Therefore, they have made it a little more difficult by introducing an
>obscure jumper on the system board just for this purpose. Now if you want
>to increase your license class (perhaps even without changing the console),
>you first have to find out about this jumper, and then you have to
>disassemble the system unit all the way down to the system board to change
>it. This sounds very plausible, and I would like to know if it's actually
>correct. (BTW, I have an idea as to why Antonio seems to try to avoid
>answering this question. Probably as a DEC employee he is not allowed to
>talk about issues that sound like cheating on VMS licensing.) I also have

I'm not trying to avoid the question, I just didn't realise you were trying to 
understand how the marketing people think ... and I'm not claiming to have the 
answer either ... I just treat it as a black box and try to guess how it works 
based on its outputs :-)

As for cheating on the licence, I suspect that most organisations would not 
consider doing it. The penalties when caught are usually too great to make it 
worthwhile. Whether the decision makers within DEC agree with that or not, I do 
not know. 

The MicroVAX 2000/VAXstation 2000 jumper is not that well hidden: it is clearly 
documented in the relevant technical manual which was available to customers. I 
wasn't inside DEC at the time so I cannot say for certain, but I presume that 
the goal was to produce two systems (a MicroVAX and a Workstation) as cheaply as 
possible so having one system do both jobs seems to be a good idea.

Don't forget that the MicroVAX 2000 was the first experiment along this 
particular road. Perhaps no-one had started to worry about customers finding 
creative ways around licencing restrictions. It would certainly have been easy 
enough to produce a VAXserver 2000 with a changed bit in EPROM for the OS to 
look at.

>   You wrote:
>> [...] in fact in a BA213 chassis has no DB9 it has
>> MMJ instead and yet the behaviour is the same as in BA23 or BA123.
>   In this case there is no external DB9, but there IS the internal
>connector on the CPU board itself that was simply connected to the DB9 in
>BA23/BA123. In BA213 it's connected to the small PCB on the back of the CPU
>cover, and that thing may short pins 8 and 9.

Yes pins 8 and 9 may be internally shorted (I have no idea) but whether they are 
shorted or not does not depend on whether you have a VCB02 installed or not. So 
if you take a MicroVAX II which writes on the serial console line when booting 
and add a VCB02 and the appropriate monitor your MicroVAX II is now a VAXstation 
II and will write to the monitor while booting: pins 8 & 9 are as they were with 
the MicroVAX.


>> As far as a hypothetical KA410 goes, it could have been designed without
>> video circuitry. I don't know how the hardware is arranged but if I
>> remember (and if noone else posts it first) I'll look in the tech manual
>> tonight.
>   Please do so. Actually, KA410 without the base mono video may not be so

OK - I'll check tonight (and this time I probably will ...)

>> I suspect that the GPX and SPX addon boards require the base mono video
>> circuitry which the KA42/KA43 have.
>   I strongly doubt this. In Jim Agnew's MicroVAX FAQ there is an article
>about a guy who used both video subsystems simultaneously by connecting two
>monitors with a special home-made cable. He had two monitors connected to

VMS (or rather DECwindows) supports two monitors, I used a VAXstation II like 
this a long time ago. It was quite weird moving a mouse off one edge of the 
screen and having it appear on another screen.

>> By the way, do you remember that in the SHOW DEV output that Thordur has
>> once posted the host adapter's SCSI ID was 7 and not 6 on both SCSI
>> buses? 7 is the standard in SCSI in general, but both KA42 (VS3100) and
>> KN01 (DS2100/3100) use 6 (at least by default, I don't know if it's
>> changeable). Is this yet another difference between KA41 and KA42?
>   Do you have any idea as what's going on here? And what is the host
>adapter's SCSI ID determined by in the first place? Is it the way the
>circuits are laid out on the board (some pins on the 5380 tied high or low)
>or does the system ROM give the 5380 a command during initialization to set
>this ID?

I believe that the host adapters SCSI ID is settable via the console. I think 
that most systems ship as ID 6 (at least mine in the lab are set to 6).

>   You wrote:
>> VAXstation 4000 boxes are different (at least the VLC and VAXstation
>> 4000-60 are, I haven't seen a VAXstation 4000-90).
>   Then how can the same Nemonix board swap into both MV3100 M30+ and
>VS4000? Maybe the boxes are different but compatible, sort of like BA23 vs.
>BA123?

The boxes are definitely different, but it would be possible to design a board 
to fit both (space available is roughly the same, mounting holes/slots are 
differently positioned).

>> And I'm still curious about the KA630 and KA650 console thing.
>   still stands. You still haven't explained why all MicroVAX IIs that I
>have seen have their consoles connected with BCC08s, the cables that short
>pins 8 and 9, and I believe that these are the official MicroVAX II console
>cables.

I don't know whether the console *has* to have 8 & 9 shorted. All I'm saying is 
that pins 8 & 9 have nothing to do with deciding whether you have a MicroVAX II 
or VAXstation II: the console decides that based on whether it finds a graphics 
card.

Antonio

Antonio Carlini                            Mail: carlini@marvin.enet.dec.com
DECnet-Plus for OpenVMS Engineering
Digital Equipment Corporation              Worton Grange, Reading, England