December 7, 2016 - Updated Roadmap

[clairg...@gmail.com]

http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf

I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

[IanD]

On Thursday, December 8, 2016 at 12:21:58 AM UTC+11, clairg...@gmail.com wrote:
> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>
> I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

Thanks

Looking forward to the 'state of the x86 port' too

[Forster, Michael]

Thank you for the update even if it's no news - you took the effort to update us. It's holiday season too. Much appreciated.

I hope there is a VSI hobby license for the os and layered products i.e. CSLG.

Michael Forster
Enterprise Storage and IDX Architect | Information Services
Medical College of Wisconsin
O: (414) 955-4967 | mfor...@mcw.edu


________________________________________
From: Info-vax <info-vax...@rbnsn.com> on behalf of clairgrant71--- via Info-vax <info...@rbnsn.com>
Sent: Wednesday, December 7, 2016 7:21:55 AM
To: info...@rbnsn.com
Cc: clairg...@gmail.com
Subject: [Info-vax] December 7, 2016 - Updated Roadmap

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.vmssoftware.com_pdfs_VSI-5FRoadmap-5F20161205.pdf&d=DgICAg&c=aFamLAsxMIDYjNglYHTMV0iqFn3z4pVFYPQkjgspw4Y&r=2i3Iy38OaXCqI2PNgrM4Aw&m=Zzq3TfvrGXkd1MeUTR01PLHrXTIh6oUUhxvCici8M-c&s=SgF-vP-FWLlRCDxRU0mwDdH_s-h1vCR_WdPKC9bTRMc&e=

I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

_______________________________________________
Info-vax mailing list
Info...@rbnsn.com
https://urldefense.proofpoint.com/v2/url?u=http-3A__rbnsn.com_mailman_listinfo_info-2Dvax-5Frbnsn.com&d=DgICAg&c=aFamLAsxMIDYjNglYHTMV0iqFn3z4pVFYPQkjgspw4Y&r=2i3Iy38OaXCqI2PNgrM4Aw&m=Zzq3TfvrGXkd1MeUTR01PLHrXTIh6oUUhxvCici8M-c&s=SRmAJr64c94yfH64upDBlmyiz7a75PrpioMs6MTWRNI&e=

[Neil Rieck]

On Wednesday, December 7, 2016 at 8:21:58 AM UTC-5, clairg...@gmail.com wrote:
> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>
> I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

I am especially interested in one item under "Research Areas" titled "MariaDB"

We have quite a bit of experience running MariaDB-5.5-25 on OpenVMS where very large databases experience shutdown problems (at least when using the InnoDB Engine)

We recently tested MariaDB-10.1.19 on CentOS-5 (our development OpenVMS platform is sending SQL requests to the Linux box over a private network). MariaDB is now behaving properly but introducing Linux into the mix has introduced new issues. (not to mention that CentOS-5 will not be supported after March 2017 and, we can’t get CentOS-6 or 7 running on our ancient DL360-G5)

A modern version of MariaDB on OpenVMS would solve all our problems.

Neil Rieck
Waterloo, Ontario, Canada.
http://www3.sympatico.ca/n.rieck/

[clairg...@gmail.com]

On Thursday, December 8, 2016 at 11:30:22 AM UTC-5, Neil Rieck wrote:

> I am especially interested in one item under "Research Areas" titled "MariaDB"
>
> We have quite a bit of experience running MariaDB-5.5-25 on OpenVMS where very large databases experience shutdown problems (at least when using the InnoDB Engine)
>
> We recently tested MariaDB-10.1.19 on CentOS-5 (our development OpenVMS platform is sending SQL requests to the Linux box over a private network). MariaDB is now behaving properly but introducing Linux into the mix has introduced new issues. (not to mention that CentOS-5 will not be supported after March 2017 and, we can’t get CentOS-6 or 7 running on our ancient DL360-G5)
>
> A modern version of MariaDB on OpenVMS would solve all our problems.
>

We are in the process of defining our next steps for MariaDB.

[Simon Clubley]

On 2016-12-07, clairg...@gmail.com <clairg...@gmail.com> wrote:
> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>
> I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

Thank you once again Clair.

I don't know what others think, but I think both documents serve
very different purposes.

I see the Roadmap as more of a longer term planning document that
allows people to do some initial planning. However, the State of
the Port document allows one to see actual progress being made,
quarter by quarter, in the VMS x86-64 port and allows a person to
build confidence that the Roadmap plans for VMS will actually happen.

For me, it's all about VSI projecting an image that the port is
on track (because most things in the Roadmap depend on the x86-64
port being successful) and the State of the Port document gives you
more immediate feedback that this is happening.

Simon.

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

[Jan-Erik Soderholm]

Thanks!

I miss one thing that was mentioned by the VSI folks (I think it
was, or if it was someone from HP) at the presentations held during
the event at IKEA IT HQ a month ago.

It was mentioned that, together with this once-in-a-lifetime release
of an VSI Alpha OpenVMS kit, there would also be a support option to
go with that release. And it was also mentioned that any such Alpha
support contract signed for 3 years (or more) would include a free
license migration to the VSI x86-64 OpenVMS version, when available.

This Alpha support was ment as an "stepping stone" between the
end of HP support and the release of the x86-64 version.

This is also in line with the update of the VSI Support web page.
For those who haven't noticed, see "Right to Major Versions:" here:
http://vmssoftware.com/services_supp.html. I think that has been
added fairly reasently.

[Robert A. Brooks]

