Talk:VAX 7000 and VAX 10000

The descriptions of DEC Products are very helpful and give insight.

I wonder, though, how much can be said about a company-policy without expressing point of view, and, conversely, how much information can be left out without impairing the value of the article.

To explain: I wonder wether DEC corporation really had informed knowledgeable management which "intended swapping the CPU module(s)":

Digital intended customers of the VAX 7000/10000 to eventually upgrade to the Alpha-based configuration (DEC 7000/10000 AXP) by simply swapping the VAX-based CPU module(s) for those based on the Alpha.

It is probably a topic beyond interest for most Wikipedians except if we accept expressions (or explanations) like "version-hell".

I have thought of a few other descriptive categories for computer system failures, but I am definitely not an expert in English computer language:

• Normal or expectable inconsistencies
• Compiler dialects
• Undefined behaviour

I mention these examples because I came to think of them in relation to the "intended CPU swapping". --d-axel (talk) 00:25, 3 February 2009 (UTC)

Did DEC intend customers of the VAX 7000 to upgrade to the DEC 7000 AXP and was this widely known? The answer is yes. This is supported by multiple sources - papers in the Digital Technical Journal, product documentation, DEC marketing material and the news: [1].

Regarding software issues as a result of upgrading from VAX to Alpha, there were two "solutions". The GEM compiler supported multiple programming languages, operating systems and hardware platforms and the VEST binary translator translated OpenVMS VAX binary images to OpenVMS AXP (Alpha) binary images. These are described in two papers, "The GEM Optimizing Compiler System" and "Binary Translation" in the Digital Technical Journal, Volume 4, Number 4.

Perhaps the article should elaborate further on the VAX to Alpha transition? Rilak (talk) 05:37, 4 February 2009 (UTC)

Blacklisted Links Found on the Main Page

Cyberbot II has detected that page contains external links that have either been globally or locally blacklisted. Links tend to be blacklisted because they have a history of being spammed, or are highly innappropriate for Wikipedia. This, however, doesn't necessarily mean it's spam, or not a good link. If the link is a good link, you may wish to request whitelisting by going to the request page for whitelisting. If you feel the link being caught by the blacklist is a false positive, or no longer needed on the blacklist, you may request the regex be removed or altered at the blacklist request page. If the link is blacklisted globally and you feel the above applies you may request to whitelist it using the before mentioned request page, or request it's removal, or alteration, at the request page on meta. When requesting whitelisting, be sure to supply the link to be whitelisted and wrap the link in nowiki tags. The whitelisting process can take its time so once a request has been filled out, you may set the invisible parameter on the tag to true. Please be aware that the bot will replace removed tags, and will remove misplaced tags regularly.

Below is a list of links that were found on the main page:

• http://www.cbronline.com/news/dec_rushes_to_rescue_of_vax_users_with_four_new_models

  Triggered by \bcbronline\.com\b on the local blacklist

• http://www.cbronline.com/news/digital_equipment_corp_launches_new_vms_release_as_openvms_unleashes_13_prealpha_vaxes

  Triggered by \bcbronline\.com\b on the local blacklist

If you would like me to provide more information on the talk page, contact User:Cyberpower678 and ask him to program me with more info.

From your friendly hard working bot.—cyberbot II ^Notify_Online 19:36, 8 December 2013 (UTC)

 Resolved This issue has been resolved, and I have therefore removed the tag, if not already done. No further action is necessary.—cyberbot II ^Notify_Online 00:28, 4 March 2014 (UTC)

Max memory incorrect

The page states that the maximum memory of these systems were 3.5 Gig, and this was because of an architecture limitation, as the VAX only have 32 bit addressing. This is incorrect. The virtual address space of the VAX is 32 bits. The physical address space depends on the implementation, and there have been many implementations of the VAX. The NVAX CPU, which were used in the 7000/10000 models can actually use 34 bits for the physical address. Although I do not know if the other subsystems of the 7000/10000 would allow 34 bit physical addresses. But it seems likely, as the Alpha used the same parts. For the 34-bit physical addressing of the NVAX, look at the VAX Archtecture Reference Manual, which is available online from bitsavers, for example. /bqt@update.uu.se 83.209.192.100 (talk) 14:48, 10 August 2015 (UTC)

I was just wondering about this, albeit 5½ years later. I just saw some documentation saying the 7000 supported up to 14 GB if only one CPU module was present, though the system was described as a "DEC 7000" so it was unclear whether it mean Vax, Alpha or both. But it's a reasonable question as DEC has plenty of history of hardware support for more memory than fits into the virtual address space (e.g. many of the PDP-11s).

3.5 GB seems oddly specific, though, especially as the reasoning given is "32 bits" which would be 4 GB. At first I'd just put it down to the tedious and endlessly confusing units war but it's not that, so what happened to the missing ½ GB? I'm assuming that part of the virtual address space is reserved for something or other but I have no idea and ideally it would be nice if the article might clarify both issues. Someone must know, but I am not that person!

--Vometia (talk) 15:34, 27 March 2021 (UTC)