Updated HPE/VSI OpenVMS V8.4-2L1 Marketing Brochures

[Kerry Main]

Fyi .. updated OpenVMS V8.4-2L1 brochures on the HPE web site

VSI OpenVMS V8.4-2L1 Operating Environments:
http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf

Exceed Business Expectations: VSI OpenVMS V8.4-2L1
https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039E
NW


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[Simon Clubley]

On 2016-09-16, Kerry Main <kemain...@gmail.com> wrote:
> Fyi .. updated OpenVMS V8.4-2L1 brochures on the HPE web site
>
> VSI OpenVMS V8.4-2L1 Operating Environments:
> http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf
>
> Exceed Business Expectations: VSI OpenVMS V8.4-2L1
> https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039E
> NW
>

Kerry's Usenet client has broken the second link. Correct link is:

https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039ENW

Kerry, you really need to sort out the client you are using...

BTW, who still uses DECnet Phase V ? (It's referenced in the first link).

Simon.


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

[Dirk Munk]

Simon Clubley wrote:
> On 2016-09-16, Kerry Main <kemain...@gmail.com> wrote:
>> Fyi .. updated OpenVMS V8.4-2L1 brochures on the HPE web site
>>
>> VSI OpenVMS V8.4-2L1 Operating Environments:
>> http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf
>>
>> Exceed Business Expectations: VSI OpenVMS V8.4-2L1
>> https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039E
>> NW
>>
>
> Kerry's Usenet client has broken the second link. Correct link is:
>
> https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039ENW
>
> Kerry, you really need to sort out the client you are using...
>
> BTW, who still uses DECnet Phase V ? (It's referenced in the first link).
>
> Simon.
>
>

There we go again, sigh.

*If* you want to use DECnet, and you have an IP only network
infrastructure (and that is very likely these days), you can *only* use
DECnet Phase V, since it has an IP transport stack. OSI has been
designed to use IP as well next to other OSI transport stacks.

There is an RFC for using IPv6 as well, in fact it is a very old RFC. I
hope (and expect) that the new VSI IP stack will also incorporate this RFC.

Since DECnet Phase V also has OSI application that are still being used
in the industry, DECnet Phase V is a very necessary product.

[Dirk Munk]

Have you noticed that the first brochure points to HP branded layered
products?

Since this is a VSI version of OpenVMS, only VSI branded layered
products are supported.

That is going to be an interesting challenge for HPE in the future.

[Kerry Main]

HPE is clearly getting back to its roots as a server and
supporting infrastructure company. Some analysts have stated they
want to be seen as a neutral company that can play and integrate
with all of the other vendors platforms.

Over time, I expect HPE to transition to support of OpenVMS in a
manner similar to the way they support Linux (now moving towards
SuSE which is interesting) and Windows i.e. as a means to sell
server and supporting infrastructure. Hence, other than the
occasional brochures like those in this thread, I would not
expect HPE to market OpenVMS any more than they market other
platforms. As an example, in their future ProLiant brochures and
tech documents, they would have "the ProLiant XYZ supports
Microsoft Windows Server 2012, Red Hat Linux, SuSE Linux and VSI
OpenVMS V9."

That in itself will be a major milestone.

Having their own server OS solutions would not be in alignment
with being a neutral server and supporting infrastructure
company. Especially when OpenVMS sales on X86-64 begin to pick
up.

It's also why I expect NonStop will be spun off in the next 24
months - most likely in a manner similar to how OpenVMS was
successfully spun-off. HP-UX will likely not be spun off for a
long time (after 2025 perhaps?) as there is an interesting
fascination internally at HP with HP-UX. Also, given HPE is
pushing its HP-UX Customers to Linux, I am not sure if any third
party Company would take on the future support of HP-UX (unless
HPE gave them a truck full of $'s).

Interesting times ..

[IanD]

It's already getting messy and it will annoy customers having to be across this

I would also assume that VSI are hoping that those customers out there that are sitting on the fence with HP(e) installs will suddenly up-root and move across to VSI since it looks like HPE are probably not going to drag forward their offerings other than for perhaps security based items?

I know of one place that is going VSI purely to get onto those nice i4's so there are customers already moving, although I suspect the numbers are small (but I don't actually know)

In time, HPE will be the second class citizen. How quickly that happens I think will be a function of how fast VSI can deliver items that matter to customers and how viable those customers platforms are in their strategic business going forward. If they are just turn-key systems sitting in a corner earmarked for eventual death, then I suspect they will remain in the HPE side of the fence for a very long time unless VSI give some dam good incentives for moving off a zero cost or probably close to zero cost environment

[IanD]

On Saturday, September 17, 2016 at 10:40:05 PM UTC+10, Kerry Main wrote:

<snip>

>
> HPE is clearly getting back to its roots as a server and
> supporting infrastructure company. Some analysts have stated they
> want to be seen as a neutral company that can play and integrate
> with all of the other vendors platforms.
>

wtf!!!

This is exactly what EDS was and HP killed that remaining neutral philosophy that was hammered into every EDS employee

"We have no product to sell, only the services of our people" was the underlining EDS moto and as an employee when you put together quotes for a customers IT solution, you had the freedom to choose what-ever hardware and software you thought fitted the bill. Sun, HP, IBM etc, it didn't matter back then

After the HP takeover, we were badgered into picking HP products in the first instance. In time, our customers slowly realized the wonderful impartiality that used to set us apart had gone and they started shopping elsewhere

Now your telling me that HPE has changed it's spots? I'll believe it when I see it. There a lot of middle management in HP stamped with the 'I must sell HP at all costs' mentality - I will find it an amazing turn-around if HPE can purge years of built up cultural philosophy overnight

Technical changes are the easiest to implement, cultural ones take years...

It will be interesting to see who snaps up non-stop. The banking sector is slowly moving on from mainframes (commonwealth bank in Australia has gone to great lengths and I believe the other banks here are also moving too)

IBM perhaps?

What will HPE actually stand for in the future then?

IT is becoming more and more a commodity every day. It will eventually become like electricity, you flick the switch and don't care who's supplying you the goods as long as it meets a set minimum standard that you require

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

Grid electricity may be a commodity. The UK is perilously
close to finding out by bitter experience what happens to
continuity of supply (countrywide and locally) when
"investment" becomes a dirty word, and planning is
abandoned in favour of leaving it to a cartel of suppliers
and a string of half witted 'industry regulators'. If
memory serves me right, parts of the USA had this
experience some years ago, to an extent.

There are some people and organisations for whom
electricity is sufficiently important that rather than
relying on commodity electricity suppliers and designs,
they take specific measures to minimise the impact of a
failure in the electricity supply chain. Some sites
might have dual feeds via two allegedly separate
routes from the distribution network. Some sites might
have the capability to generate their own electricity
if their grid connection fails. Maybe other options too,
e.g. move the work to another site instead.

Not many sites will go to those extents, but some will
see it as being important enough to spend time and money
on. Enough will do it for there to (continue to) be a
business in designing and building high availability
electricity supplies.

Needs vary. Systems need to be engineered accordingly.

See any parallels with the IT world?

[David Froble]

IanD wrote:

> In time, HPE will be the second class citizen. How quickly that happens I
> think will be a function of how fast VSI can deliver items that matter to
> customers and how viable those customers platforms are in their strategic
> business going forward. If they are just turn-key systems sitting in a corner
> earmarked for eventual death, then I suspect they will remain in the HPE side
> of the fence for a very long time unless VSI give some dam good incentives
> for moving off a zero cost or probably close to zero cost environment

If a customer will not give VSI a reason to work with them, ie; they are going
to be purchasing stuff, even if it's only service, (did I really write "only
service"?) then I doubt VSI will be working with them.

So yeah, if someone has a system just sitting there doing a job, and has no real
concept of "value" in VMS, that's all that will happen.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of IanD via Info-vax
> Sent: 17-Sep-16 9:06 AM
> To: info...@rbnsn.com
> Cc: IanD <iloveo...@gmail.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

I need to clarify what I stated by neutral.

HPE is still only going to sell HPE HW products, but they will
not be competing with CSC, BM and other SW vendors with their
services and/or software businesses.

[snip...]

>
> It will be interesting to see who snaps up non-stop. The
banking
> sector is slowly moving on from mainframes (commonwealth
> bank in Australia has gone to great lengths and I believe the
other
> banks here are also moving too)
>
> IBM perhaps?
>

Doubt it - NonStop is competition for mainframes. Also, the
installed base is not that large (lots smaller than OpenVMS btw).

More likely, if it did happen, it would be one of NonStops
integration partners.

> What will HPE actually stand for in the future then?
>

I fully expect HPE will be bought out and is the reason they are
slimming down so drastically.

>From $100B to $28B in approx. 18 months?

Imho, there is a deal cooking behind the scenes... perhaps Cisco
in order to ramp up against the new Dell/EMC?

Cisco does have USD $60B cash on hand.
http://www.siliconbeat.com/2016/05/20/apple-microsoft-google-cisc
o-oracle-hold-cash-moodys-report/

> IT is becoming more and more a commodity every day. It will
> eventually become like electricity, you flick the switch and
don't
> care who's supplying you the goods as long as it meets a set
> minimum standard that you require
>

I heard that same concern 30 years ago when concepts like the "IT
Utility" were being thrown around. What you have just described
is outsourcing and there is a reason why outsourcing has not
"taken over" like many industry pundits have predicted.

In the end, when you outsource your IT to a public cloud, you are
also giving up any control over security policy, data policy,
ability to prioritize issues and the ability to adopt new
technologies which might make your company more competitive. You
also give up flexibility to change things quickly.

In some of the larger companies, what is changing is that Mgmt
wants their senior IT staff to working more closely with the BU's
to help them understand what IT can do for them. For these
companies, trolling newsgroups or email distribution lists
looking for patches and/or other "in the weeds" issues to resolve
low level incidents is not considered a good use of a valuable
resources time.

:-)

[Hans Bachner]

Simon Clubley schrieb am 16.09.2016 um 22:45:
> [snip]

>
> BTW, who still uses DECnet Phase V ? (It's referenced in the first link).

I have several customer using DECnet Phase V for communication with shop
floor and warehouse equipment.

And a few for the sole reason to run DECnet over IP.

Hans.

[IanD]

In this day and age, waiting for a customer to front up at your door is what leads you to become dead and buried - this is why sales as a job has seen huge growth despite the economic landscape not really getting any better

If your not out there drumming up business and being in people's faces then you going to be quickly forgotten about

You also have the 'problem' that VSI don't seem to be doing a great deal of marketing or at least not the sort that gets you noticed beyond the whisperings of the already converted clan chatting in their usual haunts on the internet - such as this place for example

I've done my bit trying to let CIO's and the likes that the systems have have are on a platform with a future but it seems that unless that information comes via their sanctioned chain of IT information flow, then it's just ignored.

I can understand Vax being burried, too much baggage to carry forward but all those Alpha's out there, which exceed the Itanium group by orders of magnitude surely are fairly easy pickings?

There is the hardware issue to be sure (which the likes of Charon can address near term anyhow) but giving an upgrade path for the OS can't be overly difficult, not considering VSI have already knocked out an Alpha evaluation kit - but who would know it? The advertising is somewhat limited to fairly low key distribution outlets IMO

The only place I have read about the Alpha evaluation kit offering was here and I happen to see something on VSI's website. To my knowledge, the customer I support and us, as their IT supplier, never got an email or a cold-call or anything to say that there is a way forward for that old Alpha platform. The customer we work for is no small one either yet I don't believe they have ever been contacted by VSI as to OpenVMS offerings going forward

If your not selling your wares then don't expect customers to be signing up with you, not in this age of push advertising and BS mumbo jumbo technology spin being shoved at people

[clairg...@gmail.com]

RE: Alpha

Alpha is a very difficult issue for us. We have people coming to us looking for Alpha support
but the only way we can provide it at this time is for the customer to upgrade to a VSI release.
If you have been running on 7.3-2 for 10+ years do you really want to disturb that environment?

The Alpha Evaluation Kit (AEK) gave us a means to get some feedback on the OS itself, beyond
what we do ourselves. That was good. We provided no layered products with the AEK.

Our real motivation for considering Alpha releases is to provide a better path to get to x86; get
up to date first and it will be an easier move. However, we have always wondered if we can
provide the layered products needed by these older environments. Do we really want to support
some really ancient HW?

We are working with partners who have lists of thousands of Alpha systems. We are contacting
these users to see first, if they are interested in upgrading, and if they are, what do they need
for SW beyond the OS and what HW platforms are they on. We have a good idea of what we
can provide. The question is - can we provide the layered products to satisfy enough customers
to make this a worthwhile venture for us. We can’t just be spreading good will here since every
minute we spend on Alpha we are not spending on x86.

People seem to think that just because there are thousands of Alpha systems out there that they
should become VSI customers and make us lots of money. It’s not that obvious.

[David Froble]

clairg...@gmail.com wrote:
> RE: Alpha
>
> Alpha is a very difficult issue for us. We have people coming to us looking for Alpha support
> but the only way we can provide it at this time is for the customer to upgrade to a VSI release.
> If you have been running on 7.3-2 for 10+ years do you really want to disturb that environment?

You are entirely correct. If someone is running a static system, they do not
need support.

> The Alpha Evaluation Kit (AEK) gave us a means to get some feedback on the OS itself, beyond
> what we do ourselves. That was good. We provided no layered products with the AEK.

Thank you for that. I upgraded a disk that had V8.3. Things seem to just work.
The Basic compiler still works, I'm going to assume that other things will
work, I didn't do much testing.

On the other hand, trying to install HPE SSL1 didn't work, and when I asked, I
got the "company line" about not supporting Alpha. No problem, you got plenty
of stuff to work on.

> Our real motivation for considering Alpha releases is to provide a better path to get to x86; get
> up to date first and it will be an easier move. However, we have always wondered if we can
> provide the layered products needed by these older environments. Do we really want to support
> some really ancient HW?

While I cannot speak for everyone, and sometimes not even for myself, it's my
opinion that no, you don't. Alpha is not only dead, the last chips are
hopelessly outdated with respect to mfg process. While a better design, process
trumps design, and Alpha cannot compete in performance anymore.

Note, this comes from someone who still has a VAX running. But not in a
production environment. Actually, none of my systems run in a production
environment. I'm not what you'd consider a "customer", but more of a "partner",
developing software for those who do run production systems.

As for your thinking about a "better path to x86", I think it may be a waste of
effort. Your past movements from VAX to Alpha and Alpha to itanic have been
rather painless and straight forward, thank you very much for that. So it's my
thought that if a customer does have the capability to move to x86, which would
include some technical people with a clue and source code and such, the most
painless move would be to "just do it" when x86 is available.

> We are working with partners who have lists of thousands of Alpha systems. We are contacting
> these users to see first, if they are interested in upgrading, and if they are, what do they need
> for SW beyond the OS and what HW platforms are they on. We have a good idea of what we
> can provide. The question is - can we provide the layered products to satisfy enough customers
> to make this a worthwhile venture for us. We can’t just be spreading good will here since every
> minute we spend on Alpha we are not spending on x86.

Indeed!

> People seem to think that just because there are thousands of Alpha systems out there that they
> should become VSI customers and make us lots of money. It’s not that obvious.

No, it's not. Customers that would be good for VSI have most likely already
moved to itanic. Alpha users (and VAX users) are likely to be happy with what
they have. If it ain't broke, don't fix it. If it works, then work it.

Now, when those VAX and Alpha users are ready to upgrade their infrastructure,
their having a good opinion of VSI would be a good thing for VSI, and a point in
favor of once again selecting VMS.

[Bob Koehler]

In article <M7_Cz.673399$lr2.4...@fx16.ams1>, Dirk Munk <mu...@home.nl> writes:
> *If* you want to use DECnet, and you have an IP only network
> infrastructure (and that is very likely these days), you can *only* use
> DECnet Phase V, since it has an IP transport stack. OSI has been
> designed to use IP as well next to other OSI transport stacks.

Nonsense. I tunneled Phase IV through Multinet's IP stack many times.

[Phillip Helbig (undress to reply)]

In article <1bd0ceb5-2752-4bb4...@googlegroups.com>,

clairg...@gmail.com writes:

> Alpha is a very difficult issue for us. We have people coming to us looking
> for Alpha support
> but the only way we can provide it at this time is for the customer to
> upgrade to a VSI release.
> If you have been running on 7.3-2 for 10+ years do you really want to
> disturb that environment?

Some stayed at 7.3-2 since they thought that the writing was on the
wall. If they are still on Alpha, they might want to go to x86, which
presumably means via 8.4.

> People seem to think that just because there are thousands of Alpha systems
> out there that they
> should become VSI customers and make us lots of money.

I don't know how many Alpha customers there are compared to Itanium
customers, but both are potential x86 customers, since that is the only
future for VMS. It would be nice for the Alpha folks to skip Itanium
completely. Going from 7.3-2 to 8.4 isn't that big of a deal,
especially if there is no change in the software run.

[clairg...@gmail.com]

On Tuesday, September 20, 2016 at 4:08:38 PM UTC-4, Phillip Helbig (undress to reply) wrote:
> In article <1bd0ceb5-2752-4bb4...@googlegroups.com>,
> clairg...@gmail.com writes:
>
> > Alpha is a very difficult issue for us. We have people coming to us looking
> > for Alpha support
> > but the only way we can provide it at this time is for the customer to
> > upgrade to a VSI release.
> > If you have been running on 7.3-2 for 10+ years do you really want to
> > disturb that environment?
>
> Some stayed at 7.3-2 since they thought that the writing was on the
> wall. If they are still on Alpha, they might want to go to x86, which
> presumably means via 8.4.

Some might; we'll see. VMS on x86 will be 9.x

>
> > People seem to think that just because there are thousands of Alpha systems
> > out there that they
> > should become VSI customers and make us lots of money.
>
> I don't know how many Alpha customers there are compared to Itanium
> customers, but both are potential x86 customers, since that is the only
> future for VMS. It would be nice for the Alpha folks to skip Itanium
> completely. Going from 7.3-2 to 8.4 isn't that big of a deal,
> especially if there is no change in the software run.

Best estimates are that there are 3 times as many Alpha/VAX users as Itanium.

It is not the release of VMS that is the big deal, it is the moving of applications
to a new different architecture. You either recompile/relink or let a translator run
our Alpha image. That's a lot of disruption if you have been humming along for
many years.

[abrsvc]

> Best estimates are that there are 3 times as many Alpha/VAX users as Itanium.
>
> It is not the release of VMS that is the big deal, it is the moving of applications
> to a new different architecture. You either recompile/relink or let a translator run
> our Alpha image. That's a lot of disruption if you have been humming along for
> many years.

I would believe too that testing and validation time is a big factor. I have been involved with a number of client situations where the port would be trivial (mostly compile and go). However, due to government regulations, extensive testing must be done for compliance and validation. This time by far exceeds the "port" and involves many more people too. That translates to high costs. With the x86 target hardware being relatively close, I know of some that will wait for that before spending money on a port.

Dan

[Phillip Helbig (undress to reply)]

In article <1d446afc-d919-411b...@googlegroups.com>,

clairg...@gmail.com writes:

> > Some stayed at 7.3-2 since they thought that the writing was on the
> > wall. If they are still on Alpha, they might want to go to x86, which
> > presumably means via 8.4.
>

> Some might; we'll see. VMS on x86 will be 9.x

I remember someone saying (during the original conference call?) that
8.4 Alpha would be supported in a cluster with 9.x x86. Migration in a
mixed-architecture cluster is something many are familiar with
(VAX/Alpha, Alpha/Itanium) and gives one a chance for easy comparison
when testing things. Since the old architecture is there, there are no
show-stoppers.

I hope that it is still the plan to support this.

> It is not the release of VMS that is the big deal, it is the moving of
> applications to a new different architecture. You either
> recompile/relink or let a translator run our Alpha image. That's a lot
> of disruption if you have been humming along for many years.

Again, a mixed-architecture cluster is probably the best way.

[IanD]

On Monday, September 19, 2016 at 9:41:03 PM UTC+10, clairg...@gmail.com wrote:
> RE: Alpha
>
> Alpha is a very difficult issue for us. We have people coming to us looking for Alpha support
> but the only way we can provide it at this time is for the customer to upgrade to a VSI release.
> If you have been running on 7.3-2 for 10+ years do you really want to disturb that environment?
>

Those environments are throwing their money at like the likes of Stormasys and other emulators

What they want is to reduce their risk of their environments blowing up. At this stage of the game that would be aging hardware most of all

Beyond that, I suspect they would love a path forward

That is certainly the case where I am

If someone came along and said "For X $'s, we can move you forward", they would jump at the chance. The systems are being decommissioned to remove risk of failure not because they are tired of OpenVMS (yeah, we are on 7.3-2)

> The Alpha Evaluation Kit (AEK) gave us a means to get some feedback on the OS itself, beyond
> what we do ourselves. That was good. We provided no layered products with the AEK.
>
> Our real motivation for considering Alpha releases is to provide a better path to get to x86; get
> up to date first and it will be an easier move. However, we have always wondered if we can
> provide the layered products needed by these older environments. Do we really want to support
> some really ancient HW?
>

If we had a clear path onto x86 from Alpha 7.3-2, I suspect we would stay on OpenVMS going forward (but that includes the Application as well)

Alas, the decision was made some time ago to vacate OpenVMS before VSI clearly stating concrete intentions of forging an OpenVMS pathway to x86

I would say there's a number of shops out there wanting support on Alpha but more importantly, want someone to help them find a pathway onto Itanium and/or x86

> We are working with partners who have lists of thousands of Alpha systems. We are contacting
> these users to see first, if they are interested in upgrading, and if they are, what do they need
> for SW beyond the OS and what HW platforms are they on. We have a good idea of what we
> can provide. The question is - can we provide the layered products to satisfy enough customers
> to make this a worthwhile venture for us. We can’t just be spreading good will here since every
> minute we spend on Alpha we are not spending on x86.
>

Yeah, it's a balancing act and a difficult one, I don't envy your position at all

There must be core packages though that people are using more than others. I guess weighing up what to bring over and what to leave behind isn't always easy and it's not a 1:1 relationship either.

For those that are on arcane software constructs, they will either have to pay to bring that software across or pay to migrate elsewhere, finding a way to keep them on OpenVMS may be very difficult

> People seem to think that just because there are thousands of Alpha systems out there that they
> should become VSI customers and make us lots of money. It’s not that obvious.

I look at the porting efforts that will go into moving the platform I look after onto a linux based oracle offering. It's not going to be cheap at all. I'd guess in the millions actually by the time it's all done

VSI with all it's expertise would probably make easy work of getting things over to Itanium with the latest version of RDB. The Application side would be more work but it could be done. There's talk of source code issues but I've heard for the right money that's not a stumbling block.

The current folk doing the port know zero about OpenVMS and they are trying to move it all to linux.

If someone had said to the business 12 months ago, here's how we could move you off that old hardware and you could retain your existing application functionality because it's a port on the same OS / code base, I think they might have jumped at it.

The only winner in what's happening where I work will be Oracle and whomever does the development work and OpenVMS will vanish as a presence here probably forever :-(

There will be no future OpenVMS licensing agreements being renewed here and that is a crying shame, it's the loss of a presence that's going to hurt OpenVMS going forward

[David Froble]

So, prepare a short presentation, and submit it to the powers that be. You
could point out the "safety" in not losing the current working app. Costs would
need to be pointed out, including getting the sources, and building them first
on itanic, and later on x86. Not going to be cheap, but perhaps much cheaper
than a from scratch re-write. Once you got the sources, you would not face that
problem again, and you'd have future flexibility.

That re-write from scratch is going to have some problems, and may never reach
what you now have. It's a bottomless money pit.

Never know, might work, and if it doesn't how are you worse off than now?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of David Froble via Info-vax
> Sent: 22-Sep-16 11:24 PM
> To: info...@rbnsn.com
> Cc: David Froble <da...@tsoft-inc.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> IanD wrote:
> > On Monday, September 19, 2016 at 9:41:03 PM UTC+10,
> clairg...@gmail.com wrote:
> >> RE: Alpha
> >>
> >> Alpha is a very difficult issue for us. We have people coming to
> us
> >> looking for Alpha support but the only way we can provide it at
> this time is for the customer to upgrade to a VSI release.
> >> If you have been running on 7.3-2 for 10+ years do you really
> want to disturb that environment?
> >>

[snip..]

> >
> > The current folk doing the port know zero about OpenVMS and
> they are trying to move it all to linux.
> >

A huge part of the TCO is Oracle licensing costs which are double for Alpha/IA64 due to Oracles anti-competition tax called their Processor Core Factor which for Alpha/IA64 is 1.0. When charging $25-$50K per core, this is a huge factor (add 50% per core if using RAC).

The good news is that when OpenVMS X86-64/Oracle is available, the Processor Core factor will be 0.5 - same as Linux. Hence, OpenVMS on Alpha/IA64 customers should be able to cut their Oracle license costs by 50%.

Also remember that there is a potential to reduce OpenVMS license costs in a migration because Alpha is core (cpu) based licenses, while I2/I4 systems are socket based.

> > If someone had said to the business 12 months ago, here's how
> we could move you off that old hardware and you could retain
> your existing application functionality because it's a port on the
> same OS / code base, I think they might have jumped at it.
> >
> > The only winner in what's happening where I work will be
> Oracle and
> > whomever does the development work and OpenVMS will
> vanish as a
> > presence here probably forever :-(
> >
> > There will be no future OpenVMS licensing agreements being
> renewed
> > here and that is a crying shame, it's the loss of a presence that's
> > going to hurt OpenVMS going forward
>

The way I like to position these options as minimizing business risk with strategy options called "upgrade-n-integrate" vs. "rip-n-replace". The former is usually by far the lowest risk to the business while the latter usually is not only higher risk, but often orders of magnitude greater cost.

See note above about Oracle license costs 50% reduction on OpenVMS X86-64.

> So, prepare a short presentation, and submit it to the powers
> that be. You could point out the "safety" in not losing the current
> working app. Costs would need to be pointed out, including
> getting the sources, and building them first on itanic, and later on
> x86. Not going to be cheap, but perhaps much cheaper than a
> from scratch re-write. Once you got the sources, you would not
> face that problem again, and you'd have future flexibility.
>
> That re-write from scratch is going to have some problems, and
> may never reach what you now have. It's a bottomless money
> pit.
>

I know of one Cust that tried literally for 8 years to move a large complex mission critical OpenVMS environment to UNIX (HP-UX). HP was helping them all the way, but they just kept having issues. After numerous different attempts, the business folks essentially told the IT dept "enough!". Last I heard they now have a couple IA64 nodes in their 8 node OpenVMS A-A homogeneous Alpha ES45 cluster.

> Never know, might work, and if it doesn't how are you worse off
> than now?
>

Agree - the way to attack FUD from internal Linux groups is with discussions with senior management on lower business risk and lower costs. Fight fire with fire.

[Phillip Helbig (undress to reply)]

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

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

> A huge part of the TCO is Oracle licensing costs which are double for
> Alpha/IA64 due to Oracles anti-competition tax called their Processor
> Core Factor which for Alpha/IA64 is 1.0. When charging $25-$50K per
> core, this is a huge factor (add 50% per core if using RAC).

Right; it is expensive.

> The good news is that when OpenVMS X86-64/Oracle is available, the
> Processor Core factor will be 0.5 - same as Linux. Hence, OpenVMS on
> Alpha/IA64 customers should be able to cut their Oracle license costs by
> 50%.

Assuming that Oracle doesn't change their pricing model.

> Also remember that there is a potential to reduce OpenVMS license costs
> in a migration because Alpha is core (cpu) based licenses, while I2/I4
> systems are socket based.

Assuming that VSI doesn't change their pricing model.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Phillip Helbig undress to reply via Info-vax
> Sent: 23-Sep-16 2:27 AM
> To: info...@rbnsn.com
> Cc: Phillip Helbig undress to reply
> <hel...@asclothestro.multivax.de>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> In article <mailman.11.1474603640.24380.info-
> vax_rb...@rbnsn.com>,

> "Kerry Main" <kemain...@gmail.com> writes:
>
> > A huge part of the TCO is Oracle licensing costs which are
> double for
> > Alpha/IA64 due to Oracles anti-competition tax called their
> Processor
> > Core Factor which for Alpha/IA64 is 1.0. When charging $25-
> $50K per
> > core, this is a huge factor (add 50% per core if using RAC).
>
> Right; it is expensive.
>

I would add ridiculously expensive.

> > The good news is that when OpenVMS X86-64/Oracle is
> available, the
> > Processor Core factor will be 0.5 - same as Linux. Hence,
> OpenVMS on
> > Alpha/IA64 customers should be able to cut their Oracle
license
> costs
> > by 50%.
>
> Assuming that Oracle doesn't change their pricing model.
>

The past and current Oracle pricing model is based on the server
HW platform - not the OS, so I highly doubt that will change
anytime soon.

> > Also remember that there is a potential to reduce OpenVMS
> license
> > costs in a migration because Alpha is core (cpu) based
licenses,
> while
> > I2/I4 systems are socket based.
>
> Assuming that VSI doesn't change their pricing model.
>

The previous statement about potential savings on core/cpu on
Alpha vs socket on I2/I4 is 100% true today.

Moving from a 16 or 32 cpu Alpha to a 2 or 4 socket I4 server
could potentially have large savings on its own. On top of this,
when one looks at the exponentially increasing HW maint costs
associated with most Alpha systems today, the picture becomes
even better.

Note - There is a cost of delay (often called the price of doing
nothing) when one looks at IT cost and expense models.

Pure speculation, but in order to address its primary big
competitor on X86-64 (Linux -> Windows is taking the DEC race to
bottom) I am also hopeful that the pricing model will improve
even more with OpenVMS X86-64.

[IanD]

On Friday, September 23, 2016 at 2:10:06 PM UTC+10, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> > Of David Froble via Info-vax
> > Sent: 22-Sep-16 11:24 PM
> > To: info...@rbnsn.com
> > Cc: David Froble <da...@tsoft-inc.com>
> > Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> > Marketing Brochures
> >
> > IanD wrote:
> > > On Monday, September 19, 2016 at 9:41:03 PM UTC+10,
> > clairg...@gmail.com wrote:
> > >> RE: Alpha
> > >>
> > >> Alpha is a very difficult issue for us. We have people coming to
> > us
> > >> looking for Alpha support but the only way we can provide it at
> > this time is for the customer to upgrade to a VSI release.
> > >> If you have been running on 7.3-2 for 10+ years do you really
> > want to disturb that environment?
> > >>
>
> [snip..]
>
> > >
> > > The current folk doing the port know zero about OpenVMS and
> > they are trying to move it all to linux.
> > >
>
> A huge part of the TCO is Oracle licensing costs which are double for Alpha/IA64 due to Oracles anti-competition tax called their Processor Core Factor which for Alpha/IA64 is 1.0. When charging $25-$50K per core, this is a huge factor (add 50% per core if using RAC).
>

Ouch, I had no idea it so so expensive

> The good news is that when OpenVMS X86-64/Oracle is available, the Processor Core factor will be 0.5 - same as Linux. Hence, OpenVMS on Alpha/IA64 customers should be able to cut their Oracle license costs by 50%.
>

So Oracle have committed to x86 on OpenvMS?

I was under the impression they were fence sitting waiting to see if VSI was sustainable longer term?

> Also remember that there is a potential to reduce OpenVMS license costs in a migration because Alpha is core (cpu) based licenses, while I2/I4 systems are socket based.
>

That's so interesting. I'm so out of touch with licencing stuff having been looking after an environment that's out of support for so long

> > > If someone had said to the business 12 months ago, here's how
> > we could move you off that old hardware and you could retain
> > your existing application functionality because it's a port on the
> > same OS / code base, I think they might have jumped at it.
> > >
> > > The only winner in what's happening where I work will be
> > Oracle and
> > > whomever does the development work and OpenVMS will
> > vanish as a
> > > presence here probably forever :-(
> > >
> > > There will be no future OpenVMS licensing agreements being
> > renewed
> > > here and that is a crying shame, it's the loss of a presence that's
> > > going to hurt OpenVMS going forward
> >
>
> The way I like to position these options as minimizing business risk with strategy options called "upgrade-n-integrate" vs. "rip-n-replace". The former is usually by far the lowest risk to the business while the latter usually is not only higher risk, but often orders of magnitude greater cost.
>

Funny, I put together a document showing what they could do today. I created a simple html form that used the web server (WASD) to grab data out of RDB and display it to the screen - sure I'm simple but it showed them this is functionality available today - the Application people have been telling the business it's an old system and nothing more can be done as it's terminal based only (Lies, Dam lies, Incompetence...)

I titled one chapter "Parallel Enhance OR Risky Big Replace" ha ha ha, similar to what you are saying :-)

> See note above about Oracle license costs 50% reduction on OpenVMS X86-64.
>
> > So, prepare a short presentation, and submit it to the powers
> > that be. You could point out the "safety" in not losing the current
> > working app. Costs would need to be pointed out, including
> > getting the sources, and building them first on itanic, and later on
> > x86. Not going to be cheap, but perhaps much cheaper than a
> > from scratch re-write. Once you got the sources, you would not
> > face that problem again, and you'd have future flexibility.
> >
> > That re-write from scratch is going to have some problems, and
> > may never reach what you now have. It's a bottomless money
> > pit.
> >

They are already facing issues just getting the data over the Oracle. There some nasty data that is apparently in encrypted form in the DB and when I went looking, it's a function call to an external EXE which has no source code. Let's hope the encryption isn't anything complex. I'll have a go at brute-forcing the data trying the usual tricks that people did all those years ago like some simple bit-wise operators otherwise they are looking at getting some people in who know deciphering better than little old amateur me.

It's an interest activity for me, I'm not actually part of the DB migration activities

>
> I know of one Cust that tried literally for 8 years to move a large complex mission critical OpenVMS environment to UNIX (HP-UX). HP was helping them all the way, but they just kept having issues. After numerous different attempts, the business folks essentially told the IT dept "enough!". Last I heard they now have a couple IA64 nodes in their 8 node OpenVMS A-A homogeneous Alpha ES45 cluster.
>

Sense prevailed!

I wish people here had the same smarts...

Our customer has been fed a stream of BS over the years and they think linux is their savior and will have them skipping off into IT heaven *sigh*

> > Never know, might work, and if it doesn't how are you worse off
> > than now?
> >
>
> Agree - the way to attack FUD from internal Linux groups is with discussions with senior management on lower business risk and lower costs. Fight fire with fire.
>

I was fortunate that recently a senior manager from the business emailed a whole swag of people and I was on the list. I took the opportunity to email him directly my report and added a few pointy comments about how VSI had now taken over the reigns and that VMS had a strong future (It is also in my report actually as well about VSI but I wanted to make a point that the platform has a future)

I have not heard anything but at least I know he has directly got my report and that it didn't get filtered to the 'round file' as I suspect it might have done before when it flowed through other hands

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

I really like your posts, especially when you tell of how you approach delivery of key information - it helps me with sharpening my own delivery :-)

[Stephen Hoffman]

On 2016-09-23 23:30:49 +0000, IanD said:

> Ouch, I had no idea it so so expensive

Last I checked, a clustering license was ~$25K each, for some low-end
Alpha systems.

A decade ago, I priced out low-end servers for use here. Then-HP was
over US$20K for their low-end OpenVMS I64 and Itanium server
configuration — that's without clustering, Oracle and most of the other
software and licenses — versus US$1K for an entire low-end server with
hardware, software, and three years software and hardware support. I
very nearly purchased the whole package for the cost of the OpenVMS
license. That server was also vastly easier to install and maintain,
and I have some familiarity with OpenVMS server management. And with
SQLite and PostgreSQL and other tools, relational databases are
available.

Prices on competing servers and software have dropped, too. Ignoring
Centos and other free options, one's offering has gone from US$1K to
~$20. Oracle has more than a little competition for databases, too.

> So Oracle have committed to x86 on OpenvMS?
>
> I was under the impression they were fence sitting waiting to see if
> VSI was sustainable longer term?

Oracle will likely want access to the port before they decide, and
they'll likely also want VSI to fund the Oracle port, and they'll
probably want to turn a profit from that effort. That's certainly what
the managers of most businesses would ask for, if they were in Oracle's
position in these or other negotiations. Why should Oracle take on the
risk?

> Funny, I put together a document showing what they could do today. I
> created a simple html form that used the web server (WASD) to grab data
> out of RDB and display it to the screen - sure I'm simple but it showed
> them this is functionality available today - the Application people
> have been telling the business it's an old system and nothing more can
> be done as it's terminal based only (Lies, Dam lies, Incompetence...)

Maybe the applications don't lend themselves to that transition,
though. Getting data out of a database is easy. Getting the
business logic extracted from the usual morass of code is no small
project, and retrofitting a different front-end can verge on a large
code refactor if not a (preferably rolling) application rewrite.

> They are already facing issues just getting the data over the Oracle.
> There some nasty data that is apparently in encrypted form in the DB
> and when I went looking, it's a function call to an external EXE which
> has no source code. Let's hope the encryption isn't anything complex.
> I'll have a go at brute-forcing the data trying the usual tricks that
> people did all those years ago like some simple bit-wise operators
> otherwise they are looking at getting some people in who know
> deciphering better than little old amateur me.
> It's an interest activity for me, I'm not actually part of the DB
> migration activities

If the crypto isn't stupid-grade and if it isn't some common algo, and
assuming the licenses permit it, it'd probably be easier to
reverse-engineer the executables and figure out what they're doing.
Very few OpenVMS applications have been written with anti-reversing.

> Our customer has been fed a stream of BS over the years and they think
> linux is their savior and will have them skipping off into IT heaven
> *sigh*

Hopefully VSI knocks most of the worst of the rust off the platform
over the next five or ten years, but staying competitive never ends and
the competitors are also always moving forward.

Every business is eventually encounters cases where they can deliver
what the customer asks for, what the customer really wants or needs, or
where they can avoid even entering into a deal or can end future
dealing with a customer. I also know of many former OpenVMS customers
now running RHEL, too. More are moving. It may or may not be IT
heaven, but it works for them, and that's all that really matters.



--
Pure Personal Opinion | HoffmanLabs LLC

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 24-Sep-16 9:20 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> On 2016-09-23 23:30:49 +0000, IanD said:
>
> > Ouch, I had no idea it so so expensive
>
> Last I checked, a clustering license was ~$25K each, for some low-
> end Alpha systems.
>

Those seem like decades old pricing for OpenVMS clustering based on the old per core scheme, (not the socket based with I2/I4), but let's put things in perspective:

Microsoft Linux environment running Oracle RAC on a small 2 node ProLiant X86-64 with 4 cores on each server

Oracle pricing - 8 cores x 50K (list) + 50% for RAC
Sub-Total = $600,000 x 0.5 (oracle processor core factor for X86)
Total = $300,000 initial Oracle license + Annual Support costs of approx. 15% ($45K/year)

Now you can see why the OpenVMS X86-64 PCF is such a big licensing factor in the Oracle World

-

Rather than speculate, here is the remaining 2016 dates Oracle Rdb and Oracle DB forum schedule that is free:
http://bit.ly/2dpvNqo

In addition, Oracle is attending the OpenVMS Boot Camp next week to provide an update on both databases as well.

[snip]

[Stephen Hoffman]

On 2016-09-24 16:17:22 +0000, Kerry Main said:

> Those seem like decades old pricing for OpenVMS clustering based on the
> old per core scheme, (not the socket based with I2/I4), but let's put
> things in perspective:

I was quoted those prices about a year ago, working on an Alpha
configuration the customer couldn't upgrade. Watched several eyebrows
take tours of foreheads in that meeting, too.

> Now you can see why the OpenVMS X86-64 PCF is such a big licensing
> factor in the Oracle World

I don't doubt it's a factor, particularly for folks tied to those databases.

It's also why an increasing number of folks are using Centos and other
platforms, and using PostgreSQL and SQLite and other tools.

Unlike OpenVMS, Oracle does have a low-end offering with their MySQL
acquisition, though more than a few folks are choosing MariaDB,
PostgreSQL, SQLite or such...

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 24-Sep-16 1:28 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> On 2016-09-24 16:17:22 +0000, Kerry Main said:
>
> > Those seem like decades old pricing for OpenVMS clustering
> based on
> > the old per core scheme, (not the socket based with I2/I4),
but
> let's
> > put things in perspective:
>
> I was quoted those prices about a year ago, working on an Alpha
> configuration the customer couldn't upgrade. Watched several
> eyebrows take tours of foreheads in that meeting, too.
>

I don't disagree the current licensing scheme for OpenVMS
(especially cluster pricing) will need to change to be much more
competitive on the X86-64 platform.

Fwiw, I believe the big competition on X86-64 will be Linux, so
some sort of monthly support subscription model will need to be
available as an option. MS is following the DEC race to the
bottom strategy with its spiraling costs and ignoring Cust pain.

Having stated this, given your scenario, and not knowing the
cluster price per core, one would need to know the number of cpus
involved. If it was a 32 cpu Alpha, then the cluster license of
$20k you quoted would be about $650 per cpu. If a 16 cpu system,
then something like $1,200 per cpu.

Per cpu vs. per socket makes a big difference, not just on the
base license, but also for other licenses like clustering.
Especially as the number of cores per socket increases.

MS has gone completely backwards by adopting per core pricing
like Oracle on its server products

> > Now you can see why the OpenVMS X86-64 PCF is such a big
> licensing
> > factor in the Oracle World
>
> I don't doubt it's a factor, particularly for folks tied to
those
> databases.
>
> It's also why an increasing number of folks are using Centos
and
> other platforms, and using PostgreSQL and SQLite and other
> tools.
>
> Unlike OpenVMS, Oracle does have a low-end offering with their
> MySQL acquisition, though more than a few folks are choosing
> MariaDB, PostgreSQL, SQLite or such...
>

I agree. The big vendors like Oracle, SAP, IBM are in for some
tough times in the next few years. While Cust's may not leave
their current App platforms, they will look at other options for
new applications as a means to reduce SW costs.

Issue I have is that most of the MariaDB, SQLite etc options only
support the UNIX/Windows shared nothing cluster model.

To be truly effective in an OpenVMS environment, and with really
big TB local non-volatile memory coming next year, the DB needs
to support active-active clustering.

Btw - for those at the OpenVMS boot camp next week, I highly
(highly!) recommend attending Wolfgang Burgers database
presentation on SharkDB.

;-)

[David Froble]

Stephen Hoffman wrote:
> On 2016-09-24 16:17:22 +0000, Kerry Main said:
>
>> Those seem like decades old pricing for OpenVMS clustering based on
>> the old per core scheme, (not the socket based with I2/I4), but let's
>> put things in perspective:
>
> I was quoted those prices about a year ago, working on an Alpha
> configuration the customer couldn't upgrade. Watched several eyebrows
> take tours of foreheads in that meeting, too.

It seems that HP never followed suit for Alpha when they set itanic prices.

I am not real sure, and it's been a while, but the last thing I remembered for
itanic was maybe $5000/system for VMS cluster.

So, why so high for Alpha, and less for itanic? Real simple, HP was selling
itanics, and anything to get someone with an Alpha to buy one was their goal.

Is kind of tough on someone who cannot easily get off Alpha, but, what does HP
care, they sell an itanic, or they don't sell an itanic. That's all they care
about.

>> Now you can see why the OpenVMS X86-64 PCF is such a big licensing
>> factor in the Oracle World

Maybe only for those who cannot get off Oracle ....

[IanD]

On Saturday, September 17, 2016 at 6:20:04 AM UTC+10, Kerry Main wrote:
> Fyi .. updated OpenVMS V8.4-2L1 brochures on the HPE web site
>
> VSI OpenVMS V8.4-2L1 Operating Environments:
> http://h20195.www2.hpe.com/v2/GetPDF.aspx/4AA6-4476ENW.pdf
>
> Exceed Business Expectations: VSI OpenVMS V8.4-2L1
> https://www.hpe.com/h20195/v2/GetDocument.aspx?docname=4AA6-5039E
> NW
>
>

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

I am very excited to say that we will be going to this shiny new version :-)

