Discussion:
RX2800 i4 iLO 3 firmware
Add Reply
Rich Jordan
2021-06-17 23:18:51 UTC
Reply
Permalink
After an interesting time trying to locate the proper support pages for iLO 3 firmware update downloads for the above Integrity server, even when using google to search hpe, I'm asking here. Does anyone know if current firmware kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN file) to update the iLO on the Integrity server?

Thanks
Kenneth Randell
2021-06-18 00:22:37 UTC
Reply
Permalink
After an interesting time trying to locate the proper support pages for iLO 3 firmware update downloads for the above Integrity server, even when using google to search hpe, I'm asking here. Does anyone know if current firmware kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely different.

Are you looking for something like this?

https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
Rich Jordan
2021-06-18 22:48:06 UTC
Reply
Permalink
After an interesting time trying to locate the proper support pages for iLO 3 firmware update downloads for the above Integrity server, even when using google to search hpe, I'm asking here. Does anyone know if current firmware kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely different.
Are you looking for something like this?
https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
Don't think so, but we'd have to get the servers under support to get access to check since that appears to be a full firmware kit for blade servers, and so not a free download (as iLO updates used to be).

Maybe we can get to the real thing using hte customer's support account for their existing older integrity server. Again, right now, I'm only looking for iLO firmware, not system.

Thanks
Kenneth Randell
2021-06-19 01:00:56 UTC
Reply
Permalink
Post by Rich Jordan
After an interesting time trying to locate the proper support pages for iLO 3 firmware update downloads for the above Integrity server, even when using google to search hpe, I'm asking here. Does anyone know if current firmware kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely different.
Are you looking for something like this?
https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
Don't think so, but we'd have to get the servers under support to get access to check since that appears to be a full firmware kit for blade servers, and so not a free download (as iLO updates used to be).
Maybe we can get to the real thing using hte customer's support account for their existing older integrity server. Again, right now, I'm only looking for iLO firmware, not system.
Thanks
Sorry, I think I posted the link for the cloud system firmware bundles have everything for blade systems.. The latest rx2800 i4 firmware bundle I can find is here, but still requires a contract to download:

https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_54d0b9fdeb11460bbe83cd5ed9#tab-history
Rich Jordan
2021-06-21 15:13:47 UTC
Reply
Permalink
Post by Kenneth Randell
Post by Rich Jordan
After an interesting time trying to locate the proper support pages for iLO 3 firmware update downloads for the above Integrity server, even when using google to search hpe, I'm asking here. Does anyone know if current firmware kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely different.
Are you looking for something like this?
https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
Don't think so, but we'd have to get the servers under support to get access to check since that appears to be a full firmware kit for blade servers, and so not a free download (as iLO updates used to be).
Maybe we can get to the real thing using hte customer's support account for their existing older integrity server. Again, right now, I'm only looking for iLO firmware, not system.
Thanks
https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_54d0b9fdeb11460bbe83cd5ed9#tab-history
I don't recall that HP ever hid iLO firmware behind a paywall or made full firmware kits the only way to get ilo firmware.

The machines will be under support, but are not yet. Guess we wait.
Simon Clubley
2021-06-21 17:19:44 UTC
Reply
Permalink
Post by Rich Jordan
I don't recall that HP ever hid iLO firmware behind a paywall or made full firmware kits the only way to get ilo firmware.
The machines will be under support, but are not yet. Guess we wait.
IIRC, at one time, it was freely downloadable and then HPE restricted
firmware update access to supported contract/warranty customers.

Anyone feel free to correct me if I am wrong, but HPE did move to
lockdown access to firmware images that were once freely available IIRC.

For example, here's one I accessed at random:

https://support.hpe.com/hpesc/public/swd/detail?swItemId=ux-122918-1

Note how you are told you need to have an active warranty or support
agreement when you click the download button.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Hans Bachner
2021-06-21 21:36:25 UTC
Reply
Permalink
Post by Simon Clubley
Post by Rich Jordan
I don't recall that HP ever hid iLO firmware behind a paywall or made full firmware kits the only way to get ilo firmware.
The machines will be under support, but are not yet. Guess we wait.
IIRC, at one time, it was freely downloadable and then HPE restricted
firmware update access to supported contract/warranty customers.
Anyone feel free to correct me if I am wrong, but HPE did move to
lockdown access to firmware images that were once freely available IIRC.
https://support.hpe.com/hpesc/public/swd/detail?swItemId=ux-122918-1
Note how you are told you need to have an active warranty or support
agreement when you click the download button.
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium
(or Alpha).

Hans.
Robert A. Brooks
2021-06-21 22:34:05 UTC
Reply
Permalink
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the firmware
that is on the system.
--
-- Rob
Dave Froble
2021-06-22 00:03:32 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.

Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Robert A. Brooks
2021-06-22 02:33:04 UTC
Reply
Permalink
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare with iLO,
if anything?
I wasn't clear in my response; I did not mean to draw a distinction between the
Proliant Intel vs. the Proliant AMD series.

iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385 (the
nomenclature is such that for the Proliant line, the xx5 variant is with an
AMD CPU).
--
-- Rob
Dave Froble
2021-06-22 03:39:40 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
I wasn't clear in my response; I did not mean to draw a distinction
between the Proliant Intel vs. the Proliant AMD series.
iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385
(the nomenclature is such that for the Proliant line, the xx5 variant is
with an
AMD CPU).
Since you're answering questions ...

:-)

Is the iLO an HPe thing, or do others use it, or something similar?

Does x86 VMS require an iLO?

Or something similar?

I'm aware that VSI is looking to the HPe Proliant systems, but I'm still
holding an old grudge because of the 386 FP fiasco, and more recently
against HP(e). To be fair, I guess I should also hold a grudge for AMD
not producing the motherboards that would work with Alpha, as I believe
they agreed to do.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-06-22 07:29:57 UTC
Reply
Permalink
Post by Dave Froble
Post by Robert A. Brooks
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
I wasn't clear in my response; I did not mean to draw a distinction
between the Proliant Intel vs. the Proliant AMD series.
iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385
(the nomenclature is such that for the Proliant line, the xx5 variant is
with an
AMD CPU).
Since you're answering questions ...
:-) >
Is the iLO an HPe thing, or do others use it, or something similar?
Does x86 VMS require an iLO?
Or something similar?
I'm aware that VSI is looking to the HPe Proliant systems, but I'm still
holding an old grudge because of the 386 FP fiasco, and more recently
against HP(e).  To be fair, I guess I should also hold a grudge for AMD not
producing the motherboards that would work with Alpha, as I believe they
agreed to do.
I think your questions already have answers available to everyone.

https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
chris
2021-06-22 10:23:03 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Robert A. Brooks
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for
Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
I wasn't clear in my response; I did not mean to draw a distinction
between the Proliant Intel vs. the Proliant AMD series.
iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385
(the nomenclature is such that for the Proliant line, the xx5 variant is
with an
AMD CPU).
Since you're answering questions ...
:-) >
Is the iLO an HPe thing, or do others use it, or something similar?
Does x86 VMS require an iLO?
Or something similar?
I'm aware that VSI is looking to the HPe Proliant systems, but I'm
still holding an old grudge because of the 386 FP fiasco, and more
recently against HP(e). To be fair, I guess I should also hold a
grudge for AMD not producing the motherboards that would work with
Alpha, as I believe they agreed to do.
I think your questions already have answers available to everyone.
https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
Most server vendors have an ilo equivalent now, even if not compatible,
though remote managaement tools provide support for multiple vendors.
Both Sun and IBM for example, have for possibly decades...
Dave Froble
2021-06-22 14:17:17 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Robert A. Brooks
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for
Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
I wasn't clear in my response; I did not mean to draw a distinction
between the Proliant Intel vs. the Proliant AMD series.
iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385
(the nomenclature is such that for the Proliant line, the xx5 variant is
with an
AMD CPU).
Since you're answering questions ...
:-) >
Is the iLO an HPe thing, or do others use it, or something similar?
Does x86 VMS require an iLO?
Or something similar?
I'm aware that VSI is looking to the HPe Proliant systems, but I'm
still holding an old grudge because of the 386 FP fiasco, and more
recently against HP(e). To be fair, I guess I should also hold a
grudge for AMD not producing the motherboards that would work with
Alpha, as I believe they agreed to do.
I think your questions already have answers available to everyone.
https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
Well, no. There is the question of "Does x86 VMS require an iLO?"
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-06-22 18:40:15 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Robert A. Brooks
Post by Dave Froble
Post by Robert A. Brooks
Post by Hans Bachner
Iirc most everything (but not all) for x86 (BIOS, ILO,
Windows-/Linux-/VMware-related) is freely available. Not so for
Itanium (or Alpha).
Yes, iLO and BIOS are freely available for X86, but not the rest of the
firmware that is on the system.
Competition can be a wonderful thing.
Not knowledgeable about newest servers, wonder what AMD has to compare
with iLO, if anything?
I wasn't clear in my response; I did not mean to draw a distinction
between the Proliant Intel vs. the Proliant AMD series.
iLO is motherboard CPU-agnostic; it's the same iLO for a DL380 and DL385
(the nomenclature is such that for the Proliant line, the xx5 variant is
with an
AMD CPU).
Since you're answering questions ...
:-) >
Is the iLO an HPe thing, or do others use it, or something similar?
Does x86 VMS require an iLO?
Or something similar?
I'm aware that VSI is looking to the HPe Proliant systems, but I'm
still holding an old grudge because of the 386 FP fiasco, and more
recently against HP(e).  To be fair, I guess I should also hold a
grudge for AMD not producing the motherboards that would work with
Alpha, as I believe they agreed to do.
I think your questions already have answers available to everyone.
https://en.wikipedia.org/wiki/HP_Integrated_Lights-Out
Well, no.  There is the question of "Does x86 VMS require an iLO?"
As far as I understand, iLO has nothing to do with the OS, it is a tool
to manage the server HW.
Dennis Boone
2021-06-22 17:56:50 UTC
Reply
Permalink
Post by Dave Froble
Is the iLO an HPe thing, or do others use it, or something similar?
iLO is the HP trade name for a remote management board. Dell calls it a
DRAC. Others have equivalent products. These boards predate the common
appearance of IPMI, BMC, WfM, etc on motherboards. I imagine current
implementations probably provide and/or are based on the industry
"standards".

Provided remote control services have long included serial console
redirection, kvm functionality, virtual media for booting / installing /
testing, reset button. Newer support includes full power management, a
service processor console for exploring and setting various things.

De
k***@gmail.com
2021-06-22 23:27:16 UTC
Reply
Permalink
-----Original Message-----
via Info-vax
Sent: June-22-21 2:57 PM
Subject: Re: [Info-vax] RX2800 i4 iLO 3 firmware
Post by Dave Froble
Is the iLO an HPe thing, or do others use it, or something similar?
iLO is the HP trade name for a remote management board. Dell calls it a DRAC.
Others have equivalent products. These boards predate the common
appearance of IPMI, BMC, WfM, etc on motherboards. I imagine current
implementations probably provide and/or are based on the industry
"standards".
Provided remote control services have long included serial console
redirection, kvm functionality, virtual media for booting / installing / testing,
reset button. Newer support includes full power management, a service
processor console for exploring and setting various things.
De
_______________________________________________
Out of band server management like ILO's, DRAC including remote power mgmt. strategies has been around for decades (early 1980's).

VAX Nautilus and Polarstar systems used external PRO-350/380 PC systems to manage (including Poff/Pon, searchable soft log files) VAX systems.

Bit of trivia - one Nautilus/Pstar console firmware fix involved changing the console command "H" for Help to require a minimum of two characters "HE".

Reason was that some would log into the console mode on a running system, type "H" for help and the running system would then immediately HALT.

(H = help or halt)

For those that remember the WW DEC VAX notesfiles, Atlant Schmidt was the key VAX PC350/380 console firmware developer. Excellent resource.

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Rich Jordan
2021-06-22 23:37:00 UTC
Reply
Permalink
Post by k***@gmail.com
-----Original Message-----
via Info-vax
Sent: June-22-21 2:57 PM
Subject: Re: [Info-vax] RX2800 i4 iLO 3 firmware
Post by Dave Froble
Is the iLO an HPe thing, or do others use it, or something similar?
iLO is the HP trade name for a remote management board. Dell calls it a DRAC.
Others have equivalent products. These boards predate the common
appearance of IPMI, BMC, WfM, etc on motherboards. I imagine current
implementations probably provide and/or are based on the industry
"standards".
Provided remote control services have long included serial console
redirection, kvm functionality, virtual media for booting / installing / testing,
reset button. Newer support includes full power management, a service
processor console for exploring and setting various things.
De
_______________________________________________
Out of band server management like ILO's, DRAC including remote power mgmt. strategies has been around for decades (early 1980's).
VAX Nautilus and Polarstar systems used external PRO-350/380 PC systems to manage (including Poff/Pon, searchable soft log files) VAX systems.
Bit of trivia - one Nautilus/Pstar console firmware fix involved changing the console command "H" for Help to require a minimum of two characters "HE".
Reason was that some would log into the console mode on a running system, type "H" for help and the running system would then immediately HALT.
(H = help or halt)
For those that remember the WW DEC VAX notesfiles, Atlant Schmidt was the key VAX PC350/380 console firmware developer. Excellent resource.
😊
Regards,
Kerry Main
Kerry dot main at starkgaming dot com
--
This email has been checked for viruses by AVG.
https://www.avg.com
Strictly HP, I have been able to download just the iLO firmware for any Proliant at no cost. Same with the online configurator. BIOS and other firmware as well as the complete spp for proliants has been behind a paywall for a long time now. RX firmware kits have also been paywalled but I had hopes (and I know in the past it was in fact this way) that _kust_ the ilo firmware itself was still freely downloadable.

Maybe HPe no longer GIF since they're not supporting VMS or other uses for the RX series any longer so decided to squeeze more dollars. Don't know.

Would the firmware BIN file from a Proliant iLO 3 work on an Integrity iLO 3?

Thanks
Rich
Robert A. Brooks
2021-06-23 00:05:39 UTC
Reply
Permalink
Post by Rich Jordan
Would the firmware BIN file from a Proliant iLO 3 work on an Integrity iLO
Are you seriously still asking that question?

The first reply to your initial post answered that pretty clearly.

Subject: Re: RX2800 i4 iLO 3 firmware
Date: Thu, 17 Jun 2021 17:22:37 -0700 (PDT)
From: Kenneth Randell <***@gmail.com>
Newsgroups: comp.os.vms
Post by Rich Jordan
After an interesting time trying to locate the proper support pages for iLO 3
firmware update downloads for the above Integrity server, even when using
google to search hpe, I'm asking here. Does anyone know if current firmware
kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN
file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely
different.

Are you looking for something like this?

