Langbahn Team – Weltmeisterschaft

Talk:OpenVMS

Documentation colors

I seem to remember that the oldest binder color, before orange, was blue. - Denimadept (talk) 13:33, 30 July 2018 (UTC)[reply]

Don't know if that was the "oldest", but certainly the V3 doc set came in blue binders. V4 was orange (actually "Chinese red"). V5 was gray. Jeh (talk) 17:49, 30 July 2018 (UTC)[reply]
I seem to remember pre-VMS PDP-11 documentation coming in blue binders. Guy Harris (talk) 18:14, 30 July 2018 (UTC)[reply]

Source availability

The article currently describes VMS as a closed-source operating system. This seems inconstant with my experience. It might be more accurate to describe it as source-available software. The sources were readily available on microfiche, so open to inspection but not easy recompilation.

My experience was strictly based on VAX systems, but I always assumed that something similar applied to OpenVMS as well. Can anyone detail what has happened to source availability under the post-HP evolution of the software as it is being ported to x86? Burt Harris (talk) 19:44, 13 October 2018 (UTC)[reply]

The source kits are no longer available, will update the article accordingly. Vt320 (talk) 13:55, 2 November 2021 (UTC)[reply]

--Reciprocist (talk) 17:42, 17 April 2021 (UTC)[reply]

Maybe RSX-11 would be a more appropriate value for family? Vt320 (talk) 18:34, 17 April 2021 (UTC)[reply]

It also includes RSTS/E and DOS-11 and TSS/8 and TOPS-10 and ...; presumably the problem here's that the category is too broad, listing a bunch of OSes that don't, collectively, have anything in common other than "DEC offered them", not that it happens to include two Unixes from DEC.
And VMS 1) introduced, as far as I know, a lot of concepts and mechanisms not in RSX-11 and 2) was arguably a more significant and notable OS, so would it make sense to name the family against the earlier, smaller predecessor? Guy Harris (talk) 20:30, 17 April 2021 (UTC)[reply]
Probably not. Perhaps the solution here is to not list a "Family" category at all? The history section already makes the lineage clear. Vt320 (talk) 08:52, 19 April 2021 (UTC)[reply]
Sounds good to me. (And it should probably be dropped for other DEC OSes that only have "they came from DEC" in common with other members of the family.) Guy Harris (talk) 20:56, 19 April 2021 (UTC)[reply]
Done, applied the same change across all articles in the DEC OS category. Vt320 (talk) 22:29, 19 April 2021 (UTC)[reply]
I could maybe see a case for a TENEX family containing TENEX and TOPS-20, but that's about it. Guy Harris (talk) 23:15, 19 April 2021 (UTC)[reply]
Makes sense, done. Vt320 (talk) 09:15, 20 April 2021 (UTC)[reply]

What "VAX/VMS" means

The lede of this article needs to do a fuller job of explaining what "VAX/VMS" means, since VAX/VMS is a redirect to here. The lede explains the first meaning, which is that VAX/VMS was the official name of the operating system in the beginning. But in common practice at the time, "VAX/VMS" referred not just to the operating system, but to the computing platform that was the combination of the VAX hardware architecture and the VMS operating system. It was this combination that was very successful in the industry in the 1980s and when articles about some software say that it ran on VAX/VMS, it is this combination that they are linking to, not just the operating system. Wasted Time R (talk) 12:34, 7 November 2021 (UTC)[reply]

