Some HP and VSI OpenVMS material.

Post by Jan-Erik Soderholm
VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE

Very interesting. Does anyone know and can say whether NetApp is one of
the "5 additional partners" under consideration?

IanD

2017-01-02 09:15:23 UTC

Post by Jan-Erik Soderholm
Hi.
A few links to PDFs and MPEGs provided by the
Swedish HP-Connect office. Note that some of the
documents can be a year or a little more old...
Most of the MPEG presentations are in Swedish but
usually using English slides.
There are also some slides from the IKEA presentation.
Have a good new Year!
Jan-Erik.
PDF slides
VSI Multivendor Storage PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HAkUADUwNAVE
VSI OpenVMS Alpha PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HA0UADUwNAVE
Java 1.8 (Java 8) Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBEUADUwNAVE
VMS File System Update PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBUUADUwNAVE
VSI TCP/IP Stack & VCI 2.0 PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HBkUADUwNAVE
OpenVMS Rolling Roadmap PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HB0UADUwNAVE
IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE
Videos
HPE IL / Hadoop MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4HCUUADUwNAVE
The portable C Compiler - PCC MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAEUADUwNAVE
OpenVMS runs on Integrity I4 MPEG4
Short intro in SWedish, talk and slides in English (Ken Surplice)
http://www.hp-connect.se/lists/lt.php?id=cE4EAUUADUwNAVE
OpenVMS roadmap MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EAkUADUwNAVE
Porting OpenVMS to x86-64 MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EA0UADUwNAVE
Heartbleed bug OpenVMS MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4FAkUADUwNAVE
HP OneView MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4ECEUADUwNAVE
Migrering till Linux MPEG4
Swedish talk, Englinsh slides.
http://www.hp-connect.se/lists/lt.php?id=cE4EBEUADUwNAVE
VMS Software Incs - VSI MPEG4
Swedish talk, Englinsh slides.
By Johan Gedda, Chairman of VSI and main investor.
http://www.hp-connect.se/lists/lt.php?id=cE4EBUUADUwNAVE
VMS Technical update - VSI MPEG4
English talk and slides, Clair Grant.
http://www.hp-connect.se/lists/lt.php?id=cE4EBkUADUwNAVE

Awesome - thanks

Maybe VSI should put you on the marketing payroll...

Simon Clubley

2017-01-03 02:24:51 UTC

Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?

(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)

So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?

Simon.

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

Simon Clubley

2017-01-03 02:32:39 UTC

Post by Simon Clubley
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)

I've just dug out the bouncing ball. The card inside the package says:

"Compaq OpenVMS on AlphaServer systems

Enterprise computing in motion

One of our customers recently reminded me that Compaq OpenVMS
on AlphaServer systems requires such little management that
you can spend some time having a little fun.

Enjoy!"

The card is signed by Rich Marcello. Perhaps VSI could send out
a modern version of that card with a message addressing today's needs ?

Simon.

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

Bill Gunshannon

2017-01-03 02:39:11 UTC

"Compaq OpenVMS on AlphaServer systems
Enterprise computing in motion
One of our customers recently reminded me that Compaq OpenVMS
on AlphaServer systems requires such little management that
you can spend some time having a little fun.
Enjoy!"
The card is signed by Rich Marcello. Perhaps VSI could send out
a modern version of that card with a message addressing today's needs ?

My bouncing ball says COMPAQ OpenVMS on it. The batteries in the
flasher died ages ago but my grandson has a blast bouncing the
ball around my home office.

bill

Kerry Main

2017-01-03 04:04:20 UTC

-----Original Message-----
Of Simon Clubley via Info-vax
Sent: 02-Jan-17 9:25 PM
Earth.UFP>
Subject: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?
I wonder how much it would cost for them to produce a little
trinket or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found
(buried in a cupboard at home) a blue DECnet OSI badge which
must be at least
20 years old. I also still have the VMS umbrella and bouncing

ball

that Sue sent out back in the Compaq days.)
So what badge or trinket do you think it might be a good idea

for

VSI to start sending out ?
Simon.

Fyi - not trinkets, but nice "leave behind" materials for
Customer visits and/or conferences and/or proposals etc.:

"VSI OpenVMS V8.4-2L1 operating environments" - August 2016
http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf

"Exceed business expectations VSI OpenVMS V8.4-2L1" - October
2016
http://h20195.www2.hpe.com/V2/getpdf.aspx/4AA6-5039ENW.pdf

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

IanD

2017-01-03 04:27:49 UTC

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

I was going to say something a little more harsh but decided to keep tings light instead

I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!

Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed

As to memorabilia owned...

My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...

I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly

I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

j***@yahoo.co.uk

2017-01-03 07:00:10 UTC

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

I was going to say something a little more harsh but decided to keep tings light instead
I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!
Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...
I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

I have an HP Invent coffee mug. Well, I think that's what it
was. Over the years, through relatively infrequent use, the
whole printed logo has vanished, perhaps as though it was a
mirage. Maybe it wasn't properly specified and tested, good
job computer systems aren't built like that. Or are they?

Also mirage-like, over the years, the alleged benefits of
switching to "low cost" software (Windows etc) in critical
cases have sometimes vanished. London Ambulance Service
were reminded of this on New Years Eve when their ambulance
dispatch service fell over and manual (paper) operation
was required for five hours, on the busiest night of the
year.

Sadly for LAS, it wasn't the first time this has happened
with their implementation of Northrop Grumman's CommandPoint
system, and it likely won't be the last. I don't suppose
the supplier will end up with any meaningful financial
penalty though; a system that's defective by design seems
to be acceptable modern practice.

London's Metropolitan Police were luckier, in a way, with
their implementation of CommandPoiunt. They didn't get as
far as rolling out CommandPoint before cancelling the
project (2016).

Isn't there some nice shiny AI tool out there yet that can
readily specify, design, rollout, and manage these critical
systems in a robust secure trustworthy and idiot-resistant
manner?

I left out "test" deliberately, the modern approach seems to
be to let the customer do the testing, preferably after the
system is paid for. Real testing seems to be a bit "20th
century". As for coding: any idiot can do that given a decent
IDE, can't they. No knowledge or understanding required,
neither of the business requirements nor of the appropriate
implementation technologies.

Kerry Main

2017-01-03 15:17:04 UTC

-----Original Message-----
Of johnwallace4--- via Info-vax
Sent: 03-Jan-17 2:00 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

On Tuesday, January 3, 2017 at 1:26:23 PM UTC+11, Simon

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

I was going to say something a little more harsh but decided

keep

tings light instead
I don't know why information such as what was posted is not

their main website because it's good. I would not have asked

half

the questions I did about the new file system had i seen this
material and I have only looked at 2 items so far!

Marketing may be a black hole but I think more marketing than