https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
--
-- Rob
Rich Jordan
2021-06-23 14:43:42 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by Rich Jordan
Would the firmware BIN file from a Proliant iLO 3 work on an Integrity iLO
Are you seriously still asking that question?
The first reply to your initial post answered that pretty clearly.
Subject: Re: RX2800 i4 iLO 3 firmware
Date: Thu, 17 Jun 2021 17:22:37 -0700 (PDT)
Newsgroups: comp.os.vms
Post by Rich Jordan
After an interesting time trying to locate the proper support pages for iLO 3
firmware update downloads for the above Integrity server, even when using
google to search hpe, I'm asking here. Does anyone know if current firmware
kits for a Proliant that uses an iLO 3 can be used (presumably just the BIN
file) to update the iLO on the Integrity server?
Thanks
The answer is NO. The firmware kits for Proliant and Integrity are completely different.
Are you looking for something like this?
https://support.hpe.com/hpesc/public/swd/detail?swItemId=MTX_9f4d133ebf704e849625019793#tab-history
--
-- Rob
Rob,
sorry if I offended. The links posted in response were for an Integrity system firmware kit that included iLO firmware, not just the iLO firmware package. As such, the context was mixed; clearly the overall firmware kits for the systems would have to be different. You also posted later "iLO is motherboard CPU-agnostic"; I wasn't clear if that crossed architectures or not but the context there only mentioned AMD vs Intel so guess it doesn't.

I hadn't quite given up on finding the standalone ilo firmware that lists as supported for Integrity or VMS/HPUX. Apparently that was pointless.

Thank you for confirming. We're waiting on formal support being added so everything related to this hardware is on hold.

HPe certainly makes this more difficult than it should be.

Thanks.
Robert A. Brooks
2021-06-23 15:05:53 UTC
Reply
Permalink
Rob, sorry if I offended.
No, I should not have responded in such a fashion; I was in a bit of a cranky mood.
The links posted in response were for an
Integrity system firmware kit that included iLO firmware, not just
the iLO firmware package. As such, the context was mixed; clearly
the overall firmware kits for the systems would have to be different.
You also posted later "iLO is motherboard CPU-agnostic"; I wasn't
clear if that crossed architectures or not but the context there only
mentioned AMD vs Intel so guess it doesn't.
My guess is that if you attempted to upload the wrong firmware, it would fail the
header checksum validation, so it's not as if you could brick the iLO itself with
the wrong firmware.

However, it's just a guess.

When not paying enough attention to what I was doing, I have attempted to update an iLO3 with
iLO4 firmware, and that does fail the header validation.
--
-- Rob
Dave Froble
2021-06-23 15:17:08 UTC
Reply
Permalink
Post by Rich Jordan
HPe certainly makes this more difficult than it should be.
HPe doesn't care about you, just your money ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-06-23 16:02:35 UTC
Reply
Permalink
Post by Dave Froble
Post by Rich Jordan
HPe certainly makes this more difficult than it should be.
It's long been difficult to find stuff at DEC, Compaq, HP, and HPE. At
IBM and Dell too, for that matter. That's seemingly been a hallmark of
enterprise computing. Simple is hard. Clarity is hard.
Post by Dave Froble
HPe doesn't care about you, just your money ...
There are alternatives for ~all IT hardware vendors. Among others,
SuperMicro for servers, Brother for printers, and Synology for servers
and NAS.

The Synology packages have replaced a number of purpose-dedicated local
servers: https://www.synology.com/en-us/dsm/packages

OpenVMS V9.2 is going to shuffle a whole lot of longstanding
assumptions around hardware, too. The x86-64 upgrade cycle tends to be
much shorter—three to five years—than that of Alpha or Itanium servers.
And hypervisor guest support means we'll be seeing massively overloaded
OpenVMS guests co-resident on too little hardware with ongoing efforts
toward server constipation, err, toward server consolidation.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2021-06-23 16:58:40 UTC
Reply
Permalink
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
Outboard console was more of a necessity back then, as the earliest VAX
itself was comparatively, well, stupid.

The VAX-11/780 operated as a peripheral of an LSI-11, in a manner of
consideration. Boot the LSI, which then loads and boots Star and
Starlet.

Later VAX systems got somewhat smarter.

Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Post by k***@gmail.com
VAX Nautilus and Polarstar systems used external PRO-350/380 PC systems
to manage (including Poff/Pon, searchable soft log files) VAX systems.
The Nautilus family used Pro 350 and Pro 380 hardware, with those boxes
renamed as VAX console. The Polarstar family used a MicroVAX II as the
console. The MicroVAX was one of the distinguishing features of
Polarstar. VAX-11/780 used an LSI-11, as mentioned above. The VAX 9000
service processor unit comprised of 4 MicroVAX II processors. Alpha
eventually added RCM and RMC hardware outboard, all the way up to the
entirely gonzo server management network present within the
Marvel-class AlphaServer boxes; AlphaServer GS1280, etc.

IBM used last year's mainframe model as this year's channel controller
as that old joke went, and analogous jokes about VAX consoles.

None of these VAX and Alpha consoles was supported for remote Ethernet
network access, with the gear supporting remote serial access at best.
Early on, this serial access was intended for DEC Field Service to dial
in (modems, remember those?) and diagnose the server.

Yes, some older sites did routinely use terminal servers as a
workaround for remote console access, or used a console app such as
VAXcluster Console System (VCS) or Minicom and serial cabling, or
screen/tmux, etc. And I've remotely tapped into the Marvel internal
network, as have others. These were wildly insecure, by present-day
standards.

HP and HPE iLO, Dell iDRAC, the SuperMicro BMC, and various other
available gear all substantially improve on what the older server
consoles could do, though. Particularly around remote management and
monitoring and automation, and with far better support for server
installation. And with better connection security. (Usually. Somewhat.
See below.)

For lower-end boxes, Intel vPro and AMD Pro management access is
available from various vendors.

iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept
isolated. There are exploits against these, including the CVE-2013-4786
vulnerability.

"There is no resolution to this issue. The authentication process for
the IPMI 2.0 specification mandates that the server send a salted SHA1
or MD5 hash of the requested user's password to the client, prior to
the client authenticating. The BMC returns the password hash for any
valid user account requested. This password hash can be broken using an
offline brute force or dictionary attack. Because this functionality is
a key part of the IPMI 2.0 specification, there is no way to fix the
problem without deviating from the IPMI 2.0 specification."

Meaning you will want to disable IPMI ( MP:CM> sa -lanipmi d ) if
you're not using it, and not on a constrained-access management network.

And another reason for isolation: iLO 2 and iLO 3 ssh security is badly
down-revision, which means connecting using something similar to this:
ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 ***@Server.Example.Com
--
Pure Personal Opinion | HoffmanLabs LLC
Hans Bachner
2021-06-23 19:51:55 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
[...]
Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Actually, there was the RMC (remote management console) on various
Alphas - I think starting around the AlphaServer 4100 and friends. It
also included remote power on/off among other things.

Given that this effort startet in the last millenium, the RMC was
accessed through a serial port (not via network as today). You could
connect this port to a DECserver and access the DECserver either locally
over the network or remotely via a modem.
Post by Stephen Hoffman
Post by k***@gmail.com
[...]
Hans.
Stephen Hoffman
2021-06-23 20:15:40 UTC
Reply
Permalink
Post by Hans Bachner
Post by Stephen Hoffman
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
[...]
Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Actually, there was the RMC (remote management console) on various
Alphas - I think starting around the AlphaServer 4100 and friends. It
also included remote power on/off among other things.
Given that this effort startet in the last millenium, the RMC was
accessed through a serial port (not via network as today). You could
connect this port to a DECserver and access the DECserver either
locally over the network or remotely via a modem.
Ah, an Alpha "RMC" you say?
Post by Hans Bachner
Post by Stephen Hoffman
... Alpha eventually added RCM and RMC hardware outboard, all the way
up to the entirely gonzo server management network present within the
Marvel-class AlphaServer boxes; AlphaServer GS1280, etc.
...None of these VAX and Alpha consoles was supported for remote
Ethernet network access, with the gear supporting remote serial access
at best. Early on, this serial access was intended for DEC Field
Service to dial in (modems, remember those?) and diagnose the server.
iLO was a server-management gearshift for a lot of OpenVMS sites.

Remote management of VAX, Alpha, and Integrity sans iLO was either
purchased, or often home-grown duct tape. Some of that duct tape used
the RMC, too.

An external, outboard, out-of-the-server-cabinet management console was
never anybody's preferred solution though, which is why it's all but
disappeared as a viable design for most modern servers; why it all went
embedded.

And an approach akin to RMC/RCM was reasonable for its serial-line era,
but the RMC/RCM was missing a NIC and its supporting infrastructure.
Which is what iLO, iDRAC, BMC, and other solutions provide.

For those here that do prefer their consoles with blinking lights:
https://obsolescence.wixsite.com/obsolescence/pidp-11 — it'd very
likely be possible to hook this PiDP-11 to an RMC too, if you wanted to
work at it.
--
Pure Personal Opinion | HoffmanLabs LLC
Jan-Erik Söderholm
2021-06-23 21:54:59 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
[...]
Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Actually, there was the RMC (remote management console) on various Alphas -
I think starting around the AlphaServer 4100 and friends. It also included
remote power on/off among other things.
Maybe RMC gave some additional functions compared with the basic console.
But I have successfuly managed our DS20e Alpha servers remotely by just
having access to the concole port using a terminal server for each server.
Including configuring the FC access to the corporate SAN system using
that "nice" WWIDMGR tool...
Given that this effort startet in the last millenium, the RMC was accessed
through a serial port (not via network as today). You could connect this
port to a DECserver and access the DECserver either locally over the
network or remotely via a modem.
Just as the console port itself. But of course, direct network access is
what everyone expects today...
Post by Stephen Hoffman
Post by k***@gmail.com
[...]
Hans.
Dave Froble
2021-06-24 00:50:32 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
Outboard console was more of a necessity back then, as the earliest VAX
itself was comparatively, well, stupid.
The VAX-11/780 operated as a peripheral of an LSI-11, in a manner of
consideration. Boot the LSI, which then loads and boots Star and Starlet.
Later VAX systems got somewhat smarter.
Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Well, it wasn't "management", but way back I recall a PDP-11 with a
device the Colorado support people could dial into.
Post by Stephen Hoffman
Post by k***@gmail.com
VAX Nautilus and Polarstar systems used external PRO-350/380 PC
systems to manage (including Poff/Pon, searchable soft log files) VAX
systems.
The Nautilus family used Pro 350 and Pro 380 hardware, with those boxes
renamed as VAX console. The Polarstar family used a MicroVAX II as the
console. The MicroVAX was one of the distinguishing features of
Polarstar. VAX-11/780 used an LSI-11, as mentioned above. The VAX 9000
service processor unit comprised of 4 MicroVAX II processors. Alpha
eventually added RCM and RMC hardware outboard, all the way up to the
entirely gonzo server management network present within the Marvel-class
AlphaServer boxes; AlphaServer GS1280, etc.
IBM used last year's mainframe model as this year's channel controller
as that old joke went, and analogous jokes about VAX consoles.
None of these VAX and Alpha consoles was supported for remote Ethernet
network access, with the gear supporting remote serial access at best.
Early on, this serial access was intended for DEC Field Service to dial
in (modems, remember those?) and diagnose the server.
I do remember that ...
Post by Stephen Hoffman
Yes, some older sites did routinely use terminal servers as a workaround
for remote console access, or used a console app such as VAXcluster
Console System (VCS) or Minicom and serial cabling, or screen/tmux, etc.
And I've remotely tapped into the Marvel internal network, as have
others. These were wildly insecure, by present-day standards.
HP and HPE iLO, Dell iDRAC, the SuperMicro BMC, and various other
available gear all substantially improve on what the older server
consoles could do, though. Particularly around remote management and
monitoring and automation, and with far better support for server
installation. And with better connection security. (Usually. Somewhat.
See below.)
For lower-end boxes, Intel vPro and AMD Pro management access is
available from various vendors.
iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept isolated.
There are exploits against these, including the CVE-2013-4786
vulnerability.
"There is no resolution to this issue. The authentication process for
the IPMI 2.0 specification mandates that the server send a salted SHA1
or MD5 hash of the requested user's password to the client, prior to the
client authenticating. The BMC returns the password hash for any valid
user account requested. This password hash can be broken using an
offline brute force or dictionary attack. Because this functionality is
a key part of the IPMI 2.0 specification, there is no way to fix the
problem without deviating from the IPMI 2.0 specification."
Meaning you will want to disable IPMI ( MP:CM> sa -lanipmi d ) if you're
not using it, and not on a constrained-access management network.
And another reason for isolation: iLO 2 and iLO 3 ssh security is badly
ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-24 15:29:23 UTC
Reply
Permalink
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
Depends.

You connect to ILO and go to console.

The console works like a console.

Do you call that use ILO or not?

Arne
Dave Froble
2021-06-24 16:41:28 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
Depends.
You connect to ILO and go to console.
The console works like a console.
Do you call that use ILO or not?
Arne
Yes ...
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-24 18:13:02 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
Depends.
You connect to ILO and go to console.
The console works like a console.
Do you call that use ILO or not?
Yes ...
Maybe you should just think of it like:

VT320----(cable)----VAX or Alpa

terminal emulator----(SSH----ILO)----Itanium

:-)

Arne
Stephen Hoffman
2021-06-24 17:19:49 UTC
Reply
Permalink
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.

Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.

If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.

If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.

For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-06-24 18:44:33 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development. The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.

Didn't want the damn thing, but, I need to do the research.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Bill Gunshannon
2021-06-24 19:10:22 UTC
Reply
Permalink
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?

bill
Craig A. Berry
2021-06-24 19:17:05 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile. v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
Jan-Erik Söderholm
2021-06-24 19:29:03 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile.  v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
*Some* compilers. And, if I'm not wrong, not the compiler David use.
Bill Gunshannon
2021-06-24 20:29:57 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha
doesn't get the latest stuff, and, I really need to be using the
latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile.  v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
*Some* compilers. And, if I'm not wrong, not the compiler David use.
That's too bad. I wouldn't wish an Itanic on my worst enemy.

bill
Chris Townley
2021-06-24 19:56:07 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile.  v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
You are hopeful!
--
Chris
Stephen Hoffman
2021-06-24 20:49:37 UTC
Reply
Permalink
Post by Craig A. Berry
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile. v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
There are seemingly no native compilers in V9.1.