When OpenVMS was known as VAX/VMS, it only ran on VAX hardware. The articles you refer to could say "VAX systems running VAX/VMS" but the fact that it was a VAX system is implied from it being VAX/VMS. Perhaps the lede should make it more clear that the name change happened to indicate that the OS was no longer exclusive to the VAX? Vt320 (talk) 17:05, 7 November 2021 (UTC)[reply]
There are a few things here. First, no one would say "VAX systems running VAX/VMS"; people either said "VAX systems running VMS" or, most commonly, "VAX/VMS". To me, the lede should make clear that while VAX/VMS may have been the formal name of the OS, in common usage the phrase "VAX/VMS" often referred to the platform as a whole. Second, links to [[VAX/VMS]] should be left alone in articles rather than changed to [[OpenVMS|VAX/VMS]], per WP:NOTBROKEN. It's possible that someday someone will write an article about the combined VAX hardware/VMS operating system computing platform – akin say to the Wintel or IBM mainframe articles – and in that case, that article would be located at VAX/VMS. The former link would then point to the right thing while the latter link would not. But even if that doesn't happen, article links going through the VAX/VMS redirect causes no harm and is not something to be avoided. Third, the WP:WEIGHT of the lede and the article body is off. The lede doesn't mention that the 1980s were the period of greatest success for VAX/VMS. The History section spends 4 paragraphs on the VAX/VMS era but 16 paragraphs on various ports of VMS/OpenVMS to other architectures. The Alpha one is important but the Itanium and x86-64 ones much less so – by then DEC was gone and the popularity of VMS/OpenVMS was in steep decline. If I didn't know better – and many readers won't – this article would give me the wrong impression about what parts of VMS/OpenVMS history are important and which parts aren't. Wasted Time R (talk) 11:09, 8 November 2021 (UTC)[reply]
After reviewing guidelines on redirects, the changes made to some articles were made based on a misunderstanding on where redirects should be used. I'll go and revert them where appropriate.
I agree that the history is a bit lopsided section is lopsided. The current format where it groups by platform port makes it difficult to add relevant context in. This is something I may work on in future. Vt320 (talk) 19:50, 8 November 2021 (UTC
Thanks for doing the reversions. As for the weighting, I've looked at the sources for the history sections about the Itanium port and the x86-64 port, and those sources are substandard. Most of the Itanium sources are to DEC/HP publications or DEC/HP user groups, neither of which is the kind of strong third-party sourcing one looks for. And just about all of the x64-86 sources are to VSI, the outfit doing the port, and are thus are kind of self-promotional and supply no indication of importance. I think you would be justified in greatly reducing these sections. Wasted Time R (talk) 01:19, 9 November 2021 (UTC)[reply]

GA Review

This review is transcluded from Talk:OpenVMS/GA1. The edit link for this section can be used to add comments to the review.

Reviewer: Shushugah (talk · contribs) 17:28, 9 January 2022 (UTC)[reply]


Beginning review

Hello I am looking forward to reviewing your article today and working with you. I typically give a week for any corrections to be made and make my final assessment then. Given this is a highly technical topic, I am willing to give longer if need be, as long as active improvements are being made. I will provide a progress bar and more descriptive feedback to help you make improvements. Kind regards ~ 🦝 Shushugah (he/him • talk) 17:28, 9 January 2022 (UTC)[reply]

GA review (see here for what the criteria are, and here for what they are not)
  1. It is reasonably well written.
    a (prose, spelling, and grammar): b (MoS for lead, layout, word choice, fiction, and lists):
    OpenVMS#Open source applications is not a feature and likely better moved underneath OpenVMS#Hobbyist programs or some shared parent section OpenVMS#Uses (similar to Linux#Uses)
  2. It is factually accurate and verifiable.
    a (reference section): b (citations to reliable sources): c (OR): d (copyvio and plagiarism):
    Given the technical nature of this, more primary sources are expected, however a number of sections are still missing references. It could be they're verified in follow up paragraphs, but it's not obvious to me, and this is a problem if there are any refactors (no pun intended).
  3. It is broad in its coverage.
    a (major aspects): b (focused):
    Some sections are excessively detailed and detract from overall article. For example OpenVMS#Executive structure is literally discussing code structure and could be completely removed in my opinion. The summary style of its parent section at OpenVMS#Executive and Kernel is the right balance of abstraction/informative.
  4. It follows the neutral point of view policy.
    Fair representation without bias:
    General yes, one exception was this phrase provides feature-rich facilities feature rich is promotional language, and not verified anyhow.
  5. It is stable.
    No edit wars, etc.:
  6. It is illustrated by images and other media, where possible and appropriate.
    a (images are tagged and non-free content have fair use rationales): b (appropriate use with suitable captions):
    Cheshire Cat in one of the image captions could be wikilinked 😸
  7. Overall:
    Pass/Fail:

Additional points

  • Some of these products remain under active development, such as TCPware and MultiNet. (as of when?)
  • CLI in this article refers to both OpenVMS#Command_line_interfaces and OpenVMS#Command Language Interpreter which are duplicating each other.
  • Despite having three sections related to Porting, no wikilink/explanation is provided.Porting would be good enough.
  • OpenVMS#Major release timeline is missing an explanation of what major versions mean. Alpha releases should be removed for being excessive/confusing, given that minor/patch (if it's called that) versions are not consistently included.
  • Digital Equipment Corporation is mentioned once, and then some entity called Digital is mentioned. The connection between the two should be explicit. e.g. Digital Equipment Corporation (also known as Digital)...

This is one of the most technical articles I've reviewed and I think it's in a much better state than a few months ago. There are some small improvements to make, but otherwise it's on a good path to becoming a Good Article soon. Despite being a programmer myself, there were many concepts/details that went over my head, due to either lack of explanations/linking and or excessively detailed information that is unlikely to be of an interest to a larger group. One essays I'd highly recommend reading is Wikipedia:Make technical articles understandable. Thanks for the lovely article and happy editing! ~ 🦝 Shushugah (he/him • talk) 20:52, 9 January 2022 (UTC)[reply]

Thank you for your review and feedback. I will be addressing these articles in the coming days. Will provide updates on which items have been addressed. Vt320 (talk) 19:30, 13 January 2022 (UTC)[reply]
Still working on this. I think I have covered most of the specific points except for ensuring that there is appropriate reference coverage, and fixing up the "Major release" table. Both will require some extra time. Vt320 (talk) 14:18, 15 January 2022 (UTC)[reply]
Had some more time to work on this, fixed up the version table. Will look for areas which are missing references in the coming days. Vt320 (talk) 21:58, 6 February 2022 (UTC)[reply]

Second opinion requested in the hopes of finding reviewer to take over

Regrettably, Shushugah has been inactive of late and unresponsive to queries. The nomination status has been changed to "2nd opinion" in the hopes of finding a new reviewer to take over the review. Thank you to whoever steps up. BlueMoonset (talk) 04:01, 24 March 2022 (UTC)[reply]

Hey, I'll take it on. I'm also a programmer. I'll probably take a few days to complete my review. Ruthgrace (talk) 04:36, 25 March 2022 (UTC)[reply]

Second opinion review

I recommend waiting to make changes until my review is complete. Ruthgrace (talk) 18:04, 25 March 2022 (UTC)[reply]

Content feedback

Starting with the lead

  • "The notability of the article's subject is usually established in the first few sentences." Wikipedia:Manual_of_Style/Lead_section, so I recommend moving the following two sentences (which I think best establish the notability by describing the prevalence of OpenVMS) from the end of the lead to directly after the first sentence of the lead.
    Customers using OpenVMS include banks and financial services, hospitals and healthcare, telecommunications operators, network information services, and industrial manufacturers.[24][25] During the 1990s and 2000s, there were approximately half a million VMS systems in operation worldwide.[26][27][28]
    Addressed

Moving on to the History section

  • This is gramatically incorrect:
    MicroVMS also differed by various simplifications to the setup and management of the operating system, and came with a condensed documentation set.
"differed by" needs to be preceeded by the things that are being compared, but only a single thing is mentioned. You can fix it by saying "MicroVMS and larger VAX systems", or you can simplify the whole sentence like so:
MicroVMS also incorporated simplifications to the operating system set up, management, and documentation set.
Addressed
  • It looks like MicroVMS was a standalone thing for a bit, but then was merged back together with the rest of the operating system stuff. In accordance with summary style, I would encourage you to identify what the main significance of MicroVMS is in the history of OpenVMS. You can remove that paragraph if you don't think MicroVMS is that significant, or follow summary style and talk about MicroVMS in the context of its significance. For example, maybe the customizability of MicroVMS was so popular that these features were incorporated into VAX/VMS.
    Addressed this by providing a list of the various distributions of VMS which were created.
  • This sentence mentions the port to Alpha before the port to Alpha is explained in the article.
    DEC renamed VAX/VMS to OpenVMS as an indication for its support of "open systems" industry standards such as POSIX and Unix compatibility,[45] and to drop the VAX connection since the port to Alpha was underway.
Maybe instead you could say something like this to make it more understandable
DEC renamed VAX/VMS to OpenVMS as an indication for its support of "open systems" industry standards such as POSIX and Unix compatibility,[45] and to drop the VAX connection since a migration to a different architecture was underway.
Addressed

I finished reading the History section, and I'll continue on tomorrow. After the first pass for the writing, I'll do another pass to look at the citations.

P.S. my jaw is dropping at "VMS cluster uptimes of 17 years have been reported." That's a long time! Ruthgrace (talk) 05:14, 25 March 2022 (UTC)[reply]

I'm back for more! Starting with the Port to DEC Alpha section

  • Not necessary for Good Article, but I recommend renaming the section just "Port to Alpha" since it's hard for people to know what DEC stands for without searching, and it's referred to as "Alpha" more than "DEC Alpha" (100 vs 5 times) in the article.
Addressed
  • In the spirit of Wikipedia summary style, I'm not sure it's necessary to list the "changes needed to decouple VMS from the VAX architecture". In my view, the important point is that VMS was ported to a different architecture, and deatils on how it was done belongs in the references or footnotes.
It is relevant in the sense that the operating system was originally designed around a specific hardware platform (the VAX). It was mostly written in the assembly language of the VAX, and exposed a number of VAX-specific concepts in its APIs (particularly around interrupt handling). In that sense, I think it's worth calling it out
  • I'm not sure what the significance of the paragraph that starts with "The VMS port to Alpha resulted in the creation of two separate source code libraries" is. Isn't it self evident that if you switch to a different architecture, you'll have a codebase for the new architecture and a codebase for the old architecture? Unless there's some kind of historical significance (e.g. one of them was forked to become something else that is well-known today), I would remove this paragraph.
"Isn't it self evident that if you switch to a different architecture, you'll have a codebase for the new architecture and a codebase for the old architecture" - no, think of Linux for example. The same codebase can be used to build kernels for multiple architectures. I can condense the description of this, but it is relevant since the fact that it was a different codebase led to differences in the features between the VAX and Alpha releases of the operating system

Looking at Port to Intel Itanium!

  • I'm not sure we need all the detail following "This required certain architectural dependencies of OpenVMS to be replaced, or emulated in software. Some of the changes included...". I recommend summarizing it like so:
    This required certain architectural dependencies of OpenVMS to be replaced, or emulated in software. Some of the changes included replacing the System Reference Manual with the Extensible Firmware Interface for boot, porting Alpha PALcode to the Software Interrupt Services on the kernel, using new executable file extensions (Executable and Linking Format and DWARF formats) to support new calling conventions, adopting IEEE 754 as the default floating point format, and supporting the 50-bit physical addressing which allowed 1PiB of memory to be addressed.
    Addressed

Looking at Port to x86-64

  • Recommend summarizing the list after "As with the Alpha and Itanium ports, the x86-64 port made some changes to simplify porting and supporting OpenVMS on the new platform...". For example you could say
    As with the Alpha and Itanium ports, the x86-64 port made some changes to simplify porting and supporting OpenVMS on the new platform: adopting the open source LLVM compiler backend, more extensive use of UEFI and ACPI to make boot more hardware-agnostic, and using in-memory "pseudo registers" to accomodate the small number of general purpose registers for x86-64.
I think the bit about privilege levels isn't really a change since the levels remain the same before and after the port, so I left that one out of my summary
Addressed. However, I included the comment privilege levels, since on all the other platforms, the four privilege levels rely on hardware support, so on x86, they had to work around it in software

Onto the Architecture section!

  • I find this sentence confusing because some clauses describe the thing and then the privilege level, while others describe the privilege level and then the thing:
    The OpenVMS operating system has a layered architecture, consisting of a privileged Executive, a Command Language Interpreter which runs at an intermediate level of privilege, and utilities and run-time libraries (RTLs) which run in an unprivileged mode, but can potentially run at a higher level of privilege if authorized to do so.
Here's an exapmle of always saying the privilege level first. I also removed the detail about some things being able to run at a higher level of privilege if authorized, because I think that's part of a basic understanding of privileges, which this article already assumes the reader has.:
The OpenVMS operating system has a layered architecture, consisting of a privileged Executive, an intermediately-priviledged Command Language Interpreter, and unpriviledged utilities and run-time libraries (RTLs).
Addressed

I'll start with the Executive and Kernel section when I come back. Ruthgrace (talk) 18:04, 25 March 2022 (UTC)[reply]

Executive and Kernel

  • I think that generally these should be put in the context of operating systems. For example, currently this section starts with
    The OpenVMS Executive comprises the privileged code and data structures which reside in the system space. The Executive is further subdivided between the Kernel, which consists of the code which runs at the kernel access mode, and the less-privileged code outside of the Kernel which runs at the executive access mode.[88]
but putting it into context with other operating systems could look like this:
Like most modern operating systems, privileged code runs at the kernel access mode, and less-privileged code outside of the Kernel runs at the executive access mode. OpenVMS Executive is used to refer to both the kernel and executive access code and data structures.
This way people can differentiate between when you're describing something that's special about OpenVMS, and when you're describing general features of modern operating systems. And when you are describing general features of modern operating systems, it is probably better to reference articles like Kernel_(operating_system) or Shell_(computing) than to re-describe concepts here.

Extension mechanisms

  • Not required for Good Article, but I recommend being more specific with the "Extension mechanisms" section title. Maybe it could be renamed "Privilege, system service, and I/O device extension mechanisms" so that it makes more sense to the reader as the paragraphs skip between those topics.
Got rid of this section, condensed some content into the preceding section

File system

  • In the spirit of summary style, I think that the first paragraph in this section about RMS only needs its first sentence since the rest is not specific to OpenVMS necessarily, and the RMS article is already linked
Addressed
  • I also think that the second paragraph, which looks like this,
    The file systems supported by VMS are referred to as the Files-11 On-Disk Structures (ODS), which provide disk quotas, access control lists and file versioning.[97] The most significant structure levels are ODS-2, which is the original VMS file system, and ODS-5, which extends ODS-2 with support for Unicode file names, case sensitivity, hard links and symbolic links.[98] VMS is also capable of accessing files on ISO 9660 CD-ROMs and magnetic tape with ANSI tape labels.[99]
doesn't need the detail about the ODS structure levels:
The file systems supported by VMS are referred to as the Files-11 On-Disk Structures (ODS). VMS is also capable of accessing files on ISO 9660 CD-ROMs and magnetic tape with ANSI tape labels.
Addressed, but listed ODS-2 and ODS-5, since they are significant details - e.g. you are asked to select between them when installing the OS
  • I think the last paragraph,
    Alongside the OpenVMS Alpha V7.0 release in 1995, DEC released a log-structured file system named Spiralog which was intended as a potential successor to Files-11.[100] Spiralog shipped as an optional product, and was discontinued at the release of OpenVMS Alpha 7.2.[101] Spiralog's discontinuation was due to a variety of problems, including issues with handling full volumes.[102] The developers of Spiralog began work on a new file system in 1996, which was put on hold and later resumed by VSI in 2016 as the VMS Advanced File System (VAFS, not to be confused with DEC's AdvFS for Tru64).[103][104] VAFS no longer appears on recent roadmaps, and instead VSI have discussed porting the open source GFS2 file system to OpenVMS.[105][106] One of the major motivations for replacing the Files-11 structures is that they are limited to 2TiB volumes.[98]