what we

have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I

borrowed it and accidentally left it on a train. That loss hurt

for a

long time...

I remember getting a set of Digital Golf Balls which I gave

away

someone who played gold at the time. If I remember rightly,

they were

Dunlop brand. In a box of 12 I think. too long ago to

remember

properly
I still have a Digital coffee cup. Blue, with a white spiral

type

pattern on it (not the traditional Digital maroon color)

I have an HP Invent coffee mug. Well, I think that's what it

was.

Over the years, through relatively infrequent use, the whole
printed logo has vanished, perhaps as though it was a mirage.
Maybe it wasn't properly specified and tested, good job
computer systems aren't built like that. Or are they?
Also mirage-like, over the years, the alleged benefits of

switching

to "low cost" software (Windows etc) in critical cases have
sometimes vanished. London Ambulance Service were reminded
of this on New Years Eve when their ambulance dispatch service
fell over and manual (paper) operation was required for five
hours, on the busiest night of the year.
Sadly for LAS, it wasn't the first time this has happened with

their

implementation of Northrop Grumman's CommandPoint system,
and it likely won't be the last. I don't suppose the supplier

will end

up with any meaningful financial penalty though; a system

that's

defective by design seems to be acceptable modern practice.
London's Metropolitan Police were luckier, in a way, with their
implementation of CommandPoiunt. They didn't get as far as
rolling out CommandPoint before cancelling the project (2016).
Isn't there some nice shiny AI tool out there yet that can

readily

specify, design, rollout, and manage these critical systems in

robust secure trustworthy and idiot-resistant manner?
I left out "test" deliberately, the modern approach seems to be
to let the customer do the testing, preferably after the system

paid for. Real testing seems to be a bit "20th century". As for
coding: any idiot can do that given a decent IDE, can't they.

knowledge or understanding required, neither of the business
requirements nor of the appropriate implementation
technologies.

No platform is 100% secure (yes, including OpenVMS), but due to
the sheer volume of 20-30+ security patches per month associated
with commodity OS platforms, the decades old best practice of
testing important apps before patching (especially security
patching) has been thrown out the window. Even if a vendor does
all the security patching before it goes live, it is up to the
Customer to keep on top of the heavily distributed (large VMware
farms are also distributed computing) world of commodity OS
security patching.

Hence, we now live in a world of "patch-n-pray".

Some lottery folks a few years back told me very directly - they
have regulatory rules that state all vendor security patches
above a certain level (important?) must be installed within 45
days. While their OpenVMS systems are rock solid from a known and
published security threats perspective, with their production
commodity OS's, they really have no options - they need to patch
their prod systems, reboot (there are always a few kernel
security issues in the monthly batch) and pray nothing breaks.

Welcome to the new world of mission critical computing.

Yes, OpenVMS needs lots of security improvements (including
recent discussions here like security bug reporting etc.), but if
OpenVMS ever gets to the point where it needs 20-30+ security
patches each and every month, then we are all in for some
extremely tough times.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Stephen Hoffman

2017-01-03 16:33:16 UTC

Ayup. More than a few folks are still approaching this problem as DEC
did too, back in the 1990s. Folks looking at these issues are working
to automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts. Work on coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches. Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts. Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification, distribution
and installation sequences are just absurdly manual processes, too.

Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems

Some lottery folks a few years back told me very directly - they have
regulatory rules that state all vendor security patches above a certain
level (important?) must be installed within 45 days. While their
OpenVMS systems are rock solid from a known and published security
threats perspective, with their production commodity OS's, they really
have no options - they need to patch their prod systems, reboot (there
are always a few kernel security issues in the monthly batch) and pray
nothing breaks.

This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE patches have
gotten pretty good, but more than a few of us still have concerns
around those — and there are times when we still have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.

Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.

Welcome to the new world of mission critical computing.

Ayup. OpenVMS or otherwise.

--
Pure Personal Opinion | HoffmanLabs LLC

Kerry Main

2017-01-03 18:38:49 UTC

-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

Post by Kerry Main
No platform is 100% secure (yes, including OpenVMS), but due

to the

Post by Kerry Main
sheer volume of 20-30+ security patches per month associated

with

Post by Kerry Main
commodity OS platforms, the decades old best practice of

testing

Post by Kerry Main
important apps before patching (especially security patching)

has been

Post by Kerry Main
thrown out the window. Even if a vendor does all the security
patching before it goes live, it is up to the Customer to keep on

top

Post by Kerry Main
of the heavily distributed (large VMware farms are also

distributed

Post by Kerry Main
computing) world of commodity OS security patching.
Hence, we now live in a world of "patch-n-pray".

Security zoning has been around for decades with FW's. The challenge with FW's is increased complexity with TCPIP mgmt. (each zone has different subnet) and difficulty in change management associated with adding, maintaining and deleting rules (ok, deleting rules takes an act of CEO level, but that’s another discussion).

Of course tools help with distribution of patches (once tested), but they do not help with change mgmt. or testing of important applications. CAB meetings and chg mgmt. processes paperwork to implement a change (even with a tool) are on par with getting teeth pulled with no antiseptic. Add a rule - get a chg request in place, get it approved, scheduled, implemented and tested.

Work on
coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches.

Distributed logging is nothing new. An OpenVMS based lottery currently bringing in about $2B/year has this implemented today. Every key entered on a system is sent (along with logs) to a different system maintained by an outside auditing group separate from Operations.

Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts.

Again, while I generally agree with zoning as a means to limit risks, there is also a trade-off as to many zones results in support complexity which will likely decrease the overall security.

I do agree there needs to be more directory based / identity management security controls and auditing which is multi-platform, multi-vendor based.

Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification,
distribution
and installation sequences are just absurdly manual processes,
too.

Agree there is room for improvement.

Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems

Highly experimental UNIX only relying on open source participation - no mention of what impact it would have on Applications and App designs. They do infer that devices DMA should be turned OFF unless it is a trusted device, so I am not sure what to make of that aspect.

Post by Kerry Main
Some lottery folks a few years back told me very directly - they

have

Post by Kerry Main
regulatory rules that state all vendor security patches above a
certain level (important?) must be installed within 45 days.

While

Post by Kerry Main
their OpenVMS systems are rock solid from a known and

published

Post by Kerry Main
security threats perspective, with their production commodity

OS's,

Post by Kerry Main
they really have no options - they need to patch their prod

systems,

Post by Kerry Main
reboot (there are always a few kernel security issues in the

monthly

Post by Kerry Main
batch) and pray nothing breaks.

This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE
patches have gotten pretty good, but more than a few of us still
have concerns around those — and there are times when we still
have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.
Just counting CVEs doesn't provide a clear picture of any
platform.
There are quite a few bugs that exist in software used on
OpenVMS that haven't been patched (on OpenVMS), too. Those
cross-platform CVEs aren't difficult to locate, for anyone inclined
to do a little basic research. CVEs can also mask larger numbers of
errors — I'm aware of a case where a vendor used one CVE to
cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.

