On 2023-11-14 16:46, Arne Vajhøj wrote:
> On 11/14/2023 10:07 AM, Bob Eager wrote:
>> On Mon, 13 Nov 2023 19:29:14 -0500, Arne Vajhøj wrote:
>>> On 11/13/2023 7:25 PM, Dave Froble wrote:
>>>> On 11/13/2023 4:03 PM, Bob Eager wrote:
>>>>> On Mon, 13 Nov 2023 16:26:19 +0000, Scott Dorsey wrote:
>>>>>> Ahem A Rivet's Shot  <steveo@eircom.net> wrote:
>>>>>>>>
>>>>>>>> How does that compare with a real VAX or a PDP/11?
>>>>>>>
>>>>>>>      One VUPS is supposed to be one original VAX CPU running VMS.
>>>>>>
>>>>>> Right, so this is about a Vax 6000 or so, right?
>>>>>
>>>>> No. Original VAX. An 11/780.
>>>>>
>>>>> A VAX 6000 (one CPU) was about 7 VUPs, as I recall.
>>>>
>>>> The 6000 used the NVAX, correct?  On a VAXstation 4000 Model 90A I get
>>>> 26-27 VUPS.  I'd think the 6000 would be similar.
>>>
>>> Depends on what 6000.
>>>
>>> 200 models - 2.8 300 models - 3.9 400 models - 7 500 models - 13 600
>>> models - 32
>>>
>>> (1-6 CPU's)
>>
>> That''s why I qualified my statement with "(one CPU)"
>
> Just to be sure that everybody agrees about numbers.
>
> 200/300/400/500/600 are generational models independent of number
> of CPU's.
>
> 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.

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

Johnny

On Tue, 14 Nov 2023 18:05:21 +0100
Johnny Billquist <bqt@softjar.se> wrote:

> It is a bit different than under Unix-like systems, since commands don't
> necessarily have a 1:1 mapping to a binary.

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 2023-11-14 18:54, Ahem A Rivet's Shot wrote:
> On Tue, 14 Nov 2023 18:05:21 +0100
> Johnny Billquist <bqt@softjar.se> wrote:
>
>> It is a bit different than under Unix-like systems, since commands don't
>> necessarily have a 1:1 mapping to a binary.
>
> 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

In comp.sys.raspberry-pi Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> Back in my Amiga days, I played with the Transformer, a
> software emulation of an 8088 on a 68000. It would run
> MS-DOS, but very slowly - I figured about a 10x slowdown.
> Once just for giggles I ran Z80MU (a Z80 emulation for
> MS-DOS) under the Transformer. Under these two levels
> of emulation I fired up the CP/M BASIC interpreter and
> typed "PRINT SIN(whatever)". It came back with the
> correct answer - 7 seconds later.

....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?"

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

On Tue, 14 Nov 2023 18:05:21 +0100, Johnny Billquist wrote:

> So in which way do you think VMS is so different than all of the above?
>
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
2900 series running under VME/B,

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.

> And with alias for things, along with symlinks, Unix isn't really any
> different there either.
>
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
1900 George 3 OS (Manually operated 1900s and 2903/4 all had flat filing
systems like MSDOS, FLEX, etc).

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.

> Well, apropos is just a simple tool for one thing. Which is just a way
> to search man-pages.
>
Sure, but I wouldn't be surprised to fins that 'apropos' is just a wrapper
round 'find'.
> find on the other hand can be used for almost anything
>
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.

--

Martin | martin at
Gregorie | gregorie dot org

On 11/14/2023 1:21 PM, Martin Gregorie wrote:
> 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.

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

On 11/14/2023 1:21 PM, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 18:05:21 +0100, Johnny Billquist wrote:
>
>> So in which way do you think VMS is so different than all of the above?
>>
> 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.

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

:-)

bill

On Tue, 14 Nov 2023 18:09:05 +0100
Johnny Billquist <bqt@softjar.se> wrote:

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

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Tuesday, November 14, 2023 at 10:57:03 AM UTC-8, bill wrote:
> On 11/14/2023 1:21 PM, Martin Gregorie wrote:
> > On Tue, 14 Nov 2023 18:05:21 +0100, Johnny Billquist wrote:
> >
> >> So in which way do you think VMS is so different than all of the above?
> >>
> > 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.
> Oh my god.... I think he is equating Eunice with VMS.....
>
> :-)
>
> bill