On 12/8/2016 5:27 PM, Jan-Erik Soderholm wrote:
> Den 2016-12-07 kl. 14:21, skrev clairg...@gmail.com:
>> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>>
>> I do not have an updated State of the Port. Sorry about that but I'll
>> try to get to it soon.

> I miss one thing that was mentioned by the VSI folks (I think it
> was, or if it was someone from HP) at the presentations held during
> the event at IKEA IT HQ a month ago.
>
> It was mentioned that, together with this once-in-a-lifetime release
> of an VSI Alpha OpenVMS kit, there would also be a support option to
> go with that release. And it was also mentioned that any such Alpha
> support contract signed for 3 years (or more) would include a free
> license migration to the VSI x86-64 OpenVMS version, when available.

To be clear, it's not a "support option". If you want the license
to run VSI OpenVMS Alpha V8.4-2L1, you need to pay for support, and
essentially get the licenses for free. One cannot pay for the licenses
and decline support, technically, although I suppose you could pay for
support but refuse to use it. In any event, there is no option
for HPE support; only VSI will support OpenVMS Alpha V8.4-2L1

It's my understanding that the license to run the software (the operating system
and layered products) does not have a termination date, such that one can pay
for support for, say, three years, but continue to run the software after three
years, but without support.

You get the licenses for all the layered products and SIPs, so if you've never
used Host-Based Volume Shadowing on Alpha, now is your chance to be dazzled by
the wonders of Host-Based Minimerge. If you've never experienced the wonders of
cluster formation, and the tingling feeling one gets at the console when you see
the OPCOM message "waiting to form or join an OpenVMS Cluster", your wait can
soon be over.

--
-- Rob

[Jan-Erik Soderholm]

Den 2016-12-09 kl. 00:47, skrev Robert A. Brooks:
> On 12/8/2016 5:27 PM, Jan-Erik Soderholm wrote:
>> Den 2016-12-07 kl. 14:21, skrev clairg...@gmail.com:
>>> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>>>
>>> I do not have an updated State of the Port. Sorry about that but
>>> I'll try to get to it soon.
>
>> I miss one thing that was mentioned by the VSI folks (I think it was,
>> or if it was someone from HP) at the presentations held during the
>> event at IKEA IT HQ a month ago.
>>
>> It was mentioned that, together with this once-in-a-lifetime release
>> of an VSI Alpha OpenVMS kit, there would also be a support option to
>> go with that release. And it was also mentioned that any such Alpha
>> support contract signed for 3 years (or more) would include a free
>> license migration to the VSI x86-64 OpenVMS version, when available.
>
> To be clear, it's not a "support option". If you want the license to
> run VSI OpenVMS Alpha V8.4-2L1, you need to pay for support, and
> essentially get the licenses for free. One cannot pay for the licenses
> and decline support, technically, although I suppose you could pay for
> support but refuse to use it. In any event, there is no option for HPE
> support; only VSI will support OpenVMS Alpha V8.4-2L1

Ah, thanks for that clarification. No problem with that. My customer
is currently having the VMS support contract through a local reseller
in Sweden and they have asked how they (the reseller) will handle
this for 2017. No information from them yet.

Is there some kind of price list available yet for the different
(supported) Alpha boxes?

And was it correct that a 3 year (or more) contract includes a free
migration to x86-64 when available? Just as your support webb page
says (in a slightly different wording). I guess that will be for the
base OS, not the LPs? But then, we haven't seen the licensing model yet
for the x86-64 version. I think a subscription model was mentioned by
someone at the IKEA IT HQ meeting. More like a guess, I think. :-)

>
> It's my understanding that the license to run the software (the
> operating system and layered products) does not have a termination date,
> such that one can pay for support for, say, three years, but continue to
> run the software after three years, but without support.
>

> You get the licenses for all the layered products and SIPs,...

So for our three boxes (prod, test and dev), there would be the same
single "all-included" licence? Including Fortran, C and Cobol compilers
for the dev box?

I must also check that "ABC Client" would run OK on VSI OpenVMS Alpha
V8.4-2L1. https://storserver.com/software/storserver-software-abc/

And we also run Rdb and CDD... :-)

[Phillip Helbig (undress to reply)]

In article <o2crcj$vtq$1...@dont-email.me>, "Robert A. Brooks"

<FIRST...@vmssoftware.com> writes:

> It's my understanding that the license to run the software (the
> operating system and layered products) does not have a termination date,
> such that one can pay for support for, say, three years, but continue to
> run the software after three years, but without support.

Any idea what the lowest-cost option is? Are there hobbyist options?

> You get the licenses for all the layered products and SIPs, so if you've
> never used Host-Based Volume Shadowing on Alpha, now is your chance to
> be dazzled by the wonders of Host-Based Minimerge. If you've never
> experienced the wonders of cluster formation, and the tingling feeling
> one gets at the console when you see the OPCOM message "waiting to form
> or join an OpenVMS Cluster", your wait can soon be over.

Stop it, Rob. Some folks are getting hard already! :-)

[David Froble]

I do believe that Robert indicated the "licenses" are free. That pretty much
answers all your questions. Free is after all, "free". Just keep the support
active, and as some would say, "Bob's your uncle".

> Just as your support webb page
> says (in a slightly different wording). I guess that will be for the
> base OS, not the LPs? But then, we haven't seen the licensing model yet
> for the x86-64 version. I think a subscription model was mentioned by
> someone at the IKEA IT HQ meeting. More like a guess, I think. :-)
>
>>
>> It's my understanding that the license to run the software (the
>> operating system and layered products) does not have a termination date,
>> such that one can pay for support for, say, three years, but continue to
>> run the software after three years, but without support.
>>
>> You get the licenses for all the layered products and SIPs,...
>
> So for our three boxes (prod, test and dev), there would be the same
> single "all-included" licence? Including Fortran, C and Cobol compilers
> for the dev box?