can also be summarized better, since the important detail is that there exist motivations for replacing Files-11, but efforts haven't been fruitful:
Files-11 is limited to 2TiB volumes, and DEC attempted to replace it with a log-structured file system named Spiralog. However, Spiralog was discontinued due to a variety of problems, including issues with handling full volumes. Instead, there has been discussion of porting the open source GFS2 file system to OpenVMS.
Addressed

Command Language Interpreter

  • I think that this implementation detail of the CLI is not necessary, since it goes beyond the main point of the differences between OpenVMS and Unix CLIs.
    A CLI gets mapped into a process' private address space through execution of the LOGINOUT image, which can either be executed manually, or automatically by certain system services for process creation.[62]
    Due to the fact that the CLI is loaded into the same address space as user code, and that the CLI is responsible for invoking image activation and image rundown, the CLI is mapped into the process address space at supervisor access mode. This is in order to prevent accidental or malicious manipulation of the CLI's code and data structures by user mode code.[88][108]
    Addressed the first point by removing the sentence. I feel the second sentence is relevant in the context of comparing between Unix shells and DCL because DCL is run with higher privileges than a regular user program (unlike a Unix shell). Have added some extra wording to make this more obvious, let me know what you think

Features - Clustering

  • No comments. Very cool that OpenVMS supports clustering!