Again - OpenVMS is not 100% secure (NO platform is), but the number of *documented* (read published) security issues with OpenVMS is far, far less than commodity OS's. It's about the VOLUME that causes "patch-n-pray" processes. Documented security issues are what Customers have to address for legal and/or auditing purposes - not might, or could be or what-if scenarios (no matter if valid or not).

Post by Kerry Main
Welcome to the new world of mission critical computing.

Ayup. OpenVMS or otherwise.

Because it is a different culture, I highly doubt many OpenVMS shops would employ patch-n-pray policies with their production environments. Likely the same could be said for Solaris, NonStop, z/OS and other, what I would call "enterprise", platforms.

Patch-n-pray is specific to commodity OS platforms.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Simon Clubley

2017-01-03 20:11:28 UTC

-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems

Highly experimental UNIX only relying on open source participation -
no mention of what impact it would have on Applications and App
designs. They do infer that devices DMA should be turned OFF unless it
is a trusted device, so I am not sure what to make of that aspect.

It's not Unix. It's a capability based microkernel which can run a
Unix personality but can also run other personalities.

The DMA issue is a known issue in computer security when you can't
be sure if the hardware can be trusted.

Just counting CVEs doesn't provide a clear picture of any
platform.
There are quite a few bugs that exist in software used on
OpenVMS that haven't been patched (on OpenVMS), too. Those
cross-platform CVEs aren't difficult to locate, for anyone inclined
to do a little basic research. CVEs can also mask larger numbers of
errors — I'm aware of a case where a vendor used one CVE to
cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.

Again - OpenVMS is not 100% secure (NO platform is), but the number
of *documented* (read published) security issues with OpenVMS is far,
far less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what
Customers have to address for legal and/or auditing purposes - not
might, or could be or what-if scenarios (no matter if valid or not).

Have any VMS security issues ever been "quietly fixed" over the years
without any public CVEs being issued for them ? That's a question, not
an accusation, BTW.

Illusion of security is not the same thing as actual security.
A low patch count could simply be one of:

1) People not probing VMS at the same rate and intensity as they do
other operating systems.

2) Patches not being issued at the same rate as issues are discovered
(TCP/IP comes to mind here.)

Simon.

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

Stephen Hoffman

2017-01-03 21:21:23 UTC

Post by Simon Clubley
Have any VMS security issues ever been "quietly fixed" over the years
without any public CVEs being issued for them ? That's a question, not
an accusation, BTW.

For a recent and public example of security-relevant fixes without
OpenVMS-associated CVEs, the VSI port of the Apache 2.4.14 version
would have fixed a number of Apache CVEs in the older version, but
AFAIK those Apache CVEs were not updated to reflect applicability of
OpenVMS nor the fix, and no associated OpenVMS-specific CVEs were
issued; they'd not show up in OpenVMS-related CVE counts. For
additional examples with various open CVEs — few or none of which track
OpenVMS, and I'd expect that at least the denial-of-service and similar
bugs with CVEs to (also) apply to OpenVMS — have a look at the version
of ISC BIND integrated into TCP/IP Services, or the NTP server. There
are also security reports against SMH citing other SMH-supported
platforms, and — where there have been reproducers — I've verified some
also effect SMH on OpenVMS.

No CVE listed in the following OpenVMS fixes, either:

http://www.securityfocus.com/advisories/8174
http://www.securityfocus.com/advisories/3630
http://seclists.org/bugtraq/2012/Apr/115
https://cxsecurity.com/issue/WLB-2010120174

Or search for security-related discussions here in the comp.os.vms
newsgroup involving Andrew Harrison.

It only takes one open hole — associated CVE or otherwise — to ruin
your whole day, too. Or one slow-to-arrive or slow-to-be-applied
patch, for that matter.

--
Pure Personal Opinion | HoffmanLabs LLC

Stephen Hoffman

2017-01-03 20:28:22 UTC

-----Original Message-----
Of Stephen Hoffman via Info-vax
Sent: 03-Jan-17 11:33 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

Post by Kerry Main
...

...More than a few folks are still approaching this problem as DEC did
too, back in the 1990s. Folks looking at these issues are working to
automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts.

The challenge with firewalls is increasingly that the attacks have
evolved, and that firewalls and traditional network design increasingly
isn't effective — well, firewalls do demarcate the edge of the network.
Zones are proliferating. Anti-virus is in roughly the same state,
too. Folks think they need that, but antivirus can itself end up being
a much bigger target for attackers — more than a few AV packages have
complex code and even parsers running in kernel mode processing
untrusted input, and which is just nuts — and increasingly doesn't
provide what folks want and install the package for.

Then there are the associated discussions around not having information
around, and how sometimes breaches can hose internal and variously
external folks; groups of folks that the IT organization either ignored
or might even have never contemplated the results of breaches.

And if it takes a CEO-level decision to delete a firewall rule? The
CEO has either just found another project to deal with and delegate, or
the board needs to re-focus or replace the CEO. Now the CEO probably
should be working to expunge data, and to age out and remove firewall
rules. To make that whole review and deprecation and expungement
process easier, and — in more complex and larger organizations — even
automatic.

Post by Kerry Main
Of course tools help with distribution of patches (once tested), but
they do not help with change mgmt. or testing of important
applications. CAB meetings and chg mgmt. processes paperwork to
implement a change (even with a tool) are on par with getting teeth
pulled with no antiseptic. Add a rule - get a chg request in place, get
it approved, scheduled, implemented and tested.

Bad management is bad management. Bad management can hose a business
without the assistance of computers and software. Computers can just
make it easier for management to hose a business.

Work on coordinating responses and on distributed logging and related
efforts is also underway. Toward expecting and responding to breaches.

Distributed logging is nothing new. An OpenVMS based lottery currently
bringing in about $2B/year has this implemented today. Every key
entered on a system is sent (along with logs) to a different system
maintained by an outside auditing group separate from Operations.

Write-up on detecting admin breaches:
https://medium.com/starting-up-security/learning-from-the-expedia-heist-6cf8a0069ce0

Logging is not something that OpenVMS does well and doesn't play at all
well with others. Various of us have written work-arounds, ported
loggers or whatever. OpenVMS itself doesn't play at all, between
Apache and other tools and OpenVMS itself, nor across non-clustered
OpenVMS servers, nor across clusters, nor with firewalls or otherwise.

Toward working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts.

Again, while I generally agree with zoning as a means to limit risks,
there is also a trade-off as to many zones results in support
complexity which will likely decrease the overall security.