More likely he's referring to the POSIX shell from the 1990s. Has anyone here ever used it? I found a USENET thread from 1995 asking about it. We certainly didn't have that package at my university, and it was never available through the hobbyist program. https://groups.google.com/g/comp.os.vms/c/iN0XusPhZH4

On 2023-11-14, Johnny Billquist <bqt@softjar.se> wrote:
>
> With find it don't matter. Even the original is crazy. The one tool
> where the Unix paradigm got completely lost...

I'm baffled by this.

find finds stuff in the filesystem that match some conditions.

What else does it do?

On Tuesday, November 14, 2023 at 5:40:30 AM UTC-8, Arne Vajhøj wrote:
> On 11/14/2023 4:27 AM, Johnny Billquist wrote:
> >
> > Do you think all the propietary APIs and libraries under Unix are any
> > different?
> > Nowadays there is POSIX (didn't even exist back when VMS was designed),
> > but POSIX only covers a small fraction of the libraries people use in
> > development.
> >
> > Online documentation like man-pages is helpful, but it's usually not
> > nearly as deep as the VMS paper docs. The fact that the VMS docs were
> > made available as HTML and PDF was a nice improvement.
> The VMS API (SYS$, LIB$ etc.) is tiny by todays standard.
>
> Windows is huge. Win32, MFC, OLE/COM/ATL, .NET FX, WinRT etc.
> are probably a factor 100 bigger than VMS.
>
> Linux is a bit more tricky to measure, because it is not very well
> defined what to count: Linux kernel, glibc/musl, curses,
> Xlib + Xt + GTK/Qt, hundreds of development libraries available
> via distro package manager. I will claim that a "typical"
> Linux development machine has a lot more API's installed
> than VMS has.
>
> The non-OS platform API's are also way bigger than VMS API
> (Java + Maven repo, .NET Core + NuGet, Python + PyPi,
> JS + npm etc.).

I agree. The entire Win32 API is enormous because everything is jumbled together: processes and file handling, GUI, etc.. Win32 isn't even the native NT API: there's a different set of "Nt" APIs that Win32 calls into, and some programs/libraries (libuv is one) know how to open "ntdll.dll" and call native APIs directly whenever Win32 doesn't do what they need.

If you compare the low-level Win32 APIs to VMS, they're closer to each other than either of them is to UNIX. In Win32 and VMS, you have APIs that take many arguments and perform an entire function, like creating a process, while in the UNIX world, the API is deceptively simple. System calls like fork(), exec(), etc. take zero or few arguments but may require more work to get the job done, such as all the nonsense related to "close on exec" and dup()'ing file descriptors required to set up the environment for a child process.

The VMS APIs show their age by having a relatively large number of functions intended for assembly language, FORTRAN, etc. programming, for string handling and comparison, getting random numbers, and other functions that everyone now expects the programming language and its runtime library to handle: MTH$, STR$, OTS$, and some of $LIB. But you can just ignore all of those functions, and they don't add up to much code by today's standards. Back when RAM was expensive, the utility libraries were an excellent use of shared libraries years before SunOS and System V added them in the mid-1980s.

I think the complexity that's most confusing to someone new to OpenVMS isn't the APIs themselves so much as the underlying abstractions that don't exist elsewhere. Logical name tables and DCL symbols are both types of key/value mappings that are used in different places for different purposes. The C library exposes logical names as environment variables, but not the other way around. The RMS record APIs are roughly comparable to a library like Berkeley DB, but if you're not used to those features being integrated into the filesystem, then VMS may look overengineered, until you need something like what they provide.

The other complexity comes when you want to deal with I/O at a low level. $QIO is intimidating, with 12 arguments (although 6 of them are passed to the device driver). POSIX appears much simpler, until you actually have to use ioctl() or fcntl() and realize that not only is it not any simpler than VMS, but it's often not standardized between UNIXs. The abstraction of accessing everything through a file descriptor (UNIX) or channel number (VMS) is almost identical between the two.

On Tuesday, November 14, 2023 at 11:50:24 AM UTC-8, Jim Jackson wrote:
> On 2023-11-14, Johnny Billquist <b...@softjar.se> wrote:
> >
> > With find it don't matter. Even the original is crazy. The one tool
> > where the Unix paradigm got completely lost...
> I'm baffled by this.
>
> find finds stuff in the filesystem that match some conditions.
>
> What else does it do?

People say stuff like that because the man pages have grown lengthy compared to 30 years ago, and the standard commands have a lot more switches. On my Ubuntu box, the man page for find is 1324 lines long.

I just checked the man pages for "ls", "dd", and "cp", and they're all still fairly simple. The man page for "more" is 166 lines, but the man page for "less" is 1447 lines. The man page for "man" is 560 lines. And none of these programs are breaking the "Make each program do one thing well" rule. If anything, they're all doing their one thing better than ever.

On Tue, 14 Nov 2023 13:41:27 -0500, Arne Vajhøj wrote:

> On 11/14/2023 1:21 PM, Martin Gregorie wrote:
>> 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.
>
> Now I am confused.
>
> If you login to VMS you have immediate access to DCL commands.
>
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.

> If you want to use *nix commands you need to start something (very old
> Eunice, old posix or new GNV bash or something similar).
>
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).