Networking

  • At the end of the first paragraph of this section, this sentence confused me a bit:
    Due to the fact that the official TCP/IP stack was not introduced until 1988, and the limited feature set of the early versions,[116] multiple third party TCP/IP stacks were created for VMS.[117]
    Addressed, removed
I couldn't work out the relevance of it to the rest of the paragraph. As far as I can tell, the third party TCP/IP stacks aren't described (presumably TCP/IP Services is the thing that DEC made), and it's unclear what the significance of the third party TCP/IP stacks are (are they commonly used?)
  • In the second paragraph, I think this implementation detail of PATHWORKS is not necessary for summary style
    PATHWORKS was based on LAN Manager and supported either DECnet or TCP/IP as a transport protocol.
    Addressed, removed whole sentence


Programming

  • No comments. good stuff.

Development Tools

  • Section looks good. I thought Caché was a pretty funny name for a database, until I looked up the etymology of the word "cache" and found out it literally comes from the French word caché. Cool!

User interfaces and Security sections look good.

Cross platform compatibility

  • accidentally duplicated word ("used re-used") here
    The RSX AME played an important role on early versions of VAX/VMS, which used re-used certain RSX-11M user space utilities...
    Addressed

Hobbyist section looks good.

Influence

  • This section is awesome and puts OpenVMS into context with all the other operating systems. I think it should be the first section of the article, before History.
