VMS and the Internet of Things (IoT)

[Simon Clubley]

I've seen a number of posts recently about VMS and it's possible role
in an Internet of Things (IoT) environment.

However, it appears to me that people are talking at cross-purposes
when talking about the IoT because the term itself is so vaguely
defined and as such people appear to have their own differing and
unstated assumptions about what the IoT actually is.

As such, it might be a good idea if people state what they mean by
the IoT and how they see the role that VMS has in it, because right
now I am not seeing a major role for VMS.

Here's my initial pass at defining what I think the IoT is all about
when I hear that phrase and why I think the above about VMS:

I think of the IoT as being a three level architecture with sensors
on devices at the lowest level, some kind of coordinator or
controller within the facility at the medium level, and remote
servers (if needed) at the highest level.

At the lowest level, the sensors on devices level, there's absolutely
no role for VMS at all. Most of these are going to be Cortex-M0/M4
level CPUs if even that as in some cases these might just be small
8-bit devices or even dumb sensors wired directly into the facility
controller.

The medium level facility controller is where things may start to get
more interesting but I don't see a role for VMS here either even if
you ignore that fact that VMS will not currently run on the
architectures typically in use here.

This facility controller is going to be a small low power box which
can probably be wall mounted; think something the size of a Beaglebone
Black or a Raspberry Pi with a box and little LCD/touch panel wrapped
around it.

It's unlikely to be some desktop sized PC box with fans going and
consuming greater than a couple of hundred watts. Something like the
Cortex-A8 may even be overkill for many of these controllers. Regardless,
this is RTOS or embedded Linux territory where you can quickly put
together a BSP for the specific SBC in use (assuming one doesn't
already exist).

Only at the highest level, the remote server level, can I begin to see
a viable role for VMS. However, I am not seeing what VMS would bring
to the table here over the other existing options (and please don't
say security).

Security on the IoT devices is a joke and is a joke in ways that
changing the remote server operating system will have very little
effect on. Some of the security issues appear to be occuring because
of the mindset which is sometimes present when writing the software
for these devices.

So that's my take on the IoT. What's yours and where do you see a
possible place for VMS within the IoT world ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[Jan-Erik Soderholm]

You clearly have a reasonable view of all of the above... :-)

VMS has a role in this new IoT-world, when the IoT-world
have a need for data that is already in some VMS application.

I just this Friday had a discussion with a guy who is responsable
a new cloud based solution to keep track of products world-wide.
These products can be regarded as (a kind of) IoT-devices.

We discussed what possible integrations there might be with the
prodution support system (VMS based) I'm system analyst for.

Today, more and more products have their own processors with
firmware revisions to keep track of and configuration data that
need to be know for a service organisation when product arrives
dead to the service center. If you have VMS systems that are part
of the production environment, you need these integrations.

So the answer is that VMS has a role here, when the IoT-devices
has a need for the data that the VMS system (already) can provide.

[David Froble]

As usual, I know nothing ...

:-)

My first questions are, what are the purposes of having this computerization in
regular household appliances and such? If it's to monitor the devices and be
helpful, yes, that can be a good thing. Then the question becomes, for whom is
it helpful? If it is for the likes of Google to track what I'm doing, screw
that idea. If it's for some central system in my home to track some data, such
as the temperature in my freezer and refrigerator, that can be a good thing,
warning me if I got or might soon have problems. Also doing things such as
controlling lights, and other things remotely. Cameras to see if the MaCaws are
behaving. (Yeah, right, as if that will ever happen.)

The information could help with remote diagnostics before a repairman makes a
service call. As an example, I got a new refrigerator last year. Wasn't
keeping things from going bad. So I placed a service call, under the warranty.
Service guy comes out, checks the info, says it's working. Then looks and
says "I've seen this before, you're blocking the path from the freezer, cold air
cannot get in". Well, duh, dumb Dave strikes again. Then he says "I don't know
why the manufacturers don't strongly suggest keeping the top shelf more open".

So, two points. First, me being able to monitor the problem would have saved
throwing out lots of Milk and such. And second, the service call could have
cost much less if an on-site visit wasn't required.

So, yeah, lots of potential.

And yeah, lots of questions.

However, I'm not sure the question of how VMS fits into all this is relevant.
The real question is what applications will be useful. If some run on VMS, and
VMS is available for the minimal HW, sure, it could be used. In the past VMS
was targeted at some process control and such. Not so much, or at all, more
recently. Sort of hard to beat the cost of free *ix that isn't going to need
any support contracts. VMS would need to be free for such use. I don't see
that helping VMS all that much, but, what do I know?

[Jan-Erik Soderholm]

Agree with you there. A lot of this IoT hype is just, hype.

In my case it is more about professional garden and forest equipment
that gets more and more "intelligent". Think of automatic lawn-movers,
they today have GPS satnav and cellular "phone-home" features. Even
"simple" chainsaws today have processors in the carburators that are
individualy programmed and callibrated. All this information has to
be handled in a way so that service and repair shops can access it.

I do not see that all this is techinicaly anything new. And it doesn't
have anything particular to do eith any specicific operating system.

[Kerry Main]

My references to OpenVMS and IoT were in respect to
OpenVMS and future architectures - coming (X86-64) and
potential (ARM). This would be post OpenVMS V9+ (ARM -
V10?) - after the new file system and new TCPIP stack.
X86-64 in small boxes/appliances are valid thin "smart"
clients just as much as lower power ARM devices in even
smaller thin client "smart" devices are likely.

While there are some niche players in this thin smart
client market, the big OS to beat for OpenVMS on these
smaller devices is obviously Linux. Microsoft is on a
self-destruct model and is following in the DEC footsteps
of upsetting Customers and raising prices through the roof
at a time when Customers are under extreme pressures to
reduce IT costs. I see Microsoft share of the server
market dropping significantly in the future. Also,
OpenVMS/Linux can boot and run their latest versions in
1GB of memory (or less my Alpha servers boot latest
supported versions in 256MB) - try that with any version
of Windows Servers (or desktop).

110% pure speculation on my part, but I also suspect there
will be new licensing model options in OpenVMS V9+.

I stated "secure" thin client, because at some point, this
will need to happen. You cannot have driver-less cars or
smart traffic light systems being hacked. Unfortunately,
like what all too often happens, in the rush to get
products out the door and be first to market, the last
thing on developers/companies minds is security. As we all
know here, real security needs to be architected into the
entire solution - not added on later.

The more tiers, the higher risk of the secure chain being
breached. When "smart" thin clients are combined with
other technologies like IPV6 (low level thin client
devices can be identified by MAC addresses), it gets a lot
more interesting in terms of consolidating multiple
network tiers and returning more to a traditional secure
thin "smart" client and secure back ends.

Yes, IPV6 has been slow to be adopted, and there will be
security issues with IPV6 to be addressed, but it is
coming. There are no other feasible options to replace
IPV4.

Btw - as I stated in my earlier thread, this is a lot of
hype bundled in with this term IoT - you can literally
define it anyway you like. That's what everyone including
media analysts and vendors do anyway.

This is not unlike Public Clouds, OpenStack, Software
Defined Networks (SDN), and early industry hype of SOA
(granted, SOA does have technical validity, but not in the
way most of the industry hyped it for years i.e. SOA
everything).

[snip..]


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Stephen Hoffman]

On 2016-09-11 10:16:52 +0000, Simon Clubley said:

> So that's my take on the IoT. What's yours and where do you see a
> possible place for VMS within the IoT world ?

OpenVMS is ill-suited as an embedded operating system or as an
intermediate controller or aggregator. It's been priced out of those
markets for decades. That's also without discussing
currently-missing or currently-weak features and hardware support and
power management that would be desirable or required in those markets,
and (the lack of) which will preclude OpenVMS in those deployments.

The only way VSI plays at the lower-end tiers is with some new product
or some new variant of VAX ELN. Not with OpenVMS. Cheaper,
higher-volume, purpose-built, etc... Then integrate OpenVMS with that
client. Then some savvy marketing.

I expect to see some OpenVMS boxes acting as mid-range network servers
and some of those will get updated to receive notifications and data
from embedded sensors and aggregation; what can be called sensor or
probes or PLCs in some environments. Those markets and those
capabilities have been around for decades with OpenVMS, and — ignoring
DTLS, authentication and other security requirements that can arise in
newer deployments — are nothing particularly new. But I expect there
will be few IoT- or industrial-control-related new server deployments
outside of the installed base.

The way VSI plays here — for new customers and wholly new deployments,
looking for mid-range servers — is with all of the work on "the
whiteboard", and probably some other bits specific to industrial
control and distributed networking, as well as the requisite
development and deployment tools and support, and with the requisite
savvy marketing.



--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Soderholm]

Den 2016-09-11 kl. 15:23, skrev Kerry Main:

>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On
>> Behalf Of Jan-Erik Soderholm via Info-vax

With due respect, I didn't wrote one single word of the
texts below...

Jan-Erik.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Stephen Hoffman via Info-vax
> Sent: 11-Sep-16 9:36 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS and the Internet of Things
> (IoT)
>

> On 2016-09-11 10:16:52 +0000, Simon Clubley said:
>
> > So that's my take on the IoT. What's yours and where do
> you see a
> > possible place for VMS within the IoT world ?
>
> OpenVMS is ill-suited as an embedded operating system
> or as an
> intermediate controller or aggregator. It's been priced
> out of those
> markets for decades. That's also without discussing
> currently-missing or currently-weak features and
> hardware support and
> power management that would be desirable or required
> in those markets,
> and (the lack of) which will preclude OpenVMS in those
> deployments.
>

[snip..]

You are looking at solving requirements of the future through experiences gained via the rear view window of the past.

The OpenVMS of the past with HP and its expensive licenses on proprietary, expensive HW designed to compete with Solaris and AIX should not be compared to OpenVMS on X86-64 (possibly ARM??) with a new TCPIP stack, new file system, new security features and (hopefully) a new licensing model with V9+ versions designed to compete with other OS's on the X86-64 platform.

I view today's world as being a transition period where VSI is rapidly gearing up to address the requirements of the future.

Remember - No matter what technology is leading in market share today, it will be replaced at some point in the future with something else.

The world is changing from a very distributed world to one that may still maintain a tiered App model, but these tiers are being physically deployed on heavily centralized physical server infrastructures with TB of local memory. I would also suggest we may also start seeing these tiers being consolidated as well in order to reduce overall solution latency.

OpenVMS may not have that many advantages in a heavily distributed world of the past 20 years, but it sure has loads of experience in a heavily centralized world.

Heck, the future is wide open for new solutions.

:-)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Jan-Erik Soderholm via Info-vax
> Sent: 11-Sep-16 9:53 AM
> To: info...@rbnsn.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: Re: [Info-vax] VMS and the Internet of Things
> (IoT)
>