That's not as clear. I'd hope that "testing" and "development" would be covered
under some sort of developer program. After all, it's in VSI's best interest
that you can develop and test on VMS, so that you can run "production". It is
"production" that generates the money, some of which can then be paid to VSI for
support.

> I must also check that "ABC Client" would run OK on VSI OpenVMS Alpha
> V8.4-2L1. https://storserver.com/software/storserver-software-abc/
>
> And we also run Rdb and CDD... :-)

Very unfortunately, your relationship with Larry will most likely continue with
him taking large chunks of your cash ....

>> so if
>> you've never used Host-Based Volume Shadowing on Alpha, now is your
>> chance to be dazzled by the wonders of Host-Based Minimerge. If you've
>> never experienced the wonders of cluster formation, and the tingling
>> feeling one gets at the console when you see the OPCOM message "waiting
>> to form or join an OpenVMS Cluster", your wait can soon be over.

Being a developer, I doubt I have any use of such products, other to recommend
they be used when needed ....

[Jan-Erik Soderholm]

What was described at the IKEA meeting was that you needed to sign up
for a 3-year support contact (or more). As I understand that, is that
it is not enough to just renew on a 1-year basis (for three years).

That is also in accordance with the writing in the support page
where it says:

"Right to Major Versions: Purchasing a support term of three years or
more directly from VMS Software, for any of the four support packages,
grants rights to new major version releases, along with minor version
releases, patches, updates, etc."

How do you interpret that, David?

And yes, it was not clear if the license covered normal LPs that
are used in a typica productin environment, or if it also includes
the compilers. This is a rather special support/licens setup, as
I understand.

[Paul Sture]

On 2016-12-09, David Froble <da...@tsoft-inc.com> wrote:

> Jan-Erik Soderholm wrote:
>>
>> So for our three boxes (prod, test and dev), there would be the same
>> single "all-included" licence? Including Fortran, C and Cobol compilers
>> for the dev box?
>
> That's not as clear. I'd hope that "testing" and "development" would
> be covered under some sort of developer program. After all, it's in
> VSI's best interest that you can develop and test on VMS, so that you
> can run "production". It is "production" that generates the money,
> some of which can then be paid to VSI for support.

Indeed, "hotline, gimme an answer Right Now support" may be suitable for
your production boxes, but the only time you are likely to want that for
development or test boxes is when going live to a hard deadline.

>>Rob wrote:
>>>
>>> so if you've never used Host-Based Volume Shadowing on Alpha, now is
>>> your chance to be dazzled by the wonders of Host-Based Minimerge.
>>> If you've never experienced the wonders of cluster formation, and
>>> the tingling feeling one gets at the console when you see the OPCOM
>>> message "waiting to form or join an OpenVMS Cluster", your wait can
>>> soon be over.
>
> Being a developer, I doubt I have any use of such products, other to
> recommend they be used when needed ....

But some or all of those can be useful when you have a large and
expensive development team to service.

--
tar: Cowardly refusing to create an empty archive

[David Froble]

Well, I'm a bit worried about that. Yes, VSI needs money, now. But if they
take a bunch of 3-year payments up front, then where will the money come from in
years 2 and 3? Starts to look a bit like those "pyramid schemes". Long term,
they fail.

But, if they are going to use a support type of billing, then it won't matter
when someone wants to get support for VMS, they will sell it, that's their
business. Can't really be any other way.

Frankly, even if they are pinched a bit now, and I don't know that, I think
taking no more than a one year at a time payment would be best, thus insuring
future income. Doesn't do any good to get the port done, just to go belly up
because they already spend the support moneys.

> And yes, it was not clear if the license covered normal LPs that
> are used in a typica productin environment, or if it also includes
> the compilers. This is a rather special support/licens setup, as
> I understand.

I'm going to hope that they sell support for everything on production systems,
and no cost for development and test systems. Now, that gets a bit tricky, when
someone's business is development, which would sort of make their systems
"production". But the other side is, development for VMS systems is in VSI's
best interest.

[David Froble]

Well, I guess that's possible. My preference is one system per person, so that
when I crash it, I don't cause others to lose work, and patience, and
forbearance, and ....

:-)

Now here, one senile old man, working part time, ....

[Steven Schweda]

> > [...] "Right to Major Versions: Purchasing a support term of three
> > years or more directly from VMS Software, [...]

> Well, I'm a bit worried about that. Yes, VSI needs money, now. But if
> they take a bunch of 3-year payments up front, then where will the money
> come from in years 2 and 3? Starts to look a bit like those "pyramid
> schemes". Long term, they fail.

I missed the part of the terms which demanded full payment in
advance. (Duh.)

[Jan-Erik Soderholm]

> Well, I'm a bit worried about that. Yes, VSI needs money, now...

I do not know what you know about the VSI finance situation.

When at the IKEA meeting, Johan Gedda (main investor in VSI)
talked a bit around the situation. The amount of money spent
into the X86 port so far and how much more it probably needed
to get it flying. Actual sums in USD was mentioned. I think
the message was that they wasn't in any major crisis or so.
But then, what else could he say... :-)

Johan Gedda also talked some about Rocket Software that he co-founded
with a friend in 1990 to create software for IBM mainframes now
with over 1.000 employees. http://www.rocketsoftware.com/