At least one cross-compiler—BASIC—is seemingly arriving subsequent to
the V9.1 release, and the native compilers are also mostly (entirely?)
arriving subsequent to V9.1.
Post by Craig A. Berry
Native compilers with LLVM backend code generator: BLISS, XMACRO,
Pascal, BASIC, COBOL, FORTRAN [sic, presumably], C, C++
https://vmssoftware.com/about/roadmap/
--
Pure Personal Opinion | HoffmanLabs LLC
Craig A. Berry
2021-06-24 21:25:48 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Craig A. Berry
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile.  v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
There are seemingly no native compilers in V9.1.
You're right, not on initial release. But some will appear as updates
to v9.1 and before v9.2 if I'm understanding what I'm reading.
Post by Stephen Hoffman
At least one cross-compiler—BASIC—is seemingly arriving subsequent to
the V9.1 release, and the native compilers are also mostly (entirely?)
arriving subsequent to V9.1.
Post by Craig A. Berry
Native compilers with LLVM backend code generator: BLISS, XMACRO,
Pascal, BASIC, COBOL, FORTRAN [sic, presumably], C, C++
https://vmssoftware.com/about/roadmap/
Dave Froble
2021-06-24 22:40:39 UTC
Reply
Permalink
Post by Craig A. Berry
Post by Bill Gunshannon
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development. The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
There are no native compilers in v9.0 so he'd still need an itanic to
cross-compile. v9.1 with native compilers is due 2021H1, i.e. within
the next week or so, assuming it's on time.
I didn't submit my special request on the back of a $100 bill, so Basic
will probably be the last compiler released ...

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2021-06-24 22:38:11 UTC
Reply
Permalink
Post by Bill Gunshannon
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development. The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
bill
Not in the mood to do any testing of pre-release stuff.

I need to develop a better method of handling lots of socket connect
requests. I also need to see if my ideas will work Ok.

Current thoughts are a single listener that validates requests, accepts
the connection, and passes it off to a worker process, then drops it's
own connection to the socket. Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-06-25 08:48:18 UTC
Reply
Permalink
Post by Dave Froble
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development.  The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
bill
Not in the mood to do any testing of pre-release stuff.
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
How many are "lots of"?
Post by Dave Froble
Current thoughts are a single listener that validates requests, accepts the
connection, and passes it off to a worker process, then drops it's own
connection to the socket.  Involves some inter-process communications.
Listener might get rather busy, but will spend little time on each request.
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?

For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.

The WASD server is very stable. Mostly starts at boot and runs until
you reboot or shutdown. From our production box:

$ sh sys/proc=ht*
OpenVMS V8.4-2L2 25-JUN-2021 10:34:28.60 Uptime 802 17:00:25
Pid Process Name State pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36199885 0 00:44:26.89 10693 661
$


$ sh proc/id=00000452/acc

25-JUN-2021 10:34:46.99 User: HTTP$SERVER Process ID: 00000452
Node: HV06 Process name: "HTTPd:80"

Accounting information:
Buffered I/O count: 32823260 Peak working set size: 12464
Direct I/O count: 3376625 Peak virtual size: 216496
Page faults: 10693 Mounted volumes: 0
Images activated: 29
Elapsed CPU time: 0 00:44:26.89
Connect time: 802 18:40:12.00

As you can see, it is the same "connect time" for the WASD server
as the "Uptime" for thr system.

$ write sys$output f$getsyi("boottime")
14-APR-2019 15:50:45.00
$


If I access one of our web addresses, I get a "worker process":


$ sh sys/proc=ht*
OpenVMS V8.4-2L2 6 25-JUN-2021 10:36:04.35 Uptime 802 17:02:00
Pid Process Name State Pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36200066 0 00:44:26.91 10693 661
000BF940 HTTPd:80-590 HIB 2 5761 0 00:00:03.35 6313 3426 M
$

The worker process stays alive for a configured time so the next
access is faster without any process startup. IF the worker process
has an active session when the next request arrives, a secons process
is started. All automatically handled by WASD.

In this case, the worker process is running a Python script, but it could
be any application writen in any language, of course. Probably with a
C-wrapper for the WASD CGI APIs.

I do not understand why anyone would prefer to write all this from scratch.

Regards, Jan-Erik.
Arne Vajhøj
2021-06-25 12:44:58 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket.  Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?
For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.
A standard web server is great if the protocol is HTTP.

For something custom TCP not so much. And from last time this
came up I think David is on custom TCP communication.

If HTTP and web server then the choice is between a general purpose
web server or something designed for being embedded in the application.

If general purpose web server then WASD is one of the
possibilities.

Arne
Dave Froble
2021-06-25 13:12:18 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Bill Gunshannon
Post by Dave Froble
Post by Stephen Hoffman
Post by Dave Froble
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development. The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
bill
Not in the mood to do any testing of pre-release stuff.
I need to develop a better method of handling lots of socket connect
requests. I also need to see if my ideas will work Ok.
How many are "lots of"?
That is sort of undefined at this time. Historically, the usage has
continued to rise. Not sure what it could rise to. So far we've seen
maybe 20K per hour at times.

Doesn't really matter, what I'm looking at is how to do it as well as
possible. Then let the usage attempt to catch up.
Post by Jan-Erik Söderholm
Post by Dave Froble
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket. Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?
Clients use a protocol we've designed and implemented. The source of
connection requests doesn't matter. Some are from VMS, others from
various types of clients.
Post by Jan-Erik Söderholm
For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.
No, WASD will not satisfy our requirements. It's not just accepting
connections. It is very specific apps that handle the requests. One of
the requirements is identifying the incoming request as valid as early
as possible. Failure at this point will immediately terminate the
connection.

WASD is a "jack of all trades" type of app, and does that reasonably
well. What we require is a specialist, for various reasons.
Post by Jan-Erik Söderholm
The WASD server is very stable. Mostly starts at boot and runs until
$ sh sys/proc=ht*
OpenVMS V8.4-2L2 25-JUN-2021 10:34:28.60 Uptime 802 17:00:25
Pid Process Name State pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36199885 0 00:44:26.89 10693 661
$
$ sh proc/id=00000452/acc
25-JUN-2021 10:34:46.99 User: HTTP$SERVER Process ID: 00000452
Node: HV06 Process name: "HTTPd:80"
Buffered I/O count: 32823260 Peak working set size: 12464
Direct I/O count: 3376625 Peak virtual size: 216496
Page faults: 10693 Mounted volumes: 0
Images activated: 29
Elapsed CPU time: 0 00:44:26.89
Connect time: 802 18:40:12.00
As you can see, it is the same "connect time" for the WASD server
as the "Uptime" for thr system.
$ write sys$output f$getsyi("boottime")
14-APR-2019 15:50:45.00
$
$ sh sys/proc=ht*
OpenVMS V8.4-2L2 6 25-JUN-2021 10:36:04.35 Uptime 802 17:02:00
Pid Process Name State Pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36200066 0 00:44:26.91 10693 661
000BF940 HTTPd:80-590 HIB 2 5761 0 00:00:03.35 6313 3426 M
$
The worker process stays alive for a configured time so the next
access is faster without any process startup. IF the worker process
has an active session when the next request arrives, a secons process
is started. All automatically handled by WASD.
In this case, the worker process is running a Python script, but it could
be any application writen in any language, of course. Probably with a
C-wrapper for the WASD CGI APIs.
I do not understand why anyone would prefer to write all this from scratch.
One size does not fit all.

And, it is the sort of thing I enjoy doing. What we're doing now is
sort of butt ugly, at least I think so, but it is so far getting the job
done. Though we've had to do some tweeking to handle increasing
activity. I'm looking to do better, and hopefully to be able to handle
many more connection requests. For our customers, it seems that
internet communications is replacing most of the previous activity.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
chris
2021-06-25 14:02:22 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Bill Gunshannon
Post by Stephen Hoffman
Apparently I'm getting an itanic on Friday. Do I have to use iLO and
such, or, can I ignore tham?
That's your call.
Around here, I'd want to configure and connect the iLO to the network,
yes. With any Integrity server. Regardless of the intended usage of the
Integrity server.
If this Integrity server includes graphics hardware and a graphics
display (that via separate controller, or via the iLO), that'll likely
be the primary usage, and not the iLO network-connected serial console.
If using this Integrity server as a remote server with interactive
sessions—traditional timesharing, not graphics—then the iLO can be one
of the various network connections, or can be ignored.
For a development-only system, the iLO is akin to a backup. Handy to
have when something goes wrong, also handy for upgrades and for
restarting the host and for restarting the network stack, but probably
not used heavily otherwise.
I need to do some TCP/IP research and development. The Alpha doesn't
get the latest stuff, and, I really need to be using the latest stuff.
Didn't want the damn thing, but, I need to do the research.
Can't you get involved in the "Early Implementer" stuff with VSI
and do your research on an X86-64 version?
bill
Not in the mood to do any testing of pre-release stuff.
I need to develop a better method of handling lots of socket connect
requests. I also need to see if my ideas will work Ok.
How many are "lots of"?
That is sort of undefined at this time. Historically, the usage has
continued to rise. Not sure what it could rise to. So far we've seen
maybe 20K per hour at times.
Doesn't really matter, what I'm looking at is how to do it as well as
possible. Then let the usage attempt to catch up.
Post by Jan-Erik Söderholm
Post by Dave Froble
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket. Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?
Clients use a protocol we've designed and implemented. The source of
connection requests doesn't matter. Some are from VMS, others from
various types of clients.
Post by Jan-Erik Söderholm
For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.
No, WASD will not satisfy our requirements. It's not just accepting
connections. It is very specific apps that handle the requests. One of
the requirements is identifying the incoming request as valid as early
as possible. Failure at this point will immediately terminate the
connection.
WASD is a "jack of all trades" type of app, and does that reasonably
well. What we require is a specialist, for various reasons.
Post by Jan-Erik Söderholm
The WASD server is very stable. Mostly starts at boot and runs until
$ sh sys/proc=ht*
OpenVMS V8.4-2L2 25-JUN-2021 10:34:28.60 Uptime 802 17:00:25
Pid Process Name State pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36199885 0 00:44:26.89 10693 661
$
$ sh proc/id=00000452/acc
25-JUN-2021 10:34:46.99 User: HTTP$SERVER Process ID: 00000452
Node: HV06 Process name: "HTTPd:80"
Buffered I/O count: 32823260 Peak working set size: 12464
Direct I/O count: 3376625 Peak virtual size: 216496
Page faults: 10693 Mounted volumes: 0
Images activated: 29
Elapsed CPU time: 0 00:44:26.89
Connect time: 802 18:40:12.00
As you can see, it is the same "connect time" for the WASD server
as the "Uptime" for thr system.
$ write sys$output f$getsyi("boottime")
14-APR-2019 15:50:45.00
$
$ sh sys/proc=ht*
OpenVMS V8.4-2L2 6 25-JUN-2021 10:36:04.35 Uptime 802 17:02:00
Pid Process Name State Pri I/O CPU Page flts Pages
00000452 HTTPd:80 HIB 4 36200066 0 00:44:26.91 10693 661
000BF940 HTTPd:80-590 HIB 2 5761 0 00:00:03.35 6313 3426 M
$
The worker process stays alive for a configured time so the next
access is faster without any process startup. IF the worker process
has an active session when the next request arrives, a secons process
is started. All automatically handled by WASD.
In this case, the worker process is running a Python script, but it could
be any application writen in any language, of course. Probably with a
C-wrapper for the WASD CGI APIs.
I do not understand why anyone would prefer to write all this from scratch.
One size does not fit all.
And, it is the sort of thing I enjoy doing. What we're doing now is sort
of butt ugly, at least I think so, but it is so far getting the job
done. Though we've had to do some tweeking to handle increasing
activity. I'm looking to do better, and hopefully to be able to handle
many more connection requests. For our customers, it seems that internet
communications is replacing most of the previous activity.
Don't know about vms, but if you are running inetd, that multiplexes
requests and spawns a new thread for that request and port number. A
bit of added code to limit number of requests, with any excess just
dropped...

Chris
Arne Vajhøj
2021-06-25 14:30:08 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
How many are "lots of"?
That is sort of undefined at this time.  Historically, the usage has
continued to rise.  Not sure what it could rise to.  So far we've seen
maybe 20K per hour at times.
20K per hour is 333 per minute or 5.5 per second.

That should be manageable.

100 ms sessions => 1 worker
1 s sessions => 10 workers
10 s sessions => 100 workers
Post by Jan-Erik Söderholm
Post by Dave Froble
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket.  Involves some inter-process
communications.  Listener might get rather busy, but will spend little
time on each request.
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?
Clients use a protocol we've designed and implemented.  The source of
connection requests doesn't matter.  Some are from VMS, others from
various types of clients.
Post by Jan-Erik Söderholm
For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above
is just a description of how WASD works.
No, WASD will not satisfy our requirements.  It's not just accepting
connections.  It is very specific apps that handle the requests.  One of
the requirements is identifying the incoming request as valid as early
as possible.  Failure at this point will immediately terminate the
connection.
WASD is  a "jack of all trades" type of app, and does that reasonably
well.  What we require is a specialist, for various reasons.
One size does not fit all.
95% is HTTP today, but that leaves 5% for everything else.

Non-HTTP approaches are still seen.

If you have a requirement to be easily accessible from multiple
languages then then you could look at Thrift.

I still believe that a multi-threaded listener doing IPC with
workers is the right design.

The workers can be VMS Basic.

But you will need something else for the listener.
  For our customers, it seems that
internet communications is replacing most of the previous activity.
This internet thing seems to be staying around.

:-) :-) :-)

Arne
Simon Clubley
2021-06-25 17:40:52 UTC
Reply
Permalink
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with
workers is the right design.
The workers can be VMS Basic.
But you will need something else for the listener.
We know VMS Basic is no good for normal multi-threaded coding.

Is it any good at AST coding ? If so, instead of a multi-threaded listener,
perhaps an AST based listener could be used to handle the workers instead.

BTW, David, just how noisy _is_ your new Itanium ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Chris Townley
2021-06-25 18:28:16 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with
workers is the right design.
The workers can be VMS Basic.
But you will need something else for the listener.
We know VMS Basic is no good for normal multi-threaded coding.
Is it any good at AST coding ? If so, instead of a multi-threaded listener,
perhaps an AST based listener could be used to handle the workers instead.
BTW, David, just how noisy _is_ your new Itanium ? :-)
Simon.
VMS Basic is fine with ASTs - we had loads of code that used them
--
Chris
Dave Froble
2021-06-25 19:07:01 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with
workers is the right design.
The workers can be VMS Basic.
But you will need something else for the listener.
We know VMS Basic is no good for normal multi-threaded coding.
Is it any good at AST coding ? If so, instead of a multi-threaded listener,
perhaps an AST based listener could be used to handle the workers instead.
ASTs work just fine with Basic.
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2021-06-25 20:06:11 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
How many are "lots of"?
That is sort of undefined at this time.  Historically, the usage has
continued to rise.  Not sure what it could rise to.  So far we've seen
maybe 20K per hour at times.
20K per hour is 333 per minute or 5.5 per second.
That should be manageable.
100 ms sessions => 1 worker
1 s sessions => 10 workers
10 s sessions => 100 workers
5.5 requests per second might be sustainable on a Raspberry Pi
(discussions of storage aside), and would trivial for an Apple Mac
mini. An HPE Integrity server with a decently-modern SSD I/O subsystem
would be snoozing.

A Mac mini with a chunk of a petabyte of fast RAID storage is feasible
to configure, too.