Yes, I have managed to escape my last dungeon to a better world (at least for now)

I'm not at liberty to say where at this stage but we will be installing some nice new shiny i4's and the this nice new VSI release

I'll be updating my knowledge from 7.3-2 to 8.4+ as well as getting familiar with Itanium hardware and some of the newer aspects to the tcpip stack - so I'll apologize now in advance for all the stupid questions I'm certainly going to be asking going forward

I fell like a kid in a candy shop and so relieved to have been able to move on from that tomb of an outfit I escaped from :-)

[Jan-Erik Soderholm]

Congratulations! :-) Nice to see some positive posts from you.

I'd guess that many will be interested in your progress reports. :-)

[David Froble]

However, you failed to enlighten that tomb before you escaped ....

:-)

[IanD]

Thanks for the congratulations

I hope I haven't been too negative 😎.

Maybe it's because I have worked in IT outsourcing for the past 22+ years and see the acceleration of how fast older systems, such as VMS based ones are being retired. I see literally 100 systems transformed every week to a cloud / visualised platform and a number of those are also being earmarked for straight out porting to Linux

I've also been stuck on 7.3-2 and alpha with no means of escape either, much like the prisoner who's resigned to his fate that the bars are stronger then themselves

I was also sort of hoping that vsi might have found a way to easily bring all those alpha systems out there across to the newer and better world but that was a naive fantasy on my behalf