I got the impression that Johans income from Rocket helps with the
founding of VSI. As I remember it, he expressed that it had been, in
a way, similar backgrounds for both companies. For Rocket it was a
number of software product that IBM wanted to shut down. Rocket took
over them and that has been successfull. In the same way VMS was
something the owner wanted "out" while there was/is customers still
wanting it to stay. So he saw a similar oportunity there.

Nice guy, of course, as beeing Swedish. :-)
Had a chat during lunch.

> But if
> they take a bunch of 3-year payments up front, then where will the money
> come from in years 2 and 3?

From the same bunch of payments. Sometimes it can be worth to invest
a little more in near time to get something ready in the long term.

But then, I thought it was about signing for three years, not to
actually pay for three years up-front. I'm not native english
speaking, so that might be a misinterpretation by me... :-)

[Craig A. Berry]

On 12/9/16 4:26 PM, Steven Schweda wrote:
>>> [...] "Right to Major Versions: Purchasing a support term of three
>>> years or more directly from VMS Software, [...]
>
>> Well, I'm a bit worried about that. Yes, VSI needs money, now. But if
>> they take a bunch of 3-year payments up front, then where will the money
>> come from in years 2 and 3? Starts to look a bit like those "pyramid
>> schemes". Long term, they fail.

Do you always spend *all* of your money on payday?

> I missed the part of the terms which demanded full payment in
> advance. (Duh.)

Isn't that how it's always been, i.e., if you pay for three years of
support you pay *at the beginning*, thereby getting a better price per
year? That's how my magazine subscriptions work, and while I've never
been the contract administrator, I'm pretty sure that's how any VMS
support contract I've ever seen has worked.

I don't really see the problem here. A port to a new architecture is a
major capital expense that doesn't happen every year. Maybe it's a good
thing HP is discontinuing Alpha support in 2017 -- more folks flocking
to VSI right when VSI needs to grow a bit.

And I suspect a lot of people on Alpha don't even have support, so for
the subset of them that are paying attention and might want to move to
x86_64 eventually, giving them an opportunity to fund that effort now
while immediately getting the support and patches they've been doing
without seems like a win for everybody.

[IanD]

On Thursday, December 8, 2016 at 12:21:58 AM UTC+11, clairg...@gmail.com wrote:

> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>
> I do not have an updated State of the Port. Sorry about that but I'll try to get to it soon.

Not intending this to be seen as an 'are we there yet?, are we there yet?' statement

I was re-reading the last State of the Port and was getting goose bumps at at the level of detail so I thought I'd just ask how the new updated State of the Port is coming along...

[clairg...@gmail.com]

State of the Port

http://vmssoftware.com/updates.html

[Simon Clubley]

On 2017-01-10, clairg...@gmail.com <clairg...@gmail.com> wrote:
>
> State of the Port
>
> http://vmssoftware.com/updates.html

Thank you for the update Clair.

The first thing I notice is if you are updating the LLVM version then
you are going to get into needing to get CMake running on VMS unless
you are planning to use an intermediate LLVM version which still had
configure support.

If you are porting CMake, how are you coming along with it and will
the port be usable on Alpha ?

I know you mentioned it before, but I do like the idea of you booting
from a memory disk. Is there any potential there for a site to build
a customised memory image for their own uses and would it be possible
to boot to a memory resident filesystem for normal VMS use without
needing actual disks ?

Overall, the general feeling I get from the document is that the
work is coming along as expected. Well done, and I hope the next
update is equally positive. :-)

[Stephen Hoffman]

On 2017-01-10 19:17:47 +0000, Simon Clubley said:

> The first thing I notice is if you are updating the LLVM version then
> you are going to get into needing to get CMake running on VMS unless
> you are planning to use an intermediate LLVM version which still had
> configure support.

https://groups.google.com/d/msg/comp.os.vms/aglcCW-XTN4/40l2hSXxAwAJ


--
Pure Personal Opinion | HoffmanLabs LLC

[John Reagan]

On Tuesday, January 10, 2017 at 2:19:22 PM UTC-5, Simon Clubley wrote:

>
> The first thing I notice is if you are updating the LLVM version then
> you are going to get into needing to get CMake running on VMS unless
> you are planning to use an intermediate LLVM version which still had
> configure support.
>
> If you are porting CMake, how are you coming along with it and will
> the port be usable on Alpha ?
>

Yep. On my radar. Moving forward is a multi-step process. Here are some details:

- We have built LLVM 3.4.2 on OpenVMS Itanium. That was the last release of LLVM that didn't use C++11 syntax in the code base. The clang 3.4.2 compiler does understand C++11 syntax

- This LLVM is the basis for the cross-compilers we'll use to port the OS, etc.

- Once we have a stable version of OpenVMS x86, we'll use the cross clang 3.4.2 to built LLVM 3.8.0 (the last release that supported configure)

- Once we have native LLVM/clang 3.8.0 running on OpenVMS x86, we'll then build CMake and the LLVM/clang du jour. I've looked at the CMake code and spoke to some experts and might see if we can give it a run on OpenVMS Itanium, but I'm suspect that it would work without modification.

- I was still planning on using make and not ninja but I haven't looked at the ninja source code.

- It is unlikely that you'd get the CMake sources to go through the Alpha C++ compiler.

[Simon Clubley]

On 2017-01-10, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2017-01-10 19:17:47 +0000, Simon Clubley said:
>
>> The first thing I notice is if you are updating the LLVM version then
>> you are going to get into needing to get CMake running on VMS unless
>> you are planning to use an intermediate LLVM version which still had
>> configure support.
>
> https://groups.google.com/d/msg/comp.os.vms/aglcCW-XTN4/40l2hSXxAwAJ
>