> Den 2016-09-11 kl. 15:23, skrev Kerry Main:
>
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax...@rbnsn.com]
> On
> >> Behalf Of Jan-Erik Soderholm via Info-vax
>
> With due respect, I didn't wrote one single word of the
> texts below...
>
> Jan-Erik.
>

My bad - snip error on my side.

[Stephen Hoffman]

On 2016-09-11 14:44:47 +0000, Kerry Main said:

> You are looking at solving requirements of the future through
> experiences gained via the rear view window of the past.

Well, I am still using OpenVMS.

> The OpenVMS of the past with HP and its expensive licenses on
> proprietary, expensive HW designed to compete with Solaris and AIX
> should not be compared to OpenVMS on X86-64 (possibly ARM??) with a new
> TCPIP stack, new file system, new security features and (hopefully) a
> new licensing model with V9+ versions designed to compete with other
> OS's on the X86-64 platform.

Call back when at least some of that's available, and when the x86-64
product prices and related data is published?

> I view today's world as being a transition period where VSI is rapidly
> gearing up to address the requirements of the future.
>
> Remember - No matter what technology is leading in market share today,
> it will be replaced at some point in the future with something else.

Or it won't be needed.

> The world is changing from a very distributed world to one that may
> still maintain a tiered App model, but these tiers are being physically
> deployed on heavily centralized physical server infrastructures with TB
> of local memory. I would also suggest we may also start seeing these
> tiers being consolidated as well in order to reduce overall solution
> latency.

I think I just won buzzword bingo.

> OpenVMS may not have that many advantages in a heavily distributed
> world of the past 20 years, but it sure has loads of experience in a
> heavily centralized world.

OpenVMS has to get there first.

> Heck, the future is wide open for new solutions.
> :-)

Sure. Being behind in a competitive market isn't a fun place to be,
as you're largely left to compete on price, or exit. If you haven't
entirely missed the market window for whatever you're looking to sell.

[Simon Clubley]

On 2016-09-11, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2016-09-11 10:16:52 +0000, Simon Clubley said:
>
>> So that's my take on the IoT. What's yours and where do you see a
>> possible place for VMS within the IoT world ?
>
> OpenVMS is ill-suited as an embedded operating system or as an
> intermediate controller or aggregator. It's been priced out of those
> markets for decades. That's also without discussing
> currently-missing or currently-weak features and hardware support and
> power management that would be desirable or required in those markets,
> and (the lack of) which will preclude OpenVMS in those deployments.
>

I agree. The only possible role I am seeing for VMS is in the remote
server role; I simply don't see it being used in the middle tier of
my 3 level model, running inside a box attached to a wall somewhere
and with a touch screen/LCD interface.

> The only way VSI plays at the lower-end tiers is with some new product
> or some new variant of VAX ELN. Not with OpenVMS. Cheaper,
> higher-volume, purpose-built, etc... Then integrate OpenVMS with that
> client. Then some savvy marketing.
>

A new VAXELN, restructured to run on modern architectures, isn't going
to happen these days; it's time is over.

This is an example of what you can get for free in the RTOS world:

https://www.rtems.org/

If you want something that you pay for and which requires and takes
advantage of an MMU then there's QNX.

A new VAXELN doesn't stand a chance against the established players.

> I expect to see some OpenVMS boxes acting as mid-range network servers
> and some of those will get updated to receive notifications and data
> from embedded sensors and aggregation; what can be called sensor or
> probes or PLCs in some environments. Those markets and those
> capabilities have been around for decades with OpenVMS, and — ignoring
> DTLS, authentication and other security requirements that can arise in
> newer deployments — are nothing particularly new. But I expect there
> will be few IoT- or industrial-control-related new server deployments
> outside of the installed base.
>

Jan-Erik's point about existing systems being a source of IoT data is
a good one and one I had not considered. However, that remote server
situation only covers existing VMS installations.

[Simon Clubley]

On 2016-09-11, Kerry Main <kemain...@gmail.com> wrote:
>
> The OpenVMS of the past with HP and its expensive licenses on
> proprietary, expensive HW designed to compete with Solaris and AIX
> should not be compared to OpenVMS on X86-64 (possibly ARM??) with a
> new TCPIP stack, new file system, new security features and
> (hopefully) a new licensing model with V9+ versions designed to
> compete with other OS's on the X86-64 platform.
>

I'm confused. Are you suggesting that VMS can occupy the middle tier
in my 3 tier model and be the OS that runs inside the controller box
which is located within the facility itself and which talks directly
to the sensors ?

If that's the case, I'm curious how much embedded knowledge you have
because I am absolutely not seeing VMS as being suitable for that
position for these reasons:

1) It would have to run on ARM for one thing (x86-64 is so overpowered
by comparison, and with power and hardware space requirements to match,
that it would be like using a supercomputer to calculate your payroll),

2) VMS would have to be structured to allow you to create a BSP to
allow VMS to run on your custom hardware and

3) Device driver writing under VMS would have to be a lot more modern
than it currently is.

The only possible viable role I am seeing for VMS is as the remote
server that the IoT device/controller talks to.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Stephen Hoffman via Info-vax
> Sent: 11-Sep-16 11:10 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS and the Internet of Things
> (IoT)
>

No, it's called reading latest whitepapers from many
sources and looking at what Customers are doing in major
DC consolidation projects (which I have done plenty of).

It's called looking at what Google is doing with big core
PowerX systems.

> > OpenVMS may not have that many advantages in a
> heavily distributed
> > world of the past 20 years, but it sure has loads of
> experience in a
> > heavily centralized world.
>
> OpenVMS has to get there first.
>
> > Heck, the future is wide open for new solutions.
> > :-)
>
> Sure. Being behind in a competitive market isn't a fun
> place to be,
> as you're largely left to compete on price, or exit.
If you
> haven't
> entirely missed the market window for whatever you're
> looking to sell.
>

Just look at Apple's history (which includes a complete OS
platform change) .. small company to top of the market to
almost broke to top of the market .. now fighting with
Samsung.

If one keeps saying "we are doomed", then they surely will
be.

If Microsoft had that attitude, WordPerfect would still be
the standard word processing product in the industry.
Those that have some grey hair will remember that back in
the day , there was no more entrenched product than
WordPerfect.

Nothing stays on top forever.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Simon Clubley via Info-vax
> Sent: 11-Sep-16 1:56 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] VMS and the Internet of Things
> (IoT)
>

You missed my earlier comment in this thread -

" My references to OpenVMS and IoT were in respect to
OpenVMS and future architectures - coming (X86-64) and
potential (ARM). This would be post OpenVMS V9+ (ARM -
V10?) - after the new file system and new TCPIP stack.
X86-64 in small boxes/appliances are valid thin "smart"
clients just as much as lower power ARM devices in even
smaller thin client "smart" devices are likely. "

[snip..]

[Scott Dorsey]

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>I'm confused. Are you suggesting that VMS can occupy the middle tier
>in my 3 tier model and be the OS that runs inside the controller box
>which is located within the facility itself and which talks directly
>to the sensors ?
>
>If that's the case, I'm curious how much embedded knowledge you have
>because I am absolutely not seeing VMS as being suitable for that
>position for these reasons:
>
>1) It would have to run on ARM for one thing (x86-64 is so overpowered
>by comparison, and with power and hardware space requirements to match,
>that it would be like using a supercomputer to calculate your payroll),

Well, by the time things actually come around, it might not be ARM
anymore, and we might have some cheap stripped down x86 low power x86
stuff from some Chinese fab too. So that might not need to happen.

>2) VMS would have to be structured to allow you to create a BSP to
>allow VMS to run on your custom hardware and

That isn't going to happen.

>3) Device driver writing under VMS would have to be a lot more modern
>than it currently is.

I would say that this is actually a plus for VMS, the fact that the
device driver configuration is relatively crude. That means that much
less to go wrong and become exploited.

>The only possible viable role I am seeing for VMS is as the remote
>server that the IoT device/controller talks to.

I think even that is kind of doubtful. Perhaps the original poster
is confusing VMS with VaxELN?
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Simon Clubley]

On 2016-09-11, Kerry Main <kemain...@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On
>> Behalf Of Simon Clubley via Info-vax
>> Sent: 11-Sep-16 1:56 PM
>> To: info...@rbnsn.com
>> Cc: Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] VMS and the Internet of Things
>> (IoT)
>>

Having VMS run on ARM is only the first step.

VMS needs to be structured so that you can create a BSP so VMS will
run on your custom hardware and you need the tools to, among other
things, generate custom VMS images for your hardware and application
that you can burn to flash and run VMS and your application from that
same flash.

VMS also needs to _seriously_ up it's game when it comes to low
level stuff such as device driver writing.

Then once you have done all this, you need to ask what advantages
does VMS have over the established embedded players ?

BTW, Kerry, have you ever done any embedded development ?

Have you ever written any code which runs under a RTOS and have you
ever been through the process of generating a custom RTOS image
which includes your code to run on your own hardware ?

Have you ever gone through the process of writing your own BSP
so that you can bring up an RTOS on your own hardware ?

The reason I am asking these questions is not to be difficult but
to try and get you to think about how embedded development is very
different from "big systems" developement.

Whether you realise it or not, you appear to still have a "big
systems" mindset when you are talking about the embedded world.
That mindset doesn't apply to the embedded controller devices that
may make up many of the IoT controllers and indeed those embedded
devices have priorities of their own which don't apply to the "big
systems" world.

Simon.

PS: Please fix your line wrapping. You currently look as if you are
typing on a VIC20. :-)

[Kerry Main]

No, I'm not a programmer.

Having stated this, for over a decade or so,
OpenVMS was the defacto std for running process
control systems in many manufacturing
environments. The competition was HP-UX, but was
nowhere near as popular as OpenVMS.

It is still used in a number of manufacturing
environments that I know of like steel mills, chip
manufacturing and other mfging / utility
environments.

Btw, don't forget the IoT hype is not just about
embedded systems - its thin clients and there are
a wide range of devices that would likely not be
called embedded systems.

[snip ..]

>
> PS: Please fix your line wrapping. You currently
look as if
> you are
> typing on a VIC20. :-)
>

I recently upgraded my Outback client and the
external text wrapping is set lowered to 50.

[Paul Sture]

On 2016-09-11, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> PS: Please fix your line wrapping. You currently look as if you are
> typing on a VIC20. :-)

For those wondering what a VIC20 was:

<https://en.wikipedia.org/wiki/Commodore_VIC-20>

"The VIC-20 (Germany: VC-20;[3] Japan: VIC-1001) is an 8-bit home
computer that was sold by Commodore Business Machines. The VIC-20 was
announced in 1980,[4] roughly three years after Commodore's first
personal computer, the PET. The VIC-20 was the first computer of any
description to sell one million units"

:-)

--
It was untidy, so got unplugged.
It was unplugged, so got thrown away.