> 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 ??).
>
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.

--

Martin | martin at
Gregorie | gregorie dot org

On 11/14/2023 3:10 PM, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 13:41:27 -0500, Arne Vajhøj wrote:
>> On 11/14/2023 1:21 PM, Martin Gregorie wrote:
>>> 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.
>>
>> Now I am confused.
>>
>> If you login to VMS you have immediate access to DCL commands.
>>
> 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.

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

> 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.

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

Did you use embedded SQL or Rdb module feature?

Arne

On 2023-11-13, TimS <tim@streater.me.uk> wrote:

> On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho.Jones@proton.me> wrote:
>
>> Looking back on it now. I think the strangest thing about VMS was the
>> Manual Set.
>
> Chap I shared an office with at SLAC back in the 80s was one of these
> hoarders. We not only had the current set of VMS doc in the office, but the
> complete previous set too, while he had the set before that in his garage at
> home.

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.

> He was the sort of chap who, if you asked him for the 3-page doc that you'd
> loaned him a month previously, could unerringly poke into the 3-foot high pile
> (er, one of the piles, sorry), on his desk and pull it out straight away, with
> zero search time. This made complaining about the paper piles futile. "Works
> for me!"

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

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On Tuesday, November 14, 2023 at 1:27:40 PM UTC-8, Charlie Gibbs wrote:
> On 2023-11-13, TimS <t...@streater.me.uk> wrote:
> > On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho...@proton.me> wrote:
> >
> >> Looking back on it now. I think the strangest thing about VMS was the
> >> Manual Set.
> >
> > Chap I shared an office with at SLAC back in the 80s was one of these
> > hoarders. We not only had the current set of VMS doc in the office, but the
> > complete previous set too, while he had the set before that in his garage at
> > home.
>
> 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.

On a related note, the VSI C Runtime Library manual has disappeared from https://docs.vmssoftware.com/ so I'm assuming it's in the process of being replaced with an updated version. I have a feeling that everyone in VSI engineering is very busy preparing to release V9.2-2 which is why they've been relatively quiet as of late.

On 13/11/2023 23:40, Martin Gregorie wrote:
> Several years later I did another project on DEC Alpha Servers running
> Tru64 UNIX, which I preferred to VMS, being a UNIX fanatic. Tru64 UNIXwas
> pretty much a straight-forward port of UNIX System V functions and
> programing tools onto a MACH-based kernel. This was amazingly fast for the
> era and fairly bullet-proof.

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

In article <uj0u59$1dlnh$1@dont-email.me>, news@druck.org.uk says...
> I loved the Alpha, if there was any justice in the world it would have
> beaten the x86...

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

--
John

On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:

X> $ purge foobar.txt
>
Yes, I remember those periodic purges.

