VMS on Raspberry Pi 5

That''s why I qualified my statement with "(one CPU)"

I'd have loved to have grep on VMS. I had to keep lookign through all my directories to find what I needed. Does VMS have anything like this?

Many thanks, Alex

Just to be sure that everybody agrees about numbers.

A 210 is a 200 model with 1 CPU. 1 x 2.8 VUPS.

A 420 is 400 model with 2 CPU's. 2 x 7 VUPS.

A 660 is a 600 model with 6 CPU's. 6 x 32 VUPS.

Arne

So in which way do you think VMS is so different than all of the above? I only know a few of the ones you list, but I do know a bunch of others. And to me, there is nothing I would say is strange, unique or even special about how VMS does things.

It is a bit different than under Unix-like systems, since commands don't necessarily have a 1:1 mapping to a binary. But apart from that, I fail to see much of a difference.

And with alias for things, along with symlinks, Unix isn't really any different there either.

Well, apropos is just a simple tool for one thing. Which is just a way to search man-pages. find on the other hand can be used for almost anything, and the number of switches/options available is more than any person can memorize. Admittedly, all the operations are related to files, but then again, almost anything is a file under Unix. ;-)

Johnny

With find it don't matter. Even the original is crazy. The one tool where the Unix paradigm got completely lost...

GNU have indeed gone crazy with options to programs as well, I admit. Not to mention the added craziness of Red Hat...

Johnny

Good to point out. I'm getting the feeling people did not understand.

Johnny

Neither do unix commands (eg. ex and vi are the same binary as are more and less) the extreme case is busybox, or indeed anything built with crunchgen (such as almost the entire contents of /rescue on this FreeBSD box). Then there are shell aliases and functions.

Well, I would argue that there is a difference when you have the same binary with different names. From a shell point of view, that's completely separate commands, as basically commands are binaries, and there is a 1:1 mapping there. But of course there are exceptions. Things that deal with shell internal commands are all not related to any binary at all, and as noted, aliases muddy the water way more.

And behind the scene you certainly have the fact that it might be the same binary, and the way it behaves just depends on the content of argv[0].

But like I said - in the end I do not really think that VMS is any different, and I was questioning Martin, who was the one saying that VMS was so different.

Johnny

...and I thought TI BASIC on the 99/4A was slow. :)

"Let's build a 16-bit computer...but hobble it with an 8-bit bus, and make it access most of the available RAM through a one-byte window into memory that's only directly attached to the video processor, and implement BASIC in a pseudocode-like language that itself gets interpreted at runtime on the CPU. What could possibly go wrong?"

Its been a long time, but as I already said,