But as for the connection rate, that's not how many of these situations
work out of course. App loads tend to have spikes. And that's why we
usually end up over-provisioned.
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
Post by Dave Froble
Current thoughts are a single listener that validates requests, accepts
the connection, and passes it off to a worker process, then drops it's
own connection to the socket.  Involves some inter-process
communications.  Listener might get rather busy, but will spend little
time on each request.
On OpenVMS, I'd tend to use the auxiliary server (OpenVMS inetd
internet daemon), and let the network spin up workers.

Otherwise, you're re-implementing connection hand-off and that's ugly
on OpenVMS with TCP, and uglier with SSL, or you're starting up a
second connection for not a whole lot of gain.

This is where message queuing can be handy, but that tends to shift the
underlying app design around somewhat.
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
How are the clients deigned? Calls from Javascript running in browsers?
Are the clients your own applications too?
Clients use a protocol we've designed and implemented.  The source of
connection requests doesn't matter.  Some are from VMS, others from
various types of clients.
Pretty typical of established OpenVMS apps, more than a few of which
had app predecessors using DECnet connections.
Post by Arne Vajhøj
Post by Jan-Erik Söderholm
For the usual HTTP (and everything related to that) based communication
WASD will provide most of what you need out of the box. Have you yet
looked at WASD? What you describe as your "current thoughts" above is
just a description of how WASD works.
No, WASD will not satisfy our requirements.  It's not just accepting
connections.  It is very specific apps that handle the requests.  One
of the requirements is identifying the incoming request as valid as
early as possible.  Failure at this point will immediately terminate
the connection.
One variation involves having the client direct the connection to the
appropriate server, rather than the server trying to do load balancing
or dispatching directly.

This client-assisted dispatching might be configured or compiled in, or
it might be something akin to Portmapper, or it can be a map downloaded
at initial connection and then refreshed periodically or as needed.

Message queuing would be a different and somewhat newer approach. VSI
has ported message queuing frameworks, though there'd likely need to be
jackets added to allow easier access from BASIC.
Post by Arne Vajhøj
WASD is  a "jack of all trades" type of app, and does that reasonably
well.  What we require is a specialist, for various reasons.
One size does not fit all.
95% is HTTP today, but that leaves 5% for everything else.
HTTPS is very common, yes. Downside on OpenVMS is that REST support
stinks in most of the established OpenVMS languages and frameworks, and
support is ~nonexistent within OpenVMS itself.

I've ported libwww a few times, and there are undoubtedly other ports
and other frameworks around.
Post by Arne Vajhøj
Non-HTTP approaches are still seen.
Particularly for established app activities, and for cases where REST
doesn't fit well.
Post by Arne Vajhøj
If you have a requirement to be easily accessible from multiple
languages then then you could look at Thrift.
Which would entail porting Apache Thrift to OpenVMS, of course.
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with workers
is the right design.
OpenVMS doesn't do threads all that well.

BASIC does just fine with ASTs (two threads, one core), but I'd want a
careful look at the load trends and the peaks before committing to
using ASTs. And I wouldn't prefer it.

OpenVMS does offer KP Threads, but I've not met production apps mixing
KP threads and BASIC. It's likely possible, just not something I've
seen or used from BASIC.
Post by Arne Vajhøj
The workers can be VMS Basic.
But you will need something else for the listener.
BASIC tends to use the $qio or $io_perform interface, not the sockets.
Or there's the auxiliary server (inetd), which then deals with starting
up processes on request.
Post by Arne Vajhøj
  For our customers, it seems that internet communications is replacing
most of the previous activity.
Servers disappearing further into the background, with fewer or no
direct logins, and with the front-end UI handled either in a web
browser or in a dedicated client app, is increasingly common, yes.
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with workers
is the right design.
The workers can be VMS Basic.
But you will need something else for the listener.
We know VMS Basic is no good for normal multi-threaded coding.
OpenVMS itself isn't all that great at multi-threaded code, having
written a whole lot of it over the years.

OpenVMS threading support here is pre-millennial, in terms of
frameworks and language support. Aside from some existing
underpinnings; KP Threads, or ASTs with two threads, one core. Or
pthreads for C and C++ and (presumably) Rust if/when.

Which means more than a few cases of writing interlocked queue
message-passing, or other similar home-grown mechanisms.

libdispatch/GCD or similar multi-threading support never made it over,
short of porting or re-creating it yourself.
Post by Arne Vajhøj
Is it any good at AST coding ? If so, instead of a multi-threaded
listener, perhaps an AST based listener could be used to handle the
workers instead.
BASIC does ASTs just fine. I have piles of BASIC code around using
that, going back to network servers running DECnet, and with "more
recent" network servers running IP and SSL.

TL;DR: I'd run a prototype to see how well a pool of server processes
worked as a solution, with auxiliary server (inetd) as the initial
design. This if message queuing isn't feasible.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2021-06-25 23:26:19 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Post by Dave Froble
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket.  Involves some
inter-process communications.  Listener might get rather busy, but
will spend little time on each request.
This is where message queuing can be handy, but that tends to shift the
underlying app design around somewhat.
If async is OK *and* of the infrastructure footprint of the message
queue is OK, then that could be a great solution.

client_xxx put task in /queue/precheck
listener read task from /queue/precheck
ok => put task in /queue/task
notok => put error in /queue/client_xxx
worker read task from /queue/task, process and put result in
/queue/client_xxx
Post by Stephen Hoffman
Post by Arne Vajhøj
WASD is  a "jack of all trades" type of app, and does that reasonably
well.  What we require is a specialist, for various reasons.
One size does not fit all.
95% is HTTP today, but that leaves 5% for everything else.
HTTPS is very common, yes. Downside on OpenVMS is that REST support
stinks in most of the established OpenVMS languages and frameworks, and
support is ~nonexistent within OpenVMS itself.
In all fairness REST support stinks in those languages on other
platforms as well.

The REST world is dominated by languages less than 30 years old.

But Java, Python and PHP are available on VMS.
Post by Stephen Hoffman
Post by Arne Vajhøj
Non-HTTP approaches are still seen.
Particularly for established app activities, and for cases where REST
doesn't fit well.
Post by Arne Vajhøj
If you have a requirement to be easily accessible from multiple
languages then then you could look at Thrift.
Which would entail porting Apache Thrift to OpenVMS, of course.
For the language used. Which may be a small or big task depending
on what language.
Post by Stephen Hoffman
Post by Arne Vajhøj
I still believe that a multi-threaded listener doing IPC with workers
is the right design.
OpenVMS doesn't do threads all that well.
Doesn't pthreads do what it is supposed to do?
Post by Stephen Hoffman
OpenVMS does offer KP Threads, but I've not met production apps mixing
KP threads and BASIC.  It's likely possible, just not something I've
seen or used from BASIC.
Why not pthreads?

Standard.
Post by Stephen Hoffman
OpenVMS threading support here is pre-millennial, in terms of frameworks
and language support. Aside from some existing underpinnings; KP
Threads, or ASTs with two threads, one core. Or pthreads for C and C++
and (presumably) Rust if/when.
Which means more than a few cases of writing interlocked queue
message-passing, or other similar home-grown mechanisms.
libdispatch/GCD or similar multi-threading support never made it over,
short of porting or re-creating it yourself.
Nothing wrong with a basic thread model.

It is not new, but its usage are quite well-known.

Need to sync? pthread_mutex_t, pthread_mutex_lock
and pthread_mutex_unlock.

Arne
John Reagan
2021-06-26 01:07:18 UTC
Reply
Permalink
Sorry for the late response, I was on the road all day. Typing this now from scenic Hagerstown Maryland on my way to visit my sister for a week+

BASIC. There are several reasons why BASIC is lagging....

The RTL LOVES to walk the stack. We found a bug in one of the LIB$X86 Calling Standard routines that no other language found. Just printing a string causes the RTL to walk up the stack back to the routine that literally just called the RTL.

The compiler and RTL LOVE floating point. Printing an integer involves converting it to a floating point, converting that to a string, and printing everything to the left of the decimal point. And even with the default being IEEE, we found that Itanium BASIC still wants to use VAX floating.

And we found some other bugs in the RTL (like one routine passing the address of short to another routine that wrote a longword value).

BASIC was [ab]using a GEM interface to place stack allocated variables at known offsets on the stack frame. No other frontend does that. We do provide that feature for static variables for BLISS. We didn't know about BASIC's stack dependency until nothing worked! G2L has to collect all of the different GEM stack variables, combine them into a single 'container' variable to give to LLVM and then convert all of the references into offsets in the container. Getting the debug info right will be a nightmare and describing all the jiggery pokery to the LLVM optimizer might not be 100%.


Native compilers. Yes, at one time the existence of native compilers was tied to the definition of V9.1, but that isn't true anymore. Compilers (well, other than Macro) are layered products, not part of the OS. [V9.1 doesn't contain a native Macro either.]