Yes, I know I've asked the question previously, but that was
6 months ago and the situation was more unclear at that time.

I was interested in what the current situation is and John's
now being able to provide a much more detailed answer.

[Simon Clubley]

On 2017-01-10, John Reagan <xyzz...@gmail.com> wrote:
> On Tuesday, January 10, 2017 at 2:19:22 PM UTC-5, Simon Clubley wrote:
>
>>
>> The first thing I notice is if you are updating the LLVM version then
>> you are going to get into needing to get CMake running on VMS unless
>> you are planning to use an intermediate LLVM version which still had
>> configure support.
>>
>> If you are porting CMake, how are you coming along with it and will
>> the port be usable on Alpha ?
>>
>
> Yep. On my radar. Moving forward is a multi-step process. Here are some details:
>

[snip]

Thank you for the detailed response. That gives me a good
understanding of where you are going with this (and when).

[IanD]

Awesome

While some of the detail is beyond me, what I do get out of reading this is just how far and wide this is as a project but also, with each update, just how things are gathering together - much like an imploding star, all the materials being drawn in unto itself at an increasing exponential rate until bang! We have VMS-ala-x86-64

To be part of such a project (and more than once for some of you) must give one goosebumps (despite the long hours)!!!

Thanks for the awesome update Clair - really appreciate it :-)

Question: It was mentioned in the notes:

Start Quote:

Now that x86 VMS always boots from memory disk this new code gets plenty of testing from everyday development work and the details are always being fine tuned. We will soon start testing booting
1) over the network and
2) from DVD.

The memory disk file itself is what gets download rather than individually loading the 100+ individual files as is the current case. The initial memory disk file is created by the VMS build/kitting process.

/End Quote

Does this mean that VMS in the future will be able to be distributed as ISO's fully loaded with particular configurations?

i.e.
I can order OpenVMS with C, C++ compiler and a list of say other layered products and I can then grab an ISO of that exact configuration so that I don't need to install the base and the roll forward installing all the products individually?

Having images ready to go in the cloud marketplace is a direction Amazon have already gone and it's good for getting a known state up and running quickly. Amazon of course have gone one step further and created a true marketplace where you can buy other people's images too

I've always thought this is a good idea booting off a self contained image package.

You can add a small extra bit of security too booting from a read-only image. You can perform some type of checksum on the image to make sure it is what you expect to be booting from and can be reasonably certain no-one has tampered with the image file. You could perhaps snapshot a machine image and pack it away for boot next time as well or moving around? I assume if VMS can boot from a static image that it can then capture it's own static image to a file for run-up at another time or another place, in a galaxy far far away?
Yes, I know people could do things like fiddle with the check process etc but security is the sum of all the parts, the more we boost the parts the better things are overall

At the VMS local corner shop in the future, we might get asked...'Would you like a cluster with that VMS-x86-64 image Sir or just the regular size'?

[Jan-Erik Soderholm]

Den 2017-01-11 kl. 00:08, skrev IanD:
> On Wednesday, January 11, 2017 at 1:44:29 AM UTC+11, clairg...@gmail.com
> wrote:
>> On Friday, December 30, 2016 at 3:22:04 AM UTC-5, IanD wrote:
>>> On Thursday, December 8, 2016 at 12:21:58 AM UTC+11,
>>> clairg...@gmail.com wrote:
>>>> http://www.vmssoftware.com/pdfs/VSI_Roadmap_20161205.pdf
>>>>
>>>> I do not have an updated State of the Port. Sorry about that but
>>>> I'll try to get to it soon.
>>>
>>> Not intending this to be seen as an 'are we there yet?, are we there
>>> yet?' statement
>>>
>>> I was re-reading the last State of the Port and was getting goose
>>> bumps at at the level of detail so I thought I'd just ask how the
>>> new updated State of the Port is coming along...
>>
>> State of the Port
>>
>> http://vmssoftware.com/updates.html
>
> Awesome
>
> While some of the detail is beyond me, what I do get out of reading this
> is just how far and wide this is as a project but also, with each
> update, just how things are gathering together - much like an imploding

> star...

Right, and out comes, a starlet.

[David Froble]

IanD wrote:

> Does this mean that VMS in the future will be able to be distributed as ISO's
> fully loaded with particular configurations?
>
> i.e. I can order OpenVMS with C, C++ compiler and a list of say other layered
> products and I can then grab an ISO of that exact configuration so that I
> don't need to install the base and the roll forward installing all the
> products individually?

Well, where would you draw the line? Layered products are not part of the OS.
Not that I'm in charge, but if I were, I'd "just say no". Such a concept could
grow all out of proportion. Sure, you may feel you know what should be in a
base distribution, but others may have totally different ideas. Much better to
keep things separate.

Now, what I would advocate is that the distribution be complete, including
networking, and such. Storage is no longer an issue. Better to include
everything associated with the OS.

[Simon Clubley]

On 2017-01-10, IanD <iloveo...@gmail.com> wrote:
>
> Question: It was mentioned in the notes:
>
> Start Quote:
>
> Now that x86 VMS always boots from memory disk this new code gets plenty of
> testing from everyday development work and the details are always being fine
> tuned. We will soon start testing booting
> 1) over the network and
> 2) from DVD.
>
> The memory disk file itself is what gets download rather than individually
> loading the 100+ individual files as is the current case. The initial memory
> disk file is created by the VMS build/kitting process.
>
> /End Quote
>
> Does this mean that VMS in the future will be able to be distributed as ISO's
> fully loaded with particular configurations?
>