Moved it into the history section. I feel like it would be somewhat out of place to put it before the history section. Perhaps a one sentence summary in the lede about the relationship between VMS and Windows NT may help here?

Release section looks fine.

Overall, as someone who works with Linux systems but has never worked with OpenVMS, this article was really fascinating and had a lot of interesting details. However, as a Wikipedia editor, I think the biggest barrier to Good Article status is that some parts of the article aren't written in summary style. The review isn't complete yet; I will make another pass on the article over the weekend to check all the citations. Ruthgrace (talk) 06:27, 26 March 2022 (UTC)[reply]

  • I made sizeable edits to the Clustering section. Mostly, I trimmed the sentences to bite-sized information. Back in the 1980s, I was a computer operator on a pair of VAX/VMS computers, so I have an interest in this article. If my edits in Clustering aren't reverted, then I'll go through the other sections and trim down their sentences. After I'm finished, then the summary style may be achieved. Timhowardriley (talk) 10:51, 29 March 2022 (UTC)[reply]
    That sounds great!! Thanks for your efforts, and that's awesome that you operated these machines!! I'll continue on with my fact checking and will update my review after having gone through all the citations today. Ruthgrace (talk) 16:56, 29 March 2022 (UTC)[reply]

I'm doing a second pass of the article today to look at the citations. I'm using Wikipedia:No_original_research#Primary,_secondary_and_tertiary_sources to guide my review, in particular the part that says "be cautious about basing large passages on [primary sources]" where primary sources are "original materials that are close to an event, and are often accounts written by people who are directly involved."

Reference feedback

Lead

  • Many of the citations in the lead are primary sources, but I think they're all useful facts to have in the lead, except maybe this bit which I think might be better suited for the body of the article only. This is just my take though, and not a change that's required for Good Article.
    OpenVMS has subsequently been ported to run on DEC Alpha systems, the Itanium-based HPE Integrity Servers,[16] and select x86-64 hardware and hypervisors.

History - Origin and name changes

  • The first sentence,
    In April 1975, Digital Equipment Corporation embarked on a hardware project, code named Star, to design a 32-bit virtual address extension to its PDP-11 computer line. A companion software project, code named Starlet, was started in June 1975 to develop a totally new operating system, based on RSX-11M, for the Star family of processors.
cites a primary source ("OpenVMS at 20 Nothing stops it" (PDF). Digital Equipment Corporation.). If you could find a secondary source about when and how OpenVMS started, I think using that instead would help cut down on unecessary detail.
  • Similarly, this sentence
    The Star and Starlet projects culminated in the VAX-11/780 computer and the VAX/VMS operating system. The Starlet name survived in VMS as a name of several of the main system libraries, including STARLET.OLB and STARLET.MLB.
cites a page that looks like it's written by HP technical sales staff (http://www.hoffmanlabs.com/vmsfaq/vmsfaq_001.html). If the detail is notable enough to come up in a secondary source, maybe you could cite that and include it, otherwise, I think it can be removed.
  • Pretty much everything in the second paragraph of this section is primary sources, except for the Computerworld article. I think sticking to details mentioned in secondary sources like the computer article will take it closer to summary style.
  • All the citations in the third paragraph ("Beginning in 1989, a short lived distribution of VMS...") are also primary sources, so I would recommend removing that paragraph, or reducing it to one sentence. Though I did get joy out of reading this blog post mentioning "VMS Forever" bumper stickers. :)
  • For the last paragraph, only this sentence has a non primary source
    DEC renamed VAX/VMS to OpenVMS as an indication for its support of "open systems" industry standards such as POSIX and Unix compatibility,
so I would recommend removing the other details.