We have a native LLVM, libcxx, etc. on x86 (bootstrapped from Linux). We have a native clang (with only a few OpenVMS'isms) on x86. It is wobbly but we're working through it. Much has involved clang treating "long" as 64-bits but the RTL headers and code believing that "long" is only 32-bits. As I've mentioned before, we have to get the RTL to deal with both. Doing RTL name prefixing/mapping involves finding the right places in the clang source tree... And we haven't touched the libcxxabi library so no exceptions (ie, TRY/CATCH) but that's OK since the compilers don't use those features.

We are currently working on bootstrapping the GEM pieces needed for the legacy frontends (ie, processing the command line, managing source files, creating symbol tables/GEM CIL, etc) so we can hook up our first native legacy frontend to that native LLVM. To make it more "fun", we are using LLVM 3.4.2 with the cross-compilers but are using LLVM 10.0.1 at the moment for the native compilers. And without a functional debugger, we're using DELTA for debugging. Our first native compilers will probably be Macro or BLISS sometime in the next month or so.

Mix in some recently found bugs in the G2L (GEM to LLVM converter) and some missing functionality (including some needed for BASIC) and things are just taking time.

And finally with the release of V9.1, we'll be letting more folks download it (and the cross-tools). More people will find more bugs (thank you) but will generate questions as well. That will take time to answer them. Please go easy on me.
Dave Froble
2021-06-26 01:57:49 UTC
Reply
Permalink
Post by John Reagan
Sorry for the late response, I was on the road all day. Typing this now from scenic Hagerstown Maryland on my way to visit my sister for a week+
BASIC. There are several reasons why BASIC is lagging....
The RTL LOVES to walk the stack. We found a bug in one of the LIB$X86 Calling Standard routines that no other language found. Just printing a string causes the RTL to walk up the stack back to the routine that literally just called the RTL.
The compiler and RTL LOVE floating point. Printing an integer involves converting it to a floating point, converting that to a string, and printing everything to the left of the decimal point. And even with the default being IEEE, we found that Itanium BASIC still wants to use VAX floating.
And we found some other bugs in the RTL (like one routine passing the address of short to another routine that wrote a longword value).
BASIC was [ab]using a GEM interface to place stack allocated variables at known offsets on the stack frame. No other frontend does that. We do provide that feature for static variables for BLISS. We didn't know about BASIC's stack dependency until nothing worked! G2L has to collect all of the different GEM stack variables, combine them into a single 'container' variable to give to LLVM and then convert all of the references into offsets in the container. Getting the debug info right will be a nightmare and describing all the jiggery pokery to the LLVM optimizer might not be 100%.
Native compilers. Yes, at one time the existence of native compilers was tied to the definition of V9.1, but that isn't true anymore. Compilers (well, other than Macro) are layered products, not part of the OS. [V9.1 doesn't contain a native Macro either.]
We have a native LLVM, libcxx, etc. on x86 (bootstrapped from Linux). We have a native clang (with only a few OpenVMS'isms) on x86. It is wobbly but we're working through it. Much has involved clang treating "long" as 64-bits but the RTL headers and code believing that "long" is only 32-bits. As I've mentioned before, we have to get the RTL to deal with both. Doing RTL name prefixing/mapping involves finding the right places in the clang source tree... And we haven't touched the libcxxabi library so no exceptions (ie, TRY/CATCH) but that's OK since the compilers don't use those features.
We are currently working on bootstrapping the GEM pieces needed for the legacy frontends (ie, processing the command line, managing source files, creating symbol tables/GEM CIL, etc) so we can hook up our first native legacy frontend to that native LLVM. To make it more "fun", we are using LLVM 3.4.2 with the cross-compilers but are using LLVM 10.0.1 at the moment for the native compilers. And without a functional debugger, we're using DELTA for debugging. Our first native compilers will probably be Macro or BLISS sometime in the next month or so.
Mix in some recently found bugs in the G2L (GEM to LLVM converter) and some missing functionality (including some needed for BASIC) and things are just taking time.
And finally with the release of V9.1, we'll be letting more folks download it (and the cross-tools). More people will find more bugs (thank you) but will generate questions as well. That will take time to answer them. Please go easy on me.
John,

Perhaps not right away, but, do you see the possibility down the road of
fixing some of those things Basic does, the stack nonsense, and such?
Would be nice to improve Basic's performance some.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Richard Maher
2021-06-26 03:09:44 UTC
Reply
Permalink
Post by Dave Froble
Post by John Reagan
Sorry for the late response, I was on the road all day. Typing
this now from scenic Hagerstown Maryland on my way to visit my
sister for a week+
BASIC. There are several reasons why BASIC is lagging....
The RTL LOVES to walk the stack. We found a bug in one of the
LIB$X86 Calling Standard routines that no other language found.
Just printing a string causes the RTL to walk up the stack back to
the routine that literally just called the RTL.
The compiler and RTL LOVE floating point. Printing an integer
involves converting it to a floating point, converting that to a
string, and printing everything to the left of the decimal point.
And even with the default being IEEE, we found that Itanium BASIC
still wants to use VAX floating.
And we found some other bugs in the RTL (like one routine passing
the address of short to another routine that wrote a longword
value).
BASIC was [ab]using a GEM interface to place stack allocated
variables at known offsets on the stack frame. No other frontend
does that. We do provide that feature for static variables for
BLISS. We didn't know about BASIC's stack dependency until nothing
worked! G2L has to collect all of the different GEM stack
variables, combine them into a single 'container' variable to give
to LLVM and then convert all of the references into offsets in the
container. Getting the debug info right will be a nightmare and
describing all the jiggery pokery to the LLVM optimizer might not
be 100%.
Native compilers. Yes, at one time the existence of native
compilers was tied to the definition of V9.1, but that isn't true
anymore. Compilers (well, other than Macro) are layered products,
not part of the OS. [V9.1 doesn't contain a native Macro either.]
We have a native LLVM, libcxx, etc. on x86 (bootstrapped from
Linux). We have a native clang (with only a few OpenVMS'isms) on
x86. It is wobbly but we're working through it. Much has involved
clang treating "long" as 64-bits but the RTL headers and code
believing that "long" is only 32-bits. As I've mentioned before,
we have to get the RTL to deal with both. Doing RTL name
prefixing/mapping involves finding the right places in the clang
source tree... And we haven't touched the libcxxabi library so no
exceptions (ie, TRY/CATCH) but that's OK since the compilers don't
use those features.
We are currently working on bootstrapping the GEM pieces needed for
the legacy frontends (ie, processing the command line, managing
source files, creating symbol tables/GEM CIL, etc) so we can hook
up our first native legacy frontend to that native LLVM. To make
it more "fun", we are using LLVM 3.4.2 with the cross-compilers but
are using LLVM 10.0.1 at the moment for the native compilers. And
without a functional debugger, we're using DELTA for debugging.
Our first native compilers will probably be Macro or BLISS sometime
in the next month or so.
Mix in some recently found bugs in the G2L (GEM to LLVM converter)
and some missing functionality (including some needed for BASIC)
and things are just taking time.
And finally with the release of V9.1, we'll be letting more folks
download it (and the cross-tools). More people will find more bugs
(thank you) but will generate questions as well. That will take
time to answer them. Please go easy on me.
John,
Perhaps not right away, but, do you see the possibility down the road
of fixing some of those things Basic does, the stack nonsense, and
such? Would be nice to improve Basic's performance some.
Just use COBOL!
Dave Froble
2021-06-26 15:21:51 UTC
Reply
Permalink
Post by Richard Maher
Post by Dave Froble
Post by John Reagan
Sorry for the late response, I was on the road all day. Typing
this now from scenic Hagerstown Maryland on my way to visit my
sister for a week+
BASIC. There are several reasons why BASIC is lagging....
The RTL LOVES to walk the stack. We found a bug in one of the
LIB$X86 Calling Standard routines that no other language found.
Just printing a string causes the RTL to walk up the stack back to
the routine that literally just called the RTL.
The compiler and RTL LOVE floating point. Printing an integer
involves converting it to a floating point, converting that to a
string, and printing everything to the left of the decimal point.
And even with the default being IEEE, we found that Itanium BASIC
still wants to use VAX floating.
And we found some other bugs in the RTL (like one routine passing
the address of short to another routine that wrote a longword
value).
BASIC was [ab]using a GEM interface to place stack allocated
variables at known offsets on the stack frame. No other frontend
does that. We do provide that feature for static variables for
BLISS. We didn't know about BASIC's stack dependency until nothing
worked! G2L has to collect all of the different GEM stack
variables, combine them into a single 'container' variable to give
to LLVM and then convert all of the references into offsets in the
container. Getting the debug info right will be a nightmare and
describing all the jiggery pokery to the LLVM optimizer might not
be 100%.
Native compilers. Yes, at one time the existence of native
compilers was tied to the definition of V9.1, but that isn't true
anymore. Compilers (well, other than Macro) are layered products,
not part of the OS. [V9.1 doesn't contain a native Macro either.]
We have a native LLVM, libcxx, etc. on x86 (bootstrapped from
Linux). We have a native clang (with only a few OpenVMS'isms) on
x86. It is wobbly but we're working through it. Much has involved
clang treating "long" as 64-bits but the RTL headers and code
believing that "long" is only 32-bits. As I've mentioned before,
we have to get the RTL to deal with both. Doing RTL name
prefixing/mapping involves finding the right places in the clang
source tree... And we haven't touched the libcxxabi library so no
exceptions (ie, TRY/CATCH) but that's OK since the compilers don't
use those features.
We are currently working on bootstrapping the GEM pieces needed for
the legacy frontends (ie, processing the command line, managing
source files, creating symbol tables/GEM CIL, etc) so we can hook
up our first native legacy frontend to that native LLVM. To make
it more "fun", we are using LLVM 3.4.2 with the cross-compilers but
are using LLVM 10.0.1 at the moment for the native compilers. And
without a functional debugger, we're using DELTA for debugging.
Our first native compilers will probably be Macro or BLISS sometime
in the next month or so.
Mix in some recently found bugs in the G2L (GEM to LLVM converter)
and some missing functionality (including some needed for BASIC)
and things are just taking time.
And finally with the release of V9.1, we'll be letting more folks
download it (and the cross-tools). More people will find more bugs
(thank you) but will generate questions as well. That will take
time to answer them. Please go easy on me.
John,
Perhaps not right away, but, do you see the possibility down the road
of fixing some of those things Basic does, the stack nonsense, and
such? Would be nice to improve Basic's performance some.
Just use COBOL!
Not a chance. Cobol was one of the first languages I learned, and I
also learned to dislike it.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-06-27 03:00:54 UTC
Reply
Permalink
Post by Dave Froble
Sorry for the late response, I was on the road all day. Typing this now from scenic Hagerstown Maryland on my way to visit my sister for a week+
BASIC. There are several reasons why BASIC is lagging....
The RTL LOVES to walk the stack. We found a bug in one of the LIB$X86 Calling Standard routines that no other language found. Just printing a string causes the RTL to walk up the stack back to the routine that literally just called the RTL.
The compiler and RTL LOVE floating point. Printing an integer involves converting it to a floating point, converting that to a string, and printing everything to the left of the decimal point. And even with the default being IEEE, we found that Itanium BASIC still wants to use VAX floating.
And we found some other bugs in the RTL (like one routine passing the address of short to another routine that wrote a longword value).
BASIC was [ab]using a GEM interface to place stack allocated variables at known offsets on the stack frame. No other frontend does that. We do provide that feature for static variables for BLISS. We didn't know about BASIC's stack dependency until nothing worked! G2L has to collect all of the different GEM stack variables, combine them into a single 'container' variable to give to LLVM and then convert all of the references into offsets in the container. Getting the debug info right will be a nightmare and describing all the jiggery pokery to the LLVM optimizer might not be 100%.
Native compilers. Yes, at one time the existence of native compilers was tied to the definition of V9.1, but that isn't true anymore. Compilers (well, other than Macro) are layered products, not part of the OS. [V9.1 doesn't contain a native Macro either.]
We have a native LLVM, libcxx, etc. on x86 (bootstrapped from Linux). We have a native clang (with only a few OpenVMS'isms) on x86. It is wobbly but we're working through it. Much has involved clang treating "long" as 64-bits but the RTL headers and code believing that "long" is only 32-bits. As I've mentioned before, we have to get the RTL to deal with both. Doing RTL name prefixing/mapping involves finding the right places in the clang source tree... And we haven't touched the libcxxabi library so no exceptions (ie, TRY/CATCH) but that's OK since the compilers don't use those features.
We are currently working on bootstrapping the GEM pieces needed for the legacy frontends (ie, processing the command line, managing source files, creating symbol tables/GEM CIL, etc) so we can hook up our first native legacy frontend to that native LLVM. To make it more "fun", we are using LLVM 3.4.2 with the cross-compilers but are using LLVM 10.0.1 at the moment for the native compilers. And without a functional debugger, we're using DELTA for debugging. Our first native compilers will probably be Macro or BLISS sometime in the next month or so.
Mix in some recently found bugs in the G2L (GEM to LLVM converter) and some missing functionality (including some needed for BASIC) and things are just taking time.
And finally with the release of V9.1, we'll be letting more folks download it (and the cross-tools). More people will find more bugs (thank you) but will generate questions as well. That will take time to answer them. Please go easy on me.
John,
Perhaps not right away, but, do you see the possibility down the road of
fixing some of those things Basic does, the stack nonsense, and such?
Would be nice to improve Basic's performance some.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Probably not worth the effort or risk. We did make some changes to the RTL for Itanium to reduce the stack walking. It isn't as expensive on x86 (but still more effort than Alpha). It is all the floating that really surprised me.
Simon Clubley
2021-06-28 17:46:17 UTC
Reply
Permalink
Post by John Reagan
The compiler and RTL LOVE floating point. Printing an integer involves converting it to a floating point, converting that to a string, and printing everything to the left of the decimal point. And even with the default being IEEE, we found that Itanium BASIC still wants to use VAX floating.
Was DEC Basic by any chance written by a salesperson looking to sell
more powerful (and hence more expensive) computers ? :-)
Post by John Reagan
And we found some other bugs in the RTL (like one routine passing the address of short to another routine that wrote a longword value).
Ooh, interesting... :-)

On a more serious note however, have you made sure that routine isn't
used in any privileged parts of VMS ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-06-28 18:47:07 UTC
Reply
Permalink
Post by Simon Clubley
Post by John Reagan
The compiler and RTL LOVE floating point. Printing an integer involves converting it to a floating point, converting that to a string, and printing everything to the left of the decimal point. And even with the default being IEEE, we found that Itanium BASIC still wants to use VAX floating.
Was DEC Basic by any chance written by a salesperson looking to sell
more powerful (and hence more expensive) computers ? :-)
Basic+ came out of EG&H, Tim (or Dave) Hart wrote it, I'm assuming in
Macro-11. Ran on RSTS.

BP2 was a compiled version of the language, running on RSX, not sure
what language.

VAX Basic was the next iteration. Not sure what language. Kirbey
Altman was one of the principal developers.

The language was them implemented on Alpha, still 32 bit.

Then moved to itanic.

So, you can see, there was plenty of opportunity for things to get
messed up. As for all the stack crawling, don't have a clue how that
came to be. Wish it hadn't.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John Reagan
2021-06-29 21:50:13 UTC
Reply
Permalink
Post by Simon Clubley
On a more serious note however, have you made sure that routine isn't
used in any privileged parts of VMS ?
Yes, I did consider that

1 - there is no BASIC in any OpenVMS system code (privileged or not)
2 - the adjacent memory that was being overwritten is an alignment hole on Alpha and Itanium and serves no other purpose
Stephen Hoffman
2021-06-26 01:24:11 UTC
Reply
Permalink
Post by Arne Vajhøj
Why not pthreads?
pthreads is not my preferred threading model nor my preferred threading
API. Not after using some of the other threading implementations
around. Nor is the pthreads API friendly to BASIC code.

Specifically for established and existing OpenVMS apps, KP Threads is a
more familiar interface such as when working in BASIC.

Using processes rather than threads avoids the "fun" of ensuring that
all the app code and RTL code and all the shared variables are all
thread re-entrant, too. This for OpenVMS. Threading support
else-platform can be better.

And if I wanted to overhaul or to re-write the existing BASIC app to
use pthreads, or Java or Python or PHP, or other such efforts, I'd
seriously consider re-hosting the entire app else-platform as that's
headed for a re-write.

Then there's this bit of "fun" to consider with pthreads:
https://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-06-26 02:02:29 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Why not pthreads?
pthreads is not my preferred threading model nor my preferred threading
API. Not after using some of the other threading implementations around.
Nor is the pthreads API friendly to BASIC code.
Specifically for established and existing OpenVMS apps, KP Threads is a
more familiar interface such as when working in BASIC.
Using processes rather than threads avoids the "fun" of ensuring that
all the app code and RTL code and all the shared variables are all
thread re-entrant, too. This for OpenVMS. Threading support
else-platform can be better.
And if I wanted to overhaul or to re-write the existing BASIC app to use
pthreads, or Java or Python or PHP, or other such efforts, I'd seriously
consider re-hosting the entire app else-platform as that's headed for a
re-write.
https://www.hpl.hp.com/techreports/2004/HPL-2004-209.html
I'll just address my opinion of threads. Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?

I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-26 18:53:59 UTC
Reply
Permalink
I'll just address my opinion of threads.  Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?
I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
Threading provides a very convenient programming model.

Shared heap is a lot easier than IPC.

Sure - it is also possible to shoot oneself in the foot
accessing that shared heap.

But for people that understand concurrency problems and
locking then it should not be a big problem.

Arne
Arne Vajhøj
2021-06-29 17:01:31 UTC
Reply
Permalink
Post by Arne Vajhøj
I'll just address my opinion of threads.  Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?
I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
Threading provides a very convenient programming model.
Shared heap is a lot easier than IPC.
And if Basic is better than English.

Imports System
Imports System.Linq
Imports System.Threading
Imports System.Threading.Tasks

Namespace T
Public Class Program
Public Class SumTask
Public Property X() As Double()
Public Property IxStart() As Integer
Public Property IxEnd() As Integer
Public Property Result() As Double
Public Sub New(_x As Double(), ix1 As Integer, ix2 As Integer)
X = _x
IxStart = ix1
IxEnd = ix2
End Sub
Public Sub Run()
Dim temp As Double() = X
Dim ix1 As Integer = IxStart
Dim ix2 As Integer = IxEnd
Dim res As Double = 0
For i As Integer = ix1 To ix2 - 1
res += temp(i)
Next
Result = res
End Sub
End Class
Private Shared Function ManSeq(x As Double()) As Double
Dim res As Double = 0
For i As Integer = 0 To x.Length - 1
res += x(i)
Next
Return res
End Function
Private Shared Function ManThread(x As Double()) As Double
Dim t As Thread() = New Thread(3) {}
Dim st As SumTask() = New SumTask(t.Length - 1) {}
For k As Integer = 0 To t.Length - 1
st(k) = New SumTask(x, k * x.Length \ t.Length, (k + 1)
* x.Length \ t.Length)
t(k) = New Thread(AddressOf st(k).Run)
t(k).Start()
Next
Dim res As Double = 0
For k As Integer = 0 To t.Length - 1
t(k).Join()
res += st(k).Result
Next
Return res
End Function
Private Shared Function ManPool(x As Double()) As Double
Dim t As Task() = New Task(15) {}
Dim st As SumTask() = New SumTask(t.Length - 1) {}
For k As Integer = 0 To t.Length - 1
st(k) = New SumTask(x, k * x.Length \ t.Length, (k + 1)
* x.Length \ t.Length)
t(k) = Task.Factory.StartNew(AddressOf st(k).Run)
Next
Dim res As Double = 0
For k As Integer = 0 To t.Length - 1
t(k).Wait()
res += st(k).Result
Next
Return res
End Function
Private Shared Function LinqSeq(x As Double()) As Double
Return x.Sum()
End Function
Private Shared Function LinqPar(x As Double()) As Double
Return x.AsParallel().Sum()
End Function
Private Const N As Integer = 100000000
Private Const M As Integer = 10
Private Const REP As Integer = 5
Private Delegate Function Summer(x As Double()) As Double
Private Shared Sub Test(lbl As String, sumf As Summer, x As
Double())
Dim dt1 As DateTime = DateTime.Now
For j As Integer = 0 To M - 1
Dim res As Double = sumf(x)
If res < 0.49 * N OrElse 0.51 * N < res Then
Throw New Exception("We have a bad RNG")
End If
Next
Dim dt2 As DateTime = DateTime.Now
Console.WriteLine("{0,-20} : {1,5:F0}", lbl, (dt2 -
dt1).TotalMilliseconds)
End Sub
Private Shared ReadOnly rng As New Random()
Public Shared Sub Main(args As String())
Dim x As Double() = New Double(N - 1) {}
For i As Integer = 0 To x.Length - 1
x(i) = rng.NextDouble()
Next
For j As Integer = 0 To REP - 1
Test("Manual sequential", AddressOf ManSeq, x)
Test("Manual threading", AddressOf ManThread, x)
Test("Manual thread pool", AddressOf ManPool, x)
Test("LINQ sequential", AddressOf LinqSeq, x)
Test("LINQ parallel", AddressOf LinqPar, x)
Console.WriteLine("----")
Next
Console.ReadKey()
End Sub
End Class
End Namespace

output:

Manual sequential : 3245
Manual threading : 1534
Manual thread pool : 769
LINQ sequential : 6609
LINQ parallel : 1716
----
Manual sequential : 3245
Manual threading : 1498
Manual thread pool : 749
LINQ sequential : 6568
LINQ parallel : 1529
----
Manual sequential : 3229
Manual threading : 1420
Manual thread pool : 842
LINQ sequential : 6583
LINQ parallel : 1544
----
Manual sequential : 3229
Manual threading : 1778
Manual thread pool : 733
LINQ sequential : 6571
LINQ parallel : 1654
----
Manual sequential : 3382
Manual threading : 1413
Manual thread pool : 761
LINQ sequential : 6673
LINQ parallel : 1482
----

Arne
Simon Clubley
2021-06-30 12:04:23 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Arne Vajhøj
I'll just address my opinion of threads.  Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?
I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
Threading provides a very convenient programming model.
Shared heap is a lot easier than IPC.
And if Basic is better than English.
[snip example]

Yeah, good luck getting David to write Basic code which looks like that. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2021-06-30 13:22:10 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
I'll just address my opinion of threads.  Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?
I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
Threading provides a very convenient programming model.
Shared heap is a lot easier than IPC.
And if Basic is better than English.
[snip example]
Yeah, good luck getting David to write Basic code which looks like that. :-)
Well - I could not do it in VMS basic because:
1) I am not good enough in VMS Basic
2) VMS Basic does not support multi-threading