I'm not pretending my new world is going to magically create utopia. They are upgrading to get the speed advantage of the i4's, not because the platform is going to enable them to take them where they want to be in the next 5 years. Going to the latest version just makes sense but it not because the OS has anything magical to offer apart from accessing faster hardware

I'm still 'negative' (although I think it's more realistic) as to what's facing VMS in the near future. X86 is one thing, security another, but right behind that is development and I don't mean faster builds, I'm meaning getting those universities and young minds interested in developing on OpenVMS, because it's not going to grow much without the next base of minds to drag it forward. I have friends in achedemic circles and it's no longer about tinkering with code, it's about having the tools to build newer and better items and for that ideal you need a platform that easily and readily can pull open source code and run with it easily. University projects are not much about develop this tool or that tool anymore, that stopped years ago, there's enough tools to do just about any job now. It's all about bundling items to enable higher order functionality and develop frameworks and platforms that the education sector is teaching the next round of people to perform.
OpenVMS has got a fair way to go to be able to work in that space.

OpenVMS is still closed in its core, I think it's going to be a hard slog trying to get the next round of young minds interested in the platform. Maybe if VSI pitched it as Please help us transform VMS to an open source offering then you may attract people on a philosophical reasoning but to transform OpenVMS to open source itself or at least to a point where open sourcing sees OpenVMS as a desirable target for the greater world of developers beyond OpenVMS zealots, is years in the making.