[roger...@gmail.com]

On Sunday, September 11, 2016 at 10:36:28 AM UTC-7, Simon Clubley wrote:
> This is an example of what you can get for free in the RTOS world:
>
> https://www.rtems.org/
>
> If you want something that you pay for and which requires and takes
> advantage of an MMU then there's QNX.

Well, technically, anything running on a Cortex-A8 processor (such as
the AM3358 used in the BeagleBone Black) makes use of the CPU, because
it must to enable the cache; cacheability information comes from the
MMU.

Yes, I'm annoyed about it.
--
roger ivie
roger...@gmail.com

[roger...@gmail.com]

On Sunday, September 11, 2016 at 8:37:53 PM UTC-7, roger...@gmail.com wrote:
> On Sunday, September 11, 2016 at 10:36:28 AM UTC-7, Simon Clubley wrote:
> > This is an example of what you can get for free in the RTOS world:
> >
> > https://www.rtems.org/
> >
> > If you want something that you pay for and which requires and takes
> > advantage of an MMU then there's QNX.
>
> Well, technically, anything running on a Cortex-A8 processor (such as
> the AM3358 used in the BeagleBone Black) makes use of the CPU,

^^^
MMU. I hate it when I don't notice a typo until after I post the message.
--
roger ivie
roger...@gmail.com

[Simon Clubley]

On 2016-09-11, roger...@gmail.com <roger...@gmail.com> wrote:
> On Sunday, September 11, 2016 at 10:36:28 AM UTC-7, Simon Clubley wrote:
>> This is an example of what you can get for free in the RTOS world:
>>
>> https://www.rtems.org/
>>
>> If you want something that you pay for and which requires and takes
>> advantage of an MMU then there's QNX.
>
> Well, technically, anything running on a Cortex-A8 processor (such as

> the AM3358 used in the BeagleBone Black) makes use of the MMU, because

> it must to enable the cache; cacheability information comes from the
> MMU.
>

[I've added in your CPU to MMU correction from your later post.]

> Yes, I'm annoyed about it.

Yes, it is annoying as I've been there and had to handle that (multiple
times :-)) but setting up a minimal set of static page tables for the
MMU is easy enough.

In your BSP or bare metal startup code, all you need is a minimal table
of several entries which gives a top level view of which memory areas
need mapping and with what memory attributes.

You can then have a little MMU routine which walks through your table
and builds a level 1 section based page table (you don't need the
level 2 page based descriptors).

This is the approach I took to solve this and it's working fine for me.

[Simon Clubley]

On 2016-09-11, Kerry Main <kemain...@gmail.com> wrote:
>> -----Original Message-----
>> From: Info-vax
> [mailto:info-vax...@rbnsn.com] On
>> Behalf Of Simon Clubley via Info-vax
>> Sent: 11-Sep-16 3:19 PM
>> To: info...@rbnsn.com
>> Cc: Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> Subject: Re: [Info-vax] VMS and the Internet of
> Things
>> (IoT)
>>

>> Have you ever written any code which runs under
> a RTOS
>> and have you
>> ever been through the process of generating a
> custom
>> RTOS image
>> which includes your code to run on your own
> hardware ?
>>
>
> No, I'm not a programmer.
>
> Having stated this, for over a decade or so,
> OpenVMS was the defacto std for running process
> control systems in many manufacturing
> environments. The competition was HP-UX, but was
> nowhere near as popular as OpenVMS.
>

Unfortunately Kerry times change and so do requirements. Embedded
systems are no longer great big boxes that you boot from hard disks
or other external devices and which have only a few system hardware
configurations that are fully known to the manufacturer of the
operating system in question.

>
>>
>> PS: Please fix your line wrapping. You currently
> look as if
>> you are
>> typing on a VIC20. :-)
>>
>
> I recently upgraded my Outback client and the
> external text wrapping is set lowered to 50.
>

The problem is that you are mangling the messages you are replying
to as the messages are not being reflowed to 50 characters but the
lines are simply being chopped in two. See what your client did to
my paragraph above.

Simon.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com]
> On Behalf Of Simon Clubley via Info-vax
> Sent: 12-Sep-16 8:43 AM
> To: info...@rbnsn.com
> Cc: Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP>
> Subject: Re: [Info-vax] VMS and the Internet of
Things
> (IoT)

[snip..]

>
> Unfortunately Kerry times change and so do
> requirements. Embedded systems are no longer great
> big boxes that you boot from hard disks or other
> external devices and which have only a few system
> hardware configurations that are fully known to the
> manufacturer of the operating system in question.
>

Well, while all things certainly do change, here is
good example of where OpenVMS is today being promoted
as an integral part of a modern process control ISV
solution: (multi-platform solution that includes
OpenVMS).

http://www.vista-control.com/
http://www.vista-control.com/operating_systems.html
http://www.vista-control.com/pdf/vsystem%20description.
pdf

And yes, OpenVMS is still today used in many mission
critical process control environments like SCADA.

Posted 2015 SCADA testimonial:
http://www.qeisolutions.com/uploads/2/6/1/8/26185369/ne
w_jersey_municipal_selects_qei__for_ilex_system_upgrade
_qei.pdf
"Because of past experience with SCADA, the city wanted
to make sure that the new system would not only address
the needs of 2013/2014, but would prepare them for the
emerging smart grid environment of the next several
decades."

"The original system architecture of multiple SCADA
server with traditional hardwired remote terminal units
was to be expanded to include physical separation of
the servers (for increase hardening to catastrophic
failure) and the full incorporation of Intelligent
Electronic devices (IEDs). In order to avoid the
previous problem with obsoleting of the OS/2 operating
system, a well-established and continuing SCADA
operating system was required, and this was addressed
through the QEI use of OpenVMSR from Hewlett Packard.
The worldwide use of OpenVMS in mission critical
applications will help insure continuing support and
enhancement for the life of the system"

Does this answer the question of being capable of
addressing the mid-tier layer in the IoT world??

[Stephen Hoffman]

On 2016-09-11 18:35:20 +0000, Kerry Main said:

> No, it's called reading latest whitepapers from many sources and
> looking at what Customers are doing in major DC consolidation projects
> (which I have done plenty of).

Yet I wonder at your dismissal of DVCS, and around whether you realize
the risk of changes to the arbitrage calculations involving the future
of app stacking. DYODD, etc.

> It's called looking at what Google is doing with big core PowerX systems.

You've dismissed what Google uses and does in other (software) cases,
but somehow Power is interesting?

IMO, Power is a very bad porting target.

Greatly slowing OpenVMS development for another half-decade past the
x86-64 port and further fragmenting the installed base for what is an
expensive and boutique microprocessor is not a good strategy.

Sure, it's fast. But how many folks running OpenVMS now really need
the performance delta between a top-end Xeon and what Power provides,
at the cost of a whole 'nother round of software portage?

That an advertising company experiments with other hardware given they
already develop their own custom server platforms — that Power deal
might well get the Google folks a better deal for Intel parts, too — is
not a surprise. They're off looking at self-driving cars and at more
than a few other advertising-related projects, too.

> Just look at Apple's history (which includes a complete OS platform
> change) .. small company to top of the market to almost broke to top
> of the market ..

Unicorns do occasionally arise.

But like the BUNCH and any number of other OS vendors over the years,
more than a few OS vendors have failed.

As for emulating Apple, VSI hasn't channeled enough amperage into their
RDF generator.

The VSI folks have some work ahead to identify and to reach one or more
target markets beyond the installed base.

Tossing out what's not going to help them reach their target market(s), too.

Apple got big on iOS and mobile devices and design acumen and their
resulting hardware sales — for purchasing parts, they approach a
monopsony — none of which is currently an option for VSI.

If that VSI target market even involves Power over the next decade, I'd
be surprised.

> now fighting with Samsung.

The chaebols are an interesting construct. As for the competition,
follow the cash around. That's what VSI needs to accrue. Apple is
good at that, too.

> If one keeps saying "we are doomed", then they surely will be.
>
> If Microsoft had that attitude, WordPerfect would still be the standard
> word processing product in the industry. Those that have some grey hair
> will remember that back in the day , there was no more entrenched
> product than WordPerfect.
>
> Nothing stays on top forever.

And you'd be nuts to try to compete head-on with Microsoft Office now, too.

But yes, markets can and do change, and new markets — mobile clients,
for instance — can appear. Whether VSI can expand the installed base?
Power isn't all that and a bag of chips, though.

[Stephen Hoffman]

On 2016-09-11 18:39:48 +0000, Kerry Main said:

>>
>> I'm confused. Are you suggesting that VMS can occupy the middle tier in
>> my 3 tier model and be the OS that runs inside the controller box which
>> is located within the facility itself and which talks directly
>> to the sensors ?

>> ...

> You missed my earlier comment in this thread -
>
> " My references to OpenVMS and IoT were in respect to OpenVMS and
> future architectures - coming (X86-64) and potential (ARM). This would
> be post OpenVMS V9+ (ARM - V10?) - after the new file system and new
> TCPIP stack. X86-64 in small boxes/appliances are valid thin "smart"
> clients just as much as lower power ARM devices in even smaller thin
> client "smart" devices are likely. "

I suspect Simon saw your comment. I certainly did. Which still
leaves more than just Simon confused. This isn't just about ARM,
either, and a new TCP/IP stack — that's probably closer to what's
common, but whether it catches up with what's commonplace? Embedded
is rather more than the processor architecture, too — it's the price of
the whole box and there are more than a few cases where using
less-than-64-bit processors and very constrained memory configurations
is necessary — eliminating a single screw is a big deal in the embedded
market, as can be using some lower-end and/or non-SBSA ARM SoC that may
not or will not have native OpenVMS support — and then there's the
software and networking capabilities, distributed OS and app updates,
and even sorting out the system licensing if that's anything like the
current LMF morass. Development tools, too. And of course the
OpenVMS pricing is a factor — far lower than the applications and
servers license tier, or whatever DEC called that license.

[Stephen Hoffman]

On 2016-09-12 13:34:21 +0000, Kerry Main said:

> Does this answer the question of being capable of addressing the
> mid-tier layer in the IoT world??

That OpenVMS can do classic SCADA is known.

There's more to what's necessary now, too. Unless you want the
insecurity of IoT now, or of some of the classic SCADA configurations.

Nobody is going to want to use an x86-64 box in Simon's middle IoT
tier, much less an Itanium, either. Too expensive.

An OpenVMS port to ARM (SBSA or otherwise) is most of a decade out, at
the earliest. Then there's pricing, etc.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com]
> On Behalf Of Stephen Hoffman via Info-vax
> Sent: 12-Sep-16 9:47 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman
> <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS and the Internet of Things
> (IoT)
>

[snip..]

>
> But yes, markets can and do change, and new markets
> — mobile clients,
> for instance — can appear. Whether VSI can expand
> the installed base?
> Power isn't all that and a bag of chips, though.
>