So I went for a Basic that does support multi-threading: VB.NET.
Which accidentally solved my skill problem as well as I can write
the code in C# and auto convert to VB.NET (with a little post-conversion
polish).

Arne
Dave Froble
2021-06-30 14:47:27 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Arne Vajhøj
Post by Dave Froble
I'll just address my opinion of threads. Not saying they are useless,
but, if the OS, VMS, already gives me separate "threads" called
processes, why do I want the aggravation of re-inventing it inside my apps?
I'm sure someone will cry out "performance", but, with today's
processors, performance is most likely a rare issue.
Threading provides a very convenient programming model.
Shared heap is a lot easier than IPC.
And if Basic is better than English.
[snip example]
Yeah, good luck getting David to write Basic code which looks like that. :-)
Simon.
He hasn't got nearly a large enough army ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-26 18:49:53 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Why not pthreads?
pthreads is not my preferred threading model nor my preferred threading
API. Not after using some of the other threading implementations around.
Nor is the pthreads API friendly to BASIC code.
Specifically for established and existing OpenVMS apps, KP Threads is a
more familiar interface such as when working in BASIC.
There is at least one advantage with pthreads - it is a standard. It
is actually possible to get help with it, because it is widely used.

And I can only halfway follow your problem with the model.

The pthreads model is the basic model used by almost all
threading systems as the lowest level thread API.

Java, .NET, Windows, Boost/C++ 11, Qt, Delphi etc. all
provide a similar API.

Sure some of them provide additional capabilities on top
of that: thread pool, implicit parallelization, async,
reactive etc..

But the foundation is still the basic thread API.
Post by Stephen Hoffman
And if I wanted to overhaul or to re-write the existing BASIC app to use
pthreads, or Java or Python or PHP, or other such efforts, I'd seriously
consider re-hosting the entire app else-platform as that's headed for a
re-write.
Migrating the VMS Basic code to another platform is likely impossible
short/mid term.

Arne
Stephen Hoffman
2021-06-27 00:20:39 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Arne Vajhøj
Why not pthreads?
pthreads is not my preferred threading model nor my preferred threading
API. Not after using some of the other threading implementations
around. Nor is the pthreads API friendly to BASIC code.
Specifically for established and existing OpenVMS apps, KP Threads is a
more familiar interface such as when working in BASIC.
There is at least one advantage with pthreads - it is a standard. It is
actually possible to get help with it, because it is widely used.
pthreads is not my preferred threading.

pthreads is not something I'd prefer to interface with BASIC, either.

As for threading-based designs more generally, I'm skeptical that the
added complexity of adding threading into an established OpenVMS app
provides any particular advantage here over a pool of server processes.

And I'd prefer to performance-profile the whole existing environment
under load, looking for where the time is going.

And whether—for instance—reconfiguring the app design for sharding or
other approaches, or communications to message-passing design, or other
changes, might work well enough and within the existing app design?
And I can only halfway follow your problem with the model.
Other than the "I don't prefer the pthreads model", and "add-on
threading libraries don't work well for threading without language
help", you mean?

C and volatile has long been an adventure, too. That's all getting
better, but still problematic in places. Here's an older intro to the
"fun" with C volatile:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html

BASIC last I checked had no analogous storage-access support for what C
refers to as volatile storage, such multiprocessing-related
synchronization was based on interlocked bitlocks and ilk. Which was
discussed here back in 2019.
https://groups.google.com/g/comp.os.vms/c/Zf9tM2UkKAE/m/awJ6Tp-yAQAJ
The pthreads model is the basic model used by almost all threading
systems as the lowest level thread API.
pthreads might be the lowest-level on some platforms, though not on the
platforms I'm dealing with, including not on OpenVMS. KP Threads is the
lowest level threading API on OpenVMS, for those not creating their own.
Java, .NET, Windows, Boost/C++ 11, Qt, Delphi etc. all provide a similar API.
None of which I'd choose to use on OpenVMS, where (when) those tools
(Java) are even available for OpenVMS.

And if I were to consider the use of some of those tools—opening up a
much wider discussion during these sorts of app refactoring and app
retrofitting—I'd also necessarily be obligated to consider porting some
or all of the app to some other platform, either front-end or more.
But the foundation is still the basic thread API.
Alas, pthreads is not the foundation of threading on OpenVMS.
Post by Stephen Hoffman
And if I wanted to overhaul or to re-write the existing BASIC app to
use pthreads, or Java or Python or PHP, or other such efforts, I'd
seriously consider re-hosting the entire app else-platform as that's
headed for a re-write.
Migrating the VMS Basic code to another platform is likely impossible
short/mid term.
Grafting a threading design into an established BASIC app environment
is no small effort, either.

Adding ASTs alone into an existing app can become a design,
implementation, and refactoring adventure, for those apps not currently
using ASTs.

And handing off an SSL/TLS connection is not something I'd prefer to
tangle with within a project, nor would be having a zillion TLS
connections into one multi-threaded server process.

But again, I'd profile the whole environment, and with a discussion for
where the app developer wants to end up after the work both short-term
and longer-term.

Haven't looked at porting VSI BASIC to the various BASIC compilers for
Unix in a while, nor at porting to the VBS/VBN stuff, nor Sector7
support. That's almost certainly out-of-scope here, at least short
term. But there are BASIC compilers around.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-06-26 01:49:35 UTC
Reply
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Dave Froble
I need to develop a better method of handling lots of socket
connect requests. I also need to see if my ideas will work Ok.
How many are "lots of"?
That is sort of undefined at this time. Historically, the usage has
continued to rise. Not sure what it could rise to. So far we've
seen maybe 20K per hour at times.
Ok, I lied.

Went back to check on some things. I'm told that some peaks of 20,000
per MINUTE have been observed. We're handling that now, but, it's
stressing some. Guess this work is none too soon.

16 core itanic is being stressed at times.

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-26 19:00:06 UTC
Reply
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
How many are "lots of"?
That is sort of undefined at this time.  Historically, the usage has
continued to rise.  Not sure what it could rise to.  So far we've
seen maybe 20K per hour at times.
Ok, I lied.
Went back to check on some things.  I'm told that some peaks of 20,000
per MINUTE have been observed.  We're handling that now, but, it's
stressing some.  Guess this work is none too soon.
That x60 is significant.

:-)

Arne
Phillip Helbig (undress to reply)
2021-06-26 06:39:12 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
Hans Bachner
2021-06-28 14:08:20 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
You mean it should be switched off?

:-)
Hans.
Dave Froble
2021-06-28 15:50:07 UTC
Reply
Permalink
Post by Hans Bachner
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
You mean it should be switched off?
:-)
Hans.
Ok, to address this question. First, I'll say I was a bit surprised.
There are fans stacked in front of other fans. As if one isn't enough.

So I pushed the button to activate things, I could have sworn I was at
the airport listening to an F-15 starting it's engines. Possibly
including the afterburners.

Yes, it is loud, very loud.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2021-06-28 17:56:25 UTC
Reply
Permalink
Post by Dave Froble
Post by Hans Bachner
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
You mean it should be switched off?
:-)
Hans.
Ok, to address this question. First, I'll say I was a bit surprised.
There are fans stacked in front of other fans. As if one isn't enough.
It probably isn't given they have had to design it like that.
Post by Dave Froble
So I pushed the button to activate things, I could have sworn I was at
the airport listening to an F-15 starting it's engines. Possibly
including the afterburners.
Yes, it is loud, very loud.
So it's not going to live in your work area after all ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2021-06-28 18:28:12 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Hans Bachner
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
You mean it should be switched off?
:-)
Hans.
Ok, to address this question. First, I'll say I was a bit surprised.
There are fans stacked in front of other fans. As if one isn't enough.
It probably isn't given they have had to design it like that.
Post by Dave Froble
So I pushed the button to activate things, I could have sworn I was at
the airport listening to an F-15 starting it's engines. Possibly
including the afterburners.
Yes, it is loud, very loud.
So it's not going to live in your work area after all ? :-)
Simon.
Was never going to happen. It's downstairs with the Alphas.

My first task is to change the iLO IP address so it's on my in house
network subnet. Thought I had done so, but it wasn't changed. Must be
some method to save changes.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
chris
2021-06-28 18:28:17 UTC
Reply
Permalink
Post by Hans Bachner
Post by Simon Clubley
BTW, David, just how noisy _is_ your new Itanium ? :-)
Haven't seen it yet. Will report when it gets here.
Itanium should be seen but not heard. :-)
You mean it should be switched off?
:-)
Hans.
Ok, to address this question. First, I'll say I was a bit surprised.
There are fans stacked in front of other fans. As if one isn't enough.
It's quite common in 1 or 2U servers and has been for years now.
There are engineering limits to fan speed and airflow and putting
two back to back improves airflow and adds redundancy. Usually,
the fans start off at high speed on power up, to verify correct
operation, then slow down as the bios and then os adjusts the
speed to suit current system temperature.
So I pushed the button to activate things, I could have sworn I was at
the airport listening to an F-15 starting it's engines. Possibly
including the afterburners.
Yes, it is loud, very loud.
vVery, but not so bad once they are mounted in the rack...
Arne Vajhøj
2021-06-25 12:52:50 UTC
Reply
Permalink
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests, accepts
the connection, and passes it off to a worker process, then drops it's
own connection to the socket.  Involves some inter-process
communications.  Listener might get rather busy, but will spend little
time on each request.
If you write the listener in a language that supports threading, then
it could be done relative simple.

client---(TCP)---multi threaded listener---(IPC)---N worker processes

The multi threaded listner has:
- 1 thread that accepts connections and put them in queue
- N handler threads that in a loop take connection from queue
and does passthrough between client and worker process until
client is done

Optionally you could add another tread monitoring queue length
and handler thread activity.

Arne
Dave Froble
2021-06-25 19:15:51 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests. I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket. Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
If you write the listener in a language that supports threading, then
it could be done relative simple.
client---(TCP)---multi threaded listener---(IPC)---N worker processes
- 1 thread that accepts connections and put them in queue
- N handler threads that in a loop take connection from queue
and does passthrough between client and worker process until
client is done
Optionally you could add another tread monitoring queue length
and handler thread activity.
Arne
If I understand correctly what you suggest, it does not fit what I want.

Now, it doesn't happen, and I'm not sure why it ever would, but the
listener might have to go down for some reason. This would kill all
threaded processing, sub-processes, and such. My desire is to spawn the
worker processes, and they would then be independent of the listener.
While most jobs run very quickly, what about a request for a report that
takes 3 hours to run and then return the result(s)?

I learned long ago that when someone tells me "that never happens", it
will be one of the first things to bite me on the ass, and therefore I
plan for it happening.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-25 23:10:11 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket.  Involves some inter-process
communications.  Listener might get rather busy, but will spend little
time on each request.
If you write the listener in a language that supports threading, then
it could be done relative simple.
client---(TCP)---multi threaded listener---(IPC)---N worker processes
- 1 thread that accepts connections and put them in queue
- N handler threads that in a loop take connection from queue
  and does passthrough between client and worker process until
  client is done
Optionally you could add another tread monitoring queue length
and handler thread activity.
If I understand correctly what you suggest, it does not fit what I want.
Now, it doesn't happen, and I'm not sure why it ever would, but the
listener might have to go down for some reason.  This would kill all
threaded processing, sub-processes, and such.  My desire is to spawn the
worker processes, and they would then be independent of the listener.
While most jobs run very quickly, what about a request for a report that
takes 3 hours to run and then return the result(s)?
So the passthrough threads are not good.

Could you modify the protocol to work like:

* client connect to port N (listener)
* listener validates request, determine a free worker process, tell
worker to get ready and tell client to connect to port M
* client connect to port M (worker)

?
Post by Dave Froble
I learned long ago that when someone tells me "that never happens", it
will be one of the first things to bite me on the ass, and therefore I
plan for it happening.
Murphy's law.

Arne
Dave Froble
2021-06-26 02:08:40 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests. I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket. Involves some inter-process
communications. Listener might get rather busy, but will spend little
time on each request.
If you write the listener in a language that supports threading, then
it could be done relative simple.
client---(TCP)---multi threaded listener---(IPC)---N worker processes
- 1 thread that accepts connections and put them in queue
- N handler threads that in a loop take connection from queue
and does passthrough between client and worker process until
client is done
Optionally you could add another tread monitoring queue length
and handler thread activity.
If I understand correctly what you suggest, it does not fit what I want.
Now, it doesn't happen, and I'm not sure why it ever would, but the
listener might have to go down for some reason. This would kill all
threaded processing, sub-processes, and such. My desire is to spawn
the worker processes, and they would then be independent of the
listener. While most jobs run very quickly, what about a request for a
report that takes 3 hours to run and then return the result(s)?
So the passthrough threads are not good.
* client connect to port N (listener)
* listener validates request, determine a free worker process, tell
worker to get ready and tell client to connect to port M
* client connect to port M (worker)
Why would you do all that? A socket can be created with sharing
allowed. Listener grants the connection, worked opens same socket
shared, listener closes the socket.