I did like the customisable editor too and, IIRD, the ability to attach
customisations to file types. If there was an open source version of that
editor I might even be using it still.

>> 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.
>
>
> VMS + Cobol + Rdb was a common combo - it is till used today.
>
Worked well too - one of the better COBOL implementations
..
> Did you use embedded SQL or Rdb module feature?
>
The Rdb module.

The one real thumbs-down feature of the project, and the one that sank it,
was the bloody awful James Martin Associates system design method and its
almost equally poor diagramming rules. I mean, how can a usable Data
Structure Diagram ever be built when the overall system design rules
forbid you from adding any data items to entities but still let you insert
relationships between entities? Straight away this means you have:
(a) no way of verifying that the relationship is needed
(b) no way of validating end-to-end data flows through the system DSD.

IOW there's no way that you can verify the DSD, let alone get it reviewed
and signed off.

....and meanwhile we, the database design team, were never able to build
built a schema because the system designers never did hand us a usable DSD
to work from.

That surprised me because I'd bought a copy of James Martin's "Design of
Man-Computer Dialogs" - IMO one of the best books on application system
design I've ever seen. I bought my copy about ten years prior to that
fiasco and used it extensively when a small team of us were building BBC
Radio Three's music planning system: This was a complex system that had to
track and record every stage of building and broadcasting a concert from
the producer's original idea, checking that it wasn't too similar to any
other concert that would be broadcast around the target date, tracking and
booking all the performers and then, after the broadcast, making sure they
were paid as well as handling the repeat fees paid to performers if any
parts of a concert are rebroadcast later.

I doubt that this system, known as Orpheus, would have gone together half
so well without the ideas in that book,

For the record, it was built on an ICL 2966 mainframe, written in COBOL
and using IDMSX, a Codasyl database, as its data store. A BBC internal
team, with me as an external member, had completed that that about ten
years before the fiasco on the VAX.

IIRC there were even JMA consultants on the team that failed complete the
financial system on the VAX, but despite their presence, We never did get
a completed data structure to work from before the project collapsed.

--

Martin | martin at
Gregorie | gregorie dot org

On 11/14/23 2:09 AM, Ahem A Rivet's Shot wrote:
> On Mon, 13 Nov 2023 23:02:11 -0500
> "56d.1152" <56d.1152@ztq9.net> wrote:
>
>> There are some "ancient systems" that still see use. DOS
>> is one of them - compact/efficient and still fair for
>> embedded projects. CP/M derivs are also seen. OS9 is another -
>> and yes it's still developed and for-sale. Most of the
>> "big iron" systems from the 60s/70s went away however.
>
> Z/OS is still around and capable of running OS-360 binary
> applications as well as more modern unix based systems.

Had forgotten about Z/OS ... a bit out of my
price range at this point alas :-)

Most of those old Big Iron systems were very
well designed. No reason to completely throw
them away. Unix is rather "aged" these days
too - but it's still an inspired model, still
suited to build upon.

There's still a market for mainframes. McDonalds
Corp does NOT run on a iPad. Worldwide biz,
supply/financial logistics, soon you're using
SERIOUS computing power and need a SERIOUS
super-reliable/flexible OS to make it go. Wire a
few of those big black IBM boxes together .....

If VMS has a future, it's going to start with
those sorts of uses.

On 11/14/23 4:27 PM, Charlie Gibbs wrote:
> On 2023-11-13, TimS <tim@streater.me.uk> wrote:
>
>> On 13 Nov 2023 at 17:44:15 GMT, "Pancho" <Pancho.Jones@proton.me> wrote:
>>
>>> Looking back on it now. I think the strangest thing about VMS was the
>>> Manual Set.
>>
>> Chap I shared an office with at SLAC back in the 80s was one of these
>> hoarders. We not only had the current set of VMS doc in the office, but the
>> complete previous set too, while he had the set before that in his garage at
>> home.
>
> 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.
>
>> He was the sort of chap who, if you asked him for the 3-page doc that you'd
>> loaned him a month previously, could unerringly poke into the 3-foot high pile
>> (er, one of the piles, sorry), on his desk and pull it out straight away, with
>> zero search time. This made complaining about the paper piles futile. "Works
>> for me!"
>
> I do this frighteningly often. Of course, the whole thing falls apart when
> someone helpfully decides to "straighten things out".