We're headed toward individual hosts and smaller subnets, which means
we have to get better about automating and managing those.

Post by Kerry Main
I do agree there needs to be more directory based / identity management
security controls and auditing which is multi-platform, multi-vendor
based.

That needs to be the primary and preferred path. Whether running
self-hosted, or hosted on Active Directory or Open Directory or other
LDAP and Kerberos servers. Not via SYSUAF, et al.

Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems

Highly experimental UNIX only relying on open source participation - no
mention of what impact it would have on Applications and App designs.
They do infer that devices DMA should be turned OFF unless it is a
trusted device, so I am not sure what to make of that aspect.

OpenVMS is also using open source, and there's little choice other than
to get better about that. As for securing across boxes, have a look
at the discussions around Qubes, around Rowhammer, and around SGX.
This hardware stuff is really gnarly, when trusted and untrusted (or
breached) software is mixed on the box. OpenVMS hasn't had to deal
with this in the past (beyond vulnerable services), but we're all
headed in that direction with more than a few OpenVMS servers.

Visit the about page. "seL4 is a high-assurance, high-performance
microkernel developed, maintained and formally verified by NICTA and
owned by General Dynamics C4 Systems."

Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.

Again - OpenVMS is not 100% secure (NO platform is), but the number of
*documented* (read published) security issues with OpenVMS is far, far
less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what Customers
have to address for legal and/or auditing purposes - not might, or
could be or what-if scenarios (no matter if valid or not).

One hole is enough. Sometimes one hole in another box in the same
subnet, and as is surprisingly common. Which then opens up access to
supposedly "protected systems". Which means it's as much about
whether the vendor plugs the holes expeditiously. Again, when one of
the premier OpenVMS network storage transports (NI SCS) is unencrypted
and unauthenticated, and when DECnet is similarly problematic, you
don't even need CVEs to gain further access into supposedly-protected
systems. No CVE required.

Given what I know of CVEs, I'd be very wary about any marketing and any
claims around CVEs and vendor security, too. From any vendor. Much
like other metrics used to mismanage and mis-goal individuals and
organizations, measuring CVEs doesn't tell a particularly useful story.
CVE counts quite commonly mislead. Which might be good for vendor
marketing — in the short-term, at least — but not so good for the
end-users, or for the long-term marketing for the vendor.

Post by Kerry Main
Welcome to the new world of mission critical computing.

Ayup. OpenVMS or otherwise.

Because it is a different culture, I highly doubt many OpenVMS shops
would employ patch-n-pray policies with their production environments.
Likely the same could be said for Solaris, NonStop, z/OS and other,
what I would call "enterprise", platforms.
Patch-n-pray is specific to commodity OS platforms.

It's increasingly arising with OpenVMS, too. Because we're all under
pressure to reduce overhead, to reduce staff, to reduce hardware and
licensing costs, to automate, to deploy patches much more quickly, and
related. A team of six might have once supervised a dozen systems
from one or two vendors, now that team is five people and supervising a
hundred systems from a dozen different vendors. We ain't headed any
other way unfortunately, which means everybody has to get better about
avoiding regressions, and about dealing with regressions when they
arise. Again. the HPE UPDATE patches have been pretty around not
introducing regressions, too. As that trust — an opportunity for VSI,
and for future VSI marketing — increases, folks will be more willing to
roll out patches more quickly, and with fewer checks, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Simon Clubley

2017-01-03 20:44:59 UTC

Post by Stephen Hoffman

Post by Kerry Main
Again - OpenVMS is not 100% secure (NO platform is), but the number of
*documented* (read published) security issues with OpenVMS is far, far
less than commodity OS's. It's about the VOLUME that causes
"patch-n-pray" processes. Documented security issues are what Customers
have to address for legal and/or auditing purposes - not might, or
could be or what-if scenarios (no matter if valid or not).

To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.

When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.

Simon.

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

Johnny Billquist

2017-01-03 21:43:33 UTC

Post by Stephen Hoffman

To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.
When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.

I definitely had some issues with that research, though.

It was on the level of knocking in open doors. Very similar to, for
example, ARP cache poisoning in IP. It is trivial to take down IPv4 by
poisoning the ARP cache.
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.

You can also disrupt processing by just pulling the plug.
What does that prove?

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Simon Clubley

2017-01-03 21:57:48 UTC

Post by Simon Clubley
To emphasise that: once you compromise any general purpose OS based
system on the same LAN, you can now start attacking and monitoring
the various LAN only protocols that the VMS systems might be running.
When I briefly looked at DECnet Phase IV the other month, my research
was limited to affecting VMS operations by throwing various malformed
packets at the test system. I simply wasn't interested in other goals
such as password or data gathering because I already knew that DECnet
Phase IV was totally compromised in that area once you had that level
of access.

Yes, I know. As I've said multiple times, I didn't spend a lot of time
on it so that's about as deep as I got.

Post by Johnny Billquist
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.

The major surprise for me was that the VMS DECnet Phase IV
implementation running on the target node trusts external packets
with a source address that claims to be the address of the
target node. _That_ I was not expecting to see.

When you do ARP cache poisoning, you are poisoning the cache as
it relates to other nodes on the network (as seen from the
target node) and not the target node itself.

Post by Johnny Billquist
You can also disrupt processing by just pulling the plug.
What does that prove?

That you should have put a lock on your computer room door. :-)

Simon.

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

Johnny Billquist

2017-01-03 22:22:59 UTC

Post by Johnny Billquist
You can obviously disrupt network traffic in any number of ways if you
can inject packets on a local network.
DECnet or IP makes no difference.

Well, that is better than ARP, which trust any packet from anywhere,
claiming anything. You can put *anything* as a source in an ARP packet,
and it will be accepted. And you can put *anything* in the various
fields of the ARP packet, and that will be placed in the cache.

Post by Simon Clubley
When you do ARP cache poisoning, you are poisoning the cache as
it relates to other nodes on the network (as seen from the
target node) and not the target node itself.

Uh? You are fooling the target node to send packets destined for one
host to be sent to someone completely different, possibly a black hole.
Why is it that is being hurt? I'd say the target node.

A similar issue is poisoning the routing table by sending RIP packets.
No checking at all is done. So you don't even have to fake any source
addresses there either.

Your DECnet injection did the same. Fooling the target node how to reach
next hops by messing up the routing table.

Very many protocols, for different network stacks, at some point just
accepts packets from neighbors. I fail to see that DECnet is either
better or worse than anything else here.

Post by Johnny Billquist
You can also disrupt processing by just pulling the plug.
What does that prove?

That you should have put a lock on your computer room door. :-)

Indeed. :-)

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Stephen Hoffman

2017-01-03 22:02:32 UTC

...once you compromise any general purpose OS based system on the same
LAN, you can now start attacking and monitoring...