If the listener peeks into the buffer (not read) it can make decisions
based upon what it finds, and the entire socket activity happens in the
worker. Client never knows it is talking to other than the listener
that granted the connection.

At least that's how I understand things, which is why I need to do some
research.

The listener/worker communications is where I'm going to have problems.
Must be very fast, so listener can be done quickly.
Post by Arne Vajhøj
Post by Dave Froble
I learned long ago that when someone tells me "that never happens", it
will be one of the first things to bite me on the ass, and therefore I
plan for it happening.
Murphy's law.
Arne
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-26 19:08:56 UTC
Reply
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
Post by Arne Vajhøj
Post by Dave Froble
I need to develop a better method of handling lots of socket connect
requests.  I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket.  Involves some inter-process
communications.  Listener might get rather busy, but will spend little
time on each request.
If you write the listener in a language that supports threading, then
it could be done relative simple.
client---(TCP)---multi threaded listener---(IPC)---N worker processes
- 1 thread that accepts connections and put them in queue
- N handler threads that in a loop take connection from queue
  and does passthrough between client and worker process until
  client is done
Optionally you could add another tread monitoring queue length
and handler thread activity.
If I understand correctly what you suggest, it does not fit what I want.
Now, it doesn't happen, and I'm not sure why it ever would, but the
listener might have to go down for some reason.  This would kill all
threaded processing, sub-processes, and such.  My desire is to spawn
the worker processes, and they would then be independent of the
listener. While most jobs run very quickly, what about a request for a
report that takes 3 hours to run and then return the result(s)?
So the passthrough threads are not good.
* client connect to port N (listener)
* listener validates request, determine a free worker process, tell
  worker to get ready and tell client to connect to port M
* client connect to port M (worker)
Why would you do all that?
It is a nice model.

Minimal interaction between listener and worker.
Post by Dave Froble
  A socket can be created with sharing
allowed.  Listener grants the connection, worked opens same socket
shared, listener closes the socket.
If the listener peeks into the buffer (not read) it can make decisions
based upon what it finds, and the entire socket activity happens in the
worker.  Client never knows it is talking to other than the listener
that granted the connection.
At least that's how I understand things, which is why I need to do some
research.
The approach is common on *nix (fork).
Post by Dave Froble
The listener/worker communications is where I'm going to have problems.
Must be very fast, so listener can be done quickly.
If you accidentally happened to have code for MailBox access
available, then a MB per worker may be a convenient model
and probably fast enough (shared memory is super fast,
but proper synchronization will require more code).

Arne
Richard Maher
2021-06-26 03:11:43 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Dave Froble
I need to develop a better method of handling lots of socket
connect requests. I also need to see if my ideas will work Ok.
Current thoughts are a single listener that validates requests,
accepts the connection, and passes it off to a worker process, then
drops it's own connection to the socket. Involves some
inter-process communications. Listener might get rather busy, but
will spend little time on each request.
If you write the listener in a language that supports threading,
then it could be done relative simple.
client---(TCP)---multi threaded listener---(IPC)---N worker
processes
The multi threaded listner has: - 1 thread that accepts connections
and put them in queue - N handler threads that in a loop take
connection from queue and does passthrough between client and worker
process until client is done
Optionally you could add another tread monitoring queue length and
handler thread activity.
Arne
Or you could use something like Tier3 that handles all the Network Comms
and threading for you and you just have to provide an RTL in any 3GL
with 6 routines?
Dave Froble
2021-06-27 01:42:04 UTC
Reply
Permalink
Ok, back to the iLO. Bill brought the itanic around today. Of course
had to open it up to see what's inside. Habit of mine.

One processor, don't yet know how many cores.
8 146 GB disks.

My next question is "what good methods are there for learning to talk to
the iLO?" If I got to play with this beast, at least I can try to do it
correctly.

No noise testing yet.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2021-06-27 01:53:47 UTC
Reply
Permalink
Ok, back to the iLO.  Bill brought the itanic around today.  Of course
had to open it up to see what's inside.  Habit of mine.
One processor, don't yet know how many cores.
8 146 GB disks.
My next question is "what good methods are there for learning to talk to
the iLO?"  If I got to play with this beast, at least I can try to do it
correctly.
ssh to it
co in menu to get to the console
do whatever VMS work you need to do
ctrl/b to get back to menu
x to exit menu and ssh connection

Arne
Arne Vajhøj
2021-06-27 01:54:28 UTC
Reply
Permalink
Post by Arne Vajhøj
Ok, back to the iLO.  Bill brought the itanic around today.  Of course
had to open it up to see what's inside.  Habit of mine.
One processor, don't yet know how many cores.
8 146 GB disks.
My next question is "what good methods are there for learning to talk
to the iLO?"  If I got to play with this beast, at least I can try to
do it correctly.
ssh to it
login to it
Post by Arne Vajhøj
co in menu to get  to the console
do whatever VMS work you need to do
ctrl/b to get back to menu
x to exit menu and ssh connection
Arne
Stephen Hoffman
2021-06-27 02:33:24 UTC
Reply
Permalink
Ok, back to the iLO....
My next question is "what good methods are there for learning to talk
to the iLO?" If I got to play with this beast, at least I can try to
do it correctly.
Setup and general info for using iLO 2:
http://h10032.www1.hp.com/ctg/Manual/c00553302.pdf

Connect the iLO port to the network, configure the iLO for a static IP
address either outside of your DHCP address pool or coordinated with
your DHCP by MAC address, disable IMPI access on the iLO, and then use
ssh to access the iLO. If your ssh is new enough, you'll have to
downgrade the connection. If your ssh is outdated, it'll probably also
not notice the ssh problems with the iLO. Probably want to reset the
default passwords and/or add your own iLO admin user, too.

From a semi-recent Unix or Linux or macOS system: ssh -o
HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 ***@Server.Example.Com

telnet access is also possible, with all the issues incumbent in that path.

How to disable IPMI access from the management processor command menu:
MP:CM> sa -lanipmi d

Remote access monitoring tools can or do require IPMI be enabled,
unfortunately.

iLO 2 scripting: http://h10032.www1.hp.com/ctg/Manual/c02237707.pdf

Some of the iLO docs around are for ProLiant, so you might have to
ignore some parts of the doc related to that.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2021-06-27 03:41:47 UTC
Reply
Permalink
Post by Stephen Hoffman
Ok, back to the iLO....
My next question is "what good methods are there for learning to talk
to the iLO?" If I got to play with this beast, at least I can try to
do it correctly.
http://h10032.www1.hp.com/ctg/Manual/c00553302.pdf
Connect the iLO port to the network, configure the iLO for a static IP
address either outside of your DHCP address pool or coordinated with
your DHCP by MAC address, disable IMPI access on the iLO, and then use
ssh to access the iLO. If your ssh is new enough, you'll have to
downgrade the connection. If your ssh is outdated, it'll probably also
not notice the ssh problems with the iLO. Probably want to reset the
default passwords and/or add your own iLO admin user, too.
From a semi-recent Unix or Linux or macOS system: ssh -o
HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
telnet access is also possible, with all the issues incumbent in that path.
MP:CM> sa -lanipmi d
Remote access monitoring tools can or do require IPMI be enabled,
unfortunately.
iLO 2 scripting: http://h10032.www1.hp.com/ctg/Manual/c02237707.pdf
Some of the iLO docs around are for ProLiant, so you might have to
ignore some parts of the doc related to that.
Thanks ...

My intentions are to change the iLO IP address to be accessable from my
internal network, then after looking at what is there, get VMS V8l.4 2L3
and the latest TCP/IP, install on system disk, and clear the other
disks. Currently has a RAID set-up, but I will do away with that.
Perhaps remove most of the disk drives, unless I can shut them off while
still installed in the box.

One system disk, one disk for backup of system, and one disk with VMS
distribution image. Should be all I need.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2021-06-27 10:03:19 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Ok, back to the iLO....
My next question is "what good methods are there for learning to talk
to the iLO?"  If I got to play with this beast, at least I can try to
do it correctly.
http://h10032.www1.hp.com/ctg/Manual/c00553302.pdf
Connect the iLO port to the network, configure the iLO for a static IP
address either outside of your DHCP address pool or coordinated with
your DHCP by MAC address, disable IMPI access on the iLO, and then use
ssh to access the iLO. If your ssh is new enough, you'll have to
downgrade the connection. If your ssh is outdated, it'll probably also
not notice the ssh problems with the iLO. Probably want to reset the
default passwords and/or add your own iLO admin user, too.
From a semi-recent Unix or Linux or macOS system: ssh -o
HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
telnet access is also possible, with all the issues incumbent in that path.
MP:CM> sa -lanipmi d
Remote access monitoring tools can or do require IPMI be enabled,
unfortunately.
iLO 2 scripting: http://h10032.www1.hp.com/ctg/Manual/c02237707.pdf
Some of the iLO docs around are for ProLiant, so you might have to
ignore some parts of the doc related to that.
Thanks ...
My intentions are to change the iLO IP address to be accessable from my
internal network,
I haven't used any Itanium or iLO, but in a home/lab enviornment, I'd
probably first try with a telnet connection, *if* that gives access to
the same functionallity as ssh with all issues that comes with that.
Post by Dave Froble
then after looking at what is there, get VMS V8l.4 2L3
and the latest TCP/IP, install on system disk, and clear the other disks.
Currently has a RAID set-up, but I will do away with that. Perhaps remove
most of the disk drives, unless I can shut them off while still installed
in the box.
Remove/shutoff disks for noice reasons?
Post by Dave Froble
One system disk, one disk for backup of system,
On a 146 disk you will have room for many backup images files, no reason
to allocate a full disk for a disk-to-disk backup.
Post by Dave Froble
and one disk with VMS distribution image.
Yes, the bootable base distribution. The layeared disks images
can be mounted using LD. No need for physical disks for them.

Maybe you have said before, but what Itenium model is it?

  Should be all I need.
Dave Froble
2021-06-27 15:07:05 UTC
Reply
Permalink
Post by Jan-Erik Söderholm
Post by Dave Froble
Post by Stephen Hoffman
Ok, back to the iLO....
My next question is "what good methods are there for learning to talk
to the iLO?" If I got to play with this beast, at least I can try to
do it correctly.
http://h10032.www1.hp.com/ctg/Manual/c00553302.pdf
Connect the iLO port to the network, configure the iLO for a static IP
address either outside of your DHCP address pool or coordinated with
your DHCP by MAC address, disable IMPI access on the iLO, and then use
ssh to access the iLO. If your ssh is new enough, you'll have to
downgrade the connection. If your ssh is outdated, it'll probably also
not notice the ssh problems with the iLO. Probably want to reset the
default passwords and/or add your own iLO admin user, too.
From a semi-recent Unix or Linux or macOS system: ssh -o
HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
telnet access is also possible, with all the issues incumbent in that path.
MP:CM> sa -lanipmi d
Remote access monitoring tools can or do require IPMI be enabled,
unfortunately.
iLO 2 scripting: http://h10032.www1.hp.com/ctg/Manual/c02237707.pdf
Some of the iLO docs around are for ProLiant, so you might have to
ignore some parts of the doc related to that.
Thanks ...
My intentions are to change the iLO IP address to be accessable from
my internal network,
I haven't used any Itanium or iLO, but in a home/lab enviornment, I'd
probably first try with a telnet connection, *if* that gives access to
the same functionallity as ssh with all issues that comes with that.
Post by Dave Froble
then after looking at what is there, get VMS V8l.4 2L3 and the latest
TCP/IP, install on system disk, and clear the other disks. Currently
has a RAID set-up, but I will do away with that. Perhaps remove most
of the disk drives, unless I can shut them off while still installed
in the box.
Remove/shutoff disks for noice reasons?
Post by Dave Froble
One system disk, one disk for backup of system,
On a 146 disk you will have room for many backup images files, no reason
to allocate a full disk for a disk-to-disk backup.
Post by Dave Froble
and one disk with VMS distribution image.
Yes, the bootable base distribution. The layeared disks images
can be mounted using LD. No need for physical disks for them.
Maybe you have said before, but what Itenium model is it?
Should be all I need.
It is an RX 2660
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Norbert Schönartz
2021-06-27 11:36:12 UTC
Reply
Permalink
I have worked with many different VAX, Alpha and three Itanium (rx2620,
rx2660 ans rx2800i6) systems. Once you know iLO, wou don't want to miss
it. And it is really not that complicated.

For some iLO variants ssh support required an extra license, so maybe
your machine does not support it. Then I recommend using telnet, if your
environment is sufficiently isolated from the internet.

However, for both ssh and telnet you must have the login credentials and
know the network configuration. If you don't, you should use the serial
iLO console which always works (normally at 9600 baud) if you have
physical access to the system. From the serial console you can then set
the parameters for ssh or telnet access through the network port.