Why would they come anyhow? They already have Linux. What can we do to motivate people to come over to OpenVMS?

So yes, I'm excited about escaping the dead end system I was looking after although it had lots of potential still and I did find it hard to just give up and walk away but I'm also realistic that the new system where I've gone might not be around for ever and a day anyhow, there are some aspects to it that are really limiting it's growth that will be extremely costly to correct

At least in getting itanium experience and 8.4 exposure, which I'm extremely excited about 🙆

[IanD]

As to the tomb from wence I made my escape...

The system was an order provisioning system, developed using corba. Pretty impressive for its time and the fact that it runs today and had even had 4G mobile aspects configured within it at the application level speaks volumes of the great minds who developed it in the first place to enable to to be future configured even though the code base has not been touched in more than 10-15 years.
This is a telco system that is customer interfacing too and unless people have been living under a rock, telecommunications has seen enormous changes in the past 10 years. I don't see SAP and the likes running on a decade old code base...

The company I escaped from was an Indian IT outsourcing company and one that is growing rapidly, especially in europe etc

Let's just say my experience there was interesting. Having come from EDS/HP for shy of 20 years to an Indian based company was not an experience I ever wish to repeat

Management styles are a world, no, a universe apart. Concepts like autonomy, empowerment etc are all foreign concepts really. Everything is really driven from India. Management styles I would say are at a mid 80's timeframe and the whole middle management layer are really struggling moving beyond a top down command and control style. I'm getting shivers up my spine thinking about it.

They do however promote learning, although the quality level of learning is rather low but it features heavily their ethos. The very top level management is really forward focused and heavily western educated and are pushing things at a faster pace than I ever saw in HP, but the inertia of the middle level is just grinding everything to a halt and it's also impeded greatly because they are so lean that they are over focused on cost to the point we're they do stupid things like let people use old equipment that's well past its productive life but because it still works and isn't broken, then it isn't replaced, so you have a workforce using tools that get slower and less productive over time with no policy to speed up that productivity on the hardware side

They also come from a model that's people number rich. Want to get something done faster, throw more people at the problem. Western based tends to say, what can we do smarter with the same resources. Having said this, India's IT sector is tightening, it's not as lucrative anyhow for job opportunities, consequently, they are investing big dollars in machine learning, automation and pushing very hard towards systems that not just report on errors or even fix then when they arise but head them off proactivly. I didn't see anything in HP when I was there that rivaled what these people are trying to achieve, but it's been a while since I was in HP, who knows what they have been withing in since I left

The saying "People leave management not organisations" is never truer than in my case...

[clairg...@gmail.com]

On Friday, September 30, 2016 at 6:22:30 PM UTC-4, IanD wrote:
> I was also sort of hoping that vsi might have found a way to easily bring all those alpha systems out there across to the newer and better world but that was a naive fantasy on my behalf

We announced at Boot Camp this week that we will doing an 8.4-2L1 release for Alpha. We will get more information out as soon as we have completed the detailed planning.

> OpenVMS is still closed in its core, I think it's going to be a hard slog trying to get the next round of young minds interested in the platform. Maybe if VSI pitched it as Please help us transform VMS to an open source offering then you may attract people on a philosophical reasoning but to transform OpenVMS to open source itself or at least to a point where open sourcing sees OpenVMS as a desirable target for the greater world of developers beyond OpenVMS zealots, is years in the making.
>

The VSI/HPE agreement does not allow us to make VMS open source.

[IanD]

On Saturday, October 1, 2016 at 8:41:42 PM UTC+10, clairg...@gmail.com wrote:

<snip>

>
> We announced at Boot Camp this week that we will doing an 8.4-2L1 release for Alpha. We will get more information out as soon as we have completed the detailed planning.
>

That's amazing and quite a feat actually!

I was also meaning having a service where people can call / engage and get an assessment of what is needed to move people forward and get some help in doing so. The brilliant minds at VSI would be able to give people insights into how they can move their platforms forward (a lot would have no idea of even where to start)

I would say a lot of places out there are running in linux / windows shops with a side system of OpenVMS and the people looking after VMS have little or not enough experience to drag the platform forward

That would take a rather large engagement on behalf of VSI of course and it's probably better to focus on getting that x86 port done and the come back to helping people move beyond Alpha? You cannot do everything and your already dealing with years of little movement of movement in VMS

<snip>

> >
>
> The VSI/HPE agreement does not allow us to make VMS open source.

Yes, I believe it has been mentioned before but what happens when you enhance code?
The enhanced code must belong to VSI ? or is it any derived work based off the bade code still under HPE ownership? (I'm not expecting an actual answer as I imagine this would be commercial in confidence but it would be interesting to know)

If HPE would allow the base code to be rewritten and thereby ownership transferred, this would open things a lot and the open source aspect could be further levered

I'm not just saying 'open source' because I think it's the best thing. I advocate open source mainly because it's the current model that is attracting all the new minds to the point where most people coming out of uni now will refuse to touch anything that is not open source - such has been the brainwashing of the young! Microsoft has all but caved in to this as well and have done an about face

I advocate open source because I happen to think it's another way to remove the stumbling blocks that OpenVMS is already facing and it doesn't need more stumbling blocks, it needs to make itself as attractive as possible

I understand that VSI have probably negotiated the best deal they could with HPE at the time, my probing and being the antagonist is not meant to be negative about the whole thing but more to put my hat into the ring as to where/what I think would help OpenVMS going forward. I know people in academic circles and linux is still king because of open source and the education sector is driving the minds of the future coders. I just want to find a way to attract them to OpenVMS if at all possible

I appreciate you telling us the details too as long as you know I'm not actually grumbling at yourself or VSI at large, for that matter. I'm just trying to find a way to put OpenVMS's best foot forward in a world that has all but ignored it for far too long

[Jan-Erik Soderholm]

Den 2016-10-01 kl. 13:34, skrev IanD:
> On Saturday, October 1, 2016 at 8:41:42 PM UTC+10, clairg...@gmail.com
> wrote:
>
> <snip>
>
>>
>> We announced at Boot Camp this week that we will doing an 8.4-2L1
>> release for Alpha. We will get more information out as soon as we have
>> completed the detailed planning.
>>
>
> That's amazing and quite a feat actually!
>
> I was also meaning having a service where people can call / engage and
> get an assessment of what is needed to move people forward and get some
> help in doing so. The brilliant minds at VSI would be able to give
> people insights into how they can move their platforms forward (a lot
> would have no idea of even where to start)
>

The short term goal is probably to come out with an own build of
VMS for Alpha to be able to sign support contracts. It was someone
from VSI that a couple of weeks ago said thet there were 3 times the
number of Alpha systems still in production than IA64 systems.

So the Alpha market (and future direct Alpha -> x86 migrations) might
be more important than VSI originaly thought (?).

I'd be happy to advice my customer to transfer the VMS support
contracts to VSI, if that helps with founding the x86 port and
general future of VMS.

But first, I'd like to see what was actually said at the Boot Camp...

Jan-Erik.

[David Froble]

IanD wrote:
> On Saturday, October 1, 2016 at 8:41:42 PM UTC+10, clairg...@gmail.com wrote:
>
>
> <snip>
>
>> We announced at Boot Camp this week that we will doing an 8.4-2L1 release
>> for Alpha. We will get more information out as soon as we have completed
>> the detailed planning.
>>
>
> That's amazing and quite a feat actually!

It will allow easier movement to x86.

> I was also meaning having a service where people can call / engage and get an
> assessment of what is needed to move people forward and get some help in
> doing so. The brilliant minds at VSI would be able to give people insights
> into how they can move their platforms forward (a lot would have no idea of
> even where to start)

Usually the installation manual.

> I would say a lot of places out there are running in linux / windows shops
> with a side system of OpenVMS and the people looking after VMS have little or
> not enough experience to drag the platform forward

Oh, you mean they are unable to read? Or perhaps "inclination" is a better term
than "experience"?

You keep harping on "open source". My opinion is that it is a non-issue. It
would not make any difference. You think those "students" are driving *ix
development? I suggest that it is the "PAID" employees at RedHat, IBM, and such
that are doing so. You know, just like the paid employees at VSI.

Nobody coming out of college is ready to do any job. They don't have the real
world experience. Some may not like that idea, but it's been my reality for
many years. What education teaches one is "how to learn", which can then be
applied when exposed to real world problems. If they are any good, learning to
work with VMS will be just as easy (or more so) as any other environment.

Now, if some of them think they "know it all" and are going to remake the world
to their image of how things should be, you keep them, I got no use for snot
nosed kids who think they know more than those who have been doing a job for
years. Too much effort to beat some sense into them.

I'll just ask, other than the concept that there is something special about open
source, just what real world benefits can you imagine there might be?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of IanD via Info-vax
> Sent: 01-Oct-16 7:34 AM
> To: info...@rbnsn.com
> Cc: IanD <iloveo...@gmail.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

It's been discussed a thousand times before, but imho, open
source is a terrible strategy for OpenVMS.

> I understand that VSI have probably negotiated the best deal
> they could with HPE at the time, my probing and being the
> antagonist is not meant to be negative about the whole thing
but
> more to put my hat into the ring as to where/what I think would
> help OpenVMS going forward. I know people in academic circles
> and linux is still king because of open source and the
education
> sector is driving the minds of the future coders. I just want
to find
> a way to attract them to OpenVMS if at all possible
>

I would argue that the one of the big interests at the enterprise
level in Linux is its perceived "free" cost. There is more than
one business case that has been pushed which compares license
costs to Linux (free) vs. its competition (expensive up front
licenses).

I say "perceived" free cost because while there are no up-front
license fees (CAPEX costs that need VP approvals), few med-large
customers adopt Linux without a monthly support contract (OPEX
which the OPS manager can approve as a single line item in his
budget with no visibility) from someone like RH. And these are
not that cheap when you look at all the monthly per VM costs in
an organization.

I prefer a model which is sometimes referred to as "right
sourcing".

This model is based on one org (VSI) holding the overall
responsibility for the core section of code while at the same
allowing strategic partners with close relationships to the
primary vendor to contribute added value code (including open
source) as part of the overall distribution model.

VSI already has their developer program - perhaps this just needs
to be enhanced along with a enhanced distribution model?

Hopefully, the licensing model for the V9+ releases will adapt to
something similar to the Linux model. Financially, much reduced
up front licenses with a monthly support model would potentially
be a big reason to get off IA64/Alpha/VAX and transform to
monthly cash flows into VSI. And by the way - most Customers do
not pay monthly for monthly support contracts. They pay either
annually in one up-front payment for the next 1/2/3 years.

> I appreciate you telling us the details too as long as you know
I'm
> not actually grumbling at yourself or VSI at large, for that
matter.
> I'm just trying to find a way to put OpenVMS's best foot
forward
> in a world that has all but ignored it for far too long
>

>From informal feedback I have heard, it sounds like a great week
was had at the Boot Camp with lots of stuff happening!

:-)