Over the next decade, the long term strategy should not be X86-64 or PowerX or ARM, but rather X86-64 + ARM + Power9 (as market growth determines). Each of these HW platforms addresses a different niche in the market.

Post 2025, one would have to assume Alpha and IA64 will be distant memories.

It's been discussed extensively in c.o.v. about not putting all your eggs in one basket - including your reference to what Google is doing. So why would VSI deciding to not put all their eggs in one basket be a bad thing? Providing Customers with choices is seldom a bad strategy.

Partnering with IBM is seldom a bad strategy - especially with all their SW which is imho, the hidden big driver.

In addition, most mainframe types will not likely jump on any OS platform running on X86-64. Should Power9 be successful, then that platform would be viewed more favorably as a mainframe alternative.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com]

> On Behalf Of Stephen Hoffman via Info-vax
> Sent: 12-Sep-16 10:23 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman
> <seao...@hoffmanlabs.invalid>

> Subject: Re: [Info-vax] VMS and the Internet of
Things
> (IoT)
>

> On 2016-09-12 13:34:21 +0000, Kerry Main said:
>
> > Does this answer the question of being capable of
> addressing the
> > mid-tier layer in the IoT world??
>
> That OpenVMS can do classic SCADA is known.
>
> There's more to what's necessary now, too. Unless
> you want the
> insecurity of IoT now, or of some of the classic
SCADA
> configurations.
>
> Nobody is going to want to use an x86-64 box in
> Simon's middle IoT
> tier, much less an Itanium, either. Too expensive.
>

See the link I just posted and the reason they chose
the QEI OpenVMS solution. They wanted the middle tier
to be disaster tolerant.

Generally speaking, I expect many more future solutions
to have similar requirements.

> An OpenVMS port to ARM (SBSA or otherwise) is most
> of a decade out, at
> the earliest. Then there's pricing, etc.
>

You have just made my point - In the longer term, VSI
should not put all of its eggs in one basket.

Of course, pricing would have to change to become much
more competitive and much more simplified.

That goes with being competitive on any new target
platform, including X86-64.

[Scott Dorsey]

On 2016-09-12 13:34:21 +0000, Kerry Main said:
>

> Does this answer the question of being capable of addressing the
> mid-tier layer in the IoT world??

No, because we don't live in that world any more. Running SCADA systems is
a very different thing than dealing with highly integrated small scale
machines.

And... having done factory automation work in the eighties using VMS as
the second tier, I can certainly attest that VMS isn't even the right tool
for that job. It worked, but boy was it painful and boy did we wish for
RT-11 back....

[John Reagan]

I still have my CAMAC standard and remember those CAMAC crates (both serial and parallel buses). Worked great on our 780s in the early 80s.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com]
> On Behalf Of Scott Dorsey via Info-vax
> Sent: 12-Sep-16 11:19 AM
> To: info...@rbnsn.com
> Cc: Scott Dorsey <klu...@panix.com>
> Subject: Re: [Info-vax] VMS and the Internet of
Things
> (IoT)
>

Yes, OpenVMS is not as popular in these environments as
it used to be. Lots of reasons.

All I can say is there are many manufacturing and other
mission critical environments that had different
experiences than yours.

Heck, there are still mfging sites using small
standalone VAX's for process control because they are
so rock solid.

As I am sure you know, one these mfging sites have a
solution that works, they will stick with it as long as
they can.

[Jan-Erik Soderholm]

> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>

I think it is as simple as that:

"Middle IoT tier" != "Middle SCADA tier" != "Middle XYZ tier".

Nothing will move forward if you keep on talking
around each other...

[Chris]

On 09/11/16 10:16, Simon Clubley wrote:

<snip>

>
> So that's my take on the IoT. What's yours and where do you see a
> possible place for VMS within the IoT world ?
>

> Simon.
>

There's a lot of hype around this, a classic case being the front
page of the Oxford Times (Oxford, Uk) this week, which describes
a 3000 house "Futuristic City", with driverless cars and
"intelligent buildings". Then goes on to say how the buildings will
be "connected digitally", whatever that means. Pure hype to try to
sell a "follow the money" project for business, as usual, using a
few tech buzzwords to make it sound glamorous and futuristic.

A More concrete example is of course, the smart metering project
that's being rolled out across the uk. We do embedded systems
here, so it's of interest to me in terms of the technology used. All
the docs are available online, but from the spec, looks like vast
overkill just to gather gas / electricity meter readings.

In every home, the system will consist of a wireless network,
using an encrypted proprietary protocol, gas and
electricity meter collection interfaces, a user interface
box with lcd display to allow monitoring of usage etc.
Finally, a router communicating via a variety of wired and
wireless protocols to a central server. Fwics, a company has
been set up specifically to provide the server facilities. If
I were paranoid, I might think so much infrastructure overkill
was a bit creepy, but whatever :-). Of course, depending on the
available network bandwidth, one could see all kinds of future
uses, such as home security, appliance monitoring and even
(gasp) government snooping of residents. Once the
infrastructure is in place, no doubt they will find all kinds of
uses for it in the future. As most homes already have high speed
internet connectivity, one can only ask if the task could have
been done at far less cost and duplication of effort.

As for VMS, I see no roll at all. It's too expensive, functionally
deficient in many areas and arcane in it's user interface. If VSI
are really serious about making it mainstream, it must have all
mainstream computing facilities that everyone else in the industry
takes for granted these days. I really would like to see a
resurgence and the opportunity to use it again, but seems like
there's along way to go...

Chris

[Scott Dorsey]

John Reagan <xyzz...@gmail.com> wrote:
>On Monday, September 12, 2016 at 11:19:24 AM UTC-4, Scott Dorsey wrote:
>> On 2016-09-12 13:34:21 +0000, Kerry Main said:
>> >
>> > Does this answer the question of being capable of addressing the
>> > mid-tier layer in the IoT world??
>>
>> No, because we don't live in that world any more. Running SCADA systems is
>> a very different thing than dealing with highly integrated small scale
>> machines.
>>
>> And... having done factory automation work in the eighties using VMS as
>> the second tier, I can certainly attest that VMS isn't even the right tool
>> for that job. It worked, but boy was it painful and boy did we wish for
>> RT-11 back....
>

>I still have my CAMAC standard and remember those CAMAC crates (both serial and parallel buses). Worked great on our 780s in the early 80s.

AAAAGH! CAMAC!
Now I have to go get a drink.

[Chris]

On 09/12/16 14:32, Kerry Main wrote:
>

>
> In addition, most mainframe types will not likely jump on any OS platform running on X86-64.
> Should Power9 be successful, then that platform would be viewed more favorably as a mainframe alternative.
>

Why is that ?. Ignoring other factors, any non X86 architecture
is inherently more secure that X86, in term of binary virus and
malware susceptibility. Most of the world's malware depends on X86
architecture to run at all...

Chris

[johnwa...@yahoo.co.uk]

Real(ish)-time meter readings can be gathered remotely with
kit costing maybe £50 per meter, subject to network coverage.
Joined up thinking might have seen this as an opportunity to
have meter reading companies and mobile network companies
co-operate to improve mobile coverage to make things like
this actually work... no chance.

The smart meters being rolled out in the UK are required to
have, as well as the remote metering stuff, a remotely
controlled power-off switch. No UK law currently permits use
of this off switch, but that can be changed at a few hours
notice when the state of emergency arises.

Do people want a Window box in charge of this capability?
When a Windows (or other) Update disables the USB-serial
adapter which is likely a critical piece *somewhere* in
the setup? Or any of the other usual unfortunate stuff
you get with the usual high volume low value commodity OS
used in a place where a high volume low value commodity
OS don't fit right?

Some might tolerate Windows as a GUI in the operations
centre. Or as a part of a development environment. As it's
Capita that are doing the UK data collection, who knows
what delight the overall system will bring to us. We'll
find out soon enough.

[Bob Koehler]

Most of the world's malware depends on a particulary leaky OS that
only runs on x86. Once upon a time, it ran on a few other
processsors where the OS was equally full of holes.

There is a trick or two that help an OS provide a secure envronment,
and x86 may not have them all, but no architecure can overcome bad
software implementation.

[Simon Clubley]

On 2016-09-12, Jan-Erik Soderholm <jan-erik....@telia.com> wrote:
>
> I think it is as simple as that:
>
> "Middle IoT tier" != "Middle SCADA tier" != "Middle XYZ tier".
>
> Nothing will move forward if you keep on talking
> around each other...
>

Thank you Jan-Erik; you are absolutely right.

Kerry keeps talking with a "big systems" mindset and not an
embedded systems/IoT mindset; everyone else is correctly talking
with the embedded systems/IoT mindset.

I wonder if Kerry really doesn't get it or if he understands all
too well how poorly VMS would fair in that area so instead he
keeps trying to move the discussion to an unrelated area in
which VMS has had some historical success.

Simon.

PS: I agree with you that there's a lot of hype in the IoT world;
I'm skipping over the hype for the most part in this discussion
and I'm just trying to bring some facts and reasoning to the
discussion about the technologies which are being talked about.

[Simon Clubley]

On 2016-09-12, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
> I wonder if Kerry really doesn't get it or if he understands all
> too well how poorly VMS would fair in that area so instead he

Before someone points it out; yes I know it's "fare" and not "fair". :-)

> keeps trying to move the discussion to an unrelated area in
> which VMS has had some historical success.
>

Simon.

[Simon Clubley]

On 2016-09-12, Chris <xxx.sys...@gfsys.co.uk> wrote:
> On 09/11/16 10:16, Simon Clubley wrote:
>
><snip>
>
>>
>> So that's my take on the IoT. What's yours and where do you see a
>> possible place for VMS within the IoT world ?
>>
>> Simon.
>>
>
> There's a lot of hype around this, a classic case being the front
> page of the Oxford Times (Oxford, Uk) this week, which describes
> a 3000 house "Futuristic City", with driverless cars and
> "intelligent buildings". Then goes on to say how the buildings will
> be "connected digitally", whatever that means. Pure hype to try to
> sell a "follow the money" project for business, as usual, using a
> few tech buzzwords to make it sound glamorous and futuristic.
>

It's nonsense like this which overshadows the valid usage cases
(assuming those usage cases were implemented correctly and with
proper security).

> A More concrete example is of course, the smart metering project
> that's being rolled out across the uk. We do embedded systems
> here, so it's of interest to me in terms of the technology used. All
> the docs are available online, but from the spec, looks like vast
> overkill just to gather gas / electricity meter readings.
>

For anyone interested in knowing more about this, here is the
latest update from The Register:

http://www.theregister.co.uk/2016/09/09/smart_meters_just_get_them_smart_energy_gb_lobbyist/

Some of the comments are well worth a read.

[snip]