Port to DEC Alpha

  • first sentence is from a primary source (propietary company materials, in fact). I think you can remove it.
    During the 1980s, DEC planned to replace the VAX platform and the VMS operating system with the PRISM architecture and the MICA operating system.
  • The second sentence is also from a primary source (Bob Supnik's personal anecdote) but I think it's a pretty cool piece of history and personally don't mind if you keep this one (though you'll have to alter the beginning of this sentence if you remove the first one)
    When these projects were cancelled in 1988, a team was set up to design new VAX/VMS systems of comparable performance to RISC-based Unix systems.[47]
  • Next few sentences cite secondary sources. The report from MIT studying the development of cutting edge tech using DEC Alpha as an example is particularly col.
    After a number of failed attempts to design a faster VAX-compatible processor, the group demonstrated the feasibility of porting VMS and its applications to a RISC architecture based on PRISM.[48] This led to the creation of the Alpha architecture.[49] The project to port VMS to Alpha began in 1989, and first booted on a prototype Alpha EV3-based Alpha Demonstration Unit in early 1991.
  • The last sentence in this paragraph is from a publication self-published by DEC, and I think it can be removed
    Prior to the availability of Alpha hardware, the Alpha port was developed and booted on an emulator named Mannequin, which implemented many of the Alpha instructions in custom microcode on a VAX 8800 system.[51]
    Removed
  • Excepting for this citation on the last paragraph (https://www.arnnet.com.au/article/111492/compaq_details_strategy_openvms/), the rest of this section seems to be based entirely on primary sources, and I would recommend either deleting it entirely or condensing it to one or two sentences.

Port to Intel Itanium

  • for the first sentence
    In 2001, prior to its acquisition by Hewlett-Packard, Compaq announced the port of OpenVMS to the Intel Itanium architecture.
I don't think you have to say that the info was published by Compaq or that they weren't owned by HP yet at the time (though I'm glad that you considered that in evaluating whether it is a primary or secondary source)
  • These two sentences at the end of the first paragraph are from primary sources, and I think they should be removed as unecessary detail.
    The first boot consisted of booting a minimal system configuration on a HP i2000 workstation, logging in as the SYSTEM user, and running the DIRECTORY command. The Itanium port of OpenVMS supports specific models and configurations of HPE Integrity Servers.[11] The Itanium releases were originally named HP OpenVMS Industry Standard 64 for Integrity Servers, although the names OpenVMS I64 or OpenVMS for Integrity Servers are more commonly used.[66]
  • The rest of this section seems to cite primary sources entirely, and I would recommend removing that also.

Port to x86-64

  • Except for the first sentence
    When VMS Software Inc. (VSI) announced that they had secured the rights to develop the OpenVMS operating system from HP, they also announced their intention to port OpenVMS to the x86-64 architecture.
which cites a news article, this section seems to entirely cite primary sources, so I encourage the removal of all the rest. At this point the history section could probably go without any subheadings and include both the origins and the ports.

I will take a break and then continue on with the Architecture section.

Here's a link to the tool that I use to check for copyright violations: https://copyvios.toolforge.org/ The article looks fine right now (violation unlikely), and we can run it again after the article has undergone improvements and is ready for review once more. Ruthgrace (talk) 17:57, 29 March 2022 (UTC)[reply]

Thank you for all your hard work reviewing the page. I will review over the coming days and begin making the changes you have suggested. Vt320 (talk) 18:12, 29 March 2022 (UTC)[reply]

OK, I'm back for one last round to complete the review!

Architecture

  • I recommend removing the last sentence here which is from a primary source (a company-hosted training)
    These VAX architecture mechanisms are implemented on Alpha, Itanium and x86-64 by either mapping to corresponding hardware mechanisms on those architectures, or through emulation (via PALcode on Alpha, or in software on Itanium and x86-64).[68]

Executive and Kernel

  • This sentence uses a primary source and is probably a detail that can be removed
    Code running at executive mode can switch to kernel mode at will, meaning that the barrier between the kernel and executive modes is intended as a safeguard against accidental corruption as opposed to a security mechanism.[88]
  • this sentence is uncited, and can probably also be removed
    In addition, other functionality such as logical name management, synchronization and system service dispatch are implemented inside the Kernel.

Extension mechanisms

  • first bit cites a primary source. i recommend removing it
    OpenVMS allows user mode code with suitable privileges to switch to executive or kernel mode using the $CMEXEC and $CMKRNL system services, respectively.[89] This allows code outside of system space to have direct access to the Executive's routines and system services.

File system

  • The first paragraph cites only primary sources (self-published by VSI), so I recommend removing it
    The typical user and application interface into the file system is the Record Management Services (RMS), although applications can interface directly with the underlying file system through the QIO system services.[92] RMS supports multiple record-oriented file access methods and record formats (including fixed length, variable length, and a stream format where the file is treated as a stream of bytes, similar to Unix). RMS also supports remote file access via DECnet,[93] and optional support for journaling.[94]
  • same with these two sentence in the second paragraph
    The most significant structure levels are ODS-2, which is the original VMS file system, and ODS-5, which extends ODS-2 with support for Unicode file names, case sensitivity, hard links and symbolic links.[96] VMS is also capable of accessing files on ISO 9660 CD-ROMs and magnetic tape with ANSI tape labels.[97]
  • Since Spiralog was kind of a flash in the pan, I recommend replacing the entire paragraph about with a single sentence, or removing mention of it entirely.
    Alongside the OpenVMS Alpha V7.0 release in 1995, DEC released a log-structured file system named Spiralog which was intended as a potential successor to Files-11.[98] Spiralog shipped as an optional product, and was discontinued at the release of OpenVMS Alpha 7.2.[99] Spiralog's discontinuation was due to a variety of problems, including issues with handling full volumes.[100] The developers of Spiralog began work on a new file system in 1996, which was put on hold and later resumed by VSI in 2016 as the VMS Advanced File System (VAFS, not to be confused with DEC's AdvFS for Tru64).[101][102] VAFS no longer appears on recent roadmaps, and instead VSI have discussed porting the open source GFS2 file system to OpenVMS.[103][104] One of the major motivations for replacing the Files-11 structures is that they are limited to 2TiB volumes.[96]

Command Language Interpreter

  • the first paragraph cites only a primary source, and I think it can be removed
    An OpenVMS Command Language Interpreter (CLI) implements a command line interface for OpenVMS; responsible for executing individual commands, as well as command procedures (equivalent to shell scripts or batch files).[105] The standard CLI for OpenVMS is the DIGITAL Command Language, although other options are available as well.
  • Last sentence of the 2nd paragraph cites a primary source and can probably be removed
    A CLI gets mapped into a process' private address space through execution of the LOGINOUT image, which can either be executed manually, or automatically by certain system services for process creation.[60]

Features - Clustering

  • this section cites only primary sources, and I recommend either reducing it to one sentence, or removing it. Personally, I think this is the most interesting part of the section.
    OpenVMS supports up to 96 nodes in a single cluster. It also allows mixed-architecture clusters.

Networking

  • I think this section is also all primary sources and I recommend removal or reduction to a single summarizing sentence.

Programming

  • I think this last paragraph is also all from primary sources and can be removed
    Among OpenVMS's notable features is the Common Language Environment, a strictly defined standard that specifies calling conventions for functions and routines, including use of stacks, registers, etc., independent of programming language.[81] Because of this, it is possible to call a routine written in one language (for example, Fortran) from another (for example, COBOL), without needing to know the implementation details of the target language. OpenVMS itself is implemented in a variety of different languages and the common language environment and calling standard supports freely mixing these languages.[122] DEC created a tool named the Structure Definition Language (SDL), which allowed data type definitions to be generated for different languages from a common definition.[123]

Development Tools

  • This section looks to be based entirely on primary sources. I recommend removal.

Database management

  • This section looks to be based entirely on primary sources. I recommend removal. I think for development tools and database management, it's more appropriate for people to be looking up info about this from the primary sources directly, than Wikipedia, anyways.

User interfaces - Text-based user interfaces

  • This cites primary sources, and I think it can be removed.
    Other official CLIs available for VMS include the RSX-11 MCR (VAX only), and various Unix shells.[120] DEC provided tools for creating text-based user interface applications – the Form Management System (FMS) and Terminal Data Management System (TDMS), later succeeded by DECforms.[141][142][143] A lower level interface named Screen Management Services (SMG$), comparable to Unix curses, also exists.[144]

User interfaces - Graphical user interfaces

  • I think this section also only cites primary sources. Actually, I think the first sentences under User Interfaces are great, and maybe the entire section can be just that, and some of the reference moved up to support that.
    VMS was originally designed to be used and managed interactively using DEC's text-based video terminals such as the VT100, or hardcopy terminals such as the DECwriter series. Since the introduction of the VAXstation line in 1984, VMS has optionally supported graphical user interfaces for use with workstations or X terminals such as the VT1000 series.

Security

  • This cites only primary sources, and I think it can be removed.

Vulnerabilities

  • The citations here are great. A suggestion: it might be easier to read if instead of a bulleted list, there were two subsections called "Default passwords" and "Privilege escalation".

Cross platform compatibility

  • This cites only primary sources, and I think it can be removed.

Hobbyist program

  • This cites only primary sources, but I think that this is an important detail about OpenVMS. Is there any way you can find one or two secondary sources that mention the OpenVMS Hobbyist Program?

Open source applications

  • This cites only primary sources, and I think it can be removed.
Removed this section

Influence

  • The first bit cites primary sources, and I think it can be removed
    During the 1980s, the MICA operating system for the PRISM architecture was intended to be the eventual successor to VMS. MICA was designed to maintain backwards compatibility with VMS applications while also supporting Ultrix applications on top of the same kernel.[187] MICA was ultimately cancelled along with the rest of the PRISM platform, leading Dave Cutler to leave DEC for Microsoft.
  • This sentence also cites a primary source and can be removed
    This lineage is made clear in Cutler's foreword to "Inside Windows NT" by Helen Custer.[190]
    Addressed
  • If you can find a secondary source about FreeVMS, I would use that, otherwise, consider removing the paragraph about it
    A now-defunct project named FreeVMS attempted to develop an open source operating system following VMS conventions.[191] FreeVMS was built on top of the L4 microkernel and supported the x86-64 architecture. Prior work investigating the implementation of VMS using a microkernel-based architecture had previously been undertaken as a prototyping exercise by DEC employees with assistance from Carnegie Mellon University using the Mach 3.0 microkernel ported to VAXstation 3100 hardware, adopting a multiserver architectural model.[192]
    Found a secondary source
  • The Russian derivatives also cite primary sources, but I find it more interesting because (presumably) they were more successful than FreeVMS. However, I would remove this detail
    The main difference between MOS VP and the official DEC releases was the translation of commands, messages and documentation into Russian, and support for the Cyrillic script using KOI-8 encoding.[196]
    Condensed this, but I felt it was important to describe what the differences were between MOS VP and the original VMS

Overall, I think this article has a lot of potential, and if the issues I mentioned were fixed, would take just one more review pass to get to Good Article. What do you think about putting it on hold for now while you make the changes BlueMoonset Timhowardriley Vt320? If you think you can do everything up in a few weeks, I'm also OK with just leaving the review active. Ruthgrace (talk) 18:56, 29 March 2022 (UTC)[reply]

I think I should be able to work through these items in the coming days. Let's leave the review open. Vt320 (talk) 19:03, 29 March 2022 (UTC)[reply]
Sounds good! Ruthgrace (talk) 04:52, 30 March 2022 (UTC)[reply]

Focus on decision-making material

I hope to not offend the original editors, but I'll be removing insignificant facts. I'm coming from the viewpoint of a decision-maker considering OpenVMS over another OS. Timhowardriley (talk) 18:08, 29 March 2022 (UTC)[reply]

I think it's best to go at it with the perspective of writing for an encyclopedia. For example, someone considering OpenVMS over another OS might not care about the history of OpenVMS, but that would be relevant for an encyclopedia. I recommend reading the Wikipedia:Manual_of_Style guidelines, as well as the Wikipedia:Summary_style guideline specifically to help decide what to cut. I do agree that there are a lot of facts in this article that are only mentioned in primary sources, and that these can be removed. Excited to see the results of your work on this :) Ruthgrace (talk) 18:13, 29 March 2022 (UTC)[reply]
  • Okay. I'll consider all true facts significant.
  • If I remove something that I think isn't true, then I'll remove it on a single edit. That way it can be reverted if I'm wrong.
  • I'll primarily transform sentences with multiple messages into multiple sentences with a single message. However, I will trim redundancies. For example, I trimmed something like "peripheral hardware" down to "peripherals" because all peripherals are hardware. Timhowardriley (talk) 21:07, 29 March 2022 (UTC)[reply]
    Timhowardriley, it might be worth waiting until Vt320 goes through the good article feedback before making your changes, since the good article feedback also involves a lot of removals. Ruthgrace (talk) 04:55, 30 March 2022 (UTC)[reply]

Article reads like a brochure

The article reads like a brochure because it has so many brand names. (I did a text search for "called", "named", and "known as" and counted 30 matches.) On the other hand, operating system components have generic names like those found in textbooks. My expectation for this article would be a parallel article to operating system but with OpenVMS's implementations. I feel compelled to point this out. Timhowardriley (talk) 00:45, 7 April 2022 (UTC)[reply]

I'm not clear on your point here. If you read articles for other commercial operating systems, they will also contain brand names for features and software which runs on top of those platforms. Vt320 (talk) 19:32, 8 April 2022 (UTC)[reply]

Drive-by review

Hi. I noticed this in the queue and decided to give it a read. Just to give a little context, I was coming into the computer industry just about the time VMS hit the scene. We got an 11/780 at school sometime around 1978 or 1979.

Anyway, I'm having trouble seeing that this meets the "prose is clear, concise, and understandable to an appropriately broad audience" criteria. I'm familiar with much of the material, yet I'm still finding it a slog to get through. For example, the first sentence: "OpenVMS, often referred to as just VMS,[10] is a multi-user, multiprocessing and virtual memory-based operating system." You have to trudge through a lot of stuff to get the the most important point: "OpenVMS ... is an operating system". The laundry list of customer types ("banks and financial services, hospitals and healthcare, telecommunications operators, network information services, and industrial manufacturers"). I'm sure that list applies/applied equally to Unix, Windows, OS/360, or just about any OS. It's marketing fluff. Certainly doesn't belong in the lede.

The rest of the article reads much the same way. I'd like to see less of a collection of facts and more of a coherent story.

I'm also concerned about the sources. As others have mentioned, this is really heavy on primary sources, much of which is marketing material. Some of the sources are just plain not WP:RS. Several usenet comp.os.vms posts? Those have no place in a GA. An interview with Dave Cutler? Seems more like a "Further reading" thing than a referenced source. YouTube videos of conference presentations? If they're not talks of refereed papers, they're not WP:RS. "OpenGL Frequently Asked Questions" on faqs.org? Not even close to a WP:RS.

Sorry to sound so negative on this. I gather this was delisted from GA and this is an attempt to get it back to snuff? A valiant and commendable effort, but I think this is a long way from GA still. -- RoySmith (talk) 01:52, 11 May 2022 (UTC)[reply]

RoySmith, while someone popped a {{DelistedGA}} template on the talk page on 24 October 2005, there was nothing on that page to indicate it was a GA in the first place (though someone posts about a week later querying the delisting); there's nothing that I can see that makes it a GA. (If it was a GA, the standards over sixteen years ago were quite poor; I think the current article stands or falls on its current state, not on something that happened before most of us first edited Wikipedia.)
It's been six weeks since the most recent reviewer, Ruthgrace, has edited on Wikipedia. Perhaps you'd be willing to take over the review? Pinging nominator Vt320, in case they haven't seen what you've written thus far. BlueMoonset (talk) 04:50, 20 May 2022 (UTC)[reply]
I agree that the delist is a non-sequitur. My feeling is that this meets WP:GAFAIL for the overall writing style. To take another example, this paragraph:
The main challenge in porting VMS to a new architecture was that VMS and the VAX were designed together, meaning that VMS was dependent on certain details of the VAX architecture. Furthermore, a significant amount of the VMS kernel, layered products, and customer-developed applications were implemented in VAX MACRO assembly code. Some of the changes needed to decouple VMS from the VAX architecture included the creation of the MACRO-32 compiler, which treated VAX MACRO as a high-level language, and compiled it to Alpha object code, and the emulation of certain low-level details of the VAX architecture in PALcode, such as interrupt handling and atomic queue instructions.
Everything that says could be condensed down to:
There were two main challenges. First, VMS was tightly coupled to the VAX architecture, requiring interrupt handling and atomic queue instructions to be emulated in Alpha PALcode. Second, much of the system was written in assembler; A MACRO-32 cross-compiler had to be written to generate Alpha object code from the original assembler source.
There's virtually no paragraph in the article which couldn't use a similar rewrite. The second GAFAIL issue is the sourcing. As noted above, there's a number of sources which fail WP:V, mostly as WP:UGC. Beyond that, however, is the overwhelming reliance on WP:PRIMARY sources. WP:GACR doesn't say anything about primary vs secondary sources, so that part would be WP:IAR, which may or may not be acceptable in a GA review.
Here's my offer. I'm going to let this be for a couple of weeks. If nobody has done so in 2 weeks (I've set a calendar reminder for myself), I'll take over the review, at which point my expectation is that I'll apply WP:GAFAIL. If another reviewer with a more positive outlook comes along before then, they're welcome to pick this up and take it in whatever direction they see fit. -- RoySmith (talk) 14:46, 20 May 2022 (UTC)[reply]
Thanks for the ping, will take a look at the additional feedback and work on it. Unfortunately I don't have as much time to work on the article as I did when I nominated it back in November. Vt320 (talk) 12:32, 22 May 2022 (UTC)[reply]
yes, even if all the feedback were addressed, it would need at least an additional pass of feedback + edits to meet GA status IMO. I will fail it for now and you're welcome to re-nominate later when you have more time, @Vt320 Ruthgrace (talk) 02:11, 27 May 2022 (UTC)[reply]
just wanted to leave a note before closing it out to say that I really appreciate your work on this, @Vt320!! The article is better for it, and I'm sure you can get to GA status eventually if you decide to keep at it. Ruthgrace (talk) 02:18, 27 May 2022 (UTC)[reply]