FWIW, who needs to start the server compromise with a general-purpose
operating system? Just use a (now down-revision) printer for that...

One bad PDF sent to an internal user and then printed on a
down-revision printer, and network deflagration commences.

There are other and equally clever attacks against other network boxes
— all sorts of stuff "behind a firewall" can be vulnerable.

--
Pure Personal Opinion | HoffmanLabs LLC

j***@yahoo.co.uk

2017-01-03 21:41:24 UTC

Post by Stephen Hoffman

Ayup. More than a few folks are still approaching this problem as DEC
did too, back in the 1990s. Folks looking at these issues are working
to automate the patch distribution, and working on improving software
scanning — source code, fuzzers, etc — and on isolating breaches —
sandboxes/jails, SGX, etc — and other efforts. Work on coordinating
responses and on distributed logging and related efforts is also
underway. Toward expecting and responding to breaches. Toward
working across clusters, and across whole networks, and toward
isolating networks into smaller hunks and bastion hosts. Containers
and VM guests for faster reloads and restarts, while sorting out
whatever the issue was. The OpenVMS patch notification, distribution
and installation sequences are just absurdly manual processes, too.
Yes, there are folks that are working on proving system security too,
but OpenVMS is not in that market. https://sel4.systems

This is not particularly different on OpenVMS. More than a few of us
defer updates because of the fear of breakage — UPDATE patches have
gotten pretty good, but more than a few of us still have concerns
around those — and there are times when we still have to patch OpenVMS
and test what we can and roll out quickly. That 45 day window for
applying patches is exceptionally generous, too. I've seen more than
a few attacks arrive ahead of the patches, and that's only going to
become more common.
Just counting CVEs doesn't provide a clear picture of any platform.
There are quite a few bugs that exist in software used on OpenVMS that
haven't been patched (on OpenVMS), too. Those cross-platform CVEs
aren't difficult to locate, for anyone inclined to do a little basic
research. CVEs can also mask larger numbers of errors — I'm aware of a
case where a vendor used one CVE to cover ~400 separate problems. And
there are security problems that never get CVEs. Most of the
marketeers eventually learn that everybody gets hit with security
vulnerabilities and breaches.

Welcome to the new world of mission critical computing.

Ayup. OpenVMS or otherwise.
--
Pure Personal Opinion | HoffmanLabs LLC

Re seL4:
Any paper which talks about proof of correctness of any
non-trivial software system without acknowledging the
existence of the famous quote "Beware of bugs in the
above code; I have only proved it correct, not tried it"
is likely to get a thumbs down from people with a clue.

Same for something which references a "proof of
correctness of a realistic compiler". My first
employer spent many years in safety critical embedded
software which could do non-trivial things using simple
(testable, sometimes provable) combinations of provable
and testable components, without the unprovable and
untestable complexities of a compiler.

These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.

There are some interesting bits in the paper though. E.g.
some of the starting points: keep the attack surface
small and well characterised (arguably applies to much
of VMS, less so to commodity OSes), build bigger systems
from a collection of smaller trusted components (did that
in the 1980s thank you), microkernel approach (not
widely applicable in general, exceptions may apply, and
beware of some 'modern' approaches which appear to use
the words 'hypervisor' and 'microkernel' interchangeably,
as though they meant the same - but do they?).

The endgame is also laudable: "strong, code/machine level
guarantees as table stakes for highly critical systems."

This bit: "Leveraging separation kernels to create high
assurance architectures with formally verified software
components, as outlined in this paper, provides a means
to implement such systems with measurable security
enhancements." is interesting. It's the one which
Dilbert might generally replace with "a miracle occurs
here".

There's at least one major builder of aircraft safety
critical systems who would like to build their near-future
systems built using model-based engineering techniques
including model based software engineering. And why not.

What's less obviously satisfactory is that this company
would like to be testing (and maybe proving) the behaviour
of the *model* of the system. So a component swap (from,
say, one GCC version to another) doesn't have any
implications, as long as the changed components have
equivalent formal specifications and formal proofs.

Not that GCC or any other significant code generator is
meaningfully provable, but that's another story (see
the opening quote re proof vs testing, and Thompson's
tales on "Trusting Trust", amongst others).

Don't take my word for this, have a look at this
analysis of some of the claims of the Qubes and
seL4 folk:
http://theinvisiblethings.blogspot.co.uk/2010/05/on-formally-verified-microkernels-and.html

Some people/organisations might even want to look at
(say) a modernised Orange Book-style system as well as
new unproven (sic) allegedly-from-scratch stuff like
seL4, Qubes, etc.

The devil is in the detail, not in the Powerpoint or
the white papers or even the bogs (but I could quite
like ones like the one from theinvisiblethings above).

Bob Koehler

2017-01-04 14:34:40 UTC

Post by j***@yahoo.co.uk
These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.

That depends on the field. I've worked with some that required
certified versions of the OS, the compiler, the chip, ...

j***@yahoo.co.uk

2017-01-04 15:15:08 UTC

Post by Bob Koehler

Post by j***@yahoo.co.uk
These days the compiler trustworthiness topic is likely
to be conveniently (and silently) ignored.

That depends on the field. I've worked with some that required
certified versions of the OS, the compiler, the chip, ...

Certification and trustworthiness are unfortunately
not entirely the same thing - as you say, maybe
it depends on the field, the regulatory rules, etc.

I don't know where your experience is, but e.g.
avionic systems certified to DO178 (SW) and DO254
(electronic hardware) etc cannot be trusted to be
defect free and to do the right thing, despite
the certification paperwork.

I'll be delighted to hear that other sectors take
this more seriously.

Bob Koehler

2017-01-04 22:02:21 UTC

Post by j***@yahoo.co.uk
Certification and trustworthiness are unfortunately
not entirely the same thing - as you say, maybe
it depends on the field, the regulatory rules, etc.
I don't know where your experience is, but e.g.
avionic systems certified to DO178 (SW) and DO254
(electronic hardware) etc cannot be trusted to be
defect free and to do the right thing, despite
the certification paperwork.
I'll be delighted to hear that other sectors take
this more seriously.

I dabbled in manned space flight when I ran into the requirement.
It's part of making sure there's a quite high likelyhood of success.
It's a small part of a very serious undertaking, which newbies like
SpaceX are trying to streamline.

David Froble

2017-01-03 15:48:20 UTC

Post by j***@yahoo.co.uk

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

I was going to say something a little more harsh but decided to keep tings light instead
I don't know why information such as what was posted is not on their main website because it's good. I would not have asked half the questions I did about the new file system had i seen this material and I have only looked at 2 items so far!
Marketing may be a black hole but I think more marketing than what we have seen to date is sorely needed
As to memorabilia owned...
My wife had a Digital umbrella up until the point where I borrowed it and accidentally left it on a train. That loss hurt for a long time...
I remember getting a set of Digital Golf Balls which I gave away to someone who played gold at the time. If I remember rightly, they were Dunlop brand. In a box of 12 I think. too long ago to remember properly
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