>
> As for VMS, I see no roll at all. It's too expensive, functionally
> deficient in many areas and arcane in it's user interface. If VSI
> are really serious about making it mainstream, it must have all
> mainstream computing facilities that everyone else in the industry
> takes for granted these days. I really would like to see a
> resurgence and the opportunity to use it again, but seems like
> there's along way to go...
>

It's only possibly viable use is in any remote server systems that
the onsite IoT systems may need to talk to. I am just not seeing
any other possibly viable use for VMS in the whole IoT setup.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On

> Behalf Of Simon Clubley via Info-vax
> Sent: 12-Sep-16 3:43 PM
> To: info...@rbnsn.com
> Cc: Simon Clubley <clubley@remove_me.eisner.decus.org-
> Earth.UFP>

> Subject: Re: [Info-vax] VMS and the Internet of Things
(IoT)
>

> On 2016-09-12, Jan-Erik Soderholm <jan-

> erik.so...@telia.com> wrote:
> >
> > I think it is as simple as that:
> >
> > "Middle IoT tier" != "Middle SCADA tier" != "Middle XYZ
> tier".
> >
> > Nothing will move forward if you keep on talking around
> each other...
> >
>
> Thank you Jan-Erik; you are absolutely right.
>
> Kerry keeps talking with a "big systems" mindset and not
an
> embedded systems/IoT mindset; everyone else is correctly
> talking with the embedded systems/IoT mindset.
>
> I wonder if Kerry really doesn't get it or if he
understands all
> too well how poorly VMS would fair in that area so instead
> he keeps trying to move the discussion to an unrelated
area
> in which VMS has had some historical success.
>
> Simon.
>
> PS: I agree with you that there's a lot of hype in the IoT
> world; I'm skipping over the hype for the most part in
this
> discussion and I'm just trying to bring some facts and
> reasoning to the discussion about the technologies which
> are being talked about.
>

Let's agree to disagree.

Not all IoT hyped devices will be embedded system models,
but let's leave it as that.

I am talking potential OpenVMS futures (remember - I did
state ARM platform) and you are talking about capabilities
and pricing models that exists today.

Bottom line - VSI cannot risk putting all of its future eggs
in one (X86-64) basket.

[Stephen Hoffman]

On 2016-09-12 14:32:12 +0000, Kerry Main said:

> Over the next decade, the long term strategy should not be X86-64 or
> PowerX or ARM, but rather X86-64 + ARM + Power9 (as market growth
> determines). Each of these HW platforms addresses a different niche in
> the market.

Spending time on Power will be one of the better ways to ensure the end
of OpenVMS, IMO.

> Post 2025, one would have to assume Alpha and IA64 will be distant memories.

Those two architectures are already distant memories for most folks in
IT. For those few folks that remember those architectures, or have
even heard of them. That all given we haven't seen Kittson yet, too.

> It's been discussed extensively in c.o.v. about not putting all your
> eggs in one basket - including your reference to what Google is doing.
> So why would VSI deciding to not put all their eggs in one basket be a
> bad thing? Providing Customers with choices is seldom a bad strategy.

That "one basket" being Intel and AMD and x86-64, and betting against
the architecture that's central to the Windows hegemony, and the
majority of Linux and BSD servers in existence?

But then providing customers with choices can be a poor strategy —
particularly when there's little benefit to end-users and more than a
little cost to provide the choice for both the vendor and the vendor's
partners. Adding a port to Power gets you little you didn't have with
x86-64, except for fragmenting your own OpenVMS installed base and
ISVs, and tying up VSI and ISV development for another five years, and
higher-priced and rare boxes, among other "advantages".

This when the OpenVMS platform desperately needs to get dragged forward
with every iota of time and effort and focus that VSI can manage to
expend on behalf of that endeavor. Now.

Assuming OpenVMS is around in the late 2020s and assuming it is still
actively developed and assuming the platform owners see the
opportunity, then whatever platform is eating into Intel's revenues
(and those of AMD) will be the obvious porting target. If that's
Power, so be it. But I seriously doubt it'll be Power, and I
seriously doubt Power will bring much of anything that Intel doesn't
already offer, outside of a small slice of very high-end customers, and
those folks with control over most or all of their own software stack.

OpenVMS is not now and won't soon be playing in HPC or other high-end
computing, either. Not without a whole lot of infrastructure work
first, and of which another port will serve to delay or derail.
Adding another architecture just adds a whole pile of development and
support work for VSI and ISVs including a whole 'nother set of
compilers and linker and executable-related tools work, and delays and
fragments other and more critical development work, after all.

> Partnering with IBM is seldom a bad strategy - especially with all
> their SW which is imho, the hidden big driver.

Partnering with IBM, in direct competition with Intel and AMD, and in
competition with multiple ARM vendors and fabs (including Intel and
AMD), and fragmenting what's left of the OpenVMS market? In all
seriousness, for what?

> In addition, most mainframe types will not likely jump on any OS
> platform running on X86-64. Should Power9 be successful, then that
> platform would be viewed more favorably as a mainframe alternative.

The mainframe market worked out well for DEC, of course. And a
bespoke high-end processor or two worked for OpenVMS for some years —
in the form of Alpha and Itanium — but all that eventually ran up
against the cost advantages of x86-64. Which is right where Power is
now...

If I were guessing, AArch64 is the eventual next target, as that creeps
up into the x86-64 performance range, assuming the ARM vendors get SBSA
and other details sorted. But that's still a port that's way outside
of any reasonable window of planning and discussion for OpenVMS.

[Stephen Hoffman]

On 2016-09-12 18:13:26 +0000, Chris said:

> Why is that ?. Ignoring other factors, any non X86 architecture is
> inherently more secure that X86, in term of binary virus and malware
> susceptibility. Most of the world's malware depends on X86 architecture
> to run at all...

More than a little of the recent malware depends on Word macros, and —
barring holes in the iLO firmware or Intel AME firmware — all of the
malware is specific to a particular software package or operating
system, and not to the underlying hardware. Bare hardware doesn't
and can't run malware. But then I've chased around more than a
little malware that was wonderfully overloading OpenVMS servers, due to
bugs in the OpenVMS NTP server being used for reflection attacks.

[Chris]

I guess we must agree to differ there. From what I understand, the
object of the exercise is to get a binary executable into a region
of memory where it can be run. Doesn't matter if the attack
surface is a word or spreadsheet macro, email client, or browser
exploit, the result is the same. Of course the "bare metal" machine
runs code, it's what it's designed to do :-).

It's one of the primary reasons why I continued to run an aged
Alpha box as the main lab server for years. Now Solaris, but also
investigating FreeBSD, non X86 version of course.

Overall, I think Power would have been a better machine to port VMS
to, in terms of the sort of markets that both address, but I guess
it would be unacceptable for all kinds of reasons...

Chris

[Chris]

On 09/12/16 19:02, Bob Koehler wrote:

>
> Most of the world's malware depends on a particulary leaky OS that
> only runs on x86. Once upon a time, it ran on a few other
> processsors where the OS was equally full of holes.
>
> There is a trick or two that help an OS provide a secure envronment,
> and x86 may not have them all, but no architecure can overcome bad
> software implementation.
>

Agreed, dodgy software is to blame, but if you are trying to build a
secure system, you must assume that it is vulnerable and can be broken,
given enough time and effort. X86 and it's software is arguably the
biggest attack surface known to man. Assume that VSI will have all
that covered though.

System security is a major issue and likely to become more so, as the
bad guys get ever smarter...

Chris

[Chris]

On 09/12/16 19:43, Simon Clubley wrote:

>
> Thank you Jan-Erik; you are absolutely right.
>
> Kerry keeps talking with a "big systems" mindset and not an
> embedded systems/IoT mindset; everyone else is correctly talking
> with the embedded systems/IoT mindset.
>
> I wonder if Kerry really doesn't get it or if he understands all
> too well how poorly VMS would fair in that area so instead he
> keeps trying to move the discussion to an unrelated area in
> which VMS has had some historical success.
>
> Simon.
>
> PS: I agree with you that there's a lot of hype in the IoT world;
> I'm skipping over the hype for the most part in this discussion
> and I'm just trying to bring some facts and reasoning to the
> discussion about the technologies which are being talked about.
>

It's about using appropriate tech to solve the problem, no more
and no less. VMS runs only on a single platform right now, most
likely power hungry, space inefficient etc. A data center server
product that works well for it's intended application. Embedded
/ real time system cover a very wide and expanding field. Iphone,
avionics computers, hand held sat nav, domestic appliance
controllers, set top boxes, hearing aids and heart pacemakers.
An almost infinite range of applications, everywhere where
intelligent control needs to be built into a product.

The point is that VMS would be very poor fit for the majority
of embedded applications, where minimum cost, size and power
consumption are primary factors. I know it's been used for
factory automation (eg: Intel & Vax historically), but that
task can also be handled by much more modern and industry
standard hardware and os's these days. VMS has no USP in
that area and it would need to compete with a whole range of
specialist vendors who have been in the business for decades...

Chris
'

[Jan-Erik Soderholm]

We have had "smart" electricy meters for well over 10 years (Sweden).

It was only a switch of the meter itself. The remote reading is
done through signaling using a carrier over the power line itself.

I think there are also models using the cellular network directly.
Still only a meter switch (payed by the power company, of course,
since they save a lot on people (not) doing the readings).

In no case is there any requirement on home networks or even an
internet connection from the home.

What you describe sounds really weird...

The benefits is that you can login to the power company and get
nice statistics and graphs of your electricity use.

Jan-Erik.

[Stephen Hoffman]

On 2016-09-12 21:15:55 +0000, Chris said:

> On 09/12/16 20:30, Stephen Hoffman wrote:
>> On 2016-09-12 18:13:26 +0000, Chris said:
>>
>>> Why is that ?. Ignoring other factors, any non X86 architecture is
>>> inherently more secure that X86, in term of binary virus and malware
>>> susceptibility. Most of the world's malware depends on X86 architecture
>>> to run at all...
>>
>> More than a little of the recent malware depends on Word macros, and

>> — barring holes in the iLO firmware or Intel AME firmware — all of

>> the malware is specific to a particular software package or operating
>> system, and not to the underlying hardware. Bare hardware doesn't and
>> can't run malware. But then I've chased around more than a little
>> malware that was wonderfully overloading OpenVMS servers, due to bugs
>> in the OpenVMS NTP server being used for reflection attacks.
>
> I guess we must agree to differ there. From what I understand, the
> object of the exercise is to get a binary executable into a region of
> memory where it can be run. Doesn't matter if the attack
> surface is a word or spreadsheet macro, email client, or browser
> exploit, the result is the same. Of course the "bare metal" machine
> runs code, it's what it's designed to do :-).

That's if you're stack smashing, and that code is still entirely
dependent on the operating system that's running in the box.