VMS seemed to have a few portmanteau commands where the other OSen had a host of single function commands. For instance, to access the equivalents of the Unix commands rm, cp, less and ls under VAX/VMS you first logged in (same as unix) but then you had to start a package (sorry, but I don't remember its name) to access its own command line and then run the UNIX- like comands.

That's stuck with me because no UNIX or Linux system works that way.and logging to every other OS I've used has given immediate access to a command line. The main deviation from this plot are IBM's OS/400 and ICL's

Both these have much more rational command naming systems than either Unix/Linux or an excellent command look-up system: command names are so regular and that's backed a special key that shows your full screen prompt with help text and default parameter values already filled in and mandatory ones left blank. Any Invalid parameters you enter are merely flagged up ready for correction.

VME/B commands had two names, one abbreviated and a bit cryptic for direct input to the command line and the other much longer and intended for use in command scripts. For instance, 'x' always meant 'delete' and 'f' always meant 'file', so the command to delete a file could be entered as either "xf myfile" or as deletefile("myfile");

OS/400 is quire similar here, except that command and file names could never be more than 9 characters long and so often appeared to like line noise. For instance and there were no just three letter groups so:

crtrpgpgm is the RPG3 compiler (Create RPG program) crtplipgm is the PL/1 compiler crtcblpgm is the COBOL compiler

To OS/400 'rpg' means RPG and 'pgm' always means 'program, ie once you understand the naming system, you can often guess what a command would be called.

Also, both systems also had a 'search by name' ability that could be run from the command line or from the text editor if you were editing a command file.

The major failing of both OS is that neither had a hierarchic filing system, such as both UNIX/Linux and Windows (and even DOS) provide.

I always thought this was odd, since George 3 had a hierarchical filing system way back in 1970, when I first got my hands on it, but then again VME/B and OS/400 (which AFAIK was a resurrected version of IBM's Future Series which was killed off in about 1971) were first conceived somewhere in the early 1970s, i.e. after MULTICS was up and running, and which DID have a hierarchic filing system.

True enough, provided you exclude dinosaurs like S/360, AS/400, 2903s (been there too, but its just an ICL 1900 emulator running on box containing an ICL 2900 disk controller). Hierarchic filing systems as we know then now, seem to have originated with MULTICS, and maybe the ICL

My guess is that development of the 1900 and S/360 and all the other early mainframes started just a bit too early for their designers to have seen MULTICS and decided that hierarchic filing systems were the way to go.

Sure, but I wouldn't be surprised to fins that 'apropos' is just a wrapper round 'find'.

These days I mostly use 'locate' because its faster thanks to its associated overnight index update, for anything a bit more complex, i.e. with a bit of formatting included, 'awk / gawk' is my tool of choice.

Not so sure about that - the one thing it does well is walk a directory tree looking for matching entries. Arguable -exec wasn't needed but perhaps it predated xargs.

Now I am confused.

If you login to VMS you have immediate access to DCL commands.

If you want to use *nix commands you need to start something (very old Eunice, old posix or new GNV bash or something similar).

If you login to Linux you have immediate access to *nix commands.

If you want to use DCL commands you need to start some third party DCL implementation (Sector 7 ??).

What is the difference?

Arne

Oh my god.... I think he is equating Eunice with VMS.....

:-)

bill

I'm baffled by this.

find finds stuff in the filesystem that match some conditions.

What else does it do?

Its been a very long time (1990 or thereabouts and thats the only VAX- based project I was on, but I distinctly remember that login gave you a command line, but if you wanted to, say, get rid of old versions of a few files you had to start a a portmanteau program that gave access to all the file and directory manipulation functions via its own command line, and once you'd done all that, toy exited from that program to get back to the command line where logging in had left you.

At that time I'd not yet seen UNIX, but was familiar with a UNIX-like command line, first for seven years (1970-77) on ICL's George 3 OS (1900 hardware) and then another three years (1978-1981) on ICL's VME/B OS (2960 hardware).

Pass. While I'd been (amongst other things) a COBOL and assembler programmer and George 3 sysadmin on ICL 1900 kit and designed and written database systems on an ICL 2960 in COBOL using an IDMSX Codasyl database system, I was just a database developer on the VAX system, so had no knowledge of much about it apart from what I needed to write COBOL and interface that with DEC's relational database system.

Sounds like a very custom setup. Back in the days various captive scripts existed to limit users exposure to full DCL. But most offered a menu system. And if not fully captive DCL access was a menu item.

Usually you just login and issue DCL commands.

If you want to get rid of old versions of foobar.txt:

$ purge foobar.txt

VMS + Cobol + Rdb was a common combo - it is till used today.

Did you use embedded SQL or Rdb module feature?

Arne

The one time I would hang on to old versions of manuals was when the vendor decided there were things you no longer needed to know (e.g. low-level I/O access), and deleted them from the new version.

I do this frighteningly often. Of course, the whole thing falls apart when someone helpfully decides to "straighten things out".

I don't believe it! There she goes again! She's tidied up and I can't find anything! -- Thomas Dolby: She Blinded Me with Science

I loved the Alpha, if there was any justice in the world it would have beaten the x86, but legal machinations and unexplicable madness happened. But not before DEC sprinkled some of their Alpha magic on the ARM to give us the StrongARM. Without which the architecture may not have been as widely adopted and we wouldn't have the Pi. Of course being wildly optimistic we could yet see ARM displacing x86, given the traction ARM is gaining in the data centre and on the desktop with Apple's M series - which was created by some of the design team of the Alpha - what goes around, comes around!

---druck

Yup. There was a lovely few months when the fastest x86 processor was actually an Alpha running the FX!32 x86 emulator :)