For the rx2620 you need a special cable to access the serial port since
the serial port is part of a special connector which has some other
additional functionality (don't rember which). Maybe I could find out
how to solder a suitable cable if you need it. For the rx2660 and rx2800
the serial iLO port has a standard 9 pin connector, if I remember correctly.

And I would use RAID unless the machine is a rx2660 with only the
onboard RAID controller which has very poor performance. The performance
with a good RAID controller is much better and it is really easy to
recover from a disk failure even if your backup is not quite current.
Boot the distribution media and use MSA$UTIL to configure the RAID setup
which best fits your needs. And believe me, the noise of the disks is
negigible compared to the noise of the system.
Post by Dave Froble
Post by Stephen Hoffman
Ok, back to the iLO....
My next question is "what good methods are there for learning to talk
to the iLO?"  If I got to play with this beast, at least I can try to
do it correctly.
http://h10032.www1.hp.com/ctg/Manual/c00553302.pdf
Connect the iLO port to the network, configure the iLO for a static IP
address either outside of your DHCP address pool or coordinated with
your DHCP by MAC address, disable IMPI access on the iLO, and then use
ssh to access the iLO. If your ssh is new enough, you'll have to
downgrade the connection. If your ssh is outdated, it'll probably also
not notice the ssh problems with the iLO. Probably want to reset the
default passwords and/or add your own iLO admin user, too.
From a semi-recent Unix or Linux or macOS system: ssh -o
HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
telnet access is also possible, with all the issues incumbent in that path.
MP:CM> sa -lanipmi d
Remote access monitoring tools can or do require IPMI be enabled,
unfortunately.
iLO 2 scripting: http://h10032.www1.hp.com/ctg/Manual/c02237707.pdf
Some of the iLO docs around are for ProLiant, so you might have to
ignore some parts of the doc related to that.
Thanks ...
My intentions are to change the iLO IP address to be accessable from my
internal network, then after looking at what is there, get VMS V8l.4 2L3
and the latest TCP/IP, install on system disk, and clear the other
disks.  Currently has a RAID set-up, but I will do away with that.
Perhaps remove most of the disk drives, unless I can shut them off while
still installed in the box.
One system disk, one disk for backup of system, and one disk with VMS
distribution image.  Should be all I need.
--
Norbert Schönartz
Stephen Hoffman
2021-06-27 15:44:06 UTC
Reply
Permalink
Post by Norbert Schönartz
For the rx2620 you need a special cable to access the serial port since
the serial port is part of a special connector which has some other
additional functionality (don't rember which). Maybe I could find out
how to solder a suitable cable if you need it. For the rx2660 and
rx2800 the serial iLO port has a standard 9 pin connector, if I
remember correctly.
The so-called hydra cable is not necessary for basic operations, and a
DB25 RS-232/EIA-232 cable with limited modem control will connect and
work.

https://support.hpe.com/hpesc/public/docDisplay?docId=c02250882&docLocale=en_US

The hydra cable pinout has been posted around the 'net, and I have a
copy stashed away.

The hydra cable was not the best of ideas.

I usually use the iLO reset sequence and a few IP routing commands to
get the controller to ask for a dynamic address and to then get the iLO
working on a fixed IP address. No serial cables needed. All was
documented in the manuals, IIRC.
Post by Norbert Schönartz
And I would use RAID unless the machine is a rx2660 with only the
onboard RAID controller which has very poor performance.
The Integrity servers were commonly ordered with one of two RAID
controllers internal. The p400 (p410, p411, etc) was slow, and the p800
(p812) was less slow. I think the rx2620 followed this same pattern,
but it's been a while.
--
Pure Personal Opinion | HoffmanLabs LLC
chris
2021-06-27 22:42:06 UTC
Reply
Permalink
Post by Norbert Schönartz
I have worked with many different VAX, Alpha and three Itanium (rx2620,
rx2660 ans rx2800i6) systems. Once you know iLO, wou don't want to miss
it. And it is really not that complicated.
For some iLO variants ssh support required an extra license, so maybe
your machine does not support it. Then I recommend using telnet, if your
environment is sufficiently isolated from the internet.
However, for both ssh and telnet you must have the login credentials and
know the network configuration. If you don't, you should use the serial
iLO console which always works (normally at 9600 baud) if you have
physical access to the system. From the serial console you can then set
the parameters for ssh or telnet access through the network port.
For the rx2620 you need a special cable to access the serial port since
the serial port is part of a special connector which has some other
additional functionality (don't rember which). Maybe I could find out
how to solder a suitable cable if you need it. For the rx2660 and rx2800
the serial iLO port has a standard 9 pin connector, if I remember correctly.
And I would use RAID unless the machine is a rx2660 with only the
onboard RAID controller which has very poor performance. The performance
with a good RAID controller is much better and it is really easy to
recover from a disk failure even if your backup is not quite current.
Boot the distribution media and use MSA$UTIL to configure the RAID setup
which best fits your needs. And believe me, the noise of the disks is
negigible compared to the noise of the system.
If there is a hardware raid controller on the system, I would always
choose a mirrored system root. Very convenient and robust. For example,
on Proliants if a disk fails, just plugin another disk to replace the
failed item and the system automatically rebuids the raid with no
further input. Depending on the controller, hot swap spares can be
configured as well. Have chosen hardware raid in the past even when
modern file systems like zfs are available, for convenience reasons.

Nothing more irritating that having to reinstall a complete system,
configuration and apps...

Chris
Craig A. Berry
2021-06-24 21:36:22 UTC
Reply
Permalink
Because of this...
Post by Stephen Hoffman
iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept isolated.
There are exploits against these, including the CVE-2013-4786
vulnerability.
An external, outboard, out-of-the-server-cabinet management console was
never anybody's preferred solution though, which is why it's all but
disappeared as a viable design for most modern servers; why it all went
embedded.
?

For example, if I want to be able to access an rx2660 console on the
network without setting off alarm bells during periodic penetration
testing, don't I need an "outboard" device behind which I can hide it?
Stephen Hoffman
2021-06-25 20:43:58 UTC
Reply
Permalink
Post by Craig A. Berry
Because of this...
Post by Stephen Hoffman
iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept
isolated. There are exploits against these, including the CVE-2013-4786
vulnerability.
For the older gear many of us here are using, yes. iLO 2 and iLO 3 are
ancient. With fewer parts involved. With segmented management LANs. iLO
5 is current. But 2 and 3 are where we are today, with HPE hardware.
--
Pure Personal Opinion | HoffmanLabs LLC
Eberhard Heuser
2021-06-23 17:47:30 UTC
Reply
Permalink
Do you know if there is a special CPU for the ILO Programm? And if true, could you tell which one?
Eberhard
Post by Stephen Hoffman
Post by k***@gmail.com
Out of band server management like ILO's, DRAC including remote power
mgmt. strategies has been around for decades (early 1980's).
Outboard console was more of a necessity back then, as the earliest VAX
itself was comparatively, well, stupid.
The VAX-11/780 operated as a peripheral of an LSI-11, in a manner of
consideration. Boot the LSI, which then loads and boots Star and
Starlet.
Later VAX systems got somewhat smarter.
Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.
Post by k***@gmail.com
VAX Nautilus and Polarstar systems used external PRO-350/380 PC
systems
Post by k***@gmail.com
to manage (including Poff/Pon, searchable soft log files) VAX
systems.
The Nautilus family used Pro 350 and Pro 380 hardware, with those boxes
renamed as VAX console. The Polarstar family used a MicroVAX II as the
console. The MicroVAX was one of the distinguishing features of
Polarstar. VAX-11/780 used an LSI-11, as mentioned above. The VAX 9000
service processor unit comprised of 4 MicroVAX II processors. Alpha
eventually added RCM and RMC hardware outboard, all the way up to the
entirely gonzo server management network present within the
Marvel-class AlphaServer boxes; AlphaServer GS1280, etc.
IBM used last year's mainframe model as this year's channel controller
as that old joke went, and analogous jokes about VAX consoles.
None of these VAX and Alpha consoles was supported for remote Ethernet
network access, with the gear supporting remote serial access at best.
Early on, this serial access was intended for DEC Field Service to dial
in (modems, remember those?) and diagnose the server.
Yes, some older sites did routinely use terminal servers as a
workaround for remote console access, or used a console app such as
VAXcluster Console System (VCS) or Minicom and serial cabling, or
screen/tmux, etc. And I've remotely tapped into the Marvel internal
network, as have others. These were wildly insecure, by present-day
standards.
HP and HPE iLO, Dell iDRAC, the SuperMicro BMC, and various other
available gear all substantially improve on what the older server
consoles could do, though. Particularly around remote management and
monitoring and automation, and with far better support for server
installation. And with better connection security. (Usually. Somewhat.
See below.)
For lower-end boxes, Intel vPro and AMD Pro management access is
available from various vendors.
iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept
isolated. There are exploits against these, including the CVE-2013-4786
vulnerability.
"There is no resolution to this issue. The authentication process for
the IPMI 2.0 specification mandates that the server send a salted SHA1
or MD5 hash of the requested user's password to the client, prior to
the client authenticating. The BMC returns the password hash for any
valid user account requested. This password hash can be broken using an
offline brute force or dictionary attack. Because this functionality is
a key part of the IPMI 2.0 specification, there is no way to fix the
problem without deviating from the IPMI 2.0 specification."
Meaning you will want to disable IPMI ( MP:CM> sa -lanipmi d ) if
you're not using it, and not on a constrained-access management
network.
And another reason for isolation: iLO 2 and iLO 3 ssh security is badly
ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
--
Pure Personal Opinion | HoffmanLabs LLC
_______________________________________________
Info-vax mailing list
http://rbnsn.com/mailman/listinfo/info-vax_rbnsn.com
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
chris
2021-06-26 14:31:56 UTC
Reply
Permalink
Post by Eberhard Heuser
Do you know if there is a special CPU for the ILO Programm? And if true, could you tell which one?
Eberhard
On most modern servers, the ilo is driven by a separate management
processor on the motherboard, usually an embedded microprocessor
with it's own internal firmware. It talks to, but is completely
separate from the main system cpu. It usually has control over bios
settings and can boot, power up and power down the whole system. Either
serial rs232 or network external interface for communication, again,
separate form the main system processor and peripherals...

Chris
Stephen Hoffman
2021-06-26 17:01:27 UTC
Reply
Permalink
Post by chris
Post by Eberhard Heuser
Do you know if there is a special CPU for the ILO Programm? And if
true, could you tell which one?
On most modern servers, the ilo is driven by a separate management
processor on the motherboard, usually an embedded microprocessor with
it's own internal firmware. It talks to, but is completely separate
from the main system cpu. It usually has control over bios settings and
can boot, power up and power down the whole system. Either serial rs232
or network external interface for communication, again, separate form
the main system processor and peripherals...
Sharing the host processor—similar to the console usage of the host
processor on many VAX, Alpha, or Itanium systems—is rare for management
processors. Harder to power the whole server (almost) all down, and
harder to manage or unwedge or update the host processor if its shared
with management.

iLO 2 follows the pattern described by chris, and the older iLO 2 was
optionally-present¹ and separately orderable.

Other management interfaces are integrated on the mainboard as was
mentioned, connected to both the processor and the network interface,
and this pattern is becoming increasingly common as remote management
becomes standard. Apple tapped its Xserve LOM off the NIC.

Other management systems can use an embedded CPU within the main
processor², such as that provided with Intel vPro and with AMD PRO
management. This is where we're headed with most systems. I'd still not
expect to see the management processor share the main processor,
though. It'll likely be some outboard RISC-V or other processor for
management, and not reusing the main. But who can be sure?

++

It's not just processors within processors. There are processors all
over modern computer designs, not the least of which are lurking within
graphics controllers, and even USB "memory" sticks:
https://metabytezero.blogspot.com/2018/12/greetings-have-you-ever-dreamt-of.html


And where there are processors, there can be—or are—vulnerabilities found:
https://github.com/embedi/amt_auth_bypass_poc
https://www.bleepingcomputer.com/news/security/malware-uses-obscure-intel-cpu-feature-to-steal-data-and-avoid-firewalls/


It would not be a great surprise to learn of malware targeting iLO, nor
of yet more malware targeting OpenVMS.

++

¹I've swapped iLO 2 modules in older Integrity boxes, and I'd expect
that adding an iLO module is possible in others shipped without. Though
do check the iLO connection first. Sometimes sockets can get "left out"
of board builds, depending on the hardware vendor. DEC did that
sometimes, and sometimes filled sockets with epoxy to block usage. I
don't know if HP did this for iLO, though. Check before ordering.

²What we used to think of as a single processor or more recently as a
multi-core is increasingly now a heterogeneous collection of cores
(including big.LITTLE designs for performance and efficiency common on
Arm, ML-related support processors, and hybrid cores soon arriving on
Intel x86-64 with Alder Lake), for embedded management processors
(Intel vPro / AMT, AMD PRO, etc), and processors for communications and
I/O reminiscent of IBM channel controllers.
--
Pure Personal Opinion | HoffmanLabs LLC
vaxinf@gmail.com
2021-06-24 14:03:38 UTC
Reply
Permalink
Do you know if there is a special CPU for the ILO Programm? And if true,
could you tell which one?
Eberhard

Am 23. Juni 2021 18:58:40 MESZ schrieb Stephen Hoffman via Info-vax
<info-***@rbnsn.com>:

On 2021-06-22 23:27:16 +0000, <***@gmail.com> said:

Out of band server management like ILO's, DRAC including remote
power mgmt. strategies has been around for decades (early 1980's).


Outboard console was more of a necessity back then, as the earliest VAX
itself was comparatively, well, stupid.

The VAX-11/780 operated as a peripheral of an LSI-11, in a manner of
consideration. Boot the LSI, which then loads and boots Star and
Starlet.

Later VAX systems got somewhat smarter.

Remote management was something comparatively new for OpenVMS folks,
first arriving with Itanium for many of the OpenVMS sites around.

VAX Nautilus and Polarstar systems used external PRO-350/380 PC
systems to manage (including Poff/Pon, searchable soft log
files) VAX systems.


The Nautilus family used Pro 350 and Pro 380 hardware, with those boxes
renamed as VAX console. The Polarstar family used a MicroVAX II as the
console. The MicroVAX was one of the distinguishing features of
Polarstar. VAX-11/780 used an LSI-11, as mentioned above. The VAX 9000
service processor unit comprised of 4 MicroVAX II processors. Alpha
eventually added RCM and RMC hardware outboard, all the way up to the
entirely gonzo server management network present within the
Marvel-class AlphaServer boxes; AlphaServer GS1280, etc.

IBM used last year's mainframe model as this year's channel controller
as that old joke went, and analogous jokes about VAX consoles.

None of these VAX and Alpha consoles was supported for remote Ethernet
network access, with the gear supporting remote serial access at best.
Early on, this serial access was intended for DEC Field Service to dial
in (modems, remember those?) and diagnose the server.

Yes, some older sites did routinely use terminal servers as a
workaround for remote console access, or used a console app such as
VAXcluster Console System (VCS) or Minicom and serial cabling, or
screen/tmux, etc. And I've remotely tapped into the Marvel internal
network, as have others. These were wildly insecure, by present-day
standards.

HP and HPE iLO, Dell iDRAC, the SuperMicro BMC, and various other
available gear all substantially improve on what the older server
consoles could do, though. Particularly around remote management and
monitoring and automation, and with far better support for server
installation. And with better connection security. (Usually. Somewhat.
See below.)

For lower-end boxes, Intel vPro and AMD Pro management access is
available from various vendors.

iLO 2 and iLO 2 are hardware limited and which reportedly constrains
what is possible with the hardware, and are nowadays best kept
isolated. There are exploits against these, including the CVE-2013-4786
vulnerability.

"There is no resolution to this issue. The authentication process for
the IPMI 2.0 specification mandates that the server send a salted SHA1
or MD5 hash of the requested user's password to the client, prior to
the client authenticating. The BMC returns the password hash for any
valid user account requested. This password hash can be broken using an
offline brute force or dictionary attack. Because this functionality is
a key part of the IPMI 2.0 specification, there is no way to fix the
problem without deviating from the IPMI 2.0 specification."

Meaning you will want to disable IPMI ( MP:CM> sa -lanipmi d ) if
you're not using it, and not on a constrained-access management network.

And another reason for isolation: iLO 2 and iLO 3 ssh security is badly
down-revision, which means connecting using something similar to this:
ssh -o HostKeyAlgorithms=ssh-rsa,ssh-dss -o
KexAlgorithms=diffie-hellman-group1-sha1 -o Ciphers=aes128-cbc,3des-cbc
-o MACs=hmac-md5,hmac-sha1 ***@Server.Example.Com
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Simon Clubley
2021-06-21 17:58:53 UTC
Reply
Permalink
Post by Rich Jordan
I don't recall that HP ever hid iLO firmware behind a paywall or made full firmware kits the only way to get ilo firmware.
BTW, I've had a bit of a look because I was curious but the only old
standalone iLO firmware pages I could find were for x64 (ie x86-64)
and not Itanium.

Everything for Itanium, including old pages, appears to be in a bundle.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Loading...