> "You can abbreviate a command as long as the abbreviated name remains unique among the defined commands on a system. DCL looks only at the first four characters for uniqueness."
and since max command line length seems to be a few K, the masochistic could try instead:
$ DISCIPLINEOFPROGRAMMING
(are there any other 1976 things in the equivalence set of DISCONNECT?)
DCL is VMS's command line interface. Commands start with full-on verbs (set, copy, define, print, ...). You can use partial strings in commands as long as they are unique (e.g. "set def" instead of "set default"). Imagine being able to type "pyth" at a bash prompt and it running python.
What I think the previous posts are referring to (and which I don't remember from my DCL days) is that apparently DCL only checks the first four characters for uniqueness, so "disc", "discoduck" and "discgolf" match the "disconnect" command.
However, current VMS releases won't run on a VAX, and there's no plan to change that. See their FAQ (which links to the product roadmap for projected future releases):
(I dimly recall reading someplace that they haven't done a VAX build in so long that some of the build chain has suffered bitrot, and some VAX-specific innards might have been misplaced.)
Sure. I'm in the space that doesn't care about that. This whole COVID isolation thing revived an interest in retro computing for me. So I've ordered and repaired/hacked 8+ old CPM, classic mac, RISC Unix, etc computers since March.
It's a little out of control (space/attention wise) now, to where I need to sell the things I've fixed and start a new batch. VAX/VMS might be a good next candidate.
No indication of the exact model, or what it has for RAM or HDs. I would only buy ones that had a screen shot of the console output, since then you have some confidence that it actually boots.
It kind of makes sense. A lot of people have this stuff sitting around for 20+ years and just want to get rid of it. Connecting a serial console cable to a headless rack mount server might be a lost art.
> Is there a case to be made for developing new software […]
I think one decent case would be to keep yourself honest.
Linux started out a 80386 only, but someone ported it to DEC Alpha. By deciding to run on both 32- and 64-bit platforms in the 1990s, it kept the kernel developers agnostic. Then when the x86 world went 64-bit with amd64, there was probably a lot less 'cleanly up' to do for it to be ported compared to if it had been focused on pure-x86 (see also SPARC and endianness). It's said that NetBSD has a very clean code base because of it's reputed high portability.
Similarly Solaris was very scalable. Partly because in 1996 Sun released the SPARCcenter 2000, which could handle 20 CPU sockets. That was a lot, and I'm guessing not many folks bought one, but they had to deal with it in an official capacity, as time when on more CPUs (and cores) became prevalent Solaris was good to go as that situation became more mainstream.
If you develop for the odd ball situations and corner cases, it may force you to be less lazy as a programmer.
You are absolutely correct; anyone who worked on Solaris scalability and performance back in the day will have plenty of Dragon war stories -- and Solaris did so well on Campfire (a.k.a. UltraSPARC Enterprise 4000, shipped 1996) exactly because so much time and energy had been spent on Dragon (a.k.a. SPARCcenter 2000, shipped 1992).
My main gripe with the various 'E-series' systems (IIRC, we had some E3x00s) was boot-up time, especially the RAM check on power up.
I was in an academic environment, and so every so often we had to power down our lab for electrical/fire code inspection power outages by Facilities. The first time we rebooted one (with 4GB of RAM?) it kept booting and booting and booting and booting and booting and booting. 17 minutes later we got the login prompt on the console.
We put the 17 minutes as a note in our run book so that we knew not to worry if took 'forever' and to move onto the next step. Otherwise we'd start freaking out about something being "broken" with the system(s).
Yes! I worked at a startup with an E3500, around 1998-99, and those machines took forever to boot. Nice hardware though. I think ours had a whopping 512 meg.
The 2000 was pretty popular AFAIK; I saw a lot of them anyway. Yeah...a lot of stuff got worked out in Solaris on the SC2000, and the journey was painful. But after a year or so of very frequent out-of-cycle patches, some hardware upgrades, and a lot of time with Sun support, they were pretty stable and scalable. Nice machines.
I don't think we ever got the OC-12 ATM cards really stable...fortunately, networking went a different direction and they had a mercifully short lifespan.
Replacing a mainframe with a VM and not losing performance is a huge benefit.
But the software that used to run on that mainframe is now easier to modify, and there's a 10 year backlog of critical bugs that need to be fixed but we were always too scared of breaking something because we couldn't test it - now we have a VM. We can spin up a second one.
VMS is old and used to run multiuser systems and on relatively expensive machines; but they were called 'minicomputers' because they were already less huge/expensive than mainframes. And after the mini came the 'micro' which is more or less the PC as you know it.
i would call a vax a "super mini". one of the crop of 32 bit multi-user systems that came out in the 80's.
a pdp-11 was a mini, it was multi-user, but the machine was weak. a 'super mini', with 16MB of memory, now that was a machine you could do great things with.
The VAX succeeded the PDP, though the PDP was kept in production for many years of overlap. They're different generation of technology filling the same niche. The PDP-11/70 was the beast of it's day, and even came in a multi-processor version (the 11/74). Saying the PDP was a mini and the VAX was a supermini is like saying the 286 was a mini but the 386 was a supermini.
Mainframes are completely different beasts though. A VM on a Xeon machine is not a fair comparison to an app running on a Mainframe because by design the mainframe has many redundant systems to stay online for ever. Lots of dedicated hardware for things and redundant systems etc are the selling point to mission critical hardware that is the mainframe
I suspect this is more about not having to pay IBM for the hardware and contracts anymore
I say the same performance with absolute confidence.
I expected a drop in performance when a particular contract I worked with asked us to see if we couldn't get everything running on a VM instead of the IBM iron. Like you suspect, that was about not paying for the hardware anymore because just the price of electricity was a noticeable impact on the bank's overall budget. It was an R&D project to see if we could avoid that.
What we put together was a QEMU instance, running atop 3 very very cheap commodity servers in duplication, so that if one went down it would switch over without downtime. We chose the cheap servers, because we already had them hanging around. (Probably around $1000 in hardware all up, today.)
We did not see a drop in performance or reliance. But we did see an increase in performance. As in, ~30%. I avoided suggesting this is always the case, but it is a significant possibility when changing. As far as I know, the bank in question is now running a similar setup everywhere they used to have a mainframe.
While reading the parent comment ("stay online for ever") I was reminded of VMware lockstep VMs, which nowadays support up to 4 cores. I wouldn't be surprised if a few places do OpenVMS on lockstep.
I am very curious what you mean by "in duplication". Do you mean "3 copies of production and a router" (probably not) - or are you saying you did something like lockstep for QEMU?
Incidentally I just found https://wiki.qemu.org/Features/COLO, which looks like it may be being successfully used privately in one or two places (looking at the email addresses).
It was a little while ago, but it was 3 production servers running with the mirror backend, with a dirty-bitmap [0], and a complicated routing setup (which could hold packets instead of dropping them, depending on their importance). I didn't really have anything to do with the routing though, so I can't say much.
I'd probably use COLO if I was to do it again today.
Some Arm processors that you can buy today also support dual-core lock step in hardware, such as the Jetson AGX Xavier from Nvidia. (however, not enabled by default for perf reasons, because you halve your cores by design in that mode)
Could you point us to the source of your information please? The Xavier does not support dual-core lockstep afaik. There are other methods in place to detect random faults, but not that one.
The first widely available ARM cores providing it are fairly new (at least in the automotive domain).
Very interesting, thank you very much! I know the lockstepped R5s and the dual execution feature of the Carmels (close but no cigar for ISO26262), but not that one. Gonna ask our FAE about it eventually. ;-D
Fascinating. If the main mainframe use case is more database ops for banking or airline scheduling that doesn’t seem very compute heavy in my head so throwing hardware at the problem makes sense especially if you can save millions to invest in development and modernization.
I agree with you there. Most mainframe tasks today aren't that heavy on the compute - most relied on the amazing I/O stack, and that makes it easier to replace them.
Heavily vectorised code with modern instruction sets can also be more performant than a lot of the older compute chips, but that requires more rewriting of code, and someone who intricately understands both the code and the math. Which makes modernising much more expensive.
The VM approach is a simpler way to get you most of the way there, but replacing heavy compute stacks is usually going to require a decent bit of investment.
VMS isn’t an IBM mainframe OS, though. I think typical native VMS machines are much closer to normal enterprise servers than mainframes, so virtualization would make sense.
From my understanding there used to be a OpenVMS hobbyist license available for people to use. However the parent company seems to be abandoning it and I had trouble discerning if there was going to be some sort of replacement for it at the time I read about it. Does anyone have any better info about this?
The website has a page about a community license [0].
> VMS Software Inc. is excited to announce the availability of the OpenVMS Community License that allows the OpenVMS community members (hobbyists, non-commercial software developers, and others) to obtain an OpenVMS license free of charge.
> OpenVMS x86 licenses will be available later as more stable versions of OpenVMS are released for this architecture.
The Wikipedia article about OpenVMS clarifies this in the second paragraph. My point is that the OpenVMS FAQ should address this question because it keeps coming up.
At that time, “open” was applied to things that were based on published standards and portable, as distinguished from systems they were based in proprietary standards or tied to particular processor architectures. VAX/VMS was named to OpenVMS to signal that it supported POSIX and after the port to the Alpha.
Free/libre software generally refers to copyleft. Open Source was coined as a competing term, more friendly to tivoization and propiatary use (eg: selling a hw box with bsd/mit code parts as a commercial, closed solution). An extension of Source Available.
Free/libre software is defined around the "four freedoms" for end-users (run, study/change, (re)distribute verbatim, distribute modifications).
Open Source is more concerned with the rights connected to the source code, and does not quite see the end-user (who runs the binary) as the same as the developer (who modifies and compiles the source).
The entitled attitude of open source users not to pay for software, examples abound on this site, specially when one does Show HN of a commercial product, only to be flooded by half working open source alternatives.
> Did you sign I Love MDN? Great! Are you willing to pay 50-100 euros/dollars per year to keep MDN afloat? If not, this is all about making you feel better, not the technical writers. You’re part of the problem, not the solution.
Not everyone has that kind of money to spend on charity. I find the statement, quite frankly, condescending and ignorant. There are tons of countries in the world, consisting of web developers, who earn [far] less than an average SV wage. Sure, living expenses are also likely lower, but still.
I have travelled across several of those countries, apparently people outside of software development still managed to get hold of their tools, paying in some way for them, without feeling entitled to be given everything as free beer and yet getting paid for their own work.
Well, that depends. Software [licenses] has different price in the world, adapted to the local market. Hardware as well, but the lowest margin on hardware is simply higher than software. Especially state of the art. So the amount of people running around with a new iPhone in Serbia or India is, percentage-wise, simply lower than in USA. Yet, yes, they all use a browser on their devices. And they all have a legal license. Many people in poorer countries also pay with a different currency: privacy and security. Think Android, think out-of-date devices (older Android and iPhone devices).
Last time I checked a carpenter in Africa also doesn't pay the same as a carpenter in Europe for their saw set or the wood they need to produce the furniture, yet both buy them.
> > Did you sign I Love MDN? Great! Are you willing to pay 50-100 euros/dollars per year to keep MDN afloat? If not, this is all about making you feel better, not the technical writers. You’re part of the problem, not the solution.
> Not everyone has that kind of money to spend on charity.
The argument assumes users of MDN have 50-100 EUR to burn on charities. It shouldn't attempt to convince the reader with a static amount. As if a web developer from Serbia who donates 20 EUR a year is somehow part of the problem. They're not. Perhaps, if such donations from poorer countries are not recognized as solving the problem, the problem is that the costs are too high as it is.
>I have travelled across several of those countries, apparently people outside of software development still managed to get hold of their tools
You'd be surprised. Business owners or independent workers that need to own their tools, get into all kinds of debt to get them globally.
In fact a classic example is the loans needed by independent seamstresses to buy sewing machines in the developing countries (and which few banks would give)...
Except that isn't what many in FOSS free beer movement do.
Self employed carpenter buys their saw, self employed FOSS free beer developer downloads some stuff, never upstreams anything, gets paid and screams loudly to upstream when that stuff they got as free beer doesn't work.
It's a bit of an apples and oranges comparison, as the last VAX VMS was released in 2001, and stopped getting support in 2012. I think the main target for x86 VMS is people with Itanium (or Alpha) hardware wanting some sort of supported future path.