That memory must be executable and more than a little of it isn't, and
the code or data elsewhere in memory must have a layout that the
malware understands — this is why app or system crashes can sometimes
point to latent security issues, as the malware doesn't get the layout
right — and it's why systems (other than OpenVMS) have moved to address
space randomization, stack canaries and other features. Yes, there's
executable code — for some malware. But there still has to be an
entry that provides a way to get that code loaded, and a way to get the
processor to execute that code, and that's *entirely* system or
software dependent. There's no magic here.

More than a little of the current malware has absolutely nothing to do
with executable machine code, it's Office macro code. Some of the
more recent malware — and what's now declining on platforms with modern
security and ASLR — isn't even code, it's data. That uses what's
called ROP; return oriented programming. The data causes existing
operating system or application code to execute in completely
unexpected and unforeseen ways, and that code is already and inherently
resident in executable storage. Malware using ROP is very dependent
on the other code around, which means the malware has to know the
layout of virtual memory and ASLR and stack canaries and such — all
lacking on OpenVMS — makes these approaches vastly harder.

Other malware loads via Flash or Java weaknesses, which can be platform
independent. It wouldn't surprise me to learn that OpenVMS I64 with a
browser and web start configured — not all that easy to get there —
would be vulnerable to some of the Java malware around, too. That's
due to the ancient version of Java.

With Office macros shut off via policy and with EMET loaded, and
without Adobe Flash and Java web start present or with both disabled,
you're probably going to do pretty well with Windows 10 on x86-64, too.

> It's one of the primary reasons why I continued to run an aged Alpha
> box as the main lab server for years. Now Solaris, but also
> investigating FreeBSD, non X86 version of course.

Which is as much about the software involved — and some of which can be
infested or problematic — as the underlying hardware.

> Overall, I think Power would have been a better machine to port VMS to,
> in terms of the sort of markets that both address, but I guess it would
> be unacceptable for all kinds of reasons...

Porting OpenVMS to Power is one of the worst ideas around. Great
processor, certainly. It'll be expensive to buy and rarely
encountered outside of specific sites and with everything that tended
to make Alpha a business problem and a competitive disadvantage, and
for the foreseeable future. x86-64 won this round, and whether it's
ugly or not, it's currently the only financially viable choice —
porting to Power hammers OpenVMS development for another five or ten
years, further splits what exists of the OpenVMS installed base, and is
more likely to contribute to the end of OpenVMS than to its
renaissance. In five or ten years or whenever x86-64 architecture has
a serious competitor and particularly one that's in volume server
production — Power or AArch64 or whatever — then that's worth a look.
Then. But OpenVMS needs to get its features and capability and
security and the rest more competitive far before that port, and that
development and porting work can only happen well after OpenVMS x86-64
and ISV software and end-user software is ported over and working.

Here's what Power is right now:
https://www.youtube.com/watch?v=SSUXXzN26zg It's (in the most polite
terms) a distraction. It's flailing, thrashing, indecision, added
costs, product fragmentation, increased costs... And it's a whole lot
more work, and more expensive boxes, and all for... well... how much
specific end-user benefit past what x86-64 provides?

[David Froble]

Could VMS be used in this venue? Of course it could. It's just software.
Perhaps some tweeking would make it more usable.

Would VMS ever (well, the next 10 years) be used in this venue. Most likely
not, for one good reason. It would take some work by VSI (or someone) to make
it usable. For something that will never return any cash. Why would VSI ever
do such work, knowing it's costing them money, and they will never see anything
from it? Simple answer, they won't.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Stephen Hoffman via Info-vax
> Sent: 12-Sep-16 7:16 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS and the Internet of Things (IoT)
>

[snip..]

> Here's what Power is right now:
> https://www.youtube.com/watch?v=SSUXXzN26zg It's (in
> the most polite
> terms) a distraction. It's flailing, thrashing, indecision,
> added
> costs, product fragmentation, increased costs... And it's a
> whole lot more work, and more expensive boxes, and all
> for... well... how much specific end-user benefit past what
> x86-64 provides?
>

Power9 will address the high end market - especially those environment that need very high throughput.

ARM the lower end, lower power end market.

X86-64 the mid-tier market.

Different markets, different requirements, different price points.

If there is anything smarter companies like Oracle have learned, it's never put all your eggs in one basket.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of Stephen Hoffman via Info-vax
> Sent: 12-Sep-16 4:24 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS and the Internet of Things (IoT)
>

One word - software.

That is the sweet spot with partnering with IBM to bring another OS platform to Power9.

> > In addition, most mainframe types will not likely jump on
> any OS
> > platform running on X86-64. Should Power9 be successful,
> then that
> > platform would be viewed more favorably as a mainframe
> alternative.
>
> The mainframe market worked out well for DEC, of course.
> And a
> bespoke high-end processor or two worked for OpenVMS
> for some years — in the form of Alpha and Itanium — but all
> that eventually ran up
> against the cost advantages of x86-64. Which is right where
> Power is
> now...

The issue with mainframes is not the cost of the hardware, rather the license and support costs of the software.

To go after the mainframe market, you need a non-X86 platform and a deep understanding of what the mainframe world is all about.

High throughput, rock solid platform with ultra-high availability and high security.

>
> If I were guessing, AArch64 is the eventual next target, as
> that creeps up into the x86-64 performance range, assuming
> the ARM vendors get SBSA
> and other details sorted. But that's still a port that's way
> outside
> of any reasonable window of planning and discussion for
> OpenVMS.
>

ARM (British company) was just bought by Softbank - a Japanese company. Sept 6 2016.
https://www.arm.com/-/media/arm-com/news/Simon-Segars_Masayoshi-Son-letter_Sept-6-2016.pdf?la=en

What you are saying will depend a lot on no culture issues dragging the company down or key designers jumping ship.

[johnso...@gmail.com]

On Monday, September 12, 2016 at 10:55:06 PM UTC-4, Kerry Main wrote:

> To go after the mainframe market, you need a non-X86 platform ...

I really don't understand why you feel this way about x86. To me, it's so far down the technology stack that it's almost akin to complaining about your power supply. Could
you imagine someone telling you that 120V is the best and 220V is just not right?

Or to put it differently, when I hear you say "you need a non-X86 platform", I hear you
say "you need to be the weird one". VMS has been weird for so long for so many that
it would be best served by doing everything it can to be less weird.

EJ

[Chris]

On 09/12/16 22:06, Jan-Erik Soderholm wrote:

>
> We have had "smart" electricy meters for well over 10 years (Sweden).
>
> It was only a switch of the meter itself. The remote reading is
> done through signaling using a carrier over the power line itself.
>
> I think there are also models using the cellular network directly.
> Still only a meter switch (payed by the power company, of course,
> since they save a lot on people (not) doing the readings).
>
> In no case is there any requirement on home networks or even an
> internet connection from the home.
>
> What you describe sounds really weird...

I used the word creepy intentionally :-)...

>
> The benefits is that you can login to the power company and get
> nice statistics and graphs of your electricity use.
>
> Jan-Erik.
>

There are privacy issues here as well. To calculate real
power, you need include power factor in the calculations,
measuring voltage and current in real time to calculate
phase angle. From the spec, it will be possible to measure
all this a at subsecond rates. Thus, it's quite easy, over time
to get a fair amount of info on the type of loads and timescales
for every home. This info will be used for marketing and who
knows what other purpose in the future. Personally, I don't want
any of this junk in my house. Right now, we can refuse to have
it installed, but there's a cutoff date beyond which there will
be no choice.

Power line or umts style reporting is the sensible way to do it,
with all the infrastructure already in place, so one can only
ask why such an expensive solution ?. Sounds like some business
interest or other persuaded clueless civil servants that it was
a good idea. of course, trebles all round for the businesses
concerned, with all the hardware built in the far east to
minimise cost and maximise profit...

Chris

[Chris]

On 09/12/16 18:55, johnwa...@yahoo.co.uk wrote:

> The smart meters being rolled out in the UK are required to
> have, as well as the remote metering stuff, a remotely
> controlled power-off switch. No UK law currently permits use
> of this off switch, but that can be changed at a few hours
> notice when the state of emergency arises.

Forgot to mention that, but does raise an interesting
question from an engineering pov. They need to be able to
switch a 60-100 amp load, the usual incoming fuse rating
here in the uk. They can either use an electromechanical
contactor / relay, or a solid state switch. A relay of
that rating is physically bulky, with large silver or silver
alloy contacts That solution would drop insignificant
voltage, but would need to be always on, wasting ~10Va each.
Multiply that by millions of meters = megawatts of wasted
power. While it could be normally closed, ie: contact closed
unenergised, it's doubtful if there would be enough contact
pressure to handle the current rating. If a solid state
relay is used, at that rating, expect to drop 2-3 volts. So,
at a 100 amp load, that relay dissipates 2-300 watts, which
would need a very big heatsink or foced ar cooling to
prevent meltdown and er, who will pay for that wasted power ?.

That's just one of the things that sprung up while reading
the spec. Devil is in the detail, as usual, but the whole
project is completely over the top.

>
> Do people want a Window box in charge of this capability?
> When a Windows (or other) Update disables the USB-serial
> adapter which is likely a critical piece *somewhere* in
> the setup? Or any of the other usual unfortunate stuff
> you get with the usual high volume low value commodity OS
> used in a place where a high volume low value commodity
> OS don't fit right?

Windows might be fine for front end user interface, but one
would hope that any safety or security critical system
would have a fully hardened and avionics grade approved
os of some sort. Doubt it actually happens though :-)...

Chris

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On
> Behalf Of johnson.eric--- via Info-vax
> Sent: 13-Sep-16 4:41 AM
> To: info...@rbnsn.com
> Cc: johnso...@gmail.com
> Subject: Re: [Info-vax] VMS and the Internet of Things
(IoT)
>

You need to understand the mainframe culture.

If you think OpenVMS groups feel their capabilities have
been overlooked in the past, just ask someone from the
mainframe world what they think about "distributed systems".

:-)

[John E. Malmberg]

On 9/13/2016 6:14 AM, Chris wrote:
> On 09/12/16 18:55, johnwa...@yahoo.co.uk wrote:
>
>> The smart meters being rolled out in the UK are required to
>> have, as well as the remote metering stuff, a remotely
>> controlled power-off switch. No UK law currently permits use
>> of this off switch, but that can be changed at a few hours
>> notice when the state of emergency arises.
>
> Forgot to mention that, but does raise an interesting
> question from an engineering pov. They need to be able to
> switch a 60-100 amp load, the usual incoming fuse rating
> here in the uk. They can either use an electromechanical
> contactor / relay, or a solid state switch. A relay of
> that rating is physically bulky, with large silver or silver
> alloy contacts That solution would drop insignificant
> voltage, but would need to be always on, wasting ~10Va each.

There are electro-mechanical switching systems that consume no
power in their steady state. It increases the cost of the switch slightly.

One solenoid turns the switch on, one turns it off.