[Stephen Hoffman]

On 2016-10-01 13:25:57 +0000, David Froble said:

> IanD wrote:
>> On Saturday, October 1, 2016 at 8:41:42 PM UTC+10, clairg...@gmail.com wrote:
>>
>>
>> <snip>
>>
>>> We announced at Boot Camp this week that we will doing an 8.4-2L1
>>> release for Alpha. We will get more information out as soon as we have
>>> completed the detailed planning.
>>
>> That's amazing and quite a feat actually!
>
> It will allow easier movement to x86.

It'll allow VSI to issue compatibility kits. How they keep folks from
just staying on V8.4-2L1 is another discussion.

>
>> I was also meaning having a service where people can call / engage and
>> get an assessment of what is needed to move people forward and get some
>> help in doing so. The brilliant minds at VSI would be able to give
>> people insights into how they can move their platforms forward (a lot
>> would have no idea of even where to start)
>
> Usually the installation manual.

Having done these discussions with more than a few sites, it's a whole
lot more than reading the installation manual. That's the start, then
there's using the new versions effectively, troubleshooting problems,
rolling in hardware to replace disks that are failing, upgrading
databases for the newer versions, occasionally rebuilding bits and
pieces, and then the longer-term goal here and larger part of the
effort involved with getting off of Alpha. We're not in the same
world OpenVMS once was, and more than a few sites don't have
OpenVMS-experienced IT staff available.

>> I would say a lot of places out there are running in linux / windows
>> shops with a side system of OpenVMS and the people looking after VMS
>> have little or not enough experience to drag the platform forward
>
> Oh, you mean they are unable to read? Or perhaps "inclination" is a
> better term than "experience"?

Ayup. Pick your phrasing... Little inclination, insufficient
experience, lacking the time and money required, better things to do,
easier to do the work on another platform, etc...

>> ...I advocate open source because I happen to think it's another way to

>> remove the stumbling blocks that OpenVMS is already facing and it
>> doesn't need more stumbling blocks, it needs to make itself as

>> attractive as possible....

>
> You keep harping on "open source". My opinion is that it is a
> non-issue. It would not make any difference. You think those
> "students" are driving *ix development? I suggest that it is the
> "PAID" employees at RedHat, IBM, and such that are doing so. You know,
> just like the paid employees at VSI.

There are a lot more folks — a lot more — getting paid to work on Linux, too.

As for the open source, that is the core of most platforms and it means
folks don't need to learn new platforms and new tools. WASD is great,
but the two most common web services platforms around are nginx and
Apache.

> Nobody coming out of college is ready to do any job. They don't have
> the real world experience. Some may not like that idea, but it's been
> my reality for many years. What education teaches one is "how to
> learn", which can then be applied when exposed to real world problems.
> If they are any good, learning to work with VMS will be just as easy
> (or more so) as any other environment.

True. But then I find OpenVMS much more difficult to configure, manage
and use. This given I know well how to do all of those things and how
to troubleshoot the issues that arise. This when compared with these
same tasks on some of the other available platforms and tools.

> Now, if some of them think they "know it all" and are going to remake
> the world to their image of how things should be, you keep them, I got
> no use for snot nosed kids who think they know more than those who have
> been doing a job for years. Too much effort to beat some sense into
> them.

I've learned that various of the more experienced and "know it all"
folks can be a serious problem too, as they sometimes can't or don't or
won't invest the time and effort to keep up with what's possible and
with what's already available. Sometimes the old ways are the best
ways. Sometimes the old ways are Windows XP, or using knowledge and
experience gleaned from RH6 and which is no longer applicable, and with
all the associated problems the old ways can engender. In other
cases, repeating the old ways are a waste of time and effort.
Sometimes the more experienced folks can learn a whole lot from the
kids, if folks are willing to listen to them. Then there's the
enthusiasm, something that's been sorely lacking in more than a OpenVMS
shops. But I digress....

> I'll just ask, other than the concept that there is something special
> about open source, just what real world benefits can you imagine there
> might be?

Asking a question is a very good start to learning. Apache and nginx
are available, common and with active development, known configuration
syntax and other benefits. As good as WASD is and as well-integrated
as it is, it's yet another thing that folks would have to learn, if
WASD were to be the web server integrated into OpenVMS. Postfix and
other common packages are similarly known. ISC BIND is already part
of OpenVMS, albeit not particularly integrated and a very old version.
And yes, there are platforms that put very effective GUIs in front
of Apache, Postfix, BIND and other tools.

Everybody has to train new staff to local practices, of course. If
there aren't younger folks coming into OpenVMS, then existing
organizations are going to have to train their new staff in the
operating system and tools.

[Scott Dorsey]

Kerry Main <kemain...@gmail.com> wrote:
>
>I would argue that the one of the big interests at the enterprise
>level in Linux is its perceived "free" cost. There is more than
>one business case that has been pushed which compares license
>costs to Linux (free) vs. its competition (expensive up front
>licenses).

Free != Open Source

Open Source != Public Domain

Source-Licensed != Free (in the sense of speech)

Source-Licensed may equal Free (in the sense of beer).

There are plenty of ways to make software available to people who need it
at a cost they are willing to pay (even if that cost is zero) and to make
source code availlable to people who need it without opening it up to the
extent of the GPL or BSD licenses or even at all.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Stephen Hoffman]

On 2016-10-01 14:01:23 +0000, Kerry Main said:

> It's been discussed a thousand times before, but imho, open source is a
> terrible strategy for OpenVMS.

But whether the current OpenVMS strategy will work out?

>> I understand that VSI have probably negotiated the best deal they could
>> with HPE at the time, my probing and being the antagonist is not meant
>> to be negative about the whole thing but more to put my hat into the
>> ring as to where/what I think would help OpenVMS going forward. I know
>> people in academic circles and linux is still king because of open
>> source and the education sector is driving the minds of the future
>> coders. I just want to find a way to attract them to OpenVMS if at all
>> possible
>
> I would argue that the one of the big interests at the enterprise level
> in Linux is its perceived "free" cost. There is more than one business
> case that has been pushed which compares license costs to Linux (free)
> vs. its competition (expensive up front licenses).

Guess where all the new deployments and the prototype projects happen?
On Linux. Because folks don't need to acquire licenses, can re-use
available hardware, and can grow into vendor support if (when?) that
becomes necessary. Because folks are familiar with managing and
developing for the Linux platform. Because the tools that us younger
folks prefer — yes, I'm one of the younger folks, per VSI — are
available for Linux. Because OpenVMS has no entry-level product
offerings. Because at least prior to x86-64 and we don't know what
hardware will be supported with that, OpenVMS requires special hardware.

This greatly reduces the numbers of experimental and development
projects that might decide to start on OpenVMS, and greatly increases
the numbers starting on Linux.

Gaining — or regaining — a market in the commercial operating system
business is a large and expensive endeavor, with more than a little
risk particularly given the competition and given the market is
consolidating, and any entrant very likely takes a decade or more of
"runway" just to get some traction and some visibility — visibility
outside the installed base, in the case of OpenVMS.

Software and operating system prices are increasingly free — that's
what everybody's been increasingly trained to expect — and with in-app
purchases and support costs and value-added features and related.

Competing against "free" with a commercial product and with no free
license tier is not an easy sales call. Then there's the cost of
running a sales organization, which isn't cheap and which usually means
the low-volume sales — the sorts of sales of the sizes that small teams
and prototype projects that might just be starting out — can get fewer
sales callbacks from even the resellers.

We're not in the same market that spawned the classic OpenVMS
licensing, pricing and sales approaches.

[Kerry Main]

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

> Of Stephen Hoffman via Info-vax
> Sent: 01-Oct-16 10:08 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>

> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> On 2016-10-01 13:25:57 +0000, David Froble said:
>

[snip..]

> > I'll just ask, other than the concept that there is something
> special
> > about open source, just what real world benefits can you
> imagine there
> > might be?
>
> Asking a question is a very good start to learning. Apache and
> nginx
> are available, common and with active development, known
> configuration
> syntax and other benefits. As good as WASD is and as well-
> integrated
> as it is, it's yet another thing that folks would have to learn, if
> WASD were to be the web server integrated into OpenVMS.
> Postfix and
> other common packages are similarly known. ISC BIND is already
> part
> of OpenVMS, albeit not particularly integrated and a very old
> version.
> And yes, there are platforms that put very effective GUIs in
> front of Apache, Postfix, BIND and other tools.
>

While ports are available on different platforms, Apache and nginx are native *nix developed so have a *nix focus of development.

IIS is a good example where the vendor Microsoft has developed a platform specific alternative to Apache/nginx. While many could argue which web solution is better on a Windows platform, there are a lot of Windows focused groups who do IIS because it is a native Windows solution.

Imho, the bundling of a solution developed specifically for a platform e.g. WASD does not prevent an alternative solution like Apache from also being used on a specific platform. A pre-installed Apache on LD container similar to how Perl is distributed on OpenVMS might be one option.

In terms of overall solutions enhancement, I remember what a Microsoft Engineer told me one time - the biggest driver for new features and enhancements to the core Windows platform did not come from Customers, but rather the internal SQL Server, IIS and Exchange groups at Microsoft. In other words, the Windows core was not being enhanced for other vendor products.

That’s a pretty amazing concept - support other options like Apache, but focus major core improvements on platform specific solutions.

> Everybody has to train new staff to local practices, of course. If
> there aren't younger folks coming into OpenVMS, then existing
> organizations are going to have to train their new staff in the
> operating system and tools.
>

I do agree training is important and using multi-platform tools is a way to minimize the differences between platforms.

Key areas of focus for improvement are on those areas where enterprise L1 admins do the majority of their work - backups (often a third party product), account admin (LDAP /AD), File mgmt., scheduling (often third party product).

[Kerry Main]

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

> Of Stephen Hoffman via Info-vax
> Sent: 01-Oct-16 10:44 AM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>

> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

Why would VSI require special server HW?

Like Microsoft, I envision an initial "supported and tested" list of HW that VSI supports and that grows over time.

I envision OpenVMS ISV's will also have similar lists specific to their environment - exactly what ISV's do today with other OS platforms.

There will likely also be informal community "not fully tested, but seems to work fine" server lists.

> This greatly reduces the numbers of experimental and
> development projects that might decide to start on OpenVMS,
> and greatly increases the numbers starting on Linux.
>
> Gaining — or regaining — a market in the commercial operating
> system business is a large and expensive endeavor, with more
> than a little risk particularly given the competition and given the
> market is consolidating, and any entrant very likely takes a
> decade or more of "runway" just to get some traction and some
> visibility — visibility outside the installed base, in the case of
> OpenVMS.
>
> Software and operating system prices are increasingly free —
> that's what everybody's been increasingly trained to expect —
> and with in-app purchases and support costs and value-added
> features and related.
>

To my earlier points - RH Linux is not free for med-large orgs.

To their credit, RH has developed a great financial model. They have simply transferred the upfront very expensive license costs to a multi-year monthly support cost model which is better for them as well as the Customer. RH gets increased cash flow and the Cust gets what they want by being able to hide the true costs of the Linux platform in an annual OPS budget.

> Competing against "free" with a commercial product and with no
> free
> license tier is not an easy sales call. Then there's the cost of
> running a sales organization, which isn't cheap and which usually
> means the low-volume sales — the sorts of sales of the sizes that
> small teams and prototype projects that might just be starting out
> — can get fewer sales callbacks from even the resellers.
>
> We're not in the same market that spawned the classic OpenVMS
> licensing, pricing and sales approaches.
>