I have an HP Invent coffee mug. Well, I think that's what it
was. Over the years, through relatively infrequent use, the
whole printed logo has vanished, perhaps as though it was a
mirage. Maybe it wasn't properly specified and tested, good
job computer systems aren't built like that. Or are they?
Also mirage-like, over the years, the alleged benefits of
switching to "low cost" software (Windows etc) in critical
cases have sometimes vanished. London Ambulance Service
were reminded of this on New Years Eve when their ambulance
dispatch service fell over and manual (paper) operation
was required for five hours, on the busiest night of the
year.
Sadly for LAS, it wasn't the first time this has happened
with their implementation of Northrop Grumman's CommandPoint
system, and it likely won't be the last. I don't suppose
the supplier will end up with any meaningful financial
penalty though; a system that's defective by design seems
to be acceptable modern practice.
London's Metropolitan Police were luckier, in a way, with
their implementation of CommandPoiunt. They didn't get as
far as rolling out CommandPoint before cancelling the
project (2016).
Isn't there some nice shiny AI tool out there yet that can
readily specify, design, rollout, and manage these critical
systems in a robust secure trustworthy and idiot-resistant
manner?
I left out "test" deliberately, the modern approach seems to
be to let the customer do the testing, preferably after the
system is paid for. Real testing seems to be a bit "20th
century". As for coding: any idiot can do that given a decent
IDE, can't they. No knowledge or understanding required,
neither of the business requirements nor of the appropriate
implementation technologies.

Now, now, no reason to be so bitter ....

On second thought ....

Bob Koehler

2017-01-03 15:33:53 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

I still have a Chrlie Matco cup.

Johnny Billquist

2017-01-03 21:36:05 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

IanD

2017-01-04 05:04:11 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol

I didn't realise this - thanks

I always thought it was this

https://goo.gl/images/DSfycR

I'm trying to think when I first started all those years ago what colour the manuals were. I think they were that ghastly orange

Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time

Johnny Billquist

2017-01-04 09:49:38 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol

I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR

That is the new logo Palmer introduced in the 90s. Ugly one... :-)

Post by IanD
I'm trying to think when I first started all those years ago what colour the manuals were. I think they were that ghastly orange
Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time

Yeah. You must be young... :-D

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Bill Gunshannon

2017-01-04 12:57:59 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol

Nope, Blue came first. I still have my Blue RT-11 and RSTS manuals
right next to my Orange RSTS/E manuals. :-)

Post by IanD
Clearly i don't go back far enough lol. I was fairly young back then, about 10+ years younger than most people in the Dec world at the time

And I happily admit that in this world I am truly a dinosaur.

bill

Arne Vajhøj

2017-01-10 01:15:38 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern
on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.

I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
Clearly i don't go back far enough lol. I was fairly young back then, about
10+ years younger than most people in the Dec world at the time

I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware
focus to red illustrating warm people focus.

I think many VMS people almost fall of the chair reading such crap.

Arne

Kerry Main

2017-01-10 01:28:37 UTC

-----Original Message-----
Arne Vajhøj via Info-vax
Sent: January 9, 2017 8:16 PM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

On Wednesday, January 4, 2017 at 8:36:05 AM UTC+11, Johnny

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral

type

Post by IanD
pattern
on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.

I didn't realise this - thanks
I always thought it was this
https://goo.gl/images/DSfycR
Clearly i don't go back far enough lol. I was fairly young back

then,

about
10+ years younger than most people in the Dec world at the time

I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware

focus

to red illustrating warm people focus.
I think many VMS people almost fall of the chair reading such crap.
Arne

Real reason was the marketecture gurus at the time thought blue was
too close to "Big Blue" - the other computer company.

They wanted a way to differentiate DEC as IBM was who DEC was chasing
for the long term.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Simon Clubley

2017-01-10 18:26:10 UTC

Post by Arne VajhÃ¸j
I remember when they sent out a letter to all customers saying that
they were changing the color from blue illustrating cold hardware
focus to red illustrating warm people focus.
I think many VMS people almost fall of the chair reading such crap.

The one I remember shaking my head in disbelief at was when they
went from the grey wall for the V5 documentation set to the bound
books for V6 and they included a sheet in the V6 doc kit claiming
they were doing it to be green (or words to that effect).

Simon.

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

David Froble

2017-01-04 07:21:32 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny

Back in 1973 our PDP 11/40 was not blue. I seem to remember red and black, but,
it's my memory, and such cannot be counted on anymore.

:-)

The PDP-6 at the University of Pittsburgh was grey, I believe ....

Johnny Billquist

2017-01-04 09:52:03 UTC

Post by David Froble

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny

Back in 1973 our PDP 11/40 was not blue. I seem to remember red and
black, but, it's my memory, and such cannot be counted on anymore.
:-)
The PDP-6 at the University of Pittsburgh was grey, I believe ....

The computers all used different color schemes. PDP-11s usually had some
maroon/magenta scheme. PDP-12 were green. The list goes on...

However, the official DEC logo, and colors used on all material, and so
on, was blue. For a long, long time... And the dots above the i in
"Digital" were square. Until Palmer messed everything up.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: ***@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

IanD

2017-01-04 23:28:20 UTC

On Wednesday, January 4, 2017 at 8:52:05 PM UTC+11, Johnny Billquist wrote:

<snip>

Post by Johnny Billquist
The computers all used different color schemes. PDP-11s usually had some
maroon/magenta scheme. PDP-12 were green. The list goes on...
However, the official DEC logo, and colors used on all material, and so
on, was blue. For a long, long time... And the dots above the i in
"Digital" were square. Until Palmer messed everything up.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
pdp is alive! || tryin' to stay hip" - B. Idol

Now it's things like this that I find fascinating

Some may think it trivial but I find it interesting to know that not only the colours changes but even dots used on the i's - truly fascinating what people remember :-)

I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?

Seems to me that engineering folk back then took even little things like this into account

Simon Clubley

2017-01-05 01:11:17 UTC

Post by IanD
Now it's things like this that I find fascinating
Some may think it trivial but I find it interesting to know that not
only the colours changes but even dots used on the i's - truly
fascinating what people remember :-)

If you like trival things :-), did you pick up on the fact that
the old blue logo is monospaced while the new Palmer logo is
proportional ?

A couple of other items of trivia that I thought every one else
around here knew, but since you didn't know about the blue logo,
here goes... :-)