I think you have misunderstood what is going on with the memory disk
reference. VMS requires a primitive boot environment to be available
so it can load the full VMS environment during boot. It also has a
core set of files which need to be loaded during that same boot.
(the 100+ individual files mentioned by Clair).

This has always been the case in one form or another. For example,
back in the VAX days, VMB contained a core set of primitive boot
drivers which VMS could use until enough of itself had been loaded
(one file at a time) so that it could switch to using the newly
loaded drivers instead.

What Clair appears to be doing with the memory disk is instead much
closer to what Linux does with initrd. On Linux, you boot the kernel
and a small initrd filesystem (the filesystem is packaged as a single
image similar in concept to a disk based .iso file).

Linux then mounts this initrd image as it's initial root filesystem
and does the first part of the boot from it. Once enough of Linux
has been booted, Linux then switches it's mounted root filesystem to
the normal on-disk root filesystem.

Clair appears to be doing something very similar with the memory disk
and it raises the very interesting question about if it would be
possible to run a normal but customised site specific VMS environment
from it without ever needing to load any other files during the boot.

> i.e.
> I can order OpenVMS with C, C++ compiler and a list of say other layered
> products and I can then grab an ISO of that exact configuration so that
> I don't need to install the base and the roll forward installing all the
> products individually?
>

No. That's what a decent package manager is for. BTW, PCSI does not
qualify as a decent package manager by today's standards.

[Stephen Hoffman]

Some VAX configurations booted using a virtual disk. It's not at all
a new approach for the bootstrap, even with OpenVMS.

What is being implemented would be excellent fodder for some future
article in Sue's eventual technical journal offering. This as details
of the bootstrap are always interesting to some technical folks, and
marketing benefits can be accrued. Would have been nice to record the
boot camp sessions that discussed this stuff and post that, too. But
backing up a step or three, these details are about as fundamentally
relevant to most folks that will be using OpenVMS on x86-64 as the
innards of how IPB interacts with EFI are relevant to folks using
OpenVMS on Itanium.

The new boot manager that's been discussed once or twice and at boot
camp, and that the new boot manager hopefully reduces the exposure to
the EFI user interface? Now that's far more interesting to
(experienced) system managers, because we're going to be dealing
directly with that. It's also a good spot to build some package and
patch management, as well as access to backup and other
maintenance-related tools. (The client and server systems I commonly
use have this capability already, provide more than I've discussed
here, works very nicely, and completely avoids the need to visit EFI.)

> Clair appears to be doing something very similar with the memory disk
> and it raises the very interesting question about if it would be
> possible to run a normal but customised site specific VMS environment
> from it without ever needing to load any other files during the boot.

They're keeping the boot disk around for crashes, too. It's how the
crashdumps can access what should be a valid and uncorrupted system,
and write the encrypted crash data out to the local disk or the local
dump server host, or (eventually, hopefully, opt-in, yada yada) encrypt
the dump and write the most interesting bits to some remote crash
server at VSI. I'm working with systems that already (user-optionally)
upload application crash data and system crash data, too.

>
>> i.e.
>> I can order OpenVMS with C, C++ compiler and a list of say other
>> layered products and I can then grab an ISO of that exact configuration
>> so that I don't need to install the base and the roll forward
>> installing all the products individually?
>
> No. That's what a decent package manager is for. BTW, PCSI does not
> qualify as a decent package manager by today's standards.

Package and dependency management, or containers. Where appropriate,
client systems can further implement self-service here via Munki or
otherwise, and authorized folks can load packages on servers.

Folks are getting away from monolithic disk images, too. That works
certainly, but it's a morass of permutations, and you're going to be
regenerating the images every time you change something and whenever
you're deploying security patches and updates; OpenSSL or ISC BIND or
Apache and any number of other hunks commonly found on OpenVMS can get
rush updates, and some packages and some environments follow more
frequent or even continuous deployment strategies, even for their own
applications. But whether you use monolithic images, or thin images,
or self-service, or if you customize the OpenVMS installation DVDs with
your own bits, or the (why is this even separate from the base
installation?) factory-installed-software FIS installation approach,
use what works best for your local needs.

https://www.munki.org/munki/
https://github.com/wdas/reposado
http://blog.techtalklive.org/ttlblog/Pages/Imaging-Strategies-for-Mac-OS-X.aspx
Etc.

[dgordo...@gmail.com]

On Wednesday, January 11, 2017 at 8:27:20 AM UTC-5, Simon Clubley wrote:

> What Clair appears to be doing with the memory disk is instead much
> closer to what Linux does with initrd. On Linux, you boot the kernel
> and a small initrd filesystem (the filesystem is packaged as a single
> image similar in concept to a disk based .iso file).

On IA64, satellite and InfoServer boot work this way today. The difference is in how the memory disk is populated. Today the files are requested one at a time via TFTP until the 135-or-so files that *might* be needed are loaded into the memory disk.

X86 will boot from a (container) file that houses all the required drivers and execlets and other bits needed to get started. This allows checksumming and (in the case of installation media) signing of the memory disk image. Network boot will need to request only a single file. If UEFI can use the device (disk, USB, or NIC) then you'll probably be able to boot from it.

--D

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

Simon (and others),

Have you come across Bitnami or anything similar?

Something like Bitnami is what I took from IanD's
question about pre-configured ready-to-deploy ISOs
ready to download. That's rather different from
your interpretation. I have no idea which one was
actually intended :)