Again, no one is saying VSI should adopt a "free" model. My thoughts would be to adopt a model similar to RH which focuses on long term cash flows via monthly support contracts (which get paid in one shot by most Cust's anyway) vs up front expensive licenses.

There are also other benefits to a monthly support model like being closer and having more interaction to your Customers (contracts need to be kept current). You can add things like loyalty programs (discounts for things like consulting services, number of OS's under contract, length of time with VSI etc.)

[Jan-Erik Soderholm]

Same with Rdb. Many VMS enhancements was on request from the Rdb group.
Even after Rdb was sold to Oracle.

[Robert A. Brooks]

On 10/1/2016 8:22 AM, Jan-Erik Soderholm wrote:

> The short term goal is probably to come out with an own build of
> VMS for Alpha to be able to sign support contracts.

Correct.

> I'd be happy to advice my customer to transfer the VMS support
> contracts to VSI, if that helps with founding the x86 port and
> general future of VMS.

Yes, it would help, and we'd greatly appreciate that!

--
-- Rob

[Stephen Hoffman]

On 2016-10-01 14:56:24 +0000, Kerry Main said:

> While ports are available on different platforms, Apache and nginx are
> native *nix developed so have a *nix focus of development.

Okay. So? Keep going. What are you implying with that? Unix
and particularly Linux are the predominant competitors for OpenVMS, as
well as an exceedingly large source of software, as well as the server
platforms that OpenVMS will be commonly interoperating with in most
environments. They're fine platforms, with many good ideas and some
of which are well worth borrowing and improving upon, yes and with some
bad ideas and bad designs and frustrations in other parts, and Unix and
Linux systems can be easier to manage and deploy and develop for than
is OpenVMS. If VSI wants to grow past the current OpenVMS installed
base, the VSI folks will have to gain customers that might otherwise
have deployed Unix and Linux, which means VSI needs to understand the
advantages and disadvantages and cost advantages and cost disadvantages
of those platforms, too. As compared with OpenVMS.

> IIS is a good example where the vendor Microsoft has developed a
> platform specific alternative to Apache/nginx. While many could argue
> which web solution is better on a Windows platform, there are a lot of
> Windows focused groups who do IIS because it is a native Windows
> solution.

Microsoft is a wee bit larger and better funded than is VSI, and with a
slightly larger customer base. If VSI gets to the scale of Microsoft?
The calculations then differ. Slightly. Right now, VSI doesn't
have enough staff for what they have written on their whiteboards — not
by any stretch — and VSI just did an acquisition of an IP stack, and
that's before discussing taking on the continued development and
maintenance of project of the scale of a web server. Whether that
starts with WASD and hiring folks familiar with same, the development
of a new stack, or otherwise. For now, Apache likely means somewhat
less customer training is required; folks already know that.

> Imho, the bundling of a solution developed specifically for a platform
> e.g. WASD does not prevent an alternative solution like Apache from
> also being used on a specific platform. A pre-installed Apache on LD
> container similar to how Perl is distributed on OpenVMS might be one
> option.

Having Perl and Apache integrated into the distro and always present
would be far better. Having to deal with the configuration
permutations of separate installations means more code in OpenVMS and
in layered products and third-party packages, more testing complexity,
more risks of failures as the software versions skew, and more than a
few projects that simply won't use or won't require the tools because
they're not always present. In short, this approach continues with
the same scatter-shot software platform strategy currently in use, and
with the addition of another patch path and yet another update strategy
required, and with a completely different way to find out if the pieces
are present, and with no obvious way to place a front-end on any of
this to reasonably manage what's installed. That's not forward
progress.

> In terms of overall solutions enhancement, I remember what a Microsoft
> Engineer told me one time - the biggest driver for new features and
> enhancements to the core Windows platform did not come from Customers,
> but rather the internal SQL Server, IIS and Exchange groups at
> Microsoft. In other words, the Windows core was not being enhanced for
> other vendor products.
>
> That’s a pretty amazing concept - support other options like Apache,
> but focus major core improvements on platform specific solutions.

I'd been my experience that customer-facing polling will give you very
few new ideas, and what feedback received — and as happened at the most
recent boot camp — will seek to dissuade development from changing the
platform in any incompatible fashion, and — where changes can or do
occur — will trade off current software investments and approaches for
(often greatly) increased future development work and future management
much more difficult, delayed release schedules, and such. It's all a
trade-off, of course. But I'd prefer it if VSI had the conviction of
their decisions, and started looking forward. Because that's what
brings new users. Compatibility with the past is what makes 64-bit
addressing such a mess to deal with. Customers don't (yet) understand
the value of changes and newer approaches, and — unless the questions
are asked very carefully — will err toward avoiding costs and changes
with their current platforms. Quite justifiably preferring to avoid
any changes, in many cases. But that subset of sites — those sites in
environments or organizations that can't or won't change — shouldn't be
dictating the future of the platform.

[Bob Gezelter]

On Thursday, September 22, 2016 at 11:24:22 PM UTC-4, David Froble wrote:
> IanD wrote:
> > On Monday, September 19, 2016 at 9:41:03 PM UTC+10, clairg...@gmail.com wrote:
> >> RE: Alpha
> >>
> >> Alpha is a very difficult issue for us. We have people coming to us looking for Alpha support
> >> but the only way we can provide it at this time is for the customer to upgrade to a VSI release.
> >> If you have been running on 7.3-2 for 10+ years do you really want to disturb that environment?
> >>
> >

> > Those environments are throwing their money at like the likes of Stormasys and other emulators
> >
> > What they want is to reduce their risk of their environments blowing up. At this stage of the game that would be aging hardware most of all
> >
> > Beyond that, I suspect they would love a path forward
> >
> > That is certainly the case where I am
> >
> > If someone came along and said "For X $'s, we can move you forward", they would jump at the chance. The systems are being decommissioned to remove risk of failure not because they are tired of OpenVMS (yeah, we are on 7.3-2)
> >
> >> The Alpha Evaluation Kit (AEK) gave us a means to get some feedback on the OS itself, beyond
> >> what we do ourselves. That was good. We provided no layered products with the AEK.
> >>
> >> Our real motivation for considering Alpha releases is to provide a better path to get to x86; get
> >> up to date first and it will be an easier move. However, we have always wondered if we can
> >> provide the layered products needed by these older environments. Do we really want to support
> >> some really ancient HW?
> >>
> >
> > If we had a clear path onto x86 from Alpha 7.3-2, I suspect we would stay on OpenVMS going forward (but that includes the Application as well)
> >
> > Alas, the decision was made some time ago to vacate OpenVMS before VSI clearly stating concrete intentions of forging an OpenVMS pathway to x86
> >
> > I would say there's a number of shops out there wanting support on Alpha but more importantly, want someone to help them find a pathway onto Itanium and/or x86
> >
> >> We are working with partners who have lists of thousands of Alpha systems. We are contacting
> >> these users to see first, if they are interested in upgrading, and if they are, what do they need
> >> for SW beyond the OS and what HW platforms are they on. We have a good idea of what we
> >> can provide. The question is - can we provide the layered products to satisfy enough customers
> >> to make this a worthwhile venture for us. We can’t just be spreading good will here since every
> >> minute we spend on Alpha we are not spending on x86.
> >>
> >
> > Yeah, it's a balancing act and a difficult one, I don't envy your position at all
> >
> > There must be core packages though that people are using more than others. I guess weighing up what to bring over and what to leave behind isn't always easy and it's not a 1:1 relationship either.
> >
> > For those that are on arcane software constructs, they will either have to pay to bring that software across or pay to migrate elsewhere, finding a way to keep them on OpenVMS may be very difficult
> >
> >> People seem to think that just because there are thousands of Alpha systems out there that they
> >> should become VSI customers and make us lots of money. It’s not that obvious.
> >
> > I look at the porting efforts that will go into moving the platform I look after onto a linux based oracle offering. It's not going to be cheap at all. I'd guess in the millions actually by the time it's all done
> >
> > VSI with all it's expertise would probably make easy work of getting things over to Itanium with the latest version of RDB. The Application side would be more work but it could be done. There's talk of source code issues but I've heard for the right money that's not a stumbling block.

> >
> > The current folk doing the port know zero about OpenVMS and they are trying to move it all to linux.
> >

> > If someone had said to the business 12 months ago, here's how we could move you off that old hardware and you could retain your existing application functionality because it's a port on the same OS / code base, I think they might have jumped at it.
> >
> > The only winner in what's happening where I work will be Oracle and whomever does the development work and OpenVMS will vanish as a presence here probably forever :-(
> >
> > There will be no future OpenVMS licensing agreements being renewed here and that is a crying shame, it's the loss of a presence that's going to hurt OpenVMS going forward
>

> So, prepare a short presentation, and submit it to the powers that be. You
> could point out the "safety" in not losing the current working app. Costs would
> need to be pointed out, including getting the sources, and building them first
> on itanic, and later on x86. Not going to be cheap, but perhaps much cheaper
> than a from scratch re-write. Once you got the sources, you would not face that
> problem again, and you'd have future flexibility.
>
> That re-write from scratch is going to have some problems, and may never reach
> what you now have. It's a bottomless money pit.
>

> Never know, might work, and if it doesn't how are you worse off than now?

David,

Actually, as I noted in my presentation at last week's Bootcamp, the port to x86-64 is simpler than the port to Itanium (I will be uploading my presentations to my firm's www site in the next weeks).

Put simply, there are no representation issues when going from Itanium to x86-64. They are both 64-bit environments with IEEE floating point. If one's source base is current with regards to language standards, there is little issue.

If one's Alpha-based code is using VAX floating point (Alpha support both VAX and IEEE formats), there is the issue of verifying that there are no issues raised by the slight differences in computation related to the differences between the two formats. As before, my suggestion is to do the change in floating point BEFORE changing architectures.

Some other small changes should be made to any conditionalization, to reflect that the architecture is not the relevant issue, but the representations are the issue. There are those who will notice that data structures need reflect the fact that the size of a longword is not necessarily the size of a pointer.

- Bob Gezelter, http://www.rlgsc.com

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Jan-Erik Soderholm via Info-vax
> Sent: 01-Oct-16 11:30 AM
> To: info...@rbnsn.com
> Cc: Jan-Erik Soderholm <jan-erik....@telia.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

[snip..]

> > In terms of overall solutions enhancement, I remember what a
> Microsoft
> > Engineer told me one time - the biggest driver for new
features
> and
> > enhancements to the core Windows platform did not come
> from Customers,
> > but rather the internal SQL Server, IIS and Exchange groups
at
> > Microsoft.
>
> Same with Rdb. Many VMS enhancements was on request from
> the Rdb group.
> Even after Rdb was sold to Oracle.
>

Yep - and a lot of the UNIX portability enhancements to OpenVMS
came from the Oracle Enterprise Database group.

:-)

[Bob Gezelter]

IanD,

The jump from Alpha 7.3-2 to Alpha 8.4 et seq. is mainly a qualification exercise. I have rarely needed to make any source changes. Of course, taking advantage of new features may need small tweeks.

Clearly, the best choice is to move to 8.4 (preferably 8.4-2L1), then when x86-64 becomes available, do that transition. My personal recommendation remains as it has always been, use the smallest viable system to do the jump, use the small system to develop empirical performance results to size an actual production environment.

[Stephen Hoffman]

On 2016-10-01 15:21:41 +0000, Kerry Main said:

> To my earlier points - RH Linux is not free for med-large orgs.

Centos.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 01-Oct-16 12:40 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> On 2016-10-01 15:21:41 +0000, Kerry Main said:
>
> > To my earlier points - RH Linux is not free for med-large
orgs.
>
> Centos.
>

In all my DC migration projects, I can say that the number of
Centos installs were some fraction less than 1%. As part of the
DC Migration target site standardization efforts, OS platforms
like Centos were under pressure to migrate to the typical company
Linux std (RH).

By far, the OS's involved were Windows, RH Linux, Solaris, other
*nix's, z/OS, other stuff (incl OpenVMS, SuSE Linux, Oracle
Enterprise Linux) ...

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 01-Oct-16 12:11 PM
> To: info...@rbnsn.com
> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

> On 2016-10-01 14:56:24 +0000, Kerry Main said:
>
> > While ports are available on different platforms, Apache and
> nginx are
> > native *nix developed so have a *nix focus of development.
>
> Okay. So? Keep going. What are you implying with that? Unix
> and particularly Linux are the predominant competitors for
> OpenVMS, as well as an exceedingly large source of software, as
> well as the server platforms that OpenVMS will be commonly
> interoperating with in most
> environments. They're fine platforms, with many good ideas and
> some
> of which are well worth borrowing and improving upon, yes and
> with some bad ideas and bad designs and frustrations in other
> parts, and Unix and Linux systems can be easier to manage and
> deploy and develop for than
> is OpenVMS. If VSI wants to grow past the current OpenVMS
> installed
> base, the VSI folks will have to gain customers that might
> otherwise have deployed Unix and Linux, which means VSI needs
> to understand the advantages and disadvantages and cost
> advantages and cost disadvantages
> of those platforms, too. As compared with OpenVMS.
>

Where did I say they were not good options?

The issue is that while many of these non-OpenVMS product options work just fine on OpenVMS, there are porting issues like fork which are unique to *nix architectures. Hence, different workarounds need to be put in place which may not necessarily be the optimum way of doing things on another platform like OpenVMS or even Windows for that matter.

Also, how many of these open source options support active-active shared disk clustering which on OpenVMS allows scaling by transparently adding servers without changing any application code such as that required when dealing with DB sharding in shared nothing designs?

Btw, Apache is a nice exception because it does support OpenVMS shared disk clusters.

Getting something to work on another platform does not necessarily mean it is optimally tuned for that OS's strengths.

> > IIS is a good example where the vendor Microsoft has
> developed a
> > platform specific alternative to Apache/nginx. While many could
> argue
> > which web solution is better on a Windows platform, there are
> a lot of
> > Windows focused groups who do IIS because it is a native
> Windows
> > solution.
>
> Microsoft is a wee bit larger and better funded than is VSI, and
> with a
> slightly larger customer base. If VSI gets to the scale of
> Microsoft?
> The calculations then differ. Slightly. Right now, VSI doesn't
> have enough staff for what they have written on their
> whiteboards — not by any stretch — and VSI just did an
> acquisition of an IP stack, and that's before discussing taking on
> the continued development and
> maintenance of project of the scale of a web server. Whether
> that
> starts with WASD and hiring folks familiar with same, the
> development of a new stack, or otherwise. For now, Apache
> likely means somewhat less customer training is required; folks
> already know that.
>

As stated above, Apache is an exception as it is popular and also supports shared disk OpenVMS clusters.

An LD approach like Perl is pretty brain dead simple. Create/mount the LD drive and update the startup file.

Compatibility with backwards versions is an issue for all OS vendors - it's not unique to VSI.

Just ask Microsoft or Red Hat.

Sample reference:
https://access.redhat.com/articles/rhel-abi-compatibility

[Paul Sture]

Yes. We once came across a bug in a bit of VMS which was only accessed
by Rdb.

--
"I have spent most of the day putting in a comma and
the rest of the day taking it out." -- Oscar Wilde

[Paul Sture]