In the case of something just used for an emergency power off, you only
need a solenoid to turn it off and have a human operated reset switch
turn it back on.

Regards,
-John
wb8tyw@qsl_network

[David Froble]

In this world, financial people seem to drift to the top of things. (Shows how
stupid the human race is.)

If you ask a financial person to make a decision, it will most times be a
financial decision. (Works well when an engineering decision is needed.)

Avionics grade (that means good)? But it's so much more expensive. (See above
concerning who's at the top, and financial decisions.)

Makes you wonder how we ever got out of the caves? (Perhaps the financial
people got lost and couldn't find their way back to the caves.)

[Simon Clubley]

On 2016-09-13, David Froble <da...@tsoft-inc.com> wrote:
>
> Makes you wonder how we ever got out of the caves? (Perhaps the financial
> people got lost and couldn't find their way back to the caves.)

Perhaps Ogg and company arranged for them to be dispatched on the
prehistoric version of the B-Ark ? :-)

[Chris]

On 09/12/16 23:16, Stephen Hoffman wrote:

>
> That's if you're stack smashing, and that code is still entirely
> dependent on the operating system that's running in the box.

To be honest, neither of us have the knowledge base to comment on this,
but you only have to look at some the sophistication of some of
the exploit code (yes, it is X86 assembler) to come to the
conclusion that some serious effort and cash is being put into it.
Not bedroom hackers, but well funded organisations and state
level actors worldwide. You have to
assume that all systems can be broken, given enough resources, but using
a non X86 architecture immediately removes the majority of injected
code related exploits.

Have a look at cert.org, or google X86 security exploits for more info.

VMS may be more robust on X86, security by obscurity etc. It won't use
the same memory layout, system functions, kernel or driver code, but
it's still a pretty wide interface for the bad guys. I guess for
them it's a trade off between potential reward against effort.
Make it difficult enough and they will hopefully move on to the
next target.

<snipped>

>
> Porting OpenVMS to Power is one of the worst ideas around. Great
> processor, certainly. It'll be expensive to buy and rarely encountered
> outside of specific sites and with everything that tended to make Alpha
> a business problem and a competitive disadvantage, and for the
> foreseeable future.

<snipped>

If you are aiming VMS at the bazar, X86 is a good choice, but VMS
was aimed at the high end, the sort of market that Power systems
traditionally address. VMS was quite successful on Alpha and it's
long term demise had nothing to do the architecture, but rather lack of
investment in supporting software and infrastructure development.
Compaq were not too bad to start with, but it was subject to the NIH
factor at HP, who were clearly not interested in the product at all.

>
> Here's what Power is right now:
> https://www.youtube.com/watch?v=SSUXXzN26zg It's (in the most polite
> terms) a distraction. It's flailing, thrashing, indecision, added costs,
> product fragmentation, increased costs... And it's a whole lot more
> work, and more expensive boxes, and all for... well... how much specific
> end-user benefit past what x86-64 provides?
>

As I said, inherent levels of security, just by not being capable of
executing X86 code. There's also the kudos, real or imaginary, coming
from using IBM product, which is still seen as high end quality and
attention to detail.

As for windows 10, i'm surprised that you even mention it :-).

Chris

[Chris]

Agreed, a latching relay would get the job done, but there's still the
contact problem, which would need to be quite substantial at the current
rating. As for manual reset, I doubt that will happen as one of the
reasons for the power off capability is to allow disconnection where the
bill hasn't been paid. Brave new world indeed...

Chris

[Scott Dorsey]

In article <nr9h0g$ha4$1...@gioia.aioe.org>, Chris <sys...@gfsys.co.uk> wrote:
>On 09/12/16 23:16, Stephen Hoffman wrote:
>
>> That's if you're stack smashing, and that code is still entirely
>> dependent on the operating system that's running in the box.
>
>To be honest, neither of us have the knowledge base to comment on this,
>but you only have to look at some the sophistication of some of
>the exploit code (yes, it is X86 assembler) to come to the
>conclusion that some serious effort and cash is being put into it.
>Not bedroom hackers, but well funded organisations and state
>level actors worldwide. You have to
>assume that all systems can be broken, given enough resources, but using
>a non X86 architecture immediately removes the majority of injected
>code related exploits.

Using a non-X86 architecture helps a lot merely by obscurity; the kids don't
know how to write the code and there is no prepackaged injection code off
the shelf.

BUT.... using a capability architecture with real stack protection eliminates
the problem. Sadly the iAPX 432 never made it, though.
--scott


--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Scott Dorsey]

In article <nr9haa$hrp$1...@gioia.aioe.org>, Chris <sys...@gfsys.co.uk> wrote:
>>
>
>Agreed, a latching relay would get the job done, but there's still the
>contact problem, which would need to be quite substantial at the current
>rating. As for manual reset, I doubt that will happen as one of the
>reasons for the power off capability is to allow disconnection where the
>bill hasn't been paid. Brave new world indeed...

No, the contacts are easy, if you don't mind that they are destroyed when
the circuit is opened. Which would be reasonable for the application. When
the bill is paid and the line is reconnected the man from the power company
snaps a new module into place and the power is restored.

[Tym Stegner]

On Tuesday, September 13, 2016 at 1:35:14 PM UTC-4, Simon Clubley wrote:
> On 2016-09-13, David Froble <da...@tsoft-inc.com> wrote:
> >
> Perhaps Ogg and company arranged for them to be dispatched on the
> prehistoric version of the B-Ark ? :-)
>

They were left behind; carrying all those rocks (ancient currency) isn't easy...

[Bob Koehler]

In article <nrbgu1$mb3$1...@panix2.panix.com>, klu...@panix.com (Scott Dorsey) writes:
>
> Using a non-X86 architecture helps a lot merely by obscurity; the kids don't
> know how to write the code and there is no prepackaged injection code off
> the shelf.

I really doubt you'll find prepackaged injection code for VMS on
any architecture lieing around where the kiddies can find it.

[k...@kayceesoftware.com]

I'm working on a project with 10's of millions of nodes potential.
We are testing with hundreds of nodes. Each node is a simple *nx os with a few hundred lines of c code embedded.

Each node talks wireless to a 'master' *nx node, that talks via cellular or internet to my VMS box just to store logs and configuration settings.

I'm only using VMS as I have some spare boxes and I'm familiar with it.
It looks like we will be funded for production and the team consensus so far is that VMS will not be the final repository. Mostly because of cost and questionable future.

I can't imagine VMS being used at the low level sensor node nor the mid level master controller. Each of these units is designed so that we don't change the battery's for perhaps 10 years, a single screw or LED that is questionable is deleted. At the low level sensor node the controller cost will be under USD $15, that's for hardware, os, and embedded app. I don't foresee VMS having a version for embedded process control.

[Jan-Erik Soderholm]

I guess that technicaly VMS would work quite OK at the top level,
but your other "issues" with VMS are of course valid.

And yes, we will not see VMS either at the lowest or the
mid level for IoT "things". Or for any other embedded use.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Jan-Erik Soderholm via Info-vax
> Sent: 14-Sep-16 1:45 PM
> To: info...@rbnsn.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: Re: [Info-vax] VMS and the Internet of Things (IoT)
>

IoT and security, or rather lack thereof, in the news:

Weak Device Security Turns IoT Into Powerful Weapon in DDoS
Attacks - Oct 01, 2016

http://bit.ly/2djwx1v
"For the past several days, security researcher Brian Krebs has
been battling a cyber-attack on a scale unlike any ever
previously observed on the internet.

Krebs, who writes the security blog Krebs on Security, was on the
receiving end of a distributed denial-of-service (DDoS) attack
that delivered connection requests at the rate of nearly 700
gigabits per second. Equally alarming, the attack was generated
by well over a million video cameras as well as other
internet-connected devices ranging from set-top boxes to video
recorders."

[see link]

As discussed in this thread, in the rush to create IoT devices,
few IoT vendors have thought much about IoT security.

[Simon Clubley]

On 2016-10-02, Kerry Main <kemain...@gmail.com> wrote:
>
> As discussed in this thread, in the rush to create IoT devices,
> few IoT vendors have thought much about IoT security.
>

And as also discussed in this thread, VSI _still_ doesn't even have
any method on their website for a third party security researcher to
securely contact them with sensitive information about VMS
vulnerabilities. This public and secure reporting mechanism is
security 101 these days, especially when an organisation is selling
their products based on a security reputation.

Here's HPE's reporting mechanism (once again):

https://www.hpe.com/h41268/live/index_e.aspx?qid=11503

Quote: "The Hewlett Packard Enterprise PSRT is dedicated to providing
responses to reports of potential security vulnerabilities in a timely
manner."

This is Microsoft's reporting mechanism:

https://technet.microsoft.com/en-us/security/ff852094.aspx

Quote: "The Microsoft Security Response Center investigates all
reports of security vulnerabilities affecting Microsoft products and
services. If you are a security researcher and believe you have found
a Microsoft security vulnerability, we would like to work with you to
investigate it."

This is IBM's reporting mechanism:

http://www-03.ibm.com/security/secure-engineering/report.html

Quote: "Security researchers, industry groups, government
organizations and vendors concerned with product security can report
potential security vulnerabilities directly to IBM PSIRT."

Here's Red Hat's:

https://access.redhat.com/security/team/contact

Quote: "Red Hat takes security very seriously, and we aim to take
immediate action to address serious security-related problems that
involve our products or services."

It's pathetic that VSI don't have anything similar (with similar
"we want to work with you" type language) on their website; it
will send out a very bad message to any security researcher trying
to help VSI by reporting a security issue to them.

Once again, a secure security bug reporting mechanism is security 101
these days and we shouldn't even be having this conversation because
it should simply be there on the VSI website ready for a security
researcher to use.

BTW, all the above are fully compliant with today's standards and
are perfectly suitable, but if I had to choose, I would choose the
IBM one as a general template.

With IBM, you have the traditional encrypted email option but you
also have an online secure submission form option. IBM also directly
address what the security researcher's disclosure plans are and the
timeframe in which they intend to make that disclosure.

It would be interesting to know if this whole area was even
discussed at the Bootcamp.

[Simon Clubley]

On 2016-10-04, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2016-10-02, Kerry Main <kemain...@gmail.com> wrote:
>>
>> As discussed in this thread, in the rush to create IoT devices,
>> few IoT vendors have thought much about IoT security.
>>
>
> And as also discussed in this thread, VSI _still_ doesn't even have
> any method on their website for a third party security researcher to
> securely contact them with sensitive information about VMS
> vulnerabilities.