Bitnami's business is hosted applications, lots of
different ones, and as a taster and/or to get their
name in front of potential customers, they offer lots
of different applications and application mixes, oven
ready, on downloadable ISOs. Load and go. Some are
for trial purposes, some are the kind of thing you
could deploy on (preferably on their hosted services).

Ignoring the offsite hosting issues, I've no idea if
this "try before you buy" idea is a sensible mid term
model for VSI and its business partners, but as a way
to *easily* get VMS/x86 in front of potential customers,
it's perhaps an interesting technological approach.

Maybe even more simply (in some respects), maybe
something like a few VMware appliances (or similar)
configured for a few different kinds of VMS purchaser,
in sectors which VSI (or partners) think might be
interesting. E.g. the requirements (from VMS) for a
distributed automation/SCADA customer may not be
entirely similar to those of a centralised (but
replicated) financial trading customer, which may
not be the same as... y'know.

In parallel, there's also the question of licencing
but that's a different department altogether. Maybe
there is a case for resurrecting Temporary Service
PAKs...

Have a lot of fun.

[Simon Clubley]

On 2017-01-11, johnwa...@yahoo.co.uk <johnwa...@yahoo.co.uk> wrote:
>
> Simon (and others),
>
> Have you come across Bitnami or anything similar?
>

No, not yet. I know this kind of thing exists, but the cloud
deployment stuff is something I have not had a real need for yet.

I can however see all these custom images spiraling way out of
control in terms of the long term operating/security costs
unless you are very careful.

> Something like Bitnami is what I took from IanD's
> question about pre-configured ready-to-deploy ISOs
> ready to download. That's rather different from
> your interpretation. I have no idea which one was
> actually intended :)
>
> Bitnami's business is hosted applications, lots of
> different ones, and as a taster and/or to get their
> name in front of potential customers, they offer lots
> of different applications and application mixes, oven
> ready, on downloadable ISOs. Load and go. Some are
> for trial purposes, some are the kind of thing you
> could deploy on (preferably on their hosted services).
>
> Ignoring the offsite hosting issues, I've no idea if
> this "try before you buy" idea is a sensible mid term
> model for VSI and its business partners, but as a way
> to *easily* get VMS/x86 in front of potential customers,
> it's perhaps an interesting technological approach.
>

The stuff on the Bitnami website seems to be more about
pre-packaged application packages instead of operating
system instances.

Perhaps having easily downloadable live DVDs with limited
lifetime licences might be a better way to go for VMS.

So, does anyone else think having restricted licence live
DVDs might be a good way to get VMS in front of people
once the x86-64 port becomes generally available ?

[Kerry Main]

Agree - one option might be to enhance LD capabilities to include
booting + licensing paks pre-configured that can be auto-loaded.

Order /download LD1 for Dev environment (all LP's installed, with
option to remove if you want + open source components (TBD)
integrated)
Order / download LD2 for a Prod environment with X primary focus
Order / download LD3 for a Prod environment with Y primary focus

Re: disk space - historically speaking, the reason why we have so many
options at install time is to conserve disk space.

Drives with less than a TB are soon to become the floppies of
tomorrow. Memory sticks are already close to TB level capacities.

With 60TB disks now becoming available (google Seagate 60TB SSD), its
time to rethink install time strategies.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com

[IanD]

On Thursday, January 12, 2017 at 4:18:36 AM UTC+11, johnwa...@yahoo.co.uk wrote:
> On Wednesday, 11 January 2017 13:27:20 UTC, Simon Clubley wrote:

<snip>

>
> Have you come across Bitnami or anything similar?
>
> Something like Bitnami is what I took from IanD's
> question about pre-configured ready-to-deploy ISOs
> ready to download. That's rather different from
> your interpretation. I have no idea which one was
> actually intended :)
>
> Bitnami's business is hosted applications, lots of
> different ones, and as a taster and/or to get their
> name in front of potential customers, they offer lots
> of different applications and application mixes, oven
> ready, on downloadable ISOs. Load and go. Some are
> for trial purposes, some are the kind of thing you
> could deploy on (preferably on their hosted services).
>

<snip>

>
> Have a lot of fun.

I have not heard of this offering but it is along the lines of what I was thinking

Perhaps people need to look at things like Amazon machine images to get an idea of what is already available today

https://aws.amazon.com/amis/oracle/

These are just some of the oracle specific offerings. Other vendors do the same. The AWS marketplace has over 500 pre-configured AMI (Amazon Machine Image) pre-made packages. I was not thinking of lots of different combinations, that gets unmanageable but some might be nice at least.

You might even get to the stage where an iso of the OS is distributed encrypted and unlocked and run in a secure memory model, the same with vendor releases as well. Isn't this partially what we do for the boot kernel? Why stop there?

VMS is going to have to look at things no-one else is doing and lever them. Just porting to x86 and doing what everyone else is doing isn't going to save the platform IMO - the momentum is already landsliding towards linux, VMS needs to give businesses out there a reason to go VMS. Driving down costs through more flexible licensing would be a good thing

[Richard Maher]

On 21-Jan-17 12:58 PM, IanD wrote:

> I have not heard of this offering but it is along the lines of what I
> was thinking
>
> Perhaps people need to look at things like Amazon machine images to
> get an idea of what is already available today
>
> https://aws.amazon.com/amis/oracle/
>
> These are just some of the oracle specific offerings. Other vendors
> do the same. The AWS marketplace has over 500 pre-configured AMI
> (Amazon Machine Image) pre-made packages. I was not thinking of lots
> of different combinations, that gets unmanageable but some might be
> nice at least.
>
> You might even get to the stage where an iso of the OS is distributed
> encrypted and unlocked and run in a secure memory model, the same
> with vendor releases as well. Isn't this partially what we do for the
> boot kernel? Why stop there?
>
> VMS is going to have to look at things no-one else is doing and lever
> them. Just porting to x86 and doing what everyone else is doing isn't
> going to save the platform IMO - the momentum is already landsliding
> towards linux, VMS needs to give businesses out there a reason to go
> VMS. Driving down costs through more flexible licensing would be a
> good thing
>