On 2016-10-01, Bob Gezelter <geze...@rlgsc.com> wrote:
>
> Clearly, the best choice is to move to 8.4 (preferably 8.4-2L1), then
> when x86-64 becomes available, do that transition. My personal
> recommendation remains as it has always been, use the smallest viable
> system to do the jump, use the small system to develop empirical
> performance results to size an actual production environment.
>

I rather agree on the "smallest viable systems to do the jump" aspect.

I have too many times come across systems developed on the latest and
greatest hardware which have resulted in user disappointment when run on
the planned production hardware.

That still happens of course. The app developer with lots of RAM, SSDs
all round plus a fat internet pipe isn't going to see the bottlenecks
experienced by either the home user or the large corporate who are
running on systems which are several years old.

Of course, forcing your developers to work on old slow systems isn't the
best way forward. You can resolve this by ensuring that you have test
systems which are reasonably close in spec to target production systems.

[Simon Clubley]

On 2016-09-30, IanD <iloveo...@gmail.com> wrote:
>
> I'm still 'negative' (although I think it's more realistic) as to
> what's facing VMS in the near future. X86 is one thing, security
> another, but right behind that is development and I don't mean faster
> builds, I'm meaning getting those universities and young minds
> interested in developing on OpenVMS, because it's not going to grow
> much without the next base of minds to drag it forward. I have friends
> in achedemic circles and it's no longer about tinkering with code,
> it's about having the tools to build newer and better items and for
> that ideal you need a platform that easily and readily can pull open
> source code and run with it easily. University projects are not much
> about develop this tool or that tool anymore, that stopped years ago,
> there's enough tools to do just about any job now. It's all about
> bundling items to enable higher order functionality and develop
> frameworks and platforms that the education sector is teaching the
> next round of people to perform.

If teaching today is only about assembling existing bricks into higher
level structures and not about making the bricks themselves, then who
teaches the people needed to design and build the next generation
of bricks ?

Simon.

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

[Craig A. Berry]

On 10/1/16 12:44 PM, Kerry Main wrote:

> An LD approach like Perl is pretty brain dead simple. Create/mount
> the LD drive and update the startup file.

You might be confusing Perl with Python.

[Stephen Hoffman]

On 2016-10-01 17:24:53 +0000, Kerry Main said:

>>
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
>> Of Stephen Hoffman via Info-vax
>> Sent: 01-Oct-16 12:40 PM
>> To: info...@rbnsn.com
>> Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
>> Marketing Brochures
>>
>> On 2016-10-01 15:21:41 +0000, Kerry Main said:
>>
>>> To my earlier points - RH Linux is not free for med-large orgs.
>>
>> Centos.
>
> In all my DC migration projects, I can say that the number of Centos
> installs were some fraction less than 1%. As part of the DC Migration
> target site standardization efforts, OS platforms like Centos were
> under pressure to migrate to the typical company Linux std (RH).

I'd previously commented that free entry-level systems that can grow
into supported systems. You'd countered with the assumption I was
referring to RHEL, and that RHEL is not free for end-users. Which is
true. Centos is one of the ways this is done. Centos is an
entry-level into the RHEL environment. It's intended to be compatible
with RHEL. And Centos is free.

More recently, the Centos distro is also being directly supported by
RedHat, too. https://en.wikipedia.org/wiki/CentOS

Centos is how folks can get going with server projects and new
applications. Either with Centos or one of the other free distros, on
local hardware or on hosted services, or both. By not spending a
lot on the servers and the pilots and the low-end projects, at least
until the services and applications become more established and more
critical.

If it's in a data cebter and folks from HPE were involved in a DC
migration, then folks probably have the budget for RHEL where they need
it, and either don't use Centos, or they might just need the Centos
boxes or images or containers moved — because those systems were not
yet considered business-critical functions. Entry-level projects
prototypes and "shadow IT" projects tend not to be visible particularly
widely, either. But they're one of the places where new customers and
new deployments come from.

Again, there are entry-level options for Unix and Linux servers for
end-users, and such options are free for the software and with the
hardware either scrounged or hosted or cheap to buy, and there is a
path to configurations with vendor support. There is not a free
entry-level for OpenVMS end-users. With OpenVMS, a new organization
or a group seeking to start or to run a small project has to start out
with Itanium hardware and commercial license purchases.

This is not the production servers and critical applications of large
and enterprise businesses. This is where future enterprise
applications and businesses and future business-critical applications
come from. This is part of the genesis where those "blue ocean"
bunches get their start. Not by (initially) spending lots of money on
RHEL or OpenVMS licenses and support. That's projects quite often
(initially) involving hardware or hosting and software that costs less
than an OpenVMS two-core license, in practical terms.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf
> Of Craig A. Berry via Info-vax
> Sent: 01-Oct-16 3:41 PM
> To: info...@rbnsn.com
> Cc: Craig A. Berry <craig...@nospam.mac.com>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
>

Oops - yep, you are correct. It is the Python install that uses
LD disks.

Thx for the correction.

[Stephen Hoffman]

On 2016-10-01 17:44:40 +0000, Kerry Main said:


> An LD approach like Perl is pretty brain dead simple. Create/mount the
> LD drive and update the startup file.

We'll have to disagree. Sure, swapping in another set of LD images is
easy. Dealing with upgrades, finding where the bits installed
particularly when there are now multiple independent LD images, there's
the effort involved in migrating files and such forward across
upgrades, stuff that's not so easy. And it's a whole 'nother
installation ad upgrade mechanism, when the existing OpenVMS VMSINSTAL
and PCSI mechanisms are limited at best, and where timely notifications
and such are entirely out-of-band, and processing entirely manual.
So now we have a second approach which works differently — simpler in
some ways, but worse in some others — than the one we have, with no
particular means of locating and isolating and identifying dependencies
and incompatibilities, and with all sorts of fun around logical name
redirections and/or finding libraries or just figuring out what's
installed when something else installs, and either requiring a new or a
manual cryptographic checksum if there's any requirement for
assurance.... The existing utter morass is enough of a prob.... um,
has more than enough room for improvement, and that's without adding
distro-by-LD. But I give up....

[David Froble]

Bob Gezelter wrote:

> David,
>
> Actually, as I noted in my presentation at last week's Bootcamp, the port to
> x86-64 is simpler than the port to Itanium (I will be uploading my
> presentations to my firm's www site in the next weeks).

Bob, I don't know how it could be much simpler. The Alpha to itanic port, with
one exception, which was a programming bug on my part on image rundown that
Alpha didn't report, and itanic squaked over, was compile, link, and run.

Your stuff is always an interesting read.

> Put simply, there are no representation issues when going from Itanium to
> x86-64. They are both 64-bit environments with IEEE floating point. If one's
> source base is current with regards to language standards, there is little
> issue.
>
> If one's Alpha-based code is using VAX floating point (Alpha support both VAX
> and IEEE formats), there is the issue of verifying that there are no issues
> raised by the slight differences in computation related to the differences
> between the two formats. As before, my suggestion is to do the change in
> floating point BEFORE changing architectures.

We use D-float, and already know of the issues, which we've overcome. As long
as that doesn't change, we're expecting another compile, link, and run.

[David Froble]

Paul Sture wrote:
> On 2016-10-01, Bob Gezelter <geze...@rlgsc.com> wrote:
>> Clearly, the best choice is to move to 8.4 (preferably 8.4-2L1), then
>> when x86-64 becomes available, do that transition. My personal
>> recommendation remains as it has always been, use the smallest viable
>> system to do the jump, use the small system to develop empirical
>> performance results to size an actual production environment.
>>
>
> I rather agree on the "smallest viable systems to do the jump" aspect.

Also agree.

> I have too many times come across systems developed on the latest and
> greatest hardware which have resulted in user disappointment when run on
> the planned production hardware.
>
> That still happens of course. The app developer with lots of RAM, SSDs
> all round plus a fat internet pipe isn't going to see the bottlenecks
> experienced by either the home user or the large corporate who are
> running on systems which are several years old.
>
> Of course, forcing your developers to work on old slow systems isn't the
> best way forward. You can resolve this by ensuring that you have test
> systems which are reasonably close in spec to target production systems.

Paul, for some time now, at least for the things I do, there is no "old slow
system", unless I'm on the VAX. I'm using an AlphaServer 800, and it's way
overkill, for development. I don't even power up the EV6 systems most of the
time. I'm getting an RX2660 forced on me, and that will be overkill many times
over, for development.

I can imagine some things that might make these systems work a bit, but so far
haven't had to do any of that.

[Phillip Helbig (undress to reply)]

In article <27c6e2e0-e540-4eca...@googlegroups.com>,

clairg...@gmail.com writes:

> The VSI/HPE agreement does not allow us to make VMS open source.

And a good thing that is too.

For the first time since sometime BEFORE the demise of DEC, VMS is in
the hands of people who know it well and care about it. While there is
a fear that it might be too little too late, let's give them a chance
and see what happens.

[Phillip Helbig (undress to reply)]

In article <eb43b5c8-c59c-4885...@googlegroups.com>, IanD
<iloveo...@gmail.com> writes:

> I'm not just saying 'open source' because I think it's the best thing. I ad=
> vocate open source mainly because it's the current model that is attracting=
> all the new minds to the point where most people coming out of uni now wil=
> l refuse to touch anything that is not open source - such has been the brai=
> nwashing of the young! Microsoft has all but caved in to this as well and h=
> ave done an about face

Is it some open-source tool which posts paragraph-long lines to a
text-based newsgroup, causing them to be unnecessarily base-64 encoded?

If people are brain-washed like this, that's not the mentality I want
working on VMS.

> I advocate open source because I happen to think it's another way to remove=
> the stumbling blocks that OpenVMS is already facing and it doesn't need mo=

> re stumbling blocks, it needs to make itself as attractive as possible

What are the stumbling blocks? How will people familiar with OTHER
open-source products be able to solve them? Who will make sure that
there is some quality control? Who will pay them?

[Jan-Erik Soderholm]

Den 2016-10-01 kl. 19:44, skrev Kerry Main:

>
> An LD approach like Python is pretty brain dead simple. Create/mount the

> LD drive and update the startup file.
>

(Yes, I changed Perl to Python... :-) )

Also note that the two Python LD containers are in ODS-5 format.
Since our regular disks are ODS-2, this helps a lot since we do
not need to add basic disk volumes in ODS-5 format "just" to run
and use Python. Note that your own Python scripts and applications
doesn't need ODS-5, just the Python environment as such.

[IanD]

On Sunday, October 2, 2016 at 5:44:59 PM UTC+11, Phillip Helbig (undress to reply) wrote:
> In article <eb43b5c8-c59c-4885...@googlegroups.com>, IanD
> <iloveo...@gmail.com> writes:
>

<snip>

>
> Is it some open-source tool which posts paragraph-long lines to a
> text-based newsgroup, causing them to be unnecessarily base-64 encoded?
>

I access it however I see fit using what tool I have available. Some are open source, some are not.
Care to highlight the difference between the open source ones I'm using and the one's not?

If you have an issue perhaps a polite post rather than a snide remark might get you further, then again, perhaps it's a character thing

> If people are brain-washed like this, that's not the mentality I want
> working on VMS.
>

Brainwashed... oh dear, we're sliding further down the evolutionary slope of decency

Besides that, you have just perfectly demonstrated a facet of why open source works. Open source attracts all sorts of people with different thinking so that the full 360 degree spectrum is covered versus someone who thinks they hold a monopoly on what constitutes good VMS thinking

> > I advocate open source because I happen to think it's another way to remove=
> > the stumbling blocks that OpenVMS is already facing and it doesn't need mo=
> > re stumbling blocks, it needs to make itself as attractive as possible
>
> What are the stumbling blocks? How will people familiar with OTHER
> open-source products be able to solve them? Who will make sure that
> there is some quality control? Who will pay them?

Where is Linux today compared to OpenVMS? Years ahead and the gap is growing

Where is Windows today compared to OpenVMS? Years ahead and the gap is growing

Please enlighten us on the following...

How do you think VMS is going to catch up or stop being left behind? Doing a redhat perhaps? Redhat usurped open source indirectly by piggybacking on Linux and open source and monetised it for their own profit. I'm merely advocating VMS look to do something similar and piggyback on what is clearly working

Apart from existing customers, how do you propose to attract new customers to VMS?
Through organic growth or tapping into an existing open source code base out there? Which one do you think will create the largest growth and bring the quickest dividends?

How do you propose to attract new developers to VMS?
Do you have contacts in the education sector? I do and I can tell you with 100% certainly that open source virtually totally dominates here. Perhaps your snide remark about brainwashing might have been better focused pointing out what the education sector is doing to young minds when it comes to pushing ideas and ideals because these are the people you need to attract to VMS

As for computing languages, the one's attracting the largest base of current coders and future are in fact open sourced based one's or moving towards it

Java will go some of the way to helping code being ported over the VMS but it's hardly going to drive new innovation to be developed on the VMS platform.
VMS will be a target for deployment not the home for software development for large scale projects other than specific projects targeting VMS itself and I think that number will be tiny on actual VMS

Browse GitHub and see what's coming down the pipeline and then enlighten us how VMS is going to be playing in these future arena's and working with even a fraction of these endeavours without an open source presence and/or open source focus or embracing open source?

VMS is closed source and it appears the licence agreement will keep it that way, that's ok but it doesn't mean that going forward open source cannot be looked at for newer aspects of the OS or do you somehow think that VSI can keep up with Linux with it's 10's of 1000's of contributors who are moving it's innovation further along at an accelerating pace.

Do you think VSI will keep pace with what's coming down the pipeline in Linux? It's going to take VSI 2 - 3 years more just to move VMS to x86. What is Linux going to bring to IT in this time?

DEC failed, it's as simple as that

Having the best custodians in the world doesn't buy success. History is littered with examples of companies who failed because they failed to adapt to what was actually wanted

Best intent doesn't produce sales or attract people and businesses to systems, Market forces win's that game and the market at the moment is telling the world Linux and open source is where you need to be - you can cry a river over the right or wrong of that and it will not change a thing, it's what business believe they need

VSI's actions have slowed the tide of VMS sites rushing for the door, as to wether they have stopped it or reversed it will remain to be seen

Is it too late? Who really knows. All I know is they are doing 'something'. Is it Technically or Marketing wise or Education wise, enough?
Who knows, we will all have our specific view here and time will tell what actually ends up happening