The entrance to the old VMS facility in Nashua used to have a
two dimensional barcode sign. One day some management type
discovered that the two dimensional array of blocks they were
travelling past each day actually had meaning and ordered the
message to be changed to some inane marketing message.

Going back further, the various levels at the Mill had the
resistor colour codes painted on the walls so if you knew your
resistor colour codes, you could tell which level you were on
by looking at the colour painted on the wall.

Going back even further, I've seen claims that the PDPs were
called PDPs so that the word computer didn't appear anywhere
within the product's title. It was apparently a marketing
thing as in those days "computers" were perceived as big
expensive things...

Simon.

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

Alan Frisbie

2017-01-05 02:05:06 UTC

Post by Simon Clubley
The entrance to the old VMS facility in Nashua used to have a
two dimensional barcode sign. One day some management type
discovered that the two dimensional array of blocks they were
travelling past each day actually had meaning and ordered the
message to be changed to some inane marketing message.

And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.

In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.

Alan Frisbie

Bob Koehler

2017-01-06 14:42:32 UTC

Post by Alan Frisbie
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.

Had a manager once who had a sign in his office:

HTE
IDIGATL
IDFFRENEEC

Simon Clubley

2017-01-06 18:17:13 UTC

Post by Alan Frisbie
And when the bars were put back up, two of them were accidentally
(I assume) swapped, changing two letters. If anyone cares, I can
dig up photos of it, with the errors identified.
In late 1980s, the exterior of the DEC office building in Culver City
(Calif.) was refurbished. This required removing and re-installing
the "digital" letters near the top of the building. When they were
re-installed, they read "dgiital" for a few days. I have photos.

I would very much like to see both sets of photographs if it's
not too much work for you to post them.

Thanks,

Simon.

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

Alan Frisbie

2017-01-06 23:39:54 UTC

I would very much like to see both sets of photographs if it's
not too much work for you to post them.

I will dig them out and scan them, but it may take a while.

Alan

Simon Clubley

2017-01-09 00:03:41 UTC

Post by Alan Frisbie

I would very much like to see both sets of photographs if it's
not too much work for you to post them.

I will dig them out and scan them, but it may take a while.

Thank you, I appreciate that.

(However, although it would be nice to see them, I don't want you
to go to any major effort on my account, so I will gladly wait
until as and when it is convenient for you to scan them.)

Thanks once again,

Simon.

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

j***@yahoo.co.uk

2017-01-05 09:14:58 UTC

Post by IanD
<snip>

Now it's things like this that I find fascinating
Some may think it trivial but I find it interesting to know that not only the colours changes but even dots used on the i's - truly fascinating what people remember :-)
I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?
Seems to me that engineering folk back then took even little things like this into account

As some people said at the time re the reshaping of the dot
on the 'i', "truly fascinating what some board-level people
will waste money on".

I don't recall a technical reason for it (fonts etc were all
custom anyway).

Paul Sture

2017-01-05 09:57:30 UTC

Post by j***@yahoo.co.uk

Post by IanD
Some may think it trivial but I find it interesting to know that not
only the colours changes but even dots used on the i's - truly
fascinating what people remember :-)
I wonder if those square dots were because of a font limitation or
whether it was due to a translation from dot matrix design or for
some other reason?
Seems to me that engineering folk back then took even little things
like this into account

As some people said at the time re the reshaping of the dot
on the 'i', "truly fascinating what some board-level people
will waste money on".

A former colleague observed that in a large organisation, the closer you
get to Headquarters, the more money gets wasted.

Post by j***@yahoo.co.uk
I don't recall a technical reason for it (fonts etc were all
custom anyway).

My guess is that there was a proposal and accompanying study into a
completely new logo, which met much resistance. The change to the
dot will have been used to justify the cost.

--
"History does not repeat itself, but it does rhyme" -- Mark Twain

Stephen Hoffman

2017-01-05 14:18:07 UTC

And if you think folks remembering this DEC stuff is fascinating, find
and ask some other folks about steam trains. 2-5-2 has an entirely
different meaning over in that domain. Or ask about vintage
automobiles. Or needlepoint. Or chess. Or sporting teams. Or
clothing fashions. Or Mesoamerican cultures and constructions. Or
family histories. Or politics. Or.... People are like that in
areas that interest them, and remember a whole lot. Or at least think
they remember a whole lot. Sometimes. Maybe. I forget. What was
the discussion?

Post by IanD
I wonder if those square dots were because of a font limitation or
whether it was due to a translation from dot matrix design or for some
other reason?
Seems to me that engineering folk back then took even little things like this into account

Start here for some details of the bricks logo:
http://nedbatchelder.com/blog/200712/ancient_history_the_digital_logo.html
and then follow the metafilter link at the bottom of that through to
more arcana. BTW, the Maynard Mill was brick.

The Palmer-era burgundy bricks logo rework had more than a few
associated stories around its origins and costs, and a few wags
referred to that then-new burgundy logo color as "the color of dried
blood", alluding to the changes then happening in the company.

For some time, the pattern of the ZKO "bars" — the DEC Nashua site
located on Spit Brook Road, and not the concessionary at the Zurich
Chamber Orchestra — translated as:
digitalsoftwa
reengineering

DEC had standards for a whole lot of things, with copies of a few of
those now posted around the network. DEC Standard 32 was the VAX
architecture, and there were part-numbering standards and Unibus
standards and printer and terminal standards and... Lots and lots of
tech specs to read through. The OpenVMS documentation "wall" didn't
come from anywhere strange; DEC's preferred user interface was chapters
and chapters of detailed, technical prose, and matrix managers and
committees. The Engineering Handbook (1990 edition was the last) was
the introduction to the internal organization of the company.

http://bitsavers.trailing-edge.com/pdf/dec/vax/archSpec/EL-00032-00-decStd32_Jan90.pdf

DEC, however, is long gone, the competitive world that DEC operated in
is also long gone, and trying to mimic what DEC did will fail. Parts
of the DEC business model and organization and processes can be
salvaged and reused, but other parts and practices are best be avoided.
Avoid the fondness for creating what were sometimes known as Product
Prevention Committees, for one. VSI will be keeping the best bits of
DEC, but necessarily forgetting parts of DEC and even necessarily
discarding some of the good-but-dated DEC bits, if they are to succeed.
But I digress. There are books on DEC around, various of which have
been discussed here in the comp.os.vms newsgroup before. DEC is Dead
Long Live Dec is one that's been published, though I've not read it.

--
Pure Personal Opinion | HoffmanLabs LLC

Scott Dorsey

2017-01-05 14:27:20 UTC