Actually, to be precise, I've discussed it on several other threads
here in comp.os.vms, but not this one; a keyword search should find
them if anyone is interested. (VSI certainly don't seem to be. :-()

[clairg...@gmail.com]

On Monday, October 3, 2016 at 9:41:08 PM UTC-4, Simon Clubley wrote:
> On 2016-10-02, Kerry Main <kemain...@gmail.com> wrote:
>
> And as also discussed in this thread, VSI _still_ doesn't even have
> any method on their website for a third party security researcher to
> securely contact them with sensitive information about VMS
> vulnerabilities. This public and secure reporting mechanism is
> security 101 these days, especially when an organisation is selling
> their products based on a security reputation.

> It would be interesting to know if this whole area was even
> discussed at the Bootcamp.
>

Not that I know of but it is discussed at VSI.

[Tym Stegner]

The last page of VSI roadmap provides an email address for any questions regarding VMS:

For more information, please contact us at: R...@vmssoftware.com

[David Froble]

Now, now, don't go busting Simon's bubble, he's having so much fun with it ..

:-)

But, yeah, if I found an issue, I'm sure I could find someone to discuss it
with. Don't need so much formality ....

[Simon Clubley]

On 2016-10-04, David Froble <da...@tsoft-inc.com> wrote:
> Tym Stegner wrote:
>> The last page of VSI roadmap provides an email address for any questions regarding VMS:
>>
>> For more information, please contact us at: R...@vmssoftware.com
>>
>

> Now, now, don't go busting Simon's bubble, he's having so much fun with it ..
>

Sorry you think that David, but I am not having fun with this.

What I am feeling however is increasing concern that the VMS community
may be sleepwalking, due to complacency, into a security situation
that it is ill prepared to deal with and which could go bad very quickly.

My attitude is that I am trying to do people a favour by trying to make
them realise that the security situation with regards to VMS is about
to change big time and to jog them out of that unjustified complacency.
This is not about me having fun.

We have VMS about to become available on common x86-64 hardware and we
have a vendor (VSI) shouting from the rooftops about how massively
secure VMS is and believe me, this latter point will be like waving
a red flag not to a single bull but to a whole herd of them once the
right security researchers become aware of it.

And please don't say how things were ok back in the 1980s/1990s because
while you are correct, you also need to understand how much things have
changed since then.

>:-)
>
> But, yeah, if I found an issue, I'm sure I could find someone to discuss it
> with. Don't need so much formality ....

Then why do all the other major OS companies on the planet all invest
in formal reporting mechanisms and security teams which allow the
security researchers to communicate _easily_ and _securely_ with the
companies in question ?

You really don't want to make the security researchers run through
a maze trying to find people to contact in a _secure_ manner at VSI
especially when no other major OS company, including HPE, makes them
do that.

Simon.

PS: Oh, and I already sent VSI email on this subject to the above
RnD address back somewhere in the middle of August.

[David Froble]

Simon Clubley wrote:
> On 2016-10-04, David Froble <da...@tsoft-inc.com> wrote:
>> Tym Stegner wrote:
>>> The last page of VSI roadmap provides an email address for any questions regarding VMS:
>>>
>>> For more information, please contact us at: R...@vmssoftware.com
>>>
>> Now, now, don't go busting Simon's bubble, he's having so much fun with it ..
>>
>
> Sorry you think that David, but I am not having fun with this.
>
> What I am feeling however is increasing concern that the VMS community
> may be sleepwalking, due to complacency, into a security situation
> that it is ill prepared to deal with and which could go bad very quickly.

I'd agree with that.

> My attitude is that I am trying to do people a favour by trying to make
> them realise that the security situation with regards to VMS is about
> to change big time and to jog them out of that unjustified complacency.
> This is not about me having fun.
>
> We have VMS about to become available on common x86-64 hardware and we
> have a vendor (VSI) shouting from the rooftops about how massively
> secure VMS is and believe me, this latter point will be like waving
> a red flag not to a single bull but to a whole herd of them once the
> right security researchers become aware of it.

Yes, and it's both a problem, and an opportunity. VMS will need to close any
possible avenues of attack. But if it does, and researchers start talking like
the way back DEFCON people did, it could be an advantage.

> And please don't say how things were ok back in the 1980s/1990s because
> while you are correct, you also need to understand how much things have
> changed since then.
>
>> :-)
>>
>> But, yeah, if I found an issue, I'm sure I could find someone to discuss it
>> with. Don't need so much formality ....
>
> Then why do all the other major OS companies on the planet all invest
> in formal reporting mechanisms and security teams which allow the
> security researchers to communicate _easily_ and _securely_ with the
> companies in question ?
>
> You really don't want to make the security researchers run through
> a maze trying to find people to contact in a _secure_ manner at VSI
> especially when no other major OS company, including HPE, makes them
> do that.

I'm not such a formal guy, not like Dirk with his RFCs, and your need for some
formal reporting mechanism. As I wrote, I'm sure anyone with enough knowledge
also has knowledge of VSI, and could contact them, if desired.

I also still feel that your "I'm giving you X days, and then I'm going to expose
this problem" attitude is not so good, being kind in my description. Don't
bother to argue, I doubt there is anything you can say to change my mind. We're
just going to have to disagree.

> Simon.
>
> PS: Oh, and I already sent VSI email on this subject to the above
> RnD address back somewhere in the middle of August.
>

And I do believe that it's been reported that VSI is talking about this
internally. Don't know what's your hurry, unless you're expecting the x86 port
tomorrow ....

[clairg...@gmail.com]

On Tuesday, October 4, 2016 at 11:34:27 PM UTC-4, David Froble wrote:
> Simon Clubley wrote:
> > On 2016-10-04, David Froble <da...@tsoft-inc.com> wrote:

We completely understand that VMS is behind the times in many aspects of security. That is why security is emphasized on the Roadmap and was a major focus in the keynote session by our CEO at the Boot Camp. There are no secrets here. We need massive improvements. No one disputes that. We felt we first needed to have a solid plan for a new TCPIP to give us a foundation on which to build. Now that is finally in place we should be able to show increasing progress in the future. Of course, there are also non external access areas that need addressing.

A mechanism, similar to the ones recently cited, for reporting security issues is very high on the to-do list for our website and should be available reasonably soon.

[Simon Clubley]

On 2016-10-05, clairg...@gmail.com <clairg...@gmail.com> wrote:
>
> A mechanism, similar to the ones recently cited, for reporting
> security issues is very high on the to-do list for our website and
> should be available reasonably soon.

That's excellent news Clair, thanks.

I hope such a facility isn't going to be needed _too_ much :-), but
when it's needed, it's _really_ going to be needed.

Thanks once again Clair,

Simon.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Bob Koehler via Info-vax
> Sent: 14-Sep-16 9:45 AM
> To: info...@rbnsn.com
> Cc: Bob Koehler <koe...@eisner.nospam.decuserve.org>
> Subject: Re: [Info-vax] VMS and the Internet of Things (IoT)
>

[snip..]

Another interesting article .. a company's data was being stolen
via a soda machine that had been installed internally.

http://bit.ly/2eshdNP
"What had happened, Coffey said, was that the company had a new
soft drink vending machine installed and because the machine had
both a credit card reader and was able to automatically order
replenishment, it was connected to the company network. What
nobody thought about was that the soda machine, like most IoT
devices, had no security.

When the security staff discovered that data was being stolen
from the company, they learned that data was first being copied
from the company servers to the soda machine enabling the hackers
to transfer the data to their own servers.

This happened because there was no coordination when the soda
machine was attached to the network and nobody realized that the
machine should be put outside of the company firewall, separate
from corporate network. And, of course, nobody was monitoring the
data transfers from the soda machine because it was, after all,
just a soda machine"

[Phillip Helbig (undress to reply)]

In article <mailman.3.1478449462....@rbnsn.com>,

"Kerry Main" <kemain...@gmail.com> writes:

> "What had happened, Coffey said, was that the company had a new
> soft drink vending machine installed and because the machine had
> both a credit card reader and was able to automatically order
> replenishment, it was connected to the company network. What
> nobody thought about was that the soda machine, like most IoT
> devices, had no security.

That's what you get when Mr. Coffey is responsible for the soda machine.
:-)

[johnwa...@yahoo.co.uk]

Psst, Kerry.

Don't tell anybody, but modern networked photocopiers
(which also scan and print, ie multi-function printers
aka MFP) have been offering a variant on this theme
for over a decade, not least because they frequently and
"legitimately" have both internal LAN access (so people
can print and scan things) and external network access
(so the machine can be remotely managed and otherwise
phone home as required).

The original concern was stuff stored on the hard drive
in the MFP, stuff which could be accessed by the trusty
photocopier repair people who come with their own
laptops and without any security checks (they did at one
secure UK site I'm familar with, and when someone
suggested to both IT and corporate security that there
might be various levels of weakness here, the response
wasn't encouraging).

These days, even if the photcopier as supplied by the
vendor doesn't have a hard drive, it's a piece of cake
to add spy capability later using a small format
computer (e.g. the ubiquitous Raspberry Pi hidden
somewhere in the innards of the machine, maybe using
private WiFi to get data out).

It's 11 o'clock at night. Do you know what your MFP
is doing, and what it has been doing during the day?
E.g. saving a copy of selected documents it printed or
scanned, ready for disguised upload to HQ when nobody
is expected to be watching...

Allegedly, obviously. And obviously HP Inc wouldn't do that,
but some of those nasty foreign spy companies might.

Meanwhile, more than a few years ago, vending machine
suppliers were solving the "phone home" issue by using
things like cellular modems in the machine, thereby
keeping them off the corporate network and avoiding
most of the issues described in the article.

I briefly worked with a multinational vending machine
management company who were using cellular connectivity
to solve the day to day connectivity needs. My work was
part of a Y2K exercise, which gives a hint as to how
long ago it was.

That company is long gone, but the core connectivity
and security need appears to still exist, and the cheap
and simple solution (which involves no real opportunity
for the "security" companies) is apparently of little
interest to tech media. Fancy that.

Interesting times.

[Kerry Main]

Yep - my first experience with things like smart printers was
during a HP project, we had to develop a specific strategy for
flipping MFP printers from one companies AD to another companies
AD as part of a large IT divestiture project. Company A sold a
major division to a separate Company B (a company A competitor
unfortunately, so no AD trust) and we had to flip almost 60 sites
across NA from Company A to Company B. And of course it had to be
done so that users could still walk up to the printers, enter
their code and/or their access card so they could still print,
scan, fax as they did before. Lot more complicated when printers
are controlled by AD/LDAP controls - think about every desktop
and server file/group/ACL needing to be re-acled to new AD in
parallel with all this printer stuff going on.

The article made a good point about ensuring devices like MFP,
soda machines and other IoT devices installed internally should
NOT be on the internal LAN's, but rather dedicated protected,
heavy firewall type VLAN's with pretty tight fw rules applied.

[snip..]

>
> Interesting times.
>

Yep .. reminds me of old Sun marketing slogan "..the network is
the system"

Lots of truth today in that statement.... I wonder where Andrew
is these days?

:-)