On Sunday, October 2, 2016 at 6:01:15 AM UTC+11, Simon Clubley wrote:
> On 2016-09-30, IanD <iloveo...@gmail.com> wrote:
> >

<snip>

>
> If teaching today is only about assembling existing bricks into higher
> level structures and not about making the bricks themselves, then who
> teaches the people needed to design and build the next generation
> of bricks ?
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Don't shoot the messenger please!

I'm just relaying what the education sector is doing, I'm not endorsing it or saying I agree with it. I was pointing out the mentality of the sector and by comparison showing were VMS I think is relative to that model

The education sector stopped producing thinking and inquiring minds long ago

They pump out graduates who are productive, not innovative. They have succumbed to market forces pushed by the agenda of big business, who want productive people not so much thinkers unless that thinking can be monetised

The innovators and developers are the breakaways who either get fed up with the education sector and make their escape or they are developed in labs somewhere in the deep learning centres of the likes of Google etc

[David Froble]

IanD wrote:

> Where is Linux today compared to OpenVMS? Years ahead and the gap is growing

Linux has some large organizations doing development. It's not just individuals.

> Where is Windows today compared to OpenVMS? Years ahead and the gap is
> growing

Weendoze has a large organization doing development. It's never individuals.

> Please enlighten us on the following...
>
> How do you think VMS is going to catch up or stop being left behind? Doing a
redhat perhaps? Redhat usurped open source indirectly by piggybacking on Linux
and open source and monetised it for their own profit. I'm merely advocating VMS
look to do something similar and piggyback on what is clearly working

What I'd like to see is some details on what's leaving VMS behind. Yes, there
is vast room for improvement. But strictly for an OS, I tend to doubt these
claims of "vast differences".

> Apart from existing customers, how do you propose to attract new customers to
> VMS? Through organic growth or tapping into an existing open source code base
> out
there? Which one do you think will create the largest growth and bring the
quickest dividends?

When looking at open source stuff, you need to ask, does it have any benefit for
VMS? Perhaps some of it might not.

> How do you propose to attract new developers to VMS? Do you have contacts in
> the education sector? I do and I can tell you with
100% certainly that open source virtually totally dominates here. Perhaps your
snide remark about brainwashing might have been better focused pointing out what
the education sector is doing to young minds when it comes to pushing ideas and
ideals because these are the people you need to attract to VMS

AS I've pointed out in the past, being exposed to VMS in education would be
nice, but not essential.

> As for computing languages, the one's attracting the largest base of current
coders and future are in fact open sourced based one's or moving towards it

But, are those "current coders" doing anything worthwhile?

> Java will go some of the way to helping code being ported over the VMS but
it's hardly going to drive new innovation to be developed on the VMS platform.
> VMS will be a target for deployment not the home for software development for
>
large scale projects other than specific projects targeting VMS itself and I
think that number will be tiny on actual VMS
>
> Browse GitHub and see what's coming down the pipeline and then enlighten us
how VMS is going to be playing in these future arena's and working with even a
fraction of these endeavours without an open source presence and/or open source
focus or embracing open source?

Quantity is not the same as quality. How many of those things do you have a use
for?

> VMS is closed source and it appears the licence agreement will keep it that
way, that's ok but it doesn't mean that going forward open source cannot be
looked at for newer aspects of the OS or do you somehow think that VSI can keep
up with Linux with it's 10's of 1000's of contributors who are moving it's
innovation further along at an accelerating pace.

If there are 10s of thousands of coders for the Linux OS, how many lines of code
are allocated to each, 2-4, maybe 5?

:-)

No, the core stuff is being done by a small core of people, probably most of
them being paid for their work.

> Do you think VSI will keep pace with what's coming down the pipeline in
> Linux?
It's going to take VSI 2 - 3 years more just to move VMS to x86. What is Linux
going to bring to IT in this time?

That's a scary thought. We can hope not too much ....

> On Sunday, October 2, 2016 at 5:40:59 PM UTC+11, Phillip Helbig (undress to reply) wrote:
>> In article <27c6e2e0-e540-4eca...@googlegroups.com>,
>> clairg...@gmail.com writes:
>>
>>> The VSI/HPE agreement does not allow us to make VMS open source.
>> And a good thing that is too.
>>
>> For the first time since sometime BEFORE the demise of DEC, VMS is in
>> the hands of people who know it well and care about it. While there is
>> a fear that it might be too little too late, let's give them a chance
>> and see what happens.
>
> DEC failed, it's as simple as that

DEC failed because they could not trim the huge work force that the very
expensive early computers supported.

[Stephen Hoffman]

On 2016-10-05 03:25:02 +0000, David Froble said:

> IanD wrote:
>
>> Where is Linux today compared to OpenVMS? Years ahead and the gap is growing
>
> Linux has some large organizations doing development. It's not just
> individuals.

Yes, Linux is years ahead, in many ways. Linux involves many more
developers and many more organizations. There are parts and ideas
worth using and worth borrowing in other operating systems and tools,
and there are areas that are problems. Same as OpenVMS. Same as any
other operating system or tool, for that matter.

>> Where is Windows today compared to OpenVMS? Years ahead and the gap is growing
>
> Weendoze has a large organization doing development. It's never individuals.

Ayup. Operating systems are huge projects. Microsoft too is much
larger than VSI, and — in many ways — much further ahead, and — within
the constrains of their installed base — moving far faster. Far more
in-house and ISVs and affiliated developers, and with much better
development tools, too.

Outside of catering to the installed base, it'll be interesting to see
where VSI starts heading. But I digress.

>> Please enlighten us on the following...
>>
>> How do you think VMS is going to catch up or stop being left behind?
>> Doing a redhat perhaps? Redhat usurped open source indirectly by
>> piggybacking on Linux and open source and monetised it for their own
>> profit. I'm merely advocating VMS look to do something similar and
>> piggyback on what is clearly working
>
> What I'd like to see is some details on what's leaving VMS behind.
> Yes, there is vast room for improvement. But strictly for an OS, I
> tend to doubt these claims of "vast differences".

If the goal is 1990s applications and 1990s-era code, OpenVMS works
quite well. It will very likely continue to do so, too.

Where OpenVMS falls over — badly — has been discussed here.
Repeatedly. TLS integration, IP integration, LDAP integration, ease
of distributed management, ease of deployment, simpler management.

To attract newer applications and newer deployments? For the 2020s,
that likely involves getting back to what made OpenVMS a fine choice as
an operating system in the 1980s — ease of use, consistency, security —
and that involves performing redesigns of some parts, large overhauls
of other parts, and substantial updates, vastly improved development
tools, and a whole host of other details.

This gets back to experience with other tools and platforms. And
then there's the current pricing and related expectations in the
commercial software market. Start out your business or your prototype
or your small project for free with Centos, then migrate (easily) to
RHEL for projects that want or need to purchase the ability to blame an
outside organization.

>> Apart from existing customers, how do you propose to attract new
>> customers to VMS? Through organic growth or tapping into an existing
>> open source code base out there?

> Which one do you think will create the largest growth and bring the
> quickest dividends?

There aren't any obvious candidates. Any of those candidates are
already running on other platforms, and usually better integrated into
at least some of those other platforms.

> When looking at open source stuff, you need to ask, does it have any
> benefit for VMS? Perhaps some of it might not.

Chunks of what-should-be-part-of-OpenVMS are open source now. OpenSSL,
Apache, Python, Perl, LLVM, libxml2, libjson, libarchive or zip and
unzip, and various other giblets. These or equivalents are available
on most platforms.

>> How do you propose to attract new developers to VMS? Do you have
>> contacts in the education sector? I do and I can tell you with

> 100% certainly that open source virtually totally dominates here.
> Perhaps your snide remark about brainwashing might have been better
> focused pointing out what the education sector is doing to young minds
> when it comes to pushing ideas and ideals because these are the people
> you need to attract to VMS

Maybe the open source works well enough for their requirements, at a
price they can afford? Linux, Windows, iOS and other platforms have
followed variations of that approach as part of establishing and
increasing their business, too.

> AS I've pointed out in the past, being exposed to VMS in education
> would be nice, but not essential.

All businesses perform some sort of explicit or informal training for
their new folks. More than a few businesses have effectively
outsourced chunks of their employee training programs to schools, and
with the costs paid by the schools and by the students. Most
organizations that are using servers involve Linux and Windows, as well
as hosted services. This situation is a problem for other businesses,
particularly if the schools aren't teaching the tools the business
needs. These businesses now have to fund (more of) that training, and
a smaller pool of potential staff.

>> As for computing languages, the one's attracting the largest base of
>> current coders and future are in fact open sourced based one's or
>> moving towards it
>
> But, are those "current coders" doing anything worthwhile?

Enough are. Some of these current or future coders are also the
folks that will be replacing each and every one of us. If we don't
succeed in somehow getting rid of our own jobs first.

>> Java will go some of the way to helping code being ported over the VMS
>> but it's hardly going to drive new innovation to be developed on the
>> VMS platform. VMS will be a target for deployment not the home for
>> software development for large scale projects other than specific
>> projects targeting VMS itself and I think that number will be tiny on
>> actual VMS
>>
>> Browse GitHub and see what's coming down the pipeline and then
>> enlighten us how VMS is going to be playing in these future arena's and
>> working with even a fraction of these endeavours without an open source
>> presence and/or open source focus or embracing open source?
>
> Quantity is not the same as quality. How many of those things do you
> have a use for?

Not much, but that's like asking somebody which computer games they
play. There are lots of projects, and lots of games. But of what
Github and open source code I am using? It works, and it's useful.
So is VSI. VSI is centrally dependent on some of that same
Github-based code.

>> VMS is closed source and it appears the licence agreement will keep it
>> that way, that's ok but it doesn't mean that going forward open source
>> cannot be looked at for newer aspects of the OS or do you somehow think
>> that VSI can keep up with Linux with it's 10's of 1000's of
>> contributors who are moving it's innovation further along at an
>> accelerating pace.
>
> If there are 10s of thousands of coders for the Linux OS, how many
> lines of code are allocated to each, 2-4, maybe 5?
>
> :-)
>
> No, the core stuff is being done by a small core of people, probably
> most of them being paid for their work.

Yes, Linux has a lot of folks involved. Many are getting paid. This
from 2015:
https://www.linux.com/publications/linux-kernel-development-how-fast-it-going-who-doing-it-what-they-are-doing-and-who


As for getting paid... I've gotten paid to write code that's been open
sourced. I've had projects to port code to OpenVMS, too. Payments
are how you can get folks to do what you want, after all.

As for project scale, BSD is seemingly moving forward faster than
OpenVMS. At least in terms of development and features.

>> Do you think VSI will keep pace with what's coming down the pipeline in Linux?

No. I don't. VSI just doesn't have the scale.

> It's going to take VSI 2 - 3 years more just to move VMS to x86. What
> is Linux going to bring to IT in this time?
>
> That's a scary thought. We can hope not too much ....

Linux will bring quite a lot, I expect. Some ideas worth borrowing,
some not. Here's a quick list of what arrived in Linux 4.8:
http://www.phoronix.com/scan.php?page=article&item=linux-48-features&num=1
ARM, POWER, graphics hardware, file systems, work on security well
past what OpenVMS offers around ASLR, improved and integrated
cryptographic random number generation, etc. The live kernel patching
that merged into Linux 4.0 is something that doesn't exist on OpenVMS,
too.
http://phoronix.com/scan.php?page=news_item&px=Linux-4.0-Kernel-Big-Features

>
>> On Sunday, October 2, 2016 at 5:40:59 PM UTC+11, Phillip Helbig
>> (undress to reply) wrote:
>>> In article <27c6e2e0-e540-4eca...@googlegroups.com>,
>>> clairg...@gmail.com writes:
>>>> The VSI/HPE agreement does not allow us to make VMS open source.
>>> And a good thing that is too.

Out of curiousity, why? Are you aiming for not having to deal with the
platform — akin to folks using Microsoft Windows or macOS now — or
because you perceive open source as being problematic, and
closed-source as somehow better?

>>> For the first time since sometime BEFORE the demise of DEC, VMS is in
>>> the hands of people who know it well and care about it. While there is
>>> a fear that it might be too little too late, let's give them a chance
>>> and see what happens.
>>
>> DEC failed, it's as simple as that
>
> DEC failed because they could not trim the huge work force that the
> very expensive early computers supported.

IMHO, DEC failed because it didn't adapt to changing markets and
products quickly enough, and actively avoided trying to cannibalize its
own products and services. For a company that was founded and that
worked extensively and directly with ISVs and skilled customers on
early hardware integration and on software, that DEC utterly missed the
lower-cost shifts and the open source transition and missed the
ascendence of software was and remains unfathomable. DEC missed out
on new (huge) markets (PCs, mobile, hosted) and on new products, and
folks move on to Windows and Linux and other platforms. Folks migrated
as DEC and Compaq and HP had suggested. But I digress. Having too
many folks on staff was secondary to missing these and other market
changes. Once you miss these sorts of shifts within and underneath
your own businesses, you're in deep sneakers, too.

[Simon Clubley]

On 2016-10-04, IanD <iloveo...@gmail.com> wrote:
> On Sunday, October 2, 2016 at 6:01:15 AM UTC+11, Simon Clubley wrote:
>>
>> If teaching today is only about assembling existing bricks into higher
>> level structures and not about making the bricks themselves, then who
>> teaches the people needed to design and build the next generation
>> of bricks ?
>>
>

> Don't shoot the messenger please!
>

Oh, I'm not and I've started to see the same things as well.

The above was utter frustration at the short sighted mindset of
the education establishment and the long term damage they are
causing with such an approach.

> I'm just relaying what the education sector is doing, I'm not
> endorsing it or saying I agree with it. I was pointing out the
> mentality of the sector and by comparison showing were VMS I think is
> relative to that model
>
> The education sector stopped producing thinking and inquiring minds long ago
>
> They pump out graduates who are productive, not innovative. They
> have succumbed to market forces pushed by the agenda of big business,
> who want productive people not so much thinkers unless that thinking
> can be monetised
>

In the old days, we used to call those technical schools or something
similar, not universities.