Post by Stephen Hoffman
DEC, however, is long gone, the competitive world that DEC operated in
is also long gone, and trying to mimic what DEC did will fail. Parts
of the DEC business model and organization and processes can be
salvaged and reused, but other parts and practices are best be avoided.
Avoid the fondness for creating what were sometimes known as Product
Prevention Committees, for one. VSI will be keeping the best bits of
DEC, but necessarily forgetting parts of DEC and even necessarily
discarding some of the good-but-dated DEC bits, if they are to succeed.
But I digress. There are books on DEC around, various of which have
been discussed here in the comp.os.vms newsgroup before. DEC is Dead
Long Live Dec is one that's been published, though I've not read it.

I highly recommend the book if you are curious about what went wrong with
DEC.

DEC's biggest competitor for a long time was itself, which was a problem.
When the killer micros came out they had actual third-party competition and
that was even more of a problem..
--scott

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

Kerry Main

2017-01-05 15:49:04 UTC

-----Original Message-----
Of Scott Dorsey via Info-vax
Sent: 05-Jan-17 9:27 AM
Subject: Re: [Info-vax] VMS marketing, was: Re: Some HP and VSI
OpenVMS material.

Post by Stephen Hoffman
DEC, however, is long gone, the competitive world that DEC

operated in

Post by Stephen Hoffman
is also long gone, and trying to mimic what DEC did will fail.

Parts

Post by Stephen Hoffman
of the DEC business model and organization and processes can

Post by Stephen Hoffman
salvaged and reused, but other parts and practices are best be

avoided.

Post by Stephen Hoffman
Avoid the fondness for creating what were sometimes known

as Product

Post by Stephen Hoffman
Prevention Committees, for one. VSI will be keeping the best

bits of

Post by Stephen Hoffman
DEC, but necessarily forgetting parts of DEC and even

necessarily

Post by Stephen Hoffman
discarding some of the good-but-dated DEC bits, if they are to

succeed.

Post by Stephen Hoffman
But I digress. There are books on DEC around, various of

which

have

Post by Stephen Hoffman
been discussed here in the comp.os.vms newsgroup before.

DEC is Dead

Post by Stephen Hoffman
Long Live Dec is one that's been published, though I've not

read

it.
I highly recommend the book if you are curious about what went
wrong with DEC.
DEC's biggest competitor for a long time was itself, which was

problem.
When the killer micros came out they had actual third-party
competition and that was even more of a problem..
--scott

Fyi -

Shortened Amazon url:
DEC Is Dead, Long Live DEC: The Lasting Legacy of Digital
Equipment Corporation

http://amzn.to/2iTXYAk

Original (will wrap)
https://www.amazon.com/DEC-Dead-Long-Live-Corporation/dp/15767530
50/ref=sr_1_1?ie=UTF8&qid=1483631061&sr=8-1&keywords=DEC-dead

On a similar vein:
http://www.sigcis.org/files/Goodwin_paper.pdf
"In 1987 Digital Equipment Corporation (DEC) was the number two
computer manufacturer in the world with its founder being named
the "'most successful entrepreneur in the history of American
business" by Fortune magazine. This paper looks at the later
history of Digital Equipment Corporation and asks how an
organization that was so successful in 1988 could sink to become
a takeover target for a PC hardware company ten years later. The
management styles and company culture have been extensively
described in Edgar Schein's book "DEC is dead, long live DEC" but
there is much more to the story. The technology that the company
developed and the business decisions made in the development and
the direction of that technology had a major bearing on the fate
of the company. Many mistakes were made over the last fifteen
years of the company's existence and this paper offers a
suggestion as to what those mistakes were."

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

Bob Koehler

2017-01-06 14:35:44 UTC

Post by IanD
I wonder if those square dots were because of a font limitation or whether it was due to a translation from dot matrix design or for some other reason?

Back in the 60's folks wanted their computers to look futuristic and
high tech. So they used fonts inspired by what actually showed up on
band and drum printers. This changed a bit when dot-matrix printers
came out.

Lots of the fonts used in the 60s were designed to be optically
scanable, even though very few working OCR systems were deployed back
then.

Bob Koehler

2017-01-04 15:29:23 UTC

Post by David Froble

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type
pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.
Johnny

Back in 1973 our PDP 11/40 was not blue. I seem to remember red and black, but,
it's my memory, and such cannot be counted on anymore.

PDP 11/70 tended to be purple data processors.

Bob Koehler

2017-01-04 14:32:20 UTC

Post by IanD
I still have a Digital coffee cup. Blue, with a white spiral type pattern on it (not the traditional Digital maroon color)

Uh. Blue is the traditional DEC color, not maroon.

That seemed to vary over time. Both in coffee cups and in computer
cabinet tops.

Bob Koehler

2017-01-03 15:32:54 UTC

Post by IanD
Awesome - thanks
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?
I wonder how much it would cost for them to produce a little trinket
or a badge and send them out to potential customers ?
(This latter question was prompted by the fact I recently found (buried
in a cupboard at home) a blue DECnet OSI badge which must be at least
20 years old. I also still have the VMS umbrella and bouncing ball
that Sue sent out back in the Compaq days.)
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?

I have a little flashy badgy thingy that says something about VMS
and still lights up, decades later.

Phillip Helbig (undress to reply)

2017-01-03 19:49:03 UTC

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

Which payroll is Sue on?

I lost the umbrella on a train but still have the ball. And a DECUS
Copenhagen mouse pad. And a "call me anytime" button ("call" refers to
the RTL). And some "VAX at 20" bumper stickers. And a Compaq mug I got
when I made a pilgrimage to Nashua.

Post by Simon Clubley
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?

A 1-year license.

Alan Greig

2017-01-05 00:40:17 UTC

Post by Phillip Helbig (undress to reply)

Post by IanD
Maybe VSI should put you on the marketing payroll...

VSI has a _marketing_ payroll ??? Are you sure about that ?

Which payroll is Sue on?

Post by Simon Clubley
So what badge or trinket do you think it might be a good idea for
VSI to start sending out ?

A 1-year license.

One of my balls split in half. The other gave up flashing a long time ago. However my umbrella still gets actual use occasionally (I tell people who recognise only the Compaq name it's wifi enabled :-) and I just found my "VMS bigot" badge that I completely forgot about. And the less said about the flashing pens (I think that was Compaq), that would light you up like a Christmas tree at airport security, the better :-)

Jerome Ibanes

2017-01-03 03:22:38 UTC

Post by Jan-Erik Soderholm
IKEAs presentation PDF
http://www.hp-connect.se/lists/lt.php?id=cE4HCEUADUwNAVE

Found this one very interesting, thanks for sharing, would like to find additional
documentation on the ikea implementation.

J

u***@gmail.com

2017-01-09 08:14:07 UTC

OpenVMS apps can all be made SECURE simply by not giving them
system access. Mandatory use of ACLs should be implimented for all
software on the x86 platform. Keep your apps in a secure box and
no security threats.

Stephen Hoffman

2017-01-09 17:46:07 UTC