Heh, heh ... I didn't let them "straighten out" anything
for nearly 40 years. Found a floppy set of Windows For
Workgroups the other day - KNEW I had those SOMEWHERE :-)

I'll have to see if I can install them on VirtualBox ...

Found a photo of my office done over 20 years ago ...
a lot of the same books still on the shelf.

Got my MS Access 1.x manual, my Turbo Pascal v1 manual
and IBM/MS Pascal manual. A 300 page VMS manual, a
VIC-20 programming guide, several books on PICs back when
the 16x series was top of the line. Lots of electronics
books, some of which include vacuum tube diagrams that
parallel the "newfangled" transistor circuits. Even
have an IBM-PC Technical Reference Manual (with all those
things "you don't need to know" ....

In any case, I practice the "archeological" filing
method ... older = deeper in the piles :-)

On 14/11/2023 23:58, Martin Gregorie wrote:
> On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
>
> X> $ purge foobar.txt
>>
> Yes, I remember those periodic purges.
>
> I did like the customisable editor too and, IIRD, the ability to attach
> customisations to file types. If there was an open source version of that
> editor I might even be using it still.
>

If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
SunOS, or possibly Solaris. So it is possible there is a version
floating about.

On Tue, 14 Nov 2023 22:31:20 -0500
"56d.1152" <56d.1152@ztq9.net> wrote:

> There's still a market for mainframes. McDonalds
> Corp does NOT run on a iPad. Worldwide biz,
> supply/financial logistics, soon you're using
> SERIOUS computing power and need a SERIOUS
> super-reliable/flexible OS to make it go. Wire a
> few of those big black IBM boxes together .....

I don't know about McDonald's but these days a lot of really big
systems run as a large (and variable) number of micro-services in
containers under Kubernetes. Scalability is the watchword today. Sometimes
they run on Z/OS machines (usually running Linux) otherwise they run on a
mix of blade servers (CPU and RAM tightly packed) and SAN storage (lots of
NVMe SSDs) connected with 40Gb or 100Gb ethernet. Infrastructure as a
service they call it.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On Wed, 15 Nov 2023 07:58:47 +0000
Pancho <Pancho.Jones@proton.me> wrote:

> On 14/11/2023 23:58, Martin Gregorie wrote:
> > On Tue, 14 Nov 2023 15:24:59 -0500, Arne Vajhøj wrote:
> >
> > X> $ purge foobar.txt
> >>
> > Yes, I remember those periodic purges.
> >
> > I did like the customisable editor too and, IIRD, the ability to attach
> > customisations to file types. If there was an open source version of
> > that editor I might even be using it still.
> >
>
> If you mean EVE based on Vax/TPU it was ported to Unix, circa ~1995,
> SunOS, or possibly Solaris. So it is possible there is a version
> floating about.

Apparently there's an emulation of EVE available for Emacs.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 11/15/2023 2:44 AM, Ahem A Rivet's Shot wrote:
> On Tue, 14 Nov 2023 22:31:20 -0500
> "56d.1152" <56d.1152@ztq9.net> wrote:
>> There's still a market for mainframes. McDonalds
>> Corp does NOT run on a iPad. Worldwide biz,
>> supply/financial logistics, soon you're using
>> SERIOUS computing power and need a SERIOUS
>> super-reliable/flexible OS to make it go. Wire a
>> few of those big black IBM boxes together .....
>
> I don't know about McDonald's but these days a lot of really big
> systems run as a large (and variable) number of micro-services in
> containers under Kubernetes. Scalability is the watchword today. Sometimes
> they run on Z/OS machines (usually running Linux) otherwise they run on a
> mix of blade servers (CPU and RAM tightly packed) and SAN storage (lots of
> NVMe SSDs) connected with 40Gb or 100Gb ethernet. Infrastructure as a
> service they call it.

Most run such workloads in AWS/Azure/GCP/OCI.

Arne