SNAP!

AWS, Azure, Google cloud need to be leveraged if VMS is to survive.

I really hope VSI has been talking to Amazon about VMS and desired state
configuration.

[IanD]

On Saturday, January 21, 2017 at 5:59:44 PM UTC+11, Richard Maher wrote:
> On 21-Jan-17 12:58 PM, IanD wrote:
>

<snip>

>
> SNAP!
>
> AWS, Azure, Google cloud need to be leveraged if VMS is to survive.
>
> I really hope VSI has been talking to Amazon about VMS and desired state
> configuration.

It's been mentioned that VMS playing in the cloud is a major direction for VMS and it's customers

It also makes me wonder, where clusters will feature in the cloud

I know VMS has things like ICC and other frameworks that can piggyback on low level cluster related 'stuff' but I don't really recall any applications that were really cluster based other than ran multiple copies of itself on various nodes and shared a common data source as though it was local (no concept of farming operations out across a cluster for distributed workloads or I/O splitting)

it seems to me that VMS clustering mainly get's used for disk redundancy (since processes need to log in again if a machine goes down). Yes, having multiple nodes running an application is enhancing application availability but if one has to restart a job / log-in again, you don't really have fault tolerance

With the likes of Hadoop and it's 'friends' (like Cassandra as a distributed DB with redundancy) I'm having a hard time thinking of what advantage VMS clusters in cloud environments will actually have over applications written for large scale linux clusters that do redundancy through duplication since spinning up other nodes in linux cloud land is cheap and quick

Surely VMS clustering will need to undergo some fairly major changes and/or licensing revamps? dynamic cluster licences etc? Sliding scale licensing?

With the likes of Hadoop and it's 'friends' basically creating a means of clustered applications, is the VMS cluster past it's used by date in the cloud environment and if not, how to use it's core technology to give the world something it cannot get now (and pay for!) ?

Enlighten me because I'm starting to get the feeling that the good old VMS cluster is on the endangered species list, at least in cloud environments or is it a niche offering that business will pay for in that environment?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@rbnsn.com] On Behalf Of
> IanD via Info-vax
> Sent: January 30, 2017 11:56 AM
> To: info...@rbnsn.com
> Cc: IanD <iloveo...@gmail.com>
> Subject: Re: [Info-vax] December 7, 2016 - Updated Roadmap
>

Need to think about the developers .. yes, after many years of neglect
by its previous owners, OpenVMS obviously needs to catch-up in a
number of areas.

However, UNIX/Windows developers today have to code most of their HA,
data consistency, node mgmt. (node add/deletes), data sharding, data
routing from app to db, replication etc. in their Application code.
Think of the complexity and additional work associated with this. This
is primarily because of the shared nothing cluster model. Yes, the
shared nothing model does have advantages in some areas, but there are
also loads of cons as well.

With OpenVMS, a great deal of this complexity is handled at the OS
layer in its shared disk cluster model (OpenVMS, Linux/GFS, z/OS).
Yes, one does need to follow OpenVMS cluster programming
recommendations, but that is no different than any platform. Cluster
code takes care of node add/deletes, HBVS handles data consistency,
cluster logicals takes care of resource transparency, when the load
increases, simply add nodes with ZERO impact or changes required on
application code. And each application group might decide to do these
things differently.

To understand what shared nothing developers have to go through in
their app development, reference the following video by a former
Twitter SW Engineer:
https://www.youtube.com/watch?v=H0i_bXKwujQ

Also reference the following which plays really well in a much more
centralized environment:
http://highscalability.com/blog/2015/10/12/making-the-case-for-buildin
g-scalable-stateful-services-in-t.html

Shared nothing vs shared disk comparison:

Shortened link:
http://bit.ly/2kNvRmr
"In next-generation data center architectures, there is a shift to
massively faster and less-congested data-center fabric that would
shift many compute problems toward a preference for
Shared-Everything."

Actual link will wrap:
https://www.quora.com/What-are-the-differences-between-shared-nothing-
shared-memory-and-shared-storage-architectures-in-the-context-of-scala
ble-computing-analytics

Its also important to remember that public clouds are just another
name for outsourcing with all of the pros and cons associated with
outsourcing. Public vs private clouds are simply business models
whereby you pay someone else to provide heavily standardized IT
services or you pay one internal dept. to provide standardized, but
much more custom to meet company requirements, IT services for all of
the company via internal resources, processes and technologies.

Companies today doing private clouds are ramping up internally with
hyper converged infrastructure offerings and gui based service
catalogues to provide things like self provisioning, increased
automation etc.

Imho, with enhancements in key areas, the future is wide open in terms
of potential areas where OpenVMS can differentiate itself.

:-)

[mah...@googlemail.com]

On Tuesday, January 31, 2017 at 12:55:55 AM UTC+8, IanD wrote:
> Enlighten me because I'm starting to get the feeling that the good old VMS cluster is on the endangered species list, at least in cloud environments or is it a niche offering that business will pay for in that environment?

See Are clusters passe` https://groups.google.com/forum/#!activity/comp.os.vms/4aQgQPUNAgAJ/comp.os.vms/91qRIIRpv1s/FhiSWV9XEAAJ