f



VMS Software, Inc. announces agreement to continue development of OpenVMS and Layered Products under HP License

From the Marketplace article:

"Under the agreement, VSI will license OpenVMS operating system source code=
 from HP to expand the OpenVMS product roadmap, by adding new hardware plat=
form releases, beginning with a new version of OpenVMS for HP Integrity i4 =
servers based on Poulson, Intel=AE Itanium=AE Processor 9500 Series (rx2800=
i4, BL8xxi4). In the future, VSI will support other hardware platforms, inc=
luding X86-based servers. ..."

The full article is available at:
http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer=
-of-future-versions-of-openvms-operating-system-2014-07-31

- Bob Gezelter, http://www.rlgsc.com
0
Bob
7/31/2014 5:13:34 PM
comp.os.vms 21904 articles. 1 followers. Post Follow

395 Replies
4371 Views

Similar Articles

[PageSpeed] 50

On 31-Jul-14 12:01, Phillip Helbig---undress to reply wrote:
> Get back to building the best compilers in the world.  An OS needs
> applications, and applications are developed with compilers.

*Bingo!*
Not only this, but they /need/ to be done w/ formal-methods so that the 
compiler is *provably* free of error -- once that is done, there isn't 
any such thing as a compiler bug.

(Granted that there could be errors in the specification, but that isn't 
something that can generally be caught by an automated tool as it's 
essentially equivalent to your boss inserting/omitting a 'not' when he's 
giving you instructions.)
0
Shark8
7/31/2014 1:01:01 AM
--001a1134cfa802559c04ff809322
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Wow! :) Just Wow! Maybe it's time to get back to VMS...

Ken Robinson


On Thu, Jul 31, 2014 at 1:13 PM, Bob Gezelter <gezelter@rlgsc.com> wrote:

> From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source
> code from HP to expand the OpenVMS product roadmap, by adding new hardwar=
e
> platform releases, beginning with a new version of OpenVMS for HP Integri=
ty
> i4 servers based on Poulson, Intel=C2=AE Itanium=C2=AE Processor 9500 Ser=
ies
> (rx2800i4, BL8xxi4). In the future, VSI will support other hardware
> platforms, including X86-based servers. ..."
>
> The full article is available at:
>
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-develop=
er-of-future-versions-of-openvms-operating-system-2014-07-31
>
> - Bob Gezelter, http://www.rlgsc.com
> _______________________________________________
> Info-vax mailing list
> Info-vax@info-vax.com
> http://info-vax.com/mailman/listinfo/info-vax_info-vax.com
>

--001a1134cfa802559c04ff809322
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Wow! :) Just Wow! Maybe it&#39;s time to get back to VMS..=
..<div><br></div><div>Ken Robinson</div></div><div class=3D"gmail_extra"><br=
><br><div class=3D"gmail_quote">On Thu, Jul 31, 2014 at 1:13 PM, Bob Gezelt=
er <span dir=3D"ltr">&lt;<a href=3D"mailto:gezelter@rlgsc.com" target=3D"_b=
lank">gezelter@rlgsc.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">From the Marketplace article:<br>
<br>
&quot;Under the agreement, VSI will license OpenVMS operating system source=
 code from HP to expand the OpenVMS product roadmap, by adding new hardware=
 platform releases, beginning with a new version of OpenVMS for HP Integrit=
y i4 servers based on Poulson, Intel=C2=AE Itanium=C2=AE Processor 9500 Ser=
ies (rx2800i4, BL8xxi4). In the future, VSI will support other hardware pla=
tforms, including X86-based servers. ...&quot;<br>

<br>
The full article is available at:<br>
<a href=3D"http://www.marketwatch.com/story/vms-software-inc-named-exclusiv=
e-developer-of-future-versions-of-openvms-operating-system-2014-07-31" targ=
et=3D"_blank">http://www.marketwatch.com/story/vms-software-inc-named-exclu=
sive-developer-of-future-versions-of-openvms-operating-system-2014-07-31</a=
><br>

<br>
- Bob Gezelter, <a href=3D"http://www.rlgsc.com" target=3D"_blank">http://w=
ww.rlgsc.com</a><br>
_______________________________________________<br>
Info-vax mailing list<br>
<a href=3D"mailto:Info-vax@info-vax.com">Info-vax@info-vax.com</a><br>
<a href=3D"http://info-vax.com/mailman/listinfo/info-vax_info-vax.com" targ=
et=3D"_blank">http://info-vax.com/mailman/listinfo/info-vax_info-vax.com</a=
><br>
</blockquote></div><br></div>

--001a1134cfa802559c04ff809322--

0
Ken
7/31/2014 5:26:34 PM
Bob Gezelter schreef op 31-jul-2014 om 19:13:
>  From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>
> - Bob Gezelter, http://www.rlgsc.com

Well, now that's nice for a change!  I'd love to be a part of
this, too.  If not in terms of programming, perhaps in providing
marketing materials?  (Graphic design and such.)

(I'm also waiting for 'Bill' and the others to whine about this.)

  - MG

0
MG
7/31/2014 5:26:35 PM
In article <a77faa16-50a2-441e-afd2-9937ea2468c0@googlegroups.com>, Bob
Gezelter <gezelter@rlgsc.com> writes: 

> From the Marketplace article:
> 
> "Under the agreement, VSI will license OpenVMS operating system source code=
>  from HP to expand the OpenVMS product roadmap, by adding new hardware plat=
> form releases, beginning with a new version of OpenVMS for HP Integrity i4 =
> servers based on Poulson, Intel=AE Itanium=AE Processor 9500 Series (rx2800=
> i4, BL8xxi4). In the future, VSI will support other hardware platforms, inc=
> luding X86-based servers. ..."
> 
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer=
> -of-future-versions-of-openvms-operating-system-2014-07-31
> 
> - Bob Gezelter, http://www.rlgsc.com

I think I know what the conference call will be about.  :-)

April 1 is almost 4 months ago.

I will go eat some squid, try to participate in the conference call (I 
assume it is possible by telephone and not something fancier) and then 
think about what this means.

0
helbig
7/31/2014 5:35:49 PM
In article <mailman.3.1406827601.13954.info-vax_info-vax.com@info-vax.com>,
	Ken Robinson <kenrbnsn@gmail.com> writes:
> --001a1134cfa802559c04ff809322
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> Wow! :) Just Wow! Maybe it's time to get back to VMS...
> 
> Ken Robinson
> 

I agree...  Wow!

I never expected HP to swallow their ego and let this go.  I am not
familiar with VSI so have no idea how big they are or what resources
they have to carry this out.  Any chance that this is an opportunity
for some of the big guns here to get positions as employees or sub-
contractors to bring some of the collected knowledge and experience
back into the corral?

No, I am not including myself in that group, but if this actually
pans out I could possibly take another look at application level
porting.  I don't hate VMS, honest......

bill

> 
> On Thu, Jul 31, 2014 at 1:13 PM, Bob Gezelter <gezelter@rlgsc.com> wrote:
> 
>> From the Marketplace article:
>>
>> "Under the agreement, VSI will license OpenVMS operating system source
>> code from HP to expand the OpenVMS product roadmap, by adding new hardwar=
> e
>> platform releases, beginning with a new version of OpenVMS for HP Integri=
> ty
>> i4 servers based on Poulson, Intel=C2=AE Itanium=C2=AE Processor 9500 Ser=
> ies
>> (rx2800i4, BL8xxi4). In the future, VSI will support other hardware
>> platforms, including X86-based servers. ..."
>>
>> The full article is available at:
>>
>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-develop=
> er-of-future-versions-of-openvms-operating-system-2014-07-31
>>
>> - Bob Gezelter, http://www.rlgsc.com
>> _______________________________________________
>> Info-vax mailing list
>> Info-vax@info-vax.com
>> http://info-vax.com/mailman/listinfo/info-vax_info-vax.com
>>
> 
> --001a1134cfa802559c04ff809322
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">Wow! :) Just Wow! Maybe it&#39;s time to get back to VMS..=
> .<div><br></div><div>Ken Robinson</div></div><div class=3D"gmail_extra"><br=
>><br><div class=3D"gmail_quote">On Thu, Jul 31, 2014 at 1:13 PM, Bob Gezelt=
> er <span dir=3D"ltr">&lt;<a href=3D"mailto:gezelter@rlgsc.com" target=3D"_b=
> lank">gezelter@rlgsc.com</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex">From the Marketplace article:<br>
> <br>
> &quot;Under the agreement, VSI will license OpenVMS operating system source=
>  code from HP to expand the OpenVMS product roadmap, by adding new hardware=
>  platform releases, beginning with a new version of OpenVMS for HP Integrit=
> y i4 servers based on Poulson, Intel=C2=AE Itanium=C2=AE Processor 9500 Ser=
> ies (rx2800i4, BL8xxi4). In the future, VSI will support other hardware pla=
> tforms, including X86-based servers. ...&quot;<br>
> 
> <br>
> The full article is available at:<br>
> <a href=3D"http://www.marketwatch.com/story/vms-software-inc-named-exclusiv=
> e-developer-of-future-versions-of-openvms-operating-system-2014-07-31" targ=
> et=3D"_blank">http://www.marketwatch.com/story/vms-software-inc-named-exclu=
> sive-developer-of-future-versions-of-openvms-operating-system-2014-07-31</a=
>><br>
> 
> <br>
> - Bob Gezelter, <a href=3D"http://www.rlgsc.com" target=3D"_blank">http://w=
> ww.rlgsc.com</a><br>
> _______________________________________________<br>
> Info-vax mailing list<br>
> <a href=3D"mailto:Info-vax@info-vax.com">Info-vax@info-vax.com</a><br>
> <a href=3D"http://info-vax.com/mailman/listinfo/info-vax_info-vax.com" targ=
> et=3D"_blank">http://info-vax.com/mailman/listinfo/info-vax_info-vax.com</a=
>><br>
> </blockquote></div><br></div>
> 
> --001a1134cfa802559c04ff809322--
> 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
7/31/2014 5:41:29 PM
On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
> From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>
> - Bob Gezelter, http://www.rlgsc.com

From the press release:

|In the future, VSI will support other hardware platforms, including X86-based
|servers

Yeah, good luck with that. :-)

I would _really_ like to be proved wrong with that, but I don't think
this is going to happen. (Sadly. :-()

You simply don't have the levels of hardware abstraction and isolation
within VMS that you do within Linux. It's viable for a group of advanced
students to port Linux to a new architecture due to it's clean internal
architecture which separates out hardware specific code from generic code.

It's a massive exercise OTOH when the operating system is VMS.

Also, don't forget VMS requires more from the underlying architecture
in terms of page protection/multiple rings than Linux does.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
7/31/2014 5:47:53 PM
On 14-07-31 13:13, Bob Gezelter wrote:

> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31


Great news on the surface, But...

Seals the deal in terms of HP no longer interested in VMS. (point of no
return on its decision to abandon VMS development) But then, it opens up
VMS to people who appear to be interested in VMS.

The roadmap indicates intentions to go X86. I guess that should fill a
full afternoon of work for Hoff :-)

This is good news.

<devil advocate mode>
Or it could simply mean a short term boost in VMS followed by a decline
and abandonment, as happened with RSX/RSTE when it was offloaded.
</devil advocate>

If they pull off the port to x86, it may give VMS enough of a boost to
come back to life.

I get the feeling from the roadmap that the guys know what needs to be
done. It is good to see VMS in gands of people who know about VMS'
strengths and weaknesses and what needs fixed.

I wish Nemonix/VMS Software great success. Quite a challenge, but might
be very rewarding.



Can we speculate on who the experts will be ?
0
JF
7/31/2014 5:51:57 PM
On 7/31/2014 11:13 AM, Bob Gezelter wrote:
> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."

The HP announcement may be found on the HP Project Odyssey web page at 
http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/ 
under the title "HP and VMS Software, Inc. Collaborate to Extend OpenVMS 
Solutions" or via the direct link 
http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/openvms.aspx

0
Keith
7/31/2014 5:52:37 PM
On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
> From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>
> - Bob Gezelter, http://www.rlgsc.com

One further thought (and one which future business critical sales
prospects will ask):

	Will VSI be large enough to sue when things go wrong ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
7/31/2014 5:54:03 PM
On 14-07-31 13:47, Simon Clubley wrote:

> within VMS that you do within Linux. It's viable for a group of advanced
> students to port Linux to a new architecture 

If Vms Software really does bring back the real engineering team, they
have experience with VAX/Alpha and Alpha/IA64 so the porting shouldn't
be that difficult once they have the compilers.

OK, so maybe it will take Hoff 2 afternoons to do the job. He can choose
2 rainy days so as to not impair his golfing :-)

0
JF
7/31/2014 5:54:43 PM
On 7/31/2014 11:47 AM, Simon Clubley wrote:
> You simply don't have the levels of hardware abstraction and isolation
> within VMS that you do within Linux. It's viable for a group of advanced
> students to port Linux to a new architecture due to it's clean internal
> architecture which separates out hardware specific code from generic code.
>
> It's a massive exercise OTOH when the operating system is VMS.
>
> Also, don't forget VMS requires more from the underlying architecture
> in terms of page protection/multiple rings than Linux does.

For the Integrity port HP developed a set of code called SWIS (for 
SoftWare Interrupt Services) which abstracts things like IPL levels so 
they're no longer hardware-dependent.

0
Keith
7/31/2014 5:56:54 PM
In article <a77faa16-50a2-441e-afd2-9937ea2468c0@googlegroups.com>, Bob
Gezelter <gezelter@rlgsc.com> writes: 

> "Under the agreement, VSI will license OpenVMS operating system source code=
>  from HP to expand the OpenVMS product roadmap, by adding new hardware plat=
> form releases, beginning with a new version of OpenVMS for HP Integrity i4 =
> servers based on Poulson, Intel=AE Itanium=AE Processor 9500 Series (rx2800=
> i4, BL8xxi4). In the future, VSI will support other hardware platforms, inc=
> luding X86-based servers. ..."

Let me get in on what will probably be the longest thread ever in
comp.os.vms at the beginning with what I think are some essential things 
which need to be done in conjunction with this.  Justification, if 
necessary, will come later.

Get back to building the best compilers in the world.  An OS needs 
applications, and applications are developed with compilers.  Remember 
when VAX FORTRAN was the gold standard?  Now, Fortran on VMS is far from 
the newest Fortran version, but it should be possible to catch up.  
Ditto for other languages.

Get a decent web browser.  As long as one needs another system for 
essential stuff, VMS will never be the desktop-to-datacenter (which I 
assume is your new motto) it should be.

Take steps to get some younger people committed to this project.  The 
old and wise won't be with us for that much longer.

Talk to the Rdb folks and ensure a future for Rdb as well.

Continue the hobbyist license programme.

Provide easy patch access for hobbyists.

Come up with a sensible commercial-license system.

0
helbig
7/31/2014 6:01:01 PM
On 7/31/2014 11:54 AM, JF Mezei wrote:

> If VMS Software really does bring back the real engineering team

You'll like this, JF: the VSI announcement says "VSI has assembled an 
onshore team of veteran OpenVMS developers, many harking back to the 
core DEC team responsible for the technical excellence that has been the 
hallmark of OpenVMS."

0
Keith
7/31/2014 6:01:07 PM
In article <53da823f$0$1260$c3e8da3$b1356c67@news.astraweb.com>,
	JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> On 14-07-31 13:13, Bob Gezelter wrote:
> 
>> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>> The full article is available at:
>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
> 
> 
> Great news on the surface, But...
> 
> Seals the deal in terms of HP no longer interested in VMS. (point of no
> return on its decision to abandon VMS development) But then, it opens up
> VMS to people who appear to be interested in VMS.
> 
> The roadmap indicates intentions to go X86. I guess that should fill a
> full afternoon of work for Hoff :-)
> 
> This is good news.
> 
> <devil advocate mode>
> Or it could simply mean a short term boost in VMS followed by a decline
> and abandonment, as happened with RSX/RSTE when it was offloaded.
> </devil advocate>

Ummm...   RSX, RT-11 and RSTS/E lasted another 18 or 19 years after
Mentec took them over.  That might even be longer than DEC had them.

> 
> If they pull off the port to x86, it may give VMS enough of a boost to
> come back to life.
> 
> I get the feeling from the roadmap that the guys know what needs to be
> done. It is good to see VMS in gands of people who know about VMS'
> strengths and weaknesses and what needs fixed.
> 
> I wish Nemonix/VMS Software great success. Quite a challenge, but might
> be very rewarding.

And people think I am a naysayer.  :-)

> 
> 
> 
> Can we speculate on who the experts will be ?

It will be interesting to see what this does to HP's stock.  Assuming,
of course, that there is an actual announcement to the financial community.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
7/31/2014 6:03:57 PM
Well... definitely wow

0
Alessandro
7/31/2014 6:13:26 PM
On 2014-07-31 17:54:43 +0000, JF Mezei said:

> OK, so maybe it will take Hoff 2 afternoons to do the job. He can 
> choose 2 rainy days so as to not impair his golfing :-)

I don't golf, I'm not affiliated with VMS Software, Inc., and any 
x86-64 port will require far longer than two days.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
7/31/2014 6:14:21 PM

http://www.vmssoftware.com/news/announcement/RM/
0
Hein
7/31/2014 6:19:28 PM
In article <36eb27c6-30d8-4a7b-9c58-bf5b09cd2cac@googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>
>
>http://www.vmssoftware.com/news/announcement/RM/

Hallelujah!  I can now remove my VMS black arm band!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
7/31/2014 6:25:17 PM
On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
wrote:
> On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
>> From the Marketplace article:
>>
>> "Under the agreement, VSI will license OpenVMS operating system source
>> code from HP to expand the OpenVMS product roadmap, by adding new
>> hardware platform releases, beginning with a new version of OpenVMS for
>> HP Integrity i4 servers based on Poulson, Intel® Itanium® Processor
>> 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other
>> hardware platforms, including X86-based servers. ..."
>>
>> The full article is available at:
>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>
> One further thought (and one which future business critical sales
> prospects will ask):
>
> 	Will VSI be large enough to sue when things go wrong ?

From the VSI roadmap:

"Customers who want to have HP provide v8.next support can do so directly
through HP"

And having recently looked at some risk control stuff the question might
not be "Are they big enough to sue?" but "Can they satisfy an insurance
company that the risk is insurable at an affordable price?"

-- 
BitLocker tip: At boot time, Windows assumes you have a US keyboard.
You do know how to enter your BitLocker password on one of those, don't you?
0
Paul
7/31/2014 6:31:19 PM
In article <00AE9053.B6C2DF01@SendSpamHere.ORG>, VAXman- 
@SendSpamHere.ORG writes: 

> In article <36eb27c6-30d8-4a7b-9c58-bf5b09cd2cac@googlegroups.com>,
> > Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes: 
> >
> >
> >http://www.vmssoftware.com/news/announcement/RM/
> 
> Hallelujah!  I can now remove my VMS black arm band!

I'm still waiting for the 20-year-old Brigitte Bardot and Agnetha 
F�ltskog to tell me to get off the phone and come back to bed.  If it 
doesn't happen, maybe I can convince myself that this is not a dream!

Listening to the conference call now.  Asked three questions: compilers, 
Rdb, hobbyist.  Positive answers on all three counts.

I met Sue when I made a pilgrimage to Nashua (and Hoff, and Steve 
Lionel, and Andy Goldstein), so I recognized Sue's voice, but it was 
interesting to hear the voices of Hein, Kerry, Bob etc.  :-)

The website almost works in Mozilla on VMS.  :-|

http://www.vmssoftware.com/news/announcement/RM/

First Poulson, then Kittson, then X86.

No official word on personnel, but "no-one would surprise you", "more 
than you expect" and "we are hiring".

0
helbig
7/31/2014 6:47:02 PM
In article <lre13h$6g1$1@dont-email.me>, Stephen Hoffman
<seaohveh@hoffmanlabs.invalid> writes: 

> I don't golf, I'm not affiliated with VMS Software, Inc., and any 
> x86-64 port will require far longer than two days.

Maybe you could be affiliated if you wanted to be, I don't know.

If I were calling the shots, I would make you and Steve Lionel an offer 
you couldn't refuse.  :-)

On another note, the conference call indicates that there are many
serious VMS folks, hobbyist and others, who don't post in comp.os.vms
(though some might read it).

0
helbig
7/31/2014 6:57:00 PM
Paul Sture wrote 2014-07-31 20:31:
> On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> wrote:
>> On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
>>>  From the Marketplace article:
>>>
>>> "Under the agreement, VSI will license OpenVMS operating system source
>>> code from HP to expand the OpenVMS product roadmap, by adding new
>>> hardware platform releases, beginning with a new version of OpenVMS for
>>> HP Integrity i4 servers based on Poulson, Intel® Itanium® Processor
>>> 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other
>>> hardware platforms, including X86-based servers. ..."
>>>
>>> The full article is available at:
>>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>>
>> One further thought (and one which future business critical sales
>> prospects will ask):
>>
>> 	Will VSI be large enough to sue when things go wrong ?
>
>  From the VSI roadmap:
>
> "Customers who want to have HP provide v8.next support can do so directly
> through HP"
>
> And having recently looked at some risk control stuff the question might
> not be "Are they big enough to sue?" but "Can they satisfy an insurance
> company that the risk is insurable at an affordable price?"
>

The remaining key factory for success will be, (paying) customers.

The next weeks/months will be a busy time trying to build up
confidence in this project. This is a critical time. Will it
be enough to convince the VMS customers?

As I understand, all customers on 8.4 and lower versions will
keep paying to HP. VSI must deliver a 8.next, *and* convincing
customers to upgrade, to begin getting any income, right?

*Any* operation will survive as long as there are paying customers.

Interesting, anyway. I never believed in an open source solution
(either that HP would do that or that the open source "world" would
know what to do with it), but this is of course slightly different.


Jan-Erik.
0
Jan
7/31/2014 6:57:47 PM
On 7/31/14, 1:47 PM, Phillip Helbig---undress to reply wrote:

> The website almost works in Mozilla on VMS.  :-|
>
> http://www.vmssoftware.com/news/announcement/RM/
>
> First Poulson, then Kittson, then X86.

I understood it to be first Poulson, then start x86 development lasting
roughly 24 months targeting (at least formally) HP x86_64 servers.
Support of Kittson depends on when and whether HP releases Integrity
servers running Kittson, so I don't think the sequencing/timing of
Kittson support can really be specific yet.

> No official word on personnel, but "no-one would surprise you", "more
> than you expect" and "we are hiring".

Clair Grant's name was mentioned, which certainly gives me hope that
People Who Know Things are involved. The roadmap is a little thin and
lacks detail, but having major new releases on it is sure a quantum leap
over having nothing on it.

0
Craig
7/31/2014 7:38:15 PM
In article <lre3j9$rn5$1@news.albasani.net>, Jan-Erik Soderholm
<jan-erik.soderholm@telia.com> writes: 

> The remaining key factory for success will be, (paying) customers.

Indeed.

> The next weeks/months will be a busy time trying to build up
> confidence in this project. This is a critical time. Will it
> be enough to convince the VMS customers?

Hopefully at least enough of them.  Which raises the question: Will this 
new company do some aggressive marketing to try to win back customers 
who are in the process of leaving?

> As I understand, all customers on 8.4 and lower versions will
> keep paying to HP. VSI must deliver a 8.next, *and* convincing
> customers to upgrade, to begin getting any income, right?

That's the way I understood it as well.

> Interesting, anyway. I never believed in an open source solution
> (either that HP would do that or that the open source "world" would
> know what to do with it), but this is of course slightly different.

I don't see how this has anything at all to do with open source.  They 
have licensed the source code for the Itanium platform and the right to 
port to X86.  No Alpha.  No VAX.

0
helbig
7/31/2014 7:44:12 PM
In article <7NwCv.96773$LF1.35324@fx03.iad>, Shark8
<OneWingedShark@gmail.com> writes: 

> On 31-Jul-14 12:01, Phillip Helbig---undress to reply wrote:
> > Get back to building the best compilers in the world.  An OS needs
> > applications, and applications are developed with compilers.
> 
> *Bingo!*
> Not only this, but they /need/ to be done w/ formal-methods so that the 
> compiler is *provably* free of error -- once that is done, there isn't 
> any such thing as a compiler bug.

As Knuth said, I have only mathematically proven that the code is
bug-free.  But be careful: I have not yet tested it.

Of course, users find bugs.  I never found a bug in the VAX Fortran 
compiler (mature when I started using it), but did find some in the 
Alpha Fortran90 and Fortran95 compilers, which were quickly fixed.  One 
needs active users developing new code with new features.

0
helbig
7/31/2014 7:46:22 PM
As I understood it, the new company will have nothing to do with ALPHA.

Big Question: Will a mixed-architecture cluster with ALPHA and X86 be 
supported, at least for migration?  I suspect that I am not the only 
person who would like to go from Alpha to X86 without having to go 
through Itanium.

0
helbig
7/31/2014 7:50:22 PM
It would be nice if the new company set up an easy way for people to 
invest small sums in it (say, $1000 or so).

0
helbig
7/31/2014 7:50:55 PM
In article <lre2v6$b5i$1@online.de>, helbig@astro.multiCLOTHESvax.de
(Phillip Helbig---undress to reply) writes: 

> I met Sue when I made a pilgrimage to Nashua (and Hoff, and Steve 
> Lionel, and Andy Goldstein), so I recognized Sue's voice, but it was 
> interesting to hear the voices of Hein, Kerry, Bob etc.  :-)

And Brian.  Happy Birthday!

0
helbig
7/31/2014 8:00:54 PM
Phillip Helbig---undress to reply wrote 2014-07-31 21:44:
> In article <lre3j9$rn5$1@news.albasani.net>, Jan-Erik Soderholm
> <jan-erik.soderholm@telia.com> writes:
>
>> The remaining key factory for success will be, (paying) customers.
>
> Indeed.
>
>> The next weeks/months will be a busy time trying to build up
>> confidence in this project. This is a critical time. Will it
>> be enough to convince the VMS customers?
>
> Hopefully at least enough of them.  Which raises the question: Will this
> new company do some aggressive marketing to try to win back customers
> who are in the process of leaving?
>
>> As I understand, all customers on 8.4 and lower versions will
>> keep paying to HP. VSI must deliver a 8.next, *and* convincing
>> customers to upgrade, to begin getting any income, right?
>
> That's the way I understood it as well.
>
>> Interesting, anyway. I never believed in an open source solution
>> (either that HP would do that or that the open source "world" would
>> know what to do with it), but this is of course slightly different.
>
> I don't see how this has anything at all to do with open source.  They
> have licensed the source code for the Itanium platform and the right to
> port to X86.  No Alpha.  No VAX.
>

I ment that this is way different then to open source VMS.
Todays announcement has nothing to do with open source...

Clearer? :-)

Jan-Erik.
0
Jan
7/31/2014 8:36:53 PM
On 7/31/2014 3:50 PM, Phillip Helbig---undress to reply wrote:
> It would be nice if the new company set up an easy way for people to
> invest small sums in it (say, $1000 or so).
>
They may not need it.  I don't know, but in this day and age, it seems 
like if they needed it we would have heard about a Kick Starter type of 
thing if they needed.  I am hoping that they will have some form of 
revenue sharing with HP in the short term and that HP will be required 
to honor the right to upgrade many of us have.

-- 

Thomas Wirt
Operations Manager, IS Dept.
Kittle's Home Furnishings
Indianapolis, IN
0
Thomas
7/31/2014 8:41:49 PM
In article <53DAAA0D.5060408@kittles.com>, Thomas Wirt
<twnews@kittles.com> writes: 

> On 7/31/2014 3:50 PM, Phillip Helbig---undress to reply wrote:
> > It would be nice if the new company set up an easy way for people to
> > invest small sums in it (say, $1000 or so).
> >
> They may not need it.  I don't know, but in this day and age, it seems 
> like if they needed it we would have heard about a Kick Starter type of 
> thing if they needed.  

There was a venture capitalist mentioned during the conference call.

Hopefully, if they move to x86, as seems to be the plan, then, at least 
eventually, they will support more than just HP x86 servers.  The last 
thing we need is to be tied to a particular vendor.  And, no, "works but 
not supported" is not good enough.

0
helbig
7/31/2014 8:50:34 PM
On 7/31/2014 2:57 PM, Jan-Erik Soderholm wrote:
> Paul Sture wrote 2014-07-31 20:31:
>> On 2014-07-31, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> wrote:
>>> On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
>>>>  From the Marketplace article:
>>>>
>>>> "Under the agreement, VSI will license OpenVMS operating system source
>>>> code from HP to expand the OpenVMS product roadmap, by adding new
>>>> hardware platform releases, beginning with a new version of OpenVMS for
>>>> HP Integrity i4 servers based on Poulson, Intel® Itanium® Processor
>>>> 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other
>>>> hardware platforms, including X86-based servers. ..."
>>>>
>>>> The full article is available at:
>>>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>>>>
>>>
>>> One further thought (and one which future business critical sales
>>> prospects will ask):
>>>
>>>     Will VSI be large enough to sue when things go wrong ?
>>
>>  From the VSI roadmap:
>>
>> "Customers who want to have HP provide v8.next support can do so directly
>> through HP"

>  <snip>>>
>
> The remaining key factory for success will be, (paying) customers.
>
> The next weeks/months will be a busy time trying to build up
> confidence in this project. This is a critical time. Will it
> be enough to convince the VMS customers?
>
> As I understand, all customers on 8.4 and lower versions will
> keep paying to HP. VSI must deliver a 8.next, *and* convincing
> customers to upgrade, to begin getting any income, right?

I expect my right to upgrade (on my current architecture) to be honored. 
  It is up to HP and VSI to figure out how to share my support payments 
to honor the contract many of us have.  I am guessing they have thought 
about this and have an agreement which is a part of the expected funding 
for VSI.  After all, this is licensed by HP.  They can't take VSI's 
money and my money and pretend they are unrelated.  Someone with a 
larger contract than me would make sure of that.

I feel pretty confident that my right to upgrade will continue at least 
until they remove it from the contract.  If they do that and do not 
reduce the price, then I will certainly look at switching to VSI for 
support.  I don't think it will come to this.  HP did not license this 
for love of VMS.  They did for the $$$.  They need a smooth transition.
>
> *Any* operation will survive as long as there are paying customers.
>
<snip>
>
> Jan-Erik.


-- 

Thomas Wirt
Operations Manager, IS Dept.
Kittle's Home Furnishings
Indianapolis, IN
0
Thomas
7/31/2014 8:51:51 PM
I almost forgot, WOW!  This is great news!

On 7/31/2014 4:51 PM, Thomas Wirt wrote:
> On 7/31/2014 2:57 PM, Jan-Erik Soderholm wrote:
>> Paul Sture wrote 2014-07-31 20:31:
>>> On 2014-07-31, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>>> wrote:
>>>> On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
>>>>>  From the Marketplace article:
>>>>>
>>>>> "Under the agreement, VSI will license OpenVMS operating system source
>>>>> code from HP to expand the OpenVMS product roadmap, by adding new
>>>>> hardware platform releases, beginning with a new version of OpenVMS
>>>>> for
>>>>> HP Integrity i4 servers based on Poulson, Intel® Itanium® Processor
>>>>> 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other
>>>>> hardware platforms, including X86-based servers. ..."
>>>>>
>>>>> The full article is available at:
>>>>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>>>>>
>>>>>
>>>>
>>>> One further thought (and one which future business critical sales
>>>> prospects will ask):
>>>>
>>>>     Will VSI be large enough to sue when things go wrong ?
>>>
>>>  From the VSI roadmap:
>>>
>>> "Customers who want to have HP provide v8.next support can do so
>>> directly
>>> through HP"
>
>>  <snip>>>
>>
>> The remaining key factory for success will be, (paying) customers.
>>
>> The next weeks/months will be a busy time trying to build up
>> confidence in this project. This is a critical time. Will it
>> be enough to convince the VMS customers?
>>
>> As I understand, all customers on 8.4 and lower versions will
>> keep paying to HP. VSI must deliver a 8.next, *and* convincing
>> customers to upgrade, to begin getting any income, right?
>
> I expect my right to upgrade (on my current architecture) to be honored.
>   It is up to HP and VSI to figure out how to share my support payments
> to honor the contract many of us have.  I am guessing they have thought
> about this and have an agreement which is a part of the expected funding
> for VSI.  After all, this is licensed by HP.  They can't take VSI's
> money and my money and pretend they are unrelated.  Someone with a
> larger contract than me would make sure of that.
>
> I feel pretty confident that my right to upgrade will continue at least
> until they remove it from the contract.  If they do that and do not
> reduce the price, then I will certainly look at switching to VSI for
> support.  I don't think it will come to this.  HP did not license this
> for love of VMS.  They did for the $$$.  They need a smooth transition.
>>
>> *Any* operation will survive as long as there are paying customers.
>>
> <snip>
>>
>> Jan-Erik.
>
>


-- 

Thomas Wirt
Operations Manager, IS Dept.
Kittle's Home Furnishings
Indianapolis, IN
0
Thomas
7/31/2014 8:53:06 PM
Wow.

Whom do you send resumes to?
0
moroney
7/31/2014 8:55:39 PM
On Thursday, July 31, 2014 4:55:39 PM UTC-4, Michael Moroney wrote:
> Wow. Whom do you send resumes to?

Those that expressed interest in my effort to keep OpenVMS alive will be fo=
rwarded to VSI.  I was contacted by over 30 people with resume's attached. =
 I have contacted VSI and indicated that these would be forwarded.  Once I =
hear back, I will update this note.

Dan
0
abrsvc
7/31/2014 8:58:50 PM
On 2014-07-31 19:44:12 +0000, Phillip Helbig---undress to reply said:

> In article <lre3j9$rn5$1@news.albasani.net>, Jan-Erik Soderholm
> 
>> The next weeks/months will be a busy time trying to build up confidence 
>> in this project. This is a critical time. Will it be enough to convince 
>> the VMS customers?
> 
> Hopefully at least enough of them.  Which raises the question: Will 
> this  new company do some aggressive marketing to try to win back 
> customers  who are in the process of leaving?

In the most practical of terms, there is little that VSI can point to 
here, pending the availability of a V8.next Poulson beta.

If past history is any guide, most VMS sites won't be rushing to 
install even the V8.next release, once that's available.  This barring 
some specific incentives, of course.

Beyond getting Poulson and V8.next out the door — they'd be foolish to 
call that first release of theirs V8.4-1H1, too, but I digress — there 
is a shed-load of work waiting here, too.

A massive, ginormous, whacking great, shed-load of work.

There'll undoubtedly be various marketing materials released prior to 
that beta, including those three marketing-related publications that 
Sue Skonetski mentioned, updates to the VSI web site, the boot camp, 
and likely also additional materials and brochures.  Sue's been 
unusually quiet for a while now, but that won't last.  :-)

>> Interesting, anyway. I never believed in an open source solution 
>> (either that HP would do that or that the open source "world" would 
>> know what to do with it), but this is of course slightly different.
> 
> I don't see how this has anything at all to do with open source.  They 
> have licensed the source code for the Itanium platform and the right to 
> port to X86.  No Alpha.  No VAX.

Among other details, open-sourcing of VMS itself means that VSI could 
then choose to integrate certain additional open-source software into 
the distribution.  This was an anathema in years past and for various 
reasons, of course.  Integrating additional open source packages means 
that other stuff can then depend on the presence of those packages, too 
— this simplifies a whole bunch of the packaging and testing, and it 
means that layered products can assume the pieces and parts are present 
and go use that software.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
7/31/2014 9:05:24 PM
On 7/31/2014 5:05 PM, Stephen Hoffman wrote:
> On 2014-07-31 19:44:12 +0000, Phillip Helbig---undress to reply said:
>
>> In article <lre3j9$rn5$1@news.albasani.net>, Jan-Erik Soderholm
>>
>>> The next weeks/months will be a busy time trying to build up
>>> confidence in this project. This is a critical time. Will it be
>>> enough to convince the VMS customers?
>>
>> Hopefully at least enough of them.  Which raises the question: Will
>> this  new company do some aggressive marketing to try to win back
>> customers  who are in the process of leaving?
>
> In the most practical of terms, there is little that VSI can point to
> here, pending the availability of a V8.next Poulson beta.

Agreed, but there are lots of us still using VMS that were getting 
dangerously close to being forced to address the End of Life in 2020. 
That is no longer a conversation I must have with president of my 
company or my auditors.  There is no longer a set EOL!  So yes this may 
not attract any new customers in the next 2 years, but it should slow 
the bleeding dramatically!

Like me, many of the posters here have control or a strong influence on 
what OS is used for mission critical processes.  We love VMS and we 
choose it (for very rational reasons).  In another year or 2 that would 
have been a difficult decision to justify.  We would need a 5 year plan 
to transition to keep our professional reputation.  Now, that is off the 
table.

Lets stop the bleeding today and start to grow next year or the year after!

I am not saying you were disagreeing with this, just saying lets 
remember this.
>
> If past history is any guide, most VMS sites won't be rushing to install
> even the V8.next release, once that's available.  This barring some
> specific incentives, of course.
>
> Beyond getting Poulson and V8.next out the door — they'd be foolish to
> call that first release of theirs V8.4-1H1, too, but I digress — there
> is a shed-load of work waiting here, too.
>
> A massive, ginormous, whacking great, shed-load of work.
>
> There'll undoubtedly be various marketing materials released prior to
> that beta, including those three marketing-related publications that Sue
> Skonetski mentioned, updates to the VSI web site, the boot camp, and
> likely also additional materials and brochures.  Sue's been unusually
> quiet for a while now, but that won't last.  :-)
>
>>> Interesting, anyway. I never believed in an open source solution
>>> (either that HP would do that or that the open source "world" would
>>> know what to do with it), but this is of course slightly different.
>>
>> I don't see how this has anything at all to do with open source.  They
>> have licensed the source code for the Itanium platform and the right
>> to port to X86.  No Alpha.  No VAX.
>
> Among other details, open-sourcing of VMS itself means that VSI could
> then choose to integrate certain additional open-source software into
> the distribution.  This was an anathema in years past and for various
> reasons, of course.  Integrating additional open source packages means
> that other stuff can then depend on the presence of those packages, too
> — this simplifies a whole bunch of the packaging and testing, and it
> means that layered products can assume the pieces and parts are present
> and go use that software.
>
>


-- 

Thomas Wirt
Operations Manager, IS Dept.
Kittle's Home Furnishings
Indianapolis, IN
0
Thomas
7/31/2014 9:38:39 PM
I was on the conf call, but time ran out before they got to my questions. There is obviously a lot of detail that needs to be looked at and digested.

However I'd say that for VMS, the outlook going forward is a whole lot better today than yesterday, and I think I'll take what's left of the day to enjoy the moment.

Well done to all involved for making it happen.

$ exit 13492
0
Alex_nospam_Daniels
7/31/2014 10:15:49 PM
A key point for CEO's and CIO's is having confidence that VSI will deliver as promised.  One key influence on this is money.  What's the financing of VSI and is it solid?

Is it all from venture capitalists?  Is HP providing some funding in exchange for VSI's support for Integrity?
0
mcleanjoh
7/31/2014 10:16:59 PM
On 2014-07-31, Paul Sture <nospam@sture.ch> wrote:
> On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> wrote:
>>
>> One further thought (and one which future business critical sales
>> prospects will ask):
>>
>> 	Will VSI be large enough to sue when things go wrong ?
>
> From the VSI roadmap:
>
> "Customers who want to have HP provide v8.next support can do so directly
> through HP"
>

That's interesting Paul, thanks. I didn't realise that.

Even as a small customer, I would be very nervous about having to
get VMS support through an unknown outfit. Obtaining that support
through HP removes those concerns.

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
7/31/2014 10:17:49 PM
On Thursday, 31 July 2014 23:17:49 UTC+1, Simon Clubley  wrote:
> On 2014-07-31, Paul Sture <nospam@sture.ch> wrote:
> 
> > On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
> 
> > wrote:
> 
> >>
> 
> >> One further thought (and one which future business critical sales
> 
> >> prospects will ask):
> 
> >>
> 
> >> 	Will VSI be large enough to sue when things go wrong ?
> 
> >
> 
> > From the VSI roadmap:
> 
> >
> 
> > "Customers who want to have HP provide v8.next support can do so directly
> 
> > through HP"
> 
> >
> 
> 
> 
> That's interesting Paul, thanks. I didn't realise that.
> 
> 
> 
> Even as a small customer, I would be very nervous about having to
> 
> get VMS support through an unknown outfit. Obtaining that support
> 
> through HP removes those concerns.
> 
> 
> 
> Thanks,
> 
> 
> 
> Simon.
> 
> 
> 
> -- 
> 
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> 
> Microsoft: Bringing you 1980s technology to a 21st century world

"Even as a small customer, I would be very nervous about having to
get VMS support through an unknown outfit. Obtaining that support
through HP removes those concerns."

I understand entirely where you're coming from, and where the legal
department's comfort zone is, but reality says the statement makes
little or no sense in the current picture. 

1) Without the involvement of the "unknown outfit", the future of VMS
as defined by HP was clearly very limited. That seems to have improved.

2) Although the average corporate manager outside or even inside HP may
not have heard of Nemonix, Sue Skonetski, and other names still to be
revealed (e.g. members of VMS Engineering), the well-informed VMS
audience will be aware of these names and the heritage that comes with
them. Size isn't everything. Sometimes it's helpful, sometimes not.

Interesting times.

Very best of luck to all concerned.

John Wallace
0
johnwallace4
7/31/2014 10:36:58 PM
On 8/1/2014 1:13 AM, Bob Gezelter wrote:
>  From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source

code from HP to expand the OpenVMS product roadmap, by adding new hardware

platform releases, beginning with a new version of OpenVMS for HP Integrity

i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series

(rx2800i4, BL8xxi4). In the future, VSI will support other hardware

platforms, including X86-based servers. ..."
>
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer

-of-future-versions-of-openvms-operating-system-2014-07-31
>
> - Bob Gezelter, http://www.rlgsc.com
>
You Bewdy!!!

Disbelief! You wouldn't fool an old man would ya?

Still no IPsec :-)

Web site is crap and do you have more than $2 capitol?

Who's gonna dust off John Reagan?

"You'll never get old, and you'll never ever die"

Cheers Richard Maher

USE SOME NEWSREADER THAT LINEBREAKS!!!!!
0
Richard
7/31/2014 10:39:32 PM
In article <lre79m$980$7@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
>In article <lre2v6$b5i$1@online.de>, helbig@astro.multiCLOTHESvax.de
>(Phillip Helbig---undress to reply) writes: 
>
>> I met Sue when I made a pilgrimage to Nashua (and Hoff, and Steve 
>> Lionel, and Andy Goldstein), so I recognized Sue's voice, but it was 
>> interesting to hear the voices of Hein, Kerry, Bob etc.  :-)
>
>And Brian.  Happy Birthday!

Thanks!  And, what a wonderful present too!!!
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
7/31/2014 10:44:04 PM
On 2014-07-31, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <7NwCv.96773$LF1.35324@fx03.iad>, Shark8
><OneWingedShark@gmail.com> writes: 
>
>> On 31-Jul-14 12:01, Phillip Helbig---undress to reply wrote:
>> > Get back to building the best compilers in the world.  An OS needs
>> > applications, and applications are developed with compilers.
>> 
>> *Bingo!*
>> Not only this, but they /need/ to be done w/ formal-methods so that the 
>> compiler is *provably* free of error -- once that is done, there isn't 
>> any such thing as a compiler bug.
>
> As Knuth said, I have only mathematically proven that the code is
> bug-free.  But be careful: I have not yet tested it.
>

Thank you Phillip; I seem to be reminding people of Knuth quite a bit
recently. I freely admit I don't have any real formal methods experience,
but every time I come across it, there's always some assumptions which
are made which have the potential to be great big invalidators.

For example, how do you know the specification the formal proof is
based on is correct ? Or how do you know there are not some surprises
waiting for you in the underlying hardware the formally proved
program runs on ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
7/31/2014 10:45:37 PM
Press articles here:

http://www.theregister.co.uk/2014/07/31/openvms_spared/

The one above is available for comment on.

And.. http://www.computerworld.com/s/article/9250087/HP_gives_OpenVMS_new_life
0
Alex_nospam_Daniels
7/31/2014 11:12:40 PM
On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:

> 
> Who's gonna dust off John Reagan?
> 
> 

Do I get to pick?  VAXman in a french maid's outfit? :) :)

0
John
7/31/2014 11:24:22 PM
In article <095764bf-89b3-4476-8952-94b2cfb48619@googlegroups.com>, John Reagan <xyzzy1959@gmail.com> writes:
>On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
>
>> 
>> Who's gonna dust off John Reagan?
>> 
>> 
>
>Do I get to pick?  VAXman in a french maid's outfit? :) :)

ROTFLMFAO!

I can guarantee you that that WON'T be a pretty sight! 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/1/2014 12:07:47 AM
On Saturday, August 2, 2014 8:39:05 AM UTC+10, David Froble wrote:

>=20
> Why HP would want to retain the Alpha (or VAX) versions, I have no idea.=
=20
>   As soon as the x86 port is ready, all those old systems become boat=20
> anchors.  I can build some nice AMD based systems for under $500.  Why=20
> wouldn't everyone go that route?

HP probably gets a decent income stream from VMS on Alpha and VMS on Integr=
ity.  When you're a company HP's size you don't just look at the projected =
income over the next 12 months but over the next 5 years and that future wa=
sn't looking so rosy.  Two reasons - (a) general industry movement to Linux=
 and (b) HP's support for other operating systems.

Personally I'm thinking that HP is having some (minor? major?) financial is=
sues at the moment regards costs of Integrity and the mistaken purchase of =
the UK accounting software (Attunity??).

0
mcleanjoh
8/1/2014 1:01:01 AM
Jan-Erik Soderholm wrote:
> Paul Sture wrote 2014-07-31 20:31:
>> On 2014-07-31, Simon Clubley 
>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> wrote:
>>> On 2014-07-31, Bob Gezelter <gezelter@rlgsc.com> wrote:
>>>>  From the Marketplace article:
>>>>
>>>> "Under the agreement, VSI will license OpenVMS operating system source
>>>> code from HP to expand the OpenVMS product roadmap, by adding new
>>>> hardware platform releases, beginning with a new version of OpenVMS for
>>>> HP Integrity i4 servers based on Poulson, Intel® Itanium® Processor
>>>> 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other
>>>> hardware platforms, including X86-based servers. ..."
>>>>
>>>> The full article is available at:
>>>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31 
>>>>
>>>
>>> One further thought (and one which future business critical sales
>>> prospects will ask):
>>>
>>>     Will VSI be large enough to sue when things go wrong ?
>>
>>  From the VSI roadmap:
>>
>> "Customers who want to have HP provide v8.next support can do so directly
>> through HP"
>>
>> And having recently looked at some risk control stuff the question might
>> not be "Are they big enough to sue?" but "Can they satisfy an insurance
>> company that the risk is insurable at an affordable price?"
>>
> 
> The remaining key factory for success will be, (paying) customers.
> 
> The next weeks/months will be a busy time trying to build up
> confidence in this project. This is a critical time. Will it
> be enough to convince the VMS customers?
> 
> As I understand, all customers on 8.4 and lower versions will
> keep paying to HP. VSI must deliver a 8.next, *and* convincing
> customers to upgrade, to begin getting any income, right?
> 
> *Any* operation will survive as long as there are paying customers.
> 
> Interesting, anyway. I never believed in an open source solution
> (either that HP would do that or that the open source "world" would
> know what to do with it), but this is of course slightly different.
> 
> 
> Jan-Erik.

Well, a key issue is believing in the product (VMS).  HP didn't.  We all 
know where VMS was headed under HP.

I don't know what details have been specified, but, if I was involved, 
I'd almost immediately come out with a VMS V8.5, even if the changes are 
only the version number.  That would give VSI a product.

My understanding is that there was two entities bidding for VMS, HP got 
a chunk of change from the winner, and HP didn't want to give up the 
revenue stream from V8.4 and prior.  Kind of disgusting, wanting to milk 
the cash cow, while starving it.  But, hey, it's HP.  Expected.

For now, not much to be done for VAX and Alpha, but that could change in 
the future.  Unless it was prohibited, VSI maybe could issue new 
versions for those platforms also, should they see some potential 
profits in doing so.  Again, even if it's just a new version number.

Now, if VMS users wanted to support the new company, moving to their new 
release as quickly as possible and paying VSI for support contracts 
would be a good idea, in my opinion anyway.

They will most likely have to kiss HP's ass for a while until they get 
on their feet, and perhaps even get some benefits from being associated 
with HP, now and in the future.

If VSI can pull off the port to x86, then current customers can see 
their way to an unlimited future, with respect to the sinking of the 
itanic.  I really doubt there are many current customers who had any 
reasonable chance at porting off VMS, so, there is a rather captive 
customer base, which if handled well could pretty much make this whole 
thing actually work.

I haven't been asked, but my suggestion would be to treat VMS similar to 
what Red Hat does.  The OS license is at no cost, but to use it 
commercially a customer must maintain a support contract.  An ongoing 
revenue stream is so much better than a one time sale.  Usually comes 
out of a different budget too, so no problem in getting a purchase 
approval.  And of course continue with the free non-commercial 
(hobbyist) licenses also.

As for Simon's question about "large enough to sue", personally, I'd 
tell such to then go find some product that deserves being sued.  I'm 
pretty sure that few if any of the current customers will worry about 
this issue.  If the OS is successful, then it probably will attract 
enough "good" customers, without needing those who'd rather sue than 
succeed.

Yeah, a great announcement, and at 3:00 AM I'm still to pumped to get to 
sleep.  :-)

My birthday too Brian, you don't get all of the cake ....
0
David
8/1/2014 1:01:01 AM
Phillip Helbig---undress to reply wrote:
> In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
> mcleanjoh@gmail.com writes: 
> 
>> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
>>
>>> For now, not much to be done for VAX and Alpha, but that could change in 
>>> the future.  Unless it was prohibited, VSI maybe could issue new 
>>> versions for those platforms also, should they see some potential 
>>> profits in doing so.  Again, even if it's just a new version number.
>> David,
>>
>> I have a source who has a source (etc) ... and I've been told the VSI
>> agreement does NOT include VMS on Alpha, which means there'll be no
>> back-porting of enhancements. 
> 
> Right.  This was mentioned during the conference call.
> 

Yes, I heard that also.  But I'd like to see the details of the 
agreement, assuming they will be available, to see what is specifically 
prohibited.

Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
as they already have plenty to do, sidetracks such as VAX and Alpha 
would not be very helpful, at least right now.

One question I'd have is, in addition to the IS-64 V8.4 sources and 
build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
V7.3 sources and build tools are included in the deal, then it would be 
possible, if not likely, that they could do something there.  If the 
sources and tools are not available, then it's basically the same thing 
we were looking at if HP didn't make sources available for anything 
else, stake through the heart.

I have no idea what VSI asked HP to provide.  If I was involved, I'd 
attempt to get everything, just in case, and it really wouldn't cost HP 
any more.  Or, HP could have asked for additional money, and why throw 
extra money into what really isn't part of the game plan?

Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 
  As soon as the x86 port is ready, all those old systems become boat 
anchors.  I can build some nice AMD based systems for under $500.  Why 
wouldn't everyone go that route?
0
David
8/1/2014 1:01:01 AM
On 2014-07-31, John Reagan <xyzzy1959@gmail.com> wrote:
> On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
>
>> 
>> Who's gonna dust off John Reagan? 
>
> Do I get to pick?  VAXman in a french maid's outfit? :) :)
>

Don't forget to have a camera ready!

:-)

-- 
BitLocker tip: At boot time, Windows assumes you have a US keyboard.
You do know how to enter your BitLocker password on one of those, don't you?
0
Paul
8/1/2014 2:01:14 AM
On 7/31/2014 6:24 PM, John Reagan wrote:
> On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
>
>>
>> Who's gonna dust off John Reagan?
>>
>>
>
> Do I get to pick?  VAXman in a french maid's outfit? :) :)

Do you know how much it costs to replace LK series keyboards these days?


0
John
8/1/2014 2:04:12 AM
On Friday, August 1, 2014 7:24:22 AM UTC+8, John Reagan wrote:
> On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
> 
> 
> 
> > 
> 
> > Who's gonna dust off John Reagan?
> 
> > 
> 
> > 
> 
> 
> 
> Do I get to pick?  VAXman in a french maid's outfit? :) :)

Stop it please! You just can't un-see stuff like that :-(

BTW. Can someone (anyone who knows) please confirm this story???

The "source" seems to be a dicky publicity agent, the story mentions (VSI)as if it were a stock reference but VSI refers to the Vitamin Shop, and the web-site was knocked up in 1/2 an hour.

Please, Please say it's true?
0
maherrj
8/1/2014 2:39:36 AM
On Thursday, July 31, 2014 3:50:22 PM UTC-4, Phillip Helbig---undress to reply wrote:
> As I understood it, the new company will have nothing to do with ALPHA.
> 
> 
> 
> Big Question: Will a mixed-architecture cluster with ALPHA and X86 be 
> 
> supported, at least for migration?  I suspect that I am not the only 
> 
> person who would like to go from Alpha to X86 without having to go 
> 
> through Itanium.

I was thinking along the same lines.

We stopped get operating system updates just before the one that can run on both Alpha and Itanium.  That was a blunder.  If I understand correctly, it will cost us to a boat load to upgrade now.

We also use some 3rd party software that never made it to Itanium.
0
tadamsmar
8/1/2014 2:45:34 AM
On Thursday, July 31, 2014 10:39:36 PM UTC-4, mah...@googlemail.com wrote:
> On Friday, August 1, 2014 7:24:22 AM UTC+8, John Reagan wrote:
> 
> > On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
> 
> > 
> 
> > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > > Who's gonna dust off John Reagan?
> 
> > 
> 
> > > 
> 
> > 
> 
> > > 
> 
> > 
> 
> > 
> 
> > 
> 
> > Do I get to pick?  VAXman in a french maid's outfit? :) :)
> 
> 
> 
> Stop it please! You just can't un-see stuff like that :-(
> 
> 
> 
> BTW. Can someone (anyone who knows) please confirm this story???
> 
> 
> 
> The "source" seems to be a dicky publicity agent, the story mentions (VSI)as if it were a stock reference but VSI refers to the Vitamin Shop, and the web-site was knocked up in 1/2 an hour.
> 
> 
> 
> Please, Please say it's true?

Yeah, the website is just a picture of the mythical Phoenix.

It seems to be a start-up.
0
tadamsmar
8/1/2014 2:55:48 AM
On 2014-08-01 02:55:48 +0000, tadamsmar said:

> Yeah, the website is just a picture of the mythical Phoenix.

The site is clearly not ready yet.

Of what is known posted there, there's the VSI OpenVMS roadmap: 
<http://www.vmssoftware.com/news/announcement/RM/>



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/1/2014 3:21:08 AM
In article <lregj8$774$2@speranza.aioe.org>, Richard Maher
<maher_rjSPAMLESS@hotmail.com> writes: 

> USE SOME NEWSREADER THAT LINEBREAKS!!!!!

Yes, couldn't agree more.  However, your post has too many line breaks, 
i.e. an empty line between each non-empty line.

0
helbig
8/1/2014 4:48:04 AM
In article <095764bf-89b3-4476-8952-94b2cfb48619@googlegroups.com>, John
Reagan <xyzzy1959@gmail.com> writes: 

> On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
> 
> > Who's gonna dust off John Reagan?
> 
> Do I get to pick?  VAXman in a french maid's outfit? :) :)

What about vice-versa?

0
helbig
8/1/2014 4:49:39 AM
In article <3336924f-dc5d-42ae-b1c4-37a8c3d92bfe@googlegroups.com>,
maherrj@googlemail.com writes: 

> BTW. Can someone (anyone who knows) please confirm this story???
> 
> The "source" seems to be a dicky publicity agent, the story mentions (VSI)as if it were a stock reference but VSI refers to the Vitamin Shop, and the web-site was knocked up in 1/2 an hour.
> 
> Please, Please say it's true?

Yes, it is true.  Brigitte and Agnetha didn't tell me to get off the 
phone and come back to bed, so I assume, for now at least, that the 
conference call wasn't a dream.  The audio of the conference call should 
be up on the VSI website (vmssoftware.com); not sure if questions and 
answers will be included.

0
helbig
8/1/2014 4:51:20 AM
In article <c9066581-eca7-4ce5-8107-bb21b83a1cc9@googlegroups.com>,
tadamsmar <tadamsmar@yahoo.com> writes: 

> Yeah, the website is just a picture of the mythical Phoenix.
> 
> It seems to be a start-up.

There is not much on the website, but add /news to the URL and you can 
see a bit more.

0
helbig
8/1/2014 4:52:47 AM
On Friday, August 1, 2014 12:49:39 AM UTC-4, Phillip Helbig---undress to reply wrote:
> In article <095764bf-89b3-4476-8952-94b2cfb48619@googlegroups.com>, John
> 
> Reagan <xyzzy1959@gmail.com> writes: 
> 
> > On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
> > 
> > > Who's gonna dust off John Reagan?
> > 
> > Do I get to pick?  VAXman in a french maid's outfit? :) :)
> 
> What about vice-versa?

A french maid with a pony tail who likes Guinness and can write Macro-32 code?
0
John
8/1/2014 5:20:34 AM
On Thursday, July 31, 2014 11:21:08 PM UTC-4, Stephen Hoffman wrote:
> On 2014-08-01 02:55:48 +0000, tadamsmar said:
> 
> 
> 
> > Yeah, the website is just a picture of the mythical Phoenix.
> 
> 
> 
> The site is clearly not ready yet.
> 
> 
> 
> Of what is known posted there, there's the VSI OpenVMS roadmap: 
> 
> <http://www.vmssoftware.com/news/announcement/RM/>
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Pure Personal Opinion | HoffmanLabs LLC
Hoff,

I mentioned the problem to Sue earlier. The URL in the article (http://www.vmssoftware.com/news/announcement/RM/# ) does work.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/1/2014 5:33:29 AM
On Thursday, July 31, 2014 10:39:36 PM UTC-4, mah...@googlemail.com wrote:
> On Friday, August 1, 2014 7:24:22 AM UTC+8, John Reagan wrote:
>=20
> > On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > > Who's gonna dust off John Reagan?
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> > >=20
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > Do I get to pick?  VAXman in a french maid's outfit? :) :)
>=20
>=20
>=20
> Stop it please! You just can't un-see stuff like that :-(
>=20
>=20
>=20
> BTW. Can someone (anyone who knows) please confirm this story???
>=20
>=20
>=20
> The "source" seems to be a dicky publicity agent, the story mentions (VSI=
)as if it were a stock reference but VSI refers to the Vitamin Shop, and th=
e web-site was knocked up in 1/2 an hour.
>=20
>=20
>=20
> Please, Please say it's true?

Cocoon,

The reports are essentially correct. Reading between the lines, the VSI ref=
erence was the acronym, not a stock symbol. I do not have detailed inside i=
nformation, but the mention of a "Venture Capital" firm would indicate that=
 VSI is not publicly-held. This means, in US capital markets, that ownershi=
p is limited and the potential for outside investors is almost non-existent=
..

For those not familiar with US capital markets, being publicly traded would=
 unleash a very large body of financial compliance tasks. At this point, it=
 is far better to expend funds on product than on financial compliance.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/1/2014 5:43:21 AM
On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:

> For now, not much to be done for VAX and Alpha, but that could change in 
> the future.  Unless it was prohibited, VSI maybe could issue new 
> versions for those platforms also, should they see some potential 
> profits in doing so.  Again, even if it's just a new version number.

David,

I have a source who has a source (etc) ... and I've been told the VSI agreement does NOT include VMS on Alpha, which means there'll be no back-porting of enhancements.

Some might think that HP's being greedy but I guess HP has to get something out of the deal, more than just some support for Integrity and a part of the revenue stream for customers who prefer to deal with HP. 

0
mcleanjoh
8/1/2014 8:31:16 AM
On 2014-08-01, John Reagan <xyzzy1959@gmail.com> wrote:
> On Friday, August 1, 2014 12:49:39 AM UTC-4,
> Phillip Helbig---undress to reply wrote:
>> In article <095764bf-89b3-4476-8952-94b2cfb48619@googlegroups.com>, John
>> 
>> Reagan <xyzzy1959@gmail.com> writes: 
>> 
>> > On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
>> > 
>> > > Who's gonna dust off John Reagan?
>> > 
>> > Do I get to pick?  VAXman in a french maid's outfit? :) :)
>> 
>> What about vice-versa?
>
> A french maid with a pony tail who likes Guinness and can write Macro-32
> code?

I used to work with her!

OK, I'm lying about the Macro-32, but she was a whizz with EDT and RUNOFF

:-)

-- 
BitLocker tip: At boot time, Windows assumes you have a US keyboard.
You do know how to enter your BitLocker password on one of those, don't you?
0
Paul
8/1/2014 9:45:49 AM
> Agreed, but there are lots of us still using VMS that were getting danger=
ously close to being forced to address the End of Life in 2020. That is no =
longer a conversation I must have with president of my company or my audito=
rs. There is no longer a set EOL! So yes this may not attract any new custo=
mers in the next 2 years, but it should slow the bleeding dramatically! Lik=
e me, many of the posters here have control or a strong influence on what O=
S is used for mission critical processes. We love VMS and we choose it (for=
 very rational reasons). In another year or 2 that would have been a diffic=
ult decision to justify. We would need a 5 year plan to transition to keep =
our professional reputation. Now, that is off the table. Lets stop the blee=
ding today and start to grow next year or the year after! <

As of this morning two VMS exit projects here at work (a conversion to Linu=
x and another to SAP) have been put on hold indefinitely. :)




0
cazzer69
8/1/2014 10:12:04 AM
On 2014-07-31 19:13, Bob Gezelter wrote:
>  From the Marketplace article:
>
> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>
> The full article is available at:
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31

While this is good news, I'm sortof worried by the wording, which makes 
me think of the fate of the PDP-11 software, which is still held in a 
stranglehold by HP because of a similar setup in the DEC days with Mentec...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/1/2014 10:19:13 AM
On 2014-07-31 20:03, Bill Gunshannon wrote:
> In article <53da823f$0$1260$c3e8da3$b1356c67@news.astraweb.com>,
> 	JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> On 14-07-31 13:13, Bob Gezelter wrote:
>>
>>> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>>> The full article is available at:
>>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>>
>>
>> Great news on the surface, But...
>>
>> Seals the deal in terms of HP no longer interested in VMS. (point of no
>> return on its decision to abandon VMS development) But then, it opens up
>> VMS to people who appear to be interested in VMS.
>>
>> The roadmap indicates intentions to go X86. I guess that should fill a
>> full afternoon of work for Hoff :-)
>>
>> This is good news.
>>
>> <devil advocate mode>
>> Or it could simply mean a short term boost in VMS followed by a decline
>> and abandonment, as happened with RSX/RSTE when it was offloaded.
>> </devil advocate>
>
> Ummm...   RSX, RT-11 and RSTS/E lasted another 18 or 19 years after
> Mentec took them over.  That might even be longer than DEC had them.

It's only 20 years this year since Mentec took them over. And Mentec's 
been dead a few years, so no, it wasn't anywhere close to 18-19 years. 
Last RSX release was in 1999, five years after Mentec took over.
(Could someone please get HP to release them now, I have lots of stuff 
to put into a new release of RSX...)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/1/2014 10:24:22 AM
On 2014-08-01 05:33:29 +0000, Bob Gezelter said:

> I mentioned the problem to Sue earlier. The URL in the article 
> (http://www.vmssoftware.com/news/announcement/RM/# ) does work.

There are some issues with the web site over at VSI that could imply 
they've been running rather short-handed, which isn't a huge surprise 
at this stage of VSI.  As time passes and as they pick up some more 
folks to help them, there'll undoubtedly be more collateral materials 
posted, and the existing web site directory traversal will be disabled, 
links in from the front page, etc.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/1/2014 1:32:25 PM
In article <lrdupl$3s0$2@online.de>, helbig@astro.multiCLOTHESvax.de (Phillip Helbig---undress to reply) writes:
> 
> April 1 is almost 4 months ago.

   Yeah, I had to look hard at my calendar to make sure there was ugust
   and not pril between the A and the 1.

0
koehler
8/1/2014 5:18:09 PM
In article <c3vde9FkpavU1@mid.individual.net>, bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
> 
> I never expected HP to swallow their ego and let this go.  I am not
> familiar with VSI so have no idea how big they are or what resources
> they have to carry this out.  Any chance that this is an opportunity
> for some of the big guns here to get positions as employees or sub-
> contractors to bring some of the collected knowledge and experience
> back into the corral?

   I think they already said so in thier announcements.  And I
   appreciate that there's a connection to Nmemonix.

   IMHO, that gives them lots of credibility.

0
koehler
8/1/2014 5:19:33 PM
In article <00AE9053.B6C2DF01@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> In article <36eb27c6-30d8-4a7b-9c58-bf5b09cd2cac@googlegroups.com>, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> writes:
>>
>>
>>http://www.vmssoftware.com/news/announcement/RM/
> 
> Hallelujah!  I can now remove my VMS black arm band!

   I forget.   How many decades has it been since Gartner pronounced
   VMS dead?

   I do wish VSI good luck.

0
koehler
8/1/2014 5:24:01 PM
In article <b223de3f-9359-4590-a9b2-a642241c9581@googlegroups.com>, John
Reagan <xyzzy1959@gmail.com> writes: 

> On Friday, August 1, 2014 12:49:39 AM UTC-4, Phillip Helbig---undress to reply wrote:
> > In article <095764bf-89b3-4476-8952-94b2cfb48619@googlegroups.com>, John
> > 
> > Reagan <xyzzy1959@gmail.com> writes: 
> > 
> > > On Thursday, July 31, 2014 6:39:32 PM UTC-4, Richard Maher wrote:
> > > 
> > > > Who's gonna dust off John Reagan?
> > > 
> > > Do I get to pick?  VAXman in a french maid's outfit? :) :)
> > 
> > What about vice-versa?
> 
> A french maid with a pony tail who likes Guinness and can write Macro-32 code?

Would you settle for less?

0
helbig
8/1/2014 6:35:12 PM
In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
mcleanjoh@gmail.com writes: 

> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
> 
> > For now, not much to be done for VAX and Alpha, but that could change in 
> > the future.  Unless it was prohibited, VSI maybe could issue new 
> > versions for those platforms also, should they see some potential 
> > profits in doing so.  Again, even if it's just a new version number.
> 
> David,
> 
> I have a source who has a source (etc) ... and I've been told the VSI
> agreement does NOT include VMS on Alpha, which means there'll be no
> back-porting of enhancements. 

Right.  This was mentioned during the conference call.

0
helbig
8/1/2014 6:37:40 PM
On 14-07-31 14:14, Stephen Hoffman wrote:

> I don't golf, I'm not affiliated with VMS Software, Inc., and any 
> x86-64 port will require far longer than two days.

Party Pooper !

Seems to me that any mention of VMS Software Inc bringing back
experienced VMS engineers has an implicit inclusion of our own Hoff !!!


And how do you know porting
VMS to 8086 takes longer than 2 afternoons ? Because you've already done
it ? :-)  Come on, admit it :-)
0
JF
8/1/2014 7:22:06 PM
On 14-07-31 14:47, Phillip Helbig---undress to reply wrote:

> First Poulson, then Kittson, then X86.

At a tecmical level, since Kittson is now just a speed bump of Poulson,
would any changes be required at the OS level ?

Or is this more a question of HP upgrading Itanium systems with new
peripherals when Kittson arrives and it is those peripherals that will
need changes to VMS ?


0
JF
8/1/2014 7:24:34 PM
On 14-07-31 20:07, VAXman- @SendSpamHere.ORG wrote:

>>Do I get to pick?  VAXman in a french maid's outfit? :) :)
> 
> ROTFLMFAO!
> 
> I can guarantee you that that WON'T be a pretty sight! 


Might not be pretty, but definitely a ROFL material, and huge anmount of
fun posting such pictures on the internet !

0
JF
8/1/2014 7:32:07 PM
Just received this from a buddy at IBM Canada.

http://www.vmssoftware.com/news/announcement/RM/

Check out the roadmap.

(sure hope this isn't a hoax because the VMS roadmap at the HP site still says Jan-2014)

Neil Rieck
Waterloo, Ontario, Canada.
 
0
Neil
8/1/2014 9:05:17 PM
On 8/1/2014 1:19 PM, Bob Koehler wrote:
> In article <c3vde9FkpavU1@mid.individual.net>, bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
>>
>> I never expected HP to swallow their ego and let this go.  I am not
>> familiar with VSI so have no idea how big they are or what resources
>> they have to carry this out.  Any chance that this is an opportunity
>> for some of the big guns here to get positions as employees or sub-
>> contractors to bring some of the collected knowledge and experience
>> back into the corral?
>
>     I think they already said so in thier announcements.  And I
>     appreciate that there's a connection to Nmemonix.
>
>     IMHO, that gives them lots of credibility.
>

I just hope that VMS thrives and does not wind up like RSTS/E under 
Mentec.  That basically fizzled.
0
windows
8/1/2014 9:06:48 PM
> 
> http://www.vmssoftware.com/news/announcement/RM/
> 

Now this new roadmap (from VMS Software) shows v8.next ending up on x86 which is probably a god thing since it appears to be the only game in town.

Meanwhile:

http://www.theregister.co.uk/2014/07/31/openvms_spared/

Neil Rieck
Waterloo, Ontario, Canada.
 

0
Neil
8/1/2014 9:12:02 PM
Neil Rieck wrote 2014-08-01 23:05:
> Just received this from a buddy at IBM Canada.
>
> http://www.vmssoftware.com/news/announcement/RM/
>
> Check out the roadmap.
>
> (sure hope this isn't a hoax because the VMS roadmap at the HP site still says Jan-2014)
>
> Neil Rieck
> Waterloo, Ontario, Canada.
>
>

Where have you been hiding the last couple of days? :-)

http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/openvms.aspx

ComputerWorld artikel:
http://www.computerworld.com/s/article/9250087/HP_gives_OpenVMS_new_life

TheRegister:
http://www.theregister.co.uk/2014/07/31/openvms_spared/

And yes, the *HP* readmap is still valid, for *HP*...

Jan-Erik.
0
Jan
8/1/2014 9:13:46 PM
On 2014-08-01 21:05:17 +0000, Neil Rieck said:

> Just received this from a buddy at IBM Canada.
> 
> http://www.vmssoftware.com/news/announcement/RM/
> 
> Check out the roadmap.
> 
> (sure hope this isn't a hoax because the VMS roadmap at the HP site 
> still says Jan-2014)


Yeah, that was one of the better of the inaugural "August Fools" jokes 
around the 'net, wasn't it?




-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/1/2014 9:19:11 PM
> 
> 
> Where have you been hiding the last couple of days? :-)
> 

Believe it or not, preparing for a port from Alpha to Itanium (rx2800)

Neil

0
Neil
8/1/2014 10:40:04 PM
On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:
> Phillip Helbig---undress to reply wrote:
> 
> > In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
> 
> > mcleanjoh@gmail.com writes: 
> 
> > 
> 
> >> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
> 
> >>
> 
> >>> For now, not much to be done for VAX and Alpha, but that could change in 
> 
> >>> the future.  Unless it was prohibited, VSI maybe could issue new 
> 
> >>> versions for those platforms also, should they see some potential 
> 
> >>> profits in doing so.  Again, even if it's just a new version number.
> 
> >> David,
> 
> >>
> 
> >> I have a source who has a source (etc) ... and I've been told the VSI
> 
> >> agreement does NOT include VMS on Alpha, which means there'll be no
> 
> >> back-porting of enhancements. 
> 
> > 
> 
> > Right.  This was mentioned during the conference call.
> 
> > 
> 
> 
> 
> Yes, I heard that also.  But I'd like to see the details of the 
> 
> agreement, assuming they will be available, to see what is specifically 
> 
> prohibited.
> 
> 
> 
> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
> 
> as they already have plenty to do, sidetracks such as VAX and Alpha 
> 
> would not be very helpful, at least right now.
> 
> 
> 
> One question I'd have is, in addition to the IS-64 V8.4 sources and 
> 
> build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
> 
> V7.3 sources and build tools are included in the deal, then it would be 
> 
> possible, if not likely, that they could do something there.  If the 
> 
> sources and tools are not available, then it's basically the same thing 
> 
> we were looking at if HP didn't make sources available for anything 
> 
> else, stake through the heart.
> 
> 
> 
> I have no idea what VSI asked HP to provide.  If I was involved, I'd 
> 
> attempt to get everything, just in case, and it really wouldn't cost HP 
> 
> any more.  Or, HP could have asked for additional money, and why throw 
> 
> extra money into what really isn't part of the game plan?
> 
> 
> 
> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 
> 
>   As soon as the x86 port is ready, all those old systems become boat 
> 
> anchors.  I can build some nice AMD based systems for under $500.  Why 
> 
> wouldn't everyone go that route?

"I can build some nice AMD based systems for under $500"

Agreed. 

"Why wouldn't everyone go that route? "

Everyone who wanted to run Windows or Linux (or DOS) might go that route.

But you want VMS. There may be the small matter of qualification and support, 
maybe even some specific device drivers for some specific configurations?

I would imagine that VMS will run (or at least be supported on) some subset
of HP's x86-64 range. There are some nice budget MicroServers which probably would have been great for the "one server per shop" model which used
to be used in a few chains, for example, as well as mid and high end Proliant.

But is it realistic to expect OpenVMS/x86 to run on Yee Ha's random
Taiwanese motherboard, with or without an HP badge attached?
0
johnwallace4
8/1/2014 10:50:46 PM
On Friday, 1 August 2014 23:48:27 UTC+1, mcle...@gmail.com  wrote:
> On Saturday, August 2, 2014 8:39:05 AM UTC+10, David Froble wrote:
>=20
>=20
>=20
> >=20
>=20
> > Why HP would want to retain the Alpha (or VAX) versions, I have no idea=
..=20
>=20
> >   As soon as the x86 port is ready, all those old systems become boat=
=20
>=20
> > anchors.  I can build some nice AMD based systems for under $500.  Why=
=20
>=20
> > wouldn't everyone go that route?
>=20
>=20
>=20
> HP probably gets a decent income stream from VMS on Alpha and VMS on Inte=
grity.  When you're a company HP's size you don't just look at the projecte=
d income over the next 12 months but over the next 5 years and that future =
wasn't looking so rosy.  Two reasons - (a) general industry movement to Lin=
ux and (b) HP's support for other operating systems.
>=20
>=20
>=20
> Personally I'm thinking that HP is having some (minor? major?) financial =
issues at the moment regards costs of Integrity and the mistaken purchase o=
f the UK accounting software (Attunity??).

"mistaken purchase of the UK accounting software (Attunity??)."

Autonomy is the company/product name. Accounting is what the arguments
are about. I can't explain what the product does, despite having been
following the company on and off for a number of years. I'm probably
just not management material.
0
johnwallace4
8/1/2014 10:54:34 PM
johnwallace4@yahoo.co.uk schreef op 2-aug-2014 om 0:50:
> But is it realistic to expect OpenVMS/x86 to run on Yee Ha's random
> Taiwanese motherboard, with or without an HP badge attached?

I know HP is no stranger to screwing itself, but...

  - MG

0
MG
8/2/2014 12:09:09 AM
Where's Larry???

Please say his money is in the mix! Or I suspect it'll be very expensive 
to get him on board :-(
0
Richard
8/2/2014 12:44:48 AM
johnwallace4@yahoo.co.uk wrote:
> On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:

> "I can build some nice AMD based systems for under $500"
> 
> Agreed. 
> 
> "Why wouldn't everyone go that route? "
> 
> Everyone who wanted to run Windows or Linux (or DOS) might go that route.
> 
> But you want VMS. There may be the small matter of qualification and support, 
> maybe even some specific device drivers for some specific configurations?
> 
> I would imagine that VMS will run (or at least be supported on) some subset
> of HP's x86-64 range. There are some nice budget MicroServers which probably would have been great for the "one server per shop" model which used
> to be used in a few chains, for example, as well as mid and high end Proliant.
> 
> But is it realistic to expect OpenVMS/x86 to run on Yee Ha's random
> Taiwanese motherboard, with or without an HP badge attached?

Possibly a good question.  I'm going to guess, with nothing to base the 
guess upon, that it will depend what devices you want to use.

I think it would be silly to repeat the mistakes of the past.  Look at 
what's in general use and make sure it's supported.

If you're into graphics, it could get sticky.

I'm going to guess that disk drives, tape drives, and such are not going 
to be an issue.  SCSI, S-ATA, SAS, and future stuff.

I'm more familiar with AMD targeted motherboards.  Any more, it's the 
chipsets provided by AMD.  This stuff seems to be getting rather consistent.

I'm thinking that VSI's revenues will come from support.  If so, what's 
the use in doing something to exclude certain hardware?  Isn't that a 
bit like epoxy in part of the backplane?
0
David
8/2/2014 1:01:01 AM
Stephen Hoffman wrote:
> On 2014-08-02 10:04:05 +0000, Jan-Erik Soderholm said:
> 
>> Phillip Helbig---undress to reply wrote 2014-08-02 08:37:
>>>
>>> Basically, people are still on VAX _because_ it is stable...
>>
>> I do not think so. They (can't be *that* many today) are there becuse 
>> they *have* to. I can not think of anyone (apart from some hobbyist) 
>> that would not run on modern hardware *if they could*.
>>
>> Noone professional stays on an old hardware that risks to break apart 
>> anytime with hard to get service parts.
>>
>> So people do not stay on an old VAX just becuse it is "good enough". I 
>> do not buy that...
> 
> 
> Likely correct, J-E.    VAX isn't all that stable these days, either.  
> I'm receiving questions and calls requesting assistance various 
> age-related problems with much newer Alpha systems.  Stuff of the 
> vintage of the Alpha gear that Phillip is running and variously newer, 
> too.  Alpha is getting old.  Is old.
> 
> For the commercial users that are (still) running older software and 
> older Alpha or VAX or even PDP-11 hardware configurations, there's 
> usually some sort of an evaluation process, certification or licensing 
> lock-in involved.  It's not that replacing the box is impossible, it's 
> that the box is a component of some far larger and far more complex 
> configuration or certification or licensing.
> 
> For some of these environments, even transitioning to VAX or Alpha 
> emulation can likely be an expensive and difficult effort.
> 
> Arguably, the better licensing or certification processes include 
> something akin to the old security Rating Maintenance Phase (RAMP) 
> process.   RAMP is intended to avoid the cost of a complete 
> re-evaluation when making changes to an evaluated configuration.  But if 
> there's no RAMP process, or if using the RAMP process is more expensive 
> than the cost of keeping the old gear, then the old VAX or Alpha gear 
> will usually stay.
> 
> These environments aren't a very big market, but they'll sometimes pay — 
> substantially — to keep this old gear running, as it's cheaper than 
> recertification.   (In years past, there was a vendor advertising an 
> FPGA-based VAX processor.  Basically, a "new" VAX, implementing the VAX 
> processor in an FPGA.)
> 
> For a few other environments that are still running VAX or Alpha and 
> don't have constraints around replacing that gear, they're usually not 
> spending any money beyond critical repairs on the old hardware, and any 
> additional investments are likely going toward a port.
> 
> These markets are not, however, the path forward for an operating 
> system.  It might be a profitable sideline.  Might.  But it's not a very 
> big market, and it's not a growth market.
> 
> 
> 
> 

Nor do I think Numonix needs this market explained to them ....

:-)
0
David
8/2/2014 1:01:01 AM
In article <87f7958c-025f-4b4c-badc-787413f41e02@googlegroups.com>, Neil
Rieck <n.rieck@sympatico.ca> writes: 

> Just received this from a buddy at IBM Canada.
> 
> http://www.vmssoftware.com/news/announcement/RM/

I heard that the Beatles broke up!

0
helbig
8/2/2014 6:33:15 AM
In article <lrh4oh$5m4$1@dont-email.me>, David Froble
<davef@tsoft-inc.com> writes: 

> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
> as they already have plenty to do, sidetracks such as VAX and Alpha 
> would not be very helpful, at least right now.

Basically, people are still on VAX _because_ it is stable.  Most of 
these folks don't _want_ any new features.  They have enough to do; this 
would be a waste of time.

> One question I'd have is, in addition to the IS-64 V8.4 sources and 
> build tools, what else is VSI going to get off of HP?  

Hopefully all the compilers, whether or not they are needed for VMS.  
They should also make an effort to revive Fortran on VMS.

> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 

Customers paying support.

>   As soon as the x86 port is ready, all those old systems become boat 
> anchors.  I can build some nice AMD based systems for under $500.  Why 
> wouldn't everyone go that route?

Hardware-specific applications?  Note that many people are STILL on VAX 
today, even though Alpha (and of course Itanium) are much faster.

0
helbig
8/2/2014 6:37:13 AM
On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:
> Phillip Helbig---undress to reply wrote:
> 
> > In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
> 
> > mcleanjoh@gmail.com writes: 
> 
> > 
> 
> >> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
> 
> >>
> 
> >>> For now, not much to be done for VAX and Alpha, but that could change in 
> 
> >>> the future.  Unless it was prohibited, VSI maybe could issue new 
> 
> >>> versions for those platforms also, should they see some potential 
> 
> >>> profits in doing so.  Again, even if it's just a new version number.
> 
> >> David,
> 
> >>
> 
> >> I have a source who has a source (etc) ... and I've been told the VSI
> 
> >> agreement does NOT include VMS on Alpha, which means there'll be no
> 
> >> back-porting of enhancements. 
> 
> > 
> 
> > Right.  This was mentioned during the conference call.
> 
> > 
> 
> 
> 
> Yes, I heard that also.  But I'd like to see the details of the 
> 
> agreement, assuming they will be available, to see what is specifically 
> 
> prohibited.
> 
> 
> 
> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
> 
> as they already have plenty to do, sidetracks such as VAX and Alpha 
> 
> would not be very helpful, at least right now.
> 
> 
> 
> One question I'd have is, in addition to the IS-64 V8.4 sources and 
> 
> build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
> 
> V7.3 sources and build tools are included in the deal, then it would be 
> 
> possible, if not likely, that they could do something there.  If the 
> 
> sources and tools are not available, then it's basically the same thing 
> 
> we were looking at if HP didn't make sources available for anything 
> 
> else, stake through the heart.
> 
> 
> 
> I have no idea what VSI asked HP to provide.  If I was involved, I'd 
> 
> attempt to get everything, just in case, and it really wouldn't cost HP 
> 
> any more.  Or, HP could have asked for additional money, and why throw 
> 
> extra money into what really isn't part of the game plan?
> 
> 
> 
> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 
> 
>   As soon as the x86 port is ready, all those old systems become boat 
> 
> anchors.  I can build some nice AMD based systems for under $500.  Why 
> 
> wouldn't everyone go that route?

"I can build some nice AMD based systems for under $500.  Why
wouldn't everyone go that route? "

I've listened to the con-call now. Somewhere, it was said that the
initial x86-64 targets would be some of HP's boxes. That makes some
short term sense to me. Medium term, who knows.
0
johnwallace4
8/2/2014 8:45:18 AM
Phillip Helbig---undress to reply wrote 2014-08-02 08:37:
> In article <lrh4oh$5m4$1@dont-email.me>, David Froble
> <davef@tsoft-inc.com> writes:
>
>> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and
>> as they already have plenty to do, sidetracks such as VAX and Alpha
>> would not be very helpful, at least right now.
>
> Basically, people are still on VAX _because_ it is stable...

I do not think so. They (can't be *that* many today) are there
becuse they *have* to. I can not think of anyone (apart from some
hobbyist) that would not run on modern hardware *if they could*.

Noone professional stays on an old hardware that risks to
break apart anytime with hard to get service parts.

So people do not stay on an old VAX just becuse it is
"good enough". I do not buy that...

Jan-Erik.


> Most of
> these folks don't _want_ any new features.  They have enough to do; this
> would be a waste of time.
>
>> One question I'd have is, in addition to the IS-64 V8.4 sources and
>> build tools, what else is VSI going to get off of HP?
>
> Hopefully all the compilers, whether or not they are needed for VMS.
> They should also make an effort to revive Fortran on VMS.
>
>> Why HP would want to retain the Alpha (or VAX) versions, I have no idea.
>
> Customers paying support.
>
>>    As soon as the x86 port is ready, all those old systems become boat
>> anchors.  I can build some nice AMD based systems for under $500.  Why
>> wouldn't everyone go that route?
>
> Hardware-specific applications?  Note that many people are STILL on VAX
> today, even though Alpha (and of course Itanium) are much faster.
>

0
Jan
8/2/2014 10:04:05 AM
On 2014-08-01, mcleanjoh@gmail.com <mcleanjoh@gmail.com> wrote:
>
> Personally I'm thinking that HP is having some (minor? major?) financial
> issues at the moment regards costs of Integrity and the mistaken
> purchase of the UK accounting software (Attunity??).

As John Wallace points out the purchase was of Autonomy, a UK company.
Like John, I've not managed to work out what their products do either.

But from a strategic point of view, HP might have picked up some intellectual
property and a patent or two out of the deal.  Dunno.

-- 
BitLocker tip: At boot time, Windows assumes you have a US keyboard.
You do know how to enter your BitLocker password on one of those, don't you?
0
Paul
8/2/2014 10:34:49 AM
Op donderdag 31 juli 2014 19:52:37 UTC+2 schreef Keith Parris:
> On 7/31/2014 11:13 AM, Bob Gezelter wrote:
>=20
> > "Under the agreement, VSI will license OpenVMS operating system source =
code from HP to expand the OpenVMS product roadmap, by adding new hardware =
platform releases, beginning with a new version of OpenVMS for HP Integrity=
 i4 servers based on Poulson, Intel=EF=BF=BD Itanium=EF=BF=BD Processor 950=
0 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardwar=
e platforms, including X86-based servers. ..."
>=20
>=20
>=20
> The HP announcement may be found on the HP Project Odyssey web page at=20
>=20
> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odys=
sey/=20
>=20
> under the title "HP and VMS Software, Inc. Collaborate to Extend OpenVMS=
=20
>=20
> Solutions" or via the direct link=20
>=20
> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odys=
sey/openvms.aspx

Support for the x86 may turn out to mean on a simulator and not natively su=
pported.
That aside, I'd never thaought I'd see this happen, ever.
0
Hans
8/2/2014 11:53:55 AM
Hans Vlems wrote 2014-08-02 13:53:
> Op donderdag 31 juli 2014 19:52:37 UTC+2 schreef Keith Parris:
>> On 7/31/2014 11:13 AM, Bob Gezelter wrote:
>>
>>> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>>
>>
>>
>> The HP announcement may be found on the HP Project Odyssey web page at
>>
>> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/
>>
>> under the title "HP and VMS Software, Inc. Collaborate to Extend OpenVMS
>>
>> Solutions" or via the direct link
>>
>> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odyssey/openvms.aspx
>
> Support for the x86 may turn out to mean on a simulator and not natively supported.
> That aside, I'd never thaought I'd see this happen, ever.
>

Maybe on an emulator?
And if so, and IA64 emulator?
Or an Alpha emulator with IA64 featurs backported?
But VSI should not support Alpha, right?

No, I do not belive that beeing a working route.
It has to be native x86 to make a real change from today.

Jan-Erik.

0
Jan
8/2/2014 12:02:21 PM
In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
Vlems <hvlems@freenet.de> writes: 

> Support for the x86 may turn out to mean on a simulator and not natively 
> supported.

That was certainly not my impression.  If this is the case, then VSI 
should correct this impression right away.  However, I'm pretty sure 
that this is NOT what they mean.

0
helbig
8/2/2014 12:54:51 PM
Op zaterdag 2 augustus 2014 14:02:21 UTC+2 schreef Jan-Erik Soderholm:
> Hans Vlems wrote 2014-08-02 13:53:
>=20
> > Op donderdag 31 juli 2014 19:52:37 UTC+2 schreef Keith Parris:
>=20
> >> On 7/31/2014 11:13 AM, Bob Gezelter wrote:
>=20
> >>
>=20
> >>> "Under the agreement, VSI will license OpenVMS operating system sourc=
e code from HP to expand the OpenVMS product roadmap, by adding new hardwar=
e platform releases, beginning with a new version of OpenVMS for HP Integri=
ty i4 servers based on Poulson, Intel=EF=BF=BD Itanium=EF=BF=BD Processor 9=
500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardw=
are platforms, including X86-based servers. ..."
>=20
> >>
>=20
> >>
>=20
> >>
>=20
> >> The HP announcement may be found on the HP Project Odyssey web page at
>=20
> >>
>=20
> >> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-o=
dyssey/
>=20
> >>
>=20
> >> under the title "HP and VMS Software, Inc. Collaborate to Extend OpenV=
MS
>=20
> >>
>=20
> >> Solutions" or via the direct link
>=20
> >>
>=20
> >> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-o=
dyssey/openvms.aspx
>=20
> >
>=20
> > Support for the x86 may turn out to mean on a simulator and not nativel=
y supported.
>=20
> > That aside, I'd never thaought I'd see this happen, ever.
>=20
> >
>=20
>=20
>=20
> Maybe on an emulator?
>=20
> And if so, and IA64 emulator?
>=20
> Or an Alpha emulator with IA64 featurs backported?
>=20
> But VSI should not support Alpha, right?
>=20
>=20
>=20
> No, I do not belive that beeing a working route.
>=20
> It has to be native x86 to make a real change from today.
>=20
>=20
>=20
> Jan-Erik.

I hope so too Jan Erik. A VAX or an Alpha simulator doesn't make sense, giv=
en the products that are already there. Not sure whether HP or Intel would =
like an IA64 emulator at this point in time. So with that in mind the concl=
usion that remains is x86/VMS. Perhaps they didn't mention native platform =
support is that nobody is probably sure when the money would be there to fu=
nd the project.

Hans
0
Hans
8/2/2014 12:57:30 PM
http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com
0
Slo
8/2/2014 1:04:46 PM
Slo schreef op 2-aug-2014 om 15:04:
> http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com

LOL...

  - MG

0
MG
8/2/2014 1:15:30 PM
In article <53dce475$0$4646$e4fe514c@dreader36.news.xs4all.nl>, MG
<marcogbNO@SPAMxs4all.nl> writes: 

> Slo schreef op 2-aug-2014 om 15:04:
> > http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com

Although VMS might be a bit behind the times in some respects, there are 
at least a couple of respectable WWW servers for VMS.

0
helbig
8/2/2014 1:19:58 PM
MG wrote 2014-08-02 15:15:
> Slo schreef op 2-aug-2014 om 15:04:
>> http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com
>
> LOL...
>
>   - MG
>

Right, I do not get it. It looks as a rather straigh forward
domain registration page. What is there to lol about?

Was it the date? OK, someone else have had this domain before.
Was it the platform (Linux/Apache)? Seems as a rather
standard web platform...

No, I still don't get it...

Jan-Erik.
0
Jan
8/2/2014 1:42:51 PM
In article <5a58dbcc-329d-4f71-9da1-0178d5f8d8cd@googlegroups.com>, Slo <slovuj@gmail.com> writes:
>http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com

That was one of the things I first checked when the announcement was made.
I sent a HEAD request to the server and learned it was Apache.  Then, made
a connection to the FTP port and it reported Pure-FTPd, and a connection
to the SSH server port and it reported SSH-2.0-OpenSSH_5.3.  Sure looks to
be a Linux system.

On the plus side, it's not WEENDOZE!!!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/2/2014 1:47:17 PM
On 2014-08-02 10:04:05 +0000, Jan-Erik Soderholm said:

> Phillip Helbig---undress to reply wrote 2014-08-02 08:37:
>> 
>> Basically, people are still on VAX _because_ it is stable...
> 
> I do not think so. They (can't be *that* many today) are there becuse 
> they *have* to. I can not think of anyone (apart from some hobbyist) 
> that would not run on modern hardware *if they could*.
> 
> Noone professional stays on an old hardware that risks to break apart 
> anytime with hard to get service parts.
> 
> So people do not stay on an old VAX just becuse it is "good enough". I 
> do not buy that...


Likely correct, J-E.    VAX isn't all that stable these days, either.  
I'm receiving questions and calls requesting assistance various 
age-related problems with much newer Alpha systems.  Stuff of the 
vintage of the Alpha gear that Phillip is running and variously newer, 
too.  Alpha is getting old.  Is old.

For the commercial users that are (still) running older software and 
older Alpha or VAX or even PDP-11 hardware configurations, there's 
usually some sort of an evaluation process, certification or licensing 
lock-in involved.  It's not that replacing the box is impossible, it's 
that the box is a component of some far larger and far more complex 
configuration or certification or licensing.

For some of these environments, even transitioning to VAX or Alpha 
emulation can likely be an expensive and difficult effort.

Arguably, the better licensing or certification processes include 
something akin to the old security Rating Maintenance Phase (RAMP) 
process.   RAMP is intended to avoid the cost of a complete 
re-evaluation when making changes to an evaluated configuration.  But 
if there's no RAMP process, or if using the RAMP process is more 
expensive than the cost of keeping the old gear, then the old VAX or 
Alpha gear will usually stay.

These environments aren't a very big market, but they'll sometimes pay 
— substantially — to keep this old gear running, as it's cheaper than 
recertification.   (In years past, there was a vendor advertising an 
FPGA-based VAX processor.  Basically, a "new" VAX, implementing the VAX 
processor in an FPGA.)

For a few other environments that are still running VAX or Alpha and 
don't have constraints around replacing that gear, they're usually not 
spending any money beyond critical repairs on the old hardware, and any 
additional investments are likely going toward a port.

These markets are not, however, the path forward for an operating 
system.  It might be a profitable sideline.  Might.  But it's not a 
very big market, and it's not a growth market.




-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/2/2014 2:54:15 PM
On 8/2/14, 7:54 AM, Phillip Helbig---undress to reply wrote:
> In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
> Vlems <hvlems@freenet.de> writes:
>
>> Support for the x86 may turn out to mean on a simulator and not natively
>> supported.
>
> That was certainly not my impression.  If this is the case, then VSI
> should correct this impression right away.  However, I'm pretty sure
> that this is NOT what they mean.

In the conference call someone asked whether non-HP servers would be
supported and the answer was that the target was HP hardware at least
initially and while others might work at some point there was the
question of chipsets, etc.

Someone else (I think it was Bob Gezelter) mentioned the importance of
virtualization such as running under VirtualBox or VMWare for
development, testing, inclusion in cloud portfolios, etc. I don't recall
a specific answer, but it seemed they were listening.

A different caller then asked how virtualization could work if the
console firmware is behind an HP paywall like it is now for Integrity
servers. I don't think they could say much about that at this point. It
will probably be a couple years before that enters the top 500 list of
things they need to worry about, but it was a good question.

A separate question that didn't come up is whether the EFI capabilities
of the virtualization solutions support everything needed to make an OS
think it has a ProLiant console.
0
Craig
8/2/2014 3:01:29 PM
Stephen Hoffman wrote 2014-08-02 16:54:
> On 2014-08-02 10:04:05 +0000, Jan-Erik Soderholm said:
>
>> Phillip Helbig---undress to reply wrote 2014-08-02 08:37:
>>>
>>> Basically, people are still on VAX _because_ it is stable...
>>
>> I do not think so. They (can't be *that* many today) are there becuse
>> they *have* to. I can not think of anyone (apart from some hobbyist) that
>> would not run on modern hardware *if they could*.
>>
>> Noone professional stays on an old hardware that risks to break apart
>> anytime with hard to get service parts.
>>
>> So people do not stay on an old VAX just becuse it is "good enough". I do
>> not buy that...
>
>
> Likely correct, J-E....
> ...
> ...
> For a few other environments that are still running VAX or Alpha and don't
> have constraints around replacing that gear, they're usually not spending
> any money beyond critical repairs on the old hardware, and any additional
> investments are likely going toward a port.
>

Where I work it's not that much of a "port" as a "replacement".
Maybe with something like:
http://www.ge-ip.com/products/manufacturing-software-mes/c554
but there are other packages in the same niche, MES:
http://en.wikipedia.org/wiki/Manufacturing_execution_system



Jan-Erik.

0
Jan
8/2/2014 3:18:12 PM
On 2014-08-02 15:01:29 +0000, Craig A. Berry said:

> In the conference call someone asked whether non-HP servers would be 
> supported and the answer was that the target was HP hardware at least 
> initially and while others might work at some point there was the 
> question of chipsets, etc.

We'll all have to learn the VSI business model and plans, as those are 
solidified and rolled out.

Whether VSI will be pricing licenses and support more aggressively than 
HP, too.

Also whether VSI will have support for online software license 
purchases, for that matter.

The VSI investors involved will want to see whether VSI is delivering 
on plan, and will be watching the associated profits.

All sorts of stuff is "TBD" at this stage, and VSI is on the receiving 
end of a tsunami.

I'd expect that VSI will have far more detail available by the time 
Boot Camp arrives.

Urgh.  Might have to chase the moths out of the wallet and attend that 
event this year, as there's actually new VMS stuff.  :-)

> Someone else (I think it was Bob Gezelter) mentioned the importance of 
> virtualization such as running under VirtualBox or VMWare for 
> development, testing, inclusion in cloud portfolios, etc. I don't 
> recall a specific answer, but it seemed they were listening.

It was Mr G.  More than a little x86-64 stuff are boot images, and that 
gets you out of dealing with some of the lower-level hardware details.

A unikernel design that's basically what VAX ELN provided an aeon or 
two ago would be humorous, but that's fodder for another time.

> A different caller then asked how virtualization could work if the 
> console firmware is behind an HP paywall like it is now for Integrity 
> servers. I don't think they could say much about that at this point. It 
> will probably be a couple years before that enters the top 500 list of 
> things they need to worry about, but it was a good question.

HP owns all that stuff and almost certainly did not license that to 
VSI, so that firmware will likely remain behind a paywall at HP.

HP also charges for firmware on their x86 boxes.  There were some 
MicroServer owners commenting a while back, reporting that acquiring 
newer firmware wasn't that far off purchasing a new MicroServer, IIRC.

> A separate question that didn't come up is whether the EFI capabilities 
> of the virtualization solutions support everything needed to make an OS 
> think it has a ProLiant console.

Beyond the primary bootstrap file and (though I haven't looked) 
possibly the secondary bootstrap, and a few VMS tools that can reach 
back out into that environment to verify or update boot devices or the 
clock settings or such (and that usually on user request), there's not 
all that much in VMS that "cares" about EFI.   The admonitions of one 
or two folks that post here in comp.os.vms to the contrary, EFI and the 
bootstrap was a comparatively small part of the last port of VMS.  Yes, 
the bootstrap is a pain-in-the-arse environment to program and to debug 
in, though EFI did make that process easier in some ways.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/2/2014 4:02:16 PM
On 2014-08-02 15:18:12 +0000, Jan-Erik Soderholm said:

> ...
> Where I work it's not that much of a "port" as a "replacement".
> Maybe with something like:
> http://www.ge-ip.com/products/manufacturing-software-mes/c554
> but there are other packages in the same niche, MES:
> http://en.wikipedia.org/wiki/Manufacturing_execution_system


Ayup.  FWIW, I am aware of manufacturing floor environments, process 
control, and related considerations, having worked in that environment 
for a while.   Also with what can be involved in simply communicating 
with some of the more demented devices that exist in that environment, 
though that's hopefully gotten a little saner — some of the older 
protocols were seriously bizarre.  But yes, after years of using the 
same hardware and software, manufacturing facilities can and variously 
do nuke and pave their entire environment; when a production line or an 
entire factory is overhauled or is torn down and replaced.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/2/2014 4:07:58 PM
Phillip Helbig---undress to reply wrote:
> In article <53dce475$0$4646$e4fe514c@dreader36.news.xs4all.nl>, MG
> <marcogbNO@SPAMxs4all.nl> writes: 
> 
>> Slo schreef op 2-aug-2014 om 15:04:
>>> http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com
> 
> Although VMS might be a bit behind the times in some respects, there are 
> at least a couple of respectable WWW servers for VMS.
> 

Which are most likely far from VSI's important initial issues ...

Probably the most productive course for web servers would be a contract 
with Mark Daniels for an updated version of WASD.  Or David Jones at OSU.

While visable to the outside, I seriously doubt that web server software 
is a major issue, or any issue, for those tasked with an x86 port of VMS.

Look up the definition of "focus" ....
0
David
8/2/2014 4:11:34 PM
VAXman- @SendSpamHere.ORG wrote:
> In article <5a58dbcc-329d-4f71-9da1-0178d5f8d8cd@googlegroups.com>, Slo <slovuj@gmail.com> writes:
>> http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com
> 
> That was one of the things I first checked when the announcement was made.
> I sent a HEAD request to the server and learned it was Apache.  Then, made
> a connection to the FTP port and it reported Pure-FTPd, and a connection
> to the SSH server port and it reported SSH-2.0-OpenSSH_5.3.  Sure looks to
> be a Linux system.
> 
> On the plus side, it's not WEENDOZE!!!
> 

Would it really matter to what's important, VMS on x86, if it was weendoze?
0
David
8/2/2014 4:13:26 PM
David Froble wrote 2014-08-02 18:11:
> Phillip Helbig---undress to reply wrote:
>> In article <53dce475$0$4646$e4fe514c@dreader36.news.xs4all.nl>, MG
>> <marcogbNO@SPAMxs4all.nl> writes:
>>> Slo schreef op 2-aug-2014 om 15:04:
>>>> http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com
>>
>> Although VMS might be a bit behind the times in some respects, there are
>> at least a couple of respectable WWW servers for VMS.
>>
>
> Which are most likely far from VSI's important initial issues ...
>
> Probably the most productive course for web servers would be a contract
> with Mark Daniels for an updated version of WASD...

Note that Mark has added new "web-features" to WASD often way
before they are supported by the major web browsers. Such was
the case with WebSockets:
http://wasd.vsm.com.au/wasd_root/doc/scripting/scripting_0500.html

WASD is extreamely light weight and easy to manage.
Set up and forget, start at boot and it runs until
system shutdown... :-)

Jan-Erik.



> Or David Jones at OSU.
>
> While visable to the outside, I seriously doubt that web server software is
> a major issue, or any issue, for those tasked with an x86 port of VMS.
>
> Look up the definition of "focus" ....

0
Jan
8/2/2014 4:25:28 PM
On Saturday, August 2, 2014 2:33:15 AM UTC-4, Phillip Helbig---undress to reply wrote:
> In article <87f7958c-025f-4b4c-badc-787413f41e02@googlegroups.com>, Neil
> 
> Rieck <n.rieck@sympatico.ca> writes: 
> 
> 
> 
> > Just received this from a buddy at IBM Canada.
> 
> > 
> 
> > http://www.vmssoftware.com/news/announcement/RM/
> 
> 
> 
> I heard that the Beatles broke up!

That group (IBM Canada) does "a lot" of VMS and OpenVMS system support.

NSR
0
Neil
8/2/2014 7:30:11 PM
On 14-08-02 12:02, Stephen Hoffman wrote:

> or two folks that post here in comp.os.vms to the contrary, EFI and the 
> bootstrap was a comparatively small part of the last port of VMS.  Yes, 
> the bootstrap is a pain-in-the-arse environment to program and to debug 
> in, though EFI did make that process easier in some ways.

Likmiting only to the scope of EFI for a second, would the fact that VMS
already supports EFI mean that port to UEFI X86 boxes be trivial ?

aka: does the VMS code that deals with EFI need to be changed much when
moving to x86 boxes ?
0
JF
8/2/2014 8:13:46 PM
On 2014-08-02 20:13:46 +0000, JF Mezei said:

> On 14-08-02 12:02, Stephen Hoffman wrote:
> 
>> ...EFI and the bootstrap was a comparatively small part of the last 
>> port of VMS.  Yes, the bootstrap is a pain-in-the-arse environment to 
>> program and to debug in, though EFI did make that process easier in 
>> some ways.
> 
> Likmiting only to the scope of EFI for a second, would the fact that 
> VMS already supports EFI mean that port to UEFI X86 boxes be trivial ?
> 
> aka: does the VMS code that deals with EFI need to be changed much when 
> moving to x86 boxes ?

Will existing EFI and ACPI code within VMS be reused or adapted where 
appropriate?  Sure.

The EFI console?  In the context of a VMS port?   It's a comparative molehill.

Providing the exact dimensions of the console molehill would require 
additional research.  That'll be something best left to the VSI folks 
working on the port, too.

Consoles establish the context and configuration, and load and start 
the bootstrap, and later and occasionally answer callbacks to reset the 
time or some other settings.

The primary and secondary bootstraps will be the majority of the work 
in this particular area.  That work tends to be architecture-dependent, 
and that does read whatever details the particular console has created 
and left around for the bootstrap to find and use (this is a key part 
of how Galaxy was implemented, BTW), and the primary and secondary 
bootstrap images operate in a comparatively gnarly and limited 
execution environment.

I'd generally expect a larger measure of mental sanity will be lost 
dealing with ACPI than dealing with EFI, for that matter.

Though there won't be a need to deal with instruction emulation when 
poking around in the controller ROMs, pleasantly.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/2/2014 9:11:52 PM
Jan-Erik Soderholm schreef op 2-aug-2014 om 15:42:
> No, I still don't get it...

No problem.  Weren't you retiring anyway?

  - MG

0
MG
8/2/2014 10:29:55 PM
David Froble schreef op 2-aug-2014 om 18:13:
> Would it really matter to what's important, VMS on x86, if it was weendoze?

.... Uh, what?

  - MG

0
MG
8/2/2014 10:30:33 PM
MG wrote 2014-08-03 00:30:
> David Froble schreef op 2-aug-2014 om 18:13:
>> Would it really matter to what's important, VMS on x86, if it was weendoze?
>
> ... Uh, what?
>
>   - MG
>

What he is saying is that the actual platform the VSI web server
is running os is just sooo uninteresting. I whould rather see that
they use a web server platform that quickly and efficently serves
their needs, then expecting them to force it into an VMS solution,
just for the sake of it. Then would be highly unprofessional.

I'm sorry to say that there are some on this list that acts in
such unprofessinal ways regarding popular or "standard" OS'es
for the desktop or as web servers. That does not help VMS.

Jan-Erik.


0
Jan
8/2/2014 10:57:57 PM
MG wrote 2014-08-03 00:29:
> Jan-Erik Soderholm schreef op 2-aug-2014 om 15:42:
>> No, I still don't get it...
>
> No problem.

Then please explain. What was there to LOL about regarding:
http://toolbar.netcraft.com/site_report?url=http://www.vmssoftware.com ?

I realy would like to know.

> Weren't you retiring anyway?

Not this year and probably not next.
But then, how is that connected to the netcraft page !?

Jan-Erik.

>
>   - MG
>

0
Jan
8/2/2014 11:00:49 PM
On 02-Aug-14 16:57, Jan-Erik Soderholm wrote:
> What he is saying is that the actual platform the VSI web server
> is running os is just sooo uninteresting. I whould rather see that
> they use a web server platform that quickly and efficently serves
> their needs, then expecting them to force it into an VMS solution,
> just for the sake of it. Then would be highly unprofessional.
>
> I'm sorry to say that there are some on this list that acts in
> such unprofessinal ways regarding popular or "standard" OS'es
> for the desktop or as web servers. That does not help VMS.

On the other hand, it certainly doesn't do the community any help when 
the site about X isn't using X as a solution when it [feasibly and 
easily] can.

As an example the Ada2012.org site returns the following info:
Webserver: Apache/2.2.21 FreeBSD mod_ssl/2.2.21 OpenSSL/0.9.8y DAV/2 
mod_wsgi/2.8 Python/2.7.5 PHP/5.3.8 with Suhosin-Patch

Whereas the ada-auth.org returns the following:
Webserver: RRS Ada HTTP Server

Given that the Ada 2012 site is specifically 
endorsing/touting/advocating the language (and the particular company 
backing it *has* an Ada server: Ada Web Server) do you think it really 
is "professional" to be running PHP?

It doesn't to me -- and as people here have mentioned, there do exist 
solid VMS webservers. (Now I could understand if they were small 
companies leasing webserver-servicies, but that really doesn't seem to 
be the case.)
0
Shark8
8/2/2014 11:17:52 PM
On 8/2/14, 6:17 PM, Shark8 wrote:
> It doesn't to me -- and as people here have mentioned, there do exist
> solid VMS webservers. (Now I could understand if they were small
> companies leasing webserver-servicies, but that really doesn't seem to
> be the case.)

Look again at the netcraft page. They are using a hosting company and
getting whatever web stack that company provides, as any small start-up
that is not selling web hosting should be doing. Currently VMS is a
relatively slow, expensive, and insecure option for internet-facing
applications of any kind. There is now hope that can change, but many
other more fundamental challenges need to be addressed first.
0
Craig
8/2/2014 11:41:24 PM
Jan-Erik Soderholm schreef op 3-aug-2014 om 0:57:
> What he is saying is that the actual platform the VSI web server
> is running os is just sooo uninteresting.

"Uninteresting"?  How about: Fuck you?  If you're going to be
dense, I'll keep it short.


> I'm sorry to say that there are some on this list that acts in
> such unprofessinal ways regarding popular or "standard" OS'es
> for the desktop or as web servers. That does not help VMS.

Some of us can at least spell unprofessional properly.

  - MG

0
MG
8/2/2014 11:48:47 PM
The article about VMS in The Register, "Call off the firing squad: HP grants stay of execution to OpenVMS. Startup to take over support for today's Itaniums and beyond" now has 57 comments.

Given that it sems that few if any of the comments there are made by people here, it's intersting to see what others think about VMS and VMS issues. 
0
mcleanjoh
8/3/2014 12:12:34 AM
On 14-08-03 10:30, clairgrant71@gmail.com wrote:
>We are planning to port VMS to x86 just like we ported VMS to Alpha and Itanium.


Will the work to port to x86 begin in parralel with the work to qualify
VMS for Poulson systems ? Or only once qualification for Poulson has
been done ?

How long before you have some rough estimate of when VMS on x86 will get
first boot ?  I assume there is a lot of work needed to get compilers
first ?


As I recall, VMS uses an Intel "standard" image header format for
Itanium. I assume this remains for the port to x86 ?


For the very early portions of porting, can you use an off-the-shelf x86
compiler that doesn't support VMS extensions ?  I realise the linker
likly needs to be very VMS specific though.
0
JF
8/3/2014 1:01:01 AM
On 14-08-02 17:11, Stephen Hoffman wrote:

> The primary and secondary bootstraps will be the majority of the work 
> in this particular area.  That work tends to be architecture-dependent, 
> and that does read whatever details the particular console has created 
> and left around for the bootstrap to find and use (this is a key part 
> of how Galaxy was implemented, BTW), and the primary and secondary 
> bootstrap images operate in a comparatively gnarly and limited 
> execution environment.


I was under the impression that EFI had been designed  to ease all of
that by providing a uniform interface between early OS and the devices.
Is that not the case ?

I realise that once the EFI has given the OS the list of peripherals,
and system confg, the OS then has to go and talk to them intimately and
that would obviously require new work since devices would be different.

With regards to talking to devices, VMS has had to "emulate" x86 when
talking to them.  Do drivers who have had to do that get updated to
simply remove the emulation bit, or is it simpler to rewrite them from
scratch once you are native x86 ?
0
JF
8/3/2014 1:36:14 AM
On 14-08-02 19:17, Shark8 wrote:

> On the other hand, it certainly doesn't do the community any help when 
> the site about X isn't using X as a solution when it [feasibly and 
> easily] can.


It appears the company is using a hosted web server, and web server
hosting companies use Linux/Apache.


Perhaps later on they can repatriate the web service to one of their one
boxes instead of hosting externally, at which point VMS might become the
OS that hosts it.


Yeah, i note it isn't running on VMS, but at this point, not making a
fuss about it. And if JF isn't grumbling about something, it must be
because there really is nothing to grumble about :-)
0
JF
8/3/2014 1:39:36 AM
MG wrote 2014-08-03 01:48:
> Jan-Erik Soderholm schreef op 3-aug-2014 om 0:57:
>> What he is saying is that the actual platform the VSI web server
>> is running os is just sooo uninteresting.
>
> "Uninteresting"?  How about: Fuck you?  If you're going to be
> dense, I'll keep it short.
>

I's that kind of childish behavior that does VMS more
ill then anything else. Grow up. It's like complaining
on unprofessinal vs. unprofessional. I'm sorry I have
to write in a foreign langauge.

Again, complaining *at this stage* that the VSI page is
not running from an VMS server, is only idiotic. It's
the *content* that matters (or will matter, when there
is some content).

Still no explanation about the "LOL". I thought/hoped it
was something else then the Linux/Apache notice, but
maybe I was wrong. Unfortunaly.

Best Regars,
Jan-Erik.


>
>> I'm sorry to say that there are some on this list that acts in
>> such unprofessinal ways regarding popular or "standard" OS'es
>> for the desktop or as web servers. That does not help VMS.
>
> Some of us can at least spell unprofessional properly.
>
>   - MG
>

0
Jan
8/3/2014 1:53:34 AM
JF Mezei wrote 2014-08-03 03:39:
> On 14-08-02 19:17, Shark8 wrote:
>
>> On the other hand, it certainly doesn't do the community any help when
>> the site about X isn't using X as a solution when it [feasibly and
>> easily] can.
>
>
> It appears the company is using a hosted web server, and web server
> hosting companies use Linux/Apache.
>
>
> Perhaps later on they can repatriate the web service to one of their one
> boxes instead of hosting externally, at which point VMS might become the
> OS that hosts it.
>
>
> Yeah, i note it isn't running on VMS, but at this point, not making a
> fuss about it. And if JF isn't grumbling about something, it must be
> because there really is nothing to grumble about :-)
>

Exactly. It actualy doen't matter much if this particular
company never runs their *public* web server on VMS. It's
better if they put their time on the *content* (and into
VMS itself, of course).

A weird discussion this...







0
Jan
8/3/2014 1:59:45 AM
On Sunday, August 3, 2014 11:39:36 AM UTC+10, JF Mezei wrote:
> On 14-08-02 19:17, Shark8 wrote:
> 
> It appears the company is using a hosted web server, and web server
> hosting companies use Linux/Apache.
> 
> Perhaps later on they can repatriate the web service to one of their one
> boxes instead of hosting externally, at which point VMS might become the
> OS that hosts it.
> 
> Yeah, i note it isn't running on VMS, but at this point, not making a
> fuss about it. And if JF isn't grumbling about something, it must be
> because there really is nothing to grumble about :-)

Agreed.  It's more important to have a web presence than be fussy about what o/s the host runs.

I also recall that Intel ran its plants on VMS rather than Windows despite making chips for Windows boxes.  No-one seemed to worry about whether that was a vote of no-confidence in the chips that Intel was making.

John
0
mcleanjoh
8/3/2014 2:26:36 AM
On 2014-08-03 01:36:14 +0000, JF Mezei said:


> On 14-08-02 17:11, Stephen Hoffman wrote:
> 
>> The primary and secondary bootstraps will be the majority of the work
>> in this particular area.  That work tends to be architecture-dependent,
>> and that does read whatever details the particular console has created
>> and left around for the bootstrap to find and use (this is a key part
>> of how Galaxy was implemented, BTW), and the primary and secondary
>> bootstrap images operate in a comparatively gnarly and limited
>> execution environment.
> 
> 
> I was under the impression that EFI had been designed  to ease all of
> that by providing a uniform interface between early OS and the devices.
> Is that not the case ?

If by all that you mean "better than BIOS", then yes.

EFI and EBC and related bits were intended to avoid needing 
device-specific boot drivers, and EBC was intended allow one controller 
ROM to work on both x86 and Itanium.  That byte code in place of x86 
instructions often stored in the controller ROMs of the controllers 
that needed host-accessible ROM code.

> I realise that once the EFI has given the OS the list of peripherals,
> and system confg, the OS then has to go and talk to them intimately and
> that would obviously require new work since devices would be different.

Please skim the Internals and Data Structures Manual (IDSM) for the 
full details of the VMS bootstrap.

The primary and the first part of the secondary bootstrap are concerned 
with the boot device and the console, and with getting the system 
environment ready.

Beyond the core I/O, the device configuration process happens 
relatively later along in the bootstrap.

> With regards to talking to devices, VMS has had to "emulate" x86 when
> talking to them.  Do drivers who have had to do that get updated to
> simply remove the emulation bit, or is it simpler to rewrite them from
> scratch once you are native x86 ?

I've not met a VMS device driver that emulates x86 instructions.  See 
the device driver documentation for how device drivers access the 
hardware registers, and see DQDRIVER from one of the older Freeware 
distributions for a full example, or some of the driver-related bits in 
SYS$EXAMPLES:.

In terms of a VMS port to x86-64, all of what you're focusing on here 
would be a very small part of the port.   The console has to get the 
first part of the bootstrap loaded into memory, and transfer control to 
it, and to provide that bootstrapping operating system with some 
context.  EFI just isn't all that special, and — in the scope of a VMS 
port — the effort involved here just isn't all that huge.

Again: the console — whether EFI or SRM or whatever — is not a 
significant portion of the effort involved in a port of VMS.  All 
consoles have to provide the same basic features.  In short, set up 
some data structures.  Get the bootstrap bits loaded.  Pass control to 
the bootstrap.  Answer some callbacks.  Getting the system environment 
configured for VMS and the rest is a larger part of this work, and 
that's dependent on whatever the local console is, but not on any 
particular console.  Because all consoles set up structures, load the 
bootstrap, transfer control, and answer some callbacks.




-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 2:55:14 AM
On 8/3/2014 9:59 AM, Jan-Erik Soderholm wrote:
> Exactly. It actualy doen't matter much if this particular
> company never runs their *public* web server on VMS. It's
> better if they put their time on the *content* (and into
> VMS itself, of course).

I agree.

What does matter is that it is a Mickey Mouse site hosted by Numpty.com 
and shows less provenance/pedigree than a web-site selling timeshares in 
Liberia.

Just tell me Fagin is involved in this and I'll know it's a sad joke :-(
>
> A weird discussion this...
>

I say more of a weird, or non-existent, outfit :-(

And to paraphrase an even less believable person: -

Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party!
Third-Party, 3rd-party, 3rd-party, third-party! . . . .
0
Richard
8/3/2014 2:59:23 AM
On Saturday, August 2, 2014 8:54:51 AM UTC-4, Phillip Helbig---undress to reply wrote:
> In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
> 
> Vlems <hvlems@freenet.de> writes: 
> 
> 
> 
> > Support for the x86 may turn out to mean on a simulator and not natively 
> 
> > supported.
> 
> 
> 
> That was certainly not my impression.  If this is the case, then VSI 
> 
> should correct this impression right away.  However, I'm pretty sure 
> 
> that this is NOT what they mean.

Phillip,

I pursued that question somewhat during the call. The comment was that the port was "about a 24 month" project. From history (e.g., Alpha, Itanium), that is the right time order for a native port. An emulation would be immediate.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/3/2014 3:47:57 AM
On Saturday, August 2, 2014 11:01:29 AM UTC-4, Craig A. Berry wrote:
> On 8/2/14, 7:54 AM, Phillip Helbig---undress to reply wrote:
> 
> > In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
> 
> > Vlems <hvlems@freenet.de> writes:
> 
> >
> 
> >> Support for the x86 may turn out to mean on a simulator and not natively
> 
> >> supported.
> 
> >
> 
> > That was certainly not my impression.  If this is the case, then VSI
> 
> > should correct this impression right away.  However, I'm pretty sure
> 
> > that this is NOT what they mean.
> 
> 
> 
> In the conference call someone asked whether non-HP servers would be
> 
> supported and the answer was that the target was HP hardware at least
> 
> initially and while others might work at some point there was the
> 
> question of chipsets, etc.
> 
> 
> 
> Someone else (I think it was Bob Gezelter) mentioned the importance of
> 
> virtualization such as running under VirtualBox or VMWare for
> 
> development, testing, inclusion in cloud portfolios, etc. I don't recall
> 
> a specific answer, but it seemed they were listening.
> 
> 
> 
> A different caller then asked how virtualization could work if the
> 
> console firmware is behind an HP paywall like it is now for Integrity
> 
> servers. I don't think they could say much about that at this point. It
> 
> will probably be a couple years before that enters the top 500 list of
> 
> things they need to worry about, but it was a good question.
> 
> 
> 
> A separate question that didn't come up is whether the EFI capabilities
> 
> of the virtualization solutions support everything needed to make an OS
> 
> think it has a ProLiant console.

Craig,

You remembered correctly. I did ask about Virtual Box, VMware, etc. VSI also mentioned inline translation of existing images for previous architectures (e.g., VAX, Alpha, Itanium).

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/3/2014 3:52:08 AM
MG wrote:
> David Froble schreef op 2-aug-2014 om 18:13:
>> Would it really matter to what's important, VMS on x86, if it was 
>> weendoze?
> 
> ... Uh, what?
> 
>  - MG
> 

You don't follow threads so well ??

Ok, the discussion was concerning the access to the transcript of the 
conference call ....
0
David
8/3/2014 4:32:00 AM
On 2014-08-02 04:45:18 -0400, johnwallace4@yahoo.co.uk said:

> On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:
>> 
>> 
>> Why HP would want to retain the Alpha (or VAX) versions, I have no idea.
>> 
>> As soon as the x86 port is ready, all those old systems become boat
>> 
>> anchors.  I can build some nice AMD based systems for under $500.  Why
>> 
>> wouldn't everyone go that route?
> 
> "I can build some nice AMD based systems for under $500.  Why
> wouldn't everyone go that route? "
> 
> I've listened to the con-call now. Somewhere, it was said that the
> initial x86-64 targets would be some of HP's boxes. That makes some
> short term sense to me. Medium term, who knows.

You can pick up some very nice HP DL360 1U or DL380 2U x86_64 servers 
for under $500 on EBay as long as you don't need the latest Gen7 or 
Gen8.  I got a couple DL360 Gen5's with dual Quad-core Xeon 2.26GHz and 
16GB memory for under $400 each 18-months ago and they're cheaper now.  
 They're also much quieter than the RX2620/RX2660 Integrity systems.

Assuming these types are the targets for the migration.
-- 

John H. Reinhardt

0
John
8/3/2014 5:46:14 AM
In article <lrjqdi$l22$1@news.albasani.net>, Jan-Erik Soderholm
<jan-erik.soderholm@telia.com> writes: 

> What he is saying is that the actual platform the VSI web server
> is running os is just sooo uninteresting. I whould rather see that
> they use a web server platform that quickly and efficently serves
> their needs, then expecting them to force it into an VMS solution,
> just for the sake of it. Then would be highly unprofessional.
> 
> I'm sorry to say that there are some on this list that acts in
> such unprofessinal ways regarding popular or "standard" OS'es
> for the desktop or as web servers. That does not help VMS.

OK, if they have a webcam or whatever, then it would indeed be silly to 
bend over backwards to get it to work on VMS.  But a webserver is 
something which works fine under VMS.  Why shouldn't a VMS company run 
VMS itself?

At least in the past, the Intel production line ran on VMS.  :-)

0
helbig
8/3/2014 9:58:01 AM
David Froble schreef op 3-aug-2014 om 6:32:
> You don't follow threads so well ??

/Riiiiight!/

  - MG

0
MG
8/3/2014 10:19:23 AM
Richard Maher wrote 2014-08-03 04:59:
> On 8/3/2014 9:59 AM, Jan-Erik Soderholm wrote:
>> Exactly. It actualy doen't matter much if this particular
>> company never runs their *public* web server on VMS. It's
>> better if they put their time on the *content* (and into
>> VMS itself, of course).
>
> I agree.
>
> What does matter is that it is a Mickey Mouse site hosted by Numpty.com and
> shows less provenance/pedigree than a web-site selling timeshares in Liberia.
>

Absoutely.

Thay could have spent a few hours more and at least removed those
dead links. And why not make that "news" page the main page?
They seems to have been in a extreme hurry...

(And yes, the web *platform* is totalt irrellevant, of course :-) ).

> Third-Party, 3rd-party, 3rd-party, third-party!

Yes, that will be a tough area. *Or* they will focus
on the remaining sites with only in-house built apps.

Question is if VMS ever again will attract any 3rd-part
developers, apart from those that are still on VMS today.

Jan-Erik.


0
Jan
8/3/2014 11:21:15 AM
Phillip Helbig---undress to reply wrote 2014-08-03 11:58:
> In article <lrjqdi$l22$1@news.albasani.net>, Jan-Erik Soderholm
> <jan-erik.soderholm@telia.com> writes:
>
>> What he is saying is that the actual platform the VSI web server
>> is running os is just sooo uninteresting. I whould rather see that
>> they use a web server platform that quickly and efficently serves
>> their needs, then expecting them to force it into an VMS solution,
>> just for the sake of it. Then would be highly unprofessional.
>>
>> I'm sorry to say that there are some on this list that acts in
>> such unprofessinal ways regarding popular or "standard" OS'es
>> for the desktop or as web servers. That does not help VMS.
>
> OK, if they have a webcam or whatever, then it would indeed be silly to
> bend over backwards to get it to work on VMS.  But a webserver is
> something which works fine under VMS.  Why shouldn't a VMS company run
> VMS itself?

Becuse there are better and easier to use web platforms.
And the web hosting companies rearily uses VMS.

And finaly, becuse focus should be on the *CONTENT*,
the platform is irrelevant.

>
> At least in the past, the Intel production line ran on VMS.  :-)
>

Yes, becuse *that* (factory control) was/is one area
where VMS did/does very well. I do not see what that
has to do with VSI's web platform?

Silly discussion... :-)

Jan-Erik.
0
Jan
8/3/2014 11:26:07 AM
Bob Gezelter wrote 2014-08-03 05:47:
> On Saturday, August 2, 2014 8:54:51 AM UTC-4, Phillip Helbig---undress
> to reply wrote:
>> In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>,
>> Hans
>>
>> Vlems <hvlems@freenet.de> writes:
>>
>>
>>
>>> Support for the x86 may turn out to mean on a simulator and not
>>> natively
>>
>>> supported.
>>
>>
>>
>> That was certainly not my impression.  If this is the case, then VSI
>>
>> should correct this impression right away.  However, I'm pretty sure
>>
>> that this is NOT what they mean.
>
> Phillip,
>
> I pursued that question somewhat during the call. The comment was that
> the port was "about a 24 month" project.

"Mid 2017" was also mentioned as a target for that "24 month project".
After the "6 month project" for i4 server support. Which adds up... :-)

Jan-Erik.

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

0
Jan
8/3/2014 11:29:35 AM
On 2014-08-03 05:46:14 +0000, John H. Reinhardt said:

> Assuming these [x86-64 system] types are the targets for the migration.

Ayup.   It'll be interesting to see what x86-64 systems will be supported.

Whether VMS will be tied to specific x86-64 hardware acquired from VSI 
(akin to Apple), and/or VMS on specific hardware from VSI and/or HP 
and/or other hardware OEM resellers (akin to the Mac OS 7 era Apple), 
or if VSI opens it up to a variety of OEMs akin to Microsoft, or if 
they follow the anything-that'll-boot-it model within whatever I/O and 
controller support is available

We shall learn more, including prices and availability, as VSI 
progresses.  Right now, VSI may well have not have decided that, or 
even thought much about that.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 12:59:17 PM
On 2014-08-03 11:26:07 +0000, Jan-Erik Soderholm said:

> Phillip Helbig---undress to reply wrote 2014-08-03 11:58:
>> In article <lrjqdi$l22$1@news.albasani.net>, Jan-Erik Soderholm
>> <jan-erik.soderholm@telia.com> writes:
>> 
>>> What he is saying is that the actual platform the VSI web server
>>> is running os is just sooo uninteresting. I whould rather see that
>>> they use a web server platform that quickly and efficently serves
>>> their needs, then expecting them to force it into an VMS solution,
>>> just for the sake of it. Then would be highly unprofessional.
>>> 
>>> I'm sorry to say that there are some on this list that acts in
>>> such unprofessinal ways regarding popular or "standard" OS'es
>>> for the desktop or as web servers. That does not help VMS.
>> 
>> OK, if they have a webcam or whatever, then it would indeed be silly to 
>> bend over backwards to get it to work on VMS.  But a webserver is 
>> something which works fine under VMS.  Why shouldn't a VMS company run 
>> VMS itself?

When VSI has a release or two, and has an established infrastructure 
and preferably has something that they have decided to target as a web 
platform?  Sure.

But when VSI has been out of "stealth" for ~three days?    This verges 
on trolling.

> Becuse there are better and easier to use web platforms.

Ayup.  Definitely.

Not everybody has Phillip's level of fondness for arcana and 
command-line administration and command-line troubleshooting.

Well, easier alternatives at least for now, of course.  :-)   Maybe VSI 
looks at this as a potential market, with VMS running on HP Moonshot 
<http://hp.com/go/moonshot> or such — but VSI is just getting going, 
and has been out of "stealth" for ~three days.

> And the web hosting companies rearily uses VMS.

Ayup.  Hosting companies with VMS hosting capabilities are exceedingly 
rare.   Though I've not looked for nor then priced one of these rather 
rare VMS hosting providers (IIRC, HP was offering something like 
this?), I'd expect this to be more expensive.    As compared with 
x86-64 hosting on Linux or such, I'd expect any third-party VMS hosting 
providers to be much more expensive than hosting on another platform, 
due to the license costs and server prices and the lack of integration 
with distributed management tools, too.

If you're hosting locally, you need a server, an installation, a static 
IP network connection and a network with a DMZ, and somebody to spend 
some time troubleshooting the installation and the content management 
system.   VSI will undoubtedly have this infrastructure, but they've 
been out of "stealth" for ~three days.

Or you spend a few dollars at a hosting service, and get on with 
something else.

> And finaly, becuse focus should be on the *CONTENT*, the platform is 
> irrelevant.

Ayup.  There's presently a deep-linked roadmap web page and a "coming 
soon" page out front.

Being just ~three days out of "stealth", VSI is undoubtedly busy 
preparing more content and their web content-management system.  Maybe 
that content management system runs on VMS.  Maybe not.

> 
>> At least in the past, the Intel production line ran on VMS.  :-)
> 
> Yes, becuse *that* (factory control) was/is one area where VMS did/does 
> very well. I do not see what that has to do with VSI's web platform?

Factory floor control has very little to do with web hosting, actually. 
  From a security perspective and Stuxnet aside, the factory floor is 
(usually) a whole lot less hostile network, for instance.

> Silly discussion... :-)

Though surprisingly illuminating in some ways.  Running a mix of 
servers definitely provides an overview of the strengths and weaknesses 
of the various options.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 1:45:28 PM
Since I've heard and read the "Is it an emulator?" question a few times, le=
t me set things straight. We are planning to port VMS to x86 just like we p=
orted VMS to Alpha and Itanium.

Clair Grant
Director of R&D
VMS Software Inc



On Thursday, July 31, 2014 1:13:34 PM UTC-4, Bob Gezelter wrote:
> From the Marketplace article:
>=20
>=20
>=20
> "Under the agreement, VSI will license OpenVMS operating system source co=
de from HP to expand the OpenVMS product roadmap, by adding new hardware pl=
atform releases, beginning with a new version of OpenVMS for HP Integrity i=
4 servers based on Poulson, Intel=AE Itanium=AE Processor 9500 Series (rx28=
00i4, BL8xxi4). In the future, VSI will support other hardware platforms, i=
ncluding X86-based servers. ..."
>=20
>=20
>=20
> The full article is available at:
>=20
> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-develop=
er-of-future-versions-of-openvms-operating-system-2014-07-31
>=20
>=20
>=20
> - Bob Gezelter, http://www.rlgsc.com

0
clairgrant71
8/3/2014 2:30:12 PM
On 14-08-03 08:59, Stephen Hoffman wrote:

> Whether VMS will be tied to specific x86-64 hardware acquired from VSI 
> (akin to Apple), and/or VMS on specific hardware from VSI and/or HP 


I have to assume that initially, it will be restricted to a few known
models because that is all VMS will have been qualified on and all that
VSI will be able/willing to support.

I would think that the company will not work to prevent VMS from being
loaded onto any 8086 with basic comppatibility (64 bits, UEFI, certain
disk types etc), but support would only be sold on approved hardware/VMS
combinations.

In other words, hobbyists might be able to load VMS onto any 8086, but
if you want commercial support, you will need to have specific hardware.

Should VMS prove to be a success they may then spend extra money to test
VMS on other boxes to validate and allow support over extended range of
machines.


This is where hobbysists might be valuable to VSI if they can be used to
test various hardware combos and report back on what works and doesn't work.

0
JF
8/3/2014 3:08:03 PM
On Sunday, August 3, 2014 1:46:14 AM UTC-4, John H. Reinhardt wrote:
....

> You can pick up some very nice HP DL360 1U or DL380 2U x86_64 servers 
> 
> for under $500 on EBay as long as you don't need the latest Gen7 or 
> 
> Gen8.  I got a couple DL360 Gen5's with dual Quad-core Xeon 2.26GHz and 
> 
> 16GB memory for under $400 each 18-months ago and they're cheaper now.  
> 
>  They're also much quieter than the RX2620/RX2660 Integrity systems.

Gen7 (and earlier) as well as nearly all Gen8 ProLiants use BIOS consoles, not EFI.  I assume VSI will bypass BIOS-based servers and target only EFI models, at least initially. EFI starts to show up in late Gen8 and Gen9 ProLiant servers and blades.

I failed to find a clear UEFI roadmap for ProLiant, but I did find a single model, the DL580 Gen8, that supports UEFI.  This is a $13,000 monster, not very attractive to enable a team of developers for porting work.

Aside - HP's customer-facing web pages haven't gotten any less exasperating in recent years.

  -- Robert

0
Robert
8/3/2014 3:25:48 PM
On 14-08-03 11:25, Robert Deininger wrote:

> Gen7 (and earlier) as well as nearly all Gen8 ProLiants use BIOS consoles, not EFI.

How recent are those models ? I was under the impression that the x86
industrty had completed the move to EFI for servers.


>  I assume VSI will bypass BIOS-based servers and target only EFI models, at least initially.

I would not expect them to spend time/money on BIOS support if that is
considered a dead technology if all new servers support EFI.


Of course, the big question nobody has the guts to answer: will VSI
support booting VMS on Apple computers ? :-) :-)

(it might make sense since they adhere to a narrower set of standards
and peripherals, however, as Apple no longer makes servers, it is not
really realistic to expect VMS to boot off a Mac.



0
JF
8/3/2014 3:43:54 PM
On Sunday, 3 August 2014 15:30:12 UTC+1, clairg...@gmail.com  wrote:
> Since I've heard and read the "Is it an emulator?" question a few times, =
let me set things straight. We are planning to port VMS to x86 just like we=
 ported VMS to Alpha and Itanium.
>=20
>=20
>=20
> Clair Grant
>=20
> Director of R&D
>=20
> VMS Software Inc
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On Thursday, July 31, 2014 1:13:34 PM UTC-4, Bob Gezelter wrote:
>=20
> > From the Marketplace article:
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > "Under the agreement, VSI will license OpenVMS operating system source =
code from HP to expand the OpenVMS product roadmap, by adding new hardware =
platform releases, beginning with a new version of OpenVMS for HP Integrity=
 i4 servers based on Poulson, Intel=AE Itanium=AE Processor 9500 Series (rx=
2800i4, BL8xxi4). In the future, VSI will support other hardware platforms,=
 including X86-based servers. ..."
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > The full article is available at:
>=20
> >=20
>=20
> > http://www.marketwatch.com/story/vms-software-inc-named-exclusive-devel=
oper-of-future-versions-of-openvms-operating-system-2014-07-31
>=20
> >=20
>=20
> >=20
>=20
> >=20
>=20
> > - Bob Gezelter, http://www.rlgsc.com

Thanks for the clarification. That confirms what I thought was said
on the telecon, but obviously my interpretation could have been wrong.

It would be good to have this close to the top of your pending FAQ
when you guys get a Round To It.=20

The telecon also mentioned "something like FX!32" is likely to be part
of the picture, which also could do with clarification. I won't even
try to guess what it may mean, even though I know what FX!32 was.

Thanks again, and best of luck.

Btw, for other readers unfamiliar with the name: you may wonder what
Clair Grant knows about porting OSes, and particularly VMS...

Try this, from the DTJ in 2005 (well, HP equivalent):
http://h71000.www7.hp.com/openvms/journal/v6/porting_openvms_to_integrity.p=
df
0
johnwallace4
8/3/2014 3:46:09 PM
On 2014-08-03 15:25:48 +0000, Robert Deininger said:

> On Sunday, August 3, 2014 1:46:14 AM UTC-4, John H. Reinhardt wrote:
> ...
> 
>> You can pick up some very nice HP DL360 1U or DL380 2U x86_64 servers 
>> for under $500 on EBay as long as you don't need the latest Gen7 or 
>> Gen8.  I got a couple DL360 Gen5's with dual Quad-core Xeon 2.26GHz and 
>> 16GB memory for under $400 each 18-months ago and they're cheaper now.
>> 
>> They're also much quieter than the RX2620/RX2660 Integrity systems.
> 
> Gen7 (and earlier) as well as nearly all Gen8 ProLiants use BIOS 
> consoles, not EFI.  I assume VSI will bypass BIOS-based servers and 
> target only EFI models, at least initially. EFI starts to show up in 
> late Gen8 and Gen9 ProLiant servers and blades.

Also available in various Dell servers, reportedly.

> I failed to find a clear UEFI roadmap for ProLiant, but I did find a 
> single model, the DL580 Gen8, that supports UEFI.

Probably this document: 
<http://h20195.www2.hp.com/V2/GetPDF%2Easpx%2F4AA5%2D1111ENW%2Epdf>

> This is a $13,000 monster, not very attractive to enable a team of 
> developers for porting work.

Not many HP servers have EFI / UEFI apparently, but a bunch of the HP 
laptops do have UEFI support.   Here's a list: 
<http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>

Intel Macs also have EFI support and both virtualization and 
partitioning (Boot Camp) support is available, but it seems unlikely 
that VSI would target those.

> Aside - HP's customer-facing web pages haven't gotten any less 
> exasperating in recent years.

Ayup.   Various new color schemes are filtering through the HP web 
site.   Here's a new (or new to me) color scheme: 
<http://www8.hp.com/us/en/software/enterprise-software.html>
Hitting the remaining black VMS web pages from the era of the Darth 
color scheme is still a little jarring, too.   But I digress.   If HP 
does decide to overhaul their web site, there's a decent chance that 
some of my existing links would no longer work, and that some of the 
older information would simply be removed, as happened with the 
retirement of the SOC archives.  So... somewhat on the fence about HP 
overhauling their web site.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 4:03:50 PM
On 14-08-03 11:46, johnwallace4@yahoo.co.uk wrote:

> The telecon also mentioned "something like FX!32" is likely to be part
> of the picture, which also could do with clarification. I won't even
> try to guess what it may mean, even though I know what FX!32 was.

This is a tough question from a business case point of view:

How likely is someone still on VAX and who hasn't bought anything new
for 15 years will restart to be an active customer ?

How likely is someone still on Alpha who who hasn't bought anything new
for 5-10 years will restart to be an active customer ?

Itanium customers have at least been active in the last few years when
IA64 finally outsped Alpha.

The problem is that many customers are stuck on VAX/Alpha due to
software that was not ported to IA64. A translator might allow them to
become active again.

VSI will hopefully get access to customer database of both license and
active/support customers so they can contact them to get a feel for how
many would become active again if certain features were provided.

Or perhaps they will use a "user group" philosophy to get a feel for
what the market will want.


FX!32 becomes interesting when you start to deal with floating point
because AVX/Alpha apps coded to use VAX floating point may yield
different results when FX!32 does on-the-fly conversion to IEEE and back.
0
JF
8/3/2014 4:06:10 PM
On 2014-08-03 15:46:09 +0000, johnwallace4@yahoo.co.uk said:

> The telecon also mentioned "something like FX!32" is likely to be part 
> of the picture, which also could do with clarification. I won't even 
> try to guess what it may mean, even though I know what FX!32 was.

If VSI releases something akin to FX!32 
<http://en.wikipedia.org/wiki/FX!32>, that implies application support 
features will be available that allow images for earlier architectures 
to execute on x86-64.  This involves detecting these old images 
automatically and/or requiring a separate translation step to start the 
process on these images, and then performing some combination of static 
instruction translation and/or instruction emulation and/or JIT, with 
calls from the execution environment through into the underlying VMS 
routines for performance reasons.

These calls through to the underlying operating system were a feature 
of FX!32, as there wasn't a need to emulate these Windows calls, when 
the real, native Windows calls were available.

Somewhat newer than FX!32 — and transparent to most users — was Apple's 
Rosetta <http://en.wikipedia.org/wiki/Rosetta_(software)>, though 
Rosetta was been retired at OS X 10.7.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 4:18:48 PM
On Sunday, August 3, 2014 12:03:50 PM UTC-4, Stephen Hoffman wrote:

> 
> Not many HP servers have EFI / UEFI apparently, but a bunch of the HP 
> 
> laptops do have UEFI support.   Here's a list: 
> 
> <http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>

.... from April 2009. Windows Vista SP1.  Ick.

The average service life of consumer-grade HP laptops might lead to disappointing VMS uptime. :-)
A 3-node cluster (over IP, via WiFi) might be the minimum recommended configuration.

> Intel Macs also have EFI support and both virtualization and 
> 
> partitioning (Boot Camp) support is available, but it seems unlikely 
> 
> that VSI would target those.

We can dream, can't we?

  -- Robert
0
Robert
8/3/2014 4:27:17 PM
JF Mezei wrote 2014-08-03 17:19:
> On 14-08-03 10:30, clairgrant71@gmail.com wrote:
>> We are planning to port VMS to x86 just like we ported VMS to Alpha and Itanium.
>
>
> Will the work to port to x86 begin in parralel with the work to qualify
> VMS for Poulson systems ? Or only once qualification for Poulson has
> been done ?

If you had listened to the recording, you would have heard them
saing that Poulson/i4 is prio 1 for the next 6 months. x86 is a
18 months project with possible devivery mid-2017 after that.


0
Jan
8/3/2014 4:42:22 PM
On 2014-08-03 16:27:17 +0000, Robert Deininger said:

> On Sunday, August 3, 2014 12:03:50 PM UTC-4, Stephen Hoffman wrote:
> 
>> 
>> Not many HP servers have EFI / UEFI apparently, but a bunch of the HP 
>> laptops do have UEFI support.   Here's a list:
>> 
>> <http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>
> 
> ... from April 2009. Windows Vista SP1.  Ick.


Per Redmond <http://windows.microsoft.com/en-US/windows-8/what-uefi>, 
"All 64-bit versions of PCs running Windows with a logo from the 
Windows Certification Program will use UEFI instead of BIOS."

I'd expect that the x86-64 server systems intended for Windows�Server 
2012 R2 and later will also be increasingly UEFI-based, but I don't 
immediately see a specific requirement for UEFI in any of the Microsoft 
publications.


> The average service life of consumer-grade HP laptops might lead to 
> disappointing VMS uptime. :-)
> A 3-node cluster (over IP, via WiFi) might be the minimum recommended 
> configuration.

Got completely and frustratingly lost in a maze of HP business-grade 
laptop models and variations, when last I looked at using an HP laptop 
for a project.

>> Intel Macs also have EFI support and both virtualization and 
>> partitioning (Boot Camp) support is available, but it seems unlikely 
>> that VSI would target those.
> 
> We can dream, can't we?

Ayup.  We'll see what VSI is carrying around for corporate gear, sooner 
or later.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 5:05:01 PM
On 14-08-03 12:18, Stephen Hoffman wrote:

> Somewhat newer than FX!32 � and transparent to most users � was Apple's 
> Rosetta <http://en.wikipedia.org/wiki/Rosetta_(software)>, though 
> Rosetta was been retired at OS X 10.7.

In part because the company that had produced Rosetta technology was
purchased by IBM and I have to assume that Apple's rights to the tech
would have had to have been renenotiated.

FX!32 translated x86 binaries to run on Alpha.

How much of the FX!32 code, logic  would be of value to those creating
one to run IA64 and/or Alpha and/or VAX binaries on VMS x86 ?

Is there enough tech in there to help with new translators, or are
translators so specific to architectures and OS that they are useless
when creating one for a new platform ?
0
JF
8/3/2014 5:13:15 PM
On Sunday, 3 August 2014 18:13:15 UTC+1, JF Mezei  wrote:
> On 14-08-03 12:18, Stephen Hoffman wrote:
>=20
>=20
>=20
> > Somewhat newer than FX!32 =EF=BF=BD and transparent to most users =EF=
=BF=BD was Apple's=20
>=20
> > Rosetta <http://en.wikipedia.org/wiki/Rosetta_(software)>, though=20
>=20
> > Rosetta was been retired at OS X 10.7.
>=20
>=20
>=20
> In part because the company that had produced Rosetta technology was
>=20
> purchased by IBM and I have to assume that Apple's rights to the tech
>=20
> would have had to have been renenotiated.
>=20
>=20
>=20
> FX!32 translated x86 binaries to run on Alpha.
>=20
>=20
>=20
> How much of the FX!32 code, logic  would be of value to those creating
>=20
> one to run IA64 and/or Alpha and/or VAX binaries on VMS x86 ?
>=20
>=20
>=20
> Is there enough tech in there to help with new translators, or are
>=20
> translators so specific to architectures and OS that they are useless
>=20
> when creating one for a new platform ?

FX!32 interpreted/translated, at run-time, and saved the translated
results for next time round.

I *ass*u*me* something interesting lies within FX!32, even if it's
only concepts and not code, otherwise it wouldn't have been mentioned.

At least one caller (Bob G?) in the telecon spotted that such an
approach might benefit from saving the individual pieces rather
than the whole thing as a lump (so shareable images only need
transmogrifying one time per system rather than once for each
executable that uses them). It seemed a sensible idea on the surface.

We wait and see. Well I do anyway.
0
johnwallace4
8/3/2014 6:13:51 PM
On 2014-08-02, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
> In article <87f7958c-025f-4b4c-badc-787413f41e02@googlegroups.com>, Neil
> Rieck <n.rieck@sympatico.ca> writes: 
>
>> Just received this from a buddy at IBM Canada.
>> 
>> http://www.vmssoftware.com/news/announcement/RM/
>
> I heard that the Beatles broke up!

Talking of the Beatles, this item from a couple of weeks ago might amuse:

"In the truth is stranger than fiction department, Los Angeles Councilman
Tom LaBonge, whose district includes Griffith Park, told Pop & Hiss over
the weekend that the pine tree planted in 2004 near Griffith Observatory
in memory of George Harrison will be replanted shortly because the
original tree died as the result of an insect infestation.

Yes, the George Harrison Tree was killed by beetles."

<http://www.latimes.com/entertainment/music/posts/la-et-ms-george-harrison-tree-beetles-replant-20140721-story.html>

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 6:29:23 PM
On 2014-08-02, Craig A. Berry <craigberry@nospam.mac.com> wrote:
> On 8/2/14, 6:17 PM, Shark8 wrote:
>> It doesn't to me -- and as people here have mentioned, there do exist
>> solid VMS webservers. (Now I could understand if they were small
>> companies leasing webserver-servicies, but that really doesn't seem to
>> be the case.)
>
> Look again at the netcraft page. They are using a hosting company and
> getting whatever web stack that company provides, as any small start-up
> that is not selling web hosting should be doing. Currently VMS is a
> relatively slow, expensive, and insecure option for internet-facing
> applications of any kind. There is now hope that can change, but many
> other more fundamental challenges need to be addressed first.

USD ~10 a month will get you a decent web hosting service with ssh access
included nowadays.  Contrast that to a VMS box with licensing and
maintenance costs.  At this point in time it might be one less VMS box
that could be better used for development and testing.

Looking to the future, when (if?) VSI release a production ready web
server they can support, by all means use the product as a showcase.  But
there's a ton of work to be done to get to that point.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 6:59:20 PM
On 2014-08-03, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Hosting companies with VMS hosting capabilities are exceedingly 
> rare.   Though I've not looked for nor then priced one of these rather 
> rare VMS hosting providers (IIRC, HP was offering something like 
> this?), I'd expect this to be more expensive.    As compared with 
> x86-64 hosting on Linux or such, I'd expect any third-party VMS hosting 
> providers to be much more expensive than hosting on another platform, 
> due to the license costs and server prices and the lack of integration 
> with distributed management tools, too.

Hosting services which offer a choice of Linux or Windows charge an
extra $x per month for the Windows flavour to cover the licensing costs
and Client Access Licenses (CALs) may come into the mix.  One university
offering online courses managed to chew their way through USD 20K or more
of CALs before they realised one was being assigned per unique IP address,
and of course many students were coming in from different IP addresses all
the time...

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 7:27:59 PM
On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 14-08-03 08:59, Stephen Hoffman wrote:
>
>> Whether VMS will be tied to specific x86-64 hardware acquired from VSI 
>> (akin to Apple), and/or VMS on specific hardware from VSI and/or HP 
>
>
> I have to assume that initially, it will be restricted to a few known
> models because that is all VMS will have been qualified on and all that
> VSI will be able/willing to support.
>
> I would think that the company will not work to prevent VMS from being
> loaded onto any 8086 with basic comppatibility (64 bits, UEFI, certain
> disk types etc), but support would only be sold on approved hardware/VMS
> combinations.
>
> In other words, hobbyists might be able to load VMS onto any 8086, but
> if you want commercial support, you will need to have specific hardware.
>
> Should VMS prove to be a success they may then spend extra money to test
> VMS on other boxes to validate and allow support over extended range of
> machines.
>
>
> This is where hobbysists might be valuable to VSI if they can be used to
> test various hardware combos and report back on what works and doesn't work.

Support for the standard machines as provided by VMware and VirtualBox would
be a Good Feature To Have*.  Another nice feature would be that VMS is
virtual machine aware so that it doesn't run the cores it is assigned at
100% CPU.

* Marketable too :-)

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 7:35:23 PM
On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 14-08-03 11:25, Robert Deininger wrote:
>
>> Gen7 (and earlier) as well as nearly all Gen8 ProLiants use BIOS consoles,
>> not EFI.
>
> How recent are those models ? I was under the impression that the x86
> industrty had completed the move to EFI for servers.
>
>
>>  I assume VSI will bypass BIOS-based servers and target only EFI models,
>>  at least initially.
>
> I would not expect them to spend time/money on BIOS support if that is
> considered a dead technology if all new servers support EFI.
>
>
> Of course, the big question nobody has the guts to answer: will VSI
> support booting VMS on Apple computers ? :-) :-)
>
> (it might make sense since they adhere to a narrower set of standards
> and peripherals, however, as Apple no longer makes servers, it is not
> really realistic to expect VMS to boot off a Mac.

As I have just pointed out in another post the ability to run inside a
VMware or VirtualBox environment* would be Good To Have.  That means you
could run it on a Mac or AN Other box.

* there are other environments such as Xen and KVM:

<http://www.cyberciti.biz/tips/linux-virtualization-software.html> 

plus whatever HP is offering in the future of course.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 7:43:46 PM
On 2014-08-03, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>
> Somewhat newer than FX!32 — and transparent to most users — was Apple's 
> Rosetta <http://en.wikipedia.org/wiki/Rosetta_(software)>, though 
> Rosetta was been retired at OS X 10.7.

Rosetta was developed by Transitive.  IBM bought them in 2008:

<http://www.eweek.com/c/a/Virtualization/IBM-Acquiring-Transitive-to-Increase-Virtualization-Capabilities-of-Power-Systems/>

"IBM agrees to acquire Transitive, which has developed virtualization
technology that will allow applications written for one processor and
operating system to run on a completely different platform. Transitive is
best known for software that allowed Apple Macintosh applications written
for PowerPC platforms to run on newer Intel-based Macs. Transitive also
created software that allows Solaris/SPARC applications to run on Linux
systems."

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 7:55:35 PM
On 2014-08-02, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2014-08-02 15:01:29 +0000, Craig A. Berry said:
>
>> A different caller then asked how virtualization could work if the 
>> console firmware is behind an HP paywall like it is now for Integrity 
>> servers. I don't think they could say much about that at this point. It 
>> will probably be a couple years before that enters the top 500 list of 
>> things they need to worry about, but it was a good question.
>
> HP owns all that stuff and almost certainly did not license that to 
> VSI, so that firmware will likely remain behind a paywall at HP.
>
> HP also charges for firmware on their x86 boxes.  There were some 
> MicroServer owners commenting a while back, reporting that acquiring 
> newer firmware wasn't that far off purchasing a new MicroServer, IIRC.

The MicroServers do seem to be marketed in the same fashion as printers.

The disk caddies were something like USD 80 apiece when I last looked,
which is a lot of money for a plastic frame you screw to a disk.  While
most users will find they don't need any extra ones, as soon as you start
carrying spares for quick replacement or rotating disks for backup
purposes on a regular basis you will want these caddies.

Folks in the UK have been reporting very nice cashback deals (you pay the
retailer the asking price and HP sends you a cheque) from time to time.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/3/2014 8:58:03 PM
On 8/3/2014 12:05 PM, Stephen Hoffman wrote:
> On 2014-08-03 16:27:17 +0000, Robert Deininger said:
>
>> On Sunday, August 3, 2014 12:03:50 PM UTC-4, Stephen Hoffman wrote:
>>
>>>
>>> Not many HP servers have EFI / UEFI apparently, but a bunch of the HP
>>> laptops do have UEFI support.   Here's a list:
>>>
>>> <http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>
>>
>> ... from April 2009. Windows Vista SP1.  Ick.
>
>
> Per Redmond <http://windows.microsoft.com/en-US/windows-8/what-uefi>,
> "All 64-bit versions of PCs running Windows with a logo from the Windows
> Certification Program will use UEFI instead of BIOS."
>
> I'd expect that the x86-64 server systems intended for Windows Server
> 2012 R2 and later will also be increasingly UEFI-based, but I don't
> immediately see a specific requirement for UEFI in any of the Microsoft
> publications.

The UEFI/BIOS issue is a moot point for x86 servers.

The commercial x86 server market is essentially going to being VMs on 
Hypervisors.  The ability to hot migrate from one physical chassis to 
another even in a different city with no visible downtime is one of the 
key reasons for this.

The Hypervisor can present either a BIOS or UEFI to the guest VMs.

A commercial x86 server OS must be able to run on at least VMware and 
Hyper/V and for complete coverage, it needs to run on KVM and XEN, and 
possibly a few others.

Since a new x86 server OS must be able to run under a hypervisor for the 
volume business.  And the XEN and KVM hypervisor are free, for such use, 
I would target the hypervisor presented hardware and Hypervisor APIs 
instead of bare metal.

If I only target at least 3 of the 4 major hypervisors, I can use 
hardware vendor supplied physical device drivers instead of writing VMS 
versions from scratch.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only


0
John
8/3/2014 9:23:19 PM
On Sunday, August 3, 2014 2:59:20 PM UTC-4, Paul Sture wrote:
> On 2014-08-02, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>=20
> > On 8/2/14, 6:17 PM, Shark8 wrote:
>=20
> >> It doesn't to me -- and as people here have mentioned, there do exist
>=20
> >> solid VMS webservers. (Now I could understand if they were small
>=20
> >> companies leasing webserver-servicies, but that really doesn't seem to
>=20
> >> be the case.)
>=20
> >
>=20
> > Look again at the netcraft page. They are using a hosting company and
>=20
> > getting whatever web stack that company provides, as any small start-up
>=20
> > that is not selling web hosting should be doing. Currently VMS is a
>=20
> > relatively slow, expensive, and insecure option for internet-facing
>=20
> > applications of any kind. There is now hope that can change, but many
>=20
> > other more fundamental challenges need to be addressed first.
>=20
>=20
>=20
> USD ~10 a month will get you a decent web hosting service with ssh access
>=20
> included nowadays.  Contrast that to a VMS box with licensing and
>=20
> maintenance costs.  At this point in time it might be one less VMS box
>=20
> that could be better used for development and testing.
>=20
>=20
>=20
> Looking to the future, when (if?) VSI release a production ready web
>=20
> server they can support, by all means use the product as a showcase.  But
>=20
> there's a ton of work to be done to get to that point.
>=20
>=20
>=20
> --=20
>=20
> The early bird gets the worm but the second mouse gets the cheese.
>=20
> The early mouse is now a late mouse of course.

Paul,

I agree with your comment, and Hoff's earlier comment in this vein.

VSI has come out of "stealth" mode is the past 96 hours. I have not heard t=
he precise date when the agreement was signed, but I would not be surprised=
 if it was very recently.=20

Ignoring my technical desire to see the VSI www site running on OpenVMS, us=
ing either Apache, WASD, OSU, or some assortment, I agree with the present =
state. As a businessman, in the midst of negotiating a foundational deal, w=
ithout which the venture depends, the www site and its hosting would be vir=
tually (pun unintended) the last thing on my mind.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/3/2014 9:55:36 PM
On Sunday, 3 August 2014 22:23:19 UTC+1, John E. Malmberg  wrote:
> On 8/3/2014 12:05 PM, Stephen Hoffman wrote:
> 
> > On 2014-08-03 16:27:17 +0000, Robert Deininger said:
> 
> >
> 
> >> On Sunday, August 3, 2014 12:03:50 PM UTC-4, Stephen Hoffman wrote:
> 
> >>
> 
> >>>
> 
> >>> Not many HP servers have EFI / UEFI apparently, but a bunch of the HP
> 
> >>> laptops do have UEFI support.   Here's a list:
> 
> >>>
> 
> >>> <http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>
> 
> >>
> 
> >> ... from April 2009. Windows Vista SP1.  Ick.
> 
> >
> 
> >
> 
> > Per Redmond <http://windows.microsoft.com/en-US/windows-8/what-uefi>,
> 
> > "All 64-bit versions of PCs running Windows with a logo from the Windows
> 
> > Certification Program will use UEFI instead of BIOS."
> 
> >
> 
> > I'd expect that the x86-64 server systems intended for Windows Server
> 
> > 2012 R2 and later will also be increasingly UEFI-based, but I don't
> 
> > immediately see a specific requirement for UEFI in any of the Microsoft
> 
> > publications.
> 
> 
> 
> The UEFI/BIOS issue is a moot point for x86 servers.
> 
> 
> 
> The commercial x86 server market is essentially going to being VMs on 
> 
> Hypervisors.  The ability to hot migrate from one physical chassis to 
> 
> another even in a different city with no visible downtime is one of the 
> 
> key reasons for this.
> 
> 
> 
> The Hypervisor can present either a BIOS or UEFI to the guest VMs.
> 
> 
> 
> A commercial x86 server OS must be able to run on at least VMware and 
> 
> Hyper/V and for complete coverage, it needs to run on KVM and XEN, and 
> 
> possibly a few others.
> 
> 
> 
> Since a new x86 server OS must be able to run under a hypervisor for the 
> 
> volume business.  And the XEN and KVM hypervisor are free, for such use, 
> 
> I would target the hypervisor presented hardware and Hypervisor APIs 
> 
> instead of bare metal.
> 
> 
> 
> If I only target at least 3 of the 4 major hypervisors, I can use 
> 
> hardware vendor supplied physical device drivers instead of writing VMS 
> 
> versions from scratch.
> 
> 
> 
> Regards,
> 
> -John
> 
> wb8tyw@qsl.network
> 
> Personal Opinion Only

There's an interesting discussion to have wrt hypervisors, albeit maybe
not right here right now. Specifically, does running a production OpenVMS environment under a hypervisor expose a VMS environment to an extra and
potentially unnecessary layer of quality improvement opportunities (bugs),
and if so does the value allegedly provided by the hypervisor outweigh the extra risk? There may be no universal agreement on the subject.
0
johnwallace4
8/3/2014 10:02:22 PM
On 2014-08-03 21:23:19 +0000, John E. Malmberg said:

> The UEFI/BIOS issue is a moot point for x86 servers.
> 
> The commercial x86 server market is essentially going to being VMs on 
> Hypervisors.  The ability to hot migrate from one physical chassis to 
> another even in a different city with no visible downtime is one of the 
> key reasons for this.
> 
> The Hypervisor can present either a BIOS or UEFI to the guest VMs.

Which means UEFI, as there's little point in picking BIOS over EFI 
here.  This if you're not going to provide a unikernel-like approach 
(for new applications) outright.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/3/2014 10:31:46 PM
On 8/3/2014 10:30 PM, clairgrant71@gmail.com wrote:
>
> Clair Grant
> Director of R&D
> VMS Software Inc
>
>

Well Done!!! This must've really taken some doing.


PS. Spend 200 bucks on your web-site.

PPS. IPsec is pretty much already there.

PPPS. I'm open to offers for Tier3.

0
Richard
8/3/2014 10:39:41 PM
On 8/3/2014 5:02 PM, johnwallace4@yahoo.co.uk wrote:

>
> There's an interesting discussion to have wrt hypervisors, albeit maybe
> not right here right now. Specifically, does running a production
> OpenVMS environment under a hypervisor expose a VMS environment to an
> extra and potentially unnecessary layer of quality improvement opportunities (bugs),
> and if so does the value allegedly provided by the hypervisor outweigh the extra risk?

Yes there is extra opportunity for bugs.  VMS user mode applications can 
drive hardware at higher I/O rates than other platforms and that can 
make more bugs show up.

But those bugs are common to other platforms, so there is incentive for 
the hypervisor supplier to get them fixed as soon as they are 
identified.  Usually once the bug has been demonstrated on VMS, the bug 
can be demonstrated on other platforms.

With native drivers there are even more opportunity for bugs, since the 
native VMS drivers would need to be written independently, and there 
would be less people looking at the source.

 > There may be no universal agreement on the subject.

A new x86 server OS that is not hypervisor aware is essentially DOA for 
commercial sales.  So it is a necessary layer.

Since it is necessary to support a hypervisor layer, it is not necessary 
to have the extra expense of developing to not support a hypervisor.

All existing commercial supported x86 server OSes are now hypervisor aware.

Regards,
-John

0
John
8/3/2014 10:58:54 PM
Creating a native version of VMS for X86-64 - fantastic idea. BUT  You 
need to concentrate on specific hardware and get it right on just a few 
high end systems
Just look at M$ and Linux. Stuff kinda works with some systems.
OpenVMS has always been a very robust OS. Porting it to a good high end 
high quality server like certain Proliant servers is great. Porting it 
to a generic PC is a bad bad idea.


My opinion but someone who has experienced some stuff that KINDA works 
with VMS. Not pretty and not fun.

Graphics and SCSI/SAS especially



On 8/3/2014 10:30 AM, clairgrant71@gmail.com wrote:
> Since I've heard and read the "Is it an emulator?" question a few times, let me set things straight. We are planning to port VMS to x86 just like we ported VMS to Alpha and Itanium.
>
> Clair Grant
> Director of R&D
> VMS Software Inc
>
>
>
> On Thursday, July 31, 2014 1:13:34 PM UTC-4, Bob Gezelter wrote:
>>  From the Marketplace article:
>>
>>
>>
>> "Under the agreement, VSI will license OpenVMS operating system source code from HP to expand the OpenVMS product roadmap, by adding new hardware platform releases, beginning with a new version of OpenVMS for HP Integrity i4 servers based on Poulson, Intel� Itanium� Processor 9500 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardware platforms, including X86-based servers. ..."
>>
>>
>>
>> The full article is available at:
>>
>> http://www.marketwatch.com/story/vms-software-inc-named-exclusive-developer-of-future-versions-of-openvms-operating-system-2014-07-31
>>
>>
>>
>> - Bob Gezelter, http://www.rlgsc.com
>



0
David
8/4/2014 12:14:59 AM
Robert Deininger wrote:
> On Sunday, August 3, 2014 12:03:50 PM UTC-4, Stephen Hoffman wrote:
> 
>> Not many HP servers have EFI / UEFI apparently, but a bunch of the HP 
>>
>> laptops do have UEFI support.   Here's a list: 
>>
>> <http://h10032.www1.hp.com/ctg/Manual/c01717787.pdf>
> 
> ... from April 2009. Windows Vista SP1.  Ick.
> 
> The average service life of consumer-grade HP laptops might lead to disappointing VMS uptime. :-)
> A 3-node cluster (over IP, via WiFi) might be the minimum recommended configuration.
> 
>> Intel Macs also have EFI support and both virtualization and 
>>
>> partitioning (Boot Camp) support is available, but it seems unlikely 
>>
>> that VSI would target those.
> 
> We can dream, can't we?
> 
>   -- Robert

Isn't that what many of us have been doing for some years now?

The wonder is that sometimes dreams do come true.
0
David
8/4/2014 1:01:01 AM
Jan-Erik Soderholm wrote:
> Paul Sture wrote 2014-08-04 14:21:
>> On 2014-07-31, Simon Clubley 
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2014-07-31, Paul Sture <nospam@sture.ch> wrote:
>>>> On 2014-07-31, Simon Clubley 
>>>> <clubley@remove_me.eisner.decus.org-Earth.UFP>
>>>> wrote:
>>>>>
>>>>> One further thought (and one which future business critical sales
>>>>> prospects will ask):
>>>>>
>>>>>     Will VSI be large enough to sue when things go wrong ?
>>>>
>>>>  From the VSI roadmap:
>>>>
>>>> "Customers who want to have HP provide v8.next support can do so 
>>>> directly
>>>> through HP"
>>>>
>>>
>>> That's interesting Paul, thanks. I didn't realise that.
>>>
>>> Even as a small customer, I would be very nervous about having to
>>> get VMS support through an unknown outfit. Obtaining that support
>>> through HP removes those concerns.
>>
> 
> But even so, the actual support will probably be handed
> over to VSI. HP will just be a middle man doing the
> administration of the contracts, as I understand.
> That can still be fine, of course. Easier to
> manage the contracts for the customer.

I don't know.  I've heard some horror stories from people trying to 
contract with HP for things, including support and licenses ....
0
David
8/4/2014 1:01:01 AM
In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>,
	Hans Vlems <hvlems@freenet.de> writes:
> Op donderdag 31 juli 2014 19:52:37 UTC+2 schreef Keith Parris:
>> On 7/31/2014 11:13 AM, Bob Gezelter wrote:
>>=20
>> > "Under the agreement, VSI will license OpenVMS operating system source =
> code from HP to expand the OpenVMS product roadmap, by adding new hardware =
> platform releases, beginning with a new version of OpenVMS for HP Integrity=
>  i4 servers based on Poulson, Intel=EF=BF=BD Itanium=EF=BF=BD Processor 950=
> 0 Series (rx2800i4, BL8xxi4). In the future, VSI will support other hardwar=
> e platforms, including X86-based servers. ..."
>>=20
>>=20
>>=20
>> The HP announcement may be found on the HP Project Odyssey web page at=20
>>=20
>> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odys=
> sey/=20
>>=20
>> under the title "HP and VMS Software, Inc. Collaborate to Extend OpenVMS=
> =20
>>=20
>> Solutions" or via the direct link=20
>>=20
>> http://h17007.www1.hp.com/us/en/enterprise/servers/integrity/project-odys=
> sey/openvms.aspx
> 
> Support for the x86 may turn out to mean on a simulator and not natively su=
> pported.

I certainly hope not.

> That aside, I'd never thaought I'd see this happen, ever.

Neither did I.  And everyone here thought I was the only naysayer.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 1:01:01 AM
On 14-08-04 09:47, Jan-Erik Soderholm wrote:

> That is the only way (as I see it) that makes sense.
> Why should HP build (low level) competence on post 8.4
> VMS versions? Doesn't make sense...

Why does IBM maintain competence on VMS ? Doesn't make sense, until you
realise these companies make money on support contracts and will support
anything and everything.


0
JF
8/4/2014 1:01:01 AM
She's back!

Simon,

Lets have a chat, I just read two of your messages.  One saying the port to=
 x86 could not happen and another saying would VMS Software be big enough t=
o sue.  Since this is a public forum, questions raised should be answered p=
ublicly if ethically possible.

Let me respond to both here.

1.I remember asking about VMS moving to another platform other than Alpaha =
and being told it could not be done. So much for that, it was done.  So now=
 years later with even more advanced tools and an engineering team that has=
 ported not once but twice.  You don't think it will happen, we will just h=
ave to see. But know that due diligence was done technically prior to stati=
ng our directions.  We are talking about the best VMS experts and engineers=
 on the planet.  They are the ones that wrote all 27 million lines of code.=
   Please keep in mind that is also what they told Steve Jobs and I would b=
e ok failing to the degree Apple has failed.  To the tune of billions.

2. Big enough to sue - a business that was announced four days ago.  Lets g=
et a little positive karma here.  Do you really think that the engineering =
team and even myself would  join a company we thought would fail?

Keep in mind that if folks still need a large neck to strangle, at this tim=
e you have a choice of either working with HP or with VMS Software. Your ch=
oice.
0
Susan
8/4/2014 1:01:01 AM
JF Mezei wrote:
> On 14-08-03 12:18, Stephen Hoffman wrote:
> 
>> Somewhat newer than FX!32 � and transparent to most users � was Apple's 
>> Rosetta <http://en.wikipedia.org/wiki/Rosetta_(software)>, though 
>> Rosetta was been retired at OS X 10.7.
> 
> In part because the company that had produced Rosetta technology was
> purchased by IBM and I have to assume that Apple's rights to the tech
> would have had to have been renenotiated.

Ya know, I seriously doubt that.  When you do such a deal, you consider 
future ramifications, which definitely insure you will continue to have 
the rights you negotiated if the owner of the product changes.
0
David
8/4/2014 1:01:01 AM
And you thought I would forget or might have hoped I would forget about my =
friends on comp.os.vms

Not sure if anyone remembers me or not.  But I have the honor of being part=
 of the VMS Software Company.

There are so many comments and questions.  I am trying to figure out how to=
 answer them all.=20

You know what this means?  You will have a VP that reads comp.os.vms

There is also a facebook page (very active), twitter, linkedin group and of=
 course my favorite, email.

My email and that for every one will be first name. surname @vmssoftware.co=
m

my first name is Sue.

Folks do you remember we would talk about this and it was pretty much a dre=
am.  And now its real.  And do you remember me saying that I would never gi=
ve up on VMS as long as there was a customer left.  Well, I am sorry it too=
k so long But we have a good team in place with names you know.

I can honestly say that this has been the best work week in the last five y=
ears maybe my whole work life.

Warm Regards,
Sue
0
Susan
8/4/2014 1:04:51 AM
Hi JF how nice to hear you.

let me address some of the questions.

You do not need to speculate who the experts are, you know them already.

Nemonix and VMS Software are two different companies, just a couple of us w=
orked at Nemonix and now moved on to VMS Software Inc.  Nemonix does hardwa=
re for VAX and Alpha.  We do VMS only, we will have an engineering group, S=
ALES group, R&D, Sustaining, QTV and Customer Advocacy.

So on the Customer Advocacy side I can tell you the following.
Newsletter will be coming
Social Media (Facebook, linkedin and Twitter)
Blog
And most of the stuff you are used to.

Hey JF maybe another trip to Canada would be fun??

Warm Regards,
Sue

0
Susan
8/4/2014 1:12:37 AM
Please keep in mind that the public roadmap is just that public.

If a customer needs a more detailed roadmap that can be done just send me mail.

Sue
0
Susan
8/4/2014 1:16:11 AM
ok this made me laugh.

French mail out fit
long pony tail
drinks beer
codes in macro 

Sounds like every guy in this group's fantasy woman 
0
Susan
8/4/2014 1:47:38 AM
Cazz,

Can you please send me email

first name Sue
dot
Surname Skonetski
@ symbol
VMSSoftware
dot
com

Thanks so much
0
Susan
8/4/2014 1:50:29 AM
On 14-08-03 17:23, John E. Malmberg wrote:

> The commercial x86 server market is essentially going to being VMs on 
> Hypervisors.  


This may seem like the logical way to go about it based on industry
trends BUT...

Initially, they will want to to talk to the installed base to see if
hosting VMS on VMware or other is interesting to them. If they run
mission critical apps, they may decide they prefer dedicated hardware,
so the VMware support might come later rather than sooner.

On the other hand, how much special kludges are needed at the OS level
to run as an instance under VMware ? Does VMware present a totally
vanilla hardware environment or does the OS need special drivers ?


0
JF
8/4/2014 1:54:40 AM
On 14-08-03 21:04, Susan Skonetski wrote:

> Not sure if anyone remembers me or not.

I dont have the foggiest idea...

For those who don't know Susan, she is the one who tied me up and didn't
threathen to beat me up (the bat is CGI, added without her permission
but her hands were in right position :-)

http://www.vaxination.ca/vms/decus/web/100_0194.jpg

So she deserves kudos from everyone on comp.os.vms to have actually done
what just about everyone on comp.os.vms thought they should be doing to
me over the years :-)


>  But I have the honor of being part of the VMS Software Company.

Congratulations. I am quite happy for you and for VSI (or is it VSC ?)

Great to see you come out of the woodwork.

Here's hoping we'll get more and more well known names associated with
the new company.

This is very good news !

Question: any discussion on resurecting DECUS ?
0
JF
8/4/2014 2:17:41 AM
On 14-08-03 21:12, Susan Skonetski wrote:

> Hey JF maybe another trip to Canada would be fun??

Uh Oh...  You bring the duct tape this time :-)


0
JF
8/4/2014 2:18:55 AM
On 14-08-03 21:33, Susan Skonetski wrote:

> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.


Sue, this *may* be a valid concern for a portion of the remaining
installed base who have mission critical systems.

"Big enough to sue" is more like "are they credible, can we bet our
billion dollar firm on this small group" etc. Not so much for suing.

Selling the experienced engineers is a very positive aspect, but you
would still need to sell the support capabilities (7/24, worldwide, can
you send someone to the far reaches of the planet overnight to help
debug a serious problem etc).

Note that HP, having closed so many sales offices worldwide is probably
in a similar situation where they may have the image of being big, but
can't really deliver "on site" support in large areas anymore.

Don't know if there are many active VNS customers in Montr�al left, but
the former HP offices in Kirkland are still empty. Nobody rented the
building since HP vacated it years ago.
0
JF
8/4/2014 2:24:43 AM
On 2014-08-04 01:54:40 +0000, JF Mezei said:

> On 14-08-03 17:23, John E. Malmberg wrote:
> 
>> The commercial x86 server market is essentially going to being VMs on 
>> Hypervisors.
> 
> This may seem like the logical way to go about it based on industry 
> trends BUT...

Virtualization support will happen sooner or later with the VMS x86-64 
port, as more than a few customer sites will want to boot and run VMS 
within an existing VM-based environment, and they'll want to do that 
efficiently.

> On the other hand, how much special kludges are needed at the OS level 
> to run as an instance under VMware ? Does VMware present a totally 
> vanilla hardware environment or does the OS need special drivers ?

A virtual machine presents vanilla hardware and most guests won't 
notice any differences, while a paravirtualization-based approach 
<http://en.wikipedia.org/wiki/Paravirtualization> is common for 
performance reasons, and that does require some guest operating system 
modifications.

Paravirtualization might also make something similar to OpenVMS Galaxy 
possible, as well — different guests within the VM communicating more 
directly.

Remember too that this is all a couple of years in the future, which 
means that there'll be more virtualization, yet denser systems, and 
potentially some alternative packaging approaches such as unikernels.  
(Unikernels being quite like how the VAX ELN product operated, but I 
digress.)

-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/4/2014 2:38:21 AM
Susan Skonetski  <sue.skonetski@vmssoftware.com> wrote:
>ok this made me laugh.
>
>French mail out fit
>long pony tail
>drinks beer
>codes in macro 
>
>Sounds like every guy in this group's fantasy woman 

Depends.  Macro-11 or Macro-32?
--scott

And anyway, my ex knows COMPASS....
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."
0
kludge
8/4/2014 2:43:08 AM
On 14-08-03 22:38, Stephen Hoffman wrote:

> Virtualization support will happen sooner or later with the VMS x86-64 
> port, 

Rethinking a bit, I think developpers will want to run VMS on top of
VMware along with instances of Linux etc.

So making VMS run on VMware may in fact be a higher priority than I thought.


0
JF
8/4/2014 2:45:20 AM
On 8/3/2014 8:54 PM, JF Mezei wrote:
> On 14-08-03 17:23, John E. Malmberg wrote:
>
>> The commercial x86 server market is essentially going to being VMs on
>> Hypervisors.
>
> This may seem like the logical way to go about it based on industry
> trends BUT...
>
> Initially, they will want to to talk to the installed base to see if
> hosting VMS on VMware or other is interesting to them. If they run
> mission critical apps, they may decide they prefer dedicated hardware,
> so the VMware support might come later rather than sooner.
>
> On the other hand, how much special kludges are needed at the OS level
> to run as an instance under VMware ? Does VMware present a totally
> vanilla hardware environment or does the OS need special drivers ?

VMWare and the other hypervisors can present emulation of the most 
popular hardware.

When the OS is aware that it is running in a VM, then the OS can use 
special drivers to more efficiently run on a VM.  When this is properly 
done, there is virtually no performance penalty for running on a VM 
instead of native hardware.

These are not kludges, these are engineering enhancements to the OS to 
take advantage of the hypervisor.

This is what all the existing commercial + Linux x86 server operating 
systems do when running as a VM, and what is making that so successful.

You basically do not want to run a production system on a VM with out 
using the special drivers.

To target a hypervisor instead of bare-metal, you only need to write the 
special drivers, and those are much simpler drivers than for real 
devices and will probably not need as much maintenance.

You may have to debug and possibly fix the open source hypervisor 
drivers, but that can be a lot less work than writing device specific 
native drivers for VMS.

Regards,
-John

0
John
8/4/2014 2:50:56 AM
On Sunday, August 3, 2014 10:43:08 PM UTC-4, Scott Dorsey wrote:

> 
> And anyway, my ex knows COMPASS....
> 

I still have my COMPASS manual in my bookshelf.  The CDC 6500 that is being restored at the Living Computer Museum in Seattle is actually the very same machine from Purdue where I wrote COMPASS programs.
0
John
8/4/2014 3:03:38 AM
On Thursday, July 31, 2014 10:47:53 AM UTC-7, Simon Clubley wrote:

> |In the future, VSI will support other hardware platforms, including X86-based
> 
> |servers
> 
> Yeah, good luck with that. :-)
> 
> I would _really_ like to be proved wrong with that, but I don't think
> this is going to happen. (Sadly. :-()
> 
> [...]
> 
> don't forget VMS requires more from the underlying architecture
> in terms of page protection/multiple rings than Linux does.

The things about 4 protection rings are actually not as daunting as they might
appear at a glance.

The four-ring model can be more or less be mapped to bi-modal page tables
of x64.

A general approach is that instead of one page table you can keep two or three,
i.e. using notation [outer-mode][inner-mode] that would be page tables for UK,
SK and EK combinations. The inner mode is always K. When a switch between CPU
modes happen in such as way that the "outer" mode changes, then CR3 register is
reloaded with an appropriate page table. If PCID (address space identifier
register) is used this does not cause TLB flush. The waste of space due to 
keeping multiple page tables may also be not too high as PTEs for most pages 
can be shared, so hopefully the replication can be confined  mostly to page 
directory (PDE) entries rather than PTE segments themselves.

It is also possible to collapse K and E rings into a single ring, just as DEC's
own virtualization solution did it once upon a time. This leaves then just UK
and SK page tables and the switch of an active table needs to happen only on
CHMS (i.e. going U->S) and on REI (S->U) and also on a few select REI(K->S).
These are fairly rare events, so they would be cheap even without PCID, and even
cheaper with PCID. The content of UK and SK page tables can be largely the same
and they can share most PTEs (accessed from a single shared copy pointed from
PDEs), except for the CLI address range and some pages in the CTL region. These
latter ranges would have to have per-table PTEs, but all other PTEs could be
physically shared between the tables.

A somewhat more tricky part is that x64 provides page protection modes
equivalent to UR, UW, KR and KW, but no URKW. So pages protected as UREW (e.g.
RMS buffers and some IMGACT data) may need to be dealt with specially and 
the code using then may need to be modified, perhaps using double-mapping 
(one time mapped as UR, and another time as KW) or by changing the access 
logic to these pages indeed by directing it via an accessor method.
There is no similar problem with URSW pages (CLI data) as those can have
separate PTEs in UK and SK tables.

Certainly not trying to trivialize the amount of effort required for the port to
x64, that would surely take a lot of work and then some more and then some more
yet, but technically that appears to be doable granted sufficient resources,
and I'd say a somewhat bigger business model concern might be whether VSI would
be able to convince the owners of critical applications such as Oracle to port
them to VMS-x64.

- Sergey
0
oboguev
8/4/2014 7:58:39 AM
Le 04/08/2014 03:54, JF Mezei a �crit :
> On 14-08-03 17:23, John E. Malmberg wrote:
>
>> The commercial x86 server market is essentially going to being VMs on
>> Hypervisors.
>
>
> This may seem like the logical way to go about it based on industry
> trends BUT...
>
> Initially, they will want to to talk to the installed base to see if
> hosting VMS on VMware or other is interesting to them. If they run
> mission critical apps, they may decide they prefer dedicated hardware,
> so the VMware support might come later rather than sooner.
>

Do you know any of the installed base that does not have VMware in their 
facilities for their other applications ? Having VMS running on top of 
VMware would help integrating in what is now the "standard" environment 
for most "new" IT people. It would help recognizing VMS as a "not so 
exotic OS".

Many customers I know here in France still have VMS because of specific 
software designed and developed for VMS 20-30 years ago. They don't need 
big servers and today the smallest ia64 server is overdimensioned for 
their need. I would add that HP (or before Compaq or DEC) know about 10% 
of these customers. They haven't seen a HP/Cq/Dec salesman for decades.

0
rejoc
8/4/2014 8:21:50 AM
On 2014-08-04 09:58, oboguev.public@gmail.com wrote:
> On Thursday, July 31, 2014 10:47:53 AM UTC-7, Simon Clubley wrote:
>
>> |In the future, VSI will support other hardware platforms, including X86-based
>>
>> |servers
>>
>> Yeah, good luck with that. :-)
>>
>> I would _really_ like to be proved wrong with that, but I don't think
>> this is going to happen. (Sadly. :-()
>>
>> [...]
>>
>> don't forget VMS requires more from the underlying architecture
>> in terms of page protection/multiple rings than Linux does.
>
> The things about 4 protection rings are actually not as daunting as they might
> appear at a glance.

I think we (or at least some of us) have already talked enough about 
this. There are no big problems in this area. The problem is definitely 
solvable.

> The four-ring model can be more or less be mapped to bi-modal page tables
> of x64.
>
> A general approach is that instead of one page table you can keep two or three,
> i.e. using notation [outer-mode][inner-mode] that would be page tables for UK,
> SK and EK combinations. The inner mode is always K. When a switch between CPU
> modes happen in such as way that the "outer" mode changes, then CR3 register is
> reloaded with an appropriate page table. If PCID (address space identifier
> register) is used this does not cause TLB flush. The waste of space due to
> keeping multiple page tables may also be not too high as PTEs for most pages
> can be shared, so hopefully the replication can be confined  mostly to page
> directory (PDE) entries rather than PTE segments themselves.
>
> It is also possible to collapse K and E rings into a single ring, just as DEC's
> own virtualization solution did it once upon a time. This leaves then just UK
> and SK page tables and the switch of an active table needs to happen only on
> CHMS (i.e. going U->S) and on REI (S->U) and also on a few select REI(K->S).
> These are fairly rare events, so they would be cheap even without PCID, and even
> cheaper with PCID. The content of UK and SK page tables can be largely the same
> and they can share most PTEs (accessed from a single shared copy pointed from
> PDEs), except for the CLI address range and some pages in the CTL region. These
> latter ranges would have to have per-table PTEs, but all other PTEs could be
> physically shared between the tables.
>
> A somewhat more tricky part is that x64 provides page protection modes
> equivalent to UR, UW, KR and KW, but no URKW. So pages protected as UREW (e.g.
> RMS buffers and some IMGACT data) may need to be dealt with specially and
> the code using then may need to be modified, perhaps using double-mapping
> (one time mapped as UR, and another time as KW) or by changing the access
> logic to these pages indeed by directing it via an accessor method.
> There is no similar problem with URSW pages (CLI data) as those can have
> separate PTEs in UK and SK tables.

I don't see the problem, unless you are saying that the kernel can't get 
write access without the user also having it, which I don't think is 
correct (and I don't think you are saying that).

If you have a page protected UREW you will (you already noted this 
above) change the page mapping when you change mode anyway. So "user" 
mode after the switch is actually executive. And you map the page UWKW, 
and things work as expected. When you REI back from "executive" back to 
real user, you're going to change the mapping again, and then you revert 
back to user readonly. Unless you have some additional problem in here 
that I missed, this is a non-problem.

> Certainly not trying to trivialize the amount of effort required for the port to
> x64, that would surely take a lot of work and then some more and then some more
> yet, but technically that appears to be doable granted sufficient resources,
> and I'd say a somewhat bigger business model concern might be whether VSI would
> be able to convince the owners of critical applications such as Oracle to port
> them to VMS-x64.

Indeed. Noone should say that this is done in an afternoon, but there is 
no technical issue preventing it from being done.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/4/2014 9:14:12 AM
On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 14-08-03 21:33, Susan Skonetski wrote:
>
>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>
>
> Sue, this *may* be a valid concern for a portion of the remaining
> installed base who have mission critical systems.
>
> "Big enough to sue" is more like "are they credible, can we bet our
> billion dollar firm on this small group" etc. Not so much for suing.
>

Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
needs to convince the senior managers in those large corporations.

And those managers ask a very different set of questions to the
technical questions asked around here... :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/4/2014 12:02:23 PM
On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 14-08-03 21:04, Susan Skonetski wrote:
>
>> Not sure if anyone remembers me or not.
>
> I dont have the foggiest idea...
>
> For those who don't know Susan, she is the one who tied me up and didn't
> threathen to beat me up (the bat is CGI, added without her permission
> but her hands were in right position :-)
>

$ set response/mode=good_natured

Sue's only mistake on that glorious day was releasing you... :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/4/2014 12:05:17 PM
I think we should all take a step back here and allow VSI a little time to =
publicize their plans.  We can speculate all day long and not come close to=
 the actual plans as they exist. =20

Perhaps a separate posting with a list of the applications requested WITHOU=
T any commenting would be helpful to VSI?

Initially, I would think that supporting/improving the existing compuilers =
would be a good start.  Realize too, that available resources are likely to=
 be somewhat limited.  Keeping the scope of activities focused on a small n=
umber of projects would be more productive.

Dan

Note:  To those that responded to my initial requests for interest in keepi=
ng OpenVMS alive:  I will forward the contact information/resumes to Sue S.=
 as I believe that she may like the information.  I will forward these on F=
riday (8/8) to allow anyone to inform me that they do NOT wish me to do so.
0
abrsvc
8/4/2014 12:12:20 PM
On 2014-08-03, Susan Skonetski <sue.skonetski@vmssoftware.com> wrote:
>
> She's back!
>
> Simon,
>
> Lets have a chat, I just read two of your messages.  One saying the port to x86 could not happen and another saying would VMS Software be big enough to sue.  Since this is a public forum, questions raised should be answered publicly if ethically possible.
>
> Let me respond to both here.
>
> 1.I remember asking about VMS moving to another platform other than Alpaha
> and being told it could not be done. So much for that, it was done.  So now
> years later with even more advanced tools and an engineering team that has
> ported not once but twice.  You don't think it will happen, we will just have
> to see. But know that due diligence was done technically prior to stating our
> directions.  We are talking about the best VMS experts and engineers on the
> planet.  They are the ones that wrote all 27 million lines of code.   Please
> keep in mind that is also what they told Steve Jobs and I would be ok failing
> to the degree Apple has failed.  To the tune of billions.
>

First off, let me say upfront I don't have access to the VMS source code,
but I am familiar with VMS internals and I am very familiar with the
information in the I&DS manual.

The concern here is that I look at a number of operating systems (Linux
and various RTOSes) and I see in their source code how cleanly structured
they are when it comes to isolating architectures from each other. That
makes them (relatively) easy to port.

I then read the I&DS and I then see a great mass of monolithic intertwined
code with little of the isolation you see in Linux and friends. There are
also hardware requirements which simply don't exist in other operating
systems.

That is what makes me concerned here.

> 2. Big enough to sue - a business that was announced four days ago.  Lets get
> a little positive karma here.  Do you really think that the engineering team
> and even myself would  join a company we thought would fail?
>

JF has rephrased my concerns there in a better way in another posting.

> Keep in mind that if folks still need a large neck to strangle, at this time
> you have a choice of either working with HP or with VMS Software. Your choice.

As I mentioned in a later posting, the support from HP is a really good
step and would probably actually be required for many large corporates.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/4/2014 12:19:53 PM
On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-07-31, Paul Sture <nospam@sture.ch> wrote:
>> On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>> wrote:
>>>
>>> One further thought (and one which future business critical sales
>>> prospects will ask):
>>>
>>> 	Will VSI be large enough to sue when things go wrong ?
>>
>> From the VSI roadmap:
>>
>> "Customers who want to have HP provide v8.next support can do so directly
>> through HP"
>>
>
> That's interesting Paul, thanks. I didn't realise that.
>
> Even as a small customer, I would be very nervous about having to
> get VMS support through an unknown outfit. Obtaining that support
> through HP removes those concerns.

Another point is that some companies like a "one stop shop".  They want
to buy hardware, software and maintenance contracts from one supplier.

That gave a few of us the opportunity to be charged under the hardware
budget many years ago and we didn't object to that :-)

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/4/2014 12:21:48 PM
On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-07-31, Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> wrote:
>> In article <7NwCv.96773$LF1.35324@fx03.iad>, Shark8
>><OneWingedShark@gmail.com> writes: 
>>
>>> On 31-Jul-14 12:01, Phillip Helbig---undress to reply wrote:
>>> > Get back to building the best compilers in the world.  An OS needs
>>> > applications, and applications are developed with compilers.
>>> 
>>> *Bingo!*
>>> Not only this, but they /need/ to be done w/ formal-methods so that the 
>>> compiler is *provably* free of error -- once that is done, there isn't 
>>> any such thing as a compiler bug.
>>
>> As Knuth said, I have only mathematically proven that the code is
>> bug-free.  But be careful: I have not yet tested it.
>>
>
> Thank you Phillip; I seem to be reminding people of Knuth quite a bit
> recently. I freely admit I don't have any real formal methods experience,
> but every time I come across it, there's always some assumptions which
> are made which have the potential to be great big invalidators.
>
> For example, how do you know the specification the formal proof is
> based on is correct ? Or how do you know there are not some surprises
> waiting for you in the underlying hardware the formally proved
> program runs on ?

An interesting snippet I learned on a recent course is that Intel chips
have the ability to ignore malformed assembler instructions.  Malware
authors use this feature to assist in code obfuscation.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/4/2014 12:32:26 PM
On Monday, August 4, 2014 8:19:53 AM UTC-4, Simon Clubley wrote:


> The concern here is that I look at a number of operating systems (Linux
> and various RTOSes) and I see in their source code how cleanly structured
> they are when it comes to isolating architectures from each other. That
> makes them (relatively) easy to port.
>=20
> I then read the I&DS and I then see a great mass of monolithic intertwine=
d
> code with little of the isolation you see in Linux and friends. There are
> also hardware requirements which simply don't exist in other operating
> systems.
>=20

Well that code was taken to Alpha and then to Itanium.  It is all about abs=
tractions.  For example, pagelets.  Invented to retain code that thinks the=
 memory is still in 512byte pages.

Consider the Macro-32 code in the OS (which I think we'll all agree has the=
 most chance of being 'hardware dependent' given the age).  When porting fr=
om Alpha to Itanium, I doubt we edited 10% of the files.  The ones that wer=
e edited usually were minor edits to add a new directive or such.  It is th=
e Macro compiler that turns those VAXy instructions into PAL calls on Alpha=
 or SWIS/system-service calls on Itanium.

0
John
8/4/2014 12:58:53 PM
On 2014-08-04, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> On 14-08-03 21:33, Susan Skonetski wrote:
>>
>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>
>>
>> Sue, this *may* be a valid concern for a portion of the remaining
>> installed base who have mission critical systems.
>>
>> "Big enough to sue" is more like "are they credible, can we bet our
>> billion dollar firm on this small group" etc. Not so much for suing.
>>
>
> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
> needs to convince the senior managers in those large corporations.
>
> And those managers ask a very different set of questions to the
> technical questions asked around here... :-)

It's a lot easier to scream about software support when you are spending
big bucks on hardware purchases and maintenance from the same supplier.

I have used this technique myself in the past :-)

From a purely practical view having the same supplier also neatly avoids
the grey areas between software and hardware problems. It is all too easy
to end up in a finger pointing exercise when the hardware and software
folks are from the same company, let alone two different ones.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/4/2014 1:01:37 PM
Paul Sture wrote 2014-08-04 14:21:
> On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2014-07-31, Paul Sture <nospam@sture.ch> wrote:
>>> On 2014-07-31, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>
>>> wrote:
>>>>
>>>> One further thought (and one which future business critical sales
>>>> prospects will ask):
>>>>
>>>> 	Will VSI be large enough to sue when things go wrong ?
>>>
>>>  From the VSI roadmap:
>>>
>>> "Customers who want to have HP provide v8.next support can do so directly
>>> through HP"
>>>
>>
>> That's interesting Paul, thanks. I didn't realise that.
>>
>> Even as a small customer, I would be very nervous about having to
>> get VMS support through an unknown outfit. Obtaining that support
>> through HP removes those concerns.
>

But even so, the actual support will probably be handed
over to VSI. HP will just be a middle man doing the
administration of the contracts, as I understand.
That can still be fine, of course. Easier to
manage the contracts for the customer.


> Another point is that some companies like a "one stop shop".  They want
> to buy hardware, software and maintenance contracts from one supplier.
>
> That gave a few of us the opportunity to be charged under the hardware
> budget many years ago and we didn't object to that :-)
>

0
Jan
8/4/2014 1:15:30 PM
Paul Sture wrote 2014-08-04 15:01:
> On 2014-08-04, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>
>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>
>>>
>>> Sue, this *may* be a valid concern for a portion of the remaining
>>> installed base who have mission critical systems.
>>>
>>> "Big enough to sue" is more like "are they credible, can we bet our
>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>
>>
>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>> needs to convince the senior managers in those large corporations.
>>
>> And those managers ask a very different set of questions to the
>> technical questions asked around here... :-)
>
> It's a lot easier to scream about software support when you are spending
> big bucks on hardware purchases and maintenance from the same supplier.
>
> I have used this technique myself in the past :-)
>
>  From a purely practical view having the same supplier also neatly avoids
> the grey areas between software and hardware problems. It is all too easy
> to end up in a finger pointing exercise when the hardware and software
> folks are from the same company,...

But they will probabnly not be from the same company. HW=HP, SW=VSI. Do
not mix this up with the actual contracts. There can still be finger
pointing, but it will not be as visable to the customer. :-)

Does anyone actualy belive that *HP* will retain personel and
have them beeing up trained on any pre-8.4 VMS? Why should they?


Jan-Erik.


  let alone two different ones.
>

0
Jan
8/4/2014 1:20:36 PM
In article <IjTCv.136775$AN6.25160@fx01.iad>,
	=?windows-1252?Q?=22Ro=DFert_G=2E_Schaffrath=22?=   <rschaffrath@yahoo.com> writes:
> On 8/1/2014 1:19 PM, Bob Koehler wrote:
>> In article <c3vde9FkpavU1@mid.individual.net>, bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
>>>
>>> I never expected HP to swallow their ego and let this go.  I am not
>>> familiar with VSI so have no idea how big they are or what resources
>>> they have to carry this out.  Any chance that this is an opportunity
>>> for some of the big guns here to get positions as employees or sub-
>>> contractors to bring some of the collected knowledge and experience
>>> back into the corral?
>>
>>     I think they already said so in thier announcements.  And I
>>     appreciate that there's a connection to Nmemonix.
>>
>>     IMHO, that gives them lots of credibility.
>>
> 
> I just hope that VMS thrives and does not wind up like RSTS/E under 
> Mentec.  That basically fizzled.

How did it fizzle?  Mentec continued to maintain it and even did all the
Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
I think all three PDP-11 OSes had longer lives under Mentec than they had
under DEC.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 1:21:36 PM
In article <lrnsof$vr0$4@dont-email.me>,
	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> On 14-08-03 21:33, Susan Skonetski wrote:
>>
>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>
>>
>> Sue, this *may* be a valid concern for a portion of the remaining
>> installed base who have mission critical systems.
>>
>> "Big enough to sue" is more like "are they credible, can we bet our
>> billion dollar firm on this small group" etc. Not so much for suing.
>>

Well, let me be the ne with something positive to say for a change...

"Big enough to sue"?  And people here think I am cynical!!!

> 
> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
> needs to convince the senior managers in those large corporations.
> 
> And those managers ask a very different set of questions to the
> technical questions asked around here... :-)

All true, but the fact is this is a potential path into the future and
HP was offering none.  I would think that anyone who is locked in to
VMS, for whatever reason, is going to be happy to hear this announcement.
For one thing, I expect that, unless they do something really dumb, VSI
will have one other thing that HP lost a long time ago, credibility!!

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 1:28:35 PM
Jan-Erik Soderholm wrote 2014-08-04 15:20:
> Paul Sture wrote 2014-08-04 15:01:
>> On 2014-08-04, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>
>>>>> 2. Big enough to sue - a business that was announced four days ago.
>>>>> Lets get a little positive karma here.
>>>>
>>>>
>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>> installed base who have mission critical systems.
>>>>
>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>
>>>
>>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>>> needs to convince the senior managers in those large corporations.
>>>
>>> And those managers ask a very different set of questions to the
>>> technical questions asked around here... :-)
>>
>> It's a lot easier to scream about software support when you are spending
>> big bucks on hardware purchases and maintenance from the same supplier.
>>
>> I have used this technique myself in the past :-)
>>
>>  From a purely practical view having the same supplier also neatly avoids
>> the grey areas between software and hardware problems. It is all too easy
>> to end up in a finger pointing exercise when the hardware and software
>> folks are from the same company,...
>
> But they will probabnly not be from the same company. HW=HP, SW=VSI. Do
> not mix this up with the actual contracts. There can still be finger
> pointing, but it will not be as visable to the customer. :-)
>
> Does anyone actualy belive that *HP* will retain personel and
> have them beeing up trained on any pre-8.4 VMS? Why should they?
>
>
> Jan-Erik.
>
>
>   let alone two different ones.
>>
>

Sorry, that should hae been "post-8.4 VMS version", of course.
Jan-Erik.
0
Jan
8/4/2014 1:28:41 PM
On 2014-08-04 13:15:30 +0000, Jan-Erik Soderholm said:
> But even so, the actual support will probably be handed over to VSI.
> HP will just be a middle man doing the administration of the contracts, 
> as I understand.
> That can still be fine, of course. Easier to manage the contracts for 
> the customer.

IIRC, one of the folks that spoke on the announcement con-call 
indicated that HP would be providing support for their VMS support 
customers as per usual practices.  They were providing the first couple 
of levels through the existing HP support center mechanisms, and when 
level 3 and higher escalations where necessary they were then passing 
the call off to either HP VMS for V8.4 and earlier, or to VSI VMS for 
later releases.  Again, IIRC.

Hope somebody at VSI is accumulating fodder for an FAQ.  :-)


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/4/2014 1:37:09 PM
Thirty thumbs up! 

\(^_^)/

AEF
0
AEF
8/4/2014 1:44:48 PM
In article <lriuga$tgl$1@dont-email.me>,
	"Craig A. Berry" <craigberry@nospam.mac.com> writes:
> On 8/2/14, 7:54 AM, Phillip Helbig---undress to reply wrote:
>> In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
>> Vlems <hvlems@freenet.de> writes:
>>
>>> Support for the x86 may turn out to mean on a simulator and not natively
>>> supported.
>>
>> That was certainly not my impression.  If this is the case, then VSI
>> should correct this impression right away.  However, I'm pretty sure
>> that this is NOT what they mean.
> 
> In the conference call someone asked whether non-HP servers would be
> supported and the answer was that the target was HP hardware at least
> initially and while others might work at some point there was the
> question of chipsets, etc.

Considering the bad taste HP has left in a lot of mouths, I see this as
a real negative.

> 
> Someone else (I think it was Bob Gezelter) mentioned the importance of
> virtualization such as running under VirtualBox or VMWare for
> development, testing, inclusion in cloud portfolios, etc. I don't recall
> a specific answer, but it seemed they were listening.

I know people here are all Windows haters, but if you are going to look at
virtualization I think you really need to include Hyper-V in the mix.  It's
a very viable product.

> 
> A different caller then asked how virtualization could work if the
> console firmware is behind an HP paywall like it is now for Integrity
> servers. I don't think they could say much about that at this point. It
> will probably be a couple years before that enters the top 500 list of
> things they need to worry about, but it was a good question.
> 
> A separate question that didn't come up is whether the EFI capabilities
> of the virtualization solutions support everything needed to make an OS
> think it has a ProLiant console.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 1:45:54 PM
Stephen Hoffman wrote 2014-08-04 15:37:
> On 2014-08-04 13:15:30 +0000, Jan-Erik Soderholm said:
>> But even so, the actual support will probably be handed over to VSI.
>> HP will just be a middle man doing the administration of the contracts,
>> as I understand.
>> That can still be fine, of course. Easier to manage the contracts for the
>> customer.
>
> IIRC, one of the folks that spoke on the announcement con-call indicated
> that HP would be providing support for their VMS support customers as per
> usual practices.  They were providing the first couple of levels through
> the existing HP support center mechanisms, and when level 3 and higher
> escalations where necessary they were then passing the call off to either
> HP VMS for V8.4 and earlier, or to VSI VMS for later releases.  Again, IIRC.
>
> Hope somebody at VSI is accumulating fodder for an FAQ.  :-)
>
>

That is the only way (as I see it) that makes sense.
Why should HP build (low level) competence on post 8.4
VMS versions? Doesn't make sense...

On the practical side, it might still make sense top have
the service contract managed by one source.

Jan-Erik.
0
Jan
8/4/2014 1:47:25 PM
John Reagan <xyzzy1959@gmail.com> writes:

>On Sunday, August 3, 2014 10:43:08 PM UTC-4, Scott Dorsey wrote:

>> 
>> And anyway, my ex knows COMPASS....
>> 

>I still have my COMPASS manual in my bookshelf.  The CDC 6500 that is being
>restored at the Living Computer Museum in Seattle is actually the very 
>same machine from Purdue where I wrote COMPASS programs.

I taught myself the COMPASS assembler when I was in college.  It was how I 
got into assembly language coding.
0
moroney
8/4/2014 2:06:55 PM
Bill Gunshannon wrote 2014-08-04 15:45:
> In article <lriuga$tgl$1@dont-email.me>,
> 	"Craig A. Berry" <craigberry@nospam.mac.com> writes:
>> On 8/2/14, 7:54 AM, Phillip Helbig---undress to reply wrote:
>>> In article <19108d5e-bb23-4780-875c-7af48e2b0d9a@googlegroups.com>, Hans
>>> Vlems <hvlems@freenet.de> writes:
>>>
>>>> Support for the x86 may turn out to mean on a simulator and not natively
>>>> supported.
>>>
>>> That was certainly not my impression.  If this is the case, then VSI
>>> should correct this impression right away.  However, I'm pretty sure
>>> that this is NOT what they mean.
>>
>> In the conference call someone asked whether non-HP servers would be
>> supported and the answer was that the target was HP hardware at least
>> initially and while others might work at some point there was the
>> question of chipsets, etc.
>
> Considering the bad taste HP has left in a lot of mouths, I see this as
> a real negative.
>

There is nothing wrong with the HP x86 servers as such.
I do not see this as a problem, if you do not make it
into into a problem yourself.

>>
>> Someone else (I think it was Bob Gezelter) mentioned the importance of
>> virtualization such as running under VirtualBox or VMWare for
>> development, testing, inclusion in cloud portfolios, etc. I don't recall
>> a specific answer, but it seemed they were listening.
>
> I know people here are all Windows haters...

Some, that refuse to look at the IT market pragmatically, are.
*I* am not. Some even can't spell it correctly...

> but if you are going to look at virtualization I think you really need to
 > include Hyper-V in the mix.  It's a very viable product.
>

Of course.

Jan-Erik.

0
Jan
8/4/2014 2:16:16 PM
On 14-08-04 04:21, rejoc wrote:

> Do you know any of the installed base that does not have VMware in their 
> facilities for their other applications ? Having VMS running on top of 
> VMware would help integrating in what is now the "standard" environment 
> for most "new" IT people. It would help recognizing VMS as a "not so 
> exotic OS".


I am thinking of customers still tied to VMS because of unique hardware
interfaces or with mission critical apps where they want to reduce
layers of code.

AKA: there may be VMS customers for whom having dedicated hardware is
necessary for those apps, even if other apps in that company run atop
VMware.

The number of such customers may be low, extremly low or relatively high
when you look at the remaining VMS installed base. And those might be
the first one VSI might be catering to before expanding the VMS
installed base.

It is a no brainer that when thinking about expanding the VMS installed
base, VMware support is necessary.

0
JF
8/4/2014 3:01:20 PM
John Reagan  <xyzzy1959@gmail.com> wrote:
>On Sunday, August 3, 2014 10:43:08 PM UTC-4, Scott Dorsey wrote:
>
>> And anyway, my ex knows COMPASS....
>
>I still have my COMPASS manual in my bookshelf.  The CDC 6500 that is being restored at the Living Computer Museum in Seattle is actually the very same machine from Purdue where I wrote COMPASS programs.

There are old computers that I want to see preserved for future generations
to experience.  But there are other old computers that are better off being
shredded for scrap and I would put any machine with 60-bit words and that
stupid address register scheme in the latter category.  
--scott
-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."
0
kludge
8/4/2014 3:04:16 PM
On 14-08-04 08:21, Paul Sture wrote:

> Another point is that some companies like a "one stop shop".  They want
> to buy hardware, software and maintenance contracts from one supplier.

With the success of Linux and RedHat, is that truly still the case ?

Yes, you can get your "one stop shop" from IBM who will sell you servers
and Linux support. Oh wait, isn't IBM getting rid fo x86 server business ?



0
JF
8/4/2014 3:11:25 PM
Le 04/08/2014 17:01, JF Mezei a �crit :
>
> I am thinking of customers still tied to VMS because of unique hardware
> interfaces or with mission critical apps where they want to reduce
> layers of code.
>
 > AKA: there may be VMS customers for whom having dedicated hardware is
 > necessary for those apps, even if other apps in that company run atop
 > VMware.
 >

The one I know is still on VAX because they have specific QBus 
interfaces :-) Very populare in some industrial environments

0
rejoc
8/4/2014 3:38:17 PM
In article <lrntp8$d28$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2014-08-03, Susan Skonetski <sue.skonetski@vmssoftware.com> wrote:
>>
>> She's back!
>>
>> Simon,
>>
>> Lets have a chat, I just read two of your messages.  One saying the port to x86 could not happen and another saying would VMS Software be big enough to sue.  Since this is a public forum, questions raised should be answered publicly if ethically possib
>>
>> Let me respond to both here.
>>
>> 1.I remember asking about VMS moving to another platform other than Alpaha
>> and being told it could not be done. So much for that, it was done.  So now
>> years later with even more advanced tools and an engineering team that has
>> ported not once but twice.  You don't think it will happen, we will just have
>> to see. But know that due diligence was done technically prior to stating our
>> directions.  We are talking about the best VMS experts and engineers on the
>> planet.  They are the ones that wrote all 27 million lines of code.   Please
>> keep in mind that is also what they told Steve Jobs and I would be ok failing
>> to the degree Apple has failed.  To the tune of billions.
>>
>
>First off, let me say upfront I don't have access to the VMS source code,
>but I am familiar with VMS internals and I am very familiar with the
>information in the I&DS manual.
>
>The concern here is that I look at a number of operating systems (Linux
>and various RTOSes) and I see in their source code how cleanly structured
>they are when it comes to isolating architectures from each other. That
>makes them (relatively) easy to port.
>
>I then read the I&DS and I then see a great mass of monolithic intertwined
>code with little of the isolation you see in Linux and friends. There are
>also hardware requirements which simply don't exist in other operating
>systems.

At least VMS *IS* so well documented.  I don't find you Linux "the-code-IS-
the-documentation" approach to documenting its internals as clean an approach
as you do.  

I believe "C" has /* */ and // for comments.  Those developing Linux should
be made aware of them. ;)

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/4/2014 3:42:35 PM
Simon Clubley wrote:
> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>> On 14-08-03 21:33, Susan Skonetski wrote:
>>
>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>
>> Sue, this *may* be a valid concern for a portion of the remaining
>> installed base who have mission critical systems.
>>
>> "Big enough to sue" is more like "are they credible, can we bet our
>> billion dollar firm on this small group" etc. Not so much for suing.
>>
> 
> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
> needs to convince the senior managers in those large corporations.
> 
> And those managers ask a very different set of questions to the
> technical questions asked around here... :-)
> 
> Simon.
> 

I'll first state that in my opinion, if you count on suing someone as 
part of your strategy, then you're not really concerned with "success", 
whatever that means to each.

I've always hated this concept, since the day my partner and I were told 
we'd never get a support contract because "we weren't big enough to 
sue".  Disregarding that my partner and I were some of the primary 
architects of their software, and there was NOBODY else on the planet 
better suited to support their applications.

So, perhaps VSI doesn't need such types of customers.  Some people are 
more trouble than they are worth.
0
David
8/4/2014 4:25:32 PM
Jan-Erik Soderholm wrote:
> Paul Sture wrote 2014-08-04 15:01:
>> On 2014-08-04, Simon Clubley 
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>
>>>>> 2. Big enough to sue - a business that was announced four days 
>>>>> ago.  Lets get a little positive karma here.
>>>>
>>>>
>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>> installed base who have mission critical systems.
>>>>
>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>
>>>
>>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>>> needs to convince the senior managers in those large corporations.
>>>
>>> And those managers ask a very different set of questions to the
>>> technical questions asked around here... :-)
>>
>> It's a lot easier to scream about software support when you are spending
>> big bucks on hardware purchases and maintenance from the same supplier.
>>
>> I have used this technique myself in the past :-)
>>
>>  From a purely practical view having the same supplier also neatly avoids
>> the grey areas between software and hardware problems. It is all too easy
>> to end up in a finger pointing exercise when the hardware and software
>> folks are from the same company,...
> 
> But they will probabnly not be from the same company. HW=HP, SW=VSI. Do
> not mix this up with the actual contracts. There can still be finger
> pointing, but it will not be as visable to the customer. :-)

Well, Microsoft, Red Hat, and such do not sell the hardware.  What's 
different here?

> Does anyone actualy belive that *HP* will retain personel and
> have them beeing up trained on any pre-8.4 VMS? Why should they?

They definitely will not.  Which is why, the sooner all VMS users get on 
V8.next or whatever, the sooner they can count on at least a good 
effort, and best wishes from the software vendor.  And the sooner they 
can support the software vendor.

> 
> Jan-Erik.
> 
> 
>  let alone two different ones.
>>
> 
0
David
8/4/2014 4:35:17 PM
Bill Gunshannon wrote:
> In article <lrnsof$vr0$4@dont-email.me>,
> 	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>
>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>
>>> Sue, this *may* be a valid concern for a portion of the remaining
>>> installed base who have mission critical systems.
>>>
>>> "Big enough to sue" is more like "are they credible, can we bet our
>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>
> 
> Well, let me be the ne with something positive to say for a change...
> 
> "Big enough to sue"?  And people here think I am cynical!!!
> 
>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>> needs to convince the senior managers in those large corporations.
>>
>> And those managers ask a very different set of questions to the
>> technical questions asked around here... :-)
> 
> All true, but the fact is this is a potential path into the future and
> HP was offering none.  I would think that anyone who is locked in to
> VMS, for whatever reason, is going to be happy to hear this announcement.
> For one thing, I expect that, unless they do something really dumb, VSI
> will have one other thing that HP lost a long time ago, credibility!!
> 
> bill
> 

I'd think that the simple fact they are putting their money and efforts 
where many of us have always wished for money and effort is instant 
credibility.
0
David
8/4/2014 4:37:11 PM
On 14-08-04 12:25, David Froble wrote:

> So, perhaps VSI doesn't need such types of customers.  Some people are 
> more trouble than they are worth.

VSI is lucky in the sense that they are rescuing VMS from certain death.
The remaining VMS installed base isn't gonna want to sue the small
company that is fixing the huge mistake made by the huge company.

The remaining VMS installed base will be happy to see a company with a
vested interest in seeing the success of VMS. (unlike HP who had no
interest in VMS).

And when you consider small firms who do the also-mission-critical real
time operating systems that are often embedded into very mission
critical systems, they too seem to be doing OK despite not being large
enough to sue.

However, there will come a time where the small size of VSI may make it
harder to acquire certain types of NEW customers. But my guess is that
they will cross that bridge when they get to it.

For now, getting VMS back to life after the poison HP injected into it
is priority.

0
JF
8/4/2014 4:38:09 PM
On 2014-08-04, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> On 14-08-04 08:21, Paul Sture wrote:
>
>> Another point is that some companies like a "one stop shop".  They want
>> to buy hardware, software and maintenance contracts from one supplier.
>
> With the success of Linux and RedHat, is that truly still the case ?
>
> Yes, you can get your "one stop shop" from IBM who will sell you servers
> and Linux support. Oh wait, isn't IBM getting rid fo x86 server business ?

I think that's probably what Oracle is targeting with Oracle Linux:

<https://en.wikipedia.org/wiki/Oracle_Enterprise_Linux>

In contrast to the RHEL model, it's now free for folks without a support
contract.

<http://www.theinquirer.net/inquirer/news/2357134/oracle-releases-its-unbreakable-homebrew-oracle-linux-7>

Oracle's own page:

<http://www.oracle.com/us/technologies/linux/overview/index.html>


-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/4/2014 4:41:41 PM
In article <lrh4oh$5m4$1@dont-email.me>,
	David Froble <davef@tsoft-inc.com> writes:
> Phillip Helbig---undress to reply wrote:
>> In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
>> mcleanjoh@gmail.com writes: 
>> 
>>> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
>>>
>>>> For now, not much to be done for VAX and Alpha, but that could change in 
>>>> the future.  Unless it was prohibited, VSI maybe could issue new 
>>>> versions for those platforms also, should they see some potential 
>>>> profits in doing so.  Again, even if it's just a new version number.
>>> David,
>>>
>>> I have a source who has a source (etc) ... and I've been told the VSI
>>> agreement does NOT include VMS on Alpha, which means there'll be no
>>> back-porting of enhancements. 
>> 
>> Right.  This was mentioned during the conference call.
>> 
> 
> Yes, I heard that also.  But I'd like to see the details of the 
> agreement, assuming they will be available, to see what is specifically 
> prohibited.

I would be very surprised if it was made available.  Might even be tied
to an NDA.

> 
> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
> as they already have plenty to do, sidetracks such as VAX and Alpha 
> would not be very helpful, at least right now.

I agree.  IA-64 only long enough to protect the existing market.  But
x86-64 needs to be the future direction.  Of course, along another
devergent string, are there likely to be any limitations they have been
sadled with?  Could they do an ARM port?  Power?  :-)

> 
> One question I'd have is, in addition to the IS-64 V8.4 sources and 
> build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
> V7.3 sources and build tools are included in the deal, then it would be 
> possible, if not likely, that they could do something there.  

What would be the value in havng the old sources if you are prohibited
from doing VAX or Alpha?

>                                                               If the 
> sources and tools are not available, then it's basically the same thing 
> we were looking at if HP didn't make sources available for anything 
> else, stake through the heart.

I certainly don't see that but maybe I just don't understand your meaning.

> 
> I have no idea what VSI asked HP to provide.  If I was involved, I'd 
> attempt to get everything, just in case, and it really wouldn't cost HP 
> any more.  Or, HP could have asked for additional money, and why throw 
> extra money into what really isn't part of the game plan?
> 
> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 

As previously stated, cash cow.  They are collecting support funds for
something that they don't really have to support as it is stable and
stagnant.

>   As soon as the x86 port is ready, all those old systems become boat 
> anchors.  I can build some nice AMD based systems for under $500.  Why 
> wouldn't everyone go that route?

Well, one reason why many people are still on the VAX is hardware.  If
you need to interface to a factory floor and the only interfaces are
for the VAX....  Alpha on the other hand.  

bill


-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 4:43:33 PM
In article <106104e0-4c97-4160-8adb-1d92c2f8bfd5@googlegroups.com>,
	johnwallace4@yahoo.co.uk writes:
> On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:
>> Phillip Helbig---undress to reply wrote:
>> 
>> > In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
>> 
>> > mcleanjoh@gmail.com writes: 
>> 
>> > 
>> 
>> >> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
>> 
>> >>
>> 
>> >>> For now, not much to be done for VAX and Alpha, but that could change in 
>> 
>> >>> the future.  Unless it was prohibited, VSI maybe could issue new 
>> 
>> >>> versions for those platforms also, should they see some potential 
>> 
>> >>> profits in doing so.  Again, even if it's just a new version number.
>> 
>> >> David,
>> 
>> >>
>> 
>> >> I have a source who has a source (etc) ... and I've been told the VSI
>> 
>> >> agreement does NOT include VMS on Alpha, which means there'll be no
>> 
>> >> back-porting of enhancements. 
>> 
>> > 
>> 
>> > Right.  This was mentioned during the conference call.
>> 
>> > 
>> 
>> 
>> 
>> Yes, I heard that also.  But I'd like to see the details of the 
>> 
>> agreement, assuming they will be available, to see what is specifically 
>> 
>> prohibited.
>> 
>> 
>> 
>> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
>> 
>> as they already have plenty to do, sidetracks such as VAX and Alpha 
>> 
>> would not be very helpful, at least right now.
>> 
>> 
>> 
>> One question I'd have is, in addition to the IS-64 V8.4 sources and 
>> 
>> build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
>> 
>> V7.3 sources and build tools are included in the deal, then it would be 
>> 
>> possible, if not likely, that they could do something there.  If the 
>> 
>> sources and tools are not available, then it's basically the same thing 
>> 
>> we were looking at if HP didn't make sources available for anything 
>> 
>> else, stake through the heart.
>> 
>> 
>> 
>> I have no idea what VSI asked HP to provide.  If I was involved, I'd 
>> 
>> attempt to get everything, just in case, and it really wouldn't cost HP 
>> 
>> any more.  Or, HP could have asked for additional money, and why throw 
>> 
>> extra money into what really isn't part of the game plan?
>> 
>> 
>> 
>> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 
>> 
>>   As soon as the x86 port is ready, all those old systems become boat 
>> 
>> anchors.  I can build some nice AMD based systems for under $500.  Why 
>> 
>> wouldn't everyone go that route?
> 
> "I can build some nice AMD based systems for under $500"
> 
> Agreed. 
> 
> "Why wouldn't everyone go that route? "
> 
> Everyone who wanted to run Windows or Linux (or DOS) might go that route.
> 
> But you want VMS. There may be the small matter of qualification and support, 
> maybe even some specific device drivers for some specific configurations?
> 
> I would imagine that VMS will run (or at least be supported on) some subset
> of HP's x86-64 range. There are some nice budget MicroServers which probably would have been great for the "one server per shop" model which used
> to be used in a few chains, for example, as well as mid and high end Proliant.
> 
> But is it realistic to expect OpenVMS/x86 to run on Yee Ha's random
> Taiwanese motherboard, with or without an HP badge attached?

Considering the commonality of these boxes, I see no reason why not.
Unless one goes out of their way to introduce odd hardware requirements
it should be doable.  


bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 4:47:27 PM
In article <lrhsm2$t4b$1@dont-email.me>,
	David Froble <davef@tsoft-inc.com> writes:
> johnwallace4@yahoo.co.uk wrote:
>> On Friday, 1 August 2014 23:39:05 UTC+1, David Froble  wrote:
> 
>> "I can build some nice AMD based systems for under $500"
>> 
>> Agreed. 
>> 
>> "Why wouldn't everyone go that route? "
>> 
>> Everyone who wanted to run Windows or Linux (or DOS) might go that route.
>> 
>> But you want VMS. There may be the small matter of qualification and support, 
>> maybe even some specific device drivers for some specific configurations?
>> 
>> I would imagine that VMS will run (or at least be supported on) some subset
>> of HP's x86-64 range. There are some nice budget MicroServers which probably would have been great for the "one server per shop" model which used
>> to be used in a few chains, for example, as well as mid and high end Proliant.
>> 
>> But is it realistic to expect OpenVMS/x86 to run on Yee Ha's random
>> Taiwanese motherboard, with or without an HP badge attached?
> 
> Possibly a good question.  I'm going to guess, with nothing to base the 
> guess upon, that it will depend what devices you want to use.
> 
> I think it would be silly to repeat the mistakes of the past.  Look at 
> what's in general use and make sure it's supported.
> 
> If you're into graphics, it could get sticky.

Oh damn.  I wanted Minecraft on my VMS laptop.

> 
> I'm going to guess that disk drives, tape drives, and such are not going 
> to be an issue.  SCSI, S-ATA, SAS, and future stuff.
> 
> I'm more familiar with AMD targeted motherboards.  Any more, it's the 
> chipsets provided by AMD.  This stuff seems to be getting rather consistent.

That's what I thought as well.  Just because HP tries to make their
hardware a differntiator doesn't mean it has to be that way.

Let's look back at comments here not so long ago. People who said if HP
killed VMS they wouldn't even buy printers from them.  Well, HP did,
effectively, kill VMS.  But the VSI EMT's are trying to resucitate it
in the ambulance.  So, why choose HP servers as your target platform?

> 
> I'm thinking that VSI's revenues will come from support.  If so, what's 
> the use in doing something to exclude certain hardware?  Isn't that a 
> bit like epoxy in part of the backplane?

Agreed...


bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/4/2014 4:51:53 PM
Jan-Erik Soderholm wrote:
> Bill Gunshannon wrote 2014-08-04 15:45:

>>> In the conference call someone asked whether non-HP servers would be
>>> supported and the answer was that the target was HP hardware at least
>>> initially and while others might work at some point there was the
>>> question of chipsets, etc.
>>
>> Considering the bad taste HP has left in a lot of mouths, I see this as
>> a real negative.
>>
> 
> There is nothing wrong with the HP x86 servers as such.
> I do not see this as a problem, if you do not make it
> into into a problem yourself.
> 

The issue isn't with HP x86 systems.  The issue is with HP.

That said, and with the disclaimer that I don't know a bit about what 
I'm about to say, I'd think that doing anything other that designing to 
include most of the reasonable motherboard and chipsets in common use 
would be poor judgment.

At the low end you'd be looking at single CPU socket motherboards.  I'm 
guessing this would satisfy a large portion of the current and potential 
market.

Now, if you want a 512 core system, yeah, that's going to be more 
complex, hardware and software.
0
David
8/4/2014 4:53:07 PM
JF Mezei wrote 2014-08-04 17:17:
> On 14-08-04 09:47, Jan-Erik Soderholm wrote:
>
>> That is the only way (as I see it) that makes sense.
>> Why should HP build (low level) competence on post 8.4
>> VMS versions? Doesn't make sense...
>
> Why does IBM maintain competence on VMS ? Doesn't make sense, until you
> realise these companies make money on support contracts and will support
> anything and everything.
>
>

There is "support" and there is "support". You should know the
differance very well.

Does IBM provide low-lever VMS support on the OS level?
That is, like bug fixing and similar? No they don't.

IBM keep VMS competence enough to support their tools like
their MQ Series client kit for VMS. Just as any other
ISV selling software for VMS.

Does VMS take outsourcing contracts where there is VMS involved?
Yes they do, but that is at another (user/programmer/application)
level. Does IBM run all this support themselfs? No, that dont.
*I* have supplied VMS services and support to IBM for many years.
Now that is taken over p� TSC (Tata), but that is another story...

It doesn't make sense that HP should keep competence on any VMS
verison post 8.4, of course. On the source level.

Jan-Erik.


0
Jan
8/4/2014 5:00:54 PM
JF Mezei wrote:
> On 14-08-03 08:59, Stephen Hoffman wrote:
> 
>> Whether VMS will be tied to specific x86-64 hardware acquired from VSI 
>> (akin to Apple), and/or VMS on specific hardware from VSI and/or HP 
> 
> 
> I have to assume that initially, it will be restricted to a few known
> models because that is all VMS will have been qualified on and all that
> VSI will be able/willing to support.
> 
> I would think that the company will not work to prevent VMS from being
> loaded onto any 8086 with basic comppatibility (64 bits, UEFI, certain
> disk types etc), but support would only be sold on approved hardware/VMS
> combinations.

I would hope they have learned the lessons.  if they make the same 
mistakes that DEC made, then they will end up the same way.

> In other words, hobbyists might be able to load VMS onto any 8086, but
> if you want commercial support, you will need to have specific hardware.
> 
> Should VMS prove to be a success they may then spend extra money to test
> VMS on other boxes to validate and allow support over extended range of
> machines.
> 
> 
> This is where hobbysists might be valuable to VSI if they can be used to
> test various hardware combos and report back on what works and doesn't work.
> 

What I see here is assumptions that the way things have been done in the 
past is the only way to proceed in the future.

Why not think outside the box?  Take another (or several) approach(s).

Lets face it, acquiring all the hardware to test every possible 
configuration, and spending the time to do so, could be a black hole 
that consumes everything.

As another approach, what about having the test suite of programs, 
procedures, and such, and make them freely available to all customers?

Then say to the customers, we've tested these X configurations, and so 
far they seem to work.  But you can do any configuration of your own, 
with maybe some guidelines, and run your own tests.

Might give some hobbyists some real challenges, and a way to contribute.

Constructive feedback would be helpful, and possibly some of the issues 
found might be very easy fixes.

VSI might even provide a list of configurations they'd like to see tested.
0
David
8/4/2014 5:11:36 PM
cazzer69@googlemail.com used his keyboard to write :
>> Agreed, but there are lots of us still using VMS that were getting 
>> dangerously close to being forced to address the End of Life in 2020. That 
>> is no longer a conversation I must have with president of my company or my 
>> auditors. There is no longer a set EOL! So yes this may not attract any new 
>> customers in the next 2 years, but it should slow the bleeding dramatically! 
>> Like me, many of the posters here have control or a strong influence on what 
>> OS is used for mission critical processes. We love VMS and we choose it (for 
>> very rational reasons). In another year or 2 that would have been a 
>> difficult decision to justify. We would need a 5 year plan to transition to 
>> keep our professional reputation. Now, that is off the table. Lets stop the 
>> bleeding today and start to grow next year or the year after! <
>
> As of this morning two VMS exit projects here at work (a conversion to Linux 
> and another to SAP) have been put on hold indefinitely. :)

Same as mine...

-- 
Marc Van Dyck


0
Marc
8/4/2014 5:19:42 PM
On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
> Bill Gunshannon wrote:
>> In article <lrnsof$vr0$4@dont-email.me>,
>> 	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>
>>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>>
>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>> installed base who have mission critical systems.
>>>>
>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>
>> 
>> Well, let me be the ne with something positive to say for a change...
>> 
>> "Big enough to sue"?  And people here think I am cynical!!!
>> 

It's called being realistic. The senior manager in a large company is not
emotionally involved with VMS. What they want to know about the proposed
solution on their desk is what happens when something goes wrong and
_their_ boss starts asking when the problem is going to be fixed.

That's the reality of life in production business environments and that's
why it's so important that the contract on that desk can be with HP and
not VSI.

BTW, I can see you have never being exposed to normal commercial business
concerns. :-)

>>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>>> needs to convince the senior managers in those large corporations.
>>>
>>> And those managers ask a very different set of questions to the
>>> technical questions asked around here... :-)
>> 
>> All true, but the fact is this is a potential path into the future and
>> HP was offering none.  I would think that anyone who is locked in to
>> VMS, for whatever reason, is going to be happy to hear this announcement.
>> For one thing, I expect that, unless they do something really dumb, VSI
>> will have one other thing that HP lost a long time ago, credibility!!
>> 
>> bill
>> 
>
> I'd think that the simple fact they are putting their money and efforts 
> where many of us have always wished for money and effort is instant 
> credibility.

On an emotional/technical level for VMS technical people, yes.

For everyone else, a primary question about the proposed solution on
that manager's desk will be what happens when the critical production
system is down and is the vendor large enough to be held to account ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/4/2014 5:47:12 PM
In article <lroc5o$np8$1@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
>Simon Clubley wrote:
>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>
>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>
>>> Sue, this *may* be a valid concern for a portion of the remaining
>>> installed base who have mission critical systems.
>>>
>>> "Big enough to sue" is more like "are they credible, can we bet our
>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>
>> 
>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>> needs to convince the senior managers in those large corporations.
>> 
>> And those managers ask a very different set of questions to the
>> technical questions asked around here... :-)
>> 
>> Simon.
>> 
>
>I'll first state that in my opinion, if you count on suing someone as 
>part of your strategy, then you're not really concerned with "success", 
>whatever that means to each.

To paraphase an old Woody Allen quip.

Those who can, do.  Those who can't, are complete schmucks and litigate.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/4/2014 6:02:48 PM
In article <53de530c$0$49335$c3e8da3$c8b7d2e6@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Will the work to port to x86 begin in parralel with the work to qualify
> VMS for Poulson systems ? Or only once qualification for Poulson has
> been done ?

   The confernce said Poulson first, then maybe Kitson.

> 
> For the very early portions of porting, can you use an off-the-shelf x86
> compiler that doesn't support VMS extensions ?  I realise the linker
> likly needs to be very VMS specific though.

    I think that would be difficult.  Besides, can you find an
    off-the-shelf Macro-32 compiler for x86?

0
koehler
8/4/2014 6:58:15 PM
In article <o4SdnQfmx9gfTUPOnZ2dnUU7-R2dnZ2d@supernews.com>, David Turner <dturner@islandco.com> writes:
> Creating a native version of VMS for X86-64 - fantastic idea. BUT  You 
> need to concentrate on specific hardware and get it right on just a few 
> high end systems
> Just look at M$ and Linux. Stuff kinda works with some systems.
> OpenVMS has always been a very robust OS. Porting it to a good high end 
> high quality server like certain Proliant servers is great. Porting it 
> to a generic PC is a bad bad idea.
> 
> 
> My opinion but someone who has experienced some stuff that KINDA works 
> with VMS. Not pretty and not fun.

   IMHO, on at least the second update to VMS from VSI, they need to
   really put together versions of EDT, DEBUG, ..., that work well
   with PC keyboards.

0
koehler
8/4/2014 7:03:03 PM
In article <fedbc1cb-085d-4be5-b596-6191a354ec33@googlegroups.com>, Susan Skonetski <sue.skonetski@vmssoftware.com> writes:

> 
> Warm Regards,
> Sue

    Great work, Sue.  Much luck with the new "best job".

0
koehler
8/4/2014 7:04:11 PM
In article <53deed47$0$49532$c3e8da3$fdf4f6af@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Question: any discussion on resurecting DECUS ?

   Good question.  Is VSI going to use Compass, or try to re-create
   something like DECUS?

   I heard in the conference that VSI would be providing support
   for the DECUSserve environment.  Can I assume EISNER is going
   to physically move?

0
koehler
8/4/2014 7:07:39 PM
On 2014-08-04 15:21, Bill Gunshannon wrote:
> In article <IjTCv.136775$AN6.25160@fx01.iad>,
> 	=?windows-1252?Q?=22Ro=DFert_G=2E_Schaffrath=22?=   <rschaffrath@yahoo.com> writes:
>> On 8/1/2014 1:19 PM, Bob Koehler wrote:
>>> In article <c3vde9FkpavU1@mid.individual.net>, bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
>>>>
>>>> I never expected HP to swallow their ego and let this go.  I am not
>>>> familiar with VSI so have no idea how big they are or what resources
>>>> they have to carry this out.  Any chance that this is an opportunity
>>>> for some of the big guns here to get positions as employees or sub-
>>>> contractors to bring some of the collected knowledge and experience
>>>> back into the corral?
>>>
>>>      I think they already said so in thier announcements.  And I
>>>      appreciate that there's a connection to Nmemonix.
>>>
>>>      IMHO, that gives them lots of credibility.
>>>
>>
>> I just hope that VMS thrives and does not wind up like RSTS/E under
>> Mentec.  That basically fizzled.
>
> How did it fizzle?  Mentec continued to maintain it and even did all the
> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
> I think all three PDP-11 OSes had longer lives under Mentec than they had
> under DEC.

Not really. Active development continued for about 5 years at Mentec, 
and then another 10 years of slow death. They did live longer at DEC,

But I agree that it's a bit unfair to just say they fizzled at Mentec.
However, RSTS/E might have gotten the least attention of all of them at 
Mentec.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/4/2014 7:16:44 PM
Simon Clubley wrote:
> On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
>> Bill Gunshannon wrote:
>>> In article <lrnsof$vr0$4@dont-email.me>,
>>> 	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>>
>>>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>>> installed base who have mission critical systems.
>>>>>
>>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>>
>>> Well, let me be the ne with something positive to say for a change...
>>>
>>> "Big enough to sue"?  And people here think I am cynical!!!
>>>
> 
> It's called being realistic. The senior manager in a large company is not
> emotionally involved with VMS. What they want to know about the proposed
> solution on their desk is what happens when something goes wrong and
> _their_ boss starts asking when the problem is going to be fixed.
> 
> That's the reality of life in production business environments and that's
> why it's so important that the contract on that desk can be with HP and
> not VSI.
> 
> BTW, I can see you have never being exposed to normal commercial business
> concerns. :-)
> 
>>>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>>>> needs to convince the senior managers in those large corporations.
>>>>
>>>> And those managers ask a very different set of questions to the
>>>> technical questions asked around here... :-)
>>> All true, but the fact is this is a potential path into the future and
>>> HP was offering none.  I would think that anyone who is locked in to
>>> VMS, for whatever reason, is going to be happy to hear this announcement.
>>> For one thing, I expect that, unless they do something really dumb, VSI
>>> will have one other thing that HP lost a long time ago, credibility!!
>>>
>>> bill
>>>
>> I'd think that the simple fact they are putting their money and efforts 
>> where many of us have always wished for money and effort is instant 
>> credibility.
> 
> On an emotional/technical level for VMS technical people, yes.
> 
> For everyone else, a primary question about the proposed solution on
> that manager's desk will be what happens when the critical production
> system is down and is the vendor large enough to be held to account ?
> 
> Simon.
> 

Perhaps a better manager will attempt to minimize the possibility that 
the production system will NOT go down, rather than accept less than 
optimal and legal action, which will be costly, and in legal action 
there are never any guarantees.  I'm pretty sure the support agreements 
provide plenty of outs for the vendor.

So, now your production is stopped, the earliest court date in in 5 
years, you're bleeding money by the minute, and oh, by the way, you're 
already fired for picking the junky system .....

Is making quality your #1 goal now starting to look a bit more wise Mr 
manager?

They are not all as stupid as you think.  Yeah, I've run across some who 
say "everyone else is doing it".  I've also run across some who 
recognize reality.
0
David
8/4/2014 7:25:29 PM
VAXman- @SendSpamHere.ORG wrote:

> Those who can, do.  Those who can't, are complete schmucks and litigate.
> 

Somehow I KNEW that discussions on lawyers would be a strong magnet for 
your attention ...

:-)
0
David
8/4/2014 7:28:17 PM
John E. Malmberg wrote:

> A new x86 server OS that is not hypervisor aware is essentially DOA for 
> commercial sales.  So it is a necessary layer.

John, you're a rather astute guy, I formed that opinion lo those many 
years ago in the first 10 minutes of talking to you.  But the above 
statement seems to lack any justification.  Can you defend it a bit, 
specify situations where it's factual, and such?

I'll admit, my perception, quite likely wrong, is that the various VM 
type of environments were developed to support the weendoze concept of 
one application, one server.  Right or wrong, the perception was that 
weendoze didn't support multiple applications near as well as other 
environments.

I've never used a VM, cannot know what I'm missing.  But I also don't 
seem to suffer from the lack.

And maybe this isn't the right place for a possibly far reaching 
discussion ....

Dave
0
David
8/4/2014 7:40:47 PM
Bill Gunshannon wrote:
> In article <lrh4oh$5m4$1@dont-email.me>,
> 	David Froble <davef@tsoft-inc.com> writes:
>> Phillip Helbig---undress to reply wrote:
>>> In article <5654cff3-387c-47a8-b2c1-220a812a046c@googlegroups.com>,
>>> mcleanjoh@gmail.com writes: 
>>>
>>>> On Friday, August 1, 2014 5:13:33 PM UTC+10, David Froble wrote:
>>>>
>>>>> For now, not much to be done for VAX and Alpha, but that could change in 
>>>>> the future.  Unless it was prohibited, VSI maybe could issue new 
>>>>> versions for those platforms also, should they see some potential 
>>>>> profits in doing so.  Again, even if it's just a new version number.
>>>> David,
>>>>
>>>> I have a source who has a source (etc) ... and I've been told the VSI
>>>> agreement does NOT include VMS on Alpha, which means there'll be no
>>>> back-porting of enhancements. 
>>> Right.  This was mentioned during the conference call.
>>>
>> Yes, I heard that also.  But I'd like to see the details of the 
>> agreement, assuming they will be available, to see what is specifically 
>> prohibited.
> 
> I would be very surprised if it was made available.  Might even be tied
> to an NDA.

Would not surprise me.

>> Now, VAX, Alpha, and to an extent IA-64 is not the future for VSI, and 
>> as they already have plenty to do, sidetracks such as VAX and Alpha 
>> would not be very helpful, at least right now.
> 
> I agree.  IA-64 only long enough to protect the existing market.  But
> x86-64 needs to be the future direction.  Of course, along another
> devergent string, are there likely to be any limitations they have been
> sadled with?  Could they do an ARM port?  Power?  :-)

Good question.  I haven't heard of any restrictions for future products. 
  But, I don't get out much.

>> One question I'd have is, in addition to the IS-64 V8.4 sources and 
>> build tools, what else is VSI going to get off of HP?  If the VAX/VMS 
>> V7.3 sources and build tools are included in the deal, then it would be 
>> possible, if not likely, that they could do something there.  
> 
> What would be the value in havng the old sources if you are prohibited
> from doing VAX or Alpha?

Well, being prohibited is just one of the questions, and maybe the biggest.

However, if VSI is allowed to develop new versions of VMS, with no 
restrictions on the platform, then if it's doable, would not some 
support from old platform users be a good thing?  Something that HP has 
probably already dropped?  Remember, these are VMS believers, not HP.

>>                                                               If the 
>> sources and tools are not available, then it's basically the same thing 
>> we were looking at if HP didn't make sources available for anything 
>> else, stake through the heart.
> 
> I certainly don't see that but maybe I just don't understand your meaning.

1) Support for people who might desire it, that's additional income.

2) Contact with rather old users, that might become return customers.


>> I have no idea what VSI asked HP to provide.  If I was involved, I'd 
>> attempt to get everything, just in case, and it really wouldn't cost HP 
>> any more.  Or, HP could have asked for additional money, and why throw 
>> extra money into what really isn't part of the game plan?
>>
>> Why HP would want to retain the Alpha (or VAX) versions, I have no idea. 
> 
> As previously stated, cash cow.  They are collecting support funds for
> something that they don't really have to support as it is stable and
> stagnant.

Retain the support revenue, yes.  But what do they get by not turning 
over to VSI the VAX/VMS V7.3 sources?  That is, if they even still exist.

>>   As soon as the x86 port is ready, all those old systems become boat 
>> anchors.  I can build some nice AMD based systems for under $500.  Why 
>> wouldn't everyone go that route?
> 
> Well, one reason why many people are still on the VAX is hardware.  If
> you need to interface to a factory floor and the only interfaces are
> for the VAX....  Alpha on the other hand.  

Nemonix provides new devices for some very old hardware.  Seems to me 
there is some possibility for some convergence there.  Also some 
possibility for new x86 based devices to directly replace the old 
devices, and provide a path forward for some who have been stuck for a 
long time.  How many entities fit such a catagory, I got no clue.
0
David
8/4/2014 7:55:12 PM
Paul Sture wrote:
> On 2014-08-02, Craig A. Berry <craigberry@nospam.mac.com> wrote:
>> On 8/2/14, 6:17 PM, Shark8 wrote:
>>> It doesn't to me -- and as people here have mentioned, there do exist
>>> solid VMS webservers. (Now I could understand if they were small
>>> companies leasing webserver-servicies, but that really doesn't seem to
>>> be the case.)
>> Look again at the netcraft page. They are using a hosting company and
>> getting whatever web stack that company provides, as any small start-up
>> that is not selling web hosting should be doing. Currently VMS is a
>> relatively slow, expensive, and insecure option for internet-facing
>> applications of any kind. There is now hope that can change, but many
>> other more fundamental challenges need to be addressed first.
> 
> USD ~10 a month will get you a decent web hosting service with ssh access
> included nowadays.  Contrast that to a VMS box with licensing and
> maintenance costs.  At this point in time it might be one less VMS box
> that could be better used for development and testing.
> 
> Looking to the future, when (if?) VSI release a production ready web
> server they can support, by all means use the product as a showcase.  But
> there's a ton of work to be done to get to that point.
> 

Gonna show my old age now.

I remember when DEC's accounting department used IBM gear.  Seems the 
bean counters used what they were used to.

I also remember supplying DEC with an accounts payable system ....  on 
DEC gear of course.
0
David
8/4/2014 8:04:16 PM
On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
>
> Perhaps a better manager will attempt to minimize the possibility that 
> the production system will NOT go down, rather than accept less than 
> optimal and legal action, which will be costly, and in legal action 
> there are never any guarantees.  I'm pretty sure the support agreements 
> provide plenty of outs for the vendor.
>
> So, now your production is stopped, the earliest court date in in 5 
> years, you're bleeding money by the minute, and oh, by the way, you're 
> already fired for picking the junky system .....
>

But if they can show they followed "current fashions" in choosing the
system, then they are unlikely to be fired. Don't forget that a virus
friendly operating system managed to become the dominant corporate
desktop. :-)

> Is making quality your #1 goal now starting to look a bit more wise Mr 
> manager?
>
> They are not all as stupid as you think.  Yeah, I've run across some who 
> say "everyone else is doing it".  I've also run across some who 
> recognize reality.

I think what I am really saying is that these people might pick the
"safest for them" option, not the "technically best for the company"
option. They want to keep a roof over their heads and food on the
table - and they might think one of the best ways of doing that is
to go with a "standard" solution even if the one on their desk from
an unknown supplier might be technically better.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/4/2014 8:10:58 PM
On Monday, 4 August 2014 20:40:47 UTC+1, David Froble  wrote:
> John E. Malmberg wrote:
> 
> 
> 
> > A new x86 server OS that is not hypervisor aware is essentially DOA for 
> 
> > commercial sales.  So it is a necessary layer.
> 
> 
> 
> John, you're a rather astute guy, I formed that opinion lo those many 
> 
> years ago in the first 10 minutes of talking to you.  But the above 
> 
> statement seems to lack any justification.  Can you defend it a bit, 
> 
> specify situations where it's factual, and such?
> 
> 
> 
> I'll admit, my perception, quite likely wrong, is that the various VM 
> 
> type of environments were developed to support the weendoze concept of 
> 
> one application, one server.  Right or wrong, the perception was that 
> 
> weendoze didn't support multiple applications near as well as other 
> 
> environments.
> 
> 
> 
> I've never used a VM, cannot know what I'm missing.  But I also don't 
> 
> seem to suffer from the lack.
> 
> 
> 
> And maybe this isn't the right place for a possibly far reaching 
> 
> discussion ....
> 
> 
> 
> Dave

"the various VM type of environments were developed to support the
weendoze concept of one application, one server."

That, and the related problem of hardware sitting there near idle
much of the time. Where's Kerry (he was on the concall)?

Other reasons I remember for x86 virtualisation included:

* no easy means for x86 hardware resource redeployment 
* no easy means for x86 OS/application failover after hw or sw issue


Longstanding VMS customers are used to those last two being sorted
without needing hypervisors, instead they're using ancient stuff like
clusters (split-site if necessary), compatible hardware meaning stuff
can be reallocated without major hassle (and for a while, Galaxy meaning
stuff could be reallocated on the fly).

Where clusters weren't the answer, e.g. for rapid realtime failover,
there were homebrew solutions. And for some classes of application there
was Reliable Transaction Router.

All done without needing virtualisation. Why would that need to change now?

Obviously for the x86 market in general, virtualisation is a major
consideration. Because the volume AMD64 OSes *can't* do this kind of
stuff without virtualisation. VMS can, in the right circumstances.
0
johnwallace4
8/4/2014 8:12:37 PM
JF Mezei wrote:
> On 14-08-03 21:04, Susan Skonetski wrote:
> 
>> Not sure if anyone remembers me or not.
> 
> I dont have the foggiest idea...
> 
> For those who don't know Susan, she is the one who tied me up and didn't
> threathen to beat me up (the bat is CGI, added without her permission
> but her hands were in right position :-)
> 
> http://www.vaxination.ca/vms/decus/web/100_0194.jpg
> 
> So she deserves kudos from everyone on comp.os.vms to have actually done
> what just about everyone on comp.os.vms thought they should be doing to
> me over the years :-)
> 
> 
>>  But I have the honor of being part of the VMS Software Company.
> 
> Congratulations. I am quite happy for you and for VSI (or is it VSC ?)
> 
> Great to see you come out of the woodwork.
> 
> Here's hoping we'll get more and more well known names associated with
> the new company.
> 
> This is very good news !
> 
> Question: any discussion on resurecting DECUS ?

Oh, my!

Yeah, JF can be really a PITA at times.

But sometimes he comes out with a really great idea.
0
David
8/4/2014 8:30:10 PM
David Froble wrote 2014-08-04 22:30:
> JF Mezei wrote:
>> On 14-08-03 21:04, Susan Skonetski wrote:
>>
>>> Not sure if anyone remembers me or not.
>>
>> I dont have the foggiest idea...
>>
>> For those who don't know Susan, she is the one who tied me up and didn't
>> threathen to beat me up (the bat is CGI, added without her permission
>> but her hands were in right position :-)
>>
>> http://www.vaxination.ca/vms/decus/web/100_0194.jpg
>>
>> So she deserves kudos from everyone on comp.os.vms to have actually done
>> what just about everyone on comp.os.vms thought they should be doing to
>> me over the years :-)
>>
>>
>>>  But I have the honor of being part of the VMS Software Company.
>>
>> Congratulations. I am quite happy for you and for VSI (or is it VSC ?)
>>
>> Great to see you come out of the woodwork.
>>
>> Here's hoping we'll get more and more well known names associated with
>> the new company.
>>
>> This is very good news !
>>
>> Question: any discussion on resurecting DECUS ?
>
> Oh, my!
>
> Yeah, JF can be really a PITA at times.
>
> But sometimes he comes out with a really great idea.

Only if my member card is still valid. :-)
http://jescab2.dyndns.org/pub_docs/img_3347.jpg

Jan-Erik.
0
Jan
8/4/2014 8:53:14 PM
On 2014-08-04 19:40:47 +0000, David Froble said:

> John E. Malmberg wrote:
> 
>> A new x86 server OS that is not hypervisor aware is essentially DOA for 
>> commercial sales.  So it is a necessary layer.
> 
> John, you're a rather astute guy, I formed that opinion lo those many 
> years ago in the first 10 minutes of talking to you.  But the above 
> statement seems to lack any justification.  Can you defend it a bit, 
> specify situations where it's factual, and such?

VMs are how most businesses run stuff these days whether locally or 
hosted, and VMs are all over the place on OS X, Linux and Windows.

If your OS can't boot and run as a guest, you'll need your own 
hardware, and that'll make you unpopular with a number of environments.

There were a number of folks running VMS on HP-VM on HP-UX on Itanium, too.

> I'll admit, my perception, quite likely wrong, is that the various VM 
> type of environments were developed to support the weendoze concept of 
> one application, one server.  Right or wrong, the perception was that 
> weendoze didn't support multiple applications near as well as other 
> environments.

Need to restart some part of production due to a problem?  Roll in a 
fresh VM image.  It's wicked handy to blast an image in or out for 
development and testing, too.

They're also useful for application prototypes and for OS development 
work, as well.

> I've never used a VM, cannot know what I'm missing.  But I also don't 
> seem to suffer from the lack.

They're very handy to have around.

Maybe if you think of them as "virtual servers"?  Could having a dozen 
or a hundred servers around — without chewing up an equivalent amount 
of budget, power or cooling, and that can be loaded and reloaded very 
quickly — be handy for hacking around?


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/4/2014 10:35:13 PM
On Tuesday, August 5, 2014 4:58:15 AM UTC+10, Bob Koehler wrote:
> In article <53de530c$0$49335$c3e8da3$c8b7d2e6@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> > 
> > Will the work to port to x86 begin in parralel with the work to qualify
> > VMS for Poulson systems ? Or only once qualification for Poulson has
> > been done ?
> 
>    The confernce said Poulson first, then maybe Kitson.
> 

My understanding is that HP did a lot of the work to get VMS on Poulson so if VSI is basically taking over that work and can complete it within the next six months then
(a) VSI starts making some money
(b) HP sells more Poulson machines

Sounds like win-win to me (and win for potential customers)


0
mcleanjoh
8/4/2014 10:50:13 PM
On Monday, August 4, 2014 2:14:12 AM UTC-7, Johnny Billquist wrote:

> I don't see the problem, unless you are saying that the kernel can't get
> write access without the user also having it, which I don't think is
> correct (and I don't think you are saying that).

x86/x64 PTE has two bitflags: one controls user-mode accessibility of
the page, the other controls page writability. Thus x64 MMU does not 
provide a mode equivalent to URKW.

This means that in case rings E and K were collapsed, RMS buffers and few
other structures such as image activator data that reside in UREW pages
become URKW and fall into the category of page modes not directly supported
by the MMU and therefore need to be dealt with differently than current
VMS code does.

If rings E and K are kept separate then it is possible to have a separate
EK page table in addition to UK and SK page tables, and the problem for
UREW pages goes away, just as it does not exist for URSW pages due to the
existence of SK table. However transitions into and out of the executive
mode are much more frequent than into and out of the supervisor mode,
therefore with EK page table the flipping of an active page table would
have to be performed much more often. It boils down to a question of how
exactly costly is the reloading of CR3. Sure, with PCID it is much less
costly than without, but there is still some cost. First, albeit TLB will
retain leaf PTEs but it may not retain intermediate structures and would
have to re-read them (I guess only Intel can clarify what actually existing
chips do). Second, having three page tables instead of two cuts effective
TLB size.

- Sergey
0
oboguev
8/4/2014 10:50:21 PM
On Tuesday, August 5, 2014 5:55:12 AM UTC+10, David Froble wrote:

> >> Yes, I heard that also.  But I'd like to see the details of the 
> >> agreement, assuming they will be available, to see what is specifically 
> >> prohibited.
> 
> > I would be very surprised if it was made available.  Might even be tied
> > to an NDA.
> 
> Would not surprise me.
> 

Have you tried looking for HP's filing to the SEC?  The deal with VSI probably requires pne.

John
0
mcleanjoh
8/4/2014 10:59:25 PM
On Monday, 4 August 2014 23:35:13 UTC+1, Stephen Hoffman  wrote:
> On 2014-08-04 19:40:47 +0000, David Froble said:
> 
> 
> 
> > John E. Malmberg wrote:
> 
> > 
> 
> >> A new x86 server OS that is not hypervisor aware is essentially DOA for 
> 
> >> commercial sales.  So it is a necessary layer.
> 
> > 
> 
> > John, you're a rather astute guy, I formed that opinion lo those many 
> 
> > years ago in the first 10 minutes of talking to you.  But the above 
> 
> > statement seems to lack any justification.  Can you defend it a bit, 
> 
> > specify situations where it's factual, and such?
> 
> 
> 
> VMs are how most businesses run stuff these days whether locally or 
> 
> hosted, and VMs are all over the place on OS X, Linux and Windows.
> 
> 
> 
> If your OS can't boot and run as a guest, you'll need your own 
> 
> hardware, and that'll make you unpopular with a number of environments.
> 
> 
> 
> There were a number of folks running VMS on HP-VM on HP-UX on Itanium, too.
> 
> 
> 
> > I'll admit, my perception, quite likely wrong, is that the various VM 
> 
> > type of environments were developed to support the weendoze concept of 
> 
> > one application, one server.  Right or wrong, the perception was that 
> 
> > weendoze didn't support multiple applications near as well as other 
> 
> > environments.
> 
> 
> 
> Need to restart some part of production due to a problem?  Roll in a 
> 
> fresh VM image.  It's wicked handy to blast an image in or out for 
> 
> development and testing, too.
> 
> 
> 
> They're also useful for application prototypes and for OS development 
> 
> work, as well.
> 
> 
> 
> > I've never used a VM, cannot know what I'm missing.  But I also don't 
> 
> > seem to suffer from the lack.
> 
> 
> 
> They're very handy to have around.
> 
> 
> 
> Maybe if you think of them as "virtual servers"?  Could having a dozen 
> 
> or a hundred servers around -- without chewing up an equivalent amount 
> 
> of budget, power or cooling, and that can be loaded and reloaded very 
> 
> quickly -- be handy for hacking around?
> 
> 
> 
> 
> 
> -- 
> 
> Pure Personal Opinion | HoffmanLabs LLC

Devil's advocate time.

"Need to restart some part of production due to a problem?  Roll in a
fresh VM image.  It's wicked handy to blast an image in or out for
development and testing, too. "

A bit like DEC's Remote System Manager product could do. Or even just
an InfoServer and a few bits and pieces? When was that, 1990s?

A VMS setup didn't need to fake the hardware; the OS itself was
perfectly capable of running on a host that wasn't 100% identical with
the host where it was originally installed. Not so lucky if you're
on x86/Windows on kit with different (incompatible) core hardware.


"They're also useful for application prototypes and for OS development
work, as well. "

Application prototypes might need a separate machine when the x86
mentality (one app, one machine) applies. VMS has lots of reasons
why well behaved user mode apps don't need that. OS development
is obviously a different kettle of worms; crashes will happen.


"Could having a dozen or a hundred servers around -- without chewing
up an equivalent amount of budget, power or cooling, and that can be
loaded and reloaded very quickly -- be handy for hacking around?"

Isn't that kind of massive workload variation the ideal kind of thing
to be outsourced to "the cloud"? A smaller amount of variation can be
managed in house with none of the public-cloud-related issues now starting
to be cause for concern (at least in Europe).


Virtualisation in general is an answer to lots of problems that x86
and Windows introduced, and which the Wintel world could not or would
not fix at source (e.g. not-quite-compatible hardware and software).
Maybe there are a few circumstances where a real OS on real hardware can
benefit too.

That said, it would be very sensible to make sure that nuVMS (?)
eventually runs well in a virtualised x86 environment, because
virtualisation is now so many x86 IT people's comfort zone. Which
VM(s) should it be, or are they all sufficiently identical that no
separate qualification is needed? If you've got to qualify the
hypervisor/OS combination, how much does it cost, how much $$ does
it bring in? 

But the *technical* and *commercial* reasons I see for using
virtualisation with nuVMS are less significant than they are with
Windows. For a traditional VMS customer the virtualisation layer
brings extra complexity, and thus extra risk. It's the customers who
know whether the benefits outweigh the risks.

If it's a realtimeish environment of the kind where VMS used to excel
(e.g. factory automation with VMS in the loop), customers will want
to be sure virtualisation isn't going to bring more problems than it
solves. And if Windows can do that kind of job in a virtualised 
setup, nuVMS probably can too. Elsewhere? Tbd.

Fortunately it's not my decision :)
0
johnwallace4
8/4/2014 11:43:12 PM
On 14-08-05 00:25, John E. Malmberg wrote:

> Except for bragging rights, there is no advantage to targeting bare 
> metal with out a hypervisor.  It is just simply more initial work and 
> more on-going maintenance. 


Out of curiosity, would the engineers doing the VMS port to x86
initially work on a VM or on a vanilla bare metal with known/fixed
config ?  (talking about early development where the focus is on getting
first boot, talking to console, devices etc)


> 1. The ability assign IP and MAC addresses to a process. (Yes, some of 
> us can do that now :-)

In what way would running on a VM give a VMS process ability to get its
own MAC/IP address ?

From an ethernet point of view, do VMs allow multiple separate instances
to share the same physical ethernet card ? (which would imply faking MAC
address for all traffic, right ?)


0
JF
8/5/2014 1:01:01 AM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
> johnwallace4@yahoo.co.uk
> Sent: 04-Aug-14 7:43 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] Virtualization (was Re: VMS Software, Inc.
> announces agreement to continue development of OpenVMS and Layered
> Products under HP License)
>=20

[snip]

> Isn't that kind of massive workload variation the ideal kind of thing to =
be
> outsourced to "the cloud"? A smaller amount of variation can be managed i=
n
> house with none of the public-cloud-related issues now starting to be cau=
se
> for concern (at least in Europe).
>=20

Public Cloud computing is just a new name for external selective IT outsour=
cing using multi-tenant strategies. While some enterprise Customers are exp=
erimenting with some Apps in the Public cloud, by far, the majority of ente=
rprise Cust's are planning private clouds (ok, internal shared services ren=
amed for those with grey hair).

Re: public clouds - Like any form of outsourcing, there are pro's and con's=
.. Some examples of cons can be found online at: (hint - no offline, offsite=
 backups)
http://tinyurl.com/nd9j3v8  (ComputerWorld article June 19, 2014)
"Hacker puts 'full redundancy' code-hosting firm out of business.
CodeSpaces.com shut down after a hacker gained access to its Amazon EC2 acc=
ount and deleted most data, including backups

One of the better and hype free cloud articles I have read in a while:
http://tinyurl.com/cloud-washing (Forbes magazine)
" Multitenancy? Sounds like computing in a public restroom - who knows what=
 kind of sleazeball is in the next stall."=20

Who remembers CompuServe?

:-)

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com




0
Kerry
8/5/2014 1:03:44 AM
On 14-08-04 18:50, mcleanjoh@gmail.com wrote:

> My understanding is that HP did a lot of the work to get VMS on Poulson 


But I have to assume that VSI will have to spend much time setting up
their code management systems, import the VMS source from HP and then
spend some time cleaning up some of the mess the newbies would have made
in the code since 2010.


Will VSI hire the couple of experienced indians from HP ? What about
folks like John Egolf ?



0
JF
8/5/2014 1:17:31 AM
Johnny Billquist wrote:
> On 2014-08-04 15:21, Bill Gunshannon wrote:
>> In article <IjTCv.136775$AN6.25160@fx01.iad>,
>>     =?windows-1252?Q?=22Ro=DFert_G=2E_Schaffrath=22?=   
>> <rschaffrath@yahoo.com> writes:
>>> On 8/1/2014 1:19 PM, Bob Koehler wrote:
>>>> In article <c3vde9FkpavU1@mid.individual.net>, 
>>>> bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
>>>>>
>>>>> I never expected HP to swallow their ego and let this go.  I am not
>>>>> familiar with VSI so have no idea how big they are or what resources
>>>>> they have to carry this out.  Any chance that this is an opportunity
>>>>> for some of the big guns here to get positions as employees or sub-
>>>>> contractors to bring some of the collected knowledge and experience
>>>>> back into the corral?
>>>>
>>>>      I think they already said so in thier announcements.  And I
>>>>      appreciate that there's a connection to Nmemonix.
>>>>
>>>>      IMHO, that gives them lots of credibility.
>>>>
>>>
>>> I just hope that VMS thrives and does not wind up like RSTS/E under
>>> Mentec.  That basically fizzled.
>>
>> How did it fizzle?  Mentec continued to maintain it and even did all the
>> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
>> I think all three PDP-11 OSes had longer lives under Mentec than they had
>> under DEC.
> 
> Not really. Active development continued for about 5 years at Mentec, 
> and then another 10 years of slow death. They did live longer at DEC,
> 
> But I agree that it's a bit unfair to just say they fizzled at Mentec.
> However, RSTS/E might have gotten the least attention of all of them at 
> Mentec.
> 
>     Johnny
> 

When VMS matured, it provided all of the capabilities of RSTS/E.  Hey, I 
used RSTS/E for a number of years, and I liked it.  But VMS was better. 
  That could be a good reason RSTS/E didn't flourish.
0
David
8/5/2014 2:34:47 AM
Simon Clubley wrote:
> On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
>> Perhaps a better manager will attempt to minimize the possibility that 
>> the production system will NOT go down, rather than accept less than 
>> optimal and legal action, which will be costly, and in legal action 
>> there are never any guarantees.  I'm pretty sure the support agreements 
>> provide plenty of outs for the vendor.
>>
>> So, now your production is stopped, the earliest court date in in 5 
>> years, you're bleeding money by the minute, and oh, by the way, you're 
>> already fired for picking the junky system .....
>>
> 
> But if they can show they followed "current fashions" in choosing the
> system, then they are unlikely to be fired. Don't forget that a virus
> friendly operating system managed to become the dominant corporate
> desktop. :-)

Ayep.  And when I told the manager that he really should not put 
people's credit card and banking information unencrypted in an IIS 
server, his response was "everyone else is doing it".  I equate that to 
the claims of "I was just following orders" at the Nuremberg trials.

>> Is making quality your #1 goal now starting to look a bit more wise Mr 
>> manager?
>>
>> They are not all as stupid as you think.  Yeah, I've run across some who 
>> say "everyone else is doing it".  I've also run across some who 
>> recognize reality.
> 
> I think what I am really saying is that these people might pick the
> "safest for them" option, not the "technically best for the company"
> option. They want to keep a roof over their heads and food on the
> table - and they might think one of the best ways of doing that is
> to go with a "standard" solution even if the one on their desk from
> an unknown supplier might be technically better.

Even the incompetents understand "shit rolls downhill".  Yeah, if they 
are one of those that changes jobs every 6 months, then they don't 
really care.  But for those that take their responsibilities seriously, 
perhaps they will try to do the best for their employer.

One of the earliest things I learned in this business, "you're not going 
to win every customer".  So go for the "good" ones.
0
David
8/5/2014 2:42:25 AM
Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
>> johnwallace4@yahoo.co.uk
>> Sent: 04-Aug-14 7:43 PM
>> To: info-vax@info-vax.com
>> Subject: Re: [New Info-vax] Virtualization (was Re: VMS Software, Inc.
>> announces agreement to continue development of OpenVMS and Layered
>> Products under HP License)
>>
> 
> [snip]
> 
>> Isn't that kind of massive workload variation the ideal kind of thing to be
>> outsourced to "the cloud"? A smaller amount of variation can be managed in
>> house with none of the public-cloud-related issues now starting to be cause
>> for concern (at least in Europe).
>>
> 
> Public Cloud computing is just a new name for external selective IT outsourcing using multi-tenant strategies. While some enterprise Customers are experimenting with some Apps in the Public cloud, by far, the majority of enterprise Cust's are planning private clouds (ok, internal shared services renamed for those with grey hair).
> 
> Re: public clouds - Like any form of outsourcing, there are pro's and con's. Some examples of cons can be found online at: (hint - no offline, offsite backups)
> http://tinyurl.com/nd9j3v8  (ComputerWorld article June 19, 2014)
> "Hacker puts 'full redundancy' code-hosting firm out of business.
> CodeSpaces.com shut down after a hacker gained access to its Amazon EC2 account and deleted most data, including backups
> 
> One of the better and hype free cloud articles I have read in a while:
> http://tinyurl.com/cloud-washing (Forbes magazine)
> " Multitenancy? Sounds like computing in a public restroom - who knows what kind of sleazeball is in the next stall." 
> 
> Who remembers CompuServe?

Call it what it is.  Time Sharing.  Online systems in Pittsburgh used to 
have a room full of DECsystem 10s offering the service back in the 1970s.

The only thing really different today is much better networking.
0
David
8/5/2014 2:51:06 AM
Stephen Hoffman wrote:
> On 2014-08-04 19:40:47 +0000, David Froble said:

> Need to restart some part of production due to a problem?

Isn't this more application dependent?  Or have I been wrong all these 
years.  Many of our applications have restart capability using 
checkpoints.  Just queue up the application with restart information.

Doesn't everyone do this?

>  Roll in a 
> fresh VM image.  It's wicked handy to blast an image in or out for 
> development and testing, too.
> 
> They're also useful for application prototypes and for OS development 
> work, as well.

Funny, never seemed to need a VM to do any of that.

>> I've never used a VM, cannot know what I'm missing.  But I also don't 
>> seem to suffer from the lack.
> 
> They're very handy to have around.
> 
> Maybe if you think of them as "virtual servers"?  Could having a dozen 
> or a hundred servers around — without chewing up an equivalent amount of 
> budget, power or cooling, and that can be loaded and reloaded very 
> quickly — be handy for hacking around?
> 
> 

But, I have the same with just one VMS system.  Why not keep things simple?

At one time we had several customers running two completely separate 
companies on one VMS system.  Not two applications.  Two complete 
distribution companies.

Unless I'd want to run something else in addition to VMS, then I just 
don't see the need for a VM.  And since it's me, I do NOT want to run 
anything else.

:-)

I'm reminded that just because most of the lemmings run off the cliff 
and drown, doesn't mean that running off the cliff and drowning is an 
optimal strategy ....
0
David
8/5/2014 2:59:28 AM
David Froble wrote:

> 1) Support for people who might desire it, that's additional income.
> 
> 2) Contact with rather old users, that might become return customers.

In my normal attitude of ignoring etiquite, I'm replying to my own post.

:-)

After looking at the VMS Software web site, and yes, it's improving, as 
someone else mentioned, some interesting statements were found.

"Providing support for versions of VMS that HP no longer supports"

Now, doesn't that churn the waters a bit?

"Developing VMS releases for other platforms"

So, perhaps ARM is in the crystal ball, but, would not the two 
statements also open up the possibility for maybe VAX/VMS V7.3.1?  Why? 
  To provide support for VAX users who may be wandering in the 
wilderness?  Same for ALpha.
0
David
8/5/2014 3:07:26 AM
On 8/4/2014 9:59 PM, David Froble wrote:
> Stephen Hoffman wrote:
>> On 2014-08-04 19:40:47 +0000, David Froble said:
>
>> Need to restart some part of production due to a problem?
>
> Isn't this more application dependent?  Or have I been wrong all these
> years.  Many of our applications have restart capability using
> checkpoints.  Just queue up the application with restart information.
>
> Doesn't everyone do this?

Apparently not, but that is not the main reason that VMs are taking over 
the IT world.

One feature of the VMs is the ability to hot migrate a VM from one 
hardware chassis to another.

With a VMS cluster, if you have an SSH connection to a node and it has 
to be shut off because of a impending hardware failure, you have to 
specifically reconnect to one of the surviving nodes.

With VMs, you move the VM to another hardware chassis live.  No 
reconnection.

The hardware can also be load balanced on the fly.

The VM chassis does not need hot swap power supplies, it just has to 
have enough redundancy to survive long enough for migrating the guests 
to the other chassis.

The IT department can mix Microsoft, Bsd, Linux and other x86 operating 
systems on one common chassis.  The political cost of adding VMS based 
x86 VMs into the mix is must lower than trying to add a standalone box.

>>  Roll in a fresh VM image.  It's wicked handy to blast an image in or
>> out for development and testing, too.
>>
>> They're also useful for application prototypes and for OS development
>> work, as well.
>
> Funny, never seemed to need a VM to do any of that.

A VM allows you to run multiple versions of an OS on the same hardware 
simultaneously.  You can set up a cluster in a box.

Run out of proseccnt or other sysgen parameter?  If your development is 
on a VM, it is the only one affected by the reboot.

VMs do not solve all problems, but they solve a lot of problems that IT 
managers care about.

>>> I've never used a VM, cannot know what I'm missing.  But I also don't
>>> seem to suffer from the lack.
>>
>> They're very handy to have around.
>>
>> Maybe if you think of them as "virtual servers"?  Could having a dozen
>> or a hundred servers around — without chewing up an equivalent amount
>> of budget, power or cooling, and that can be loaded and reloaded very
>> quickly — be handy for hacking around?
>
> But, I have the same with just one VMS system.  Why not keep things simple?

A VM allows you to run multiple versions of an OS on the same hardware 
simultaneously.  You can set up a cluster in a box.

Run out of proseccnt or other sysgen parameter?  If your development is 
on a VM, it is the only one affected by the reboot.

Here is the reality though for an x86 VMS port.

    * If you target VMware/Hyper/V/KVM only you will always have
      device driver support for all major network and storage
      available from the hardware vendor.

    * If you write your own drivers, you either have to get
      pre-production hardware to develop against, or you
      will be writing drivers for hardware that is probably
      not being produced.  By the time a hardware card is
      available retail, that version is no longer being
      produced.
      It will take you longer to write.
      It will cost more.
      It will not be as versatile.
      It probably will not give significantly better performance.

So even if you only intend to ever run a single instance of VMS/x86 
there is a cost advantage to targeting a hypervisor with paravirtualized 
drivers instead of a native drivers.

Except for bragging rights, there is no advantage to targeting bare 
metal with out a hypervisor.  It is just simply more initial work and 
more on-going maintenance.  And it probably will not make a difference 
in the number of paying customers.

There will be paying customers that just want it to work fast and not 
care if there is or is not a hypervisor underneath it.

There will be paying customers that will not purchase unless it can run 
on at least one of the major hypervisors.

And while there may be customers that absolutely want true native 
drivers, I would expect that those would be a small minority.

> At one time we had several customers running two completely separate
> companies on one VMS system.  Not two applications.  Two complete
> distribution companies.

Yes, but could you live migrate them with no downtime to a different 
hardware chassis.

> Unless I'd want to run something else in addition to VMS, then I just
> don't see the need for a VM.  And since it's me, I do NOT want to run
> anything else.

You may not need it, but from my viewpoint, the corporate world wants 
just about everything on VMs.

> :-)
>
> I'm reminded that just because most of the lemmings run off the cliff
> and drown, doesn't mean that running off the cliff and drowning is an
> optimal strategy ....

For VMS to provide what hypervisors give it for free it would need:

1. The ability assign IP and MAC addresses to a process. (Yes, some of 
us can do that now :-)

2. The ability to move a process or process tree from one physical 
cluster member to another including those IP and MAC addresses without a 
reboot, or having the remote systems notice the move.

This is stuff that the x86 world has been taking for granted for years now.

Regards,
-John

0
John
8/5/2014 4:25:55 AM
In article <53dee7e1$0$55637$c3e8da3$b280bf18@news.astraweb.com>,
JF Mezei  <jfmezei.spamnot@vaxination.ca> wrote:
>On 14-08-03 17:23, John E. Malmberg wrote:
>
>> The commercial x86 server market is essentially going to being VMs on 
>> Hypervisors.  

Yup.

>This may seem like the logical way to go about it based on industry
>trends BUT...
>
>Initially, they will want to to talk to the installed base to see if
>hosting VMS on VMware or other is interesting to them. If they run
>mission critical apps, they may decide they prefer dedicated hardware,
>so the VMware support might come later rather than sooner.

It's also a way to to multiple VMS boxes on one piece of hardware.
Buy one box and split it between customers or between development and
test and production...

>On the other hand, how much special kludges are needed at the OS level
>to run as an instance under VMware ? Does VMware present a totally
>vanilla hardware environment or does the OS need special drivers ?


It depends... VMware ESX and ESXi used to pretty standard emulation of
standard PC platforms. Intel chips, vga video.  No fancy driver loads
were required.  They emulated National Semiconductor NICS, or DEC Tulip
or now sometimes even Intel E1000.

At one point they just were emulation pretty standard generic Pentium
boxes with Intel chipsets.  They've gotten much more hardware assist
built into the Intel CPU's to allow a lot less emulation and 
more virtualization at the actual cpu chip level.

You now have the Linux drivers building in virtualization drivers that
don't have to go through the layers of emulation of the NCR/LSI scsi
card and drivers.  The paravirtualized drivers talk directly to the
Virtualization stuff in the hypervisor...

On VMware you chose which drivers to use when defining the VM.
(Checkboxes in the gui...) for OS's without the support of that layer
they either emulate the LSI SAS/Paralel scsi (two different checks) or
the really old one from Bus Logic (199x vintage).

If you pick the right mix for your OS -- you can run it with no driver
changes.  For performance reasons VMware has a couple of drivers you can
replace the standard windows ones with that are better performing in the
VMware environment.

The storage can be ISCSI, SAN, NFS, local disks...

One nice feature of the VMware approach (which is also copied by
Microsoft in their new HyperV in Server 2012R2) is the hot migration of
the virtual machine and it's memory and storage from one location
(machine, san, memory) to another...  There's a slight slowing of the
machine during the migration -- but the users don't think it's much
beyond peak load.

So if the site catches fire you pull the switch and the running systems
migrate completely to the backup data center at your next location.  

I've done this on VMware ESX and only dropped one or two pings during
the migration to the datacenter in the next building.

If you can do this live without clustering you can provide additional
redundancy.  You also could run VAX clusters on top of ESX and get the
additional features.

I've got a Lenovo box here with dual 6 core Xeons.   I had 2 copies of 
Windows 2012R2 running (one as a VM) and two CentOS linux boxes
installing (Centos6 and 7) and the machine didn't break a sweat.  Next
step is two more CentOS or Ubuntu VM's running Alpha in one and Vax in
the other.

The interesting things that they've done is added in hooks for
virtualization  (SLAT).

Wikipedia says:
"Second Level Address Translation (SLAT), also known as nested paging, is
a hardware-assisted virtualization technology which makes it possible to
avoid the overhead associated with software-managed shadow page tables.

Intel's implementation of SLAT, known as Extended Page Table (EPT), was
introduced in the Nehalem microarchitecture found in certain Core i7,
Core i5, and Core i3 processors. AMD supports SLAT through the Rapid
Virtualization Indexing (RVI) technology since the introduction of its
third-generation Opteron processors (code name Barcelona)."

So they can let the hardware directly handle most this stuff instead of 
emulating page tables in memory.

My earlier 64 bit 2nd hand IBM AMD Opteron boxes didn't support this.
VMware emulated the needed stuff in software, but Windows and Citrix
Xen server required the hardware to virtualize 64 bit servers.  

If you have a recent chip and bios Windows 8 has full HyperV built in
and can do all this virtualization on your desktop.

The Server version has more management functions like hot migration.
Guess they think you're not likely to need that on your desktop.

If I could get VMS up on this Lenovo D20 I'd love it.
I'd love to see how much load I could get on it with a mix of Windows,
Linux and VMS.

Perhaps even some RT11, RSTS/E and RSX.

It's nice to spin up a new vm when you need a test/development box.
Just copy a disk image with the preinstalled working OS and fire it up.

Delete it when you no longer need it.  One install for the OS is all you
ever need to do.


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/5/2014 4:58:19 AM
In article <7ISdnRdmEZSawH3OnZ2dnUVZ_qednZ2d@mchsi.com>,
John E. Malmberg <wb8tyw@qsl.network> wrote:
>
>A VM allows you to run multiple versions of an OS on the same hardware 
>simultaneously.  You can set up a cluster in a box.
>
>Run out of proseccnt or other sysgen parameter?  If your development is 
>on a VM, it is the only one affected by the reboot.
>
>Here is the reality though for an x86 VMS port.
>
>    * If you target VMware/Hyper/V/KVM only you will always have
>      device driver support for all major network and storage
>      available from the hardware vendor.
>
>    * If you write your own drivers, you either have to get
>      pre-production hardware to develop against, or you
>      will be writing drivers for hardware that is probably
>      not being produced.  By the time a hardware card is
>      available retail, that version is no longer being
>      produced.
>      It will take you longer to write.
>      It will cost more.
>      It will not be as versatile.
>      It probably will not give significantly better performance.
>
>So even if you only intend to ever run a single instance of VMS/x86 
>there is a cost advantage to targeting a hypervisor with paravirtualized 
>drivers instead of a native drivers.
>
>Except for bragging rights, there is no advantage to targeting bare 
>metal with out a hypervisor.  It is just simply more initial work and 
>more on-going maintenance.  And it probably will not make a difference 
>in the number of paying customers.
>
>There will be paying customers that just want it to work fast and not 
>care if there is or is not a hypervisor underneath it.
>
>There will be paying customers that will not purchase unless it can run 
>on at least one of the major hypervisors.
>
>This is stuff that the x86 world has been taking for granted for years now.
>
>Regards,
>-John
>

And if it runs on HyperV and VMware and VirtualBox any Windows 8 box, 
Linux box with Virtual box or both with VMware Workstation can be a
programmer's development box.


Imagine the ability to work on the road on a portable Thinkpad with
a test cluster and compile environment running in a virtual network for
testing... and the ability to hook that directly into the customers
network for data migration... also the ability to host this anywhere in
the world... Including the "Cloud."

Suddenly VMS gets to be a serious option making all of those Gartner
checkboxes again.


VMS:  Tried and True Security.  Tested.  Proven over decades.

VMS:
Develop and test on Virtual -- deploy on hardware, virtual or cloud.

Nice for smaller VAR's and Software Houses to develop with software only 
costs.

No large noisy hardware.   The 12 core box I've got running (with
Hyperthreading it looks like 24)... is next to the bed and it's so quiet
I can talk on the phone and hear the TV when it runs.  It's quieter than
my P4 desktop.  The Intel folks spent a lot of cash making the cpu
throttle back and shut down unused sections when it doesn't need to run
all the cores.


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/5/2014 5:20:39 AM
On 8/4/2014 2:40 PM, David Froble wrote:
> John E. Malmberg wrote:
>
>> A new x86 server OS that is not hypervisor aware is essentially DOA
>> for commercial sales.  So it is a necessary layer.
>
> John, you're a rather astute guy, I formed that opinion lo those many
> years ago in the first 10 minutes of talking to you.  But the above
> statement seems to lack any justification.  Can you defend it a bit,
> specify situations where it's factual, and such?

Disclaimer:  I work for Riverbed.com which is selling solutions that 
make it more practical to use VMs for location independent solutions in 
addition to other network and storage optimizations.

While I can not mention specific installations, the trend is definitely 
to running on hypervisors with VMs deployed the way that on timesharing 
you would have deployed a set of processes instead of dedicated servers.

The difference is that you can not assign a network address to a process 
tree and move the process tree to different hardware.

VMs do not solve all problems, but they solve some significant issues.

> I'll admit, my perception, quite likely wrong, is that the various VM
> type of environments were developed to support the weendoze concept of
> one application, one server.  Right or wrong, the perception was that
> weendoze didn't support multiple applications near as well as other
> environments.

VMs started there, but did not start to really take off until the server 
hardware got much faster than what the applications needed and SANS 
became more low cost.

Then someone figured out that since a VM was essentially a process, they 
could swap the process out to the SAN, and then swap it in on a 
different hardware chassis almost simultaneously, and then you got an 
additional benefit.  You could now load balance on the fly, including 
adding additional hardware.

Now many applications do not need to be migrated hot, but it an 
impressive feature to help sell the feature.

Hot migrations do not solve system crashes or sudden hardware failures, 
having redundancy solves that.  VMs and replicated storage make it 
easier to have redundancy.

So what started out as as hack to support one application/one server 
ended up adding critical business continuity features.

There also used to be a performance penalty for running in a VM.  With 
the newer chipsets and paravirtualization, this is no longer the case.

> I've never used a VM, cannot know what I'm missing.  But I also don't
> seem to suffer from the lack.

A skilled programmer can implement things on just about any platform.

> And maybe this isn't the right place for a possibly far reaching
> discussion ....

An on topic discussion here?

Regards,
-John


0
John
8/5/2014 5:21:11 AM
On 2014-08-05 00:50, oboguev.public@gmail.com wrote:
> On Monday, August 4, 2014 2:14:12 AM UTC-7, Johnny Billquist wrote:
>
>> I don't see the problem, unless you are saying that the kernel can't get
>> write access without the user also having it, which I don't think is
>> correct (and I don't think you are saying that).
>
> x86/x64 PTE has two bitflags: one controls user-mode accessibility of
> the page, the other controls page writability. Thus x64 MMU does not
> provide a mode equivalent to URKW.

In which case we can simplify this discussion. The x86-64 then do not 
support URKW, which is also a protection mode used in VMS, unless I'm 
mistaken. No need to involve and discuss supervisor or executive mode.

Seems like that could be an interesting problem... Flip the write enable 
for the pages every time you go into kernel mode. A bit on the expensive 
side...

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/5/2014 8:06:06 AM
On Tuesday, 5 August 2014 05:58:19 UTC+1, William Pechter  wrote:
> In article <53dee7e1$0$55637$c3e8da3$b280bf18@news.astraweb.com>,
> 
> JF Mezei  <jfmezei.spamnot@vaxination.ca> wrote:
> 
> >On 14-08-03 17:23, John E. Malmberg wrote:
> 
> >
> 
> >> The commercial x86 server market is essentially going to being VMs on 
> 
> >> Hypervisors.  
> 
> 
> 
> Yup.
> 
> 
> 
> >This may seem like the logical way to go about it based on industry
> 
> >trends BUT...
> 
> >
> 
> >Initially, they will want to to talk to the installed base to see if
> 
> >hosting VMS on VMware or other is interesting to them. If they run
> 
> >mission critical apps, they may decide they prefer dedicated hardware,
> 
> >so the VMware support might come later rather than sooner.
> 
> 
> 
> It's also a way to to multiple VMS boxes on one piece of hardware.
> 
> Buy one box and split it between customers or between development and
> 
> test and production...
> 
> 
> 
> >On the other hand, how much special kludges are needed at the OS level
> 
> >to run as an instance under VMware ? Does VMware present a totally
> 
> >vanilla hardware environment or does the OS need special drivers ?
> 
> 
> 
> 
> 
> It depends... VMware ESX and ESXi used to pretty standard emulation of
> 
> standard PC platforms. Intel chips, vga video.  No fancy driver loads
> 
> were required.  They emulated National Semiconductor NICS, or DEC Tulip
> 
> or now sometimes even Intel E1000.
> 
> 
> 
> At one point they just were emulation pretty standard generic Pentium
> 
> boxes with Intel chipsets.  They've gotten much more hardware assist
> 
> built into the Intel CPU's to allow a lot less emulation and 
> 
> more virtualization at the actual cpu chip level.
> 
> 
> 
> You now have the Linux drivers building in virtualization drivers that
> 
> don't have to go through the layers of emulation of the NCR/LSI scsi
> 
> card and drivers.  The paravirtualized drivers talk directly to the
> 
> Virtualization stuff in the hypervisor...
> 
> 
> 
> On VMware you chose which drivers to use when defining the VM.
> 
> (Checkboxes in the gui...) for OS's without the support of that layer
> 
> they either emulate the LSI SAS/Paralel scsi (two different checks) or
> 
> the really old one from Bus Logic (199x vintage).
> 
> 
> 
> If you pick the right mix for your OS -- you can run it with no driver
> 
> changes.  For performance reasons VMware has a couple of drivers you can
> 
> replace the standard windows ones with that are better performing in the
> 
> VMware environment.
> 
> 
> 
> The storage can be ISCSI, SAN, NFS, local disks...
> 
> 
> 
> One nice feature of the VMware approach (which is also copied by
> 
> Microsoft in their new HyperV in Server 2012R2) is the hot migration of
> 
> the virtual machine and it's memory and storage from one location
> 
> (machine, san, memory) to another...  There's a slight slowing of the
> 
> machine during the migration -- but the users don't think it's much
> 
> beyond peak load.
> 
> 
> 
> So if the site catches fire you pull the switch and the running systems
> 
> migrate completely to the backup data center at your next location.  
> 
> 
> 
> I've done this on VMware ESX and only dropped one or two pings during
> 
> the migration to the datacenter in the next building.
> 
> 
> 
> If you can do this live without clustering you can provide additional
> 
> redundancy.  You also could run VAX clusters on top of ESX and get the
> 
> additional features.
> 
> 
> 
> I've got a Lenovo box here with dual 6 core Xeons.   I had 2 copies of 
> 
> Windows 2012R2 running (one as a VM) and two CentOS linux boxes
> 
> installing (Centos6 and 7) and the machine didn't break a sweat.  Next
> 
> step is two more CentOS or Ubuntu VM's running Alpha in one and Vax in
> 
> the other.
> 
> 
> 
> The interesting things that they've done is added in hooks for
> 
> virtualization  (SLAT).
> 
> 
> 
> Wikipedia says:
> 
> "Second Level Address Translation (SLAT), also known as nested paging, is
> 
> a hardware-assisted virtualization technology which makes it possible to
> 
> avoid the overhead associated with software-managed shadow page tables.
> 
> 
> 
> Intel's implementation of SLAT, known as Extended Page Table (EPT), was
> 
> introduced in the Nehalem microarchitecture found in certain Core i7,
> 
> Core i5, and Core i3 processors. AMD supports SLAT through the Rapid
> 
> Virtualization Indexing (RVI) technology since the introduction of its
> 
> third-generation Opteron processors (code name Barcelona)."
> 
> 
> 
> So they can let the hardware directly handle most this stuff instead of 
> 
> emulating page tables in memory.
> 
> 
> 
> My earlier 64 bit 2nd hand IBM AMD Opteron boxes didn't support this.
> 
> VMware emulated the needed stuff in software, but Windows and Citrix
> 
> Xen server required the hardware to virtualize 64 bit servers.  
> 
> 
> 
> If you have a recent chip and bios Windows 8 has full HyperV built in
> 
> and can do all this virtualization on your desktop.
> 
> 
> 
> The Server version has more management functions like hot migration.
> 
> Guess they think you're not likely to need that on your desktop.
> 
> 
> 
> If I could get VMS up on this Lenovo D20 I'd love it.
> 
> I'd love to see how much load I could get on it with a mix of Windows,
> 
> Linux and VMS.
> 
> 
> 
> Perhaps even some RT11, RSTS/E and RSX.
> 
> 
> 
> It's nice to spin up a new vm when you need a test/development box.
> 
> Just copy a disk image with the preinstalled working OS and fire it up.
> 
> 
> 
> Delete it when you no longer need it.  One install for the OS is all you
> 
> ever need to do.
> 
> 
> 
> 
> 
> Bill
> 
> -- 
> 
> -- 
> 
> Digital had it then.  Don't you wish you could buy it now!
> 
> pechter-at-pechter.dyndns.org        http://xkcd.com/705/

"VMware ESX and ESXi used to pretty standard emulation of standard
PC platforms. Intel chips, vga video."

Don't get me wrong, I think what can be done with VMware etc is truly
amazing. I've been using Player on the desktop at work for years because
the IT department is Linux-intolerant and some things just don't work
(or don't work well) on a Window box; sometimes Cygwin isn't usable.
VMware player came to an end when it became a paid-for option and therefore visible to IT.

I have also had occasion to try ESX(i). A colleague and I were
trialling ESX(i), already widely used in the IT department and the
industry at large. Like others, we had a requirement for a handful (three?
five?) of instances to be used for dev + test + support ("crash+burn") 
purposes, and wanted to understand how well they'd work if virtualised.

We were gathering performance evidence, as anyone wanting to make an
objective decision (rather than being a fashion victim) would. 

All looked good, as you'd expect, till we started looking at performance.
Some of the workloads in question were bottlenecked by disk IO in the
real world. In the hyper world, serious weirdness was observed. With one
VM on the host, near-native IO performance was observed. With four
VMs enabled, disk IO per VM was limited to ~one quarter of the native
rate, EVEN IF THREE OF THE VMs WERE IDLE. We also tried with other numbers
of VM instances.

In each case, what we saw was as though ESX had decided to allocate a
disk IO quota per VM; in the interests of "fairness" it would take the
system's native IO capability and divide it equally between each instance.
And you got no more than your quota even if others weren't using theirs.
A bit like virtual memory quotas in the early days of VAX/VMS maybe?

None of the local IT staff, or their backups, or the Interweb, appeared
to be willing or able to explain this.

Maybe things have changed since then, but it was at that point that me
and my colleague doing the testing decided that whatever the HYPErvisor
fanbois may tell you, there are potentially downsides to adding this extra
layer of complexity without someone being able to help you understand it.

One of the IO-bound tasks was building gcc etc from source and running
the Ada compiler validation suite, so not your usual LAMP or other 
mainstream-for-x86 Linux/Windows stuff.

With native VMS, what you see can generally be explained, even if you
don't like it.
0
johnwallace4
8/5/2014 8:15:48 AM
On 2014-08-05 06:58, William Pechter wrote:
[...]
> If I could get VMS up on this Lenovo D20 I'd love it.
> I'd love to see how much load I could get on it with a mix of Windows,
> Linux and VMS.
>
> Perhaps even some RT11, RSTS/E and RSX.

They don't run on x86, and I don't expect they ever will.

But VMs work fine with both VMS and all the PDP-11 OSes already today.
simh is an example of that.

Paravirtualization is just a thing to make it go a bit faster. It is not 
a binary thing. Virtual machines can boot VMS already today, and have 
always been able to. VMS do not have to do a single thing to make this 
happen.
But from a performance perspective it would probably be a good thing if 
VMS got adapted to the paravirtualization world as one piece of an 
x86-64 port.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
0
Johnny
8/5/2014 8:19:51 AM
William Pechter wrote 2014-08-05 06:58:

> It's nice to spin up a new vm when you need a test/development box.
> Just copy a disk image with the preinstalled working OS and fire it up.
>

How long does it take to get a license for that new instance?
Or are you running as hobbyist?
Or do you foresee some major changes in the licensing scheme?


0
Jan
8/5/2014 8:37:54 AM
In article <Y+iJlP48Nu2F@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>In article <53deed47$0$49532$c3e8da3$fdf4f6af@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> 
>> Question: any discussion on resurecting DECUS ?
>
>   Good question.  Is VSI going to use Compass, or try to re-create
>   something like DECUS?
>
>   I heard in the conference that VSI would be providing support
>   for the DECUSserve environment.  Can I assume EISNER is going
>   to physically move?

Eisner made a physical move months ago.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/5/2014 10:08:17 AM
On 2014-08-05 08:37:54 +0000, Jan-Erik Soderholm said:

> William Pechter wrote 2014-08-05 06:58:
> 
>> It's nice to spin up a new vm when you need a test/development box.
>> Just copy a disk image with the preinstalled working OS and fire it up.
>> 
> 
> How long does it take to get a license for that new instance?
> Or are you running as hobbyist?
> Or do you foresee some major changes in the licensing scheme?

HP was selling the little-known iCAP licensing, which is on the way to 
dynamic licensing.

But yes, it'd be nice if VMS and its licensing and LMF were updated to 
modern norms, and where we could get a per-box license, or some sort of 
site or bulk licensing, or dynamic licensing with a pool of local 
licenses, or a way to query the VSI licensing servers and purchase a 
license.  Something closer to current VM-friendly licensing than to the 
state-of-the-1990-art solution that is LMF.

It'd be nice if there was a VSI web page where I could purchase a 
license PAK or a support contract, but I'm not getting my hopes up. :-)


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 11:49:13 AM
On 2014-08-05 10:08:17 +0000,   VAXman-  @SendSpamHere.ORG said:

> In article <Y+iJlP48Nu2F@eisner.encompasserve.org>, 
> koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <53deed47$0$49532$c3e8da3$fdf4f6af@news.astraweb.com>, JF 
>> Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>> 
>>> Question: any discussion on resurecting DECUS ?
>> 
>> Good question.  Is VSI going to use Compass, or try to re-create
>> something like DECUS?
>> 
>> I heard in the conference that VSI would be providing support for the 
>> DECUSserve environment.  Can I assume EISNER is going to physically 
>> move?
> 
> Eisner made a physical move months ago.

Yes, but...

Barring remote support, the EISNER:: AlphaServer DS20 box might be 
making a move from Nemonix in Northborough MA to VSI in Bolton MA, 
unless the VSI datacenter and network was (quietly) online ~five months 
ago and that DS20 was actually delivered to "an undisclosed location".

Relocating a DS20 from Northborough to Bolton is easily possible in an 
afternoon — probably in a couple of hours, if you pushed it — assuming 
some time to prepare the power, rack and network in Bolton, and to drop 
the DNS TTL setting, and some backups performed in Northborough as a 
precaution.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 12:04:21 PM
On Tuesday, August 5, 2014 12:58:19 AM UTC-4, William Pechter wrote:
> In article <53dee7e1$0$55637$c3e8da3$b280bf18@news.astraweb.com>,
>=20
> JF Mezei  <jfmezei.spamnot@vaxination.ca> wrote:
>=20
> >On 14-08-03 17:23, John E. Malmberg wrote:
>=20
> >
>=20
> >> The commercial x86 server market is essentially going to being VMs on=
=20
>=20
> >> Hypervisors. =20
>=20
>=20
>=20
> Yup.
>=20
>=20
>=20
> >This may seem like the logical way to go about it based on industry
>=20
> >trends BUT...
>=20
> >
>=20
> >Initially, they will want to to talk to the installed base to see if
>=20
> >hosting VMS on VMware or other is interesting to them. If they run
>=20
> >mission critical apps, they may decide they prefer dedicated hardware,
>=20
> >so the VMware support might come later rather than sooner.
>=20
>=20
>=20
> It's also a way to to multiple VMS boxes on one piece of hardware.
>=20
> Buy one box and split it between customers or between development and
>=20
> test and production...
>=20
>=20
>=20
> >On the other hand, how much special kludges are needed at the OS level
>=20
> >to run as an instance under VMware ? Does VMware present a totally
>=20
> >vanilla hardware environment or does the OS need special drivers ?
>=20
>=20
>=20
>=20
>=20
> It depends... VMware ESX and ESXi used to pretty standard emulation of
>=20
> standard PC platforms. Intel chips, vga video.  No fancy driver loads
>=20
> were required.  They emulated National Semiconductor NICS, or DEC Tulip
>=20
> or now sometimes even Intel E1000.
>=20
>=20
>=20
> At one point they just were emulation pretty standard generic Pentium
>=20
> boxes with Intel chipsets.  They've gotten much more hardware assist
>=20
> built into the Intel CPU's to allow a lot less emulation and=20
>=20
> more virtualization at the actual cpu chip level.
>=20
>=20
>=20
> You now have the Linux drivers building in virtualization drivers that
>=20
> don't have to go through the layers of emulation of the NCR/LSI scsi
>=20
> card and drivers.  The paravirtualized drivers talk directly to the
>=20
> Virtualization stuff in the hypervisor...
>=20
>=20
>=20
> On VMware you chose which drivers to use when defining the VM.
>=20
> (Checkboxes in the gui...) for OS's without the support of that layer
>=20
> they either emulate the LSI SAS/Paralel scsi (two different checks) or
>=20
> the really old one from Bus Logic (199x vintage).
>=20
>=20
>=20
> If you pick the right mix for your OS -- you can run it with no driver
>=20
> changes.  For performance reasons VMware has a couple of drivers you can
>=20
> replace the standard windows ones with that are better performing in the
>=20
> VMware environment.
>=20
>=20
>=20
> The storage can be ISCSI, SAN, NFS, local disks...
>=20
>=20
>=20
> One nice feature of the VMware approach (which is also copied by
>=20
> Microsoft in their new HyperV in Server 2012R2) is the hot migration of
>=20
> the virtual machine and it's memory and storage from one location
>=20
> (machine, san, memory) to another...  There's a slight slowing of the
>=20
> machine during the migration -- but the users don't think it's much
>=20
> beyond peak load.
>=20
>=20
>=20
> So if the site catches fire you pull the switch and the running systems
>=20
> migrate completely to the backup data center at your next location. =20
>=20
>=20
>=20
> I've done this on VMware ESX and only dropped one or two pings during
>=20
> the migration to the datacenter in the next building.
>=20
>=20
>=20
> If you can do this live without clustering you can provide additional
>=20
> redundancy.  You also could run VAX clusters on top of ESX and get the
>=20
> additional features.
>=20
>=20
>=20
> I've got a Lenovo box here with dual 6 core Xeons.   I had 2 copies of=20
>=20
> Windows 2012R2 running (one as a VM) and two CentOS linux boxes
>=20
> installing (Centos6 and 7) and the machine didn't break a sweat.  Next
>=20
> step is two more CentOS or Ubuntu VM's running Alpha in one and Vax in
>=20
> the other.
>=20
>=20
>=20
> The interesting things that they've done is added in hooks for
>=20
> virtualization  (SLAT).
>=20
>=20
>=20
> Wikipedia says:
>=20
> "Second Level Address Translation (SLAT), also known as nested paging, is
>=20
> a hardware-assisted virtualization technology which makes it possible to
>=20
> avoid the overhead associated with software-managed shadow page tables.
>=20
>=20
>=20
> Intel's implementation of SLAT, known as Extended Page Table (EPT), was
>=20
> introduced in the Nehalem microarchitecture found in certain Core i7,
>=20
> Core i5, and Core i3 processors. AMD supports SLAT through the Rapid
>=20
> Virtualization Indexing (RVI) technology since the introduction of its
>=20
> third-generation Opteron processors (code name Barcelona)."
>=20
>=20
>=20
> So they can let the hardware directly handle most this stuff instead of=
=20
>=20
> emulating page tables in memory.
>=20
>=20
>=20
> My earlier 64 bit 2nd hand IBM AMD Opteron boxes didn't support this.
>=20
> VMware emulated the needed stuff in software, but Windows and Citrix
>=20
> Xen server required the hardware to virtualize 64 bit servers. =20
>=20
>=20
>=20
> If you have a recent chip and bios Windows 8 has full HyperV built in
>=20
> and can do all this virtualization on your desktop.
>=20
>=20
>=20
> The Server version has more management functions like hot migration.
>=20
> Guess they think you're not likely to need that on your desktop.
>=20
>=20
>=20
> If I could get VMS up on this Lenovo D20 I'd love it.
>=20
> I'd love to see how much load I could get on it with a mix of Windows,
>=20
> Linux and VMS.
>=20
>=20
>=20
> Perhaps even some RT11, RSTS/E and RSX.
>=20
>=20
>=20
> It's nice to spin up a new vm when you need a test/development box.
>=20
> Just copy a disk image with the preinstalled working OS and fire it up.
>=20
>=20
>=20
> Delete it when you no longer need it.  One install for the OS is all you
>=20
> ever need to do.
>=20
>=20
>=20
>=20
>=20
> Bill
>=20
> --=20
>=20
> --=20
>=20
> Digital had it then.  Don't you wish you could buy it now!
>=20
> pechter-at-pechter.dyndns.org        http://xkcd.com/705/

Bill,

Essentially the argument I made at an earlier point with the use of HPVM on=
 Itanium from my presentation from the 2011 OpenVMS Bootcamp "Evolving Open=
VMS Environments: An Exercise In Continuous Computing" (slides and audio tr=
ack available at http://rlgsc.com/openvms-bootcamp/2011/continuous-openvms.=
html ). This presentation, which is a slight revision of my presentation fr=
om the 2009 Connect Symposium, noted several strategic advantages to using =
VMs for hosting OpenVMS.

"Climbing the Spiral: A Better Rightsizing Paradigm" (November 2010) and " =
Soloist OpenVMS Clusters: A New Perspective to Improve Functionality,... (J=
anuary 2010) entries in my OpenVMS.org column contributed to this revision.=
 When all the elements of these are combined, one realizes that one can use=
 a VM to provide fractional machine provisioning of an OpenVMS soloist VMSc=
luster as a prototyping base, with seamless expansion to a two-node VMSclus=
ter and beyond.

OpenVMSclusters and Virtual Machines are essentially orthogonal concepts ar=
chitecturally, with some areas of overlap in functionality.

In the case of virtual machines, they offer political, budgetary, and techn=
ical advantages.

To move the discussion forward, I am starting a new thread in comp.os.vms, =
directly on the use of OpenVMS on VMs.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/5/2014 12:05:37 PM
In article <lrpfs1$2qu$3@dont-email.me>,
	David Froble <davef@tsoft-inc.com> writes:
> Johnny Billquist wrote:
>> On 2014-08-04 15:21, Bill Gunshannon wrote:
>>> In article <IjTCv.136775$AN6.25160@fx01.iad>,
>>>     =?windows-1252?Q?=22Ro=DFert_G=2E_Schaffrath=22?=   
>>> <rschaffrath@yahoo.com> writes:
>>>> On 8/1/2014 1:19 PM, Bob Koehler wrote:
>>>>> In article <c3vde9FkpavU1@mid.individual.net>, 
>>>>> bill@server3.cs.scranton.edu (Bill Gunshannon) writes:
>>>>>>
>>>>>> I never expected HP to swallow their ego and let this go.  I am not
>>>>>> familiar with VSI so have no idea how big they are or what resources
>>>>>> they have to carry this out.  Any chance that this is an opportunity
>>>>>> for some of the big guns here to get positions as employees or sub-
>>>>>> contractors to bring some of the collected knowledge and experience
>>>>>> back into the corral?
>>>>>
>>>>>      I think they already said so in thier announcements.  And I
>>>>>      appreciate that there's a connection to Nmemonix.
>>>>>
>>>>>      IMHO, that gives them lots of credibility.
>>>>>
>>>>
>>>> I just hope that VMS thrives and does not wind up like RSTS/E under
>>>> Mentec.  That basically fizzled.
>>>
>>> How did it fizzle?  Mentec continued to maintain it and even did all the
>>> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
>>> I think all three PDP-11 OSes had longer lives under Mentec than they had
>>> under DEC.
>> 
>> Not really. Active development continued for about 5 years at Mentec, 
>> and then another 10 years of slow death. They did live longer at DEC,
>> 
>> But I agree that it's a bit unfair to just say they fizzled at Mentec.
>> However, RSTS/E might have gotten the least attention of all of them at 
>> Mentec.
>> 
>>     Johnny
>> 
> 
> When VMS matured, it provided all of the capabilities of RSTS/E.  Hey, I 
> used RSTS/E for a number of years, and I liked it.  But VMS was better. 
>   That could be a good reason RSTS/E didn't flourish.

Let me have the source so I can do an x86-64 port and we'll see.  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 12:21:09 PM
In article <lroguv$s4h$1@dont-email.me>,
	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
>> Bill Gunshannon wrote:
>>> In article <lrnsof$vr0$4@dont-email.me>,
>>> 	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>>
>>>>>> 2. Big enough to sue - a business that was announced four days ago.  Lets get a little positive karma here.
>>>>>
>>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>>> installed base who have mission critical systems.
>>>>>
>>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>>
>>> 
>>> Well, let me be the ne with something positive to say for a change...
>>> 
>>> "Big enough to sue"?  And people here think I am cynical!!!
>>> 
> 
> It's called being realistic. The senior manager in a large company is not
> emotionally involved with VMS. What they want to know about the proposed
> solution on their desk is what happens when something goes wrong and
> _their_ boss starts asking when the problem is going to be fixed.
> 
> That's the reality of life in production business environments and that's
> why it's so important that the contract on that desk can be with HP and
> not VSI.
> 
> BTW, I can see you have never being exposed to normal commercial business
> concerns. :-)

Yeah, I guess all that pre and post sale stuff on multi-million dollar
contracts at Martin Marietta doesn't count as "normal commercial business".
Why does everyone here think that because I have a dot edu address I have
no experience outside of academia?

> 
>>>> Exactly JF. VSI doesn't need to convince the comp.os.vms readers, it
>>>> needs to convince the senior managers in those large corporations.
>>>>
>>>> And those managers ask a very different set of questions to the
>>>> technical questions asked around here... :-)
>>> 
>>> All true, but the fact is this is a potential path into the future and
>>> HP was offering none.  I would think that anyone who is locked in to
>>> VMS, for whatever reason, is going to be happy to hear this announcement.
>>> For one thing, I expect that, unless they do something really dumb, VSI
>>> will have one other thing that HP lost a long time ago, credibility!!
>>> 
>>> bill
>>> 
>>
>> I'd think that the simple fact they are putting their money and efforts 
>> where many of us have always wished for money and effort is instant 
>> credibility.
> 
> On an emotional/technical level for VMS technical people, yes.
> 
> For everyone else, a primary question about the proposed solution on
> that manager's desk will be what happens when the critical production
> system is down and is the vendor large enough to be held to account ?

If their concern is where to lay the blame rather than getting the problem
fixed I would rather not do business with them.  I can assure you that "can
we sue them" was never a conern in picking sub-contractors for the very
large projects I was involved in before I "retired" to academia.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 12:26:11 PM
In article <c4c0r3F90b0U6@mid.individual.net>,
Bill Gunshannon <billg999@cs.uofs.edu> wrote:
>In article <lroguv$s4h$1@dont-email.me>,
>	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> On 2014-08-04, David Froble <davef@tsoft-inc.com> wrote:
>>> Bill Gunshannon wrote:
>>>> In article <lrnsof$vr0$4@dont-email.me>,
>>>> 	Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>>> On 2014-08-03, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>>>> On 14-08-03 21:33, Susan Skonetski wrote:
>>>>>>
>>>>>>> 2. Big enough to sue - a business that was announced four days
>ago.  Lets get a little positive karma here.
>>>>>>
>>>>>> Sue, this *may* be a valid concern for a portion of the remaining
>>>>>> installed base who have mission critical systems.
>>>>>>
>>>>>> "Big enough to sue" is more like "are they credible, can we bet our
>>>>>> billion dollar firm on this small group" etc. Not so much for suing.
>>>>>>
>>>> 
>>>> Well, let me be the ne with something positive to say for a change...
>>>> 
>>>> "Big enough to sue"?  And people here think I am cynical!!!
>>>> 
>> 
>> It's called being realistic. The senior manager in a large company is not
>> emotionally involved with VMS. What they want to know about the proposed
>> solution on their desk is what happens when something goes wrong and
>> _their_ boss starts asking when the problem is going to be fixed.
>> 
>> That's the reality of life in production business environments and that's
>> why it's so important that the contract on that desk can be with HP and
>> not VSI.
>> 
>> BTW, I can see you have never being exposed to normal commercial business
>> concerns. :-)
>
>Yeah, I guess all that pre and post sale stuff on multi-million dollar
>contracts at Martin Marietta doesn't count as "normal commercial business".
>Why does everyone here think that because I have a dot edu address I have
>no experience outside of academia?

OH no.  

I still get nightmares about a couple of 11/70's from one of their
projects.  Worst time I ever had in my Field Service days at DEC.

Computers on a schedule where the hardware acceptance could never be
completed on time since they were being run so far out of environmental
specs. Had to start at 10am and shut down by 2-3pm to avoid destroying
the machine.  

The warranty was violated by running them to tempest test them. 

Ten days to get them up and running so they could move them.  No air
conditioning for the tempest tests ad 94 degrees F...

Machines close to melt down at over 120 internal temp.

Worst VAR/OEM I ever worked with at DEC.  Normal install was 10 days.
We had less than that to assemble/test/validate/tear down.

Couldn't move the hardware without fork lifts.  Military tempest
cabinets...

Really rough couple of weeks.  Looked like I was taking a shower with my
close on.

>bill
>
>-- 
>Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
>billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
>University of Scranton   |
>Scranton, Pennsylvania   |         #include <std.disclaimer.h>   


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/5/2014 1:18:17 PM
In article <lrq43d$6jm$1@Iltempo.Update.UU.SE>,
Johnny Billquist  <bqt@softjar.se> wrote:
>On 2014-08-05 06:58, William Pechter wrote:
>[...]
>> If I could get VMS up on this Lenovo D20 I'd love it.
>> I'd love to see how much load I could get on it with a mix of Windows,
>> Linux and VMS.
>>
>> Perhaps even some RT11, RSTS/E and RSX.
>
>They don't run on x86, and I don't expect they ever will.

Well... some stripped down linux vm's that run the simh at boot and it's
as close as you can get.
>
>But VMs work fine with both VMS and all the PDP-11 OSes already today.
>simh is an example of that.

Yup.   And they're faaaasssst.

>Paravirtualization is just a thing to make it go a bit faster. It is not 
>a binary thing. Virtual machines can boot VMS already today, and have 
>always been able to. VMS do not have to do a single thing to make this 
>happen.
>But from a performance perspective it would probably be a good thing if 
>VMS got adapted to the paravirtualization world as one piece of an 
>x86-64 port.

I think it's necessary to push VMS into major companies that are
completely virtuallized.

There's a lot of them.

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

bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/5/2014 1:22:41 PM
In article <lrq552$gkg$1@news.albasani.net>,
Jan-Erik Soderholm  <jan-erik.soderholm@telia.com> wrote:
>William Pechter wrote 2014-08-05 06:58:
>
>> It's nice to spin up a new vm when you need a test/development box.
>> Just copy a disk image with the preinstalled working OS and fire it up.
>>
>
>How long does it take to get a license for that new instance?
>Or are you running as hobbyist?
>Or do you foresee some major changes in the licensing scheme?
>
>

Just a hobbyist here.  As far as the work stuff at the old job -- we had site
licenses for most of the Oracle/Windows stuff and about an extra 10 
licenses for RedHat Enterprise 3/4/5/6 and there's always CentOS for 
testing if the licenses ran out.

Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/5/2014 1:24:55 PM
William Pechter wrote 2014-08-05 15:24:
> In article <lrq552$gkg$1@news.albasani.net>,
> Jan-Erik Soderholm  <jan-erik.soderholm@telia.com> wrote:
>> William Pechter wrote 2014-08-05 06:58:
>>
>>> It's nice to spin up a new vm when you need a test/development box.
>>> Just copy a disk image with the preinstalled working OS and fire it up.
>>>
>>
>> How long does it take to get a license for that new instance?
>> Or are you running as hobbyist?
>> Or do you foresee some major changes in the licensing scheme?
>>
>>
>
> Just a hobbyist here.  As far as the work stuff at the old job -- we had site
> licenses for most of the Oracle/Windows stuff and about an extra 10
> licenses for RedHat Enterprise 3/4/5/6 and there's always CentOS for
> testing if the licenses ran out.
>
> Bill
>

OK. If it wasn't clear, I asked about VMS licenes. :-)


0
Jan
8/5/2014 1:38:47 PM
In article <2f8525a6-4dbd-4467-90fd-9d269362ef3f@googlegroups.com>,
	johnwallace4@yahoo.co.uk writes:
> On Monday, 4 August 2014 20:40:47 UTC+1, David Froble  wrote:
>> John E. Malmberg wrote:
>> 
>> 
>> 
>> > A new x86 server OS that is not hypervisor aware is essentially DOA for 
>> 
>> > commercial sales.  So it is a necessary layer.
>> 
>> 
>> 
>> John, you're a rather astute guy, I formed that opinion lo those many 
>> 
>> years ago in the first 10 minutes of talking to you.  But the above 
>> 
>> statement seems to lack any justification.  Can you defend it a bit, 
>> 
>> specify situations where it's factual, and such?
>> 
>> 
>> 
>> I'll admit, my perception, quite likely wrong, is that the various VM 
>> 
>> type of environments were developed to support the weendoze concept of 
>> 
>> one application, one server.  Right or wrong, the perception was that 
>> 
>> weendoze didn't support multiple applications near as well as other 
>> 
>> environments.
>> 
>> 
>> 
>> I've never used a VM, cannot know what I'm missing.  But I also don't 
>> 
>> seem to suffer from the lack.
>> 
>> 
>> 
>> And maybe this isn't the right place for a possibly far reaching 
>> 
>> discussion ....
>> 
>> 
>> 
>> Dave
> 
> "the various VM type of environments were developed to support the
> weendoze concept of one application, one server."
> 
> That, and the related problem of hardware sitting there near idle
> much of the time. Where's Kerry (he was on the concall)?
> 
> Other reasons I remember for x86 virtualisation included:
> 
> * no easy means for x86 hardware resource redeployment 
> * no easy means for x86 OS/application failover after hw or sw issue

These three reasons pretty much sum up our move to VM's.  After building
a new VM I export it to a thumbdrive and put it in the desk drawer.  If
I have a failure for any reason I merely import the VM on another Hyper-V
instance and we are back in operation.  And I have reduced 20-some servers
to about 8 physical boxes.

> 
> 
> Longstanding VMS customers are used to those last two being sorted
> without needing hypervisors, instead they're using ancient stuff like
> clusters (split-site if necessary), compatible hardware meaning stuff
> can be reallocated without major hassle (and for a while, Galaxy meaning
> stuff could be reallocated on the fly).
> 
> Where clusters weren't the answer, e.g. for rapid realtime failover,
> there were homebrew solutions. And for some classes of application there
> was Reliable Transaction Router.
> 
> All done without needing virtualisation. Why would that need to change now?

One reason being that they now have to be integrated and "works and plays
well with others" is an important line on the Maryland Test.  :-)
The datacenter has everything on VM's.  If VMS won't it will still be the
odd man out and it could mean really out.  The industry has changed.
If this is to be successful VMS needs to start looking a team player.

> 
> Obviously for the x86 market in general, virtualisation is a major
> consideration. Because the volume AMD64 OSes *can't* do this kind of
> stuff without virtualisation. VMS can, in the right circumstances.

Of course they can.  But common practices today say don't do that.
Maybe that's one of the reasons for the decline of VMS in the first
place.  People seeing it as not keeping up with common IT practices.
And saying, "All you people are wrong and we are right" does not win
friends and influence people.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 2:10:31 PM
On 2014-08-05 13:38:47 +0000, Jan-Erik Soderholm said:

> OK. If it wasn't clear, I asked about VMS licenes. :-)

That was quite clear.   Maybe ask this question of VSI more directly?

I wouldn't expect VSI to necessarily follow HP's licensing practices.

Until there are VSI products and services available, license and 
support prices known, and software licensing policies published, most 
folks posting here simply don't know the answer.

Some discussions of your organization's preferences and needs and of 
alternatives and options — held between your organization and VSI — are 
entirely reasonable.

The VSI folks are probably discussing and establishing these same 
prices and polices and details among themselves, too.   Even VSI may 
not have established and be entirely certain about these details quite 
yet.

On no evidence, it wouldn't surprise me to see another round of public 
announcements from VSI next month at the boot camp, and then 
particularly again around the time of the first VSI product 
availability.  This assuming that the Poulson and x86-64 ports aren't 
both tested and available by the end of next month. :-)



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 2:11:11 PM
Stephen Hoffman wrote 2014-08-05 16:11:
> On 2014-08-05 13:38:47 +0000, Jan-Erik Soderholm said:
>
>> OK. If it wasn't clear, I asked about VMS licenes. :-)
>
> That was quite clear.   Maybe ask this question of VSI more directly?

I was not asking VSI. I was asking the one who described how easy
it was to just copy a file and just fire up. Todays licencing
doesn't realy support that, apart from in a hobbyist environment.

[Triming the rather obvious licencing stuff...]

0
Jan
8/5/2014 2:24:29 PM
On 2014-08-05, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
> On Tuesday, 5 August 2014 05:58:19 UTC+1, William Pechter  wrote:

<loads of stuff snipped>

>
> "VMware ESX and ESXi used to pretty standard emulation of standard
> PC platforms. Intel chips, vga video."
>
> I have also had occasion to try ESX(i). A colleague and I were trialling
> ESX(i), already widely used in the IT department and the industry at
> large. Like others, we had a requirement for a handful (three? five?) of
> instances to be used for dev + test + support ("crash+burn") purposes,
> and wanted to understand how well they'd work if virtualised.
> >
> We were gathering performance evidence, as anyone wanting to make an
> objective decision (rather than being a fashion victim) would. 
> >
> All looked good, as you'd expect, till we started looking at
> performance. Some of the workloads in question were bottlenecked by disk
> IO in the real world. In the hyper world, serious weirdness was
> observed. With one VM on the host, near-native IO performance was
> observed. With four VMs enabled, disk IO per VM was limited to ~one
> quarter of the native rate, EVEN IF THREE OF THE VMs WERE IDLE. We also
> tried with other numbers of VM instances.
> >
> In each case, what we saw was as though ESX had decided to allocate a
> disk IO quota per VM; in the interests of "fairness" it would take the
> system's native IO capability and divide it equally between each
> instance. And you got no more than your quota even if others weren't
> using theirs. A bit like virtual memory quotas in the early days of
> VAX/VMS maybe?
> >
> None of the local IT staff, or their backups, or the Interweb, appeared
> to be willing or able to explain this.

Out of interest, which year was this?

In early 2011 I used the 30 day demo offered for VMware Workstation.  This
is a slightly different beast from ESX as it sits atop either Windows or
Linux (the licence is flexible in that the same key will work for both
host platforms, though you aren't supposed to swap on a continuous basis).

One of the best I/O stress tests I came across was to try doing a host
backup while installing Windows Server 2008.  Using either WS2008 or
Windows 7 as the host was completely reliable even if the system did grind
to a very slow pace, but Ubuntu as a host failed pretty spectacularly
under such heavy I/O, quickly becoming unusable.  The simplest performance
improvement could be gained by putting the VM files onto a non-system disk,
and before SSDs became affordable my recommendation for anyone wanting
a laptop for running VMs was to get one with 2 disks (which incidentally
meant I couldn't recommend Apple laptops for such users unless they really
wanted OS X).

Now, VMware Workstation at the time was boasting the ability of being able
to run Windows clients simultaneously with more RAM allocated in total
than the host machine had available.  This was done via a paging mechanism.

Similar to your ESX I/O quota example, even running only one client with
plenty of free RAM in the host still caused a lot of paging using VMware's
own pagefiles.  This slowed things down considerably and reminded me of
trying to run a process on VMS with insufficient working set quotas.

Like you I came up with a blank when enquiring how to switch this paging
off.  The nearest I came to an answer was a guy who claimed it could be 
done easily but backed out when I asked how.

Net result: I went back to using VirtualBox because that gave me better
performance (though it doesn't have nice features such as record and
playback or the extended ability to create virtual networks).

Incidentally, the Resource Monitor in Windows enabled me to locate the
VMware pagefiles quickly and see exactly how much read and write I/O was
hitting them.  No such luck with Linux as a host.  I did a bit of digging
on this front and was rather surprised to find a lack of anything remotely
resembling what VMS Monitor gives in I/O statistics.  Furthermore it
transpired that the most common filesystem benchmark performed by the
Linux filesystem developers was unpacking the kernel source tree.  The
only other significant benchmarking I could find at that time was from an
XFS filesystem developer, but here again he was only interested in file
creation, and he was busy benchmarking the time it took to create a
billion *empty* files.

(Yes I have since been pointed at the Linux sar utility, but what I wanted
was a GUI display - not too much to ask I would have thought)

Two other points about my VMware Workstation demo:

1. At the time this product claimed that certain Windows components could
   be shared between the host and clients.  Since I was running dissimilar
   versions of Windows as host and client I don't think I could take
   advantage of this.
2. Beware time zones (yet again).  I applied for my VMware demo licence
   bright and early in the day my time, but it was still yesterday for
   the VMware servers so I ended up with a 29 day demo!

> Maybe things have changed since then, but it was at that point that me
> and my colleague doing the testing decided that whatever the HYPErvisor
> fanbois may tell you, there are potentially downsides to adding this
> extra layer of complexity without someone being able to help you
> understand it.

I'm pretty certain things have changed.  A lot of people (MS included) have
been putting a lot of effort into this area.

However, there's still a lot of smoke and mirrors.  I have VMware Fusion
V5 for my Mac, bought a year ago. When V6 arrived a few months later, not
only had the price been increased by a significant amount but they seem
unable to give me hard reasons to part with any upgrade money. "50 new
features" means absolutely nothing when they seem incapable of listing
even one of them.  Similarly "better for OS X Mavericks" doesn't mean much
either if they refuse to give any more information.

They've managed to hit my stubborn streak here, and I have to ask if
complacency is rearing its ugly head.

> One of the IO-bound tasks was building gcc etc from source and running
> the Ada compiler validation suite, so not your usual LAMP or other
> mainstream-for-x86 Linux/Windows stuff.
>
> With native VMS, what you see can generally be explained, even if you
> don't like it.

The lack of this ability is indeed frustrating.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/5/2014 2:28:54 PM
On 2014-08-05 14:24:29 +0000, Jan-Erik Soderholm said:

> Stephen Hoffman wrote 2014-08-05 16:11:
>> On 2014-08-05 13:38:47 +0000, Jan-Erik Soderholm said:
>> 
>>> OK. If it wasn't clear, I asked about VMS licenes. :-)
>> 
>> That was quite clear.   Maybe ask this question of VSI more directly?
> 
> I was not asking VSI. I was asking the one who described how easy it 
> was to just copy a file and just fire up. Todays licencing doesn't 
> realy support that, apart from in a hobbyist environment.

Today's VMS licensing is not relevant until and unless VSI states it is.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 2:41:02 PM
Stephen Hoffman wrote 2014-08-05 16:41:
> On 2014-08-05 14:24:29 +0000, Jan-Erik Soderholm said:
>
>> Stephen Hoffman wrote 2014-08-05 16:11:
>>> On 2014-08-05 13:38:47 +0000, Jan-Erik Soderholm said:
>>>
>>>> OK. If it wasn't clear, I asked about VMS licenes. :-)
>>>
>>> That was quite clear.   Maybe ask this question of VSI more directly?
>>
>> I was not asking VSI. I was asking the one who described how easy it was
>> to just copy a file and just fire up. Todays licencing doesn't realy
>> support that, apart from in a hobbyist environment.
>
> Today's VMS licensing is not relevant until and unless VSI states it is.
>
>

Today's VMS licensing is relevant until VSI states it isn't.


0
Jan
8/5/2014 2:45:36 PM
In article <cf058918-b73c-40e5-bd3d-1e900094e435@googlegroups.com>,
	johnwallace4@yahoo.co.uk writes:
> On Monday, 4 August 2014 23:35:13 UTC+1, Stephen Hoffman  wrote:
>> On 2014-08-04 19:40:47 +0000, David Froble said:
>> 
>> 
>> 
>> > John E. Malmberg wrote:
>> 
>> > 
>> 
>> >> A new x86 server OS that is not hypervisor aware is essentially DOA for 
>> 
>> >> commercial sales.  So it is a necessary layer.
>> 
>> > 
>> 
>> > John, you're a rather astute guy, I formed that opinion lo those many 
>> 
>> > years ago in the first 10 minutes of talking to you.  But the above 
>> 
>> > statement seems to lack any justification.  Can you defend it a bit, 
>> 
>> > specify situations where it's factual, and such?
>> 
>> 
>> 
>> VMs are how most businesses run stuff these days whether locally or 
>> 
>> hosted, and VMs are all over the place on OS X, Linux and Windows.
>> 
>> 
>> 
>> If your OS can't boot and run as a guest, you'll need your own 
>> 
>> hardware, and that'll make you unpopular with a number of environments.
>> 
>> 
>> 
>> There were a number of folks running VMS on HP-VM on HP-UX on Itanium, too.
>> 
>> 
>> 
>> > I'll admit, my perception, quite likely wrong, is that the various VM 
>> 
>> > type of environments were developed to support the weendoze concept of 
>> 
>> > one application, one server.  Right or wrong, the perception was that 
>> 
>> > weendoze didn't support multiple applications near as well as other 
>> 
>> > environments.
>> 
>> 
>> 
>> Need to restart some part of production due to a problem?  Roll in a 
>> 
>> fresh VM image.  It's wicked handy to blast an image in or out for 
>> 
>> development and testing, too.
>> 
>> 
>> 
>> They're also useful for application prototypes and for OS development 
>> 
>> work, as well.
>> 
>> 
>> 
>> > I've never used a VM, cannot know what I'm missing.  But I also don't 
>> 
>> > seem to suffer from the lack.
>> 
>> 
>> 
>> They're very handy to have around.
>> 
>> 
>> 
>> Maybe if you think of them as "virtual servers"?  Could having a dozen 
>> 
>> or a hundred servers around -- without chewing up an equivalent amount 
>> 
>> of budget, power or cooling, and that can be loaded and reloaded very 
>> 
>> quickly -- be handy for hacking around?
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 
>> Pure Personal Opinion | HoffmanLabs LLC
> 
> Devil's advocate time.
> 
> "Need to restart some part of production due to a problem?  Roll in a
> fresh VM image.  It's wicked handy to blast an image in or out for
> development and testing, too. "
> 
> A bit like DEC's Remote System Manager product could do. Or even just
> an InfoServer and a few bits and pieces? When was that, 1990s?
> 
> A VMS setup didn't need to fake the hardware; the OS itself was
> perfectly capable of running on a host that wasn't 100% identical with
> the host where it was originally installed. Not so lucky if you're
> on x86/Windows on kit with different (incompatible) core hardware.

But that took an entire hardware platform and the stuff that VMS ran on
wasn't cheap.  Try convincing your CFO to drop tens of thousands of dollars
so you can do a "proof of concept".

> 
> 
> "They're also useful for application prototypes and for OS development
> work, as well. "
> 
> Application prototypes might need a separate machine when the x86
> mentality (one app, one machine) applies. VMS has lots of reasons
> why well behaved user mode apps don't need that. OS development
> is obviously a different kettle of worms; crashes will happen.

I have never tried it, but I'll bet I could write a user level program
that could adversely affect other users.  Kinda like emacs. :-)  Come
to think of it, I can remember when notices used to get put up on the
11/750 telling people when the Ada compiler was going to be used so they
could plan a trip to the gym or anything other than trying to get any
work done on the VAX.  :-)

> 
> 
> "Could having a dozen or a hundred servers around -- without chewing
> up an equivalent amount of budget, power or cooling, and that can be
> loaded and reloaded very quickly -- be handy for hacking around?"
> 
> Isn't that kind of massive workload variation the ideal kind of thing
> to be outsourced to "the cloud"? 

Given what we read in the papers every day, you still trust the cloud?

>                                   A smaller amount of variation can be
> managed in house with none of the public-cloud-related issues now starting
> to be cause for concern (at least in Europe).
> 
> 
> Virtualisation in general is an answer to lots of problems that x86
> and Windows introduced, and which the Wintel world could not or would
> not fix at source (e.g. not-quite-compatible hardware and software).
> Maybe there are a few circumstances where a real OS on real hardware can
> benefit too.

That is not necessarily true.  I think much of it (like 99% idle time)
was the result of improvements in hardware.  Like it or not, there are
good reasons to have single tasked servers, even when they are not
Windows.  I know, I do it all the time.  Security, performance and
maintenance come immediately to mind.

> 
> That said, it would be very sensible to make sure that nuVMS (?)
> eventually runs well in a virtualised x86 environment, because
> virtualisation is now so many x86 IT people's comfort zone. Which
> VM(s) should it be, or are they all sufficiently identical that no
> separate qualification is needed? If you've got to qualify the
> hypervisor/OS combination, how much does it cost, how much $$ does
> it bring in? 
> 
> But the *technical* and *commercial* reasons I see for using
> virtualisation with nuVMS are less significant than they are with
> Windows. For a traditional VMS customer the virtualisation layer
> brings extra complexity, and thus extra risk. It's the customers who
> know whether the benefits outweigh the risks.
> 
> If it's a realtimeish environment of the kind where VMS used to excel
> (e.g. factory automation with VMS in the loop), customers will want
> to be sure virtualisation isn't going to bring more problems than it
> solves. And if Windows can do that kind of job in a virtualised 
> setup, nuVMS probably can too. Elsewhere? Tbd.
> 
> Fortunately it's not my decision :)

Nor mine.  

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 2:51:30 PM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of John
> E. Malmberg
> Sent: 05-Aug-14 1:21 AM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> On 8/4/2014 2:40 PM, David Froble wrote:
> > John E. Malmberg wrote:
> >
> >> A new x86 server OS that is not hypervisor aware is essentially DOA
> >> for commercial sales.  So it is a necessary layer.
> >
> > John, you're a rather astute guy, I formed that opinion lo those many
> > years ago in the first 10 minutes of talking to you.  But the above
> > statement seems to lack any justification.  Can you defend it a bit,
> > specify situations where it's factual, and such?
>=20
> Disclaimer:  I work for Riverbed.com which is selling solutions that make=
 it
> more practical to use VMs for location independent solutions in addition =
to
> other network and storage optimizations.
>=20
> While I can not mention specific installations, the trend is definitely t=
o
> running on hypervisors with VMs deployed the way that on timesharing you
> would have deployed a set of processes instead of dedicated servers.
>=20
While this is true, established shops using VMware for a while now are now =
running into major issues with VM sprawl. Unfortunately, because of cultura=
l and technical challenges, VM sprawl is exponentially harder to address th=
an physical server sprawl. Essentially this is all about OS instance consol=
idation. You need to have strict VM governance in place or your shop will s=
oon fall over with non-standard configs, unpatched security VM's, vastly in=
creased licensing costs.=20

Developers will be upset at these extra controls (they like creating VM's w=
henever they like), but if you want to get VM sprawl under control, you nee=
d to establish firm VM governance.

How does one do OS instance consolidation to reduce licensing, LP, staffing=
, security costs?

Well, one approach is to use Application stacking. Course, try and convince=
 Linux and Windows Bus groups they need to share their business application=
 on the same OS instance as another bus application. Watch the fireworks ex=
plode. "DLL hell" is something I am sure would come up in the discussion as=
 well.

As John indicated, OpenVMS Cust culture have few issues with Application st=
acking (on OS, and in single / multiple OS image clusters) as that has alwa=
ys been part of the culture. You do extra testing, and things like the nati=
ve class scheduler to limit bad things lower priority processes can do to h=
igher priority processes.

Now, should OpenVMS take a look at some of the really cool things VMware ca=
n do? Absolutely. =20

As a reminder, Galaxy on existing Alpha servers that support it today, can =
dynamically and via bus rules, migrate CPU's between OS instances  - someth=
ing VMware, Windows and Linux cannot do today (at least not to my knowledge=
). Features like being able to snapshot a process and dynamically (or via b=
us rules) move it to another server instance would be a great future additi=
on to the Galaxy x86-64 implementation.

[snip]

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com



0
Kerry
8/5/2014 3:04:07 PM
On 14-08-04 23:07, David Froble wrote:

> "Developing VMS releases for other platforms"
> So, perhaps ARM is in the crystal ball,

Lets not get ahead of ourselves. VMS is currently in intensive care
after HP had declared it dead but VSI managed to get a weak pulse.

You can dream about getting VMS to break a world record at the olympics,
but for now, getting VMS to just stand up and take a few steps would be
a major achievement.




0
JF
8/5/2014 3:08:18 PM
JF Mezei wrote 2014-08-05 17:08:
> On 14-08-04 23:07, David Froble wrote:
>
>> "Developing VMS releases for other platforms"
>> So, perhaps ARM is in the crystal ball,
>
> Lets not get ahead of ourselves. VMS is currently in intensive care
> after HP had declared it dead but VSI managed to get a weak pulse.
>
> You can dream about getting VMS to break a world record at the olympics,
> but for now, getting VMS to just stand up and take a few steps would be
> a major achievement.
>
>
>
>

 From :

http://www.enterprisetech.com/2014/08/01/upstart-breathe-new-life-venerable-openvms/

[Duane Harris is CEO at VMS Software Inc]

"�We have no illusions that we are going to take the market back
from Linux any time soon,� says Harris with a laugh. �But frankly,
we don�t want to limit ourselves to X86 chips, either. We have a
marquee operating system that is widely used in embedded environments
and it is time to broaden its scope.� That could mean OpenVMS ports
to ARM, MIPS, and other processor architectures."

That last sentence is not from Harris, though....

Jan-Erik.
0
Jan
8/5/2014 3:25:49 PM
In article <lrqlv7$989$5@pechter.motzarella.org>,
	pechter@tucker.pechter.dyndns.org (William Pechter) writes:
> In article <lrq552$gkg$1@news.albasani.net>,
> Jan-Erik Soderholm  <jan-erik.soderholm@telia.com> wrote:
>>William Pechter wrote 2014-08-05 06:58:
>>
>>> It's nice to spin up a new vm when you need a test/development box.
>>> Just copy a disk image with the preinstalled working OS and fire it up.
>>>
>>
>>How long does it take to get a license for that new instance?
>>Or are you running as hobbyist?
>>Or do you foresee some major changes in the licensing scheme?
>>
>>
> 
> Just a hobbyist here.  As far as the work stuff at the old job -- we had site
> licenses for most of the Oracle/Windows stuff and about an extra 10 
> licenses for RedHat Enterprise 3/4/5/6 and there's always CentOS for 
> testing if the licenses ran out.
> 

And the windows world has things like MSDNAA and MSDN so that bringing
up a new system for quick testing is quite common.  Didn't the VMS
developers program have somekind of multiple available licenses for
just this kind of environment?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 4:10:59 PM
On 14-08-05 11:04, Kerry Main wrote:
> As a reminder, Galaxy on existing Alpha servers that support it today, 


Does VSI get access to Galaxy IP or are they restricted to only stuff
that was enabled on IA64 ?

(since it is shared code baase for Alpha and IA64, I would hope that
anything specific to Alpha would be included in what VSI gets, but if
they don't have rights to deploy Galaxy, it doesn't do them any good to
have code they can't enable.

I would also hope that VSI would get (eventually) the full portfolio of
DEC application software for VMS, from ALL-IN-1 to Zsomething. Even of
they dont do much with it, it does give them the archives in case they
ever need it. Otherwise those codebases will disapear.

0
JF
8/5/2014 4:22:07 PM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of JF
> Mezei
> Sent: 05-Aug-14 12:22 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> On 14-08-05 11:04, Kerry Main wrote:
> > As a reminder, Galaxy on existing Alpha servers that support it today,
>=20
>=20
> Does VSI get access to Galaxy IP or are they restricted to only stuff
> that was enabled on IA64 ?
>=20
> (since it is shared code baase for Alpha and IA64, I would hope that
> anything specific to Alpha would be included in what VSI gets, but if
> they don't have rights to deploy Galaxy, it doesn't do them any good to
> have code they can't enable.
>=20
> I would also hope that VSI would get (eventually) the full portfolio of
> DEC application software for VMS, from ALL-IN-1 to Zsomething. Even of
> they dont do much with it, it does give them the archives in case they
> ever need it. Otherwise those codebases will disapear.
>=20
> _______________________________________________
> Info-vax mailing list
> Info-vax@info-vax.com
> http://info-vax.com/mailman/listinfo/info-vax_info-vax.com

I am sure all of this will come out over time, but when I raised the possib=
ility of Galaxy on the X86-64 implementation on the call last Thurs, I beli=
eve the answer was that it was something they were going to look into.=20

In the meantime, here is the currently available FAQ:
http://www.vmssoftware.com/news/announcement/faq.pdf

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com



0
Kerry
8/5/2014 5:02:30 PM
In article <lrqqgd$qf7$1@dont-email.me>, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> writes:
> 
> Today's VMS licensing is not relevant until and unless VSI states it is.

   From listening to the conference call, and surveying the web site,
   I came away with the impression that they already did.

   Something like they'll follow HP's Itanium licensing model, licensing per
   core except for some single user licenses.

0
koehler
8/5/2014 5:14:33 PM
In article <lrorrq$g1s$2@news.albasani.net>,
	Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> David Froble wrote 2014-08-04 22:30:
>> JF Mezei wrote:
>>> On 14-08-03 21:04, Susan Skonetski wrote:
>>>
>>>> Not sure if anyone remembers me or not.
>>>
>>> I dont have the foggiest idea...
>>>
>>> For those who don't know Susan, she is the one who tied me up and didn't
>>> threathen to beat me up (the bat is CGI, added without her permission
>>> but her hands were in right position :-)
>>>
>>> http://www.vaxination.ca/vms/decus/web/100_0194.jpg
>>>
>>> So she deserves kudos from everyone on comp.os.vms to have actually done
>>> what just about everyone on comp.os.vms thought they should be doing to
>>> me over the years :-)
>>>
>>>
>>>>  But I have the honor of being part of the VMS Software Company.
>>>
>>> Congratulations. I am quite happy for you and for VSI (or is it VSC ?)
>>>
>>> Great to see you come out of the woodwork.
>>>
>>> Here's hoping we'll get more and more well known names associated with
>>> the new company.
>>>
>>> This is very good news !
>>>
>>> Question: any discussion on resurecting DECUS ?
>>
>> Oh, my!
>>
>> Yeah, JF can be really a PITA at times.
>>
>> But sometimes he comes out with a really great idea.
> 
> Only if my member card is still valid. :-)
> http://jescab2.dyndns.org/pub_docs/img_3347.jpg
> 

I would have to dig a bit, but I still have mine at home somewhere.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 5:15:49 PM
Bill Gunshannon wrote 2014-08-05 19:15:
> In article <lrorrq$g1s$2@news.albasani.net>,
> 	Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
>>
>> Only if my member card is still valid. :-)
>> http://jescab2.dyndns.org/pub_docs/img_3347.jpg
>>
>
> I would have to dig a bit, but I still have mine at home somewhere.
>
> bill
>

I've got my card in my wallet since the mid 80's.
Never know when you need it... :-)

(No, I'm not joking, I have!)

Jan-Erik.
0
Jan
8/5/2014 5:31:45 PM
In article <lrr4e1$nnh$1@news.albasani.net>,
	Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> Bill Gunshannon wrote 2014-08-05 19:15:
>> In article <lrorrq$g1s$2@news.albasani.net>,
>> 	Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
>>>
>>> Only if my member card is still valid. :-)
>>> http://jescab2.dyndns.org/pub_docs/img_3347.jpg
>>>
>>
>> I would have to dig a bit, but I still have mine at home somewhere.
>>
>> bill
>>
> 
> I've got my card in my wallet since the mid 80's.
> Never know when you need it... :-)
> 
> (No, I'm not joking, I have!)
> 

I carried mine for ages after DECUS went away but then I made this wild
and crazy journey in 2009 and they told me I should strip the contents
of my wallet to a bare minimum.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/5/2014 5:47:24 PM
William Pechter wrote:

> I think it's necessary to push VMS into major companies that are
> completely virtuallized.
> 
> There's a lot of them.

This topic is interesting, and at least one thing I'm getting from it is 
that there doesn't seem to be a downside if VMS on x86 could be run on a 
VM.  That's as long as it can also run directly on the system.  Anyone 
doing any real-time type of stuff is definitely not going to want to 
have the possibility of being affected by any other instances on the system.

But the topic has also brought out some problems incurred on VM systems. 
  So it appears that there are definitely a minimum of two sides to the 
issue.  (There always are.)

It makes me wonder whether some of those sites that are "completely 
virtuallized" might not be having some problems.  Having VMS being able 
to run in a VM could get it in the door.  Having the capability of 
avoiding some possible problems might also break the VM monopoly.
0
David
8/5/2014 6:54:18 PM
Johnny Billquist wrote:
> On 2014-08-05 00:50, oboguev.public@gmail.com wrote:
>> On Monday, August 4, 2014 2:14:12 AM UTC-7, Johnny Billquist wrote:
>>
>>> I don't see the problem, unless you are saying that the kernel can't get
>>> write access without the user also having it, which I don't think is
>>> correct (and I don't think you are saying that).
>>
>> x86/x64 PTE has two bitflags: one controls user-mode accessibility of
>> the page, the other controls page writability. Thus x64 MMU does not
>> provide a mode equivalent to URKW.
> 
> In which case we can simplify this discussion. The x86-64 then do not 
> support URKW, which is also a protection mode used in VMS, unless I'm 
> mistaken. No need to involve and discuss supervisor or executive mode.
> 
> Seems like that could be an interesting problem... Flip the write enable 
> for the pages every time you go into kernel mode. A bit on the expensive 
> side...

No, you don't flip bits on a mode change.

You have parallel, pre-built page tables for each mode with the 
protections you need for that mode.  On CHMx/return calls, you change to 
the appropriate page table for the new mode.

All possible page protections (including URKW) are available with this 
design.

Yes, mode changes have TLB flush overhead with this design, but if it is 
the difference between working and not working, so be it.

Note that U, S, and E are all "user" modes that just differ in their 
memory protections.  Even though we refer to S and E as "privileged", 
they are not privileged at the hardware level.  This is true even on the 
VAX.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris@applied-synergy.com
   Fax: 817-237-3074
0
Chris
8/5/2014 7:00:38 PM
Jan-Erik Soderholm wrote:
> William Pechter wrote 2014-08-05 06:58:
> 
>> It's nice to spin up a new vm when you need a test/development box.
>> Just copy a disk image with the preinstalled working OS and fire it up.
>>
> 
> How long does it take to get a license for that new instance?
> Or are you running as hobbyist?
> Or do you foresee some major changes in the licensing scheme?
> 
> 

Personal observations.

Development and testing doesn't produce income.  The opposite, it costs, 
a negative cash flow.

Production on the other hand produces income, and pays for all the overhead.

Yeah, for sure someone is going to mention companies who produce 
software.  But does their products actually produce money, or is the 
cost just transfered to their clients?

I'd suggest that the capability to develop and test and such should 
incur little to no costs.  Preferably no costs.

After all, who is one of the main beneficiaries of such development and 
testing?  I'd suggest the developers of the OS software that gain 
applications to run on their platform.

Such sayings as "don't cook the goose laying the golden eggs" comes to 
mind.  Haven't many of us lamented DEC's poor approach to education, and 
software developers?  Repeat DEC's mistakes, and you'll repeat DEC's fate.

It's not a one way street.  It's a partnership.  For VSI to succeed, 
they will need to work with their partners to the common good of both.
0
David
8/5/2014 7:12:50 PM
Stephen Hoffman wrote:
> On 2014-08-05 08:37:54 +0000, Jan-Erik Soderholm said:
> 
>> William Pechter wrote 2014-08-05 06:58:
>>
>>> It's nice to spin up a new vm when you need a test/development box.
>>> Just copy a disk image with the preinstalled working OS and fire it up.
>>>
>>
>> How long does it take to get a license for that new instance?
>> Or are you running as hobbyist?
>> Or do you foresee some major changes in the licensing scheme?
> 
> HP was selling the little-known iCAP licensing, which is on the way to 
> dynamic licensing.
> 
> But yes, it'd be nice if VMS and its licensing and LMF were updated to 
> modern norms, and where we could get a per-box license, or some sort of 
> site or bulk licensing, or dynamic licensing with a pool of local 
> licenses, or a way to query the VSI licensing servers and purchase a 
> license.  Something closer to current VM-friendly licensing than to the 
> state-of-the-1990-art solution that is LMF.
> 
> It'd be nice if there was a VSI web page where I could purchase a 
> license PAK or a support contract, but I'm not getting my hopes up. :-)
> 
> 

Or just do away with licensing.  The only real source of money is those 
systems running production, and, ongoing support of those systems is 
where the easy money will come from.
0
David
8/5/2014 7:15:00 PM
Stephen Hoffman wrote:
> On 2014-08-05 13:38:47 +0000, Jan-Erik Soderholm said:
> 
>> OK. If it wasn't clear, I asked about VMS licenes. :-)
> 
> That was quite clear.   Maybe ask this question of VSI more directly?
> 
> I wouldn't expect VSI to necessarily follow HP's licensing practices.
> 
> Until there are VSI products and services available, license and support 
> prices known, and software licensing policies published, most folks 
> posting here simply don't know the answer.
> 
> Some discussions of your organization's preferences and needs and of 
> alternatives and options — held between your organization and VSI — are 
> entirely reasonable.
> 
> The VSI folks are probably discussing and establishing these same prices 
> and polices and details among themselves, too.   Even VSI may not have 
> established and be entirely certain about these details quite yet.
> 
> On no evidence, it wouldn't surprise me to see another round of public 
> announcements from VSI next month at the boot camp, and then 
> particularly again around the time of the first VSI product 
> availability.  This assuming that the Poulson and x86-64 ports aren't 
> both tested and available by the end of next month. :-)
> 
> 
> 

Now why do the letters NDA pop into my mind at this time?

:-)

:-)
0
David
8/5/2014 7:16:54 PM
JF Mezei wrote:
> On 14-08-04 23:07, David Froble wrote:
> 
>> "Developing VMS releases for other platforms"
>> So, perhaps ARM is in the crystal ball,
> 
> Lets not get ahead of ourselves. VMS is currently in intensive care
> after HP had declared it dead but VSI managed to get a weak pulse.
> 
> You can dream about getting VMS to break a world record at the olympics,
> but for now, getting VMS to just stand up and take a few steps would be
> a major achievement.
> 
> 
> 
> 

I'm just quoting VSI's web site ....
0
David
8/5/2014 7:19:51 PM
VAXman- @SendSpamHere.ORG wrote:
> In article <Y+iJlP48Nu2F@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>> In article <53deed47$0$49532$c3e8da3$fdf4f6af@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>> Question: any discussion on resurecting DECUS ?
>>   Good question.  Is VSI going to use Compass, or try to re-create
>>   something like DECUS?
>>
>>   I heard in the conference that VSI would be providing support
>>   for the DECUSserve environment.  Can I assume EISNER is going
>>   to physically move?
> 
> Eisner made a physical move months ago.
> 

Yeah, and wasn't Numonix involved?
0
David
8/5/2014 7:20:58 PM
In article <lrraqj$ntk$5@dont-email.me>, David Froble <davef@tsoft-inc.com> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> In article <Y+iJlP48Nu2F@eisner.encompasserve.org>, koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
>>> In article <53deed47$0$49532$c3e8da3$fdf4f6af@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>>>> Question: any discussion on resurecting DECUS ?
>>>   Good question.  Is VSI going to use Compass, or try to re-create
>>>   something like DECUS?
>>>
>>>   I heard in the conference that VSI would be providing support
>>>   for the DECUSserve environment.  Can I assume EISNER is going
>>>   to physically move?
>> 
>> Eisner made a physical move months ago.
>> 
>
>Yeah, and wasn't Numonix involved?

Yup!
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.
0
VAXman
8/5/2014 7:28:55 PM
On Tuesday, August 5, 2014 11:04:07 AM UTC-4, Kerry Main wrote:

>=20
> As a reminder, Galaxy on existing Alpha servers that support it today, ca=
n dynamically and via bus rules, migrate CPU's between OS instances  - some=
thing VMware, Windows and Linux cannot do today (at least not to my knowled=
ge). Features like being able to snapshot a process and dynamically (or via=
 bus rules) move it to another server instance would be a great future addi=
tion to the Galaxy x86-64 implementation.
>=20

Galaxy has HUGE dependencies on the firmware and console.  That's why you d=
on't see it on Itanium for instance. =20


0
John
8/5/2014 8:11:18 PM
On 2014-08-05 17:14:33 +0000, Bob Koehler said:

> In article <lrqqgd$qf7$1@dont-email.me>, Stephen Hoffman 
> <seaohveh@hoffmanlabs.invalid> writes:
>> 
>> Today's VMS licensing is not relevant until and unless VSI states it is.
> 
>    From listening to the conference call, and surveying the web site, I 
> came away with the impression that they already did.
> 
>    Something like they'll follow HP's Itanium licensing model, 
> licensing per core except for some single user licenses.


Startups and smaller companies tend to change their minds (a.k.a. 
"pivot") from time to time, and they don't always do what the 
juggernaut-class companies might do or might expect.

....When the product prices become known and/or become available for web 
purchases or other such, then we'lll know the list prices and the 
available options.

:-)



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 8:42:13 PM
On 2014-08-05 20:11:18 +0000, John Reagan said:

> Galaxy has HUGE dependencies on the firmware and console.  That's why 
> you don't see it on Itanium for instance.

A VM provides you with something rather similar to this, however.

Add pseudo device(s) for VM to VM and/or to open up a shared memory 
window for best "shenanigans", and off you go.



-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/5/2014 8:54:30 PM
On Tuesday, 5 August 2014 15:28:54 UTC+1, Paul Sture  wrote:
> On 2014-08-05, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
> 
> > On Tuesday, 5 August 2014 05:58:19 UTC+1, William Pechter  wrote:
> 
> 
> 
> <loads of stuff snipped>
> 

[weird experience with ESXi details snipped]

> 
> > None of the local IT staff, or their backups, or the Interweb, appeared
> 
> > to be willing or able to explain this.
> 
> 
> 
> Out of interest, which year was this?
> 
> 

[more snippage]
> 
> -- 
> 
> The early bird gets the worm but the second mouse gets the cheese.
> 
> The early mouse is now a late mouse of course.


[sorry for delay responding]

At a guess, three years or so ago, maybe a little bit more. So not
that old but not that recent either.

The departmental trial did look at VirtualBox on paper; it looked
promising but the IT people said the company standard was ESX so
that's what our trial (for sw dev/test/support) had to use.

They're still using VMware rather than Hyper-V, which some might
find interesting, especially in the light of VMware repricing in
recent times (get them hooked, then change the licencing/pricing).

I wouldn't currently know where to start looking wrt monitoring hot
files etc on Linux but if I did want to know I might start with e.g.
https://www.suse.com/documentation/sled11/singlehtml/book_sle_tuning/book_sle_tuning.html (2014)

Manuals. Documentation. Business-class support. What a concept, eh?
0
johnwallace4
8/5/2014 9:43:23 PM
On 2014-08-05, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
>
>
> [sorry for delay responding]

No problem.

> At a guess, three years or so ago, maybe a little bit more. So not
> that old but not that recent either.

My VMware trial was in early 2011 so the same timeframe.

> The departmental trial did look at VirtualBox on paper; it looked
> promising but the IT people said the company standard was ESX so
> that's what our trial (for sw dev/test/support) had to use.

FWIW I went for VMware Fusion on the Mac because the VirtualBox port to
OS X was relatively recent and the GUI was still somewhat flaky a year ago.
It's quite stable now.

> They're still using VMware rather than Hyper-V, which some might
> find interesting, especially in the light of VMware repricing in
> recent times (get them hooked, then change the licencing/pricing).

I can see that happening with all this "cheap cloud storage" sooner or
later.

> I wouldn't currently know where to start looking wrt monitoring hot
> files etc on Linux but if I did want to know I might start with e.g.
> https://www.suse.com/documentation/sled11/singlehtml/book_sle_tuning/book_sle_tuning.html (2014)

Thanks for the link.

> Manuals. Documentation. Business-class support. What a concept, eh?

:-)

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/5/2014 10:11:14 PM
Stephen Hoffman wrote 2014-08-05 22:42:
> On 2014-08-05 17:14:33 +0000, Bob Koehler said:
>
>> In article <lrqqgd$qf7$1@dont-email.me>, Stephen Hoffman
>> <seaohveh@hoffmanlabs.invalid> writes:
>>>
>>> Today's VMS licensing is not relevant until and unless VSI states it is.
>>
>>    From listening to the conference call, and surveying the web site, I
>> came away with the impression that they already did.
>>
>>    Something like they'll follow HP's Itanium licensing model, licensing
>> per core except for some single user licenses.
>
>
> Startups and smaller companies tend to change their minds (a.k.a. "pivot")
> from time to time, and they don't always do what the juggernaut-class
> companies might do or might expect.
>
> ...When the product prices become known and/or become available for web
> purchases or other such, then we'lll know the list prices and the available
> options.
>
> :-)
>
>
>

About licenes...

In my own case (my own company), I have an Alpha at my office.
Currently running in the hobbist way. Mainly for the joy of it
and doing some tests my customer would not allow or
proof-of-concept kind of things for my own sake.

Now, if there was a licence modelled after my/our needs, I'd
gladly use that instead of the hobbyist licens. There seems
to be some solution for VAR's and other larger companies
building commersial softare, but that is not me... :-)

Jan-Erik.
0
Jan
8/5/2014 10:25:09 PM
Johnny Billquist wrote:
> On 2014-08-04 15:21, Bill Gunshannon wrote: 
>> In article <IjTCv.136775$AN6.25160@fx01.iad>,
>> <rschaffrath@yahoo.com> writes:

>>> I just hope that VMS thrives and does not wind up like RSTS/E under
>>> Mentec.  That basically fizzled.
>>
>>
>> How did it fizzle?  Mentec continued to maintain it and even did all the
>> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
>> I think all three PDP-11 OSes had longer lives under Mentec than they had
>> under DEC.
> 
> 
> Not really. Active development continued for about 5 years at Mentec,
> and then another 10 years of slow death. They did live longer at DEC,
> 
> But I agree that it's a bit unfair to just say they fizzled at Mentec.
> However, RSTS/E might have gotten the least attention of all of them at
> Mentec.

As far as I know, they had no hobbyist program.  I have several
(micro) 11's at home, each with the original O/S they had running
when I purchased them.  I do not believe I'm actually even legally
entitled to run those.

I do have Venix (System V r2) on my DEC Professional.  I guess
I can run that one.

George

0
George
8/5/2014 11:15:19 PM
On 8/5/2014 10:14 AM, JF Mezei wrote:
> On 14-08-05 00:25, John E. Malmberg wrote:
>
>> Except for bragging rights, there is no advantage to targeting bare
>> metal with out a hypervisor.  It is just simply more initial work and
>> more on-going maintenance.
>
> Out of curiosity, would the engineers doing the VMS port to x86
> initially work on a VM or on a vanilla bare metal with known/fixed
> config ?  (talking about early development where the focus is on getting
> first boot, talking to console, devices etc)

I do not know about them.  If it were my money on the line, I would not 
even consider the "bare-metal" drivers for a new x86 OS.

Less work to fix any defects found in the native Linux drivers and the 
KVM hypervisor.  More people motivated to fix them.

If you are going to write native drivers, you are better off 
implementing a hypervisor level that would be equivalent to what KVM or 
Hyper/V already provides.

Or you can do what some of the hardware emulators do, simply install a 
custom built Linux kernel and call it a bare-metal port.  Native drivers 
done, and mostly accomplished by a statement from the Marketing department.

As the late Fred Kleinsorge often stated here about graphics chip-sets, 
the chip-sets for disk, network, memory, etc all have lifespans of 
fruit-flies.

>> 1. The ability assign IP and MAC addresses to a process. (Yes, some of
>> us can do that now :-)
>
> In what way would running on a VM give a VMS process ability to get its
> own MAC/IP address ?

By dedicating a VM to that process tree.  The VM can then be 
transparently moved from one hardware chassis to another.

Think of this, a VM running SimH/VAX VMS can be moved from a host in 
Montreal to one in Quebec while you are sshed into it, with out you 
noticing that it moved.

VMS/x86 starts out with that ability if implemented on a Hypervisor.

How long would it take for native hardware to be able to do that?

>  From an ethernet point of view, do VMs allow multiple separate instances
> to share the same physical ethernet card ? (which would imply faking MAC
> address for all traffic, right ?)

That is correct.  You can run lots of VMs off of the same ethernet card 
or sets of ethernet cards.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion
0
John
8/6/2014 12:43:13 AM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of John
> Reagan
> Sent: 05-Aug-14 4:11 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> On Tuesday, August 5, 2014 11:04:07 AM UTC-4, Kerry Main wrote:
>=20
> >
> > As a reminder, Galaxy on existing Alpha servers that support it today, =
can
> dynamically and via bus rules, migrate CPU's between OS instances  -
> something VMware, Windows and Linux cannot do today (at least not to my
> knowledge). Features like being able to snapshot a process and dynamicall=
y
> (or via bus rules) move it to another server instance would be a great fu=
ture
> addition to the Galaxy x86-64 implementation.
> >
>=20
> Galaxy has HUGE dependencies on the firmware and console.  That's why
> you don't see it on Itanium for instance.
>=20

John, I understand the limitations of the IA64 console were a challenge, bu=
t perhaps the new x86-64 HW virtualization capabilities might make Galaxy e=
asier to implement?

Reference:
http://tinyurl.com/Intel-Virt-1

http://tinyurl.com/Intel-Virt-2

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com



0
Kerry
8/6/2014 1:42:45 AM
On 8/5/2014 10:04 AM, Kerry Main wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces@info-vax.com]
 >> On Behalf Of John E. Malmberg
>
> As a reminder, Galaxy on existing Alpha servers that support it
> today,  can dynamically and via bus rules, migrate CPU's between OS instances -
> something VMware, Windows and Linux cannot do today (at least not to my
> knowledge). Features like being able to snapshot a process and
> dynamically (or via bus rules) move it to another server instance would
> be a great future addition to the Galaxy x86-64 implementation.

You need to look again at Linux, this document is dated 2009.
https://communities.vmware.com/docs/DOC-10493

http://www.linux-kvm.org/page/CPUHotPlug

http://www.linux-kvm.org/page/FAQ

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only



0
John
8/6/2014 1:51:54 AM
On 14-08-05 21:42, Kerry Main wrote:

> John, I understand the limitations of the IA64 console were a challenge, but perhaps the new x86-64 HW virtualization capabilities might make Galaxy easier to implement?


How much of what Galaxy does is already implemented in VMware and would
easily interface with the existing Galaxy code in VMS to provide the
same services that were provided by the Wilfire and successor Alpha
hardware ?

There has been mention that VMware is able to move an OS instance from
one physical server to another "live" without interruption. How is that
accomplished ?  Does it actually freeze the source system while it
copies all memory ?

Does it have its own SCS-like and MSCP like protocols ? Or use some
industry standard ones  ?

In the context of Galaxy, would VMware allow formation of a Galaxy
across physical servers ? (opresent remote server's memory as shared
NUMA memory ?(

And from a cluster point of view, if two nodes on same physical server
use special memory interconnects for very fast SCS communications, but
you decide to move one instance to another physicxal server, would VMS
failover to Ethernet automatically ?


0
JF
8/6/2014 2:23:13 AM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of John
> E. Malmberg
> Sent: 05-Aug-14 9:52 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> On 8/5/2014 10:04 AM, Kerry Main wrote:
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces@info-vax.com]
>  >> On Behalf Of John E. Malmberg
> >
> > As a reminder, Galaxy on existing Alpha servers that support it today,
> > can dynamically and via bus rules, migrate CPU's between OS instances
> > - something VMware, Windows and Linux cannot do today (at least not to
> > my knowledge). Features like being able to snapshot a process and
> > dynamically (or via bus rules) move it to another server instance
> > would be a great future addition to the Galaxy x86-64 implementation.
>=20
> You need to look again at Linux, this document is dated 2009.
> https://communities.vmware.com/docs/DOC-10493
>=20
> http://www.linux-kvm.org/page/CPUHotPlug
>=20
> http://www.linux-kvm.org/page/FAQ
>=20
> Regards,
> -John
> wb8tyw@qsl.network
> Personal Opinion Only
>=20

Thanks for the pointers. It definitely looks like the Linux folks have trie=
d to implement some aspects of Galaxy - at least with hot CPU add, but unle=
ss the info is dated, it looks like they have not figured out how to implem=
ent hot unplug on X86 HW.

>From the second link:
" Hot-unplug does not work, and actually, does not even make that much sens=
e."

Actually it makes a great deal of sense to be able to dynamically and via b=
us rules to switch CPU resources back and forth between different OS instan=
ces on the same server.

Sample1 - during the day PROD1 OS instance has 10 CPU's to handle day to da=
y transaction loads. PROD2 server is relatively dormant during the day with=
 only 4 CPU's handling background day batch jobs. A business rule kicks in =
at 10:00pm every night and moves 8 CPU's from PROD1 to PROD2 to handle the =
evening batch jobs. At 6:00 AM, the rule switches the CPU's back to PROD1.

Sample2 - same scenario above, but during the day PROD1 starts reaching 80%=
 CPU utilization. A business rule kicks in and 2 CPUs are automatically mov=
ed from PROD2 to PROD1. When the PROD1 load goes back down to 20%, the bus =
rule moves the 2 CPUs back to PROD2.

Galaxy on supported Alpha HW supports this today.

Galaxy also supports shared memory between OS instances allowing extremely =
fast inter-OS communications.

Galaxy also supports different time zones for each OS instance on the same =
server - as long as they are not clustered. Granted, I believe VMware can a=
lso do multi-time zones with its guest OS's, but would need someone to conf=
irm.

Reference:
http://h71000.www7.hp.com/availability/galaxy.html

http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf

>From the discussion here, the challenge will be to determine if Galaxy can =
take advantage of new X86-64 HW virtualization capabilities. If it can, I w=
ould suggest this would be a very good differentiator for OpenVMS X86-64.

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com




0
Kerry
8/6/2014 2:30:59 AM
In article <53e0f4f4$0$1749$c3e8da3$5d8fb80f@news.astraweb.com>,
JF Mezei  <jfmezei.spamnot@vaxination.ca> wrote:
>On 14-08-05 00:25, John E. Malmberg wrote:
>
>> Except for bragging rights, there is no advantage to targeting bare 
>> metal with out a hypervisor.  It is just simply more initial work and 
>> more on-going maintenance. 
>
>
>Out of curiosity, would the engineers doing the VMS port to x86
>initially work on a VM or on a vanilla bare metal with known/fixed
>config ?  (talking about early development where the focus is on getting
>first boot, talking to console, devices etc)
>
>
>> 1. The ability assign IP and MAC addresses to a process. (Yes, some of 
>> us can do that now :-)
>
>In what way would running on a VM give a VMS process ability to get its
>own MAC/IP address ?
>
>From an ethernet point of view, do VMs allow multiple separate instances
>to share the same physical ethernet card ? (which would imply faking MAC
>address for all traffic, right ?)
>
>

While I haven't worked on all Virtualization platforms... I think
Xenserver, ESXi, VMware Workstation all share the same physical NIC (or
you could give them their own physical one if you want).  VMware 
and Microsoft's Hyper-v have virtual switches which then can share NICs 
or teams of NICs... (for throughput, failover, redundancy etc.)

Each machine gets one or more of their own MAC addresses -- so the
Ethernet just works like ... er ... ethernet.

MACs are generated at VM configuration time and ESX will allow a user
mandated MAC address to be locked with a virtual machine for cases where
software licensing is MAC address dependant.... 

One thing I don't know about virtualization is how DECnet Phase IV would
work with it.

TCP/IP works fine since it was designed to support it.

Bill


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 2:41:34 AM
On 8/5/2014 9:41 PM, William Pechter wrote:
>
> One thing I don't know about virtualization is how DECnet Phase IV would
> work with it.

Works fine.  Just start it before the TCP/IP program as usual.

Regards,
-John
wb8tyw@qsl.network
Personal Opinion Only

0
John
8/6/2014 2:49:48 AM
In article <mailman.1.1407251053.25770.info-vax_info-vax.com@info-vax.com>,
Kerry Main  <kerry.main@backtothefutureit.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of John
>> E. Malmberg
>> Sent: 05-Aug-14 1:21 AM
>> To: info-vax@info-vax.com
>> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
>> continue development of OpenVMS and Layered Products under HP License
>> 
>> On 8/4/2014 2:40 PM, David Froble wrote:
>> > John E. Malmberg wrote:
>> >
>> >> A new x86 server OS that is not hypervisor aware is essentially DOA
>> >> for commercial sales.  So it is a necessary layer.
>> >
>> > John, you're a rather astute guy, I formed that opinion lo those many
>> > years ago in the first 10 minutes of talking to you.  But the above
>> > statement seems to lack any justification.  Can you defend it a bit,
>> > specify situations where it's factual, and such?
>> 
>> Disclaimer:  I work for Riverbed.com which is selling solutions that make it
>> more practical to use VMs for location independent solutions in addition to
>> other network and storage optimizations.
>> 
>> While I can not mention specific installations, the trend is definitely to
>> running on hypervisors with VMs deployed the way that on timesharing you
>> would have deployed a set of processes instead of dedicated servers.
>> 

>While this is true, established shops using VMware for a while now are
>now running into major issues with VM sprawl. Unfortunately, because of
>cultural and technical challenges, VM sprawl is exponentially harder to
>address than physical server sprawl. Essentially this is all about OS
>instance consolidation. You need to have strict VM governance in place
>or your shop will soon fall over with non-standard configs, unpatched
>security VM's, vastly increased licensing costs. 

Actually, we got better control of stuff under VMware.  We had the
ability to have everything backed with VM's in sync'd to the disaster
recovery site.  We didn't have all the hardware for the 2 and 1 U
servers that went into production for when the departments bought
applicatons and hardware.  They rarely looked into test and development
box support with vendor software.

With the correct sized VMware hosts we made sure we had test/dev backing
for all the boxes before go-live.

As far as non-standard configs -- the OS's were all built to standards.
Patching was done on a schedule for all the IT boxes.  The only thing we
didn't patch were University boxes used by profesors for things like
the computing research cluster... etc.

>Developers will be upset at these extra controls (they like creating
>VM's whenever they like), but if you want to get VM sprawl under
>control, you need to establish firm VM governance.

>How does one do OS instance consolidation to reduce licensing, LP,
>staffing, security costs?

Much more of a problem on Windows then RHEL.  We just re-utilized the
old RHEL licenses on new VM's as we replaced them.

Keeping a pool of 120 or so licenses left us able to keep a free
pile of 10-20 licenses that we'd use for rolling upgrades.
The Windows guys had to deal with Microsoft's open licensing and
whatever the University arraingment was.

The RHEL licenses also don't stop you from installing more than your
count as part of the upgrade... so sometimes I'd put up 121 and then
schedule a shutdown and license move and do the final switch out in the
maintenance window.  Most of our extra licenses were coming from
decommissioned licenses from stuff moved out to the cloud or from
physical boxes that were virtualized.

We didn't do much Linux VM cloning since we had an automated kickstart
installation that mostly fully scripted...

>Well, one approach is to use Application stacking. Course, try and
>convince Linux and Windows Bus groups they need to share their business
>application on the same OS instance as another bus application. Watch
>the fireworks explode. "DLL hell" is something I am sure would come up
>in the discussion as well.

Not something I've seen in 6 years admining on ESX on the Linux side.
Mixing applications is easy, and a normal Unix thing -- but when
different app vendors support different versions of the OS you can get 
clipped by App A needs to run on Linux RHEL6.x and App B on the same box
is not supported on newer than v5.8.

It's easier to right size the VM for the one app and you can roll in and
out version upgrades and OS upgrades without having compatibility issues
between app and OS.

>
>As John indicated, OpenVMS Cust culture have few issues with Application
>stacking (on OS, and in single / multiple OS image clusters) as that has
>always been part of the culture. You do extra testing, and things like
>the native class scheduler to limit bad things lower priority processes
>can do to higher priority processes.
>
>Now, should OpenVMS take a look at some of the really cool things VMware
>can do? Absolutely.  
>
>As a reminder, Galaxy on existing Alpha servers that support it today,
>can dynamically and via bus rules, migrate CPU's between OS instances  -
>something VMware, Windows and Linux cannot do today (at least not to my
>knowledge). Features like being able to snapshot a process and
>dynamically (or via bus rules) move it to another server instance would
>be a great future addition to the Galaxy x86-64 implementation.
>
>[snip]
>
>Regards,
>
>Kerry Main
>Back to the Future IT Inc.
> .. Learning from the past to plan the future
>
>Kerry dot main at backtothefutureit dot com
>
>
>


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 2:56:49 AM
In article <53e19192$0$2853$c3e8da3$66d3cc2f@news.astraweb.com>,
JF Mezei  <jfmezei.spamnot@vaxination.ca> wrote:
>On 14-08-05 21:42, Kerry Main wrote:
>
>> John, I understand the limitations of the IA64 console were a
>challenge, but perhaps the new x86-64 HW virtualization capabilities
>might make Galaxy easier to implement?
>
>
>How much of what Galaxy does is already implemented in VMware and would
>easily interface with the existing Galaxy code in VMS to provide the
>same services that were provided by the Wilfire and successor Alpha
>hardware ?
>
>There has been mention that VMware is able to move an OS instance from
>one physical server to another "live" without interruption. How is that
>accomplished ?  Does it actually freeze the source system while it
>copies all memory ?
>

It's magic... 8-).

Basically it copies all the memory to a file and  (kind of like
checkpointing) and then the other  server fires up the box....  It
really looks like a very fast laptop hibernate and resume...)

This assumes storage accessable by both host platforms at the same time.
The machine does the necessary gratuitous arp to say... "I'm over
here" to the network and switches... and off it goes.

If there's the need for a storage move to a different SAN or NFS datastore
the Windows and VMware stuff can now do a storage copy between storage
systems live and then the machine can be migrated...

I've seen about two pings lost at the worst when this happens.

>Does it have its own SCS-like and MSCP like protocols ? Or use some
>industry standard ones  ?
>

It just uses the standard NFS or ISCSI or Fiber Channel protocols
between the host and the storage.  The VM only sees the presented out
disk container files.

>In the context of Galaxy, would VMware allow formation of a Galaxy
>across physical servers ? (opresent remote server's memory as shared
>NUMA memory ?(

I have no idea if that is possible.  Basic clustering between Windows
servers or linux servers -- yes...

Shared disks can be set up between machines...  Hot standby is possible.


>And from a cluster point of view, if two nodes on same physical server
>use special memory interconnects for very fast SCS communications, but
>you decide to move one instance to another physicxal server, would VMS
>failover to Ethernet automatically ?
>

I don't know if they support special memory interconnects between the
virtual machines.

With support for 40gig ethernet between the hosts would you need
something faster for Galaxy?


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 3:07:45 AM
In article <X_mdnQzcjrzwF3zOnZ2dnUVZ_qKdnZ2d@mchsi.com>,
John E. Malmberg <wb8tyw@qsl.network> wrote:
>On 8/5/2014 10:04 AM, Kerry Main wrote:
>>> -----Original Message-----
>>> From: Info-vax [mailto:info-vax-bounces@info-vax.com]
> >> On Behalf Of John E. Malmberg
>>
>> As a reminder, Galaxy on existing Alpha servers that support it
>> today,  can dynamically and via bus rules, migrate CPU's between OS
>instances -

There's no way to "migrate" cpu's between VMs... but you can do hot cpu
and memory addition with VMware and I think with some of the latest
HyperV.  RHEL6 supports hot memory add and hot cpu add.  Disk addition can
happen at any time as well.

Now you can migrate the VM's to different hosts at any time...

>> something VMware, Windows and Linux cannot do today (at least not to my
>> knowledge). Features like being able to snapshot a process and
>> dynamically (or via bus rules) move it to another server instance would
>> be a great future addition to the Galaxy x86-64 implementation.
>
>You need to look again at Linux, this document is dated 2009.
>https://communities.vmware.com/docs/DOC-10493
>
>http://www.linux-kvm.org/page/CPUHotPlug
>
>http://www.linux-kvm.org/page/FAQ
>
>Regards,
>-John
>wb8tyw@qsl.network
>Personal Opinion Only

Bill
>
>
>


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 3:10:22 AM
In article <mailman.7.1407292270.25770.info-vax_info-vax.com@info-vax.com>,
Kerry Main  <kerry.main@backtothefutureit.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of John
>> E. Malmberg
>> Sent: 05-Aug-14 9:52 PM
>> To: info-vax@info-vax.com
>> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
>> continue development of OpenVMS and Layered Products under HP License
>> 
>> On 8/5/2014 10:04 AM, Kerry Main wrote:
>> >> -----Original Message-----
>> >> From: Info-vax [mailto:info-vax-bounces@info-vax.com]
>>  >> On Behalf Of John E. Malmberg
>> >
>> > As a reminder, Galaxy on existing Alpha servers that support it today,
>> > can dynamically and via bus rules, migrate CPU's between OS instances
>> > - something VMware, Windows and Linux cannot do today (at least not to
>> > my knowledge). Features like being able to snapshot a process and
>> > dynamically (or via bus rules) move it to another server instance
>> > would be a great future addition to the Galaxy x86-64 implementation.
>> 
>> You need to look again at Linux, this document is dated 2009.
>> https://communities.vmware.com/docs/DOC-10493
>> 
>> http://www.linux-kvm.org/page/CPUHotPlug
>> 
>> http://www.linux-kvm.org/page/FAQ
>> 
>> Regards,
>> -John
>> wb8tyw@qsl.network
>> Personal Opinion Only
>> 
>
>Thanks for the pointers. It definitely looks like the Linux folks have
>tried to implement some aspects of Galaxy - at least with hot CPU add,
>but unless the info is dated, it looks like they have not figured out
>how to implement hot unplug on X86 HW.
>
>>From the second link:
>" Hot-unplug does not work, and actually, does not even make that much sense."
>
>Actually it makes a great deal of sense to be able to dynamically and
>via bus rules to switch CPU resources back and forth between different
>OS instances on the same server.
>
>Sample1 - during the day PROD1 OS instance has 10 CPU's to handle day to
>day transaction loads. PROD2 server is relatively dormant during the day
>with only 4 CPU's handling background day batch jobs. A business rule
>kicks in at 10:00pm every night and moves 8 CPU's from PROD1 to PROD2 to
>handle the evening batch jobs. At 6:00 AM, the rule switches the CPU's
>back to PROD1.
>
>Sample2 - same scenario above, but during the day PROD1 starts reaching
>80% CPU utilization. A business rule kicks in and 2 CPUs are
>automatically moved from PROD2 to PROD1. When the PROD1 load goes back
>down to 20%, the bus rule moves the 2 CPUs back to PROD2.
>
>Galaxy on supported Alpha HW supports this today.
>
>Galaxy also supports shared memory between OS instances allowing
>extremely fast inter-OS communications.
>
>Galaxy also supports different time zones for each OS instance on the
>same server - as long as they are not clustered. Granted, I believe
>VMware can also do multi-time zones with its guest OS's, but would need
>someone to confirm.
>
>Reference:
>http://h71000.www7.hp.com/availability/galaxy.html
>
>http://h71000.www7.hp.com/doc/732final/aa-rezqe-te/aa-rezqe-te.pdf
>
>>From the discussion here, the challenge will be to determine if Galaxy
>can take advantage of new X86-64 HW virtualization capabilities. If it
>can, I would suggest this would be a very good differentiator for
>OpenVMS X86-64.
>
>Regards,
>
>Kerry Main
>Back to the Future IT Inc.
> .. Learning from the past to plan the future
>
>Kerry dot main at backtothefutureit dot com
>
>
>
>

Under VMware ESX you can set throttles on how many cpus get used for
what VM's at the ESX host level.  So you can have 6 cpu's on a system
and if that VM is not using them fully the remaining cpu time can go to
other VMs...

It's all tuneable on the fly and VMware does have scripting capability.
The thing I saw in reality was there was almost always less than 50% cpu
avaliable on my site.  The biggest factor on the performance was the
storage IOPS and the amount of memory free.  

Balancing things like the Oracle db boxes across the various hosts was
also important.  When we were worried about certain performance we put
one ESXi instance on one IBM blade and put just one VM on the 16-32 gb of
memory.  We got the benefit of dedicated hardware with the additional 
failover and migration that VMware gave us.

One additional thing was making sure we could take any single ESX host
out of production and still have enough available cpu and memory to
distribute the virtual machines to other hosts.

It made hardware repair doable any time and made upgrades a rolling
process.

1.  Evacuate VMs on server.
2.  Upgrade server hw/os
3.  Roll the production stuff back
4.  Repeat on next server.

Simple and easy to do even remotely in a lights out data center.

Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 3:18:31 AM
In article <c4ce0jFc7icU1@mid.individual.net>,
Bill Gunshannon <billg999@cs.uofs.edu> wrote:
>In article <lrqlv7$989$5@pechter.motzarella.org>,
>	pechter@tucker.pechter.dyndns.org (William Pechter) writes:
>> In article <lrq552$gkg$1@news.albasani.net>,
>> Jan-Erik Soderholm  <jan-erik.soderholm@telia.com> wrote:
>>>William Pechter wrote 2014-08-05 06:58:
>>>
>>>> It's nice to spin up a new vm when you need a test/development box.
>>>> Just copy a disk image with the preinstalled working OS and fire it up.
>>>>
>>>
>>>How long does it take to get a license for that new instance?
>>>Or are you running as hobbyist?
>>>Or do you foresee some major changes in the licensing scheme?
>>>
>>>
>> 
>> Just a hobbyist here.  As far as the work stuff at the old job -- we had site
>> licenses for most of the Oracle/Windows stuff and about an extra 10 
>> licenses for RedHat Enterprise 3/4/5/6 and there's always CentOS for 
>> testing if the licenses ran out.
>> 
>
>And the windows world has things like MSDNAA and MSDN so that bringing
>up a new system for quick testing is quite common.  Didn't the VMS
>developers program have somekind of multiple available licenses for
>just this kind of environment?
>
>bill
>
>-- 
>Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
>billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
>University of Scranton   |
>Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Too bad they got rid of my TechNet licensing.  I may need to go back to
the partner program again.

Right now I've just put up Win8/2012R2/CentOS7/CentOS6 and during the
two CentOS loads the machines were only using 2% of CPU each...

12 Cores and 24gb of memory is just too much fun for me to play with.
Got 3 different network zones with virtual switches with two NICs per
zone for load/failover...

This box probably has more power than all of Princeton University or 
Dow Jones Information Retrieval did in 1986 when I left DEC.

How many 11/780's can I run under how many VM's before I can't
successfully search the web and download OS torrents?

Bill


Bill


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 3:27:43 AM
On 2014-08-05, George Cornelius <cornelius@nowhere.net> wrote:
>
> As far as I know, they had no hobbyist program.  I have several
> (micro) 11's at home, each with the original O/S they had running
> when I purchased them.  I do not believe I'm actually even legally
> entitled to run those.
>

Mentec did have a hobbyist program, but it was designed for the simh
emulator only:

	http://www.aracnet.com/~healyzh/pdp11emu.html

There are also some questions about if the licence continued to apply
after Bob Supnik stopped working on simh as a DEC employee (ie: when
he left DEC).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/6/2014 11:55:52 AM
On 2014-08-05, Chris Scheers <chris@applied-synergy.com> wrote:
>
> No, you don't flip bits on a mode change.
>
> You have parallel, pre-built page tables for each mode with the 
> protections you need for that mode.  On CHMx/return calls, you change to 
> the appropriate page table for the new mode.
>
> All possible page protections (including URKW) are available with this 
> design.
>
> Yes, mode changes have TLB flush overhead with this design, but if it is 
> the difference between working and not working, so be it.
>

I'm still trying to work out how VSI are going to pull this off without
having crazy stupid overheads.

Are they going to split VMS over the 4 rings and do something creative
with the ring protections to help reduce the overheads, or are they going
for a pure ring 0/ring 3 split and do the emulation by purely switching
page tables ?

As was pointed out earlier, PCID does exist for x86-64, but that's only
a 12 bit field and you would presumably need multiple (and unique) PCID
values for each VMS process.

The core problem here (for the benefit of other people reading this and
not understanding the performance issue) is that every time you switch
the page tables, you have to invalidate the TLB entries covering the
existing page table entries. There are tools available in x86-64 to
reduce the overheads, but you are still going to have overheads.

Consider an application program which does 5000 RMS record reads and
needs to switch to executive mode to perform those reads.

Each record read will need two mode switches (user -> executive and
the return executive -> user), so for the above example, the application
needs 10,000 page table switches to perform those 5000 reads.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/6/2014 12:15:30 PM
On Tuesday, August 5, 2014 11:07:45 PM UTC-4, William Pechter wrote:
> In article <53e19192$0$2853$c3e8da3$66d3cc2f@news.astraweb.com>,
>=20
> ... Omitted for brevity ...
>=20
>=20
>=20
> Basically it copies all the memory to a file and  (kind of like
>=20
> checkpointing) and then the other  server fires up the box....  It
>=20
> really looks like a very fast laptop hibernate and resume...)
>=20
>=20
>=20
> This assumes storage accessable by both host platforms at the same time.
>=20
> The machine does the necessary gratuitous arp to say... "I'm over
>=20
> here" to the network and switches... and off it goes.
>=20
>=20
>=20
> If there's the need for a storage move to a different SAN or NFS datastor=
e
>=20
> the Windows and VMware stuff can now do a storage copy between storage
>=20
> systems live and then the machine can be migrated...
>=20
>=20
>=20
> I've seen about two pings lost at the worst when this happens.
>=20
>=20
>=20
> >Does it have its own SCS-like and MSCP like protocols ? Or use some
>=20
> >industry standard ones  ?
>=20
> >
>=20
>=20
>=20
> It just uses the standard NFS or ISCSI or Fiber Channel protocols
>=20
> between the host and the storage.  The VM only sees the presented out
>=20
> disk container files.
>=20
>=20
>=20
> >In the context of Galaxy, would VMware allow formation of a Galaxy
>=20
> >across physical servers ? (opresent remote server's memory as shared
>=20
> >NUMA memory ?(
>=20
>=20
>=20
> I have no idea if that is possible.  Basic clustering between Windows
>=20
> servers or linux servers -- yes...
>=20
>=20
>=20
> Shared disks can be set up between machines...  Hot standby is possible.
>=20
>=20
>=20
>=20
>=20
> >And from a cluster point of view, if two nodes on same physical server
>=20
> >use special memory interconnects for very fast SCS communications, but
>=20
> >you decide to move one instance to another physicxal server, would VMS
>=20
> >failover to Ethernet automatically ?
>=20
> >
>=20
>=20
>=20
> I don't know if they support special memory interconnects between the
>=20
> virtual machines.
>=20
>=20
>=20
> With support for 40gig ethernet between the hosts would you need
>=20
> something faster for Galaxy?
>=20
>=20
>=20
>=20
>=20
> Bill
>=20
> --=20
>=20
> --=20
>=20
> Digital had it then.  Don't you wish you could buy it now!
>=20
> pechter-at-pechter.dyndns.org        http://xkcd.com/705/

Bill,

With all due respect, some clarifications.=20

I am not sure it is was VMWARE, but I attended a presentation a while ago a=
bout VM migration. While somewhat equivalent to hibernate/re-start, it was =
a bit more subtle.

A copy was made machine to machine, but the first machine was still running=
.. Then the pages that were modified in the interim were updated (possibly i=
teratively), until final switchover. The extra differential updates were ne=
eded to make the downtime switch as short as possible.

The ARPs are hardly gratuitous. Without them, message traffic (at the IEEE =
802.3 aka Ethernet level; below the IP level), would not be able to find th=
e correct target. At that level, addressing is by adapter address, which is=
, in most implementations different on different physical nodes. The except=
ion is DECnet adapters, where the adapter MAC address is altered to a value=
 that is a function of the DECnet node number.

- Bob Gezelter, http://www.rlgsc.com
0
Bob
8/6/2014 12:35:54 PM
In article <lrroi7$n7l$1@speranza.aioe.org>,
	George Cornelius <cornelius@nowhere.net> writes:
> Johnny Billquist wrote:
>> On 2014-08-04 15:21, Bill Gunshannon wrote: 
>>> In article <IjTCv.136775$AN6.25160@fx01.iad>,
>>> <rschaffrath@yahoo.com> writes:
> 
>>>> I just hope that VMS thrives and does not wind up like RSTS/E under
>>>> Mentec.  That basically fizzled.
>>>
>>>
>>> How did it fizzle?  Mentec continued to maintain it and even did all the
>>> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
>>> I think all three PDP-11 OSes had longer lives under Mentec than they had
>>> under DEC.
>> 
>> 
>> Not really. Active development continued for about 5 years at Mentec,
>> and then another 10 years of slow death. They did live longer at DEC,
>> 
>> But I agree that it's a bit unfair to just say they fizzled at Mentec.
>> However, RSTS/E might have gotten the least attention of all of them at
>> Mentec.
> 
> As far as I know, they had no hobbyist program.  

True, don't get me started again on why I think that was the case!!

>                                                  I have several
> (micro) 11's at home, each with the original O/S they had running
> when I purchased them.  I do not believe I'm actually even legally
> entitled to run those.

Not unless you purchased commercial licenses.

> 
> I do have Venix (System V r2) on my DEC Professional.  I guess
> I can run that one.

Or Ultrix-11.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   
0
bill
8/6/2014 1:05:41 PM
In article <lrr4e1$nnh$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> 
> I've got my card in my wallet since the mid 80's.
> Never know when you need it... :-)

   You're not alone.  My card is in the same place.

0
koehler
8/6/2014 1:19:15 PM
In article <lrr9kv$i4a$1@dont-email.me>, Chris Scheers <chris@applied-synergy.com> writes:
> 
> Note that U, S, and E are all "user" modes that just differ in their 
> memory protections.  Even though we refer to S and E as "privileged", 
> they are not privileged at the hardware level.  This is true even on the 
> VAX.

   Define "priviledged".  Some instructions only run in kernel mode.
   Some pages are only readable in kernel mode.  Some pages are
   only writable in kernel mode.  Some pages are only readable in 
   executive or kernel mode, ...

   For many issues, page access is privilege.

0
koehler
8/6/2014 1:22:34 PM
On 2014-08-06 13:22:34 +0000, Bob Koehler said:

>    For many issues, page access is privilege.

The virtual memory page access protection mechanism is *the* 
fundamental mechanism of system security, and underlies all of software 
and hardware security.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/6/2014 1:50:17 PM
On 2014-08-06, Bob Gezelter <gezelter@rlgsc.com> wrote:
> On Tuesday, August 5, 2014 11:07:45 PM UTC-4, William Pechter wrote:
>> In article <53e19192$0$2853$c3e8da3$66d3cc2f@news.astraweb.com>,
>> 
>> ... Omitted for brevity ...
>> 
>> Basically it copies all the memory to a file and  (kind of like
>> checkpointing) and then the other  server fires up the box....  It
>> really looks like a very fast laptop hibernate and resume...)
>> 
>> This assumes storage accessable by both host platforms at the same time.
>> The machine does the necessary gratuitous arp to say... "I'm over
>> here" to the network and switches... and off it goes.
>> 
>> If there's the need for a storage move to a different SAN or NFS datastore
>> the Windows and VMware stuff can now do a storage copy between storage
>> systems live and then the machine can be migrated...
>> 
>> I've seen about two pings lost at the worst when this happens.
>> 
> Bill,
>
> With all due respect, some clarifications. 
>
> I am not sure it is was VMWARE, but I attended a presentation a while
> ago about VM migration. While somewhat equivalent to hibernate/re-start,
> it was a bit more subtle.

I saw a demo using Hyper-V in 2010.  The claim then was that the transition
would occur with not a single ping being lost and yes that did work in the
demo.  I was cynical about active transactions doing real work (in contrast
to a ping), but I gather that active work can be shifted nowadays.

> A copy was made machine to machine, but the first machine was still
> running. Then the pages that were modified in the interim were updated
> (possibly iteratively), until final switchover. The extra differential
> updates were needed to make the downtime switch as short as possible.
> >
> The ARPs are hardly gratuitous. Without them, message traffic (at the
> IEEE 802.3 aka Ethernet level; below the IP level), would not be able to
> find the correct target. At that level, addressing is by adapter
> address, which is, in most implementations different on different
> physical nodes. The exception is DECnet adapters, where the adapter MAC
> address is altered to a value that is a function of the DECnet node
> number.

Enter Software Defined Networking, aka SDN.  I've just done a course on
this. SDN has the concept of pseudo MAC addresses which reflect the part
of the network they reside in, and can do the re-ARPing automatically
when a node moves in the network.

<https://en.wikipedia.org/wiki/Software-defined_networking>

or leap straight to the bit which talks about VMs

<https://en.wikipedia.org/wiki/Software-defined_networking#Applications>

And yes, the lecture covering pseudo MAC addresses did give me a chuckle
because I could relate it to what DECnet has done for years.


-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/6/2014 1:51:53 PM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
> William Pechter
> Sent: 05-Aug-14 10:57 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> In article <mailman.1.1407251053.25770.info-vax_info-vax.com@info-
> vax.com>,
> Kerry Main  <kerry.main@backtothefutureit.com> wrote:
> >> -----Original Message-----
> >> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
> >> John E. Malmberg
> >> Sent: 05-Aug-14 1:21 AM
> >> To: info-vax@info-vax.com
> >> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> >> continue development of OpenVMS and Layered Products under HP
> License
> >>

[snip]

> >> While I can not mention specific installations, the trend is
> >> definitely to running on hypervisors with VMs deployed the way that
> >> on timesharing you would have deployed a set of processes instead of
> dedicated servers.
> >>
>=20
> >While this is true, established shops using VMware for a while now are
> >now running into major issues with VM sprawl. Unfortunately, because of
> >cultural and technical challenges, VM sprawl is exponentially harder to
> >address than physical server sprawl. Essentially this is all about OS
> >instance consolidation. You need to have strict VM governance in place
> >or your shop will soon fall over with non-standard configs, unpatched
> >security VM's, vastly increased licensing costs.
>=20
> Actually, we got better control of stuff under VMware.  We had the abilit=
y to
> have everything backed with VM's in sync'd to the disaster recovery site.=
  We
> didn't have all the hardware for the 2 and 1 U servers that went into
> production for when the departments bought applicatons and hardware.
> They rarely looked into test and development box support with vendor
> software.
>=20

Bill - in a well-run enterprise IT shop, proper VM governance is definitely=
 required for large VM environments. It sounds like your shop has this unde=
r control.=20

Where things break down is when developers, others in various BU's have the=
 ability to create / request VMs be created on the fly with no review/appro=
val process in place from the IT dept. Just because something can be done v=
ery quick from a technical perspective e.g. VM creation, does not mean it i=
s the in the best interests of the company to do so.

> With the correct sized VMware hosts we made sure we had test/dev backing
> for all the boxes before go-live.
>=20

Agree - one of the biggest benefits of VM's in general (any hypervisor), is=
 ability to create dev/test environments and then delete them when they are=
 no longer required.

> As far as non-standard configs -- the OS's were all built to standards.
> Patching was done on a schedule for all the IT boxes.  The only thing we
> didn't patch were University boxes used by profesors for things like the
> computing research cluster... etc.
>=20
> >Developers will be upset at these extra controls (they like creating
> >VM's whenever they like), but if you want to get VM sprawl under
> >control, you need to establish firm VM governance.
>=20
> >How does one do OS instance consolidation to reduce licensing, LP,
> >staffing, security costs?
>=20
> Much more of a problem on Windows then RHEL.  We just re-utilized the old
> RHEL licenses on new VM's as we replaced them.
>=20
> Keeping a pool of 120 or so licenses left us able to keep a free pile of =
10-20
> licenses that we'd use for rolling upgrades.
> The Windows guys had to deal with Microsoft's open licensing and whatever
> the University arraingment was.
>=20
> The RHEL licenses also don't stop you from installing more than your coun=
t as
> part of the upgrade... so sometimes I'd put up 121 and then schedule a
> shutdown and license move and do the final switch out in the maintenance
> window.  Most of our extra licenses were coming from decommissioned
> licenses from stuff moved out to the cloud or from physical boxes that we=
re
> virtualized.
>=20
> We didn't do much Linux VM cloning since we had an automated kickstart
> installation that mostly fully scripted...
>=20
> >Well, one approach is to use Application stacking. Course, try and
> >convince Linux and Windows Bus groups they need to share their business
> >application on the same OS instance as another bus application. Watch
> >the fireworks explode. "DLL hell" is something I am sure would come up
> >in the discussion as well.
>=20
> Not something I've seen in 6 years admining on ESX on the Linux side.
> Mixing applications is easy, and a normal Unix thing -- but when differen=
t app
> vendors support different versions of the OS you can get clipped by App A
> needs to run on Linux RHEL6.x and App B on the same box is not supported
> on newer than v5.8.
>=20

The issue I have seen is more cultural i.e. even if technically possible, B=
USA does not want BUSB's apps on their system. Also, the use of class sched=
ulers to prevent one App from doing undesirable things on the system, is no=
t that common in Linux environments (primarily because of the one Bus app e=
nvironment per OS instance culture).

> It's easier to right size the VM for the one app and you can roll in and =
out
> version upgrades and OS upgrades without having compatibility issues
> between app and OS.
>=20

The issue is that many 3rd party apps are licensed on a per OS instance or =
per CPU /vCPU basis (and we are talking big $'s for some apps).  What is a =
CPU also depends on whether one is talking sockets, cores or vCPU's. Oracle=
 is good example of how VM costs (easily 5-6 digits) can go through the roo=
f. As I recall, it boils down to one having to license every physical cpu t=
hat the DB running in a vCPU might actually run on.Every Dev VM typically r=
equires a DB and this gets costly.

Btw, most people likely know this, but Oracle split from Red Hat and now of=
fer their own bare metal hypervisor called Oracle Enterprise Linux (OEL). T=
hey also have their own virtualization technology called Oracle VM (XenServ=
er repackaged?). They have some strict views on what is supported.  At $40K=
+ list per cpu (add 50% per CPU for RAC) multiplied by a processor core fac=
tor (Oracles way of inflating competitive HW costs) for the enterprise DB's=
, you can see why it can get expensive.

Reference:
http://www.oracle.com/us/026952.pdf
http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf=
=20

And a great read to see what per CPU costs are for various Oracle products =
- check out DB Gateway for Teradata costs :-)=20
http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf

[snip]

Regards,

Kerry Main
Back to the Future IT Inc.
 .. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com



0
Kerry
8/6/2014 2:44:48 PM
On 2014-08-06 13:51:53 +0000, Paul Sture said:

> Enter Software Defined Networking, aka SDN.

AKA, "virtualization" comes to the networking world.

Some of the same sorts of "fun" can arise with SDN as arose with 
virtualized memory, virtualized servers, virtualized storage, etc., too.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/6/2014 3:05:24 PM
JF Mezei wrote:

> How much of what Galaxy does is already implemented in VMware and would
> easily interface with the existing Galaxy code in VMS to provide the
> same services that were provided by the Wilfire and successor Alpha
> hardware ?
> 
> There has been mention that VMware is able to move an OS instance from
> one physical server to another "live" without interruption. How is that
> accomplished ?  Does it actually freeze the source system while it
> copies all memory ?

My own very limited understand is that:

Galaxy can move processors between instances of the OS

VM can move instances of the OS to another VM (processor)

It seems to me that while the two are basically the opposite of each 
other, in practical usage, they share many of the same benefits.
0
David
8/6/2014 4:12:20 PM
William Pechter wrote:

> I've seen about two pings lost at the worst when this happens.

For the nit pickers such as myself, this tells me that it's
"not reliable".  Perhaps for many users, it's acceptable.  But I'd guess 
that for real time stuff, it would be unacceptable.

"Oh, what happened to that $20 million transaction ????"
0
David
8/6/2014 4:16:09 PM
On Wed, Aug 6, 2014 at 12:16 PM, David Froble via Info-vax <
info-vax@rbnsn.com> wrote:

> William Pechter wrote:
>
>  I've seen about two pings lost at the worst when this happens.
>>
>
> For the nit pickers such as myself, this tells me that it's
> "not reliable".  Perhaps for many users, it's acceptable.  But I'd guess
> that for real time stuff, it would be unacceptable.
>
> "Oh, what happened to that $20 million transaction ????"


So how does that transaction deal with network hiccups that cause a packet
or two to be dropped?

As for real time applications on VMware, I don't think that's their target
market.

-jav
0
Javier
8/6/2014 4:47:49 PM
On 2014-08-06 16:16:09 +0000, David Froble said:

> William Pechter wrote:
> 
>> I've seen about two pings lost at the worst when this happens.
> 
> For the nit pickers such as myself, this tells me that it's
> "not reliable".  Perhaps for many users, it's acceptable.  But I'd 
> guess that for real time stuff, it would be unacceptable.
> 
> "Oh, what happened to that $20 million transaction ????"

Loosing a couple of pings now and again is almost intrinsic with an IP 
network, and TCP/IP and DECnet for that matter were written with 
typical network hardware error rates in mind.

The expected network error rates are substantially higher than storage 
hardware error rates, too — this is one of the reasons why there is a 
price delta between NICs and FC SAN HBAs.

As for that hypothetical $20 million dollar transaction, that 
particular transaction might or will fail and will be rolled back 
(assuming TCP/IP didn't ride over the error), and the operation will 
usually be retried.   That's why we use databases and distributed 
transaction managers for certain sorts of applications, after all.

If you're sending $20 million by UDP/IP and/or outside of transactions, 
you're probably only running something of the ilk of the MtGox BitCoin 
exchange and, well, surprises happen.


-- 
Pure Personal Opinion | HoffmanLabs LLC

0
Stephen
8/6/2014 4:48:59 PM
On 2014-08-05, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
>
>  From :
>
> http://www.enterprisetech.com/2014/08/01/upstart-breathe-new-life-venerable-openvms/
>
> [Duane Harris is CEO at VMS Software Inc]
>
> "�We have no illusions that we are going to take the market back
> from Linux any time soon,� says Harris with a laugh. �But frankly,
> we don�t want to limit ourselves to X86 chips, either. We have a
> marquee operating system that is widely used in embedded environments
> and it is time to broaden its scope.� That could mean OpenVMS ports
> to ARM, MIPS, and other processor architectures."
>
> That last sentence is not from Harris, though....
>

Careful. :-)

We still don't know if VSI are using all four rings or if they are
folding VMS into ring 0/ring 3 and doing the other stuff by playing
around purely with page tables only. The reason that matters is
because the ARM and MIPS architectures have 2 rings only.

We also don't know if VSI are using x86-64 paging capabilities which
might not exist in MIPS/ARM architectures to try and reduce page table
overheads while playing games with User/Executive/Supervisor modes.

(In these games, I'm assuming the Kernel memory areas are permanently
mapped as in a traditional 2 ring kernel and are protected from the
_hardware_ User mode.)

There's also the fact that VMS, unlike Linux, is currently a 64 bit
operating system only, so I doubt you are going to be able to run
VMS on a Beaglebone Black or Raspberry Pi board. :-)

I also think there are too many well established and respected
alternatives (including free ones) in the embedded world for
VMS to make a serious dent. VMS would also have to be structured
around a BSP concept for it to be viable in today's embedded market.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/6/2014 5:33:54 PM
Simon Clubley wrote 2014-08-06 19:33:
> On 2014-08-05, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
>>
>>   From :
>>
>> http://www.enterprisetech.com/2014/08/01/upstart-breathe-new-life-venerable-openvms/
>>
>> [Duane Harris is CEO at VMS Software Inc]
>>
>> "�We have no illusions that we are going to take the market back
>> from Linux any time soon,� says Harris with a laugh. �But frankly,
>> we don�t want to limit ourselves to X86 chips, either. We have a
>> marquee operating system that is widely used in embedded environments
>> and it is time to broaden its scope.� That could mean OpenVMS ports
>> to ARM, MIPS, and other processor architectures."
>>
>> That last sentence is not from Harris, though....
>>
>
> Careful. :-)
>
> We still don't know if VSI are using all four rings...

I just couldn't care less about ring this or ring that.
It's totaly uninteresting. My interest is in the practical
use ov VMS.

But no, I do not expect an ARM version of VMS anytime soon.

Jan-Erik.
0
Jan
8/6/2014 6:00:01 PM
In article <c4enh5Fq0caU3@mid.individual.net>,
Bill Gunshannon <billg999@cs.uofs.edu> wrote:
>In article <lrroi7$n7l$1@speranza.aioe.org>,
>	George Cornelius <cornelius@nowhere.net> writes:
>> Johnny Billquist wrote:
>>> On 2014-08-04 15:21, Bill Gunshannon wrote: 
>>>> In article <IjTCv.136775$AN6.25160@fx01.iad>,
>>>> <rschaffrath@yahoo.com> writes:
>> 
>>>>> I just hope that VMS thrives and does not wind up like RSTS/E under
>>>>> Mentec.  That basically fizzled.
>>>>
>>>>
>>>> How did it fizzle?  Mentec continued to maintain it and even did all the
>>>> Y2K stuff.  It lasted until Mentec got out of the PDP-11 world entirely.
>>>> I think all three PDP-11 OSes had longer lives under Mentec than they had
>>>> under DEC.
>>> 
>>> 
>>> Not really. Active development continued for about 5 years at Mentec,
>>> and then another 10 years of slow death. They did live longer at DEC,
>>> 
>>> But I agree that it's a bit unfair to just say they fizzled at Mentec.
>>> However, RSTS/E might have gotten the least attention of all of them at
>>> Mentec.
>> 
>> As far as I know, they had no hobbyist program.  
>
>True, don't get me started again on why I think that was the case!!
>
>>                                                  I have several
>> (micro) 11's at home, each with the original O/S they had running
>> when I purchased them.  I do not believe I'm actually even legally
>> entitled to run those.
>
>Not unless you purchased commercial licenses.

DEC was pretty good about reasonably pricing license transfers.
I'm not sure what would happen if you asked HP to, say, transfer the
license from some PDP11 which was being disposed of to a new owner.

My bet is they'd never be able to track the stuff and a major circle
jerk would occur unless the original owner had the license paperwork for
the original sale.  I don't know if that info transitioned to Mentec or
the new owner.

>> I do have Venix (System V r2) on my DEC Professional.  I guess
>> I can run that one.
>
>Or Ultrix-11.

Only if he ported it to the Pro3x0

>
>bill
>
>-- 
>Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
>billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
>University of Scranton   |
>Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 6:21:47 PM
In article <81275539-46fc-4adb-9fd4-ef7ee28e0ffc@googlegroups.com>,
Bob Gezelter  <gezelter@rlgsc.com> wrote:
>On Tuesday, August 5, 2014 11:07:45 PM UTC-4, William Pechter wrote:
>> In article <53e19192$0$2853$c3e8da3$66d3cc2f@news.astraweb.com>,
>> 
>> ... Omitted for brevity ...
>> 
>> 
>> 
>> Basically it copies all the memory to a file and  (kind of like
>> 
>> checkpointing) and then the other  server fires up the box....  It
>> 
>> really looks like a very fast laptop hibernate and resume...)
>> 
>> 
>> 
>> This assumes storage accessable by both host platforms at the same time.
>> 
>> The machine does the necessary gratuitous arp to say... "I'm over
>> 
>> here" to the network and switches... and off it goes.
>> 
>> 
>> 
>> If there's the need for a storage move to a different SAN or NFS datastore
>> 
>> the Windows and VMware stuff can now do a storage copy between storage
>> 
>> systems live and then the machine can be migrated...
>> 
>> 
>> 
>> I've seen about two pings lost at the worst when this happens.
>> 
>> 
>> 
>> >Does it have its own SCS-like and MSCP like protocols ? Or use some
>> 
>> >industry standard ones  ?
>> 
>> >
>> 
>> 
>> 
>> It just uses the standard NFS or ISCSI or Fiber Channel protocols
>> 
>> between the host and the storage.  The VM only sees the presented out
>> 
>> disk container files.
>> 
>> 
>> 
>> >In the context of Galaxy, would VMware allow formation of a Galaxy
>> 
>> >across physical servers ? (opresent remote server's memory as shared
>> 
>> >NUMA memory ?(
>> 
>> 
>> 
>> I have no idea if that is possible.  Basic clustering between Windows
>> 
>> servers or linux servers -- yes...
>> 
>> 
>> 
>> Shared disks can be set up between machines...  Hot standby is possible.
>> 
>> 
>> 
>> 
>> 
>> >And from a cluster point of view, if two nodes on same physical server
>> 
>> >use special memory interconnects for very fast SCS communications, but
>> 
>> >you decide to move one instance to another physicxal server, would VMS
>> 
>> >failover to Ethernet automatically ?
>> 
>> >
>> 
>> 
>> 
>> I don't know if they support special memory interconnects between the
>> 
>> virtual machines.
>> 
>> 
>> 
>> With support for 40gig ethernet between the hosts would you need
>> 
>> something faster for Galaxy?
>> 
>> 
>> 
>> 
>> 
>> Bill
>> 
>> -- 
>> 
>> -- 
>> 
>> Digital had it then.  Don't you wish you could buy it now!
>> 
>> pechter-at-pechter.dyndns.org        http://xkcd.com/705/
>
>Bill,
>
>With all due respect, some clarifications. 
>
>I am not sure it is was VMWARE, but I attended a presentation a while
>ago about VM migration. While somewhat equivalent to hibernate/re-start,
>it was a bit more subtle.

I tried to simplify it down to avoid getting deep into the low level for
those who've never seen it.

>A copy was made machine to machine, but the first machine was still
>running. Then the pages that were modified in the interim were updated
>(possibly iteratively), until final switchover. The extra differential
>updates were needed to make the downtime switch as short as possible.
>

Yes... that's right.  With shared storage the copy's not needed.  The
snapshot mechanism is used so that when the copy starts the VMware IO
goes to a separate file that gets migrated last.  So if you need to
migrate 400gb of disk that copies as new I/O goes to a different file
which acts kind of like a database replay log file and these get
integrated when the machine migrates.  

With shared storage on the back end the amount of disk copying is less.
Usually the storage copy of the VM disk is only used to off-site replicate 
and migrate for disaster recovery.

We used netapp replication to keep the DR site x minutes behind the live
site so if we had a major disaster we wouldn't have to go to tape or
virtual tape.

We could also clone off a copy of the VM disk in case of OS or
application upgrade.  We could test the upgrade on a copy of the
production data and VMware also allowed snapshots which could be removed
to go back to the disk state before the start of the upgrade if it
failed.

If the upgrade doesn't work just point the vm at the original disk
structure or blow off the snapshot.

>The ARPs are hardly gratuitous. Without them, message traffic (at the
>IEEE 802.3 aka Ethernet level; below the IP level), would not be able to
>find the correct target. At that level, addressing is by adapter
>address, which is, in most implementations different on different
>physical nodes. The exception is DECnet adapters, where the adapter MAC
>address is altered to a value that is a function of the DECnet node
>number.

Yup.  Gratuitous arp is what the forcing of the arp cache update was
called by Unix sysadmins... Google seems to see that as a "term of art" 
I think for the process.

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


Bill

-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 6:37:30 PM
In article <lrtga8$tcm$1@dont-email.me>,
Stephen Hoffman  <seaohveh@hoffmanlabs.invalid> wrote:
>On 2014-08-06 13:51:53 +0000, Paul Sture said:
>
>> Enter Software Defined Networking, aka SDN.
>
>AKA, "virtualization" comes to the networking world.
>
>Some of the same sorts of "fun" can arise with SDN as arose with 
>virtualized memory, virtualized servers, virtualized storage, etc., too.
>
>
>-- 
>Pure Personal Opinion | HoffmanLabs LLC
>

And Cisco has Virtual Network Switches -- the Nexus 1000's that are
plugins to the VMware and Windows ecosystems.   Really it's all software
now.  The Cisco switches are optional add-ons that let your Cisco
certified network folks control the ethernet down to the invisible
little RJ45's inside the Virtual Machines. 8-)


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 6:40:38 PM
In article <lrtkc1$sqh$1@dont-email.me>,
David Froble  <davef@tsoft-inc.com> wrote:
>William Pechter wrote:
>
>> I've seen about two pings lost at the worst when this happens.
>
>For the nit pickers such as myself, this tells me that it's
>"not reliable".  Perhaps for many users, it's acceptable.  But I'd guess 
>that for real time stuff, it would be unacceptable.
>

Absolutely.  This isn't designed for industrial control of an oil
refinery.

>"Oh, what happened to that $20 million transaction ????"

If the code was done right the TCP layer would retransmit or the UDP app
would have to request a resend on the lost packet, right.

We're talking about a loss of two 1500 byte packets which is less than 1
second of glitch.

What happens if two ethernet packets collide.  Retransmission is always
part of networking when things don't go right.  

I'm not talking about anything different from what happens on normal
networks when someone pulls on a loose RJ45 and it drops a packet until
it's reseated.  The software controls the retransmission if it's not
received, right.

I don't think this is designed for industrial control of a steel mill.
For normal IT we've migrated things like mail servers and oracle
databases.  We did try to do this off hours, but if hardware fails you do
the best you can.

Our stuff wasn't high frequency trading -- just normal University data
processing. The industrial control stuff we did was probably limited to
controlling card access to various faclilities and computer rooms.

I was told those readers all had their own memory and processing so
they're functional when the computers were even down. The only thing the 
control system did was update the readers access lists every so often.

If you want better reliablity -- redundant networking and clusters on
top of this virtualization is possible.

Virtualization is not a cure-all for bad design.


Bill
-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 6:53:06 PM
In article <mailman.9.1407336294.25770.info-vax_info-vax.com@info-vax.com>,
Kerry Main  <kerry.main@backtothefutureit.com> wrote:
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
>> William Pechter
>> Sent: 05-Aug-14 10:57 PM
>> To: info-vax@info-vax.com
>> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
>> continue development of OpenVMS and Layered Products under HP License
>> 
>> In article <mailman.1.1407251053.25770.info-vax_info-vax.com@info-
>> vax.com>,
>> Kerry Main  <kerry.main@backtothefutureit.com> wrote:
>> >> -----Original Message-----
>> >> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
>> >> John E. Malmberg
>> >> Sent: 05-Aug-14 1:21 AM
>> >> To: info-vax@info-vax.com
>> >> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
>> >> continue development of OpenVMS and Layered Products under HP
>> License
>> >>
>
>[snip]
>
>> >> While I can not mention specific installations, the trend is
>> >> definitely to running on hypervisors with VMs deployed the way that
>> >> on timesharing you would have deployed a set of processes instead of
>> dedicated servers.
>> >>
>> 
>> >While this is true, established shops using VMware for a while now are
>> >now running into major issues with VM sprawl. Unfortunately, because of
>> >cultural and technical challenges, VM sprawl is exponentially harder to
>> >address than physical server sprawl. Essentially this is all about OS
>> >instance consolidation. You need to have strict VM governance in place
>> >or your shop will soon fall over with non-standard configs, unpatched
>> >security VM's, vastly increased licensing costs.
>> 
>> Actually, we got better control of stuff under VMware.  We had the ability
>> to have everything backed with VM's in sync'd to the disaster recovery 
>> site. 
>> We didn't have all the hardware for the 2 and 1 U servers that went into
>> production for when the departments bought applicatons and hardware.
>> They rarely looked into test and development box support with vendor
>> software.
>> 
>
>Bill - in a well-run enterprise IT shop, proper VM governance is
>definitely required for large VM environments. It sounds like your shop
>has this under control. 

Not at first 8-).

But they pushed ITIL and that tended to get approvals and sign-offs in
line and they limited who could create the VMs.

No programmer could cut machines.  Installs and machine copies and
clones all went through the ticketing system and needed approvals.
Emergency changes needed senior IT management sign off.

Did we have the: "We need 4 web servers and 2 oracle db boxes up by
Monday.  The vendor's been paid do intall and set them up next week..."

Sure... With VM's we could get the word on Wednesday and the boxes would
be ready by Monday morning. Try that with rush ordered hardware.

>Where things break down is when developers, others in various BU's have
>the ability to create / request VMs be created on the fly with no
>review/approval process in place from the IT dept. Just because
>something can be done very quick from a technical perspective e.g. VM
>creation, does not mean it is the in the best interests of the company
>to do so.

Yes, but it's easy to prototype and test before committing money to
real hardware.  We've had projects where departments purchased vendor
software  and hardware without IT approvals.  At least pushing to
virtual avoids the hardware spending and duplication.  Power
requirements are also controlled.

VMware's management console (Vsphere) controls the level of access users had.
We even eliminated developers access to that.  They had RDP and SSH
where needed.  If the box needed rebooting on the Unix side or Windows
side those permissions and controls were set up inside the Virtual
Machine.

VMware has 60 day (IIRC) demo licenses so you can just download the
software and set it up and test.  I was amazingly productive with the
toolset.

>> With the correct sized VMware hosts we made sure we had test/dev backing
>> for all the boxes before go-live.

>Agree - one of the biggest benefits of VM's in general (any hypervisor),
>is ability to create dev/test environments and then delete them when
>they are no longer required.

>> As far as non-standard configs -- the OS's were all built to standards.
>> Patching was done on a schedule for all the IT boxes.  The only thing we
>> didn't patch were University boxes used by profesors for things like the
>> computing research cluster... etc.
>> 
>> >Developers will be upset at these extra controls (they like creating
>> >VM's whenever they like), but if you want to get VM sprawl under
>> >control, you need to establish firm VM governance.
>> 

Isn't that the reason for IT management to exist?  Or is it to golf with
the sales reps... 8-)

>The issue is that many 3rd party apps are licensed on a per OS instance
>or per CPU /vCPU basis (and we are talking big $'s for some apps).  What
>is a CPU also depends on whether one is talking sockets, cores or
>vCPU's. Oracle is good example of how VM costs (easily 5-6 digits) can
>go through the roof. As I recall, it boils down to one having to license
>every physical cpu that the DB running in a vCPU might actually run
>on.Every Dev VM typically requires a DB and this gets costly.

We're seeing the licensing on most things starting to work with Virtual
CPU or core count.  The biggest licensing headache was the VMware one
when they started counting processor and core count.  We were site
licensed up to xxx.   Suddenly we had to run around and re-inventory and
prove we were in compliance.  We were well under the amount licensed
since we hadn't gotten the Virtual Desktop stuff going due to manpower
and time restrictions.

IIRC, Microsoft's now giving unlimited licenses for windows datacenter 
2012R2 VM's hosted up on HyperV on datacenter 2012R2.  IIRC what the
windows guys told me... applications like SqlServer are a bitch in 
the licensing since if we're running VMware Microsoft wants licensing 
per physical cpu on the ESX host.

I think Oracle is also a pain.  We dropped Solaris as soon as the vendor
for one of our apps had Linux support up to prime time.  Oracle kept
pushing us to move to Oracle Linux from RedHat.  We were a big Oracle
shop with a pile of Oracle database instances.  One machine had over 10
on the vm.  

We had some University licensing so I'm sure we were discounted in a big
way.

>Btw, most people likely know this, but Oracle split from Red Hat and now
>offer their own bare metal hypervisor called Oracle Enterprise Linux
>(OEL). They also have their own virtualization technology called Oracle
>VM (XenServer repackaged?). They have some strict views on what is
>supported.  At $40K+ list per cpu (add 50% per CPU for RAC) multiplied
>by a processor core factor (Oracles way of inflating competitive HW
>costs) for the enterprise DB's, you can see why it can get expensive.

Yup...we had no RAC stuff and had some kind of site license on Orcle's
other database products.  We were running 10g and 11 when I left.
As far as support goes... VMware and RedHat were pretty good.  I don't
think I ever used RedHat support beyond Google searches.  In 7 years
they only broke one thing on us... printing of PostScript forms.

They changed the Ascii->Postscript processing between RHEL3 and RHEL5
and nothing fit the preprinted schedule and billing forms.  Turns out we
just had to revert the processing app back to the original which they
were still shipping.  I compared the print configs and found the change.
A couple of months later a Google search pulled that in about 1 day...
We weren't the only ones bitten on that.

>
>Reference:
>http://www.oracle.com/us/026952.pdf
>http://www.oracle.com/technetwork/server-storage/vm/ovm-hardpart-168217.pdf 

Interesting.

>
>And a great read to see what per CPU costs are for various Oracle
>products - check out DB Gateway for Teradata costs :-) 
>http://www.oracle.com/us/corporate/pricing/technology-price-list-070617.pdf
>
>[snip]
>
>Regards,
>
>Kerry Main
>Back to the Future IT Inc.


Bill
> .. Learning from the past to plan the future
>
>Kerry dot main at backtothefutureit dot com
>
>
>


-- 
-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-pechter.dyndns.org        http://xkcd.com/705/
0
pechter
8/6/2014 7:22:17 PM
On 2014-08-06, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
> Simon Clubley wrote 2014-08-06 19:33:
>>
>> Careful. :-)
>>
>> We still don't know if VSI are using all four rings...
>
> I just couldn't care less about ring this or ring that.
> It's totaly uninteresting. My interest is in the practical
> use ov VMS.
>

Actually, these issues have a direct impact on how viable a x86-64
port is as well as how viable it might be to further port VMS to
yet another architecture.

And besides, (just in case you have not figured it out yet :-)), some
of us absolutely love this stuff. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Simon
8/6/2014 7:49:32 PM
On 2014-08-06, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2014-08-06 13:51:53 +0000, Paul Sture said:
>
>> Enter Software Defined Networking, aka SDN.
>
> AKA, "virtualization" comes to the networking world.
>
> Some of the same sorts of "fun" can arise with SDN as arose with 
> virtualized memory, virtualized servers, virtualized storage, etc., too.

Um.  The sight of a piece of menu file in the middle of a stock record 
display screen (which didn't even access that file) was something I have
not forgotten.

I don't know if BT are dipping their toes into it yet, but one of the
things SDN is supposed to do wrt home routers is supporting separate
services for traffic caps and billing (via separate suppliers too, but
there's the current kerfuffle about net neutrality to overcome first on
that front).

<http://www.theregister.co.uk/2014/08/06/bt_bills_customers_for_using_free_fon_wifi_hotspots/>

Oops.

-- 
The early bird gets the worm but the second mouse gets the cheese.
The early mouse is now a late mouse of course.
0
Paul
8/6/2014 8:26:31 PM
> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces@info-vax.com] On Behalf Of
> William Pechter
> Sent: 06-Aug-14 3:22 PM
> To: info-vax@info-vax.com
> Subject: Re: [New Info-vax] VMS Software, Inc. announces agreement to
> continue development of OpenVMS and Layered Products under HP License
>=20
> In article <mailman.9.1407336294.25770.info-vax_info-vax.com@info-
> vax.com>,
> Kerry Main  <kerry.main@backtothefutureit.com> wrote:

[snip...]

> >
> >Bill - in a well-run enterprise IT shop, proper VM governance is
> >definitely required for large VM environments. It sounds like your shop
> >has this under control.
>=20
> Not at first 8-).
>=20
> But they pushed ITIL and that tended to get approvals and sign-offs in li=
ne
> and they limited who could create the VMs.
>=20
> No programmer could cut machines.  Installs and machine copies and clones
> all went through the ticketing system and needed approvals.
> Emergency changes needed senior IT management sign off.
>=20

Back to basics .. gotta love it.=20

> Did we have the: "We need 4 web servers and 2 oracle db boxes up by
> Monday.  The vendor's been paid do intall and set them up next week..."
>=20
> Sure... With VM's we could get the word on Wednesday and the boxes
> would be ready by Monday morning. Try that with rush ordered hardware.
>=20

The concept of pooled resourcing vs. the traditional sequential process of =
ordering on demand is the basics of internal shared services which has been=
 around for at least a