VMS port to x86

  • Permalink
  • submit to reddit
  • Email
  • Follow


Was thinking about the Oracle allegations against HP.

HP did have plans to port HP-UX to x86 and started the work.
And I have been told that porting of VMS to x86 had also been started.

Neither of which would have been official projects since they couldn't
appear in any books since HP wanted very much to hide the fact that
IA64'S EOL was aready planned.


At some point, HP decided to not port to x86.

Then, VMS experienced engineering team is fired and replaced by newbie
programmers given 2 weeks of training.

Looks to me that once HP decided to end of line its proprietary OS at
same time as IA64, there was no point in keeping the experienced
engineering teams since they wouldn't be needed for the port.

I fear it may be too late to save VMS.
0
Reply jfmezei.spamnot (9469) 3/20/2012 2:20:40 AM

See related articles to this posting

In article <4f67e979$0$4672$c3e8da3$3a1a2348@news.astraweb.com>,
 JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:

> I fear it may be too late to save VMS.

We can always hope they'll release the source code for some earlier 
version, such as 7.3.  Then we can have some fun.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
Reply howard578 (2137) 3/20/2012 4:27:59 AM

> I fear it may be too late to save VMS.

   F L A S H !   SUN RISES IN MORNING
0
Reply sms.antinode (948) 3/20/2012 4:31:01 AM

Steven Schweda wrote:

>    F L A S H !   SUN RISES IN MORNING


Well, it is morning here already (01:18) and the sun has not risen. :-)

And towards end of june the sun doesn't rise at Inuvik and further
north. (neither does it set).

So that rule which you thought was unbreakable is in fact breakable.  :-)
0
Reply jfmezei.spamnot (9469) 3/20/2012 5:19:00 AM

JF Mezei schrieb:

> 
> At some point, HP decided to not port to x86.
> 

According to what I've read,
there was no customer demand for it.


> 
> Looks to me that once HP decided to end of line its proprietary OS at
> same time as IA64, there was no point in keeping the experienced
> engineering teams since they wouldn't be needed for the port.
> 
> I fear it may be too late to save VMS.

well, iirc, the source listing is available,
so feel free to start your own skunkworks project.

0
Reply M.Kraemer (2048) 3/20/2012 10:22:29 AM

Howard S Shubs wrote:
> In article <4f67e979$0$4672$c3e8da3$3a1a2348@news.astraweb.com>,
>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> 
>> I fear it may be too late to save VMS.
> 
> We can always hope they'll release the source code for some earlier 
> version, such as 7.3.  Then we can have some fun.
> 

There already exists a Macro32 compiler, used on both Alpha and itanic.  Don't know what 
language it's written in, but with recent trends, probably (hock, spit) C.

Same argument for Bliss.

Just being able to compile the code probably isn't the only requirements.  There is most 
likely some things that depend upon the underlying hardware.  That's a conservative 
assumption to make.

Not going to try to guess what all the problems might be, but, I've got to think that it's 
not just a complete re-write.
0
Reply davef3 (3717) 3/20/2012 3:20:31 PM

On Tuesday, March 20, 2012 11:20:31 AM UTC-4, David Froble wrote:
> Howard S Shubs wrote:
> > In article <4f67e979$0$4672$c3e8da3$3a1a2348@news.astraweb.com>,
> >  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> >=20
> >> I fear it may be too late to save VMS.
> >=20
> > We can always hope they'll release the source code for some earlier=20
> > version, such as 7.3.  Then we can have some fun.
> >=20
>=20
> There already exists a Macro32 compiler, used on both Alpha and itanic.  =
Don't know what=20
> language it's written in, but with recent trends, probably (hock, spit) C=
..
>=20
> Same argument for Bliss.
>=20
> Just being able to compile the code probably isn't the only requirements.=
  There is most=20
> likely some things that depend upon the underlying hardware.  That's a co=
nservative=20
> assumption to make.
>=20
> Not going to try to guess what all the problems might be, but, I've got t=
o think that it's=20
> not just a complete re-write.

As with previous ports, there are many things involved.  Simply porting the=
 compilers won't be enough.  The Macro compiler and the bliss compiler use =
the GEM backend code generator.  That too would need to be developed.  Also=
, tehre are "hardware assists" that are used to implement some of the VMS "=
isms" that exist.  For example, I don't think that the x86 has the concept =
of 4 operating priv modes.

Dan
0
Reply dansabrservices (320) 3/20/2012 4:47:38 PM

In article <543564.889.1332262058086.JavaMail.geo-discussion-forums@vbgx21>,
abrsvc <dansabrservices@yahoo.com> writes:

> 
> As with previous ports, there are many things involved.  Simply porting the=
>  compilers won't be enough.  The Macro compiler and the bliss compiler use =
> the GEM backend code generator.  That too would need to be developed.  Also=
> , tehre are "hardware assists" that are used to implement some of the VMS "=
> isms" that exist.  For example, I don't think that the x86 has the concept =
> of 4 operating priv modes.

Another aspect could be, that for a software product as complex as VMS,
one could imagine that over the decades, 
the owners have accumulated a gazillion of
(regression) test cases to ensure proper functioning even for rare situations.
Unless these are released too, a lot of wheels would have to be reinvented.
0
Reply M.Kraemer (2048) 3/20/2012 4:58:54 PM

abrsvc wrote:
> On Tuesday, March 20, 2012 11:20:31 AM UTC-4, David Froble wrote:
>> Howard S Shubs wrote:
>>> In article <4f67e979$0$4672$c3e8da3$3a1a2348@news.astraweb.com>,
>>>  JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
>>>
>>>> I fear it may be too late to save VMS.
>>> We can always hope they'll release the source code for some earlier 
>>> version, such as 7.3.  Then we can have some fun.
>>>
>> There already exists a Macro32 compiler, used on both Alpha and itanic.  Don't know what 
>> language it's written in, but with recent trends, probably (hock, spit) C.
>>
>> Same argument for Bliss.
>>
>> Just being able to compile the code probably isn't the only requirements.  There is most 
>> likely some things that depend upon the underlying hardware.  That's a conservative 
>> assumption to make.
>>
>> Not going to try to guess what all the problems might be, but, I've got to think that it's 
>> not just a complete re-write.
> 
> As with previous ports, there are many things involved.  Simply porting the compilers won't be enough.  The Macro compiler and the bliss compiler use the GEM backend code generator.  That too would need to be developed.  Also, tehre are "hardware assists" that are used to implement some of the VMS "isms" that exist.  For example, I don't think that the x86 has the concept of 4 operating priv modes.
> 
> Dan

Forget about modes and such, that's just details that could be addressed.

All I was trying to say is that there is much that would require little or no re-working. 
  As with NT, there was the code dealing with the OS, and there was what I think they 
called the "hardware layer".

But VMS isn't just the OS.  There are all the tools, languages, and such that make up the 
total package.  If you cannot get all of it, then why bother?  Frankly, I'm more than a 
bit tired of being told to "program in C and forget the other languages".  If that's all I 
wanted to do, I can do it on Unix and windoz.  Some things I can do on Windoz much easier.

As pointed out, there is the back side of the GEM compilers.  Sure, the front end stuff 
should work, syntax checking and parsing and such, but you then have to produce code that 
would run on the target hardware.

It would not be an easy job, or better to say it would not be a cheap job.  If HP cannot 
justify doing it, then I doubt anyone else could justify the cost.

In terms of cost, I cannot know what it would take.  I have some ideas, but, there are 
other issues.  If HP would have retained the team that did the IA64 port, then perhaps 
they could have done the job at a reasonable cost.  But they didn't.  And now it's 
possible that the critical knowledge no longer exists at HP.  That might be the real problem.
0
Reply davef3 (3717) 3/20/2012 7:13:44 PM

In article <543564.889.1332262058086.JavaMail.geo-discussion-forums@vbgx21>, abrsvc <dansabrservices@yahoo.com> writes:
> 
> As with previous ports, there are many things involved.  Simply porting the=
>  compilers won't be enough.  The Macro compiler and the bliss compiler use =
> the GEM backend code generator.  That too would need to be developed.  Also=
> , tehre are "hardware assists" that are used to implement some of the VMS "=
> isms" that exist.  For example, I don't think that the x86 has the concept =
> of 4 operating priv modes.

   Jees, how many times have we been over this.  80386 and later all
   have the 4 modes needed by VMS.  There are no "hardware assists"
   added to Itanium just to make VMS work.

0
Reply koehler2 (8314) 3/20/2012 7:29:03 PM

On Mar 20, 12:19 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Steven Schweda wrote:
> >    F L A S H !   SUN RISES IN MORNING
>
> Well, it is morning here already (01:18) and the sun has not risen. :-)
>
> And towards end of june the sun doesn't rise at Inuvik and further
> north. (neither does it set).
>
> So that rule which you thought was unbreakable is in fact breakable.  :-)

   Because you know what I thought, it may be redundant to
point out that an event which does not occur everywhere at
every time can still be less than amazing.
0
Reply sms.antinode (948) 3/20/2012 9:07:58 PM

Translation:

If OpenVMS is not ported to x86-64 then OpenVMS is toast!
If NonStop is not ported to x86-64 then NonStop is toast!
If HP-UX is not ported to x86-64 then HP-UX is toast!
If HP doesn't get back its technical talent to do these ports, HP will
be toast!

p.s. Here is a laugh from Wikipedia: Tandem was then (1998) midway in
porting its NonStop product line from MIPS R12000 microprocessors to
Intel's new Itanium Merced microprocessors. This project was restarted
with Alpha as the new target to align NonStop with Compaq's other
large server lines. But in 2001, Compaq terminated all Alpha
engineering investments in favor of the unproven Itanium
microprocessors. The Alpha version of NonStop died before shipping. So
the NonStop migration project was restarted yet again, targeting
Itanium McKinley.

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

0
Reply n.rieck (2007) 3/21/2012 1:07:59 AM

Neil Rieck wrote:

> If OpenVMS is not ported to x86-64 then OpenVMS is toast!
> If NonStop is not ported to x86-64 then NonStop is toast!
> If HP-UX is not ported to x86-64 then HP-UX is toast!

Correct. But HP has bet that it can survive by offering migration to
Linux or Windows on its own servers.

With HP now building 8086 based Superdomes which should be shipping
soon, HP should stay to unveil its true colours within the next 12
months. The Oracle documents said that customers would find out about he
EOL of Itanium in 2012 so that the 5 year period would correspond to the
end of support by Intel.


My gut tells me that the decision to gut VMS engineering came when HP
decided to abandon porting efforts. It is a shame because VMS could
probably be ported to X86 much cheaper and faster than HP-UX (endianness
issues for HP-UX).

It isn't clear what value HP-UX on x86 would bring that Linux couldn't
bring.

But VMS and NSK would still bring distinctive features not available on
Linux.


The big question is really NSK. It would not surprise me if this were
the only OS to survive the death of IA64. Those are high value and high
profile servers that, in many cases, control lives.


Another possibility is that HP will have its own distribution of linux
with proprietary HP add-ons. This would compete against the other Linux
distributiosn such as Red Hat etc
0
Reply jfmezei.spamnot (9469) 3/21/2012 6:13:11 AM

On Mar 21, 2:13=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > If OpenVMS is not ported to x86-64 then OpenVMS is toast!
> > If NonStop is not ported to x86-64 then NonStop is toast!
> > If HP-UX is not ported to x86-64 then HP-UX is toast!
>
> Correct. But HP has bet that it can survive by offering migration to
> Linux or Windows on its own servers.
>
> With HP now building 8086 based Superdomes which should be shipping
> soon, HP should stay to unveil its true colours within the next 12
> months. The Oracle documents said that customers would find out about he
> EOL of Itanium in 2012 so that the 5 year period would correspond to the
> end of support by Intel.
>
> My gut tells me that the decision to gut VMS engineering came when HP
> decided to abandon porting efforts. It is a shame because VMS could
> probably be ported to X86 much cheaper and faster than HP-UX (endianness
> issues for HP-UX).
>
> It isn't clear what value HP-UX on x86 would bring that Linux couldn't
> bring.
>
> But VMS and NSK would still bring distinctive features not available on
> Linux.
>
> The big question is really NSK. It would not surprise me if this were
> the only OS to survive the death of IA64. Those are high value and high
> profile servers that, in many cases, control lives.
>
> Another possibility is that HP will have its own distribution of linux
> with proprietary HP add-ons. This would compete against the other Linux
> distributiosn such as Red Hat etc

This comment is a little off topic, but may be worth mentioning. I
recently stumbled across "Compaq's source code for OpenSSL 1.1A" which
appears to have been written in 2003. While this product version was
targeted at Alpha and VAX, the scripts contain bread-crumbs showing
that OpenVMS engineering was playing with an Itanium cross compiler.
No surprise here, they always had a plethora of tools.

Why should anyone care? These people were much better at doing
software than anything else. If someone decided that OpenVMS should be
ported to x86-64 then it would be easy to begin. If HP was smart then
they've been doing this for a while.

###

Oracle has products running on every endian platform so I'm going to
assume "endian"  is no longer the technical obstacle it once was.

According to wikipedia:
http://en.wikipedia.org/wiki/Endianness

These platforms are little endian:
OpenVMS on VAX, Alpha and Itanium
Solaris on x86, x86-64, PowerPC
Tru64 UNIX on Alpha
Windows on x86, x86-64, Alpha, PowerPC, MIPS and Itanium

....so it should be easier to port OpenVMS than HP (which is big endian
on the bi-endian Itanium)

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

0
Reply n.rieck (2007) 3/21/2012 11:14:22 AM

On 2012-03-20 09.47, abrsvc wrote:
> On Tuesday, March 20, 2012 11:20:31 AM UTC-4, David Froble wrote:
>> Howard S Shubs wrote:
>>> In article<4f67e979$0$4672$c3e8da3$3a1a2348@news.astraweb.com>,
>>>   JF Mezei<jfmezei.spamnot@vaxination.ca>  wrote:
>>>
>>>> I fear it may be too late to save VMS.
>>>
>>> We can always hope they'll release the source code for some earlier
>>> version, such as 7.3.  Then we can have some fun.
>>>
>>
>> There already exists a Macro32 compiler, used on both Alpha and itanic.  Don't know what
>> language it's written in, but with recent trends, probably (hock, spit) C.
>>
>> Same argument for Bliss.
>>
>> Just being able to compile the code probably isn't the only requirements.  There is most
>> likely some things that depend upon the underlying hardware.  That's a conservative
>> assumption to make.
>>
>> Not going to try to guess what all the problems might be, but, I've got to think that it's
>> not just a complete re-write.
>
> As with previous ports, there are many things involved.  Simply porting the compilers won't be enough.  The Macro compiler and the bliss compiler use the GEM backend code generator.  That too would need to be developed.  Also, tehre are "hardware assists" that are used to implement some of the VMS "isms" that exist.  For example, I don't think that the x86 has the concept of 4 operating priv modes.

Neither do the Itanic...
But yes, porting to a new architecture is more work than just making 
compilers run.

	Johnny
0
Reply bqt2 (1410) 3/21/2012 12:58:20 PM

On 2012-03-20 12.29, Bob Koehler wrote:
> In article<543564.889.1332262058086.JavaMail.geo-discussion-forums@vbgx21>, abrsvc<dansabrservices@yahoo.com>  writes:
>>
>> As with previous ports, there are many things involved.  Simply porting the=
>>   compilers won't be enough.  The Macro compiler and the bliss compiler use =
>> the GEM backend code generator.  That too would need to be developed.  Also=
>> , tehre are "hardware assists" that are used to implement some of the VMS "=
>> isms" that exist.  For example, I don't think that the x86 has the concept =
>> of 4 operating priv modes.
>
>     Jees, how many times have we been over this.  80386 and later all
>     have the 4 modes needed by VMS.  There are no "hardware assists"
>     added to Itanium just to make VMS work.

No, they don't. But VMS don't actually need four hardware modes in order 
to work, which is what Itanium proves.

	Johnny
0
Reply bqt2 (1410) 3/21/2012 1:00:07 PM


"David Froble"  wrote in message news:jka781$jpo$1@dont-email.me...


>There already exists a Macro32 compiler, used on both Alpha and itanic. 
>Don't know what language it's written in, but with recent trends, probably 
>(hock, spit) C.

>Same argument for Bliss.

The Macro compiler is written in Macro-32 (uses the same pass1 parser as the 
VAX Macro-32 assembler), C, and BLISS.

The BLISS frontend is BLISS.

GEM is a mixture of BLISS, C, and C++.  (I'd say 60/40 in favor of BLISS)


0
Reply johnrreagan (372) 3/21/2012 2:44:56 PM

In article <2cda01d4-8363-4198-9472-679ca69aa91c@cj6g2000vbb.googlegroups.com>, Neil Rieck <n.rieck@sympatico.ca> writes:

> If HP doesn't get back its technical talent to do these ports, HP will
> be toast!

   HP has enough technical talent to procude ink and paper for a long,
   long, time, without worrying about toast.

0
Reply koehler2 (8314) 3/21/2012 7:12:43 PM

In article <jkcjcn$p3r$3@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
> 
> No, they don't.

   Intel, not to mention every other reference I've seen, says they do:

http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=cpu+architecture+mode+ring

   Intel. 64 and IA-32 Architectures
   Software Developer.s Manual
   Volume 3A:
   System Programming Guide, Part 1

   "The processor.s segment-protection mechanism recognizes 4 privilege
    levels, numbered from 0 to 3."
  
0
Reply koehler2 (8314) 3/21/2012 7:32:10 PM

On Mar 21, 7:32=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <jkcjcn$p3...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@so=
ftjar.se> writes:
>
> > No, they don't.
>
> =A0 =A0Intel, not to mention every other reference I've seen, says they d=
o:
>
> http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=3Dcpu+arc..=
..
>
> =A0 =A0Intel. 64 and IA-32 Architectures
> =A0 =A0Software Developer.s Manual
> =A0 =A0Volume 3A:
> =A0 =A0System Programming Guide, Part 1
>
> =A0 =A0"The processor.s segment-protection mechanism recognizes 4 privile=
ge
> =A0 =A0 levels, numbered from 0 to 3."

There's a discussion for anyone interested to have about how well the
AMD64 and IA64 protection mechanisms map onto the VMS-required
mechanisms, and how exploit-proof they might be in reality. My
recollection is that Alpha only had two protection levels in the
hardware, the rest was implemented in PALcode, but the Alpha
architecture and design and the VMS implementation appeared reasonably
leakproof, subject to the occasional near-inevitable software bug.

x86 wasn't really architected, just thrown together over a number of
years. AMD64 and IA64 attempted to address that but who knows how
successful they were technically?

The increasing use of HYPErvisors on AMD64 and elsewhere may make IT
people increasingly conscious of things like unauthorised privilege
escalation and information leakage. Or may not.
0
Reply johnwallace44 (907) 3/21/2012 7:53:28 PM

In article <_pednVfbMoD3dPTSnZ2dnUVZ_qadnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
>
>"David Froble"  wrote in message news:jka781$jpo$1@dont-email.me...
>
>
>>There already exists a Macro32 compiler, used on both Alpha and itanic. 
>>Don't know what language it's written in, but with recent trends, probably 
>>(hock, spit) C.
>
>>Same argument for Bliss.
>
>The Macro compiler is written in Macro-32 (uses the same pass1 parser as the 
>VAX Macro-32 assembler), C, and BLISS.
>
>The BLISS frontend is BLISS.
>
>GEM is a mixture of BLISS, C, and C++.  (I'd say 60/40 in favor of BLISS)

I wonder if INSQxIs will work on x86! :D ;)
 
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/21/2012 8:00:55 PM


> I wonder if INSQxIs will work on x86! :D ;)

I'll have to ask Hoff. :)


0
Reply johnrreagan (372) 3/21/2012 8:11:49 PM

On 3/19/2012 10:20 PM, JF Mezei wrote:
> Was thinking about the Oracle allegations against HP.
>
> HP did have plans to port HP-UX to x86 and started the work.
> And I have been told that porting of VMS to x86 had also been started.
>
> Neither of which would have been official projects since they couldn't
> appear in any books since HP wanted very much to hide the fact that
> IA64'S EOL was aready planned.
>
>
> At some point, HP decided to not port to x86.
>
> Then, VMS experienced engineering team is fired and replaced by newbie
> programmers given 2 weeks of training.
>
> Looks to me that once HP decided to end of line its proprietary OS at
> same time as IA64, there was no point in keeping the experienced
> engineering teams since they wouldn't be needed for the port.
>
> I fear it may be too late to save VMS.

VMS has been dead, in some sense, for about thirteen years now!

I still have a couple of systems running VMS and I'll hang on to them.
I don't know that I'll DO anything with them, there seems to be very
little demand!

Face it.  If VMS is not dead, it's on "life support".

0
Reply rgilbert88 (4439) 3/21/2012 9:23:06 PM

In article <GfGdnWMIE92bq_fSnZ2dnUVZ_jadnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
>
>> I wonder if INSQxIs will work on x86! :D ;)
>
>I'll have to ask Hoff. :)

Now it's beginning to all make sense. 

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/21/2012 10:49:21 PM

On Wednesday, March 21, 2012 6:49:21 PM UTC-4, (unknown) wrote:
> In article <GfGdnWMIE92bq_fSnZ2dnUVZ_jadnZ2d@earthlink.com>, "John Reagan=
" <johnrreagan@earthlink.net> writes:
> >
> >
> >> I wonder if INSQxIs will work on x86! :D ;)
> >
> >I'll have to ask Hoff. :)
>=20
> Now it's beginning to all make sense.=20
>=20
> --=20
> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)=
ORG
>=20
> Well I speak to machines with the voice of humanity.

VAXman,

I have not worked out the precise sequences, but IMHO the x86 certainly has=
 the ISP (Instruction Set Processor) functionality to implement the INSQxIs=
 instructions.=20

The original VAX implementation in microcode represented a reasonable decis=
ion reflecting the state of semiconductor technology ala 1977. The tradeoff=
s are different now, in favor of software implementations. The proof of thi=
s in any Computer Science text on architecture. All that is REQUIRED for mu=
ltiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primitive=
.. Everything else can be constructed using that as a base.

- Bob Gezelter, http://www.rlgsc.com
0
Reply gezelter (551) 3/22/2012 3:24:57 PM

On 2012-03-21 20.32, Bob Koehler wrote:
> In article<jkcjcn$p3r$3@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>>
>> No, they don't.
>
>     Intel, not to mention every other reference I've seen, says they do:
>
> http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=cpu+architecture+mode+ring
>
>     Intel. 64 and IA-32 Architectures
>     Software Developer.s Manual
>     Volume 3A:
>     System Programming Guide, Part 1
>
>     "The processor.s segment-protection mechanism recognizes 4 privilege
>      levels, numbered from 0 to 3."

My bad. Anyway, you do not need four hardware levels in order p[ 
implement VMS. Two is what really is needed. The rest can be solved in 
software, although having hardware makes it easier/more efficient.

	Johnny
0
Reply bqt2 (1410) 3/22/2012 4:54:16 PM

On Mar 22, 3:24=A0pm, Bob Gezelter <gezel...@rlgsc.com> wrote:
> On Wednesday, March 21, 2012 6:49:21 PM UTC-4, (unknown) wrote:
> > In article <GfGdnWMIE92bq_fSnZ2dnUVZ_jadn...@earthlink.com>, "John Reag=
an" <johnrrea...@earthlink.net> writes:
>
> > >> I wonder if INSQxIs will work on x86! :D ;)
>
> > >I'll have to ask Hoff. :)
>
> > Now it's beginning to all make sense.
>
> > --
> > VAXman- A Bored Certified VMS Kernel Mode Hacker =A0 =A0VAXman(at)TMESI=
S(dot)ORG
>
> > Well I speak to machines with the voice of humanity.
>
> VAXman,
>
> I have not worked out the precise sequences, but IMHO the x86 certainly h=
as the ISP (Instruction Set Processor) functionality to implement the INSQx=
Is instructions.
>
> The original VAX implementation in microcode represented a reasonable dec=
ision reflecting the state of semiconductor technology ala 1977. The tradeo=
ffs are different now, in favor of software implementations. The proof of t=
his in any Computer Science text on architecture. All that is REQUIRED for =
multiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primiti=
ve. Everything else can be constructed using that as a base.
>
> - Bob Gezelter,http://www.rlgsc.com


Bob,

I suspect you know better than that (you even said "in effect") but
here's a footnote or two for anyone who's interested.

1) It's not just for multiprocessor synch even though MP synch is the
classically quoted example. Unless I'm mistaken, it's also for
protecting any multi stage operation which is at risk of delivering
undesirable results if interrupted - for example, accessing a multi-
word datum in mainline code while some other bit of code in an ISR (or
in an AST, or in a different thread, or ...) might want to read (or
write) it and might get to run.

2) RISC processors tend not to use Test and Set because they tend to
have load/operate/store designs where only the loads and stores can
access memory and most opcodes only do registers. So on Alpha (and
iirc on ARM) and various others the same result is achieved using load-
locked/store-conditional instruction groups (or some equivalent with a
different name). It's written up in lots of places, for Alpha
including the VMS Programming Concepts manual or the freely
downloadable Alpha Architecture Handbook.

Every mainstream processor I know has this kind of capability one way
or another but I'm also aware of one obscure one that doesn't. On that
one you have to be careful about when non-atomic data can be accessed.
Great fun.

There is also a case to be made that these things can be done without
any underlying semaphore capability (semaphore is what T+S etc
provides) but it seems a fairly pointless argument in general.


0
Reply johnwallace44 (907) 3/22/2012 6:15:11 PM

In article <5819721.328.1332429897519.JavaMail.geo-discussion-forums@vbbfw10>, Bob Gezelter <gezelter@rlgsc.com> writes:
>On Wednesday, March 21, 2012 6:49:21 PM UTC-4, (unknown) wrote:
>> In article <GfGdnWMIE92bq_fSnZ2dnUVZ_jadnZ2d@earthlink.com>, "John Reagan=
>" <johnrreagan@earthlink.net> writes:
>> >
>> >
>> >> I wonder if INSQxIs will work on x86! :D ;)
>> >
>> >I'll have to ask Hoff. :)
>>=20
>> Now it's beginning to all make sense.=20
>>=20
>> --=20
>> VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)=
>ORG
>>=20
>> Well I speak to machines with the voice of humanity.
>
>VAXman,
>
>I have not worked out the precise sequences, but IMHO the x86 certainly has=
> the ISP (Instruction Set Processor) functionality to implement the INSQxIs=
> instructions.=20
>
>The original VAX implementation in microcode represented a reasonable decis=
>ion reflecting the state of semiconductor technology ala 1977. The tradeoff=
>s are different now, in favor of software implementations. The proof of thi=
>s in any Computer Science text on architecture. All that is REQUIRED for mu=
>ltiprocessor synch is in effect a Test-and-Set (or Fetch-and-Add) primitive=
>.. Everything else can be constructed using that as a base.

Correct Bob, now if only it gets implemented properly unlike the INS/REM-QxIs
on another platform.  :rolleyes:  

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/22/2012 7:15:54 PM

John Wallace <johnwallace4@yahoo.co.uk> wrote:

(snip)
> I suspect you know better than that (you even said "in effect") but
> here's a footnote or two for anyone who's interested.

> 1) It's not just for multiprocessor synch even though MP synch is the
> classically quoted example. Unless I'm mistaken, it's also for
> protecting any multi stage operation which is at risk of delivering
> undesirable results if interrupted - for example, accessing a multi-
> word datum in mainline code while some other bit of code in an ISR (or
> in an AST, or in a different thread, or ...) might want to read (or
> write) it and might get to run.

(snip on RISC processors and store conditional)

> Every mainstream processor I know has this kind of capability one way
> or another but I'm also aware of one obscure one that doesn't. On that
> one you have to be careful about when non-atomic data can be accessed.
> Great fun.

In the core memory days, where core has a destructive read and so
requires a write back, there were some processors that would do a
read-modify-write by delaying the write back to core. (That assumes
that there are read-modify-write instructions.) 

DRAM also requires a write back, and I beleive that some early DRAM
users at least thought about delaying the write back. 

> There is also a case to be made that these things can be done without
> any underlying semaphore capability (semaphore is what T+S etc
> provides) but it seems a fairly pointless argument in general.

IBM S/360 has TS (test and set), where S/370 added CS and CDS 
(compare and swap, compare double and swap). There is some discussion
about the need to add new instructions without multiprocessing, but
that when they were shown to be needed even with a single processor
(in the case of interrupts), then they were allowed to be added.

-- glen

0
Reply gah (12850) 3/22/2012 8:24:12 PM


"Bob Koehler"  wrote in message 
news:ryFmpNcXtFN$@eisner.encompasserve.org...



>  How many instructions in lib$insqXi on IA64?

The code checks for operand alignment, raises to IPL 14, disables 
interrupts, uses the 'tak' instruction (an esoteric Itanium instruction to 
look in translation buffers and page tables), locks the header, probes the 
header, probes the predecessor, restores interrupts, lowers IPL, checks for 
pending ASTs, etc.

I counted 60 bundles in the best case but there are retry paths if the 'tak' 
fails, etc.



0
Reply johnrreagan (372) 3/22/2012 10:37:58 PM

In article <00ABEAFB.E1910C80@SendSpamHere.ORG>,   VAXman-  @SendSpamHere.ORG writes:
> 
> I wonder if INSQxIs will work on x86! :D ;)
>  

   How many instructions in lib$insqXi on IA64?

0
Reply koehler2 (8314) 3/22/2012 10:44:46 PM

In article <c0ce4a20-dd64-4c50-92b2-c0cf480ce336@q11g2000vbu.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
> 
> There's a discussion for anyone interested to have about how well the
> AMD64 and IA64 protection mechanisms map onto the VMS-required
> mechanisms, and how exploit-proof they might be in reality. My
> recollection is that Alpha only had two protection levels in the
> hardware, the rest was implemented in PALcode, but the Alpha
> architecture and design and the VMS implementation appeared reasonably
> leakproof, subject to the occasional near-inevitable software bug.

   Yes, there are some "OS defined" bits in Alpha where you might
   expect support for twice as many modes.

   Alpha modes aren't a perfect map to VAX, and neither are IA64,
   but they are good enough and IA32 looks like it would be, too.

0
Reply koehler2 (8314) 3/22/2012 10:46:50 PM

In article <L5udnSn0D5xUNPbSnZ2dnUVZ_qidnZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>
>
>"Bob Koehler"  wrote in message 
>news:ryFmpNcXtFN$@eisner.encompasserve.org...
>
>
>
>>  How many instructions in lib$insqXi on IA64?
>
>The code checks for operand alignment, raises to IPL 14, disables 
>interrupts, uses the 'tak' instruction (an esoteric Itanium instruction to 
>look in translation buffers and page tables), locks the header, probes the 
>header, probes the predecessor, restores interrupts, lowers IPL, checks for 
>pending ASTs, etc.
>
>I counted 60 bundles in the best case but there are retry paths if the 'tak' 
>fails, etc.

That's the count in LIB$INSQxI?  Or, the {SYS/EXE}$PAL_INSQxI?  I suppose I
could just count them for myself.

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/23/2012 12:00:49 PM

On Mar 21, 3:32=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <jkcjcn$p3...@Iltempo.Update.UU.SE>, Johnny Billquist <b...@so=
ftjar.se> writes:
>
> > No, they don't.
>
> =A0 =A0Intel, not to mention every other reference I've seen, says they d=
o:
>
> http://www.intel.com/Assets/en_US/PDF/manual/253668.pdf?wapkw=3Dcpu+arc..=
..
>
> =A0 =A0Intel. 64 and IA-32 Architectures
> =A0 =A0Software Developer.s Manual
> =A0 =A0Volume 3A:
> =A0 =A0System Programming Guide, Part 1
>
> =A0 =A0"The processor.s segment-protection mechanism recognizes 4 privile=
ge
> =A0 =A0 levels, numbered from 0 to 3."

Yep, for segemented 32 bit mode x86 has 4 levels.  They don't map
directly to the vax levels, but there are 4 of them.  In any case, in
x86-64 there are two levels because it doesn't use segmentation --
just page-level protection.
0
Reply bdwheele (53) 3/23/2012 2:29:14 PM


wrote in message news:00ABEC4B.2438820D@SendSpamHere.ORG...

>That's the count in LIB$INSQxI?  Or, the {SYS/EXE}$PAL_INSQxI?  I suppose I
>could just count them for myself.

I counted SYS$PAL_INSQTI.  LIB$INSQTI is a small C routine that contains an 
'__PAL_INSQTIL' built-in call in a while loop until it succeeds, then 
returns a return value based on the return code from the PAL built-in.  The 
compiler turns that into a call to SYS$PAL_INSQTIL.  So LIB$INSQTI would 
involve an 'alloc', 'br.call', a handful of compares, 'br.ret' and not much 
more.  Another 10 bundles maybe.  Any real overhead is in the SYS$ routine 
to provide correct synchronization.


0
Reply johnrreagan (372) 3/23/2012 2:57:10 PM

On Wednesday, March 21, 2012 5:23:06 PM UTC-4, Richard B. Gilbert wrote:
> On 3/19/2012 10:20 PM, JF Mezei wrote:
> > Was thinking about the Oracle allegations against HP.
> >
> > HP did have plans to port HP-UX to x86 and started the work.
> > And I have been told that porting of VMS to x86 had also been started.
> >
> > Neither of which would have been official projects since they couldn't
> > appear in any books since HP wanted very much to hide the fact that
> > IA64'S EOL was aready planned.
> >
> >
> > At some point, HP decided to not port to x86.
> >
> > Then, VMS experienced engineering team is fired and replaced by newbie
> > programmers given 2 weeks of training.
> >
> > Looks to me that once HP decided to end of line its proprietary OS at
> > same time as IA64, there was no point in keeping the experienced
> > engineering teams since they wouldn't be needed for the port.
> >
> > I fear it may be too late to save VMS.
>=20
> VMS has been dead, in some sense, for about thirteen years now!
>=20
> I still have a couple of systems running VMS and I'll hang on to them.
> I don't know that I'll DO anything with them, there seems to be very
> little demand!
>=20
> Face it.  If VMS is not dead, it's on "life support".


Sadly, I am not sure I would be that generous... Even though it still runs =
my home web server and offsite backups for a long-time customer who uses it=
 daily - I am not sure what I will do when their DS10 dies as it has been r=
unning 24x7 since 1999 when it replaced a MVII that ran for equally as long=
.. The custom app was "migrated" via VEST because the developer did not appe=
ar to keep the entire app source code on the customer system and subsequent=
ly was hit by a bus and there was no good backup before the old system died=
 - except for the executables and some of the source code.
0
Reply onedbguru (194) 3/24/2012 12:36:09 AM

I was just thinking.

If HP were to produce fault tolerant 8086s for NSK, those boxes could
also become quite usable as routers in enterprise (since there is now
some serious open sourced routing software) and HP could then provide
compelling products.

Sure, it would cannabalise some of the sales of its 3com unit, but it
could do serious harm to folks like cisco.
0
Reply jfmezei.spamnot (9469) 3/24/2012 5:24:29 AM

onedbguru <onedbguru@yahoo.com> wrote:
> Richard B. Gilbert wrote:
>> >
>> > At some point, HP decided to not port to x86.
>> >
>> > Then, VMS experienced engineering team is fired and replaced by newbie
>> > programmers given 2 weeks of training.
>> >
>> > Looks to me that once HP decided to end of line its proprietary OS at
>> > same time as IA64, there was no point in keeping the experienced
>> > engineering teams since they wouldn't be needed for the port.
>> >
>> > I fear it may be too late to save VMS.
>> 
>> VMS has been dead, in some sense, for about thirteen years now!
>> 
>> I still have a couple of systems running VMS and I'll hang on to them.
>> I don't know that I'll DO anything with them, there seems to be very
>> little demand!
>> 
>> Face it.  If VMS is not dead, it's on "life support".
> 
> Sadly, I am not sure I would be that generous... Even though
> it still runs my home web server and offsite backups for a
> long-time customer who uses it daily - I am not sure what
> I will do when their DS10 dies as it has been running 24x7
> since 1999 when it replaced a MVII that ran for equally as long.
> The custom app was "migrated" via VEST because the developer
> did not appear to keep the entire app source code on the
> customer system and subsequently was hit by a bus
> and there was no good backup before the old system died -
> except for the executables and some of the source code.

Literally hit by a bus??? If ever there was a metaphor...
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )
0
Reply john42 (342) 3/24/2012 6:24:47 AM

On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:

> onedbguru <onedbguru@yahoo.com> wrote:
>> Richard B. Gilbert wrote:
>>> >
>>> > At some point, HP decided to not port to x86.
>>> >
>>> > Then, VMS experienced engineering team is fired and replaced by
>>> > newbie programmers given 2 weeks of training.
>>> >
>>> > Looks to me that once HP decided to end of line its proprietary OS
>>> > at same time as IA64, there was no point in keeping the experienced
>>> > engineering teams since they wouldn't be needed for the port.
>>> >
>>> > I fear it may be too late to save VMS.
>>> 
>>> VMS has been dead, in some sense, for about thirteen years now!
>>> 
>>> I still have a couple of systems running VMS and I'll hang on to them.
>>> I don't know that I'll DO anything with them, there seems to be very
>>> little demand!
>>> 
>>> Face it.  If VMS is not dead, it's on "life support".
>> 
>> Sadly, I am not sure I would be that generous... Even though it still
>> runs my home web server and offsite backups for a long-time customer
>> who uses it daily - I am not sure what I will do when their DS10 dies
>> as it has been running 24x7 since 1999 when it replaced a MVII that ran
>> for equally as long. The custom app was "migrated" via VEST because the
>> developer did not appear to keep the entire app source code on the
>> customer system and subsequently was hit by a bus and there was no good
>> backup before the old system died - except for the executables and some
>> of the source code.
> 
> Literally hit by a bus??? If ever there was a metaphor...

Hit by a Q-bus, I assume. :-)

-- 
Paul Sture
0
Reply paul303 (1382) 3/24/2012 11:28:28 AM


"JF Mezei"  wrote in message 
news:4f6d5a90$0$2201$c3e8da3$460562f1@news.astraweb.com...

>I was just thinking.

>If HP were to produce fault tolerant 8086s for NSK, those boxes could

Any more fault tolerant than the Itaniums used by NSK today?


0
Reply johnrreagan (372) 3/24/2012 12:45:01 PM

In article <snn049-87o.ln1@news.sture.ch>, Paul Sture <paul@sture.ch> writes:
>On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>
>> onedbguru <onedbguru@yahoo.com> wrote:
>>> Richard B. Gilbert wrote:
>>>> >
>>>> > At some point, HP decided to not port to x86.
>>>> >
>>>> > Then, VMS experienced engineering team is fired and replaced by
>>>> > newbie programmers given 2 weeks of training.
>>>> >
>>>> > Looks to me that once HP decided to end of line its proprietary OS
>>>> > at same time as IA64, there was no point in keeping the experienced
>>>> > engineering teams since they wouldn't be needed for the port.
>>>> >
>>>> > I fear it may be too late to save VMS.
>>>> 
>>>> VMS has been dead, in some sense, for about thirteen years now!
>>>> 
>>>> I still have a couple of systems running VMS and I'll hang on to them.
>>>> I don't know that I'll DO anything with them, there seems to be very
>>>> little demand!
>>>> 
>>>> Face it.  If VMS is not dead, it's on "life support".
>>> 
>>> Sadly, I am not sure I would be that generous... Even though it still
>>> runs my home web server and offsite backups for a long-time customer
>>> who uses it daily - I am not sure what I will do when their DS10 dies
>>> as it has been running 24x7 since 1999 when it replaced a MVII that ran
>>> for equally as long. The custom app was "migrated" via VEST because the
>>> developer did not appear to keep the entire app source code on the
>>> customer system and subsequently was hit by a bus and there was no good
>>> backup before the old system died - except for the executables and some
>>> of the source code.
>> 
>> Literally hit by a bus??? If ever there was a metaphor...
>
>Hit by a Q-bus, I assume. :-)

or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)

Back to serious matters...  Try AESTing the VESTed code and then see how it
functions on Itanium.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/24/2012 1:04:39 PM

On Mar 24, 12:45=A0pm, "John Reagan" <johnrrea...@earthlink.net> wrote:
> "JF Mezei" =A0wrote in message
>
> news:4f6d5a90$0$2201$c3e8da3$460562f1@news.astraweb.com...
>
> >I was just thinking.
> >If HP were to produce fault tolerant 8086s for NSK, those boxes could
>
> Any more fault tolerant than the Itaniums used by NSK today?

Exactly.

Tandem hasn't needed CPU lockstep since they dropped their own
proprietary processor architectures, and that's a LONG time ago in
processor history. This isn't a secret, but it may as well be as far
as the trade media and others are concerned.

In modern Tandem boxes, the synchronisation is not at instruction
level or even main-memory access level but conceptually more like "IO
access level" (or maybe process context switch level). The
synchronisation is not on the CPU chip, not even particularly close to
it, but is managed by a piece of complex external logic called the
Logical Synchronization Unit, which doesn't care about instruction-
level lockstep but does care that each processor's operations result
in the same IO with the outside world (and the same context if a
processor swap has to occur). The LSU also does a lot more than that,
which I won't go into here.

The 2006 Oztug presentation at [1] was given by one of Tandem's senior
architects, Hal Massey, and was an excellent intro to the internals of
Tandem boxes over the years. Sadly, it's fallen off the internet and I
haven't kept a copy and nor have I yet been able to find a suitable
replacement. Suggestions welcome for a definitive replacement - but
I'm
not holding my breath.

Don't take my word for it, work it out from first principles. Modern
chips have lots of RAS/availability features which result in many soft
errors being correctable, but errors may have an impact on timing -
sometimes software support is needed at the time or later, or the
error results in visibly different processor behaviour. For example, a
cache error which resulted in a reference to main memory in a chip
which can continue with other processing while it waits for the main
memory reference to arrive. If two chips didn't both have the same
correctable soft error at the same time (what are the odds of that),
they'd not both be executing the same instructions at the same time,
so they'd be out of sync. (Gross oversimplification alert, but
hopefully you get the drift).

hth
john

[1] www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf - now
vanished, sadly.

[yes this text may seem familiar]
0
Reply johnwallace44 (907) 3/24/2012 1:38:17 PM

On 3/24/2012 2:24 AM, JohnF wrote:
> onedbguru<onedbguru@yahoo.com>  wrote:
>> Richard B. Gilbert wrote:
>>>>
>>>> At some point, HP decided to not port to x86.
>>>>
>>>> Then, VMS experienced engineering team is fired and replaced by newbie
>>>> programmers given 2 weeks of training.
>>>>
>>>> Looks to me that once HP decided to end of line its proprietary OS at
>>>> same time as IA64, there was no point in keeping the experienced
>>>> engineering teams since they wouldn't be needed for the port.
>>>>
>>>> I fear it may be too late to save VMS.
>>>
>>> VMS has been dead, in some sense, for about thirteen years now!
>>>
>>> I still have a couple of systems running VMS and I'll hang on to them.
>>> I don't know that I'll DO anything with them, there seems to be very
>>> little demand!
>>>
>>> Face it.  If VMS is not dead, it's on "life support".
>>
>> Sadly, I am not sure I would be that generous... Even though
>> it still runs my home web server and offsite backups for a
>> long-time customer who uses it daily - I am not sure what
>> I will do when their DS10 dies as it has been running 24x7
>> since 1999 when it replaced a MVII that ran for equally as long.
>> The custom app was "migrated" via VEST because the developer
>> did not appear to keep the entire app source code on the
>> customer system and subsequently was hit by a bus
>> and there was no good backup before the old system died -
>> except for the executables and some of the source code.
>
> Literally hit by a bus??? If ever there was a metaphor...

Metaphor or not, it's a good warning.  If you don't have a copy of
the source for critical applications, and the tools needed to build them 
or a viable vendor to support them you may be "hanging by a thread".

It is not wise to allow the lessons of 9/11/2001 to be forgotten.
The sky is full of aircraft and the supply of idiots never seems to run 
short!

Can YOU do the Merrill-Lynch trick?  They were off line for a whole four 
minutes and did not lose a single transaction or a byte of data!
I hate to think what it must have cost but not spending that money would 
have cost far more.

One company lost seventy percent of its staff!  Think "corporate 
lobotomy"!  Could YOUR company survive a loss like that?

0
Reply rgilbert88 (4439) 3/24/2012 3:22:19 PM

On 3/24/2012 7:28 AM, Paul Sture wrote:
> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>
>> onedbguru<onedbguru@yahoo.com>  wrote:
>>> Richard B. Gilbert wrote:
>>>>>
>>>>> At some point, HP decided to not port to x86.
>>>>>
>>>>> Then, VMS experienced engineering team is fired and replaced by
>>>>> newbie programmers given 2 weeks of training.
>>>>>
>>>>> Looks to me that once HP decided to end of line its proprietary OS
>>>>> at same time as IA64, there was no point in keeping the experienced
>>>>> engineering teams since they wouldn't be needed for the port.
>>>>>
>>>>> I fear it may be too late to save VMS.
>>>>
>>>> VMS has been dead, in some sense, for about thirteen years now!
>>>>
>>>> I still have a couple of systems running VMS and I'll hang on to them.
>>>> I don't know that I'll DO anything with them, there seems to be very
>>>> little demand!
>>>>
>>>> Face it.  If VMS is not dead, it's on "life support".
>>>
>>> Sadly, I am not sure I would be that generous... Even though it still
>>> runs my home web server and offsite backups for a long-time customer
>>> who uses it daily - I am not sure what I will do when their DS10 dies
>>> as it has been running 24x7 since 1999 when it replaced a MVII that ran
>>> for equally as long. The custom app was "migrated" via VEST because the
>>> developer did not appear to keep the entire app source code on the
>>> customer system and subsequently was hit by a bus and there was no good
>>> backup before the old system died - except for the executables and some
>>> of the source code.
>>
>> Literally hit by a bus??? If ever there was a metaphor...
>
> Hit by a Q-bus, I assume. :-)
>

Off with his head!


0
Reply rgilbert88 (4439) 3/24/2012 3:25:03 PM

On Mar 21, 2:53=A0pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> The increasing use of HYPErvisors on AMD64 and elsewhere may make IT
> people increasingly conscious of things like unauthorised privilege
> escalation and information leakage. Or may not.

Still, one would want to port to an AMD CPU not a CPU from has been
chip maker Intel.  The AMD quad cores rock and are already 128-bit.

Itanic was simply HP and Intel trying to force VMS users to pay for
their multi-million (multi-billion?) dollar boondoggle.

I still expect 2 things to happen.

1)  HP to make yet another appearance before yet another Congressional
committee.
2)  HP being forced into either the Open Source release or (more
likely) the sale of OpenVMS.  I'm 80% certain the buyer will come from
China if the platform is sold.
0
Reply roland (281) 3/24/2012 3:25:14 PM

Sprag wrote:
>Bob Koehler wrote:
>> Intel. 64 and IA-32 Architectures
>> Software Developer.s Manual
>> Volume 3A:
>> System Programming Guide, Part 1
>>
>> "The processor.s segment-protection mechanism recognizes 4 privilege
>> levels, numbered from 0 to 3."
>
> Yep, for segemented 32 bit mode x86 has 4 levels.  They don't map
> directly to the vax levels, but there are 4 of them.  In any case, in
> x86-64 there are two levels because it doesn't use segmentation --
> just page-level protection.

It's possible to implement more than 2 privilege levels in software
on systems that have only 2 privilege levels using a form of ring
compression and multiple page directories.

Let's say you had an address space with 4 rings.

---  4gb
kernel 
---  3gb 
ring 1
---  2gb 
ring 2 
---  1gb 
ring 3
--- 0gb 

Using 3 page directories you can have them mapped as:

Page Dir 1 - maps kernel (supervisor) + rings 1,2,3 (user) 
Page Dir 2 - maps kernel (supervisor) + rings 2,3  (user) 
Page Dir 3 - maps kernel (supervisor) + ring 3   (user) 

In effect rings 1, 2 and 3 always run in user-mode, compressed
into a single hardware protection ring.

2 system calls in the kernel, call() and return() are used
to call into an return from a more privileged ring, implementing
a call-gate like mechanism and performing permission checks
before switching page directories and returning into the new
ring.

Of course it is more expensive than doing it in hardware,
you have the cost of entering and leaving the kernel each
time a call() and reply() system call is made as well as the
overhead of switching page directories.


-- 
Marv
0
Reply marven10 (15) 3/24/2012 3:49:32 PM

Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> JohnF wrote:
>> onedbguru<onedbguru@yahoo.com>  wrote:
>>> Richard B. Gilbert wrote:
>>>>>
>>>>> At some point, HP decided to not port to x86.
>>>>>
>>>>> Then, VMS experienced engineering team is fired and replaced by newbie
>>>>> programmers given 2 weeks of training.
>>>>>
>>>>> Looks to me that once HP decided to end of line its proprietary OS at
>>>>> same time as IA64, there was no point in keeping the experienced
>>>>> engineering teams since they wouldn't be needed for the port.
>>>>>
>>>>> I fear it may be too late to save VMS.
>>>>
>>>> VMS has been dead, in some sense, for about thirteen years now!
>>>>
>>>> I still have a couple of systems running VMS and I'll hang on to them.
>>>> I don't know that I'll DO anything with them, there seems to be very
>>>> little demand!
>>>>
>>>> Face it.  If VMS is not dead, it's on "life support".
>>>
>>> Sadly, I am not sure I would be that generous... Even though
>>> it still runs my home web server and offsite backups for a
>>> long-time customer who uses it daily - I am not sure what
>>> I will do when their DS10 dies as it has been running 24x7
>>> since 1999 when it replaced a MVII that ran for equally as long.
>>> The custom app was "migrated" via VEST because the developer
>>> did not appear to keep the entire app source code on the
>>> customer system and subsequently was hit by a bus
>>> and there was no good backup before the old system died -
>>> except for the executables and some of the source code.
>>
>> Literally hit by a bus??? If ever there was a metaphor...
> 
> Metaphor or not, it's a good warning.  If you don't have a copy of
> the source for critical applications, and the tools needed to build them 
> or a viable vendor to support them you may be "hanging by a thread".
> 
> It is not wise to allow the lessons of 9/11/2001 to be forgotten.
> The sky is full of aircraft and the supply of idiots never seems to run 
> short!
> 
> Can YOU do the Merrill-Lynch trick?  They were off line for a whole four 
> minutes and did not lose a single transaction or a byte of data!
> I hate to think what it must have cost but not spending that money would 
> have cost far more.
> 
> One company lost seventy percent of its staff!  Think "corporate 
> lobotomy"!  Could YOUR company survive a loss like that?

That was Cantor-Fitzgerald, where I had a contract from 1995-1997,
see http://www.forkosh.com/resume.html?cf1195 for details.
They had vms (on vax) at that time. Managers (and many traders)
were on high floors, where we had meetings every morning on 104.
But us peon computer contractors were generally cubicled on 30-33.
Everyone there (that I knew of) made it out on 9/11. I called a few weeks
later to volunteer some free time if they needed help picking up pieces.
But they had transferred much of the NY work to their London offices.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )
0
Reply john42 (342) 3/24/2012 4:08:56 PM

On Sat, 24 Mar 2012 08:25:14 -0700, seasoned_geek wrote:

> On Mar 21, 2:53 pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>> The increasing use of HYPErvisors on AMD64 and elsewhere may make IT
>> people increasingly conscious of things like unauthorised privilege
>> escalation and information leakage. Or may not.
> 
> Still, one would want to port to an AMD CPU not a CPU from has been chip
> maker Intel.  The AMD quad cores rock and are already 128-bit.
> 
> Itanic was simply HP and Intel trying to force VMS users to pay for
> their multi-million (multi-billion?) dollar boondoggle.
> 
> I still expect 2 things to happen.
> 
> 1)  HP to make yet another appearance before yet another Congressional
> committee.
> 2)  HP being forced into either the Open Source release or (more likely)
> the sale of OpenVMS.  I'm 80% certain the buyer will come from China if
> the platform is sold.


You might want to consider this:

<http://tinyurl.com/3thwyvm>

'In China, business travelers take extreme precautions to avoid cyber-
espionage

....

Though no country was named, "it was really directed at countries like 
China and Russia," Brenner said in a recent interview.

He based his 2008 warning on cases in which Chinese malware was remotely 
inserted into cellphones; the malware then infected computer servers in 
the United States. He said the networks in every major hotel are 
monitored by Chinese security agencies.'


-- 
Paul Sture
0
Reply paul303 (1382) 3/24/2012 6:12:45 PM

John Reagan wrote:

> Any more fault tolerant than the Itaniums used by NSK today?

I was under the impression that HP did build fault tolerant itaniums for
NSK. Is that not the case ?
0
Reply jfmezei.spamnot (9469) 3/24/2012 6:43:43 PM

John Wallace wrote:

> Tandem hasn't needed CPU lockstep since they dropped their own
> proprietary processor architectures,


But building a fault tolerant system is much more than "lockstep". There
are many hardware designs (dual power, dual fans, dual disk controllers
etc etc).


Are you saying that NSK now runs on the same systems/model numbers as
HP-UX and VMS ?
0
Reply jfmezei.spamnot (9469) 3/24/2012 6:46:42 PM


"JF Mezei"  wrote in message 
news:4f6e15e0$0$463$c3e8da3$4db35a27@news.astraweb.com...

>John Reagan wrote:

>> Any more fault tolerant than the Itaniums used by NSK today?

>I was under the impression that HP did build fault tolerant itaniums for
>NSK. Is that not the case ?

Not that I'm aware of.  Same chips, same disks, same memory, etc.  The boxes 
may have some additional RAS features but I think it is more about the 
bundled support that comes with them.  I'm not an expert however.  I do know 
that the Itanium chips are the same. 

0
Reply johnrreagan (372) 3/25/2012 1:25:51 AM

John Reagan wrote:

> bundled support that comes with them.  I'm not an expert however.  I do know 
> that the Itanium chips are the same. 



The chips are but a small part of the "NSK" equation. Back in the days
of Tandem, their boxes had a lot of hardware features for not only
redundnacy, but also hot swappability of components whihout having to
stop the whole system.

disk drives were dual pathed for instance, and there were 2 controllers
for the disks.

The interconnects between systems were also quite different to allow for
memory exchanges and internode transactions etc.


Looking at the HP site, it appears HP still has NSK specific servers,
but the web pages are devoid of any real details on how they differ from
the "standard" IA64 servers for HP-UX and VMS.



http://h20223.www2.hp.com/NonStopComputing/cache/307953-0-0-0-121.html

Consider how different the VAXft was from normal VAXen.


The NSK software and hardware might be sufficiently unique that customer
would demand HP port NSK to x86 and build x86 servers with fault
tolerance features for NSK to run on.

HP even has a video on Nonstop:
http://h20621.www2.hp.com/video-gallery/us/en/adc2060c6ef0fd43d853202cbcc2985efefe93c8/r/video

They even pitch NSK as a solution for healthcare. (no mention of VMS there).


Looks to me like NSK might survive beyond the death of IA64.

0
Reply jfmezei.spamnot (9469) 3/25/2012 3:17:53 AM

On Mar 23, 7:36=A0pm, onedbguru <onedbg...@yahoo.com> wrote:
>
> Sadly, I am not sure I would be that generous... Even though it still run=
s my home web server and offsite backups for a long-time customer who uses =
it daily - I am not sure what I will do when their DS10 dies as it has been=
 running 24x7 since 1999 when it replaced a MVII that ran for equally as lo=
ng. The custom app was "migrated" via VEST because the developer did not ap=
pear to keep the entire app source code on the customer system and subseque=
ntly was hit by a bus and there was no good backup before the old system di=
ed - except for the executables and some of the source code
>

Have you considered emulation?  You can run a virtual VAX or Alpha (or
both at the same time, if you wish) on just about any relatively
recent x86 (x86-64 for Alpha) system, including consumer desktops or
laptops. Even modest PC hardware configurations can provide better
(often much better) performance  than desktop or deskside VAX or Alpha
systems with much less power consumption and heat generation. VAX/
Alpha virtualization won't be the right fit for everyone, of course,
but in many cases it can provide the best of both worlds - the
benefits of modern hardware while retaining the stability of your
software enviuronment - with a relatively quick and inexpensive
migration path.

Disclosure: I sell these emultor products. I also use them because I
like running VMS and they're much cheaper and easier to maintain than
15+ year old hardware.  And I no longer have the patience to wait for
a real MVII, 3100, or 4100.
0
Reply jerry52 (6) 3/25/2012 4:21:30 AM

jerry@virtual-vax-alpha.com wrote:

> systems with much less power consumption and heat generation. VAX/
> Alpha virtualization won't be the right fit for everyone, of course,


SimH causes one core of an x86 to run at 100% all the time to emulate
the vax.  A Mac Pro computer running at 100% consumes about as much
power as a DS10L.

If SimH could "capture" the idle loop and sleep the process instead,
then power consumption might be down, but not that much.
0
Reply jfmezei.spamnot (9469) 3/25/2012 5:40:11 AM

On Mar 24, 7:46=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> John Wallace wrote:
> > Tandem hasn't needed CPU lockstep since they dropped their own
> > proprietary processor architectures,
>
> But building a fault tolerant system is much more than "lockstep". There
> are many hardware designs (dual power, dual fans, dual disk controllers
> etc etc).
>
> Are you saying that NSK now runs on the same systems/model numbers as
> HP-UX and VMS ?

As John Reagan already said, not on the same HP model numbers as VMS
and HP/UX boxes, but on the same CPU chips. Contrary to some writeups
elsewhere in the past, no "lockstep CPUs" or lockstep memory are
needed - not at instruction level anyway.

The fault tolerance in modern NSK (ie in NonStop Advanced Architecture
systems) is provided largely by "logical synchonisation units" which
compare the results of chunks of calculations before they are written
to the outside world (disk, network, etc); they do not compare the
timing and results of individual instructions (that would not be
sensible in modern hardware).

Obviously that is a massive oversimplification. For more detail, see
what you can find to helpfully read about NonStop Advanced
Architecture and (as mentioned in my earlier post) Logical
Synchronisation Units.

As also mentioned in my earlier post, the Hal Massey (VP of Tandem)
presentation to OzTUG in 2006 which was the best I had found on the
subject, sadly seems to have vanished, I didn't keep a copy, and I
haven't found anything nearly as helpful anywhere else. Suggestions
for substitutes most welcome.
0
Reply johnwallace44 (907) 3/25/2012 8:46:09 AM

On Mar 25, 6:40=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> je...@virtual-vax-alpha.com wrote:
> > systems with much less power consumption and heat generation. VAX/
> > Alpha virtualization won't be the right fit for everyone, of course,
>
> SimH causes one core of an x86 to run at 100% all the time to emulate
> the vax. =A0A Mac Pro computer running at 100% consumes about as much
> power as a DS10L.
>
> If SimH could "capture" the idle loop and sleep the process instead,
> then power consumption might be down, but not that much.


"If SimH could "capture" the idle loop"

JF, have you tried the SIMH "SET CPU IDLE=3DVMS" command (as written up
in various places on the Internet) and found it wanting, or were you
just unaware of it?

In a commercial setup rather than hobbyist setup, a far greater
concern than using one of the multiple cores [often unnecessarily]
provided in many modern Window boxes would likely be the reliability
and availability of the underlying OS in comparison with the
reliability and availability which led to the choice (and retention)
of VMS.
0
Reply johnwallace44 (907) 3/25/2012 8:48:53 AM

In article <00ABED1D.39A4359F@SendSpamHere.ORG>,
 VAXman-  @SendSpamHere.ORG wrote:

> In article <snn049-87o.ln1@news.sture.ch>, Paul Sture <paul@sture.ch> writes:
> >On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
> >
> >> onedbguru <onedbguru@yahoo.com> wrote:
> >>> Richard B. Gilbert wrote:
> >>>> >
> >>>> > At some point, HP decided to not port to x86.
> >>>> >
> >>>> > Then, VMS experienced engineering team is fired and replaced by
> >>>> > newbie programmers given 2 weeks of training.
> >>>> >
> >>>> > Looks to me that once HP decided to end of line its proprietary OS
> >>>> > at same time as IA64, there was no point in keeping the experienced
> >>>> > engineering teams since they wouldn't be needed for the port.
> >>>> >
> >>>> > I fear it may be too late to save VMS.
> >>>> 
> >>>> VMS has been dead, in some sense, for about thirteen years now!
> >>>> 
> >>>> I still have a couple of systems running VMS and I'll hang on to them.
> >>>> I don't know that I'll DO anything with them, there seems to be very
> >>>> little demand!
> >>>> 
> >>>> Face it.  If VMS is not dead, it's on "life support".
> >>> 
> >>> Sadly, I am not sure I would be that generous... Even though it still
> >>> runs my home web server and offsite backups for a long-time customer
> >>> who uses it daily - I am not sure what I will do when their DS10 dies
> >>> as it has been running 24x7 since 1999 when it replaced a MVII that ran
> >>> for equally as long. The custom app was "migrated" via VEST because the
> >>> developer did not appear to keep the entire app source code on the
> >>> customer system and subsequently was hit by a bus and there was no good
> >>> backup before the old system died - except for the executables and some
> >>> of the source code.
> >> 
> >> Literally hit by a bus??? If ever there was a metaphor...
> >
> >Hit by a Q-bus, I assume. :-)
> 
> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)

Don't forget the MASSBUS.  It strikes me (ha!) as being more MASSive.

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
Reply howard578 (2137) 3/26/2012 1:19:50 AM

On 2012-03-26 03.19, Howard S Shubs wrote:
> In article<00ABED1D.39A4359F@SendSpamHere.ORG>,
>   VAXman-  @SendSpamHere.ORG wrote:
>
>> In article<snn049-87o.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>  writes:
>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>>>> Literally hit by a bus??? If ever there was a metaphor...
>>>
>>> Hit by a Q-bus, I assume. :-)
>>
>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)
>
> Don't forget the MASSBUS.  It strikes me (ha!) as being more MASSive.

The cables certainly are... :-)

	Johnny
0
Reply bqt2 (1410) 3/26/2012 11:54:49 AM

On 2012-03-26 15.28, VAXman- @SendSpamHere.ORG wrote:
> In article<jkpldl$m3p$2@Iltempo.Update.UU.SE>, Johnny Billquist<bqt@softjar.se>  writes:
>> On 2012-03-26 03.19, Howard S Shubs wrote:
>>> In article<00ABED1D.39A4359F@SendSpamHere.ORG>,
>>>    VAXman-  @SendSpamHere.ORG wrote:
>>>
>>>> In article<snn049-87o.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>   writes:
>>>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>>>>>> Literally hit by a bus??? If ever there was a metaphor...
>>>>>
>>>>> Hit by a Q-bus, I assume. :-)
>>>>
>>>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)
>>>
>>> Don't forget the MASSBUS.  It strikes me (ha!) as being more MASSive.
>>
>> The cables certainly are... :-)
>
> ROFL.  Those were pipes, not cables!

You could almost think so, except they were flexible, for some 
definition of "flexible". :-)

It was/is hell to pull them into a cabinet and maneuver them in place 
for the connector. A nice feature was that the connector could be set in 
three different angles to the cable. That helped a lot.

	Johnny
0
Reply bqt2 (1410) 3/26/2012 12:44:17 PM

In article <jkpldl$m3p$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2012-03-26 03.19, Howard S Shubs wrote:
>> In article<00ABED1D.39A4359F@SendSpamHere.ORG>,
>>   VAXman-  @SendSpamHere.ORG wrote:
>>
>>> In article<snn049-87o.ln1@news.sture.ch>, Paul Sture<paul@sture.ch>  writes:
>>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
>>>>> Literally hit by a bus??? If ever there was a metaphor...
>>>>
>>>> Hit by a Q-bus, I assume. :-)
>>>
>>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus...  :)
>>
>> Don't forget the MASSBUS.  It strikes me (ha!) as being more MASSive.
>
>The cables certainly are... :-)

ROFL.  Those were pipes, not cables!

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 3/26/2012 1:28:12 PM

On Mar 25, 12:40=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> je...@virtual-vax-alpha.com wrote:
> > systems with much less power consumption and heat generation. VAX/
> > Alpha virtualization won't be the right fit for everyone, of course,
>
> SimH causes one core of an x86 to run at 100% all the time to emulate
> the vax. =A0A Mac Pro computer running at 100% consumes about as much
> power as a DS10L.
>
> If SimH could "capture" the idle loop and sleep the process instead,
> then power consumption might be down, but not that much.

The vtAlpha Eco-App (not to be confused with an ECO-App) does just
this. The Eco-App is presently available for OpenVMS; the web site
indicates a Tru64 version is under development.

0
Reply jerry52 (6) 3/26/2012 3:32:11 PM

On Mar 25, 3:48=A0am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> On Mar 25, 6:40=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>
> > je...@virtual-vax-alpha.com wrote:
> > > systems with much less power consumption and heat generation. VAX/
> > > Alpha virtualization won't be the right fit for everyone, of course,
>
> > SimH causes one core of an x86 to run at 100% all the time to emulate
> > the vax. =A0A Mac Pro computer running at 100% consumes about as much
> > power as a DS10L.
>
> > If SimH could "capture" the idle loop and sleep the process instead,
> > then power consumption might be down, but not that much.
>
> "If SimH could "capture" the idle loop"
>
> JF, have you tried the SIMH "SET CPU IDLE=3DVMS" command (as written up
> in various places on the Internet) and found it wanting, or were you
> just unaware of it?
>
vtAlpha
> In a commercial setup rather than hobbyist setup, a far greater
> concern than using one of the multiple cores [often unnecessarily]
> provided in many modern Window boxes would likely be the reliability
> and availability of the underlying OS in comparison with the
> reliability and availability which led to the choice (and retention)
> of VMS.

0
Reply jerry52 (6) 3/26/2012 3:32:33 PM

On Mar 25, 3:48=A0am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
> In a commercial setup rather than hobbyist setup, a far greater
> concern than using one of the multiple cores [often unnecessarily]
> provided in many modern Window boxes would likely be the reliability
> and availability of the underlying OS in comparison with the
> reliability and availability which led to the choice (and retention)
> of VMS.

If one dedicates a box to the emulation applications, which is the
recommendation of the vendors, many of the Windows services can be
disabled.  This provides a significant improvement in the reliability
of the underlying OS. Since Windows network connectivity is for
management only, in most cases it should be possible to isolate it
from general network traffic, reducing exposure to the network
security vulnerabilities.

Another option is not to run the emulator under Windows.  vtAlpha's
bare metalapproach, which is a bundled Linux kernel, works well
because the underlying OS is shipped stripped down and tested with the
application; there is no issue with OS upgrades applied on-site
introducing incompatabilities.
0
Reply jerry52 (6) 3/26/2012 4:20:03 PM

On Mon, 26 Mar 2012 09:20:03 -0700, Jerry Eckert wrote:

> vtAlpha's bare
> metalapproach, which is a bundled Linux kernel, works well because the
> underlying OS is shipped stripped down and tested with the application;
> there is no issue with OS upgrades applied on-site introducing
> incompatabilities.

1. Can you point us at price lists for the various flavours of vtAlpha?
2. Are evaluation copies available?
3. Will vtAlpha run inside a virtual machine for initial valuation
   purposes?


-- 
Paul Sture
0
Reply paul303 (1382) 3/26/2012 6:05:57 PM

On Mar 26, 1:44=A0pm, Johnny Billquist <b...@softjar.se> wrote:
> On 2012-03-26 15.28, VAXman- @SendSpamHere.ORG wrote:
>
>
>
> > In article<jkpldl$m3...@Iltempo.Update.UU.SE>, Johnny Billquist<b...@so=
ftjar.se> =A0writes:
> >> On 2012-03-26 03.19, Howard S Shubs wrote:
> >>> In article<00ABED1D.39A43...@SendSpamHere.ORG>,
> >>> =A0 =A0VAXman- =A0@SendSpamHere.ORG wrote:
>
> >>>> In article<snn049-87o....@news.sture.ch>, Paul Sture<p...@sture.ch> =
=A0 writes:
> >>>>> On Sat, 24 Mar 2012 06:24:47 +0000, JohnF wrote:
> >>>>>> Literally hit by a bus??? If ever there was a metaphor...
>
> >>>>> Hit by a Q-bus, I assume. :-)
>
> >>>> or a UNIbus... or a BI bus... or an XMI bus... or a PCI bus... =A0:)
>
> >>> Don't forget the MASSBUS. =A0It strikes me (ha!) as being more MASSiv=
e.
>
> >> The cables certainly are... :-)
>
> > ROFL. =A0Those were pipes, not cables!
>
> You could almost think so, except they were flexible, for some
> definition of "flexible". :-)
>
> It was/is hell to pull them into a cabinet and maneuver them in place
> for the connector. A nice feature was that the connector could be set in
> three different angles to the cable. That helped a lot.
>
> =A0 =A0 =A0 =A0 Johnny

I had a trip to a vendor in Leeds once, when my then employers were
looking to replace an 11/70 with an 11/780 (UK readers may know the
vendor I mean). The place we went sold "DEC compatible" kit, where
anything that didn't need to come direct from DEC was replaced with
cheaper alternatives (everything from industrial power supplies to
photocopied manuals to disk controllers and drives). Their idea of an
*external* MASSbus cable was what would now be called a rainbow ribbon
(twisted) cable. You could drive a fork truck over the DEC cables (and
more importantly drop a computer room floor tile on them) and they'd
survive. Not so with the "compatible" ones.
0
Reply johnwallace44 (907) 3/26/2012 6:30:03 PM

On Mar 26, 5:20=A0pm, Jerry Eckert <je...@virtual-vax-alpha.com> wrote:
> On Mar 25, 3:48=A0am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
>
>
> > In a commercial setup rather than hobbyist setup, a far greater
> > concern than using one of the multiple cores [often unnecessarily]
> > provided in many modern Window boxes would likely be the reliability
> > and availability of the underlying OS in comparison with the
> > reliability and availability which led to the choice (and retention)
> > of VMS.
>
> If one dedicates a box to the emulation applications, which is the
> recommendation of the vendors, many of the Windows services can be
> disabled. =A0This provides a significant improvement in the reliability
> of the underlying OS. Since Windows network connectivity is for
> management only, in most cases it should be possible to isolate it
> from general network traffic, reducing exposure to the network
> security vulnerabilities.
>
> Another option is not to run the emulator under Windows. =A0vtAlpha's
> bare metalapproach, which is a bundled Linux kernel, works well
> because the underlying OS is shipped stripped down and tested with the
> application; there is no issue with OS upgrades applied on-site
> introducing incompatabilities.

"vtAlpha's bare metalapproach, which is a bundled Linux kernel"

Oh dear, not that silliness again. Not running Windows may be better
than running Windows, but running a Linux layer underneath the
emulator doesn't make it a "bare metal" emulator.

Why is it so difficult for IT people to be honest these days?

HYPErvisor. With the emphasis on the first four letters.
0
Reply johnwallace44 (907) 3/26/2012 6:32:44 PM

John Wallace wrote:

> Oh dear, not that silliness again. Not running Windows may be better
> than running Windows, but running a Linux layer underneath the
> emulator doesn't make it a "bare metal" emulator.

Not sure how much of linux is included in that vtAlpha "bare bones". But
it is quite possible to really have a bare metal linux and this is
commonly done for embedded systems, TVs, thermostats, TV decoders etc.

In fact, when you look at the iphone, it's got BDS Unix under the hood
but no command line utilities (and no command line). When you jailbreak
it, the first thing it does is add the ability to access a command line
and load all the standrad unix commands.
0
Reply jfmezei.spamnot (9469) 3/26/2012 7:55:30 PM

On 2012-03-26 21:55, JF Mezei wrote:
> John Wallace wrote:
>
>> Oh dear, not that silliness again. Not running Windows may be better
>> than running Windows, but running a Linux layer underneath the
>> emulator doesn't make it a "bare metal" emulator.
>
> Not sure how much of linux is included in that vtAlpha "bare bones". But
> it is quite possible to really have a bare metal linux and this is
> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>
> In fact, when you look at the iphone, it's got BDS Unix under the hood
> but no command line utilities (and no command line). When you jailbreak
> it, the first thing it does is add the ability to access a command line
> and load all the standrad unix commands.

Yes, and that is not properly "bare metal". Having Linux on which your 
emulator runs, means it's running under Linux, not on the bare metal. 
How hard can it be?

	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
Reply bqt2 (1410) 3/26/2012 8:05:35 PM

On 2012-03-26, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> John Wallace wrote:
>
>> Oh dear, not that silliness again. Not running Windows may be better
>> than running Windows, but running a Linux layer underneath the
>> emulator doesn't make it a "bare metal" emulator.
>
> Not sure how much of linux is included in that vtAlpha "bare bones". But
> it is quite possible to really have a bare metal linux and this is
> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>

In the embedded world, bare metal has a specific meaning. When your
application is directly addressing the hardware it's running on
without any operating system between the application and the hardware,
the application is running in bare metal mode.

When your application is talking to the hardware via a operating system
supplied API, that is not bare metal mode.

One specific example: one of the boards in front of me is a Atmel SAM7S256
board (this one: http://olimex.com/dev/sam7-h256.html in case you are
interested.) When my application directly talks to the hardware registers
on this board and handles the interrupts directly, then it's running in
bare metal mode.

If I write a BSP for a RTOS and modify the same application to run on this
board under that RTOS, then the application is no longer running in bare
metal mode.

If there's a cut down Linux between your application and the hardware,
then that application is not running in bare metal mode. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 3/26/2012 8:19:15 PM

On 2012-03-26 22:19, "Simon Clubley" wrote:

> [...]
> 
> If I write a BSP for a RTOS and modify the same application to run on this
> board under that RTOS, then the application is no longer running in bare
> metal mode.

I would suppose running a RTOS instead of Windows as the "base layer"
would be a real benefit, even if it is _not_ a "bare metal" solution.

> [...]

Michael

-- 
Real names enhance the probability of getting real answers.
My e-mail account at DECUS Munich is no longer valid.
0
Reply spam.to.unger (428) 3/26/2012 8:38:48 PM

Johnny Billquist wrote:

> Yes, and that is not properly "bare metal". Having Linux on which your 
> emulator runs, means it's running under Linux, not on the bare metal. 
> How hard can it be?


Except for IBM's LPARS (or whatever it is called) and Galaxy/Wildfire
class Alphas, are there hypervisors that allow multiple instances of an
OS directly on the hardware without some sort of host operating system ?

In the case of HP, the hypervisor they use on IA64 runs an instance of
HP-UX which then hosts other instances as glorified applications.

Anyone know what VMware really is ? It wouldn't susprise me if it had
linux under the hood.

Windows' offering is of course based on windows.

0
Reply jfmezei.spamnot (9469) 3/26/2012 8:40:45 PM

Simon Clubley wrote 2012-03-26 22:19:
> On 2012-03-26, JF Mezei<jfmezei.spamnot@vaxination.ca>  wrote:
>> John Wallace wrote:
>>
>>> Oh dear, not that silliness again. Not running Windows may be better
>>> than running Windows, but running a Linux layer underneath the
>>> emulator doesn't make it a "bare metal" emulator.
>>
>> Not sure how much of linux is included in that vtAlpha "bare bones". But
>> it is quite possible to really have a bare metal linux and this is
>> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>>
>
> In the embedded world, bare metal has a specific meaning. When your
> application is directly addressing the hardware it's running on
> without any operating system between the application and the hardware,
> the application is running in bare metal mode.
>
> When your application is talking to the hardware via a operating system
> supplied API, that is not bare metal mode.
>
> One specific example: one of the boards in front of me is a Atmel SAM7S256
> board (this one: http://olimex.com/dev/sam7-h256.html in case you are
> interested.) When my application directly talks to the hardware registers
> on this board and handles the interrupts directly, then it's running in
> bare metal mode.
>
> If I write a BSP for a RTOS and modify the same application to run on this
> board under that RTOS, then the application is no longer running in bare
> metal mode.
>
> If there's a cut down Linux between your application and the hardware,
> then that application is not running in bare metal mode. :-)
>

But Linux runs on "bare metal". And if that part is builtin in whatever
the developer calles "the product", then what ? Doesn't "the product" then
run on "bare metal"? Yes, one component of "the product" is some parts
usualy called "Linux", but so what ? Why should the customer/user care ?

The customer buys something called "vtAlpha" that can be runed on a
new "bare metal" box without installing anything else before. Fine.

In the same way, if someone buys your SAM7 "application" with a
builtin runtime version of a RTOS, he could get a "bare metal"
sam7-h256 board from Olimex and run it on.

The term "bare metal" is more how the user/customer looks at it.

If the user can install product "X" without pre-installing anything
else, product "X" runs on "bare metal". Doesn't matter a bit (to the
customer) what product "X" is built from.

Jan-Erik.









> Simon.
>

0
Reply jan-erik.soderholm (2673) 3/26/2012 8:46:55 PM

On Mar 26, 1:32=A0pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
> On Mar 26, 5:20=A0pm, Jerry Eckert <je...@virtual-vax-alpha.com> wrote:
>
>
>
>
>
> > On Mar 25, 3:48=A0am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
> > > In a commercial setup rather than hobbyist setup, a far greater
> > > concern than using one of the multiple cores [often unnecessarily]
> > > provided in many modern Window boxes would likely be the reliability
> > > and availability of the underlying OS in comparison with the
> > > reliability and availability which led to the choice (and retention)
> > > of VMS.
>
> > If one dedicates a box to the emulation applications, which is the
> > recommendation of the vendors, many of the Windows services can be
> > disabled. =A0This provides a significant improvement in the reliability
> > of the underlying OS. Since Windows network connectivity is for
> > management only, in most cases it should be possible to isolate it
> > from general network traffic, reducing exposure to the network
> > security vulnerabilities.
>
> > Another option is not to run the emulator under Windows. =A0vtAlpha's
> > bare metalapproach, which is a bundled Linux kernel, works well
> > because the underlying OS is shipped stripped down and tested with the
> > application; there is no issue with OS upgrades applied on-site
> > introducing incompatabilities.
>
> "vtAlpha's bare metalapproach, which is a bundled Linux kernel"
>
> Oh dear, not that silliness again. Not running Windows may be better
> than running Windows, but running a Linux layer underneath the
> emulator doesn't make it a "bare metal" emulator.
>
> Why is it so difficult for IT people to be honest these days?
>
> HYPErvisor. With the emphasis on the first four letters.- Hide quoted tex=
t -
>
> - Show quoted text -

The term "bare metal" is obviously from the user's perspective -- they
provide the appropriate hardware, no OS required.

Something has to provide the OS services: either the application can
bundle an existing OS (or the necessary portions of an OS), or the
application developers can write the code themselves.  The latter is
obviously not feasible from either economic or reliability
perspectives. Anyone who understands the technology should understand
this.
0
Reply jerry52 (6) 3/26/2012 8:54:12 PM

On Mar 26, 8:55=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> John Wallace wrote:
> > Oh dear, not that silliness again. Not running Windows may be better
> > than running Windows, but running a Linux layer underneath the
> > emulator doesn't make it a "bare metal" emulator.
>
> Not sure how much of linux is included in that vtAlpha "bare bones". But
> it is quite possible to really have a bare metal linux and this is
> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>
> In fact, when you look at the iphone, it's got BDS Unix under the hood
> but no command line utilities (and no command line). When you jailbreak
> it, the first thing it does is add the ability to access a command line
> and load all the standrad unix commands.

Well yes, any piece of smart modern consumer electronics very likely
bases its software on a custom Linux kernel, and busybox (look it up
if you don't already know it), and a few other pieces of application-
specific software. Your TV, your set top box, your cable/DSL router,
your NAS box, your media centre, etc, as well as the obvious
smartphones etc. Plus all kinds of professional kit not widely seen.

Do any of these vendors running their software on top of a Linux see
any reason to mislead (and irritate and thus discourage) their
potential customers by meaninglessly saying their application software
is running in "bare metal" mode?

Don't get me wrong, things like VMware and QEMU look like marvellous
pieces of software, as probably are the various PDP11 and VAX and
Alpha emulators (the PDP11 in JavaScript from the author of QEMU,
booting Unix V6 from a web page, is particularly mindblowing).

But none of them are "bare metal" software, and no sensible person
would to attempt to describe them as such, whatever the "industry
standard" usage of the term may have deteriorated to.

Bare metal HYPErvisor. The emphasis is on the first syllable.
0
Reply johnwallace44 (907) 3/26/2012 8:55:45 PM

On Mar 26, 3:19=A0pm, Simon Clubley <clubley@remove_me.eisner.decus.org-
Earth.UFP> wrote:
>
> In the embedded world, bare metal has a specific meaning. When your
> application is directly addressing the hardware it's running on
> without any operating system between the application and the hardware,
> the application is running in bare metal mode.
>
vtAlpha isn't targeted at embedded systems developers; I don't see why
one would expect the vendor to adhere to the terminology used in a
completely different market segment.  The term "bare metal", as used
by vtAlpha, accurately describes the nature of the product from the
host system administrator's perspective -- they provide a box with no
OS and install the application product.
0
Reply jerry52 (6) 3/26/2012 9:11:07 PM

On Mar 26, 9:40=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Johnny Billquist wrote:
> > Yes, and that is not properly "bare metal". Having Linux on which your
> > emulator runs, means it's running under Linux, not on the bare metal.
> > How hard can it be?
>
> Except for IBM's LPARS (or whatever it is called) and Galaxy/Wildfire
> class Alphas, are there hypervisors that allow multiple instances of an
> OS directly on the hardware without some sort of host operating system ?
>
> In the case of HP, the hypervisor they use on IA64 runs an instance of
> HP-UX which then hosts other instances as glorified applications.
>
> Anyone know what VMware really is ? It wouldn't susprise me if it had
> linux under the hood.
>
> Windows' offering is of course based on windows.

Yes various directly-bootable flavours of VMware have (historically)
had Linux under the hood. If I remember rightly they have ended up in
court because they weren't sticking to the licence (sorry, can't find
details right now).

I think as a result of those legal cases, VMware now runs on top of
something allegedly home grown which allegedly isn't Linux (so no GPL
to worry about) but from the bits I've seen written about, to anyone
with a bit of a clue it looks remarkably similar to what a kernel code
writer would see as Linux.

The difference between genuine "bare metal" and "thin OS" may matter
(not to everyone, but to some people). To some people it may matter
from a legal point of view, as VMware found out. And to some it may
matter from a practical point of view. E.g. to customers who are
retaining VMS because of its history of stability, when you put it on
top of a layer that introduces its own bugs and vulnerabilities. OK a
thinner layer than Windows, with fewer bugs than Windows, but not an
invisible layer.

The "not really bare metal" approach gives customers the flexibility
to install their VMS-machine emulator on a commodity box on which the
"not really bare metal" OS will almost certainly run OK much of the
time, but the "not really bare metal" OS will almost certainly not
have been tested and qualified to the level people used to expect from
VMS.

This "not really bare metal" OS will (presumably, as it's a thin
layer) not have the error recovery and diagnosis features which VMS
users have come to expect, right? If an intermittent disk error
occurs, how is it diagnosed? VMS managers running VMS on real hardware
know how. What happens in this environment, is there an error log in
the "not really bare metal" OS? Or does that kind of diagnosis in this
kind of environment require telepathetic skills?

There are lots of cases running simple legacy VMS apps where this kind
of stuff won't matter. Fine. But VMS often lives on in more complex
cases too, where it might matter more than is being admitted...
0
Reply johnwallace44 (907) 3/26/2012 9:15:20 PM

On Mar 26, 9:54=A0pm, Jerry Eckert <je...@virtual-vax-alpha.com> wrote:
> On Mar 26, 1:32=A0pm, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
>
>
> > On Mar 26, 5:20=A0pm, Jerry Eckert <je...@virtual-vax-alpha.com> wrote:
>
> > > On Mar 25, 3:48=A0am, John Wallace <johnwalla...@yahoo.co.uk> wrote:
>
> > > > In a commercial setup rather than hobbyist setup, a far greater
> > > > concern than using one of the multiple cores [often unnecessarily]
> > > > provided in many modern Window boxes would likely be the reliabilit=
y
> > > > and availability of the underlying OS in comparison with the
> > > > reliability and availability which led to the choice (and retention=
)
> > > > of VMS.
>
> > > If one dedicates a box to the emulation applications, which is the
> > > recommendation of the vendors, many of the Windows services can be
> > > disabled. =A0This provides a significant improvement in the reliabili=
ty
> > > of the underlying OS. Since Windows network connectivity is for
> > > management only, in most cases it should be possible to isolate it
> > > from general network traffic, reducing exposure to the network
> > > security vulnerabilities.
>
> > > Another option is not to run the emulator under Windows. =A0vtAlpha's
> > > bare metalapproach, which is a bundled Linux kernel, works well
> > > because the underlying OS is shipped stripped down and tested with th=
e
> > > application; there is no issue with OS upgrades applied on-site
> > > introducing incompatabilities.
>
> > "vtAlpha's bare metalapproach, which is a bundled Linux kernel"
>
> > Oh dear, not that silliness again. Not running Windows may be better
> > than running Windows, but running a Linux layer underneath the
> > emulator doesn't make it a "bare metal" emulator.
>
> > Why is it so difficult for IT people to be honest these days?
>
> > HYPErvisor. With the emphasis on the first four letters.- Hide quoted t=
ext -
>
> > - Show quoted text -
>
> The term "bare metal" is obviously from the user's perspective -- they
> provide the appropriate hardware, no OS required.
>
> Something has to provide the OS services: either the application can
> bundle an existing OS (or the necessary portions of an OS), or the
> application developers can write the code themselves. =A0The latter is
> obviously not feasible from either economic or reliability
> perspectives. Anyone who understands the technology should understand
> this.

The appropriate hardware for VMS is documented on the VMS SPD, isn't
it?
0
Reply johnwallace44 (907) 3/26/2012 9:16:33 PM

On 3/24/2012 7:38 AM, John Wallace wrote:
> On Mar 24, 12:45 pm, "John Reagan"<johnrrea...@earthlink.net>  wrote:
>> "JF Mezei"  wrote in message
>>
>> news:4f6d5a90$0$2201$c3e8da3$460562f1@news.astraweb.com...
>>
>>> I was just thinking.
>>> If HP were to produce fault tolerant 8086s for NSK, those boxes could
>>
>> Any more fault tolerant than the Itaniums used by NSK today?
>
> Exactly.
>
> Tandem hasn't needed CPU lockstep since they dropped their own
> proprietary processor architectures, and that's a LONG time ago in
> processor history. This isn't a secret, but it may as well be as far
> as the trade media and others are concerned.
>
> In modern Tandem boxes, the synchronisation is not at instruction
> level or even main-memory access level but conceptually more like "IO
> access level" (or maybe process context switch level). The
> synchronisation is not on the CPU chip, not even particularly close to
> it, but is managed by a piece of complex external logic called the
> Logical Synchronization Unit, which doesn't care about instruction-
> level lockstep but does care that each processor's operations result
> in the same IO with the outside world (and the same context if a
> processor swap has to occur). The LSU also does a lot more than that,
> which I won't go into here.
>
> The 2006 Oztug presentation at [1] was given by one of Tandem's senior
> architects, Hal Massey, and was an excellent intro to the internals of
> Tandem boxes over the years. Sadly, it's fallen off the internet and I
> haven't kept a copy and nor have I yet been able to find a suitable
> replacement. Suggestions welcome for a definitive replacement - but
> I'm not holding my breath.

> [1] www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf - now
> vanished, sadly.

I see the session description for Hal Massey's session at Archive.org:
http://web.archive.org/web/20060716110540/http://www.oztug.org/events/2006/Techsessions.cfm

"NonStop Advanced Architecture for Integrity NS Server, Hal Massey, HP

The NonStop Advanced Architecture (NSAA) is a new offering in the 
NonStop world. It's so new that we are finding new ways to describe it, 
new aspects of its advantages, and positve feedback from customers who 
are utilizing it in their applications on Integrity NS-series servers. 
The fundamentals that the NonStop division is famous for are showing up 
in exciting new forms and functions. This is the session to learn about 
how NSAA can make a difference in your world."

Does sound interesting. Maybe some of these will be helpful:

HP NonStop Advanced Architecture web page with FAQs and white paper:
http://h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html

NonStop Advanced Architecture, System Configuration and Site Planning, 
Bob Kossler
ftp://ftp.hp.com/pub/nonstop/ccc/2005/jun0905.pdf

The NonStop Advanced Architecture Value Proposition: HP Integrity 
NonStop Server Availability Compared to NonStop S-series Server, Bob Kossler
ftp://ftp.hp.com/pub/nonstop/ccc/2005/sep1505.pdf

Data Integrity in HP NonStop Servers
http://www.cs.uiuc.edu/class/sp06/cs523/nonstop-selse06.pdf

NonStop Advanced Architecture
http://www.cse.chalmers.se/~davidwh/eac/papers/karlsson5.pdf

NonStop Servers - The future    (from 2003)
http://www.suntug.org/Articles/SE_RUG_Roadshow_V3_June_203.pdf
0
Reply keithparris_deletethis (241) 3/26/2012 9:28:39 PM

On Mar 26, 10:28=A0pm, Keith Parris <keithparris_deletet...@yahoo.com>
wrote:
> On 3/24/2012 7:38 AM, John Wallace wrote:
>
>
>
> > On Mar 24, 12:45 pm, "John Reagan"<johnrrea...@earthlink.net> =A0wrote:
> >> "JF Mezei" =A0wrote in message
>
> >>news:4f6d5a90$0$2201$c3e8da3$460562f1@news.astraweb.com...
>
> >>> I was just thinking.
> >>> If HP were to produce fault tolerant 8086s for NSK, those boxes could
>
> >> Any more fault tolerant than the Itaniums used by NSK today?
>
> > Exactly.
>
> > Tandem hasn't needed CPU lockstep since they dropped their own
> > proprietary processor architectures, and that's a LONG time ago in
> > processor history. This isn't a secret, but it may as well be as far
> > as the trade media and others are concerned.
>
> > In modern Tandem boxes, the synchronisation is not at instruction
> > level or even main-memory access level but conceptually more like "IO
> > access level" (or maybe process context switch level). The
> > synchronisation is not on the CPU chip, not even particularly close to
> > it, but is managed by a piece of complex external logic called the
> > Logical Synchronization Unit, which doesn't care about instruction-
> > level lockstep but does care that each processor's operations result
> > in the same IO with the outside world (and the same context if a
> > processor swap has to occur). The LSU also does a lot more than that,
> > which I won't go into here.
>
> > The 2006 Oztug presentation at [1] was given by one of Tandem's senior
> > architects, Hal Massey, and was an excellent intro to the internals of
> > Tandem boxes over the years. Sadly, it's fallen off the internet and I
> > haven't kept a copy and nor have I yet been able to find a suitable
> > replacement. Suggestions welcome for a definitive replacement - but
> > I'm not holding my breath.
> > [1]www.oztug.org/events/2006/AdvancedArchitecture_Massey.pdf- now
> > vanished, sadly.
>
> I see the session description for Hal Massey's session at Archive.org:htt=
p://web.archive.org/web/20060716110540/http://www.oztug.org/events...
>
> "NonStop Advanced Architecture for Integrity NS Server, Hal Massey, HP
>
> The NonStop Advanced Architecture (NSAA) is a new offering in the
> NonStop world. It's so new that we are finding new ways to describe it,
> new aspects of its advantages, and positve feedback from customers who
> are utilizing it in their applications on Integrity NS-series servers.
> The fundamentals that the NonStop division is famous for are showing up
> in exciting new forms and functions. This is the session to learn about
> how NSAA can make a difference in your world."
>
> Does sound interesting. Maybe some of these will be helpful:
>
> HP NonStop Advanced Architecture web page with FAQs and white paper:http:=
//h20223.www2.hp.com/NonStopComputing/cache/77119-0-0-0-121.html
>
> NonStop Advanced Architecture, System Configuration and Site Planning,
> Bob Kosslerftp://ftp.hp.com/pub/nonstop/ccc/2005/jun0905.pdf
>
> The NonStop Advanced Architecture Value Proposition: HP Integrity
> NonStop Server Availability Compared to NonStop S-series Server, Bob Koss=
lerftp://ftp.hp.com/pub/nonstop/ccc/2005/sep1505.pdf
>
> Data Integrity in HP NonStop Servershttp://www.cs.uiuc.edu/class/sp06/cs5=
23/nonstop-selse06.pdf
>
> NonStop Advanced Architecturehttp://www.cse.chalmers.se/~davidwh/eac/pape=
rs/karlsson5.pdf
>
> NonStop Servers - The future =A0 =A0(from 2003)http://www.suntug.org/Arti=
cles/SE_RUG_Roadshow_V3_June_203.pdf

Good stuff on that list, but the Hal Massey one is/was betterer (or so
my subjective memory tells me).

You might want to add (from 2008, so relatively recent):
http://www.availabilitydigest.com/public_articles/0308/ns_blades.pdf
0
Reply johnwallace44 (907) 3/26/2012 10:44:43 PM

John Wallace wrote:
>
> You might want to add (from 2008, so relatively recent):
> http://www.availabilitydigest.com/public_articles/0308/ns_blades.pdf

This is the first document that provides real (non marketing
gobbledeegook) information. Many thanks.

I am interested thought in finding out what is different between the
C-class chassis/blades used for NonStop and the ones uses for HP-UX/VMS.

are the blade cards with CPU the same ? if not, what is different ?

It *looks* like HP is using its standard C class enclosures and blade
boards with slightly different firmware and some peripheral modules to
add the management and fault detection logic. Is that the case ?



Also, out of curiosity, would Tandem customers really want to take 4
different cabinets with 4 CPUs each and merge them into a single Class
blade system with all 16 processors in one box ?  Seems to me that
having all their eggs in one blade enclosure seems more risky than
having at least 2 separate systems.

0
Reply jfmezei.spamnot (9469) 3/26/2012 11:17:26 PM

On 2012-03-26 22:46, Jan-Erik Soderholm wrote:
> Simon Clubley wrote 2012-03-26 22:19:
>> On 2012-03-26, JF Mezei<jfmezei.spamnot@vaxination.ca> wrote:
>>> John Wallace wrote:
>>>
>>>> Oh dear, not that silliness again. Not running Windows may be better
>>>> than running Windows, but running a Linux layer underneath the
>>>> emulator doesn't make it a "bare metal" emulator.
>>>
>>> Not sure how much of linux is included in that vtAlpha "bare bones". But
>>> it is quite possible to really have a bare metal linux and this is
>>> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>>>
>>
>> In the embedded world, bare metal has a specific meaning. When your
>> application is directly addressing the hardware it's running on
>> without any operating system between the application and the hardware,
>> the application is running in bare metal mode.
>>
>> When your application is talking to the hardware via a operating system
>> supplied API, that is not bare metal mode.
>>
>> One specific example: one of the boards in front of me is a Atmel
>> SAM7S256
>> board (this one: http://olimex.com/dev/sam7-h256.html in case you are
>> interested.) When my application directly talks to the hardware registers
>> on this board and handles the interrupts directly, then it's running in
>> bare metal mode.
>>
>> If I write a BSP for a RTOS and modify the same application to run on
>> this
>> board under that RTOS, then the application is no longer running in bare
>> metal mode.
>>
>> If there's a cut down Linux between your application and the hardware,
>> then that application is not running in bare metal mode. :-)
>>
>
> But Linux runs on "bare metal". And if that part is builtin in whatever
> the developer calles "the product", then what ? Doesn't "the product" then
> run on "bare metal"? Yes, one component of "the product" is some parts
> usualy called "Linux", but so what ? Why should the customer/user care ?
>
> The customer buys something called "vtAlpha" that can be runed on a
> new "bare metal" box without installing anything else before. Fine.
>
> In the same way, if someone buys your SAM7 "application" with a
> builtin runtime version of a RTOS, he could get a "bare metal"
> sam7-h256 board from Olimex and run it on.
>
> The term "bare metal" is more how the user/customer looks at it.
>
> If the user can install product "X" without pre-installing anything
> else, product "X" runs on "bare metal". Doesn't matter a bit (to the
> customer) what product "X" is built from.

That is a pretty meaningless definition. I could then just as well say 
that my Firefox runs on bare metal.

It makes a big difference in that the underlying layer can and will hide 
away and abstract away some parts of the underlying details.
That is the whole point of the underlying layer. Abstract away gritty 
details of the hardware so that your software can be written in a more 
general way and work on various different types of hardware.
But it comes at a costs. I no longer knows exactly what happens at the 
hardware layer. That is handled by the middleware. As someone else 
mentioned - what about hardware errors, as an example. I no longer get 
reports of those, nor can my system perform actions to such errors. I'm 
just presented with a preprocessed result to whatever request I made.
And if your expectations are that you are on the bare metal, then you 
probably also expect all kind of potential hardware problems to be 
visible. To *your* emulator, and not only to the underlying operating 
system...

	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
Reply bqt2 (1410) 3/27/2012 10:25:50 AM

On 2012-03-26 23:11, Jerry Eckert wrote:
> On Mar 26, 3:19 pm, Simon Clubley<clubley@remove_me.eisner.decus.org-
> Earth.UFP>  wrote:
>>
>> In the embedded world, bare metal has a specific meaning. When your
>> application is directly addressing the hardware it's running on
>> without any operating system between the application and the hardware,
>> the application is running in bare metal mode.
>>
> vtAlpha isn't targeted at embedded systems developers; I don't see why
> one would expect the vendor to adhere to the terminology used in a
> completely different market segment.  The term "bare metal", as used
> by vtAlpha, accurately describes the nature of the product from the
> host system administrator's perspective -- they provide a box with no
> OS and install the application product.

Cool. So I can just call my target audience "foobars", and then I can 
redefine known terms to mean what I want? Sounds like an excellent 
opportunity to sell non-stop servers, machines that produce gold, and 
oracle databases here...

	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
Reply bqt2 (1410) 3/27/2012 10:27:20 AM

On 2012-03-27, Johnny Billquist <bqt@softjar.se> wrote:
> On 2012-03-26 23:11, Jerry Eckert wrote:
>> On Mar 26, 3:19 pm, Simon Clubley<clubley@remove_me.eisner.decus.org-
>> Earth.UFP>  wrote:
>>>
>>> In the embedded world, bare metal has a specific meaning. When your
>>> application is directly addressing the hardware it's running on
>>> without any operating system between the application and the hardware,
>>> the application is running in bare metal mode.
>>>
>> vtAlpha isn't targeted at embedded systems developers; I don't see why
>> one would expect the vendor to adhere to the terminology used in a
>> completely different market segment.  The term "bare metal", as used
>> by vtAlpha, accurately describes the nature of the product from the
>> host system administrator's perspective -- they provide a box with no
>> OS and install the application product.

I would expect it because the terminology is not tied to the market
segment, but is tied to the technology in use, regardless of the target
market.

We don't change the definition of operating system (for example) to mean
different things depending on the market segment. We include different
capabilities in the operating system depending on the market segment
but we don't change the definition itself.

Furthermore, how does the use of this hidden layer affect the realtime
capabilities of the emulation it provides ? If people are told it's bare
metal, then they may expect a much more deterministic response time than
they would expect from something running on a hidden OS.

In virtualisation there have been security issues with the guest operating
system been able to break through the virtualisation layer and compromise
the security or functionality of the virtualisation environment. Does
this hidden Linux layer also pose security risks, if say, a path exists
from the network to the Linux layer and a remote exploit is discovered in
the underlying Linux version ?

It would seem to me that if the Linux layer is network accessible then it
would have to be updated on a regular basis for any security issues, just
as my normal Linux servers and clients have to be.

If the box is been sold as a black box, is this updating done (assuming of
course the underlying functionality causes such updating to be required) ?

>
> Cool. So I can just call my target audience "foobars", and then I can 
> redefine known terms to mean what I want? Sounds like an excellent 
> opportunity to sell non-stop servers, machines that produce gold, and 
> oracle databases here...
>

I agree. If the use of the term "bare metal" doesn't mean anything to
someone outside of the embedded world, then why is it used in the
advertising material for these products as a positive selling point ?

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 3/27/2012 11:53:37 AM

On Mon, 26 Mar 2012 11:30:03 -0700, John Wallace wrote:

> I had a trip to a vendor in Leeds once, when my then employers were
> looking to replace an 11/70 with an 11/780 (UK readers may know the
> vendor I mean). The place we went sold "DEC compatible" kit, where
> anything that didn't need to come direct from DEC was replaced with
> cheaper alternatives (everything from industrial power supplies to
> photocopied manuals to disk controllers and drives). Their idea of an
> *external* MASSbus cable was what would now be called a rainbow ribbon
> (twisted) cable. You could drive a fork truck over the DEC cables (and
> more importantly drop a computer room floor tile on them) and they'd
> survive. Not so with the "compatible" ones.

Chuckle.  As one customer found out the hard way, when you have fork 
lifts rushing around you need to think of redundant comms gear around 
your factory floor.

IBM also had very robust cables, some would say over-engineered, but then 
IBM could get away with the prices.

Yes, your description of that UK vendor leaves me in no doubt who they 
were.  They even had a separate company devoted to selling the original 
DEC kit that had been separated from bought systems.

-- 
Paul Sture
0
Reply paul303 (1382) 3/27/2012 12:31:10 PM

Johnny Billquist wrote 2012-03-27 12:25:
> On 2012-03-26 22:46, Jan-Erik Soderholm wrote:
>> Simon Clubley wrote 2012-03-26 22:19:
>>> On 2012-03-26, JF Mezei<jfmezei.spamnot@vaxination.ca> wrote:
>>>> John Wallace wrote:
>>>>
>>>>> Oh dear, not that silliness again. Not running Windows may be better
>>>>> than running Windows, but running a Linux layer underneath the
>>>>> emulator doesn't make it a "bare metal" emulator.
>>>>
>>>> Not sure how much of linux is included in that vtAlpha "bare bones". But
>>>> it is quite possible to really have a bare metal linux and this is
>>>> commonly done for embedded systems, TVs, thermostats, TV decoders etc.
>>>>
>>>
>>> In the embedded world, bare metal has a specific meaning. When your
>>> application is directly addressing the hardware it's running on
>>> without any operating system between the application and the hardware,
>>> the application is running in bare metal mode.
>>>
>>> When your application is talking to the hardware via a operating system
>>> supplied API, that is not bare metal mode.
>>>
>>> One specific example: one of the boards in front of me is a Atmel
>>> SAM7S256
>>> board (this one: http://olimex.com/dev/sam7-h256.html in case you are
>>> interested.) When my application directly talks to the hardware registers
>>> on this board and handles the interrupts directly, then it's running in
>>> bare metal mode.
>>>
>>> If I write a BSP for a RTOS and modify the same application to run on
>>> this
>>> board under that RTOS, then the application is no longer running in bare
>>> metal mode.
>>>
>>> If there's a cut down Linux between your application and the hardware,
>>> then that application is not running in bare metal mode. :-)
>>>
>>
>> But Linux runs on "bare metal". And if that part is builtin in whatever
>> the developer calles "the product", then what ? Doesn't "the product" then
>> run on "bare metal"? Yes, one component of "the product" is some parts
>> usualy called "Linux", but so what ? Why should the customer/user care ?
>>
>> The customer buys something called "vtAlpha" that can be runed on a
>> new "bare metal" box without installing anything else before. Fine.
>>
>> In the same way, if someone buys your SAM7 "application" with a
>> builtin runtime version of a RTOS, he could get a "bare metal"
>> sam7-h256 board from Olimex and run it on.
>>
>> The term "bare metal" is more how the user/customer looks at it.
>>
>> If the user can install product "X" without pre-installing anything
>> else, product "X" runs on "bare metal". Doesn't matter a bit (to the
>> customer) what product "X" is built from.
>
> That is a pretty meaningless definition. I could then just as well say that
> my Firefox runs on bare metal.

Yes, if you could get a packed version of Firefox that includes
everything it needs to be installed on a "bare metal" box from
the shelf. You can't. You need to have a system with an OS up
and running to be able to install Firefox.

If one would build a combined Firefox/Linux distribution (where
Linux was more or less hidden from the user), then this would be
a Firefox kit that installs and runs on a "bare metal" box directly.

The rest below is "just" technical details that most users
just couldn't care less about anyway.

Jan-Erik.

>
> It makes a big difference in that the underlying layer can and will hide
> away and abstract away some parts of the underlying details.
> That is the whole point of the underlying layer. Abstract away gritty
> details of the hardware so that your software can be written in a more
> general way and work on various different types of hardware.
> But it comes at a costs. I no longer knows exactly what happens at the
> hardware layer. That is handled by the middleware. As someone else
> mentioned - what about hardware errors, as an example. I no longer get
> reports of those, nor can my system perform actions to such errors. I'm
> just presented with a preprocessed result to whatever request I made.
> And if your expectations are that you are on the bare metal, then you
> probably also expect all kind of potential hardware problems to be visible.
> To *your* emulator, and not only to the underlying operating system...
>
> Johnny
>

0
Reply jan-erik.soderholm (2673) 3/27/2012 1:47:00 PM

Bob Koehler wrote 2012-03-27 17:49:
> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik Soderholm<jan-erik.soderholm@telia.com>  writes:
>>
>> But Linux runs on "bare metal". And if that part is builtin in whatever
>> the developer calles "the product", then what ? Doesn't "the product" then
>> run on "bare metal"? Yes, one component of "the product" is some parts
>> usualy called "Linux", but so what ? Why should the customer/user care ?
>
>     Because the Linux kernel can't handle some of the hard real-time
>     applications that the user might have.
>

But that is a completly different question.
It has nothing to do with the "bare metall" discussion.
0
Reply jan-erik.soderholm (2673) 3/27/2012 2:23:52 PM

On 2012-03-27 16.23, Jan-Erik Soderholm wrote:
> Bob Koehler wrote 2012-03-27 17:49:
>> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik
>> Soderholm<jan-erik.soderholm@telia.com> writes:
>>>
>>> But Linux runs on "bare metal". And if that part is builtin in whatever
>>> the developer calles "the product", then what ? Doesn't "the product"
>>> then
>>> run on "bare metal"? Yes, one component of "the product" is some parts
>>> usualy called "Linux", but so what ? Why should the customer/user care ?
>>
>> Because the Linux kernel can't handle some of the hard real-time
>> applications that the user might have.
>>
>
> But that is a completly different question.
> It has nothing to do with the "bare metall" discussion.

I think it has a lot of relevance if your "bare metal" actually 
introduce a non-deterministic middle layer to your emulation.

The bare metal actually, by definition, do not have this property. So I 
would expect something that runs on the bare metal to retain that 
property, which to some is a very much wanted property. By falsely 
claiming that a product is running on the bare metal, when it actually 
is running on top of an operating system, they are in fact doing false 
marketing, and implicitly claim properties of their system which they 
can not back up.

"Bare metal" is not just a word... It *means* something.

	Johnny

0
Reply bqt2 (1410) 3/27/2012 3:23:10 PM

In article <4f70d44f$0$1746$c3e8da3$92d0a893@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Anyone know what VMware really is ? It wouldn't susprise me if it had
> linux under the hood.

   I think VMware is a product line.  I know we're using it to host
   WXP on top of Mac OS.  Since they're both Intel user mode code on
   WXP simply runs as user mode code on the CPU.  Adds I hear for VMware
   imply other, quite different products.

   For us, VMware has to intercept WXP access to the underlying hardware, 
   and simulate interrupts from hardware, but I don't suspect anyone of
   tossing a whole Linux kernel in there just for that.

0
Reply koehler2 (8314) 3/27/2012 3:42:02 PM

In article <162d0e52-99d4-4859-8e37-6a5342578ca9@er9g2000vbb.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
> 
> The appropriate hardware for VMS is documented on the VMS SPD, isn't
> it?

   Yes.  I haven't looked for it in the SPD, but at least one VAX emulator
   is also officially supported, if running on Windows on HP hardware.

0
Reply koehler2 (8314) 3/27/2012 3:44:07 PM

In article <fefb398b-b9ee-439f-ac13-967d32e47d75@gw9g2000vbb.googlegroups.com>, John Wallace <johnwallace4@yahoo.co.uk> writes:
> 
> This "not really bare metal" OS will (presumably, as it's a thin
> layer) not have the error recovery and diagnosis features which VMS
> users have come to expect, right? If an intermittent disk error
> occurs, how is it diagnosed? VMS managers running VMS on real hardware
> know how. What happens in this environment, is there an error log in
> the "not really bare metal" OS? Or does that kind of diagnosis in this
> kind of environment require telepathetic skills?

   It's been a long time since the disks themselves have hidden that
   information from VMS.

   A thin layer of anything could mess up VMS' real-time capabilities
   mightily.  But the owner has long since stopped selling VMS to any
   market that cares.

0
Reply koehler2 (8314) 3/27/2012 3:46:31 PM

In article <jkqkjv$p1i$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> 
> But Linux runs on "bare metal". And if that part is builtin in whatever
> the developer calles "the product", then what ? Doesn't "the product" then
> run on "bare metal"? Yes, one component of "the product" is some parts
> usualy called "Linux", but so what ? Why should the customer/user care ?

   Because the Linux kernel can't handle some of the hard real-time
   applications that the user might have.

0
Reply koehler2 (8314) 3/27/2012 3:49:18 PM

Johnny Billquist wrote 2012-03-27 17:23:
> On 2012-03-27 16.23, Jan-Erik Soderholm wrote:
>> Bob Koehler wrote 2012-03-27 17:49:
>>> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik
>>> Soderholm<jan-erik.soderholm@telia.com> writes:
>>>>
>>>> But Linux runs on "bare metal". And if that part is builtin in whatever
>>>> the developer calles "the product", then what ? Doesn't "the product"
>>>> then
>>>> run on "bare metal"? Yes, one component of "the product" is some parts
>>>> usualy called "Linux", but so what ? Why should the customer/user care ?
>>>
>>> Because the Linux kernel can't handle some of the hard real-time
>>> applications that the user might have.
>>>
>>
>> But that is a completly different question.
>> It has nothing to do with the "bare metall" discussion.
>
> I think it has a lot of relevance if your "bare metal" actually introduce a
> non-deterministic middle layer to your emulation.
>
> The bare metal actually, by definition, do not have this property. So I
> would expect something that runs on the bare metal to retain that property,
> which to some is a very much wanted property. By falsely claiming that a
> product is running on the bare metal, when it actually is running on top of
> an operating system, they are in fact doing false marketing, and implicitly
> claim properties of their system which they can not back up.
>
> "Bare metal" is not just a word... It *means* something.
>
> Johnny
>

Windows runs on "bare metal", still many would claim that Windows
is non-deterministic.

I could easily write some simple code that runs on "bare metal"
that would be (by design!) *very* non-deterministic... :-)

No, the only thing rellevant here is if you need to add any software
yourself (such as an "OS") before installing the actual "product".



0
Reply jan-erik.soderholm (2673) 3/27/2012 4:12:16 PM

On 3/24/2012 11:40 PM, JF Mezei wrote:
> SimH causes one core of an x86 to run at 100% all the time to emulate
> the vax.  A Mac Pro computer running at 100% consumes about as much
> power as a DS10L.
>
> If SimH could "capture" the idle loop and sleep the process instead,
> then power consumption might be down, but not that much.

SimH can detect the idle loop and throttle back. Hoff has a great 
write-up on this at http://labs.hoffmanlabs.com/node/931

0
Reply keithparris_deletethis (241) 3/27/2012 4:41:59 PM

On Mar 27, 4:42=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <4f70d44f$0$1746$c3e8da3$92d0a...@news.astraweb.com>, JF Mezei=
 <jfmezei.spam...@vaxination.ca> writes:
>
>
>
> > Anyone know what VMware really is ? It wouldn't susprise me if it had
> > linux under the hood.
>
> =A0 =A0I think VMware is a product line. =A0I know we're using it to host
> =A0 =A0WXP on top of Mac OS. =A0Since they're both Intel user mode code o=
n
> =A0 =A0WXP simply runs as user mode code on the CPU. =A0Adds I hear for V=
Mware
> =A0 =A0imply other, quite different products.
>
> =A0 =A0For us, VMware has to intercept WXP access to the underlying hardw=
are,
> =A0 =A0and simulate interrupts from hardware, but I don't suspect anyone =
of
> =A0 =A0tossing a whole Linux kernel in there just for that.

" I think VMware is a product line."

The VMware brand covers multiple different products. Some of them run
on top of a very visible OS (often but not always Windows).

Some so-called bare metal ones run on top of a "not really bare metal"
OS, not unlike the discussion we're having here. This "not really bare
metal" OS provides facilities such as hardware independence for the
next layer up, remote management, resource allocation, scheduling, and
many of the other things that would normally be regarded as the
territory of a real OS.

The main difference between this and a real OS is that a real OS
usually offers a documented set of generic APIs so that customers can
write their own applications. The API(s) offered by VMware's ESX
family are, as far as I know, intended primarily to support the
management of the ESX product and not (for example) re-implementing
DECburger or All-in-1 or a stock exchange trading system.
0
Reply johnwallace44 (907) 3/27/2012 5:06:21 PM

On Mar 27, 2:47=A0pm, Jan-Erik Soderholm <jan-erik.soderh...@telia.com>
wrote:
> Johnny Billquist wrote 2012-03-27 12:25:
>
>
>
> > On 2012-03-26 22:46, Jan-Erik Soderholm wrote:
> >> Simon Clubley wrote 2012-03-26 22:19:
> >>> On 2012-03-26, JF Mezei<jfmezei.spam...@vaxination.ca> wrote:
> >>>> John Wallace wrote:
>
> >>>>> Oh dear, not that silliness again. Not running Windows may be bette=
r
> >>>>> than running Windows, but running a Linux layer underneath the
> >>>>> emulator doesn't make it a "bare metal" emulator.
>
> >>>> Not sure how much of linux is included in that vtAlpha "bare bones".=
 But
> >>>> it is quite possible to really have a bare metal linux and this is
> >>>> commonly done for embedded systems, TVs, thermostats, TV decoders et=
c.
>
> >>> In the embedded world, bare metal has a specific meaning. When your
> >>> application is directly addressing the hardware it's running on
> >>> without any operating system between the application and the hardware=
,
> >>> the application is running in bare metal mode.
>
> >>> When your application is talking to the hardware via a operating syst=
em
> >>> supplied API, that is not bare metal mode.
>
> >>> One specific example: one of the boards in front of me is a Atmel
> >>> SAM7S256
> >>> board (this one:http://olimex.com/dev/sam7-h256.htmlin case you are
> >>> interested.) When my application directly talks to the hardware regis=
ters
> >>> on this board and handles the interrupts directly, then it's running =
in
> >>> bare metal mode.
>
> >>> If I write a BSP for a RTOS and modify the same application to run on
> >>> this
> >>> board under that RTOS, then the application is no longer running in b=
are
> >>> metal mode.
>
> >>> If there's a cut down Linux between your application and the hardware=
,
> >>> then that application is not running in bare metal mode. :-)
>
> >> But Linux runs on "bare metal". And if that part is builtin in whateve=
r
> >> the developer calles "the product", then what ? Doesn't "the product" =
then
> >> run on "bare metal"? Yes, one component of "the product" is some parts
> >> usualy called "Linux", but so what ? Why should the customer/user care=
 ?
>
> >> The customer buys something called "vtAlpha" that can be runed on a
> >> new "bare metal" box without installing anything else before. Fine.
>
> >> In the same way, if someone buys your SAM7 "application" with a
> >> builtin runtime version of a RTOS, he could get a "bare metal"
> >> sam7-h256 board from Olimex and run it on.
>
> >> The term "bare metal" is more how the user/customer looks at it.
>
> >> If the user can install product "X" without pre-installing anything
> >> else, product "X" runs on "bare metal". Doesn't matter a bit (to the
> >> customer) what product "X" is built from.
>
> > That is a pretty meaningless definition. I could then just as well say =
that
> > my Firefox runs on bare metal.
>
> Yes, if you could get a packed version of Firefox that includes
> everything it needs to be installed on a "bare metal" box from
> the shelf. You can't. You need to have a system with an OS up
> and running to be able to install Firefox.
>
> If one would build a combined Firefox/Linux distribution (where
> Linux was more or less hidden from the user), then this would be
> a Firefox kit that installs and runs on a "bare metal" box directly.
>
> The rest below is "just" technical details that most users
> just couldn't care less about anyway.
>
> Jan-Erik.
>
>
>
> > It makes a big difference in that the underlying layer can and will hid=
e
> > away and abstract away some parts of the underlying details.
> > That is the whole point of the underlying layer. Abstract away gritty
> > details of the hardware so that your software can be written in a more
> > general way and work on various different types of hardware.
> > But it comes at a costs. I no longer knows exactly what happens at the
> > hardware layer. That is handled by the middleware. As someone else
> > mentioned - what about hardware errors, as an example. I no longer get
> > reports of those, nor can my system perform actions to such errors. I'm
> > just presented with a preprocessed result to whatever request I made.
> > And if your expectations are that you are on the bare metal, then you
> > probably also expect all kind of potential hardware problems to be visi=
ble.
> > To *your* emulator, and not only to the underlying operating system...
>
> > Johnny

"a combined Firefox/Linux distribution (where Linux was more or less
hidden from the user), then this would be a Firefox kit that installs
and runs on a "bare metal" box directly."

Probably not that difficult to do with a LiveLinux CD and a bit of
ingenuity. And when you take out the CD, it's gone, nothing to see.

When someone finishes installing a "not really bare metal" HYPErvisor,
it leaves plenty of evidence behind. E.g. something bootable that can
be executed when the hardware powers up.

Moving on: VMS on native hardware is well characterised.

A Linux can have a variety of characteristics depending on the
particular Linux and the particular configuration. Some of these
characteristics (not just the realtime ones) will likely affect the
characteristics of a VMS system running in a "not really bare metal"
environment.

When you say "users" may not care about them, it depends on whether
you mean end users ie non-IT people sitting at VT emulators, or
whether users means the people installing (that word again) the
emulator, the people trying to continue to use VMS to run an important
business application, who may have little vendor support for
diagnosing problems when something occasionally goes wrong at low
level.
0
Reply johnwallace44 (907) 3/27/2012 5:16:19 PM

On 2012-03-27, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> wrote:
> Johnny Billquist wrote 2012-03-27 17:23:
>> On 2012-03-27 16.23, Jan-Erik Soderholm wrote:
>>> Bob Koehler wrote 2012-03-27 17:49:
>>>> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik
>>>> Soderholm<jan-erik.soderholm@telia.com> writes:
>>>>>
>>>>> But Linux runs on "bare metal". And if that part is builtin in whatever
>>>>> the developer calles "the product", then what ? Doesn't "the product"
>>>>> then
>>>>> run on "bare metal"? Yes, one component of "the product" is some parts
>>>>> usualy called "Linux", but so what ? Why should the customer/user care ?
>>>>
>>>> Because the Linux kernel can't handle some of the hard real-time
>>>> applications that the user might have.
>>>>
>>>
>>> But that is a completly different question.
>>> It has nothing to do with the "bare metall" discussion.
>>
>> I think it has a lot of relevance if your "bare metal" actually introduce a
>> non-deterministic middle layer to your emulation.
>>
>> The bare metal actually, by definition, do not have this property. So I
>> would expect something that runs on the bare metal to retain that property,
>> which to some is a very much wanted property. By falsely claiming that a
>> product is running on the bare metal, when it actually is running on top of
>> an operating system, they are in fact doing false marketing, and implicitly
>> claim properties of their system which they can not back up.
>>
>> "Bare metal" is not just a word... It *means* something.
>>
>> Johnny
>>
>
> Windows runs on "bare metal", still many would claim that Windows
> is non-deterministic.
>

You are missing the point. :-)

You don't get deterministic behaviour simply by running your software
on bare metal; your software has to be designed to have deterministic
behaviour. Running on bare metal is what allows you to maintain that
deterministic behaviour (in the absence of a dedicated RTOS).

In order to guarantee deterministic behaviour on a platform, you need
to make sure that everything about that platform behaves in a predictable
and deterministic manner.

It doesn't matter if your software, in it's native environment, is the
most predictable and deterministic software in the world if it's running
on top of a hidden OS layer which is non-deterministic.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 3/27/2012 5:25:56 PM

On Tue, 27 Mar 2012 09:42:02 -0600, Bob Koehler wrote:

> In article <4f70d44f$0$1746$c3e8da3$92d0a893@news.astraweb.com>, JF
> Mezei <jfmezei.spamnot@vaxination.ca> writes:
>> 
>> Anyone know what VMware really is ? It wouldn't susprise me if it had
>> linux under the hood.
> 
>    I think VMware is a product line.  I know we're using it to host WXP
>    on top of Mac OS.  Since they're both Intel user mode code on WXP
>    simply runs as user mode code on the CPU.  Adds I hear for VMware
>    imply other, quite different products.

Yes, VMware has a family of products.  The one you are running on Mac OS 
X is probably (but not necessarily) VMware Fusion.

It does add its own networking and allows you to talk to peripherals 
which are only supported by Windows:

http://www.vmware.com/products/fusion/overview.html

>    For us, VMware has to intercept WXP access to the underlying
>    hardware, and simulate interrupts from hardware, but I don't suspect
>    anyone of tossing a whole Linux kernel in there just for that.

It's probably hosting a virtual disk for the Windows system, easy to back 
up, and will have snapshot facilities so you can roll back to a known 
good point-

I have used the equivalent (known as VMware Workstation) on Windows and 
Linux hosts.  I am not sure how much that differs from the Mac version, 
but you can seamlessly integrate desktops, make movies of your work adn 
so on.  VMware also has the means to build comprehensive virtual 
networks, handy for those who want to test them out before deploying.

I did find a couple of performance problems with it *for my environment*:

a) It uses its own pagefiles. The advantage here is that you can have
   n virtual machines which have total RAM exceeding the amount on
   the host system.  The drawback for me was that it used these pagefiles
   even when I had plenty of real RAM free, and it slowed things up too
   much.

b) It has its own allocation algorithms for hosted virtual disks, and
   functionality to defragment these.  You still have to do any
   defragmentation that the Windows virtual machine requires itself
   though.

Point a) is what persuaded me to look elsewhere on my hardware, I got 
sick of the system grinding to a halt with the disk activity light on 
solidly.  I chose VirtualBox.

If you have the right combination of disks attached to the host, you can 
set your virtual machines to use them as raw devices by their O/S.

I also looked at different Linux file systems when I was looking at VMware 
Workstation.  I wasn't particularly happy about the performance I got 
with any of them*, and believe it or not, I ended up concluding that 
Windows as a host provided me with better performance and a more stable 
experience.

* I might try this again now that more work has been on of btrfs and XFS. 
Those interested in file systems might wish to have a look at a couple of 
presentations on these at a recent Australian Linux conference:

"I Can't Believe This is Butter! A tour of btrfs. - Avi Miller"

http://www.youtube.com/watch?v=hxWuaozpe2I

"XFS: Recent and Future Adventures in Filesystem Scalability - Dave 
Chinner"

http://www.youtube.com/watch?v=5XDTQLa3NjE

Be ready with the pause button for these videos, as the video editor had 
the unfortunate tendency to switch away from the slides before the 
speaker had got to every point.

And to get the best enjoyment out of the XFS one, do watch the btrfs one 
first so that you understand the bit at the end where he criticies btrfs 
performance :-)

-- 
Paul Sture
0
Reply paul303 (1382) 3/27/2012 5:41:44 PM

On Tue, 27 Mar 2012 17:23:10 +0200, Johnny Billquist wrote:

> I think it has a lot of relevance if your "bare metal" actually
> introduce a non-deterministic middle layer to your emulation.
> 
> The bare metal actually, by definition, do not have this property. So I
> would expect something that runs on the bare metal to retain that
> property, which to some is a very much wanted property. By falsely
> claiming that a product is running on the bare metal, when it actually
> is running on top of an operating system, they are in fact doing false
> marketing, and implicitly claim properties of their system which they
> can not back up.
> 
> "Bare metal" is not just a word... It *means* something.

Yes, as I pointed out in my other post, my evaluation of VMware 
Workstation demonstrated that it introduced substantial amounts of paging 
activity which brought my system to its knees.  Someone told me it was 
possible to switch this off, but only after my evaluation period had 
finished. :-(



-- 
Paul Sture
0
Reply paul303 (1382) 3/27/2012 5:46:25 PM

On 3/26/2012 5:17 PM, JF Mezei wrote:
> Also, out of curiosity, would Tandem customers really want to take 4
> different cabinets with 4 CPUs each and merge them into a single Class
> blade system with all 16 processors in one box ?  Seems to me that
> having all their eggs in one blade enclosure seems more risky than
> having at least 2 separate systems.

Multiple boxes can be linked together with ServerNet, so just like an 
OpenVMS Cluster customer might want to have at least two chassis for 
redundancy, a NonStop customer could have multiple chassis.

0
Reply keithparris_deletethis (241) 3/27/2012 6:21:37 PM

On 2012-03-27 18.12, Jan-Erik Soderholm wrote:
> Johnny Billquist wrote 2012-03-27 17:23:
>> On 2012-03-27 16.23, Jan-Erik Soderholm wrote:
>>> Bob Koehler wrote 2012-03-27 17:49:
>>>> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik
>>>> Soderholm<jan-erik.soderholm@telia.com> writes:
>>>>>
>>>>> But Linux runs on "bare metal". And if that part is builtin in
>>>>> whatever
>>>>> the developer calles "the product", then what ? Doesn't "the product"
>>>>> then
>>>>> run on "bare metal"? Yes, one component of "the product" is some parts
>>>>> usualy called "Linux", but so what ? Why should the customer/user
>>>>> care ?
>>>>
>>>> Because the Linux kernel can't handle some of the hard real-time
>>>> applications that the user might have.
>>>>
>>>
>>> But that is a completly different question.
>>> It has nothing to do with the "bare metall" discussion.
>>
>> I think it has a lot of relevance if your "bare metal" actually
>> introduce a
>> non-deterministic middle layer to your emulation.
>>
>> The bare metal actually, by definition, do not have this property. So I
>> would expect something that runs on the bare metal to retain that
>> property,
>> which to some is a very much wanted property. By falsely claiming that a
>> product is running on the bare metal, when it actually is running on
>> top of
>> an operating system, they are in fact doing false marketing, and
>> implicitly
>> claim properties of their system which they can not back up.
>>
>> "Bare metal" is not just a word... It *means* something.
>>
>> Johnny
>>
>
> Windows runs on "bare metal", still many would claim that Windows
> is non-deterministic.

*Exactly* Which is why you would not want a product like a machine 
emulator running on Windows (or Linux, which have the same problem), and 
then have someone claim it runs on bare metal, which is not 
non-deterministic.

> I could easily write some simple code that runs on "bare metal"
> that would be (by design!) *very* non-deterministic... :-)

Right. Not a problem at all. It is the opposite which is the problem, 
and which you cannot do. And which is why running the emulator on top of 
an OS instead of on the bare metal is a bad idea, for some.

> No, the only thing rellevant here is if you need to add any software
> yourself (such as an "OS") before installing the actual "product".

No. You are even missing your own point.

	Johnny
0
Reply bqt2 (1410) 3/27/2012 7:01:19 PM

On Tue, 27 Mar 2012 10:41:59 -0600, Keith Parris wrote:

> On 3/24/2012 11:40 PM, JF Mezei wrote:
>> SimH causes one core of an x86 to run at 100% all the time to emulate
>> the vax.  A Mac Pro computer running at 100% consumes about as much
>> power as a DS10L.
>>
>> If SimH could "capture" the idle loop and sleep the process instead,
>> then power consumption might be down, but not that much.
> 
> SimH can detect the idle loop and throttle back. Hoff has a great
> write-up on this at http://labs.hoffmanlabs.com/node/931

I have just added a comment to that topic:

http://labs.hoffmanlabs.com/node/931#comment-2766

My findings so far indicate that VAX/VMS will only use 12-14% of a twin 
cpu Pentium 4 when running under SIMH and Linux and the full complement 
of Hobbyist software (OK, when just sitting at the DCL prompt).

It's a far cry from when I was using prior versions of SIMH on an iBook 
or PowerBook and hearing the fans rev up due to 95+ percent CPU usage :-)


-- 
Paul Sture
0
Reply paul303 (1382) 3/27/2012 8:31:51 PM

In article <jksihn$5ho$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> Bob Koehler wrote 2012-03-27 17:49:
>> In article<jkqkjv$p1i$1@news.albasani.net>, Jan-Erik Soderholm<jan-erik.soderholm@telia.com>  writes:
>>>
>>> But Linux runs on "bare metal". And if that part is builtin in whatever
>>> the developer calles "the product", then what ? Doesn't "the product" then
>>> run on "bare metal"? Yes, one component of "the product" is some parts
>>> usualy called "Linux", but so what ? Why should the customer/user care ?
>>
>>     Because the Linux kernel can't handle some of the hard real-time
>>     applications that the user might have.
>>
> 
> But that is a completly different question.
> It has nothing to do with the "bare metall" discussion.

    OK, that makes as much sense as mush.  How can a problem caused by
    not truely running on bare metal not be relavent to a discussion of
    what "bare metal" really means?

0
Reply koehler2 (8314) 3/30/2012 1:24:14 AM

In article <jksot0$iv0$1@news.albasani.net>, Jan-Erik Soderholm <jan-erik.soderholm@telia.com> writes:
> 
> Windows runs on "bare metal", still many would claim that Windows
> is non-deterministic.

   It is always possible to write non-deterministic code on top of
   a bare metal, or on top of a deterministic OS.

   It is not possible to write deterministic code on top of a
   non-deterministic OS, micro-kernel, or othr software layer.

0
Reply koehler2 (8314) 4/2/2012 3:20:22 PM

Le Tue, 20 Mar 2012 11:22:29 +0100,
Michael Kraemer <M.Kraemer@gsi.de> écrivait :
> JF Mezei schrieb:
>
>> 
>> At some point, HP decided to not port to x86.
>> 
>
> According to what I've read,
> there was no customer demand for it.
>
>
>> 
>> Looks to me that once HP decided to end of line its proprietary OS at
>> same time as IA64, there was no point in keeping the experienced
>> engineering teams since they wouldn't be needed for the port.
>> 
>> I fear it may be too late to save VMS.
>
> well, iirc, the source listing is available,
> so feel free to start your own skunkworks project.

	I'm not sure that's a good idea. If I have to write an OpenVMS-like
	system, I'll start from a microkernel like L4... With this
	microkernel, you can emulate all protection levels you want and your
	OS is portable.

	Regards,

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/11/2012 11:41:14 AM

In article <slrnjqpumo.snv.jkb@rayleigh.systella.fr>, JKB <jkb@koenigsberg.invalid> writes:
>Le Tue, 20 Mar 2012 11:22:29 +0100,
>Michael Kraemer <M.Kraemer@gsi.de> écrivait :
>> JF Mezei schrieb:
>>
>>> 
>>> At some point, HP decided to not port to x86.
>>> 
>>
>> According to what I've read,
>> there was no customer demand for it.
>>
>>
>>> 
>>> Looks to me that once HP decided to end of line its proprietary OS at
>>> same time as IA64, there was no point in keeping the experienced
>>> engineering teams since they wouldn't be needed for the port.
>>> 
>>> I fear it may be too late to save VMS.
>>
>> well, iirc, the source listing is available,
>> so feel free to start your own skunkworks project.
>
>	I'm not sure that's a good idea. If I have to write an OpenVMS-like
>	system, I'll start from a microkernel like L4... With this
>	microkernel, you can emulate all protection levels you want and your
>	OS is portable.
>
>	Regards,
>
>	JKB
>
>-- 
>Si votre demande me parvient sur carte perforée, je titiouaillerai très
>volontiers une réponse...
>=> http://grincheux.de-charybde-en-scylla.fr

Then it won't be VMS!

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 5/11/2012 10:05:28 PM

JF Mezei wrote :
> Was thinking about the Oracle allegations against HP.
>
> HP did have plans to port HP-UX to x86 and started the work.
> And I have been told that porting of VMS to x86 had also been started.
>
> Neither of which would have been official projects since they couldn't
> appear in any books since HP wanted very much to hide the fact that
> IA64'S EOL was aready planned.
>
>
> At some point, HP decided to not port to x86.
>
> Then, VMS experienced engineering team is fired and replaced by newbie
> programmers given 2 weeks of training.
>
> Looks to me that once HP decided to end of line its proprietary OS at
> same time as IA64, there was no point in keeping the experienced
> engineering teams since they wouldn't be needed for the port.
>
> I fear it may be too late to save VMS.

Rather than porting the entire operating system, would it not be
much more efficient to just port HPVM to X86, and then let OVMS
and HPUX run on top of that ? Once the Odyssey project will give
its first results, will we have a robust enough environment to
propose it in combination with HPVM ported to X86 to replace the
Itanium hardware ?

-- 
Marc Van Dyck


0
Reply marc.gr.vandyck (64) 5/11/2012 10:19:10 PM

Marc Van Dyck wrote 2012-05-12 00:19:
> JF Mezei wrote :
>> Was thinking about the Oracle allegations against HP.
>>
>> HP did have plans to port HP-UX to x86 and started the work.
>> And I have been told that porting of VMS to x86 had also been started.
>>
>> Neither of which would have been official projects since they couldn't
>> appear in any books since HP wanted very much to hide the fact that
>> IA64'S EOL was aready planned.
>>
>>
>> At some point, HP decided to not port to x86.
>>
>> Then, VMS experienced engineering team is fired and replaced by newbie
>> programmers given 2 weeks of training.
>>
>> Looks to me that once HP decided to end of line its proprietary OS at
>> same time as IA64, there was no point in keeping the experienced
>> engineering teams since they wouldn't be needed for the port.
>>
>> I fear it may be too late to save VMS.
>
> Rather than porting the entire operating system, would it not be
> much more efficient to just port HPVM to X86, and then let OVMS
> and HPUX run on top of that ? Once the Odyssey project will give
> its first results, will we have a robust enough environment to
> propose it in combination with HPVM ported to X86 to replace the
> Itanium hardware ?
>

HPVM is, as far as I know, not an emulator. If HPVM would run
on X86, the guest OS'es would also need to be X86 versions.

0
Reply jan-erik.soderholm (2673) 5/11/2012 10:54:02 PM

Jan-Erik Soderholm wrote:

> HPVM is, as far as I know, not an emulator. If HPVM would run
> on X86, the guest OS'es would also need to be X86 versions.

The emulator company that wrote Rosetta for Apple (which did on-the-fly
endian conversion at run time for big endian OS-X PowerPC to little
endian OS-X on x86)  was purchased by... IBM .


So HP would have to write its own IA64 emulator with endian conversion
to support HP-UX on x86.  Hopefully that emulator could also run VMS in
little endian mode.

While this is good for "maintenance mode" operating systems, it isn't
really suited for on-going concerns because HP would still have to
write/update compilers for IA64 and not be able to benefit from fine
tuning on x86, and folks like Oracle would still have to write for
Itanium platform, something they don't want to do because Itanium is dead.


However, the plan is to allow IA64 and X86 blades to co-exist in the
same chassis. So your legacy apps can run on an IA64 blade while your
port/develop them on x86 blades and once ready, you just switch them to
the new environment in the same cabinet.

I suspect Odyssey will have hardware based partitioning to allow
different architectures and totally separate instances to co-exist
without needing HPVM.
0
Reply jfmezei.spamnot (9469) 5/11/2012 11:24:58 PM

JF Mezei wrote:
> Jan-Erik Soderholm wrote:
> 
>> HPVM is, as far as I know, not an emulator. If HPVM would run
>> on X86, the guest OS'es would also need to be X86 versions.
> 
> The emulator company that wrote Rosetta for Apple (which did on-the-fly
> endian conversion at run time for big endian OS-X PowerPC to little
> endian OS-X on x86)  was purchased by... IBM .
> 
> 
> So HP would have to write its own IA64 emulator with endian conversion
> to support HP-UX on x86.  Hopefully that emulator could also run VMS in
> little endian mode.
> 
> While this is good for "maintenance mode" operating systems, it isn't
> really suited for on-going concerns because HP would still have to
> write/update compilers for IA64 and not be able to benefit from fine
> tuning on x86, and folks like Oracle would still have to write for
> Itanium platform, something they don't want to do because Itanium is dead.
> 
> 
> However, the plan is to allow IA64 and X86 blades to co-exist in the
> same chassis. So your legacy apps can run on an IA64 blade while your
> port/develop them on x86 blades and once ready, you just switch them to
> the new environment in the same cabinet.
> 
> I suspect Odyssey will have hardware based partitioning to allow
> different architectures and totally separate instances to co-exist
> without needing HPVM.

Why not just have everybody sue Intel out of business ?

Surely their plan to do away with competitive CPUs has caused harm.

Perhaps my AMD stock would finally pay off ....
0
Reply davef3 (3717) 5/12/2012 5:59:26 AM

Le Fri, 11 May 2012 22:05:28 GMT,
VAXman-  @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> écrivait :
>
> Then it won't be VMS!

	Maybe. But alpha is dead and IA64 has no future. If you want use
	OpenVMS in next years, you only have two choices :
	- opensourcing OpenVMS (why not, but I'm not sure that HP shall give
	  OpenVMS sources without restrictions) ;
	- waiting for OpenVMS on amd64 (I'm not sure that HP want to port
	  VMS).

	Thirsd solution : trying to write your own version.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/14/2012 10:15:34 AM

In article <mn.60137dc5b0df2a03.104627@invalid.skynet.be>, Marc Van Dyck <marc.gr.vandyck@invalid.skynet.be> writes:
> 
> Rather than porting the entire operating system, would it not be
> much more efficient to just port HPVM to X86, and then let OVMS
> and HPUX run on top of that ? Once the Odyssey project will give
> its first results, will we have a robust enough environment to
> propose it in combination with HPVM ported to X86 to replace the
> Itanium hardware ?

   If you don't do enough port to get the OS running in the native
   instruction set, then performance is crap.

   And the easiest way to get that much port done is first port the
   thing to the hardware.  VMS doesn't have a lot of code to support
   sitting on HPVM instead of naked Itanium, and doesn't have a
   lot of dead code in that environment, either.

0
Reply koehler2 (8314) 5/14/2012 1:26:09 PM

In article <slrnjr1mq4.1nb.jkb@rayleigh.systella.fr>, JKB
<jkb@koenigsberg.invalid> writes: 

> 	Maybe. But alpha is dead and IA64 has no future. If you want use
> 	OpenVMS in next years, you only have two choices :
> 	- opensourcing OpenVMS (why not, but I'm not sure that HP shall give
> 	  OpenVMS sources without restrictions) ;

HP certainly won't, and a big advantage of VMS---its uniform
design---will probably be lost since not all coders will have the 
knowledge/time/resources to follow it.

> 	- waiting for OpenVMS on amd64 (I'm not sure that HP want to port
> 	  VMS).

I would be surprised, but not overly so, if this happens.

> 	Thirsd solution : trying to write your own version.

Not practical.

Fourth solution: Continue to use what you've got.

0
Reply helbig (5067) 5/14/2012 8:33:20 PM

For the past 3 months I have been involved in cleaning up a number
(10) of virtualized VAXs. I don't know why everyone uses the term
"virtualized" because these platforms are running on the Charon-VAX
emulation which runs on x86 (well, really the XEON flavor as part of
DL380 but I digress).

p.s. according to the contractors, my employer is running more than 25
of these things

Don't get me wrong, the disk i/o on these beasts is incredibly fast.
And there is something neat about doing a VMS standalone backup
(shutdown VMS; shut down Charon-VAX; then duplicate a Windows-2003
folder by just dragging and dropping). Doing any disk backup or
restore just takes seconds.

But the CPU power is horrible. For example, generating a new set of
1024-bit DSA keys takes 5 minutes on this emulated uVAX-4300 while
less than one second is required on my DS20e Alpha.

Once you buy Charon keys (rumored to be in the range of 8k each; HP is
a authorized reseller so they get a cut); ILO licenses for the CPUs
and SANs; Windows licenses; VMS transfer licenses; the all-in costs of
doing something like this is not cheap.

Why am I saying all this? It seems to me that HP thinks they can keep
OpenVMS alive by selling Charon-VAX and Charon-Alpha emulations (while
making a buck on the side) rather than doing a native x86 port (as it
appears they have done with HP-UX).

This emulation/virtualization technology is not that easy to manage in
a large enterprise as you would think.  In the old days there was only
one group responsible; now there are three (one group is responsible
for all Windows issues; another for the Charon environment; and a
third for VMS).

The whole experience has left me with the feeling of dead-technology-
walking.

If I were HP, I'd have the skunk-works in India working on an x86 port
right now.

Neil Rieck
Kitchener / Waterloo / Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
0
Reply n.rieck (2007) 5/24/2012 12:36:15 AM

Neil Rieck wrote:

> If I were HP, I'd have the skunk-works in India working on an x86 port
> right now.

Thyey tried this a few years ago but those skunkworks which also
involved HP-UX were killed because moving HP=UX to x86 would be too much
of an effort.

With regards to running VMS in emulation. VAX-VMS is over 10 years old
at 7.3. Not developped anymore. And Alpha/IA64 is barely being
maintained/developped anymore. About the only commitment from HP is to
make it run on the upcoming Poulson and Kittson platforms.

So even if you can continue to run VMS on emulated environments, you are
still limited to whatever VMS version and software are available.
0
Reply jfmezei.spamnot (9469) 5/24/2012 6:59:48 AM

Le Thu, 24 May 2012 02:59:48 -0400,
JF Mezei <jfmezei.spamnot@vaxination.ca> écrivait :
> Neil Rieck wrote:
>
>> If I were HP, I'd have the skunk-works in India working on an x86 port
>> right now.
>
> Thyey tried this a few years ago but those skunkworks which also
> involved HP-UX were killed because moving HP=UX to x86 would be too much
> of an effort.
>
> With regards to running VMS in emulation. VAX-VMS is over 10 years old
> at 7.3. Not developped anymore. And Alpha/IA64 is barely being
> maintained/developped anymore. About the only commitment from HP is to
> make it run on the upcoming Poulson and Kittson platforms.
>
> So even if you can continue to run VMS on emulated environments, you are
> still limited to whatever VMS version and software are available.

	Right. I think it's really time to know if we want to assist to VMS
	death or if we want to do somethink to keep VMS alive. Even if VMS
	is a fabulous OS, its design has to be changed. A long time ago, Dec
	has started to port VMS on a microkernel (VMS-O-Mach) and I'm sure
	that if VMS has today still future, it has to be rewritten over a
	microkernel. It's time to drop Bliss and some strange languages to
	write VMS as servers (written in C, ADA or all language you want)
	on top of a real microkernel (not Mach, but L4 for example).

	But VMS is dying also as porting Unix application to VMS is not
	simple. If you want to propose a lot of softwares, you cannot ignore
	Unix and VMS should have a real POSIX/SysV libc like newlib.

	Regards,

	JKB

-- 
http://www.freevms.net
0
Reply jkb (86) 5/24/2012 10:05:15 AM

On May 24, 2:59=A0am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Neil Rieck wrote:
> > If I were HP, I'd have the skunk-works in India working on an x86 port
> > right now.
>
> Thyey tried this a few years ago but those skunkworks which also
> involved HP-UX were killed because moving HP=3DUX to x86 would be too muc=
h
> of an effort.
>
> With regards to running VMS in emulation. VAX-VMS is over 10 years old
> at 7.3. Not developped anymore. And Alpha/IA64 is barely being
> maintained/developped anymore. About the only commitment from HP is to
> make it run on the upcoming Poulson and Kittson platforms.
>
> So even if you can continue to run VMS on emulated environments, you are
> still limited to whatever VMS version and software are available.

Agreed. But all this was sold to an unsuspecting customer (my
employer) with the claim "buy this x86 platform and emulator then you
won't need to risk upgrading to a higher VMS version" (the department
owning these systems is still paying annual prior version support!!!)

The real joke here is this:
1) we are in possession of all the source code
2) there is VMS/OpenVMS talent elsewhere in the company
3) there are real Alpha and Itanium systems elsewhere running
OpenVMS-8.x

NSR
0
Reply n.rieck (2007) 5/24/2012 10:44:16 AM

One final thought,

If it is true that HP-UX has been ported to x86 and VMS has not (or
will not), then it is true that VMS suffers the same fate as "the red-
headed step-child".

1) HP-UX was fathered by HP.
2) VMS was fathered by DEC.
3) Like an unwanted step-child, VMS was adopted by Compaq then later
by HP.
(HP really didn't want VMS; it just came with the acquisition)

The reg article about how HP was "thinking about acquiring SPARC/
Solaris" indicates (to me) that HP saw more value in Solaris then they
did in VMS (although in the end, HP insiders may have given special
treatment to HP-UX)

http://bit.ly/LED7hd

Just my 2-cents worth.

NSR
0
Reply n.rieck (2007) 5/24/2012 11:02:42 AM

In article <4fbddc69$0$24761$c3e8da3$e408f015@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> So even if you can continue to run VMS on emulated environments, you are
> still limited to whatever VMS version and software are available.

   Limitted to continue using a VMS version that continues to work?
   Not seen as a problem.

   Limitted to software that is available?  Not as long as the compilers
   don't wear out.

   Gee, I've never seen software wear out.

0
Reply koehler2 (8314) 5/24/2012 2:05:48 PM

JKB wrote:

> 	Right. I think it's really time to know if we want to assist to VMS
> 	death or if we want to do somethink to keep VMS alive. 


It isnt our business to do either. VMS is a commercial product entirely
owned by HO at the moment. HP is the one to assist its death or do
something to keep it alive.

We can't change HP's mind on this.  VMS is small compared to whatever
conracts HP has signed with Intel and HP isn't going to change those to
please VMS enthousiasts.

The only aspect the community can do is convince HP to announce it will
open source VMS on the day it announces the end of the line for iA64 VMS
and HP-UX.


Yes, it would have been nice if VMS had been onwed by a company whose
survival depended on the success of VMS because you would have then seen
that company market, price and develop VMS to compete and grow. But this
is now the case and it is entirely out of our hands.

Now, if HP were to come to us and ask us what would be needed to bring
VMS back to life, then our opinions would count. But that's not gonna
happen.
0
Reply jfmezei.spamnot (9469) 5/24/2012 5:35:33 PM

Le Thu, 24 May 2012 13:35:33 -0400,
JF Mezei <jfmezei.spamnot@vaxination.ca> écrivait :
> JKB wrote:
>
>> 	Right. I think it's really time to know if we want to assist to VMS
>> 	death or if we want to do somethink to keep VMS alive. 
>
>
> It isnt our business to do either. VMS is a commercial product entirely
> owned by HO at the moment. HP is the one to assist its death or do
> something to keep it alive.
>
> We can't change HP's mind on this.  VMS is small compared to whatever
> conracts HP has signed with Intel and HP isn't going to change those to
> please VMS enthousiasts.
>
> The only aspect the community can do is convince HP to announce it will
> open source VMS on the day it announces the end of the line for iA64 VMS
> and HP-UX.
>

	And what ? Even if OpenVMS will be opensourced, you have to write
	Bliss and macro compilers and you have to rewrite all low level
	routines to support a new architecture (for example x86 or Power).

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/24/2012 6:27:57 PM

JKB wrote:

> 	And what ? Even if OpenVMS will be opensourced, you have to write
> 	Bliss and macro compilers and you have to rewrite all low level
> 	routines to support a new architecture (for example x86 or Power).


Huff will be able to do all that on a rainy afternoon. :-)
0
Reply jfmezei.spamnot (9469) 5/24/2012 6:37:27 PM

JKB wrote:
> Le Thu, 24 May 2012 02:59:48 -0400,
> JF Mezei <jfmezei.spamnot@vaxination.ca> écrivait :
>> Neil Rieck wrote:
>>
>>> If I were HP, I'd have the skunk-works in India working on an x86 port
>>> right now.
>> Thyey tried this a few years ago but those skunkworks which also
>> involved HP-UX were killed because moving HP=UX to x86 would be too much
>> of an effort.
>>
>> With regards to running VMS in emulation. VAX-VMS is over 10 years old
>> at 7.3. Not developped anymore. And Alpha/IA64 is barely being
>> maintained/developped anymore. About the only commitment from HP is to
>> make it run on the upcoming Poulson and Kittson platforms.
>>
>> So even if you can continue to run VMS on emulated environments, you are
>> still limited to whatever VMS version and software are available.
> 
> 	Right. I think it's really time to know if we want to assist to VMS
> 	death or if we want to do somethink to keep VMS alive. Even if VMS
> 	is a fabulous OS, its design has to be changed. A long time ago, Dec
> 	has started to port VMS on a microkernel (VMS-O-Mach) and I'm sure
> 	that if VMS has today still future, it has to be rewritten over a
> 	microkernel. It's time to drop Bliss and some strange languages to
> 	write VMS as servers (written in C, ADA or all language you want)
> 	on top of a real microkernel (not Mach, but L4 for example).
> 
> 	But VMS is dying also as porting Unix application to VMS is not
> 	simple. If you want to propose a lot of softwares, you cannot ignore
> 	Unix and VMS should have a real POSIX/SysV libc like newlib.
> 
> 	Regards,
> 
> 	JKB
> 

I do not share this perspective.  Not saying which if either is a better perspective.  As 
for Bliss, I have little experience working with it, but it seems to be adequate.  If 
there is a Bliss compiler, what is the problem?

The language I'd prefer to drop is C, but that's just personal preference, which is what I 
consider the above suggestion.

VMS does not have to look and feel like Unix in order to be successful.  If that were the 
goal, then why not just use Unix?

What VMS needs is a viable hardware platform, good implementations of current 
capabilities, and continued development of new capabilities as they come into use.
0
Reply davef3 (3717) 5/24/2012 7:55:37 PM

JF Mezei wrote:
> JKB wrote:
> 
>> 	Right. I think it's really time to know if we want to assist to VMS
>> 	death or if we want to do somethink to keep VMS alive. 
> 
> 
> It isnt our business to do either. VMS is a commercial product entirely
> owned by HO at the moment. HP is the one to assist its death or do
> something to keep it alive.

Well, there are various ways to look at such.  One is, when a company sells systems with 
VMS for customers to use, there is at least a moral commitment being made.  The customers 
don't just plug in a computer and gaze at it.  They develop or purchase applications to do 
the work they need performed.  There are a number of things that fit together to make the 
whole.

Now companies that do not hold to moral commitments seem to not do well.  It's a 2 way 
street.  The customers pay for the products.  The producer needs to also support the 
customer's needs, which the producer originally created.

> We can't change HP's mind on this.  VMS is small compared to whatever
> conracts HP has signed with Intel and HP isn't going to change those to
> please VMS enthousiasts.

It is NOT enthusiasts that need to be pleased.  It is the customers that have kept the 
provider in business by purchasing products that need to continue to be supported.  To 
think that a company can continue to retain customers without adequately supporting their 
needs is sort of unrealistic.  If you've fooled me once, why should I give you the 
opportunity to foll me again?

> The only aspect the community can do is convince HP to announce it will
> open source VMS on the day it announces the end of the line for iA64 VMS
> and HP-UX.
> 
> 
> Yes, it would have been nice if VMS had been onwed by a company whose
> survival depended on the success of VMS because you would have then seen
> that company market, price and develop VMS to compete and grow. But this
> is now the case and it is entirely out of our hands.

Yeah, well not always.  There was G.Q. Palmer ....

Talk about not believing in your products ....

> Now, if HP were to come to us and ask us what would be needed to bring
> VMS back to life, then our opinions would count. But that's not gonna
> happen.

See, that is one of the fallacies.  VMS is still alive, there is no need to "bring VMS 
back to life".  What's needed is adequate support to continue life.  The perception that 
such is not forthcoming is what will kill VMS.
0
Reply davef3 (3717) 5/24/2012 8:10:15 PM

Le Thu, 24 May 2012 15:55:37 -0400,
David Froble <davef@tsoft-inc.com> écrivait :
> JKB wrote:
>> Le Thu, 24 May 2012 02:59:48 -0400,
>> JF Mezei <jfmezei.spamnot@vaxination.ca> écrivait :
>>> Neil Rieck wrote:
>>>
>>>> If I were HP, I'd have the skunk-works in India working on an x86 port
>>>> right now.
>>> Thyey tried this a few years ago but those skunkworks which also
>>> involved HP-UX were killed because moving HP=UX to x86 would be too much
>>> of an effort.
>>>
>>> With regards to running VMS in emulation. VAX-VMS is over 10 years old
>>> at 7.3. Not developped anymore. And Alpha/IA64 is barely being
>>> maintained/developped anymore. About the only commitment from HP is to
>>> make it run on the upcoming Poulson and Kittson platforms.
>>>
>>> So even if you can continue to run VMS on emulated environments, you are
>>> still limited to whatever VMS version and software are available.
>> 
>> 	Right. I think it's really time to know if we want to assist to VMS
>> 	death or if we want to do somethink to keep VMS alive. Even if VMS
>> 	is a fabulous OS, its design has to be changed. A long time ago, Dec
>> 	has started to port VMS on a microkernel (VMS-O-Mach) and I'm sure
>> 	that if VMS has today still future, it has to be rewritten over a
>> 	microkernel. It's time to drop Bliss and some strange languages to
>> 	write VMS as servers (written in C, ADA or all language you want)
>> 	on top of a real microkernel (not Mach, but L4 for example).
>> 
>> 	But VMS is dying also as porting Unix application to VMS is not
>> 	simple. If you want to propose a lot of softwares, you cannot ignore
>> 	Unix and VMS should have a real POSIX/SysV libc like newlib.
>> 
>> 	Regards,
>> 
>> 	JKB
>> 
>
> I do not share this perspective.  Not saying which if either is a better perspective.  As 
> for Bliss, I have little experience working with it, but it seems to be adequate.  If 
> there is a Bliss compiler, what is the problem?
>
> The language I'd prefer to drop is C, but that's just personal preference, which is what I 
> consider the above suggestion.
>
> VMS does not have to look and feel like Unix in order to be successful.  If that were the 
> goal, then why not just use Unix?

	I agree. But new softwares are written for Windows or Unix, not for
	VMS. Thus, a decent libc is required if you want to keep VMS alive.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/24/2012 8:21:36 PM

On Thu, 24 May 2012 13:35:33 -0400, JF Mezei
<jfmezei.spamnot@vaxination.ca> wrote:

>JKB wrote:
>
>> 	Right. I think it's really time to know if we want to assist to VMS
>> 	death or if we want to do somethink to keep VMS alive. 
>
>
>It isnt our business to do either. VMS is a commercial product entirely
>owned by HO at the moment. HP is the one to assist its death or do
>something to keep it alive.
>
>We can't change HP's mind on this.  VMS is small compared to whatever
>conracts HP has signed with Intel and HP isn't going to change those to
>please VMS enthousiasts.
>
>The only aspect the community can do is convince HP to announce it will
>open source VMS on the day it announces the end of the line for iA64 VMS
>and HP-UX.
>
>Yes, it would have been nice if VMS had been onwed by a company whose
>survival depended on the success of VMS because you would have then seen
>that company market, price and develop VMS to compete and grow. But this
>is now the case and it is entirely out of our hands.
>
>Now, if HP were to come to us and ask us what would be needed to bring
>VMS back to life, then our opinions would count. But that's not gonna
>happen.

"They can't abide the cold steel, sir! no, sir! They don't like it
  up 'em."

-- Lance Corporal Jack Jones (The local butcher), �Dad�s Army�

Call me a sentimental old fool (guilty as charged!).

But let us assume, for argument's sake, that Meg Whitman is a
innocent, a "clean hands", naive about the sheer inherent quality and
potential of the VMS asset on the HP books - that she is not (yet) a
"Lady Macbeth" in relation to VMS. Rather that she is currently a
"Desdemona" badly advised on VMS by myriad "Iago"s in senior HP
management, for any number of reasons foul.

Then how do you properly brief her and how do you ensure that
everybody knows that she is properly briefed and she knows that
everybody knows she has been properly briefed, without anyone losing
face?

Construct a formal, dry, sober, comprehensive and immaculate
Memoradum, clean of any (so called) "VMS Mysticism" then publish it on
a dedicated website and then also send her a printed copy.

http://en.wikipedia.org/wiki/Memorandum
http://courses.washington.edu/affhsg/pdf/memoonmemos.pdf

Even if you are a moping no-hoping nay-sayer about the future of VMS,
put your melancholy to the side, or send it on a holiday, and give it
your best shot.

Rather than opening a specific thread and incrementally developing
such a Memorandum, I would suggest instead initially opening a
dedicated thread devoted to fleshing out topics and subtopics that
need to be addressed in any such Memorandum, and try to avoid
discussing the substance and content of each topic and sub-topic as
much as possible.

Then a two week development period is declared and a nominated
delivery date defined, and the comp.os collegiate then retire to their
man-caves, dens, skunkworks cellars, backyard sheds, garages or
machine rooms and then compose their own version of such a Memorandum,
to the best of their abilities, experience and expertise. 

(People could also inform their networks of digits from VMS
Engineering or otherwise that still hold a candle for VMS, inviting
them to muck in, too, NDA's signed should not be a gaffer-tape
impediment to so mucking in.)

Upon the nominated date a new dedicated thread is opened where people
publish their version of such a Memorandum and no commentary is
allowed in the thread - it is *strictly* for collection.

After that, it is then discussed how to go about the business of
compiling a master Memorandum. Plain text or source code, same diff,
whack it into a collaborative RCS/VCS, agree on some sort of editorial
committee to compile and edit it all into order and let it rip.

Once the master Memorandum is matured and stabilised, a dedicated
website is established, and word is put out inviting people to put
their names, ranks and serial numbers, extant or emeritus, to it in
support. Also effort it put into making sure that the CEO's of all the
known business customers of VMS are informed of the Memorandum's
existence, inviting them to put their or their business entity's name
to the Memorandum as well.

(It would not hurt notifying the major long-term investors in HP were
notified also)

[Dilatory side: is it not time that Vernon had a Facebook page?]

As everyone is well aware, the 25th of October 2012 is the 35th
anniversary of the mighty VMS operating system, is comp.os.vms going
to celebrate that with a whimper or a roar?

http://www.poets.org/viewmedia.php/prmMID/15377
http://poetry.poetryx.com/poems/784/

Hell, it's something noble and worthy to do besides fussing over the
grand-children and you would be doing it for their benefit anyway.

VMS is part of their intellectual heritage and conceptual literacy in
the commonweath of computer science, the most immaculate, logical,
systematic, disciplined, and literate culture and "vade mecum" about
how to go about the business of computing at every level of operating
system function, that has ever been devised, it is a glory and
testament to wo/man's ingenuity.

Do you want them to inherit a world which is essentially a dreary,
dire, conceptually retarded, monoculture of Microsoft operating
systems with a bit of GNU/Linux (not half bad I must admit, but not a
patch on VMS) on the side, in which to scratch out a living from
matters computing?

I say give such a future a resounding Bronx cheer.

[Danger! Danger! Will Robinson - you are veering into "VMS Mysticism"
- Ed.]

Ok, call me a slightly unhinged sentimental old fool.

But is it the kernel of a Plan? - has it got moxie?

What say you gentlemen (and Ruth if she is kibitzing on comp.os.vms)?

if not, think of something better and do it quickly.

Semper VMS - In VMS We Trust.
_________________________________________________________
Otter: Bluto's right. Psychotic, but absolutely right. We gotta take
       these bastards. Now we could do it with conventional weapons.
       But that could take years and cost millions of lives. No, I
       think we have to go all out. I think that this situation
       absolutely requires a really futile and stupid gesture be done
       on somebody's part. 
Bluto: We're just the guys to do it. (Animal House)
0
Reply vlf (63) 5/25/2012 1:47:27 AM

On May 24, 7:02=A0am, Neil Rieck <n.ri...@sympatico.ca> wrote:
> One final thought,
>
> If it is true that HP-UX has been ported to x86 and VMS has not (or
> will not), then it is true that VMS suffers the same fate as "thered-head=
edstep-child".
>
> 1) HP-UX was fathered by HP.
> 2) VMS was fathered by DEC.
> 3) Like an unwanted step-child, VMS was adopted by Compaq then later
> by HP.
> (HP really didn't want VMS; it just came with the acquisition)
>
> The reg article about how HP was "thinking about acquiring SPARC/
> Solaris" indicates (to me) that HP saw more value in Solaris then they
> did in VMS (although in the end, HP insiders may have given special
> treatment to HP-UX)
>
> http://bit.ly/LED7hd
>
> Just my 2-cents worth.
>
> NSR

Speaking of acquisitions, I was just over at the Oracle website
downloading a copy of Solaris-11 x86.
http://www.oracle.com/index.html

Man, this site is really cool. All major categories are all on one
page. No hunting around. Why can't HP do something like this? What are
the chances that you would ever see the words "OpenVMS", "HP-UX", and
"NonStop" all in the same location?

NSR
0
Reply n.rieck (2007) 5/25/2012 1:58:36 AM

On Fri, 25 May 2012 11:47:27 +1000, Subcommandante XDelta
<vlf@star.enet.dec.com> wrote:

:
>Construct a formal, dry, sober, comprehensive and immaculate
>Memoradum, clean of any (so called) "VMS Mysticism" then publish it on
>a dedicated website and then also send her a printed copy.
>
>http://en.wikipedia.org/wiki/Memorandum
>http://courses.washington.edu/affhsg/pdf/memoonmemos.pdf
>
>Even if you are a moping no-hoping nay-sayer about the future of VMS,
>put your melancholy to the side, or send it on a holiday, and give it
>your best shot.
:

PS: Gentleman, we have to earn our "lagered products" for the 25th
October 2012.

So why not work up a righteous, justified, thirst in the meantime? ;-)
0
Reply vlf (63) 5/25/2012 2:17:28 AM

Subcommandante XDelta wrote:

> But let us assume, for argument's sake, that Meg Whitman is a
> innocent, a "clean hands", naive about the sheer inherent quality and
> potential of the VMS asset on the HP books 


I believe it is John Egolf's job to ensure HP management know about the
potential of VMS. He and a couple of others are all that is left that
know about VMS' potential.

More importantly, those few very large customer who still rely on VMS
can call Whitman and ask to speak to her about VMS. The president of a
stock exchange has enough clout to get past Whitman's secretary and
admin assistants and get to speak or meet with her.


What Egolf could do is remind Whitman that while the pilot to evaluate
porting HP-UX showed such a project to be too expensive, porting VMS
would not be too expensive.

We know that HP employees are forbidden to discuss porting VMS to x86 to
the public, but Shirley, they can discuss it internally ?

Whitman inherited contracts and decisions that are past the point of no
return on IA64 and the operating systems.

Decimating VMS engineering was done because they knew there wouldn't be
much development left to be done on it. Same with HP-UX.  It would be
hard to reconstitute the experience that was there prior to the decimation.

So it is not an easy job for Whitman to overturn those decisions.
Overturning the "sell the PC division" was easy to do because nothing
had been done yet so there was really nothing to reverse. But in the
case of IA64 and VMS, much has already been done to make it past the
point of no return.

It still is possible to turn it around and save it, but it is getting
more and more difficult.


The best we could hope at this point would be using the VMS clustering
experience to develop "TrueCluster" for Linux which would be sold by HP
only.  (and porting of TPU to Linux and maybe OS-X, both of which
support X window)




0
Reply jfmezei.spamnot (9469) 5/25/2012 2:52:17 AM

Subcommandante XDelta wrote:

> PS: Gentleman, we have to earn our "lagered products" for the 25th
> October 2012.


I nominate Mr VAXman as official in charge of lagered products for that
occasion. He has plenty of experience with lagered products and has the
hardware and software to produce the good stuff.
0
Reply jfmezei.spamnot (9469) 5/25/2012 2:54:19 AM

Over the years we've watched companies like AMD reverse engineer the
x86 instruction set to produce a functionally similar x86 chip.
Likewise, companies like Compaq reverse engineered the PC (and BIOS)
to produce a functionally similar computer. In the past, big companies
charged big bucks for C compilers yet today every C programming course
instructs people to only use open-source compilers like GNU-C.

So why do people here always throw out BLISS as the reason why porting
VMS to x86 is not possible? After all, its only software. Software
patents have always been dubious but if there is a copyright on BLISS
then why not just reverse engineer it in C?

Just my 2-cents worth.

NSR
0
Reply n.rieck (2007) 5/25/2012 10:50:41 AM

In article
<75540c5c-cb05-4367-8936-a605e433c434@h10g2000yqn.googlegroups.com>,
Neil Rieck <n.rieck@sympatico.ca> writes: 

> Over the years we've watched companies like AMD reverse engineer the
> x86 instruction set to produce a functionally similar x86 chip.
> Likewise, companies like Compaq reverse engineered the PC (and BIOS)
> to produce a functionally similar computer. 

OK.

> In the past, big companies
> charged big bucks for C compilers yet today every C programming course
> instructs people to only use open-source compilers like GNU-C.

Several reasons for the change.  First, open-source stuff now exists 
in "reasonable" quality.  Cheap internet has made it possible to have 
such projects.  Second, hardware has become cheap and operating systems 
as well, led to some extent by "Wintel" stuff since one helped sell the 
other and high-volume low-margin was profitable.  So, paying, say, 2000 
for a compiler is a lot of money.  Back when the hardware cost several 
tens of thousands, the extra money for compilers was, seen as a fraction 
of the total cost, small.

> So why do people here always throw out BLISS as the reason why porting
> VMS to x86 is not possible? After all, its only software. Software
> patents have always been dubious but if there is a copyright on BLISS
> then why not just reverse engineer it in C?

Reverse-engineered might not be very efficient.

0
Reply helbig (5067) 5/25/2012 11:21:41 AM

On Fri, 25 May 2012 11:21:41 +0000, Phillip Helbig---undress to reply
wrote:

> In article
> <75540c5c-cb05-4367-8936-a605e433c434@h10g2000yqn.googlegroups.com>,
> Neil Rieck <n.rieck@sympatico.ca> writes:
> 
>> Over the years we've watched companies like AMD reverse engineer the
>> x86 instruction set to produce a functionally similar x86 chip.
>> Likewise, companies like Compaq reverse engineered the PC (and BIOS) to
>> produce a functionally similar computer.
> 
> OK.
> 
>> In the past, big companies
>> charged big bucks for C compilers yet today every C programming course
>> instructs people to only use open-source compilers like GNU-C.
> 
> Several reasons for the change.  First, open-source stuff now exists in
> "reasonable" quality.  Cheap internet has made it possible to have such
> projects.  Second, hardware has become cheap and operating systems as
> well, led to some extent by "Wintel" stuff since one helped sell the
> other and high-volume low-margin was profitable.  So, paying, say, 2000
> for a compiler is a lot of money.  Back when the hardware cost several
> tens of thousands, the extra money for compilers was, seen as a fraction
> of the total cost, small.

If you want to pay 2000 or more for a compiler you can.  See Microsoft's 
Visual Studio prices page:

http://bit.ly/KTiYi7

OK Visual Studio is more than just a compiler, but you get the idea.



-- 
Paul Sture
0
Reply paul.nospam (2164) 5/25/2012 12:48:16 PM

Le Fri, 25 May 2012 03:50:41 -0700 (PDT),
Neil Rieck <n.rieck@sympatico.ca> écrivait :
> Over the years we've watched companies like AMD reverse engineer the
> x86 instruction set to produce a functionally similar x86 chip.
> Likewise, companies like Compaq reverse engineered the PC (and BIOS)
> to produce a functionally similar computer. In the past, big companies
> charged big bucks for C compilers yet today every C programming course
> instructs people to only use open-source compilers like GNU-C.
>
> So why do people here always throw out BLISS as the reason why porting
> VMS to x86 is not possible? After all, its only software. Software
> patents have always been dubious but if there is a copyright on BLISS
> then why not just reverse engineer it in C?

	In FreeVMS, we have a Bliss compiler that runs with gcc. Today,
	FreeVMS 0.4.0 waits for new developers to write memory management
	subsystem. 0.4.0 is rewritten from scratch to use a microkernel and
	to be portable.

	Rewrite from scratch a VMS like operating system is not a huge work.
	Problems come with drivers.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/25/2012 1:22:37 PM


"Phillip Helbig---undress to reply"  wrote in message 
news:jpnq05$9m1$2@online.de...

> Reverse-engineered might not be very efficient.

Or readable/maintainable by humans

Over the years, several "BLISS to C" converters have been investigated. 
Some internal attempts.  Some discussions with 3rd party companies.  All 
went down in flames.  The easy ones are easy. :)  The hard ones, well...

At this point in my career (and with lots of 20/20 hindsight), I think the 
best solution today would be to translate the "easy" ones and keep the hard 
ones as BLISS source and turn the BLISS frontend into the translator tool. 
Ensures source compatibility.  Debugging the code would be a PITA.  Or use 
some Perl/translator-tool into C.  Same problems debugging.

If it weren't for having to debug the stuff now and then, the problem gets 
easier.

0
Reply johnrreagan (372) 5/25/2012 6:21:45 PM

John Reagan wrote:

> ones as BLISS source and turn the BLISS frontend into the translator tool. 
> Ensures source compatibility.  Debugging the code would be a PITA.  Or use 
> some Perl/translator-tool into C.  Same problems debugging.


Wouldn't it be easier to translate Bliss into Macro32 and then use the
existing macro32 compiler to get to it to the target platform ?

Pardon my ignorance here, but does Macro32 *compiler* have 64 bit
extensions ?
0
Reply jfmezei.spamnot (9469) 5/25/2012 6:34:57 PM

JF Mezei schrieb:
> John Reagan wrote:
> 
> 
>>ones as BLISS source and turn the BLISS frontend into the translator tool. 
>>Ensures source compatibility.  Debugging the code would be a PITA.  Or use 
>>some Perl/translator-tool into C.  Same problems debugging.
> 
> 
> 
> Wouldn't it be easier to translate Bliss into Macro32 and then use the
> existing macro32 compiler to get to it to the target platform ?

Wouldn't it be even easier to have the Bliss compiler
(and all other strange stuff)
recoded in C, so it would be just another piece of C software
which has to be compiled for a VMS build?
You could keep your beloved Bliss based utilities
but they would no longer be showstoppers for portability.

> Pardon my ignorance here, but does Macro32 *compiler* have 64 bit
> extensions ?

0
Reply M.Kraemer (2048) 5/25/2012 7:59:25 PM

In article <4fbfd0d1$0$2291$c3e8da3$1cbc7475@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> Pardon my ignorance here, but does Macro32 *compiler* have 64 bit
> extensions ?

    It does on Alpha.

0
Reply koehler2 (8314) 5/25/2012 9:09:04 PM

On May 25, 5:09=A0pm, koeh...@eisner.nospam.encompasserve.org (Bob
Koehler) wrote:
> In article <4fbfd0d1$0$2291$c3e8da3$1cbc7...@news.astraweb.com>, JF Mezei=
 <jfmezei.spam...@vaxination.ca> writes:
>
>
>
> > Pardon my ignorance here, but does Macro32 *compiler* have 64 bit
> > extensions ?
>
> =A0 =A0 It does on Alpha.

http://www3.sympatico.ca/n.rieck/docs/alpha_diary.html#macro64

But I think people quickly realized that a smart C-compiler can beat
the pants off any programmer using Macro64 so they decided to give it
away. Whether anyone likes it or not, getting your code moved over to
C means future portability (probably why HP-UX was ported to x86 so
quickly although no one has presented us with the details)

NSR
0
Reply n.rieck (2007) 5/25/2012 10:09:42 PM

On May 25, 3:59=A0pm, Michael Kraemer <M.Krae...@gsi.de> wrote:
> JF Mezei schrieb:
>
> > John Reagan wrote:
>
> >>ones as BLISS source and turn the BLISS frontend into the translator to=
ol.
> >>Ensures source compatibility. =A0Debugging the code would be a PITA. =
=A0Or use
> >>some Perl/translator-tool into C. =A0Same problems debugging.
>
> > Wouldn't it be easier to translate Bliss into Macro32 and then use the
> > existing macro32 compiler to get to it to the target platform ?
>
> Wouldn't it be even easier to have the Bliss compiler
> (and all other strange stuff)
> recoded in C, so it would be just another piece of C software
> which has to be compiled for a VMS build?
> You could keep your beloved Bliss based utilities
> but they would no longer be showstoppers for portability.
>
>
>
>
>
>
>
> > Pardon my ignorance here, but does Macro32 *compiler* have 64 bit
> > extensions ?

I am in full agreement. C has replaced macro assemblers almost
everywhere. My cousin is a C-programmer in a big Canadian insurance
company. I like to poke him with the odd barbs about C but he always
has some good come backs. For example, when I told him "most people
consider C a low level language" he responded with "it is only low
level until add to includes". I guess that is sort of true with every
language.

NSR
0
Reply n.rieck (2007) 5/25/2012 10:16:16 PM

Neil Rieck wrote:

> I am in full agreement. C has replaced macro assemblers almost
> everywhere. 


Since the Bliss compiler already has what it takes to generate near
assembly code, I was thinking it would be less complex to have it
generate macro code that could then be compiled using macro64.

And since x86 doesn't have the baggage of IA64 with epic and instruction
 bundles etc, it might be easier to use either Bliss-Alpha or even
Bliss-Vax (and give it 64 bit) to create something which can take bliss
source and make it work on x86.

On the other hand, if HP were to port VMS to x86, it would likely get
sufficient funding to get Bliss ported anyways.
0
Reply jfmezei.spamnot (9469) 5/26/2012 12:35:02 AM


"Michael Kraemer"  wrote in message news:jpooau$kdu$1@solani.org...


>Wouldn't it be even easier to have the Bliss compiler
>(and all other strange stuff)
>recoded in C, so it would be just another piece of C software
>which has to be compiled for a VMS build?
>You could keep your beloved Bliss based utilities
>but they would no longer be showstoppers for portability.

Having a portable BLISS compiler (and Macro compiler) would be a good idea. 
Several folks who read this newsgroup have looked into it.   The BLISS docs 
are pretty good for the language description.

However, for some reason, the VMS customer base uses other languages like 
COBOL, Fortran, BASIC, Pascal, and even Ada.  Don't forget them.

And just recompiling GEM with vaporware "portable" BLISS compiler, gets you 
an x86-hosted compiler that can generate code for Alpha (or Itanium).

"JF Mezei" wrote...

>And since x86 doesn't have the baggage of IA64 with epic and instruction
> bundles etc, it might be easier to use either Bliss-Alpha or even
>Bliss-Vax (and give it 64 bit) to create something which can take bliss
>source and make it work on x86.

The BLISS front is common source for Alpha and Itanium.  There is no "epic & 
bundle" baggage in the frontend.  You're back to talking about what code 
generator to hook upto the frontend.  GEM knows (or at least knew at some 
point in the past) how to generate 32-bit x86 code that conforms to the 
Windows Calling Standard, generating Windows object file with Windows debug 
information.  That would be one possible starting point.  The "Mister 
Potatohead" aspect of GEM is that the OpenVMS Itanium ELF/DWARF support 
could be also used as a starting point.

I've never understood all the negativity against the BLISS code base.  Yes, 
you can't easily find good BLISS programmers, but from the C code I've seen 
coming from young engineers, it seems we can't find good C programmers 
either.


0
Reply johnrreagan (372) 5/29/2012 5:32:09 PM

In article <OaCdndPGobaClVjSnZ2dnUVZ_rydnZ2d@insightbb.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>{...snip...{
>I've never understood all the negativity against the BLISS code base.  Yes, 
>you can't easily find good BLISS programmers, but from the C code I've seen 
>coming from young engineers, it seems we can't find good C programmers 
>either.

ROFL!  That's because comp-sci curriculum and degree now means collecting
tuition dollars to indoctrinate the student using the Micro$oft mind-meld
and Visual BASIC.

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 5/29/2012 6:55:57 PM

VAXman- @SendSpamHere.ORG wrote:
> In article <OaCdndPGobaClVjSnZ2dnUVZ_rydnZ2d@insightbb.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
>> {...snip...{
>> I've never understood all the negativity against the BLISS code base.  Yes, 
>> you can't easily find good BLISS programmers, but from the C code I've seen 
>> coming from young engineers, it seems we can't find good C programmers 
>> either.
> 
> ROFL!  That's because comp-sci curriculum and degree now means collecting
> tuition dollars to indoctrinate the student using the Micro$oft mind-meld
> and Visual BASIC.
> 

Yeah, I enjoyed that too.

But to do a decent job with Visual Basic requires some capability.  I'm sure that hackers 
can screw up in any language or environment.
0
Reply davef3 (3717) 5/29/2012 7:41:32 PM

In article <OaCdndPGobaClVjSnZ2dnUVZ_rydnZ2d@insightbb.com>, "John
Reagan" <johnrreagan@earthlink.net> writes: 

> I've never understood all the negativity against the BLISS code base.  Yes, 
> you can't easily find good BLISS programmers, but from the C code I've seen 
> coming from young engineers, it seems we can't find good C programmers 
> either.

Someone said a good Fortran programmer can write good Fortran in any 
language.  I'm sure bad C programmers can write bad C in any language as 
well.  :-)

0
Reply helbig (5067) 5/29/2012 9:32:17 PM

Le Tue, 29 May 2012 21:32:17 +0000 (UTC),
Phillip Helbig---undress to reply <helbig@astro.multiCLOTHESvax.de> écrivait :
> In article <OaCdndPGobaClVjSnZ2dnUVZ_rydnZ2d@insightbb.com>, "John
> Reagan" <johnrreagan@earthlink.net> writes: 
>
>> I've never understood all the negativity against the BLISS code base.  Yes, 
>> you can't easily find good BLISS programmers, but from the C code I've seen 
>> coming from young engineers, it seems we can't find good C programmers 
>> either.
>
> Someone said a good Fortran programmer can write good Fortran in any 
> language.  I'm sure bad C programmers can write bad C in any language as 
> well.  :-)

	And a lot of C issues do not come from C itself, but from libc. I
	have written some years ago a subset of STR$ to use string
	descriptors with gcc to avoid buffer overflows.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/30/2012 7:23:24 AM

On 05/30/12 07:23, JKB wrote:

>
> 	And a lot of C issues do not come from C itself, but from libc. I
> 	have written some years ago a subset of STR$ to use string
> 	descriptors with gcc to avoid buffer overflows.
>
> 	JKB
>

Working in embedded space, you try to avoid clib in that many of the 
types are
wrong (signed types applied to unsigned functionality etc) and build you 
own
libraries over the the years.

However, clib is very usefull for it's wide range of functionality, for 
quick
utilities and other non critical stuff, but program with care...

Regards,

Chris



0
Reply meru (441) 5/31/2012 11:55:30 AM

On 5/24/2012 11:35 AM, JF Mezei wrote:
> The only aspect the community can do is convince HP to announce it will
> open source VMS on the day it announces the end of the line for iA64 VMS
> and HP-UX.

OpenMPE was unable to convince HP to open-source MPE code after its EOL 
announcement. 3rd-party support organizations were allowed licenses only 
to view the MPE code, not to modify or redistribute it. I suspect there 
would be no better outcome with OpenVMS.

And based on the feedback I've heard at user group events in the past, 
some OpenVMS users, particularly those concerned about security, don't 
want the OpenVMS code exposed to everyone, including potential hackers. 
Security by obscurity isn't the best security, but it does make things 
harder for most potential attackers to a degree that makes a difference 
in the real world.

And even if the actual VMS code were released to Open Source, what you'd 
have is a kernel written in mostly Macro, with some Bliss and C, 
utilities and RTLs in mostly Bliss, and no Bliss or Macro compiler for 
any other architecture. Perhaps the community could write Bliss and 
Macro front ends for gcc or something, but it seems to me that would be 
the only way to make the existing OpenVMS source code usable.
0
Reply keithparris_deletethis (241) 5/31/2012 3:08:59 PM

Le Thu, 31 May 2012 09:08:59 -0600,
Keith Parris <keithparris_deletethis@yahoo.com> écrivait :
> On 5/24/2012 11:35 AM, JF Mezei wrote:
>> The only aspect the community can do is convince HP to announce it will
>> open source VMS on the day it announces the end of the line for iA64 VMS
>> and HP-UX.
>
> OpenMPE was unable to convince HP to open-source MPE code after its EOL 
> announcement. 3rd-party support organizations were allowed licenses only 
> to view the MPE code, not to modify or redistribute it. I suspect there 
> would be no better outcome with OpenVMS.
>
> And based on the feedback I've heard at user group events in the past, 
> some OpenVMS users, particularly those concerned about security, don't 
> want the OpenVMS code exposed to everyone, including potential hackers. 
> Security by obscurity isn't the best security, but it does make things 
> harder for most potential attackers to a degree that makes a difference 
> in the real world.
>
> And even if the actual VMS code were released to Open Source, what you'd 
> have is a kernel written in mostly Macro, with some Bliss and C, 
> utilities and RTLs in mostly Bliss, and no Bliss or Macro compiler for 
> any other architecture. Perhaps the community could write Bliss and 
> Macro front ends for gcc or something, but it seems to me that would be 
> the only way to make the existing OpenVMS source code usable.

	No. You have to rewrite all low level routines also. And this
	operation is very huge.

	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 5/31/2012 8:34:33 PM

On Thu, 31 May 2012 09:08:59 -0600, Keith Parris wrote:

> And based on the feedback I've heard at user group events in the past,
> some OpenVMS users, particularly those concerned about security, don't
> want the OpenVMS code exposed to everyone, including potential hackers.
> Security by obscurity isn't the best security, but it does make things
> harder for most potential attackers to a degree that makes a difference
> in the real world.

I was recently accused of "security through obscurity" when I observed 
that moving ssh to a non-standard port stopped the constant rattling of 
my Alpha's system disk.
¨
Real world example.

No, it wouldn't have dissuaded a determined and knowledgeable attacker, 
but it certainly cut out the noise.  Literally in my case :-)

-- 
Paul Sture
0
Reply paul.nospam (2164) 6/1/2012 6:41:54 AM

Latest from HP posted at 

http://www.hp.com/go/HPOracleCustomersFirst
0
Reply gxys (807) 6/1/2012 9:11:31 AM

In article <daad1745-f8c4-45fc-8894-6ce1437c2124@googlegroups.com>,
IanMiller <gxys@uk2.net> writes: 

> Latest from HP posted at 
> 
> http://www.hp.com/go/HPOracleCustomersFirst

Worth a read.  It links to "Project Odyssey":

   http://h18004.www1.hp.com/products/solutions/mcci/index.html

However, with Mozilla on VMS the page is unreadable due to the dark 
background in much of the picture.  :-(

0
Reply helbig (5067) 6/1/2012 9:29:04 AM

On 05/31/12 20:34, JKB wrote:

>
> 	No. You have to rewrite all low level routines also. And this
> 	operation is very huge.
>
> 	JKB
>

What, exactly ?. If it's device drivers, then you need to rewrite those
for any change in architecture. Quality open source drivers exist for just
about all hardware now and they are mostly written in C or other hll.

No one writes much OS code in asm these days and how much is left in vms 
now,
other than things like lowest level context switching ?...

Regards,

Chris
0
Reply meru (441) 6/1/2012 11:45:21 AM

Le Fri, 01 Jun 2012 11:45:21 +0000,
ChrisQ <meru@devnull.com> écrivait :
> On 05/31/12 20:34, JKB wrote:
>
>>
>> 	No. You have to rewrite all low level routines also. And this
>> 	operation is very huge.
>>
>> 	JKB
>>
>
> What, exactly ?. If it's device drivers, then you need to rewrite those
> for any change in architecture. Quality open source drivers exist for just
> about all hardware now and they are mostly written in C or other hll.
>
> No one writes much OS code in asm these days and how much is left in vms 
> now,
> other than things like lowest level context switching ?...

	Memory management (MMU), SMP, context switching and some other
	stuff.

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 6/1/2012 12:00:36 PM

On 5/11/2012 5:41 AM, JKB wrote:
> 	If I have to write an OpenVMS-like
> 	system, I'll start from a microkernel like L4... With this
> 	microkernel, you can emulate all protection levels you want and your
> 	OS is portable.

If you're building an OpenVMS clone starting with a UNIX-like or Linux 
kernel, I can see the logic in a microkernel approach. Linux has only 
two modes: User and Kernel, and microkernels are attractive because they 
allow you to run software within user-mode processes (with a separate 
address space, and protection for the rest of kernel context) for things 
like the network stack so if you have a buffer overflow, the damage is 
limited to a single process instead of having access to the kernel itself.

But it seems to me this solves a problem that VMS doesn't have, or at 
least isn't forced by design to have. With four rings of protection 
(Kernel, Executive, Supervisor, and Kernel) there's really no need to 
run a network stack in Kernel mode on VMS; it could at worst run in Exec 
mode and probably even be placed in Supervisor mode, which protects 
kernel mode context and limits the scope of potential damage.

So if you were writing a VMS-like kernel from scratch, I'm not convinced 
a microkernel would be the way to go.
0
Reply keithparris_deletethis (241) 6/1/2012 3:55:10 PM

On 06/01/12 15:55, Keith Parris wrote:

> If you're building an OpenVMS clone starting with a UNIX-like or Linux
> kernel, I can see the logic in a microkernel approach. Linux has only
> two modes: User and Kernel, and microkernels are attractive because they
> allow you to run software within user-mode processes (with a separate
> address space, and protection for the rest of kernel context) for things
> like the network stack so if you have a buffer overflow, the damage is
> limited to a single process instead of having access to the kernel itself.
>
> But it seems to me this solves a problem that VMS doesn't have, or at
> least isn't forced by design to have. With four rings of protection
> (Kernel, Executive, Supervisor, and Kernel) there's really no need to
> run a network stack in Kernel mode on VMS; it could at worst run in Exec
> mode and probably even be placed in Supervisor mode, which protects
> kernel mode context and limits the scope of potential damage.
>
> So if you were writing a VMS-like kernel from scratch, I'm not convinced
> a microkernel would be the way to go.

All you are saying there is that microkernels you are familiar with only 
have
two protection levels, but there's no reason why > 2 couldn't be 
implemented.
One thing to note is that protection mechanisms are often dependent on cpu
hardware specific features. Iirc, (correct me if wrong) for vax, there are
two, with non overlapping address spaces that preclude any user process 
from
overwriting kernel memory. It just can't access the address space. Memory
management can also contribute, typically causing a memory access violation
trap, once again using  hardware features.

None of this is as critical as the old days, when for example the ethernet
frame format was changed (trailer protocol), to provide the equivalent of a
memory copy by simply switching page table entries. Iirc, first used in 
bsd unix.
Modern processors are fast enough so that much of this can be done in 
software,
which gives a lot more flexibility...

Regards,

Chris
0
Reply meru (441) 6/1/2012 5:13:31 PM

On 2012-06-01, Keith Parris <keithparris_deletethis@yahoo.com> wrote:
> On 5/11/2012 5:41 AM, JKB wrote:
>> 	If I have to write an OpenVMS-like
>> 	system, I'll start from a microkernel like L4... With this
>> 	microkernel, you can emulate all protection levels you want and your
>> 	OS is portable.
>
> If you're building an OpenVMS clone starting with a UNIX-like or Linux 
> kernel, I can see the logic in a microkernel approach. Linux has only 
> two modes: User and Kernel, and microkernels are attractive because they 
> allow you to run software within user-mode processes (with a separate 
> address space, and protection for the rest of kernel context) for things 
> like the network stack so if you have a buffer overflow, the damage is 
> limited to a single process instead of having access to the kernel itself.
>
> But it seems to me this solves a problem that VMS doesn't have, or at 
> least isn't forced by design to have. With four rings of protection 
> (Kernel, Executive, Supervisor, and Kernel) there's really no need to 
> run a network stack in Kernel mode on VMS; it could at worst run in Exec 
> mode and probably even be placed in Supervisor mode, which protects 
> kernel mode context and limits the scope of potential damage.
>

What you have missed here that is that if you write directly to the
underlying hardware, then the hardware needs to support all the multiple
protection rings (if you want to design the operating system to use
them) and much of the hardware available today does not.

For example, on ARM it's a simple two level architecture, user mode or
supervisor mode.

As for the real time issues mentioned in other posts, the posters are
quite correct in that the wrong choice of microkernel design will destroy
the real time capabilities of the operating system.

However, with the correct choice of microkernel design it's quite possible
to have real time capability. Don't forget that QNX is a microkernel based
RTOS.

> So if you were writing a VMS-like kernel from scratch, I'm not convinced 
> a microkernel would be the way to go.

It depends on if you want to capture what's good about VMS and reimplement
that or if you want to blindly take every single feature and every single
design decision and implement that without any change allowed.

Some example issues other than the microkernel issue:

Would you blindly reimplement ODS-2 as the standard filesystem because
that's what was state of the art when VMS was designed or would you
implement a more modern filesystem with all the functionality of ODS-2 or
ODS-5 (so that you can implement multiple file versions and RMS) but also
with all the lessons learnt in filesystem design since the 1970s/1980s ?

Would you retain a version limit of 32767 ?

Would you blindly implement all the special quoting required for ODS-5
volumes or would you implement another approach which reduced the special
quoting requirements ?

Would New-VMS fail the first I/O and _then_ put the volume into mount
verification state, or would the failing I/O be suspended until mount
verification is completed ? (It's been a number of years since I looked
at this; does VMS still fail the first I/O after a hardware issue before
putting the drive into mount verification ?)

BTW, IMHO, in any redesign it would be crazy not to allow a clean plugin
architecture for filesystems (much like Linux has) so that you can
cleanly mount any filesystems in New-VMS, including ones not currently
supported natively on VMS.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/1/2012 5:22:37 PM

IanMiller wrote:
> Latest from HP posted at 
> http://www.hp.com/go/HPOracleCustomersFirst


PR speak for "we're not ready to fess up yet"

0
Reply jfmezei.spamnot (9469) 6/1/2012 6:34:08 PM

JKB wrote:
> Le Fri, 01 Jun 2012 11:45:21 +0000,
> ChrisQ <meru@devnull.com> écrivait :
>> On 05/31/12 20:34, JKB wrote:
>>
>>> 	No. You have to rewrite all low level routines also. And this
>>> 	operation is very huge.
>>>
>>> 	JKB
>>>
>> What, exactly ?. If it's device drivers, then you need to rewrite those
>> for any change in architecture. Quality open source drivers exist for just
>> about all hardware now and they are mostly written in C or other hll.
>>
>> No one writes much OS code in asm these days and how much is left in vms 
>> now,
>> other than things like lowest level context switching ?...
> 
> 	Memory management (MMU), SMP, context switching and some other
> 	stuff.
> 

I think something to keep in mind when talking about designing / writing an OS is that 
most likely a large percentage of the people on c.o.v don't really know the details of 
what it takes to implement an OS.  I'll admit that while I've played around with some 
things in the past, I'd have a long and steep learning curve to get to the level of an OS 
architect

I'll even pose the thought that if we're talking about very detailed knowledge of all 
parts of VMS than possibly nobody on this list would qualify.

What's even more alarming is that I have to wonder if anyone at HP still would qualify?
0
Reply davef3 (3717) 6/1/2012 6:39:23 PM

IanMiller wrote:
> Latest from HP posted at 
> 
> http://www.hp.com/go/HPOracleCustomersFirst

I hate to be a pessimist, but such is always coming from businesses trying to affect 
public perception.  There are various names for such.  But read carefully.  Is there even 
a hint of a real commitment is the letter?  I don't think so.

It all goes back to "the bedbug letter" ...
0
Reply davef3 (3717) 6/1/2012 6:48:18 PM

On 6/1/2012 11:13 AM, ChrisQ wrote:
> One thing to note is that protection mechanisms are often dependent on cpu
> hardware specific features. Iirc, (correct me if wrong) for vax, there are
> two, with non overlapping address spaces that preclude any user process
> from
> overwriting kernel memory. It just can't access the address space. Memory
> management can also contribute, typically causing a memory access violation
> trap, once again using hardware features.

For VAX there are not 2 but 4 modes: Kernel, Executive, Supervisor, 
User. Memory management provides protections limiting access by 
less-privileged modes to pages which more-privileged modes choose to 
protect.
0
Reply keithparris_deletethis (241) 6/1/2012 7:43:39 PM

On 6/1/2012 11:22 AM, Simon Clubley wrote:
> What you have missed here that is that if you write directly to the
> underlying hardware, then the hardware needs to support all the multiple
> protection rings (if you want to design the operating system to use
> them) and much of the hardware available today does not.
>
> For example, on ARM it's a simple two level architecture, user mode or
> supervisor mode.

Thanks. I was thinking of x86, which does have 4 modes.

For ARM I presume one would use something similar to the SWIS code which 
is in OpenVMS on IA64.

> Would you blindly reimplement ODS-2 as the standard filesystem because
> that's what was state of the art when VMS was designed or would you
> implement a more modern filesystem with all the functionality of ODS-2 or
> ODS-5 (so that you can implement multiple file versions and RMS) but also
> with all the lessons learnt in filesystem design since the 1970s/1980s ?

It would likely need to be able to read ODS-2/ODS-5 but I'd sure want to 
do the latter.

> Would you retain a version limit of 32767 ?

Perhaps one could extend the version limit range possible but give the 
choice of retaining current behavior with a max. of 32767 if desired.

There are a lot of other limits in OpenVMS based on 8-bit, 16-bit, 
24-bit (e.g. Lock IDs), and 32-bit field widths. Memory is no longer so 
expensive, and many of these limits beg to be raised.

> Would you blindly implement all the special quoting required for ODS-5
> volumes or would you implement another approach which reduced the special
> quoting requirements ?

That's pretty ugly, isn't it?

> BTW, IMHO, in any redesign it would be crazy not to allow a clean plugin
> architecture for filesystems (much like Linux has) so that you can
> cleanly mount any filesystems in New-VMS, including ones not currently
> supported natively on VMS.

I agree.
0
Reply keithparris_deletethis (241) 6/1/2012 7:50:11 PM

On 2012-06-01 21:43, Keith Parris wrote:
> On 6/1/2012 11:13 AM, ChrisQ wrote:
>> One thing to note is that protection mechanisms are often dependent on
>> cpu
>> hardware specific features. Iirc, (correct me if wrong) for vax, there
>> are
>> two, with non overlapping address spaces that preclude any user process
>> from
>> overwriting kernel memory. It just can't access the address space. Memory
>> management can also contribute, typically causing a memory access
>> violation
>> trap, once again using hardware features.
>
> For VAX there are not 2 but 4 modes: Kernel, Executive, Supervisor,
> User. Memory management provides protections limiting access by
> less-privileged modes to pages which more-privileged modes choose to
> protect.

Depends on how you look at things.
On the VAX, there are four processor modes. And the access rights to 
each page is determined by the protection of the page, in combination 
with the protection code. So in that way, there are four modes.

However, memory space itself comes actually just in one way. There is 
just one address space, that all of the system, as well as the user 
program lives in. All of it is in the same 32-bit virtual address space.
But furthermore, the virtual address space itself is divided into four 
sections. S0,S1,P0 and P1. I suspect Chris was thinking of the division 
between system space (S0,S1) and process space (P0,P1). That mapping, 
however, have no relevance for the processor modes, but is a distinction 
on which page table to use, and where in the virtual address space it is 
located. System space and process space are just two halves of the whole 
virtual address space. A context switch only affects process space, but 
leaves system space alone. But it still exists for each process. It is 
just normally protected from both reads and writes (for obvious reasons).

	Johnny
0
Reply bqt2 (1410) 6/2/2012 9:00:08 AM

On 06/02/12 09:00, Johnny Billquist wrote:
> On 2012-06-01 21:43, Keith Parris wrote:
>> On 6/1/2012 11:13 AM, ChrisQ wrote:
>>> One thing to note is that protection mechanisms are often dependent on
>>> cpu
>>> hardware specific features. Iirc, (correct me if wrong) for vax, there
>>> are
>>> two, with non overlapping address spaces that preclude any user process
>>> from
>>> overwriting kernel memory. It just can't access the address space.
>>> Memory
>>> management can also contribute, typically causing a memory access
>>> violation
>>> trap, once again using hardware features.
>>
>> For VAX there are not 2 but 4 modes: Kernel, Executive, Supervisor,
>> User. Memory management provides protections limiting access by
>> less-privileged modes to pages which more-privileged modes choose to
>> protect.
>
> Depends on how you look at things.
> On the VAX, there are four processor modes. And the access rights to
> each page is determined by the protection of the page, in combination
> with the protection code. So in that way, there are four modes.
>
> However, memory space itself comes actually just in one way. There is
> just one address space, that all of the system, as well as the user
> program lives in. All of it is in the same 32-bit virtual address space.
> But furthermore, the virtual address space itself is divided into four
> sections. S0,S1,P0 and P1. I suspect Chris was thinking of the division
> between system space (S0,S1) and process space (P0,P1). That mapping,
> however, have no relevance for the processor modes, but is a distinction
> on which page table to use, and where in the virtual address space it is
> located. System space and process space are just two halves of the whole
> virtual address space. A context switch only affects process space, but
> leaves system space alone. But it still exists for each process. It is
> just normally protected from both reads and writes (for obvious reasons).
>
> Johnny

It's been a long time since I looked at any vax manuals, but what I was 
trying
to illustrate was that protection modes are often bound to processor 
hardware
features, so any port to a new architecture must take this into account. If
the new arch has fewer modes in hardware, then the remaining modes can 
only be
synthesised in software. Vax was a particularly rich architecture, both 
in h/w
features, instruction set, addressing modes and calling standards. A lot of
things were done in hardware on vax to get the performance, while the 
modern
tendency is to do as much as possible in software...

Regards,

Chris

0
Reply meru (441) 6/2/2012 10:05:01 AM

On 2012-06-01, Keith Parris <keithparris_deletethis@yahoo.com> wrote:
> On 6/1/2012 11:22 AM, Simon Clubley wrote:
>> What you have missed here that is that if you write directly to the
>> underlying hardware, then the hardware needs to support all the multiple
>> protection rings (if you want to design the operating system to use
>> them) and much of the hardware available today does not.
>>
>> For example, on ARM it's a simple two level architecture, user mode or
>> supervisor mode.
>
> Thanks. I was thinking of x86, which does have 4 modes.
>
> For ARM I presume one would use something similar to the SWIS code which 
> is in OpenVMS on IA64.
>

No, based on my understanding of what SWIS provides, that does not appear
to be possible.

My knowledge of the IA64 MMU and SWIS is based on what I have been reading
this evening as I have no prior IA64 experience. If I am wrong about what
I am about to write I would appreciate pointers to documents so that I can
read up more about this.

SWIS appears to be an enabling mechanism in that it provides various
services which were provided by the PALcode on Alpha. What it does _not_
appear to be is a enforcing mechanism, at least when it comes to page
protections across multiple rings.

Page protection functionality on IA64 VMS appears to be provided by the
standard IA64 page protection capabilities, which appear to closely match
(in concept) the page protection functionality found on VAX/Alpha.

This 4 ring page protection capability simply does not exist on ARM.

A example might help to clarify the difference between IA64 and a typical
ARM board. Download volume 2 of the IA64 architecture manual set from Intel
and have a look at section 4.1.1.6 "Page Access Rights" and look at the
range of options available which allow you to implement VMS pretty much
as is.

For comparison, one of the ARM boards in front of me uses a LPC3131, which
is based on the ARM926EJ-S core and is a typical ARM core. Now download the
ARM926EJ-S technical reference manual from ARM:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0198e/DDI0198E_arm926ejs_r0p5_trm.pdf

and look at section 3.4 "Domain access control" on pages 3-23 and 3-24.
As you can see in table 3-12 (split across those pages), page protection on
this core is implemented as a two-level privileged or user mode access.

There is simply no way to implement VMS as-is on a ARM or similar core.

You _should_ however be able to implement the functional equivalent of what
the various protection rings provide by running the various VMS privileged
services seperately on top of a microkernel,

You could even make it _more_ robust than the current VMS setup by
splitting up the kernel mode components and running them seperately
on top of the microkernel.

>> Would you blindly reimplement ODS-2 as the standard filesystem because
>> that's what was state of the art when VMS was designed or would you
>> implement a more modern filesystem with all the functionality of ODS-2 or
>> ODS-5 (so that you can implement multiple file versions and RMS) but also
>> with all the lessons learnt in filesystem design since the 1970s/1980s ?
>
> It would likely need to be able to read ODS-2/ODS-5 but I'd sure want to 
> do the latter.
>

If you implement a filesystem plugin architecture, you could have a new
native filesystem, but also ODS-2/ODS-5 as a plugin module.

>> Would you blindly implement all the special quoting required for ODS-5
>> volumes or would you implement another approach which reduced the special
>> quoting requirements ?
>
> That's pretty ugly, isn't it?
>

Yes, it is. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/2/2012 9:38:25 PM


>"Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...

>No, based on my understanding of what SWIS provides, that does not appear
>to be possible.

>SWIS appears to be an enabling mechanism in that it provides various
>services which were provided by the PALcode on Alpha. What it does _not_
>appear to be is a enforcing mechanism, at least when it comes to page
>protections across multiple rings.

At one point after he finished it, Burns Fisher (the designer and 
implementor of SWIS) said "I think I can do it with two modes."  Of course 
he might be wrong, but that's what Burns told me.

John 

0
Reply johnrreagan (372) 6/3/2012 3:06:31 AM

On 2012-06-02, John Reagan <johnrreagan@earthlink.net> wrote:
>
>
>>"Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...
>
>>No, based on my understanding of what SWIS provides, that does not appear
>>to be possible.
>
>>SWIS appears to be an enabling mechanism in that it provides various
>>services which were provided by the PALcode on Alpha. What it does _not_
>>appear to be is a enforcing mechanism, at least when it comes to page
>>protections across multiple rings.
>
> At one point after he finished it, Burns Fisher (the designer and 
> implementor of SWIS) said "I think I can do it with two modes."  Of course 
> he might be wrong, but that's what Burns told me.
>

So are you saying that RMS no longer runs in executive mode on IA64 and
hence no longer requires a MMU which can provide different page protection
configurations to both executive mode code and kernel mode code ?

Does DCL no longer require supervisor mode page protection from the MMU ?

If so, it would be nice to read a SWIS design document to understand
how this works. The porting VMS to IA64 briefing document makes a point
of mentioning that IA64 is a 4 mode architecture and I cannot find
anything about reducing the number of modes in use.

BTW, there is no way of implementing anything like PALcode on a ARM
(at least on the ARM cores I am familiar with) so you cannot add missing
functionality into a PALcode firmware layer as you can on Alpha.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/3/2012 6:08:35 AM

On 2012-06-03 08:08, Simon Clubley wrote:
> On 2012-06-02, John Reagan<johnrreagan@earthlink.net>  wrote:
>>
>>
>>> "Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...
>>
>>> No, based on my understanding of what SWIS provides, that does not appear
>>> to be possible.
>>
>>> SWIS appears to be an enabling mechanism in that it provides various
>>> services which were provided by the PALcode on Alpha. What it does _not_
>>> appear to be is a enforcing mechanism, at least when it comes to page
>>> protections across multiple rings.
>>
>> At one point after he finished it, Burns Fisher (the designer and
>> implementor of SWIS) said "I think I can do it with two modes."  Of course
>> he might be wrong, but that's what Burns told me.
>>
>
> So are you saying that RMS no longer runs in executive mode on IA64 and
> hence no longer requires a MMU which can provide different page protection
> configurations to both executive mode code and kernel mode code ?
>
> Does DCL no longer require supervisor mode page protection from the MMU ?
>
> If so, it would be nice to read a SWIS design document to understand
> how this works. The porting VMS to IA64 briefing document makes a point
> of mentioning that IA64 is a 4 mode architecture and I cannot find
> anything about reducing the number of modes in use.
>
> BTW, there is no way of implementing anything like PALcode on a ARM
> (at least on the ARM cores I am familiar with) so you cannot add missing
> functionality into a PALcode firmware layer as you can on Alpha.

I'm not really clear that there is any requirements for the additional 
protection levels in VMS. You obviously need the user level protection, 
so that normal user programs can't read or modify parts that they are 
not allowed to.
But RMS? Does it really need to be prevented from being able to access 
the kernel memory? It might be good to have both a belt and suspenders, 
but why would it be required? RMS is a piece of the system after all. We 
have full control of the code paths, and knows what it is doing at all 
times. It can't be injected with user code. There is no real need for 
the additional protection, as far as I know. Same for DCL.

Could someone point out to me what I am missing. Why is it *really* 
needed to have four protection levels?

	Johnny
0
Reply bqt2 (1410) 6/3/2012 6:22:43 AM

On Fri, 01 Jun 2012 17:22:37 +0000, Simon Clubley wrote:

Subject to much thought and discussion about backward compatibility and 
migrating existing data to the new system:

> Some example issues other than the microkernel issue:
> 
> Would you blindly reimplement ODS-2 as the standard filesystem because
> that's what was state of the art when VMS was designed or would you
> implement a more modern filesystem with all the functionality of ODS-2
> or ODS-5 (so that you can implement multiple file versions and RMS) but
> also with all the lessons learnt in filesystem design since the
> 1970s/1980s ?

Desirable, but redesigning a file system is very time consuming.  The 
testing of it too.  When I was looking for comparisons of Unix file 
systems early last year, the most frequently quoted "benchmark" I came 
across was unpacking the (Linux) kernel sources from a tarball.  Another 
"benchmark" I came across earlier this year was creating a billion zero 
length files.  Both examples made me wonder how familiar the file system 
designers/developers are with the real world I/O demands of commercial 
workloads.

> Would you retain a version limit of 32767 ?

Nope.

> Would you blindly implement all the special quoting required for ODS-5
> volumes or would you implement another approach which reduced the
> special quoting requirements ?

I've always hated that caret business.  Dollar signs in filenames aren't 
very friendly for a GNV environment either.

> Would New-VMS fail the first I/O and _then_ put the volume into mount
> verification state, or would the failing I/O be suspended until mount
> verification is completed ? (It's been a number of years since I looked
> at this; does VMS still fail the first I/O after a hardware issue before
> putting the drive into mount verification ?)

Pass.

> BTW, IMHO, in any redesign it would be crazy not to allow a clean plugin
> architecture for filesystems (much like Linux has) so that you can
> cleanly mount any filesystems in New-VMS, including ones not currently
> supported natively on VMS.

Indeed.

Can we have SYSGEN UNLOAD at last? :-)

-- 
Paul Sture
0
Reply paul.nospam (2164) 6/3/2012 12:53:20 PM

Le Fri, 1 Jun 2012 17:22:37 +0000 (UTC),
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> écrivait :
> On 2012-06-01, Keith Parris <keithparris_deletethis@yahoo.com> wrote:
>> On 5/11/2012 5:41 AM, JKB wrote:
>>> 	If I have to write an OpenVMS-like
>>> 	system, I'll start from a microkernel like L4... With this
>>> 	microkernel, you can emulate all protection levels you want and your
>>> 	OS is portable.
>>
>> If you're building an OpenVMS clone starting with a UNIX-like or Linux 
>> kernel, I can see the logic in a microkernel approach. Linux has only 
>> two modes: User and Kernel, and microkernels are attractive because they 
>> allow you to run software within user-mode processes (with a separate 
>> address space, and protection for the rest of kernel context) for things 
>> like the network stack so if you have a buffer overflow, the damage is 
>> limited to a single process instead of having access to the kernel itself.
>>
>> But it seems to me this solves a problem that VMS doesn't have, or at 
>> least isn't forced by design to have. With four rings of protection 
>> (Kernel, Executive, Supervisor, and Kernel) there's really no need to 
>> run a network stack in Kernel mode on VMS; it could at worst run in Exec 
>> mode and probably even be placed in Supervisor mode, which protects 
>> kernel mode context and limits the scope of potential damage.
>>
>
> What you have missed here that is that if you write directly to the
> underlying hardware, then the hardware needs to support all the multiple
> protection rings (if you want to design the operating system to use
> them) and much of the hardware available today does not.
>
> For example, on ARM it's a simple two level architecture, user mode or
> supervisor mode.
>
> As for the real time issues mentioned in other posts, the posters are
> quite correct in that the wrong choice of microkernel design will destroy
> the real time capabilities of the operating system.
>
> However, with the correct choice of microkernel design it's quite possible
> to have real time capability. Don't forget that QNX is a microkernel based
> RTOS.

	And don't forget that L4 microkernel is a real microkernel. Mach and
	XNU, for example, aren't real microkernels but hybrid ones that have
	been written to implemant a lot of unixism.
	
	JKB

-- 
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
0
Reply jkb (86) 6/4/2012 9:01:53 AM

In article <hzlyr.540108$4R.443731@fx17.am4>, ChrisQ <meru@devnull.com> writes:
> 
> It's been a long time since I looked at any vax manuals, but what I was 
> trying
> to illustrate was that protection modes are often bound to processor 
> hardware
> features, so any port to a new architecture must take this into account. If
> the new arch has fewer modes in hardware, then the remaining modes can 
> only be
> synthesised in software.

   This has been discussed many times in the past.  Alpha's support for
   4 modes is not as hardwired as VAX.  IA64 and IA32 don't support all
   the possible combinations of X read and Y write that VAX did.

   Yet VMS runs fine on IA64 and knowledgable people have said there is
   enough of 4 modes in IA32 that it would work.

   IIRC, in port from Alpha to IA64 this missing combinations were found
   not to actually be needed.

0
Reply koehler2 (8314) 6/4/2012 1:18:22 PM

Johnny Billquist wrote:
> On 2012-06-03 08:08, Simon Clubley wrote:
>> On 2012-06-02, John Reagan<johnrreagan@earthlink.net>  wrote:
>>>
>>>
>>>> "Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...
>>>
>>>> No, based on my understanding of what SWIS provides, that does not 
>>>> appear
>>>> to be possible.
>>>
>>>> SWIS appears to be an enabling mechanism in that it provides various
>>>> services which were provided by the PALcode on Alpha. What it does 
>>>> _not_
>>>> appear to be is a enforcing mechanism, at least when it comes to page
>>>> protections across multiple rings.
>>>
>>> At one point after he finished it, Burns Fisher (the designer and
>>> implementor of SWIS) said "I think I can do it with two modes."  Of 
>>> course
>>> he might be wrong, but that's what Burns told me.
>>>
>>
>> So are you saying that RMS no longer runs in executive mode on IA64 and
>> hence no longer requires a MMU which can provide different page 
>> protection
>> configurations to both executive mode code and kernel mode code ?
>>
>> Does DCL no longer require supervisor mode page protection from the MMU ?
>>
>> If so, it would be nice to read a SWIS design document to understand
>> how this works. The porting VMS to IA64 briefing document makes a point
>> of mentioning that IA64 is a 4 mode architecture and I cannot find
>> anything about reducing the number of modes in use.
>>
>> BTW, there is no way of implementing anything like PALcode on a ARM
>> (at least on the ARM cores I am familiar with) so you cannot add missing
>> functionality into a PALcode firmware layer as you can on Alpha.
> 
> I'm not really clear that there is any requirements for the additional 
> protection levels in VMS. You obviously need the user level protection, 
> so that normal user programs can't read or modify parts that they are 
> not allowed to.
> But RMS? Does it really need to be prevented from being able to access 
> the kernel memory? It might be good to have both a belt and suspenders, 
> but why would it be required? RMS is a piece of the system after all. We 
> have full control of the code paths, and knows what it is doing at all 
> times. It can't be injected with user code. There is no real need for 
> the additional protection, as far as I know. Same for DCL.
> 
> Could someone point out to me what I am missing. Why is it *really* 
> needed to have four protection levels?
> 
>     Johnny

There seems to be a lot of mysticism about VMS "modes".

If you go back to the original VAX, there are really six processor 
modes: user, supervisor, executive, kernel, interrupt, compatibility

Ignoring compatibility mode, and looking at the modes from a different 
functional point of view, there are only two modes: unprivileged and 
privileged.  This classification restricts what instructions can be 
executed.

So what is the difference between user, supervisor, and executive modes? 
  These modes all have the same processor model (unprivileged) and 
execute the same instructions.  When you get down to it, the ONLY 
difference between these modes is the memory map.

On the VAX, the memory map is a single structure with various KESU 
fields/flags, but it does not need to be that way.  Since unprivileged 
code can not directly manipulate the memory map, its structure can be 
changed.

If you define separate user, supervisor, and executive memory maps, the 
CHMx and corresponding RET functions (which are privileged) can just 
swap the memory maps as needed, giving you the full VMS memory model on 
a processor with a single unprivileged mode.

Yes, this may result in some inefficiencies in TLB management, but if 
you are running on a processor that is twice as fast and take a small 
TLB hit, who cares?

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris@applied-synergy.com
   Fax: 817-237-3074
0
Reply chris78 (32) 6/4/2012 8:13:49 PM

On 2012-06-04, Chris Scheers <chris@applied-synergy.com> wrote:
> Johnny Billquist wrote:
>> On 2012-06-03 08:08, Simon Clubley wrote:
>>> On 2012-06-02, John Reagan<johnrreagan@earthlink.net>  wrote:
>>>>
>>>>
>>>>> "Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...
>>>>
>>>>> No, based on my understanding of what SWIS provides, that does not 
>>>>> appear
>>>>> to be possible.
>>>>
>>>>> SWIS appears to be an enabling mechanism in that it provides various
>>>>> services which were provided by the PALcode on Alpha. What it does 
>>>>> _not_
>>>>> appear to be is a enforcing mechanism, at least when it comes to page
>>>>> protections across multiple rings.
>>>>
>>>> At one point after he finished it, Burns Fisher (the designer and
>>>> implementor of SWIS) said "I think I can do it with two modes."  Of 
>>>> course
>>>> he might be wrong, but that's what Burns told me.
>>>>
>>>
>>> So are you saying that RMS no longer runs in executive mode on IA64 and
>>> hence no longer requires a MMU which can provide different page 
>>> protection
>>> configurations to both executive mode code and kernel mode code ?
>>>
>>> Does DCL no longer require supervisor mode page protection from the MMU ?
>>>
>>> If so, it would be nice to read a SWIS design document to understand
>>> how this works. The porting VMS to IA64 briefing document makes a point
>>> of mentioning that IA64 is a 4 mode architecture and I cannot find
>>> anything about reducing the number of modes in use.
>>>
>>> BTW, there is no way of implementing anything like PALcode on a ARM
>>> (at least on the ARM cores I am familiar with) so you cannot add missing
>>> functionality into a PALcode firmware layer as you can on Alpha.
>> 
>> I'm not really clear that there is any requirements for the additional 
>> protection levels in VMS. You obviously need the user level protection, 
>> so that normal user programs can't read or modify parts that they are 
>> not allowed to.
>> But RMS? Does it really need to be prevented from being able to access 
>> the kernel memory? It might be good to have both a belt and suspenders, 
>> but why would it be required? RMS is a piece of the system after all. We 
>> have full control of the code paths, and knows what it is doing at all 
>> times. It can't be injected with user code. There is no real need for 
>> the additional protection, as far as I know. Same for DCL.
>> 
>> Could someone point out to me what I am missing. Why is it *really* 
>> needed to have four protection levels?
>> 
>>     Johnny
>
> There seems to be a lot of mysticism about VMS "modes".
>
> If you go back to the original VAX, there are really six processor 
> modes: user, supervisor, executive, kernel, interrupt, compatibility
>
> Ignoring compatibility mode, and looking at the modes from a different 
> functional point of view, there are only two modes: unprivileged and 
> privileged.  This classification restricts what instructions can be 
> executed.
>
> So what is the difference between user, supervisor, and executive modes? 
>   These modes all have the same processor model (unprivileged) and 
> execute the same instructions.  When you get down to it, the ONLY 
> difference between these modes is the memory map.
>

You also need to change stack pointers when switching modes and you need
to emulate the additional VMS stacks with stack fixups required when
switching modes.

> On the VAX, the memory map is a single structure with various KESU 
> fields/flags, but it does not need to be that way.  Since unprivileged 
> code can not directly manipulate the memory map, its structure can be 
> changed.
>
> If you define separate user, supervisor, and executive memory maps, the 
> CHMx and corresponding RET functions (which are privileged) can just 
> swap the memory maps as needed, giving you the full VMS memory model on 
> a processor with a single unprivileged mode.
>
> Yes, this may result in some inefficiencies in TLB management, but if 
> you are running on a processor that is twice as fast and take a small 
> TLB hit, who cares?
>

Because you have to take two memory map switches and TLB invalidations
per record I/O when using RMS. (Once when the user mode code calls RMS
and once when RMS returns back to the user mode code having performed
the record I/O.)

So to read a file containing 5000 records, you would have to perform
10,000 memory map switches and TLB invalidations in order to read that
file. _Ouch_ :-)

In addition to this overhead, there are additional mode emulation
overheads.

On Alpha, you have PALcode to allow you to implement the VMS specific
functionality in the change mode/return opcodes and which also allows
you to securely implement it in a efficient way as a atomic operation.

On ARM, both RMS and user mode code would be running at the same ARM
unprivileged level. There's no way to implement PALcode like functionality
on ARM processors (at least the ones I am familiar with) so that means
that instead of performing a REI instruction, RMS would have to make
a normal system service call to perform the switch back to the user mode
memory map with a messy fixup of the physical ARM stack required in order
to get back to the correct emulated VMS mode code upon return.

You could track the current emulated mode level within the kernel to
stop user mode code from executing the REI, but that still means that
you would need to perform a full system service call per REI operation.

All this massive overhead means that it does not seem practical to
implement VMS as it stands now on a two mode processor (although
conceptually, switching memory maps is a neat hack even if it does not
appear to be practical in practice).

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/5/2012 6:09:51 PM

On 2012-06-03, Paul Sture <paul.nospam@sture.ch> wrote:
> On Fri, 01 Jun 2012 17:22:37 +0000, Simon Clubley wrote:
>> Would you blindly implement all the special quoting required for ODS-5
>> volumes or would you implement another approach which reduced the
>> special quoting requirements ?
>
> I've always hated that caret business.  Dollar signs in filenames aren't 
> very friendly for a GNV environment either.
>

Agreed on both, but with bash, it's at least very good about inserting the
reserved symbol escape character if you use tab completion.

A refresh of DCL, with current CLI standards in mind, could be quite a
nice thing.

Things I would like to see in a new and improved DCL:

Editing of command lines longer than the terminal width.

Filename tab completion with a list of matching options displayed if you
keep pressing tab.

Incremental recall of commands bash style (hit Ctrl-R and start typing).

Optionally writing out the commands entered in the current session to the
end of a existing history file when you logout and having those commands
automatically available for you at next login as part of the command
history. (I am thinking .bash_history here).

Structured programming constructs (while/do-until/etc).

Associative arrays/sets and supporting set based loop structures. It would
also be nice to have the output from a lexical such as f$search optionally
returned as a set.

Ability to use a regex in a wildcard file specification.

Site specific lexical functions.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/5/2012 6:49:39 PM

In article <jqlkc2$67r$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> 
> A refresh of DCL, with current CLI standards in mind, could be quite a
> nice thing.

   Looking at UNIX shells and DOS command line (including the new fancy
   one),  current CLI substandards are crap I don't need.  An improved DCL
   would be nice.  Some of your ideas aren't bad, but I really don't
   want a complete programming language in DCL.

   My one biggy:  access to VMS constants, like HLLs do through include
   files.


> Optionally writing out the commands entered in the current session to the
> end of a existing history file when you logout and having those commands
> automatically available for you at next login as part of the command
> history. (I am thinking .bash_history here).

   Already exists.  See HELP RECALL /OUTPUT.

0
Reply koehler2 (8314) 6/5/2012 8:27:04 PM

On 2012-06-05, Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote:
> In article <jqlkc2$67r$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> 
>> A refresh of DCL, with current CLI standards in mind, could be quite a
>> nice thing.
>
>    Looking at UNIX shells and DOS command line (including the new fancy
>    one),  current CLI substandards are crap I don't need.  An improved DCL
>    would be nice.  Some of your ideas aren't bad, but I really don't
>    want a complete programming language in DCL.
>
>    My one biggy:  access to VMS constants, like HLLs do through include
>    files.
>

Yes, I love the idea of having access to VMS constants automatically
from within DCL. :-)

>
>> Optionally writing out the commands entered in the current session to the
>> end of a existing history file when you logout and having those commands
>> automatically available for you at next login as part of the command
>> history. (I am thinking .bash_history here).
>
>    Already exists.  See HELP RECALL /OUTPUT.
>

I know about recall/output but it does not do the job in this case.

It outputs all the commands from the current session's recall buffer,
including any from previous sessions loaded at the start of the current
session, instead of only writing out the commands entered during the
current session.

It also overwrites the specified file, instead of merging the contents.

This is a problem when you have multiple DCL sessions at the same time
because you will end up with either a huge history file with multiple
copies of the previous history which grows by the size of the full
recall buffer every time you exit (if you write a routine to add the
current session buffer to the end of the history file) or only the recall
buffer from the last DCL session to exit (if you use recall/output as is).

With bash however, only the commands entered into a session are written
to the history file when the session exits, and they are added to the
existing contents of the history file. This means that when you load
a new instance of bash, all the commands from all previous sessions are
present (up to a defined limit) without any duplicates of the previous
session history. DCL simply cannot do this at the moment.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/5/2012 9:30:12 PM

On Tue, 05 Jun 2012 18:49:39 +0000, Simon Clubley wrote:

> On 2012-06-03, Paul Sture <paul.nospam@sture.ch> wrote:
>> On Fri, 01 Jun 2012 17:22:37 +0000, Simon Clubley wrote:
>>> Would you blindly implement all the special quoting required for ODS-5
>>> volumes or would you implement another approach which reduced the
>>> special quoting requirements ?
>>
>> I've always hated that caret business.  Dollar signs in filenames
>> aren't very friendly for a GNV environment either.
>>
>>
> Agreed on both, but with bash, it's at least very good about inserting
> the reserved symbol escape character if you use tab completion.

Windows CLI tab completion is also very handy, though what that does is 
to surround file names containing spaces with double quotes.
 
> A refresh of DCL, with current CLI standards in mind, could be quite a
> nice thing.
> 
> Things I would like to see in a new and improved DCL:
> 
> Editing of command lines longer than the terminal width.

That's been on my list since we got command line editing :-)

> Filename tab completion with a list of matching options displayed if you
> keep pressing tab.
> 
> Incremental recall of commands bash style (hit Ctrl-R and start typing).
> 
> Optionally writing out the commands entered in the current session to
> the end of a existing history file when you logout and having those
> commands automatically available for you at next login as part of the
> command history. (I am thinking .bash_history here).

I have a bit of DCL which I implemented before RECALL got the ability to 
write its history to file.  I'll dig it out later.

> Structured programming constructs (while/do-until/etc).
> 
> Associative arrays/sets and supporting set based loop structures. It
> would also be nice to have the output from a lexical such as f$search
> optionally returned as a set.

I wouldn't have suggested that myself, but can see the appeal.

> Ability to use a regex in a wildcard file specification.

Yes. Very powerful once you get used to regex.

> Site specific lexical functions.

Why "site specific"?  I can understand "user defined" here.

-- 
Paul Sture
0
Reply paul.nospam (2164) 6/7/2012 12:39:00 PM

On 2012-06-07, Paul Sture <paul.nospam@sture.ch> wrote:
> On Tue, 05 Jun 2012 18:49:39 +0000, Simon Clubley wrote:
>> 
>> Optionally writing out the commands entered in the current session to
>> the end of a existing history file when you logout and having those
>> commands automatically available for you at next login as part of the
>> command history. (I am thinking .bash_history here).
>
> I have a bit of DCL which I implemented before RECALL got the ability to 
> write its history to file.  I'll dig it out later.
>

The main problem here is identifying the commands entered during the
current session from the commands from previous sessions which were
loaded into the recall buffer at the start of the session.

If you have some DCL to do this, I would be interested to see how you
did it, thanks.

>> Site specific lexical functions.
>
> Why "site specific"?  I can understand "user defined" here.
>

Because DCL runs in supervisor mode and hence so do the lexicals it
implements.

This means that either DCL has to switch to user mode before running
user created lexical functions, or, if they are run in supervisor mode,
the system manager has to make a decision that a specific lexical
library can be installed (via a privileged command mechanism) on the
systems they are responsible for.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 6/7/2012 5:19:46 PM

Simon Clubley wrote:
> On 2012-06-04, Chris Scheers <chris@applied-synergy.com> wrote:
>> Johnny Billquist wrote:
>>> On 2012-06-03 08:08, Simon Clubley wrote:
>>>> On 2012-06-02, John Reagan<johnrreagan@earthlink.net>  wrote:
>>>>>
>>>>>> "Simon Clubley"  wrote in message news:jqe14g$87e$1@dont-email.me...
>>>>>> No, based on my understanding of what SWIS provides, that does not 
>>>>>> appear
>>>>>> to be possible.
>>>>>> SWIS appears to be an enabling mechanism in that it provides various
>>>>>> services which were provided by the PALcode on Alpha. What it does 
>>>>>> _not_
>>>>>> appear to be is a enforcing mechanism, at least when it comes to page
>>>>>> protections across multiple rings.
>>>>> At one point after he finished it, Burns Fisher (the designer and
>>>>> implementor of SWIS) said "I think I can do it with two modes."  Of 
>>>>> course
>>>>> he might be wrong, but that's what Burns told me.
>>>>>
>>>> So are you saying that RMS no longer runs in executive mode on IA64 and
>>>> hence no longer requires a MMU which can provide different page 
>>>> protection
>>>> configurations to both executive mode code and kernel mode code ?
>>>>
>>>> Does DCL no longer require supervisor mode page protection from the MMU ?
>>>>
>>>> If so, it would be nice to read a SWIS design document to understand
>>>> how this works. The porting VMS to IA64 briefing document makes a point
>>>> of mentioning that IA64 is a 4 mode architecture and I cannot find
>>>> anything about reducing the number of modes in use.
>>>>
>>>> BTW, there is no way of implementing anything like PALcode on a ARM
>>>> (at least on the ARM cores I am familiar with) so you cannot add missing
>>>> functionality into a PALcode firmware layer as you can on Alpha.
>>> I'm not really clear that there is any requirements for the additional 
>>> protection levels in VMS. You obviously need the user level protection, 
>>> so that normal user programs can't read or modify parts that they are 
>>> not allowed to.
>>> But RMS? Does it really need to be prevented from being able to access 
>>> the kernel memory? It might be good to have both a belt and suspenders, 
>>> but why would it be required? RMS is a piece of the system after all. We 
>>> have full control of the code paths, and knows what it is doing at all 
>>> times. It can't be injected with user code. There is no real need for 
>>> the additional protection, as far as I know. Same for DCL.
>>>
>>> Could someone point out to me what I am missing. Why is it *really* 
>>> needed to have four protection levels?
>>>
>>>     Johnny
>> There seems to be a lot of mysticism about VMS "modes".
>>
>> If you go back to the original VAX, there are really six processor 
>> modes: user, supervisor, executive, kernel, interrupt, compatibility
>>
>> Ignoring compatibility mode, and looking at the modes from a different 
>> functional point of view, there are only two modes: unprivileged and 
>> privileged.  This classification restricts what instructions can be 
>> executed.
>>
>> So what is the difference between user, supervisor, and executive modes? 
>>   These modes all have the same processor model (unprivileged) and 
>> execute the same instructions.  When you get down to it, the ONLY 
>> difference between these modes is the memory map.
>>
> 
> You also need to change stack pointers when switching modes and you need
> to emulate the additional VMS stacks with stack fixups required when
> switching modes.
> 
>> On the VAX, the memory map is a single structure with various KESU 
>> fields/flags, but it does not need to be that way.  Since unprivileged 
>> code can not directly manipulate the memory map, its structure can be 
>> changed.
>>
>> If you define separate user, supervisor, and executive memory maps, the 
>> CHMx and corresponding RET functions (which are privileged) can just 
>> swap the memory maps as needed, giving you the full VMS memory model on 
>> a processor with a single unprivileged mode.
>>
>> Yes, this may result in some inefficiencies in TLB management, but if 
>> you are running on a processor that is twice as fast and take a small 
>> TLB hit, who cares?
>>
> 
> Because you have to take two memory map switches and TLB invalidations
> per record I/O when using RMS. (Once when the user mode code calls RMS
> and once when RMS returns back to the user mode code having performed
> the record I/O.)
> 
> So to read a file containing 5000 records, you would have to perform
> 10,000 memory map switches and TLB invalidations in order to read that
> file. _Ouch_ :-)
> 
> In addition to this overhead, there are additional mode emulation
> overheads.
> 
> On Alpha, you have PALcode to allow you to implement the VMS specific
> functionality in the change mode/return opcodes and which also allows
> you to securely implement it in a efficient way as a atomic operation.
> 
> On ARM, both RMS and user mode code would be running at the same ARM
> unprivileged level. There's no way to implement PALcode like functionality
> on ARM processors (at least the ones I am familiar with) so that means
> that instead of performing a REI instruction, RMS would have to make
> a normal system service call to perform the switch back to the user mode
> memory map with a messy fixup of the physical ARM stack required in order
> to get back to the correct emulated VMS mode code upon return.
> 
> You could track the current emulated mode level within the kernel to
> stop user mode code from executing the REI, but that still means that
> you would need to perform a full system service call per REI operation.
> 
> All this massive overhead means that it does not seem practical to
> implement VMS as it stands now on a two mode processor (although
> conceptually, switching memory maps is a neat hack even if it does not
> appear to be practical in practice).
> 
> Simon.

I didn't say it was optimal.  I just said it could be done.

Now you state that it isn't practical.  Without actual figures, I 
dispute that.

And as current hardware gains in capability, the threshold for what is 
practical keeps changing.

Beyond the basic model outlined above, many optimizations are possible 
that make this more "practical".

Depending on the hardware, TLB invalidations may or may not need to be done.

As opposed to a full system call, a low latency trap into privileged 
code is a boon to implementations like this.  On the Alpha, that is what 
PALCODE is and it is used for the CHMx and REI functionality.  So Alpha 
already partially implements this design.

On the VAX, I used the OPCDEC trap for things like this.

With some creativity, solutions can be found.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris@applied-synergy.com
   Fax: 817-237-3074
0
Reply chris78 (32) 6/7/2012 7:56:06 PM

On Thu, 07 Jun 2012 17:19:46 +0000, Simon Clubley wrote:

> On 2012-06-07, Paul Sture <paul.nospam@sture.ch> wrote:
>> On Tue, 05 Jun 2012 18:49:39 +0000, Simon Clubley wrote:
>>> 
>>> Optionally writing out the commands entered in the current session to
>>> the end of a existing history file when you logout and having those
>>> commands automatically available for you at next login as part of the
>>> command history. (I am thinking .bash_history here).
>>
>> I have a bit of DCL which I implemented before RECALL got the ability
>> to write its history to file.  I'll dig it out later.
>>
>>
> The main problem here is identifying the commands entered during the
> current session from the commands from previous sessions which were
> loaded into the recall buffer at the start of the session.
> 
> If you have some DCL to do this, I would be interested to see how you
> did it, thanks.

Sorry for the delay but here it is.  Contrary to what I said above, it 
does rely on being able to write the recall buffer.  Its advantage over 
the RECALL command is that you can search for keywords anywhere in the 
buffer rather than at the start of lines

In my LOGIN.COM

$ rec :== "pipe recall/all > sys$login:recall.out ; @sys$login:searchbuf"

in searchbuf.com

$! sys$login:searchbuf.com
$! -----------------------
$!
$ if f$search("sys$login:recall.out") .eqs. "" then exit
$ search/match=and sys$login:recall.out 'p1'
$ delete/nolog sys$login:recall.out;*

Usage:

$ rec eve
  1 type eveini.eve
  4 sh log *eve*

$ rec eve,sh  !note no spaces or use "string" so it all goes in P1
  4 sh log *eve*

If you have some form of LOGOUT.COM this idea could be extended to 
preserving recall buffers across sessions and adding to them, sorting, 
what you will.


-- 
Paul Sture
0
Reply paul303 (1382) 8/9/2012 3:10:19 PM

On 2012-08-09, Paul Sture <paul@sture.ch> wrote:
> On Thu, 07 Jun 2012 17:19:46 +0000, Simon Clubley wrote:
>
>> On 2012-06-07, Paul Sture <paul.nospam@sture.ch> wrote:
>>> On Tue, 05 Jun 2012 18:49:39 +0000, Simon Clubley wrote:
>>>> 
>>>> Optionally writing out the commands entered in the current session to
>>>> the end of a existing history file when you logout and having those
>>>> commands automatically available for you at next login as part of the
>>>> command history. (I am thinking .bash_history here).
>>>
>>> I have a bit of DCL which I implemented before RECALL got the ability
>>> to write its history to file.  I'll dig it out later.
>>>
>> The main problem here is identifying the commands entered during the
>> current session from the commands from previous sessions which were
>> loaded into the recall buffer at the start of the session.
>> 
>> If you have some DCL to do this, I would be interested to see how you
>> did it, thanks.
>
> Sorry for the delay but here it is.  Contrary to what I said above, it 
> does rely on being able to write the recall buffer.  Its advantage over 
> the RECALL command is that you can search for keywords anywhere in the 
> buffer rather than at the start of lines
>

Thanks Paul.

What I was looking for was a way to be able to extract automatically only
the commands entered into the recall buffer from the current session.
I would then be able to append them to a combined history log and drop the
older commands once it got over a predefined size.

This functionality be built into bash and it's something which it would be
nice for DCL to have as well.

(Before anyone suggests it, you cannot just dump the whole recall buffer to
a file; think about the sequence of events when you have multiple DCL
sessions going at the same time (with their unique commands entered
during the course of that session), and what will happen when you exit
the sessions one by one.)

Simon.

> In my LOGIN.COM
>
> $ rec :== "pipe recall/all > sys$login:recall.out ; @sys$login:searchbuf"
>
> in searchbuf.com
>
> $! sys$login:searchbuf.com
> $! -----------------------
> $!
> $ if f$search("sys$login:recall.out") .eqs. "" then exit
> $ search/match=and sys$login:recall.out 'p1'
> $ delete/nolog sys$login:recall.out;*
>
> Usage:
>
> $ rec eve
>   1 type eveini.eve
>   4 sh log *eve*
>
> $ rec eve,sh  !note no spaces or use "string" so it all goes in P1
>   4 sh log *eve*
>
> If you have some form of LOGOUT.COM this idea could be extended to 
> preserving recall buffers across sessions and adding to them, sorting, 
> what you will.
>

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/10/2012 12:18:17 PM

Simon Clubley wrote:

> (Before anyone suggests it, you cannot just dump the whole recall buffer to
> a file; 


HELP RECALL on a modern VMS system will show that you can in fact save
your recall buffer to file and restore it from file.
0
Reply jfmezei.spamnot (9469) 8/10/2012 4:14:45 PM

On 2012-08-10, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote:
> Simon Clubley wrote:
>
>> (Before anyone suggests it, you cannot just dump the whole recall buffer to
>> a file; 
>
> HELP RECALL on a modern VMS system will show that you can in fact save
> your recall buffer to file and restore it from file.

Next time JF, you may wish to spend more time reading the message before
responding. :-)

Thanks,

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/10/2012 4:36:14 PM

On 08/10/12 12:18, Simon Clubley wrote:

>
> (Before anyone suggests it, you cannot just dump the whole recall buffer to
> a file; think about the sequence of events when you have multiple DCL
> sessions going at the same time (with their unique commands entered
> during the course of that session), and what will happen when you exit
> the sessions one by one.)
>
> Simon.

I guess you could if you use the pid of the session as key. Multiple bash
sessions seem to handle that quite well...

Regards,

Chris
0
Reply meru (441) 8/11/2012 3:54:36 PM

On Fri, 10 Aug 2012 12:18:17 +0000, Simon Clubley wrote:

> On 2012-08-09, Paul Sture <paul@sture.ch> wrote:
>> On Thu, 07 Jun 2012 17:19:46 +0000, Simon Clubley wrote:
>>
>>> On 2012-06-07, Paul Sture <paul.nospam@sture.ch> wrote:
>>>> On Tue, 05 Jun 2012 18:49:39 +0000, Simon Clubley wrote:
>>>>> 
>>>>> Optionally writing out the commands entered in the current session
>>>>> to the end of a existing history file when you logout and having
>>>>> those commands automatically available for you at next login as part
>>>>> of the command history. (I am thinking .bash_history here).
>>>>
>>>> I have a bit of DCL which I implemented before RECALL got the ability
>>>> to write its history to file.  I'll dig it out later.
>>>>
>>> The main problem here is identifying the commands entered during the
>>> current session from the commands from previous sessions which were
>>> loaded into the recall buffer at the start of the session.
>>> 
>>> If you have some DCL to do this, I would be interested to see how you
>>> did it, thanks.
>>
>> Sorry for the delay but here it is.  Contrary to what I said above, it
>> does rely on being able to write the recall buffer.  Its advantage over
>> the RECALL command is that you can search for keywords anywhere in the
>> buffer rather than at the start of lines
>>
>>
> Thanks Paul.
> 
> What I was looking for was a way to be able to extract automatically
> only the commands entered into the recall buffer from the current
> session.

I have to admit that when I wrote my original message I had forgotten 
exactly what my bit of DCL did. :-)

> I would then be able to append them to a combined history log and drop
> the older commands once it got over a predefined size.
> 
> This functionality be built into bash and it's something which it would
> be nice for DCL to have as well.

Yes.

> (Before anyone suggests it, you cannot just dump the whole recall buffer
> to a file; think about the sequence of events when you have multiple DCL
> sessions going at the same time (with their unique commands entered
> during the course of that session), and what will happen when you exit
> the sessions one by one.)

I am sure it could be done in DCL, but doing it without creating a 
monster would require careful thought.

-- 
Paul Sture
0
Reply paul.nospam (2164) 8/11/2012 5:54:20 PM

On 2012-08-11, ChrisQ <meru@devnull.com> wrote:
> On 08/10/12 12:18, Simon Clubley wrote:
>
>>
>> (Before anyone suggests it, you cannot just dump the whole recall buffer to
>> a file; think about the sequence of events when you have multiple DCL
>> sessions going at the same time (with their unique commands entered
>> during the course of that session), and what will happen when you exit
>> the sessions one by one.)
>>
>> Simon.
>
> I guess you could if you use the pid of the session as key. Multiple bash
> sessions seem to handle that quite well...
>

The problem is that the combined entire history (up to a limit) from all
previous sessions is loaded into any new session. In bash, when you exit
a session, bash knows which commands were entered during the new session
and only adds those new commands to the combined history file, even though
there can be several thousand commands in the bash recall buffer.

In VMS, when you write out the recall history to a file, there's no way to
isolate the commands entered at the DCL prompt during the current session
from those loaded into the recall buffer at the start of the session.

Therefore, you would have to write out the full recall buffer and each
DCL session would write out it's own version of the full recall buffer.

This would effectively clobber the history from any other DCL session
which had been running at the same time (even if you allowed the history
to be appended into what would quickly become a _massive_ history file)
as you can only reload a maximum of 254 commands back into the recall
buffer.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/12/2012 11:10:59 AM

At the risk of taking this thread even further off into tangents unknown, c=
ould someone explain the BENEFIT of being able to recall commands from past=
 sessions?  It seems like a lot of work to implement (BASH or DCL) and I ca=
n't remember any time I needed to recall a command from a prior session tha=
t I couldn't retype from scratch.  I mean, really, how complicated are the =
command lines you're building?

Generally speaking, for my purposes, command recall more than a dozen or so=
 commands back in the current session has been unnecessary.  And even then =
I'm just being too lazy to type it in again.
0
Reply sapienza (410) 8/12/2012 2:10:56 PM

On 2012-08-12, FrankS <sapienza@noesys.com> wrote:
> At the risk of taking this thread even further off into tangents unknown,
> could someone explain the BENEFIT of being able to recall commands from past
> sessions?  It seems like a lot of work to implement (BASH or DCL) and I can't
> remember any time I needed to recall a command from a prior session that I
> couldn't retype from scratch.  I mean, really, how complicated are the command
> lines you're building?
>

It's not only the length of the commands, but also having quick and easy
ways of recalling them and constructing them. In bash, you can type Ctrl-R
followed by a few characters and keep hitting Ctrl-R until the matching
command is found. Tab completion makes it very easy to construct long
command lines as well.

This means that instead of having lots of little files floating around
with one line commands in them, it's _much_ easier to use the command
history file to hold the commands.

Generally, when I am working on something, I work on it for more than one
day. I also have a series of commands I use on a regular basis. In either
case, I can just type a few characters per command the next day and have
the command available once again.

Using a command history file is self maintaining as well. When I have not
used the commands for a while, they will automatically be removed from
the history file without me having to delete anything.

You asked for some example commands. I cannot discuss anything I am doing
at work, but below are some examples from home. I am currently doing some
work on a USB device stack of mine and it's very easy to find the related
sets of commands and PDF documents when I pick it up the next evening.
[I have a large (but organised) reference library and with tab completion
it's as quick to find a document from the command line as it is to use
a GUI browser, especially when you can recall the command and use it to
find related documents or use locate or find on the reference library
tree.]

stty -F /dev/ttyS3 raw -echo time 60 min 0 -crtscts -hupcl

xpdf /reflib/arm_arch_docs/cpu_docs/arm7dtmi/atmel/doc6175_AT91SAM7S_DS.pdf &

The following command is one command; I've broken it into several lines.
There are also variants for burning to flash and for different images.
There are also related commands for running ddd (and specifying the
required gdb backend) on the command line. It's _very_ easy to recall
one of these variants the next day with a few characters.

FNAME=/sd/arm-test/usb-dev-h256/usb-dev-h256_sram.bin
	/projs2/embedded/exe-openocd-0.4.0/bin/openocd
	-f /sd/simuclib/scripts/arm/sam7s256/openocd-pp-ram-run.cmd

>Generally speaking, for my purposes, command recall more than a dozen or so
> commands back in the current session has been unnecessary.  And even then I'm
> just being too lazy to type it in again.

With a permanent command history, easy recall of commands ($ recall/search
does _NOT_ qualify as easy recall) and tab completion of filenames, it's
something I really miss even on repeated short commands when it's not
available. If it's anything more complicated than viewing a file in the
current directory, it's quicker to get it from the command history under
bash.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/12/2012 4:03:52 PM

Simon Clubley wrote:
> On 2012-08-12, FrankS <sapienza@noesys.com> wrote:
>> At the risk of taking this thread even further off into tangents unknown,
>> could someone explain the BENEFIT of being able to recall commands from past
>> sessions?  It seems like a lot of work to implement (BASH or DCL) and I can't
>> remember any time I needed to recall a command from a prior session that I
>> couldn't retype from scratch.  I mean, really, how complicated are the command
>> lines you're building?
>>
> 
> It's not only the length of the commands, but also having quick and easy
> ways of recalling them and constructing them. In bash, you can type Ctrl-R
> followed by a few characters and keep hitting Ctrl-R until the matching
> command is found. Tab completion makes it very easy to construct long
> command lines as well.
> 
> This means that instead of having lots of little files floating around
> with one line commands in them, it's _much_ easier to use the command
> history file to hold the commands.
> 
> Generally, when I am working on something, I work on it for more than one
> day. I also have a series of commands I use on a regular basis. In either
> case, I can just type a few characters per command the next day and have
> the command available once again.
> 
> Using a command history file is self maintaining as well. When I have not
> used the commands for a while, they will automatically be removed from
> the history file without me having to delete anything.
> 
> You asked for some example commands. I cannot discuss anything I am doing
> at work, but below are some examples from home. I am currently doing some
> work on a USB device stack of mine and it's very easy to find the related
> sets of commands and PDF documents when I pick it up the next evening.
> [I have a large (but organised) reference library and with tab completion
> it's as quick to find a document from the command line as it is to use
> a GUI browser, especially when you can recall the command and use it to
> find related documents or use locate or find on the reference library
> tree.]
> 
> stty -F /dev/ttyS3 raw -echo time 60 min 0 -crtscts -hupcl
> 
> xpdf /reflib/arm_arch_docs/cpu_docs/arm7dtmi/atmel/doc6175_AT91SAM7S_DS.pdf &
> 
> The following command is one command; I've broken it into several lines.
> There are also variants for burning to flash and for different images.
> There are also related commands for running ddd (and specifying the
> required gdb backend) on the command line. It's _very_ easy to recall
> one of these variants the next day with a few characters.
> 
> FNAME=/sd/arm-test/usb-dev-h256/usb-dev-h256_sram.bin
> 	/projs2/embedded/exe-openocd-0.4.0/bin/openocd
> 	-f /sd/simuclib/scripts/arm/sam7s256/openocd-pp-ram-run.cmd
> 
>> Generally speaking, for my purposes, command recall more than a dozen or so
>> commands back in the current session has been unnecessary.  And even then I'm
>> just being too lazy to type it in again.
> 
> With a permanent command history, easy recall of commands ($ recall/search
> does _NOT_ qualify as easy recall) and tab completion of filenames, it's
> something I really miss even on repeated short commands when it's not
> available. If it's anything more complicated than viewing a file in the
> current directory, it's quicker to get it from the command history under
> bash.
> 
> Simon.
> 

Well, frankly, I'm with Frank on this one ....

(Ok, stop with the boos and hisses)

I feel that command recall is very useful, but, only for the last 20-40 
commands.  If you have some complex commands that you perform often, why not 
have a command file you can invoke?  Yes, that is about what a permanent recall 
buffer might be considered.  But if the command is complex enough, the command 
file is, to me anyway, easier to maintain.

I understand that VMS is used in many ways.  Just when I think I've seen all of 
them, I get my nose rubbed in another.  So I'm open to some usage somewhere, but 
in general, I see it (permanent command buffer) as something that gets used 
because some feel it is useful, but I just don't see it.

In the traditional VT terminal session, you're communicating with a computer. 
What I'm saying today is what I have to say today.  If talking to a person, I 
don't keep saying "what I said yesterday, what I said 2 months ago, what I said 
3 weeks ago, ....".  I just say what I have to say right now.  I just feel that 
at some point it can be easier to just "say" what you have to say than finding a 
command from a hugh recall buffer.  I just don't comprehend a thousand or more 
commands that I'm going to retrieve and modify and use over and over.  If I have 
a procedure that I want to use periodically, I build a command file and perhaps 
have it re-queue itself in a batch queue.

I also sometimes find the editing of a command more difficult than just typing 
the desired command.

About the most use I make of command recall is when I'm working on a program and 
not doing so well.  I might use the up-arrow key to keep repeating maybe 4-5 
commands, EDT, COMPILE, LINK, PURGE, RUN.  Even then, it can be a close call 
between recalling commands and just re-typing them.
0
Reply davef3 (3717) 8/12/2012 5:04:27 PM

On Sunday, August 12, 2012 12:03:52 PM UTC-4, Simon Clubley wrote:
> ... lots ...

Okay, the discussion is about implementing on OpenVMS a command recall faci=
lity similar to that available in BASH.  So, my question was related to wha=
t you're doing on OpenVMS that makes a more extensive command recall necess=
ary.  Providing examples of what you're doing on BASH doesn't quite cut it =
for me, because we have ways of working around things on OpenVMS that might=
 not be available on Unix and its variants.

For example, you mention the ability to type a few characters to recall a s=
ingle, often-used, complex command.  I do that now on OpenVMS by setting up=
 a global symbol in my login procedure.  It's much easier -- IMHO -- to rem=
ember the command shortcut and retype it than it is to go through some keys=
trokes to recall the command from a permanent command buffer.  And if I'm u=
sing the same command(s) day in and day out, all day long, then I definitel=
y want a shortcut rather than having to recall it from a command buffer the=
 next day.

The other example you mention is of commands that are often used but requir=
e some slight modification.  Again, on OpenVMS I do the same thing using a =
command procedure.  I can make the procedure as complex or as simple as nee=
ded to take a set of parameters and generate the command I need.  For the r=
ecord, I have no single-line command procedures (for this or any other purp=
ose).

As for popping up a PDF reference library, that example isn't relevant in t=
hat all of my OpenVMS access is via terminal emulation.  Not a single DECwi=
ndows session in sight.  All my customers use Windows on the desktop, and s=
o I have all my PDF documents organized in Windows such that I can go find =
the book/library I need fairly easily.  Just a few clicks and I'm in the fo=
lder I need, then double-click to bring up the document.  If I need the sam=
e document day after day, it's not really a significant problem to go throu=
gh the same process the next day.

So I'm still unconvinced that the existing OpenVMS facilities need to be au=
gmented by a permanent command buffer, and all the associated headaches rel=
ated to consolidating those buffers across multiple terminal sessions.

0
Reply sapienza (410) 8/13/2012 3:34:24 PM

Op zaterdag 11 augustus 2012 19:54:20 UTC+2 schreef Paul Sture het volgende:

> I am sure it could be done in DCL, but doing it without creating a 
> 
> monster would require careful thought.

And what about recall/output and recall/input? Or am I missing the point completely?
0
Reply peutbaars1 (24) 8/13/2012 11:35:38 PM

On Mon, 13 Aug 2012 08:34:24 -0700, FrankS wrote:

> Providing examples of what you're doing on BASH doesn't quite cut it for
> me, because we have ways of working around things on OpenVMS that might
> not be available on Unix and its variants.
> 
> For example, you mention the ability to type a few characters to recall
> a single, often-used, complex command.  I do that now on OpenVMS by
> setting up a global symbol in my login procedure.

When I used to spend a lot of time working on a large variety of customer 
machines I didn't want a large LOGIN.COM.  Yes I had a few favourites but 
I really didn't want to form the habit of relying on a customised login 
procedure.

This approach was vindicated by a former colleague who had got so used to 
his heavily customised login that when he came across a virgin system he 
couldn't work with the native VMS commands alone, and wrote a quick and 
dirty assembler program to get his LOGIN.COM across a serial line.

> So I'm still unconvinced that the existing OpenVMS facilities need to be
> augmented by a permanent command buffer, and all the associated
> headaches related to consolidating those buffers across multiple
> terminal sessions.

At one time I would have agreed with you, but the more I am exposed to 
other systems, the more useful I see such features.  Command line 
completion is another feature I miss when I go back to VMS - it really is 
useful.

-- 
Paul Sture
0
Reply paul.nospam (2164) 8/14/2012 8:43:02 AM

On 2012-08-14 10:43, Paul Sture wrote:
> On Mon, 13 Aug 2012 08:34:24 -0700, FrankS wrote:
>
>> So I'm still unconvinced that the existing OpenVMS facilities need to be
>> augmented by a permanent command buffer, and all the associated
>> headaches related to consolidating those buffers across multiple
>> terminal sessions.
>
> At one time I would have agreed with you, but the more I am exposed to
> other systems, the more useful I see such features.  Command line
> completion is another feature I miss when I go back to VMS - it really is
> useful.

Yes, I really wish TOPS-20 would come back, from which much of this 
really stems... :-)

As for saving and retrieving the command history between sessions - it's 
pretty much only useful if you also have a usable way of quickly search 
and recall commands from the history. As DCL lacks that, I don't see 
persistent, large command history as a useful addition to DCL. Now, 
better command searching and recalling would be a very nice thing to have.

Completion of filenames and commands would also be very nice. Did 
DCLCOMPLETE ever get ported beyond VAX?

	Johnny

0
Reply bqt2 (1410) 8/14/2012 9:32:00 AM

On 8/14/12 5:32 AM, in article k0d5ug$dpv$1@Iltempo.Update.UU.SE, "Johnny
Billquist" <bqt@softjar.se> wrote:

> On 2012-08-14 10:43, Paul Sture wrote:
>> On Mon, 13 Aug 2012 08:34:24 -0700, FrankS wrote:
>> 
>>> So I'm still unconvinced that the existing OpenVMS facilities need to be
>>> augmented by a permanent command buffer, and all the associated
>>> headaches related to consolidating those buffers across multiple
>>> terminal sessions.
>> 
>> At one time I would have agreed with you, but the more I am exposed to
>> other systems, the more useful I see such features.  Command line
>> completion is another feature I miss when I go back to VMS - it really is
>> useful.
> 
> Yes, I really wish TOPS-20 would come back, from which much of this
> really stems... :-)
> 
> As for saving and retrieving the command history between sessions - it's
> pretty much only useful if you also have a usable way of quickly search
> and recall commands from the history. As DCL lacks that, I don't see
> persistent, large command history as a useful addition to DCL. Now,
> better command searching and recalling would be a very nice thing to have.
> 
> Completion of filenames and commands would also be very nice. Did
> DCLCOMPLETE ever get ported beyond VAX?
> 
> Johnny
> 
I don't understand why this cannot be done on the client side?
Back when I was logging in via a terminal server to our Alpha/Vax systems
(1999 or so), I used a terminal emulator that had a mode where you could
completely type your command line, edit it if need be, and then send it to
the remote system.

0
Reply winston19842005 (232) 8/14/2012 11:46:56 AM

On 2012-08-13, Jose Baars <peutbaars@gmail.com> wrote:
> Op zaterdag 11 augustus 2012 19:54:20 UTC+2 schreef Paul Sture het volgende:
>
>> I am sure it could be done in DCL, but doing it without creating a 
>> 
>> monster would require careful thought.
>
> And what about recall/output and recall/input? Or am I missing the point completely?

Yes, you are. :-)

If you read my previous postings, I have explained the issues in detail
and why what works with bash is not supported in VMS as it stands.

(Although Hoff's suggested hack about inserting a marker is a good one
and solves _part_ of the problem.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/14/2012 6:46:32 PM

On 2012-08-14, Paul Sture <paul.nospam@sture.ch> wrote:
> On Mon, 13 Aug 2012 08:34:24 -0700, FrankS wrote:
>
>> Providing examples of what you're doing on BASH doesn't quite cut it for
>> me, because we have ways of working around things on OpenVMS that might
>> not be available on Unix and its variants.
>> 

I was trying more to explain a general workflow which I use in bash and
would like to use in VMS. I explained the other things because you need
the tools to be able to access the command history (and construct new
commands) in a efficient way in order for my preferred workflow to be
viable.

However, I do have a direct like-for-like example which I had forgotten
about when I posted my response. I recently looked at the slrn (it's a
newsreader) and slang (required support library for slrn) source trees
on both VMS and Linux.

On VMS, I found it cumbersome to move around the source tree and find
things in the code, and at one point, knowing what was possible on Linux,
I actually said "sod this" and went and did my digging around on Linux.
On Linux, I found it quick and efficient to move around the source trees
and do the same things I was trying to do on VMS.

In this case, I was mainly missing directory/filename completion and
efficient recall of previous commands.

>> So I'm still unconvinced that the existing OpenVMS facilities need to be
>> augmented by a permanent command buffer, and all the associated
>> headaches related to consolidating those buffers across multiple
>> terminal sessions.
>
> At one time I would have agreed with you, but the more I am exposed to 
> other systems, the more useful I see such features.  Command line 
> completion is another feature I miss when I go back to VMS - it really is 
> useful.
>

Thinking about it, I think this is the core issue.

Sometimes when you look at other systems, you think "yuck, VMS is far
better at that", but other times you think "this is really nice and I
wish VMS could do this".

Quite a bit of what I am asking for can be done in a different way with
DCL, even if it's not as elegant as under bash. However, it's all the
little things in bash which come together as a whole and produce, for
me, a seamless workflow and it's really hard to describe the resultant
whole unless you have experienced it.

I think it's a case of not missing something you have never been
exposed to. (And, yes, I accept the workflow of other people will be
different from my own and hence they may not put as much emphasis on
these capabilities even if they were exposed to them.)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
0
Reply clubley (1478) 8/14/2012 8:16:00 PM

On 2012-08-14 13:46, Winston19842005 wrote:
> On 8/14/12 5:32 AM, in article k0d5ug$dpv$1@Iltempo.Update.UU.SE, "Johnny
> Billquist" <bqt@softjar.se> wrote:
>
>> On 2012-08-14 10:43, Paul Sture wrote:
>>> On Mon, 13 Aug 2012 08:34:24 -0700, FrankS wrote:
>>>
>>>> So I'm still unconvinced that the existing OpenVMS facilities need to be
>>>> augmented by a permanent command buffer, and all the associated
>>>> headaches related to consolidating those buffers across multiple
>>>> terminal sessions.
>>>
>>> At one time I would have agreed with you, but the more I am exposed to
>>> other systems, the more useful I see such features.  Command line
>>> completion is another feature I miss when I go back to VMS - it really is
>>> useful.
>>
>> Yes, I really wish TOPS-20 would come back, from which much of this
>> really stems... :-)
>>
>> As for saving and retrieving the command history between sessions - it's
>> pretty much only useful if you also have a usable way of quickly search
>> and recall commands from the history. As DCL lacks that, I don't see
>> persistent, large command history as a useful addition to DCL. Now,
>> better command searching and recalling would be a very nice thing to have.
>>
>> Completion of filenames and commands would also be very nice. Did
>> DCLCOMPLETE ever get ported beyond VAX?
>>
>> Johnny
>>
> I don't understand why this cannot be done on the client side?
> Back when I was logging in via a terminal server to our Alpha/Vax systems
> (1999 or so), I used a terminal emulator that had a mode where you could
> completely type your command line, edit it if need be, and then send it to
> the remote system.

How would that deal with when you do not want echo of what you are 
typing? Or when you actually are running in a mode where each keystroke 
are acted upon, such as when you are running EDT?

	Johnny

0
Reply bqt2 (1410) 8/14/2012 9:59:24 PM

In article <k0eblu$knk$1@dont-email.me>,
 Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> I think it's a case of not missing something you have never been
> exposed to. (And, yes, I accept the workflow of other people will be
> different from my own and hence they may not put as much emphasis on
> these capabilities even if they were exposed to them.)

Remember command and filename completion on TOPS-20?  Fantastic.

I interviewed for the VMS team once.  They asked me what I'd want to do 
under the radar.  I told them I'd want to look into making the CLI more 
pluggable.  That is, if I want to run DCL, fine.  But if I want to run 
the MCR interpreter, or bash-for-VMS, it should be trivial.  I'd want to 
work on making it so.  For some reason, they didn't hire me. :-/

-- 
May joy be yours all the days of your life! - Phina
We are but a moment's sunlight, fading in the grass. - The Youngbloods
Those who eat natural foods die of natural causes. - Kperspective
0
Reply howard578 (2137) 8/14/2012 10:23:45 PM

On 8/14/12 5:59 PM, in article k0ehns$450$1@Iltempo.Update.UU.SE, "Johnny
Billquist" <bqt@softjar.se> wrote:

> On 2012-08-14 13:46, Winston19842005 wrote:

>> I don't understand why this cannot be done on the client side?
>> Back when I was logging in via a terminal server to our Alpha/Vax systems
>> (1999 or so), I used a terminal emulator that had a mode where you could
>> completely type your command line, edit it if need be, and then send it to
>> the remote system.
> 
> How would that deal with when you do not want echo of what you are
> typing? Or when you actually are running in a mode where each keystroke
> are acted upon, such as when you are running EDT?
> 
> Johnny
> 

It was a simple switch from buffered back to the original terminal, just a
keypress away.

0
Reply winston19842005 (232) 8/15/2012 12:28:47 AM

On 2012-08-15 02:28, Winston19842005 wrote:
> On 8/14/12 5:59 PM, in article k0ehns$450$1@Iltempo.Update.UU.SE, "Johnny
> Billquist" <bqt@softjar.se> wrote:
>
>> On 2012-08-14 13:46, Winston19842005 wrote:
>
>>> I don't understand why this cannot be done on the client side?
>>> Back when I was logging in via a terminal server to our Alpha/Vax systems
>>> (1999 or so), I used a terminal emulator that had a mode where you could
>>> completely type your command line, edit it if need be, and then send it to
>>> the remote system.
>>
>> How would that deal with when you do not want echo of what you are
>> typing? Or when you actually are running in a mode where each keystroke
>> are acted upon, such as when you are running EDT?
>>
>> Johnny
>>
>
> It was a simple switch from buffered back to the original terminal, just a
> keypress away.

The problem being that you can miss it, or not even be aware of this 
being required.
Sure, you can run with local echo and local editing. For many, that is 
not an attractive solution, which is why a host based solution is asked for.

	Johnny

0
Reply bqt2 (1410) 8/15/2012 9:00:38 AM

In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
 Johnny Billquist <bqt@softjar.se> wrote:


> As for saving and retrieving the command history between sessions - it's 
> pretty much only useful if you also have a usable way of quickly search 
> and recall commands from the history. 

You mean like RECALL/SEARCH.

$ help recall/search

RECALL

  /SEARCH

        /SEARCH string

     Searches the recall buffer and displays all the commands (and
     their numbers) that contain the specified search string.
0
Reply craigberry (308) 8/15/2012 12:36:04 PM

On Tue, 14 Aug 2012 20:16:00 +0000, Simon Clubley wrote:

> On VMS, I found it cumbersome to move around the source tree and find
> things in the code, and at one point, knowing what was possible on
> Linux, I actually said "sod this" and went and did my digging around on
> Linux. On Linux, I found it quick and efficient to move around the
> source trees and do the same things I was trying to do on VMS.

That is precisely what I was doing for years with Windows, particularly 
with a corporate box I wasn't allowed to install a decent editor on.  I 
too would say "sod this" and whiz something across to VMS to get 
something done.

However the other week when I was poking around some of the VMS Freeware 
stuff I basically did what you did and lobbed it onto a Linux system.

Another point here is that the original limit of directory nesting on VMS 
forced a different structure on source trees.  Traditionally on VMS we 
would have a full program suite (e.g. payroll) in one directory rather 
than using a directory tree per program.  This made recompiling the lot 
in one go very simple, but it wasn't as flexible as a system which has 
the version number built into the top of the directory tree.

And yes, with my VMS background it did take me some time to get my head 
around this. 

-- 
Paul Sture
0
Reply paul.nospam (2164) 8/15/2012 1:27:30 PM

On 2012-08-15 14:36, Craig A. Berry wrote:
> In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
>   Johnny Billquist <bqt@softjar.se> wrote:
>
>
>> As for saving and retrieving the command history between sessions - it's
>> pretty much only useful if you also have a usable way of quickly search
>> and recall commands from the history.
>
> You mean like RECALL/SEARCH.
>
> $ help recall/search
>
> RECALL
>
>    /SEARCH
>
>          /SEARCH string
>
>       Searches the recall buffer and displays all the commands (and
>       their numbers) that contain the specified search string.

That is not my definition of quick search and recall... Which was my point.

	Johnny

0
Reply bqt2 (1410) 8/15/2012 7:45:29 PM

In article <k0gu8p$sdn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2012-08-15 14:36, Craig A. Berry wrote:
>> In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
>>   Johnny Billquist <bqt@softjar.se> wrote:
>>
>>
>>> As for saving and retrieving the command history between sessions - it's
>>> pretty much only useful if you also have a usable way of quickly search
>>> and recall commands from the history.
>>
>> You mean like RECALL/SEARCH.
>>
>> $ help recall/search
>>
>> RECALL
>>
>>    /SEARCH
>>
>>          /SEARCH string
>>
>>       Searches the recall buffer and displays all the commands (and
>>       their numbers) that contain the specified search string.
>
>That is not my definition of quick search and recall... Which was my point.

It seems pretty quick here.

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 8/15/2012 8:36:45 PM

On 2012-08-15 22:36, VAXman- @SendSpamHere.ORG wrote:
> In article <k0gu8p$sdn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> On 2012-08-15 14:36, Craig A. Berry wrote:
>>> In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
>>>    Johnny Billquist <bqt@softjar.se> wrote:
>>>
>>>
>>>> As for saving and retrieving the command history between sessions - it's
>>>> pretty much only useful if you also have a usable way of quickly search
>>>> and recall commands from the history.
>>>
>>> You mean like RECALL/SEARCH.
>>>
>>> $ help recall/search
>>>
>>> RECALL
>>>
>>>     /SEARCH
>>>
>>>           /SEARCH string
>>>
>>>        Searches the recall buffer and displays all the commands (and
>>>        their numbers) that contain the specified search string.
>>
>> That is not my definition of quick search and recall... Which was my point.
>
> It seems pretty quick here.

Compare that to something like M-P i tcsh or ^R in bash... Which is 
typed interactively at the terminal, and for which you get the result 
immediately, and can continue and edit the line right away...

	Johnny

0
Reply bqt2 (1410) 8/15/2012 10:22:13 PM

On 2012-08-16 00:22, Johnny Billquist wrote:
> On 2012-08-15 22:36, VAXman- @SendSpamHere.ORG wrote:
>> In article <k0gu8p$sdn$1@Iltempo.Update.UU.SE>, Johnny Billquist
>> <bqt@softjar.se> writes:
>>> On 2012-08-15 14:36, Craig A. Berry wrote:
>>>> In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
>>>>    Johnny Billquist <bqt@softjar.se> wrote:
>>>>
>>>>
>>>>> As for saving and retrieving the command history between sessions -
>>>>> it's
>>>>> pretty much only useful if you also have a usable way of quickly
>>>>> search
>>>>> and recall commands from the history.
>>>>
>>>> You mean like RECALL/SEARCH.
>>>>
>>>> $ help recall/search
>>>>
>>>> RECALL
>>>>
>>>>     /SEARCH
>>>>
>>>>           /SEARCH string
>>>>
>>>>        Searches the recall buffer and displays all the commands (and
>>>>        their numbers) that contain the specified search string.
>>>
>>> That is not my definition of quick search and recall... Which was my
>>> point.
>>
>> It seems pretty quick here.
>
> Compare that to something like M-P i tcsh or ^R in bash... Which is
> typed interactively at the terminal, and for which you get the result
> immediately, and can continue and edit the line right away...

Maybe I should clarify that by "quick search and recall" I did not mean 
execution time to do the actual search, but how quick and convenient it 
is to access for a user. As such, typing whole commands, perhaps several 
commands, to do it, makes it cumbersome compared to just pressing a key 
or two, and have the whole process done for you in the current command line.

	Johnny

0
Reply bqt2 (1410) 8/15/2012 10:43:02 PM

In article <k0h8lu$vqn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2012-08-16 00:22, Johnny Billquist wrote:
>> On 2012-08-15 22:36, VAXman- @SendSpamHere.ORG wrote:
>>> In article <k0gu8p$sdn$1@Iltempo.Update.UU.SE>, Johnny Billquist
>>> <bqt@softjar.se> writes:
>>>> On 2012-08-15 14:36, Craig A. Berry wrote:
>>>>> In article <k0d5ug$dpv$1@Iltempo.Update.UU.SE>,
>>>>>    Johnny Billquist <bqt@softjar.se> wrote:
>>>>>
>>>>>
>>>>>> As for saving and retrieving the command history between sessions -
>>>>>> it's
>>>>>> pretty much only useful if you also have a usable way of quickly
>>>>>> search
>>>>>> and recall commands from the history.
>>>>>
>>>>> You mean like RECALL/SEARCH.
>>>>>
>>>>> $ help recall/search
>>>>>
>>>>> RECALL
>>>>>
>>>>>     /SEARCH
>>>>>
>>>>>           /SEARCH string
>>>>>
>>>>>        Searches the recall buffer and displays all the commands (and
>>>>>        their numbers) that contain the specified search string.
>>>>
>>>> That is not my definition of quick search and recall... Which was my
>>>> point.
>>>
>>> It seems pretty quick here.
>>
>> Compare that to something like M-P i tcsh or ^R in bash... Which is
>> typed interactively at the terminal, and for which you get the result
>> immediately, and can continue and edit the line right away...
>
>Maybe I should clarify that by "quick search and recall" I did not mean 
>execution time to do the actual search, but how quick and convenient it 
>is to access for a user. As such, typing whole commands, perhaps several 
>commands, to do it, makes it cumbersome compared to just pressing a key 
>or two, and have the whole process done for you in the current command line.
>
>	Johnny
>

OK.  So, put a wrapper around DCL.EXE and introduce your OWN ^R handler 
to read in the recall buffer and provide editing.  Of course, a ^R has
been used as a screen refresh in a number of VMS products/utilities, so
you willl probably want to use some other control char.  You can still
specify your OWN CLI in your UAF record!

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 8/16/2012 12:54:59 PM

Op donderdag 16 augustus 2012 14:54:59 UTC+2 schreef (onbekend) het volgende:
>  You can still specify your OWN CLI in your UAF record!

Are there any examples including sources of this available somewhere?
Just curious.
0
Reply peutbaars1 (24) 8/16/2012 2:24:51 PM

On 2012-08-16 14:54, VAXman- @SendSpamHere.ORG wrote:
> In article <k0h8lu$vqn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> Maybe I should clarify that by "quick search and recall" I did not mean
>> execution time to do the actual search, but how quick and convenient it
>> is to access for a user. As such, typing whole commands, perhaps several
>> commands, to do it, makes it cumbersome compared to just pressing a key
>> or two, and have the whole process done for you in the current command line.
>>
>> 	Johnny
>>
>
> OK.  So, put a wrapper around DCL.EXE and introduce your OWN ^R handler
> to read in the recall buffer and provide editing.  Of course, a ^R has
> been used as a screen refresh in a number of VMS products/utilities, so
> you willl probably want to use some other control char.  You can still
> specify your OWN CLI in your UAF record!

Certainly doable. But that is another thing. We were (I thought) talking 
about history preservation and use cases in DCL compared to shells like 
bash. Some people questioned the need to preserve history between 
sessions. I made a comment that without quick search and recall of the 
command history, I don't see much point in preserving history between 
sessions either, as it really only becomes useful (in my opinion) once 
you can easily and quickly search and recall your command history. And 
as (in my opinion) that does not exist in DCL, the need for history 
preservation isn't that big either.

Writing my own CLI for VMS does nothing for changing how DCL works, not 
to mention the non-existing documentation for doing such a thing.

Also, unless I remember wrong, tcsh (and I think bash) have already been 
ported to VMS, so I can just as well just use them.
They are not proper CLIs, though, if I understand things right, but just 
user applications (quite like how they are under Unix).

	Johnny

0
Reply bqt2 (1410) 8/16/2012 8:09:32 PM

In article <k0jk23$nou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2012-08-16 14:54, VAXman- @SendSpamHere.ORG wrote:
>> In article <k0h8lu$vqn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>> Maybe I should clarify that by "quick search and recall" I did not mean
>>> execution time to do the actual search, but how quick and convenient it
>>> is to access for a user. As such, typing whole commands, perhaps several
>>> commands, to do it, makes it cumbersome compared to just pressing a key
>>> or two, and have the whole process done for you in the current command line.
>>>
>>> 	Johnny
>>>
>>
>> OK.  So, put a wrapper around DCL.EXE and introduce your OWN ^R handler
>> to read in the recall buffer and provide editing.  Of course, a ^R has
>> been used as a screen refresh in a number of VMS products/utilities, so
>> you willl probably want to use some other control char.  You can still
>> specify your OWN CLI in your UAF record!
>
>Certainly doable. But that is another thing. We were (I thought) talking 
>about history preservation and use cases in DCL compared to shells like 
>bash. Some people questioned the need to preserve history between 
>sessions. I made a comment that without quick search and recall of the 
>command history, I don't see much point in preserving history between 
>sessions either, as it really only becomes useful (in my opinion) once 
>you can easily and quickly search and recall your command history. And 
>as (in my opinion) that does not exist in DCL, the need for history 
>preservation isn't that big either.
>
>Writing my own CLI for VMS does nothing for changing how DCL works, not 
>to mention the non-existing documentation for doing such a thing.

Who said write a CLI?  I merely suggested "augmentation" of DCL.



>Also, unless I remember wrong, tcsh (and I think bash) have already been 
>ported to VMS, so I can just as well just use them.
>They are not proper CLIs, though, if I understand things right, but just 
>user applications (quite like how they are under Unix).

Neither are implemented as a CLI; just user programs and they're a bit
of a kludge at that.

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 8/16/2012 11:05:31 PM

On 2012-08-17 01:05, VAXman- @SendSpamHere.ORG wrote:
> In article <k0jk23$nou$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> On 2012-08-16 14:54, VAXman- @SendSpamHere.ORG wrote:
>>> In article <k0h8lu$vqn$1@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>>>> Maybe I should clarify that by "quick search and recall" I did not mean
>>>> execution time to do the actual search, but how quick and convenient it
>>>> is to access for a user. As such, typing whole commands, perhaps several
>>>> commands, to do it, makes it cumbersome compared to just pressing a key
>>>> or two, and have the whole process done for you in the current command line.
>>>>
>>>> 	Johnny
>>>>
>>>
>>> OK.  So, put a wrapper around DCL.EXE and introduce your OWN ^R handler
>>> to read in the recall buffer and provide editing.  Of course, a ^R has
>>> been used as a screen refresh in a number of VMS products/utilities, so
>>> you willl probably want to use some other control char.  You can still
>>> specify your OWN CLI in your UAF record!
>>
>> Certainly doable. But that is another thing. We were (I thought) talking
>> about history preservation and use cases in DCL compared to shells like
>> bash. Some people questioned the need to preserve history between
>> sessions. I made a comment that without quick search and recall of the
>> command history, I don't see much point in preserving history between
>> sessions either, as it really only becomes useful (in my opinion) once
>> you can easily and quickly search and recall your command history. And
>> as (in my opinion) that does not exist in DCL, the need for history
>> preservation isn't that big either.
>>
>> Writing my own CLI for VMS does nothing for changing how DCL works, not
>> to mention the non-existing documentation for doing such a thing.
>
> Who said write a CLI?  I merely suggested "augmentation" of DCL.

Well, you did say "You can still specify your OWN CLI in your UAF 
record!", but yes, most of your post was suggesting ways of doing a 
wrapper around DCL with enhancements. However, that is also not trivial, 
but I bet a lot of people would enjoy that, if done...

>> Also, unless I remember wrong, tcsh (and I think bash) have already been
>> ported to VMS, so I can just as well just use them.
>> They are not proper CLIs, though, if I understand things right, but just
>> user applications (quite like how they are under Unix).
>
> Neither are implemented as a CLI; just user programs and they're a bit
> of a kludge at that.

I definitely will not argue with that. :-)

	Johnny

0
Reply bqt2 (1410) 8/16/2012 11:29:03 PM

On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:

> Maybe I should clarify that by "quick search and recall" I did not mean
> execution time to do the actual search, but how quick and convenient it
> is to access for a user. As such, typing whole commands, perhaps several
> commands, to do it, makes it cumbersome compared to just pressing a key
> or two, and have the whole process done for you in the current command
> line.

You could assign "RECALL /SEARCH" to a function key using "DEFINE /KEY".

However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the 
keys you can use here.

-- 
Paul Sture
0
Reply nospam9740 (2260) 8/17/2012 8:01:14 AM

On 2012-08-17 10:01, Paul Sture wrote:
> On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:
>
>> Maybe I should clarify that by "quick search and recall" I did not mean
>> execution time to do the actual search, but how quick and convenient it
>> is to access for a user. As such, typing whole commands, perhaps several
>> commands, to do it, makes it cumbersome compared to just pressing a key
>> or two, and have the whole process done for you in the current command
>> line.
>
> You could assign "RECALL /SEARCH" to a function key using "DEFINE /KEY".
>
> However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the
> keys you can use here.

How would you give the arguments to the recall/search if you bound it to 
a key? Or would that just be used as a shortcut for typing the letters?

I strongly suspect it still falls seriously short.

	Johnny

0
Reply bqt2 (1410) 8/17/2012 9:29:48 AM

On Fri, 17 Aug 2012 11:29:48 +0200, Johnny Billquist wrote:

> On 2012-08-17 10:01, Paul Sture wrote:
>> On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:
>>
>>> Maybe I should clarify that by "quick search and recall" I did not
>>> mean execution time to do the actual search, but how quick and
>>> convenient it is to access for a user. As such, typing whole commands,
>>> perhaps several commands, to do it, makes it cumbersome compared to
>>> just pressing a key or two, and have the whole process done for you in
>>> the current command line.
>>
>> You could assign "RECALL /SEARCH" to a function key using "DEFINE
>> /KEY".
>>
>> However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the
>> keys you can use here.
> 
> How would you give the arguments to the recall/search if you bound it to
> a key? Or would that just be used as a shortcut for typing the letters?
> 

It's simply a shortcut for typing the letters.

-- 
Paul Sture
0
Reply nospam9740 (2260) 8/17/2012 9:34:35 AM

In article <k0l2uc$6oe$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>On 2012-08-17 10:01, Paul Sture wrote:
>> On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:
>>
>>> Maybe I should clarify that by "quick search and recall" I did not mean
>>> execution time to do the actual search, but how quick and convenient it
>>> is to access for a user. As such, typing whole commands, perhaps several
>>> commands, to do it, makes it cumbersome compared to just pressing a key
>>> or two, and have the whole process done for you in the current command
>>> line.
>>
>> You could assign "RECALL /SEARCH" to a function key using "DEFINE /KEY".
>>
>> However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the
>> keys you can use here.
>
>How would you give the arguments to the recall/search if you bound it to 
>a key? Or would that just be used as a shortcut for typing the letters?
>
>I strongly suspect it still falls seriously short.

What arguments???

vaxman@Satellite:~$ echo $SHELL
/bin/bash
vaxman@Satellite:~$ ^R
(reverse-i-search)`': 


I get prompted.

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

Well I speak to machines with the voice of humanity.
0
Reply VAXman 8/17/2012 11:50:59 AM

In article <bqf1g9-bj9.ln1@news1.chingola.ch>, Paul Sture <nospam@sture.ch> writes:
>On Fri, 17 Aug 2012 11:29:48 +0200, Johnny Billquist wrote:
>
>> On 2012-08-17 10:01, Paul Sture wrote:
>>> On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:
>>>
>>>> Maybe I should clarify that by "quick search and recall" I did not
>>>> mean execution time to do the actual search, but how quick and
>>>> convenient it is to access for a user. As such, typing whole commands,
>>>> perhaps several commands, to do it, makes it cumbersome compared to
>>>> just pressing a key or two, and have the whole process done for you in
>>>> the current command line.
>>>
>>> You could assign "RECALL /SEARCH" to a function key using "DEFINE
>>> /KEY".
>>>
>>> However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the
>>> keys you can use here.
>> 
>> How would you give the arguments to the recall/search if you bound it to
>> a key? Or would that just be used as a shortcut for typing the letters?
>> 
>
>It's simply a shortcut for typing the letters.

Right... then, type what you want to search for.
-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.
0
Reply VAXman 8/17/2012 11:52:43 AM

In article <howard-91AFF9.16234514082012@news.giganews.com>, Howard S Shubs <howard@shubs.net> writes:
> 
> Remember command and filename completion on TOPS-20?  Fantastic.

   Yes, but TOPS-20 EXEC had those (flavor) words in the middle of it's
   commands, and the blasted sub-command entries.

   For those who didn't use it, the (flavor) words were optional and enclosed 
   in parentheses.  Nobody typed them in, but command completion would
   put them in:

   Entered manually (@ is the prompt):

      @COPY A.MAC B.MAC

   Entered with the help of file name and command completion:

      @COPY A.MAC (TO) B.MAC

   And to get a subcommand, you had to end a line with a ",", this is
   the equivalent of DCL PURGE (@@ is the subcommand prompt):

      @DELETE *.*,
      @@KEEP 1

   Can you imagine what happened when you forgot the ","?  Well, no, it
   wasn't that bad.  "DELETE *.*" always prompted with "ARE YOU SURE?".

   You also couldn't readily stuff those into command scripts, as EXEC
   had no ability to pass arguments to command scripts.  To do that
   you had to switch to a different interpreter, which was available
   on a free "tools" tape, along with other goodies like the BLISS-10
   compiler.



0
Reply koehler2 (8314) 8/17/2012 2:43:31 PM

In article <58561ded-6786-4c25-9fac-c59a819fb367@googlegroups.com>, Jose Baars <peutbaars@gmail.com> writes:
> Op donderdag 16 augustus 2012 14:54:59 UTC+2 schreef (onbekend) het volgende:
>>  You can still specify your OWN CLI in your UAF record!
> 
> Are there any examples including sources of this available somewhere?
> Just curious.

   Examples:  there have been.  Sources:  no.

   The exampes I know of have all shipped from DEC, and include choice
   of DCL, MCR, DEC Shell (an implementation of Bourne shell), and the
   POSIX shell (basically ksh).

   Some of the sources might be on the fiche or CD.

0
Reply koehler2 (8314) 8/17/2012 2:46:44 PM

On Fri, 17 Aug 2012 09:43:31 -0500, Bob Koehler wrote:

> In article <howard-91AFF9.16234514082012@news.giganews.com>, Howard S
> Shubs <howard@shubs.net> writes:
>> 
>> Remember command and filename completion on TOPS-20?  Fantastic.
> 
>    Yes, but TOPS-20 EXEC had those (flavor) words in the middle of it's
>    commands, and the blasted sub-command entries.
> 
>    For those who didn't use it, the (flavor) words were optional and
>    enclosed in parentheses.  Nobody typed them in, but command
>    completion would put them in:
> 
>    Entered manually (@ is the prompt):
> 
>       @COPY A.MAC B.MAC
> 
>    Entered with the help of file name and command completion:
> 
>       @COPY A.MAC (TO) B.MAC

ISTR that CP/M had the COPY foo TO bar syntax.  Even as someone 
maintaining COBOL when I came across that, I thought it was too verbose.


>    And to get a subcommand, you had to end a line with a ",", this is
>    the equivalent of DCL PURGE (@@ is the subcommand prompt):
> 
>       @DELETE *.*,
>       @@KEEP 1
> 
>    Can you imagine what happened when you forgot the ","?  Well, no, it
>    wasn't that bad.  "DELETE *.*" always prompted with "ARE YOU SURE?".

Bad memories of the various versions of PIP across various DEC operating 
systems there.  IIRC on the RT-11 flavour confirmation for a wildcard 
delete was "ARE YOU SURE?", but when I was working on a RSTS system at a 
bureau the default was the other way around.

Ah well. The bureau concerned had a decent backup system and I didn't 
have to wait long to get my files back :-)

>    You also couldn't readily stuff those into command scripts, as EXEC
>    had no ability to pass arguments to command scripts.  To do that you
>    had to switch to a different interpreter, which was available on a
>    free "tools" tape, along with other goodies like the BLISS-10
>    compiler.

As I have discovered in more recent times, many places don't install 
"extras".  The installation of the "Enterprise Version" of MS Office I 
was working with a couple of years ago didn't have the kind of import/
export add-ons that were available in an "Extras" folder of Office 97, 
for example.

-- 
Paul Sture
0
Reply nospam9740 (2260) 8/17/2012 3:08:01 PM

On 2012-08-17, Paul Sture <nospam@sture.ch> wrote:
> ISTR that CP/M had the COPY foo TO bar syntax.

Nope. In CP/M, you copied stuff using PIP dest=source
-- 
roger ivie
rivie@ridgenet.net
0
Reply rivie (670) 8/17/2012 3:45:10 PM

On Fri, 17 Aug 2012 10:45:10 -0500, Roger Ivie wrote:

> On 2012-08-17, Paul Sture <nospam@sture.ch> wrote:
>> ISTR that CP/M had the COPY foo TO bar syntax.
> 
> Nope. In CP/M, you copied stuff using PIP dest=source

It must have been something else I came across in the late 80s.

FWIW the Amstrad PCW 9512 I bought in 1987 had CP/M under the skin.  
Although the hardware quality left much to be desired, the GUI was pretty 
good.  It managed to hide the CP/M stuff very well.  The LocoScript word 
processing package was good and there were other useful packages 
available.  My first ever shareware purchase was a C compiler and Kermit 
for that system.

The C compiler came with vi, the combination of which put me off both for 
a while :-)

-- 
Paul Sture
0
Reply nospam9740 (2260) 8/18/2012 2:28:48 PM

On 2012-08-17 13:50, VAXman- @SendSpamHere.ORG wrote:
> In article <k0l2uc$6oe$2@Iltempo.Update.UU.SE>, Johnny Billquist <bqt@softjar.se> writes:
>> On 2012-08-17 10:01, Paul Sture wrote:
>>> On Thu, 16 Aug 2012 00:43:02 +0200, Johnny Billquist wrote:
>>>
>>>> Maybe I should clarify that by "quick search and recall" I did not mean
>>>> execution time to do the actual search, but how quick and convenient it
>>>> is to access for a user. As such, typing whole commands, perhaps several
>>>> commands, to do it, makes it cumbersome compared to just pressing a key
>>>> or two, and have the whole process done for you in the current command
>>>> line.
>>>
>>> You could assign "RECALL /SEARCH" to a function key using "DEFINE /KEY".
>>>
>>> However "HELP DEFINE/KEY PARAMETERS" shows you are a bit limited in the
>>> keys you can use here.
>>
>> How would you give the arguments to the recall/search if you bound it to
>> a key? Or would that just be used as a shortcut for typing the letters?
>>
>> I strongly suspect it still falls seriously short.
>
> What arguments???
>
> vaxman@Satellite:~$ echo $SHELL
> /bin/bash
> vaxman@Satellite:~$ ^R
> (reverse-i-search)`':
>
>
> I get prompted.

And RECALL /SEARCH expects an argument... That was the argument I was 
referring to. No point in talking about how other shells work when we 
are talking about how to possibly modify DCL, is there...?

(In tcsh you type some letters, and then press M-P or M-N...)

	Johnny

0
Reply bqt2 (1410) 8/19/2012 1:38:54 AM

On 08/18/12 14:28, Paul Sture wrote:

>
> The C compiler came with vi, the combination of which put me off both for
> a while :-)
>

A lot of the early systems only had line editors, but there are those 
who still
swear by vi as the best programming editor around. I found myself 
swearing at it
more often than not, at least to start with, but it was better than ed 
at least.
It is actually usefull for quick, few line edits, but like any modal 
editor, a
pita for serious work.

Never understood the obsession with teco or emacs either.

Give me a decent gui based editor like nedit, jedit or notepad++ any 
day. The
world stopped using teletypes and decwriters years ago :-)...

Regards,

Chris
0
Reply meru (441) 8/21/2012 1:44:19 PM
comp.os.vms 20590 articles. 11 followers. Post

221 Replies
635 Views

Similar Articles

[PageSpeed] 15

  • Permalink
  • submit to reddit
  • Email
  • Follow


Reply:

Similar Artilces:

Android-x86
https://sites.google.com/a/android-x86.org/web/ Nobody <invalid@invalid.com> writes: > https://sites.google.com/a/android-x86.org/web/ > A hive of activity! -- A certain COLA "advocate" faking his user-agent in order to pretend to be a Linux user: User-Agent: Outlook 5.5 (WinNT 5.0), User-Agent: slrn/0.9.8.0 (Linux), Message-ID: <wPGdnd3NnOM0ACfdRVn-hw@comcast.com> On Sun, 03 Feb 2013 13:01:37 +0100, Hadron wrote: > Nobody <invalid@invalid.com> writes: > >> https://sites.google.com/a/android-x86.org/web/ >> >...

Speaking of porting VMS
These guys might need an OS. http://www.eet.com/news/latest/showArticle.jhtml?articleID=164903385 Tom Linden wrote: > These guys might need an OS. > > http://www.eet.com/news/latest/showArticle.jhtml?articleID=164903385 Yeah, but HP only invents ways of not promoting VMS's use. OTOH, you might want to port a compiler for Cell. -- OpenVMS - The never-advertised operating system with the dwindling ISV base. ----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ---...

Porting Subversion to VMS
I am attempting (with what little knowledge of c that I have) to port Subversion to OpenVMS. I have looked but can't see where anyone has done this already. I currently have three customers that use Netbeans for Java development and they would like the source code to be "in a safe place" which they all agree is their OpenVMS system. I could install Subversion on a Linux system (they all have them) and back it up to OpenVMS, but it would be preferable that the source stay on the OpenVMS system. I know there is a port of the CVS client to OpenVMS, but CVS appears to be rep...

X86 BSP Porting
Hi friends, I have a doubt in X86 based BSP. I have seen one X86 board BSP, in which they have taken Pentium4 BSP for porting and changed the CPU to Pentium. What will be the reason? Why they did not take Pentium BSP directly. Version is Tornado 2.2.1/VxWorks 5.5.1. -Regards, K.Ananth ...

VMS atop x86 *nix
I would like to set up OpenVMS+JDK on something I already have, which is x86-64 machines and Unix/Linux. The emulators PersonalAlpha, FreeAXP, and CHARON-AXP are Windows-only, so that seems to just leave ES40 Emulator. Comments on ES40 indicate that it's pretty rough. Any idea how much of a challenge to get it working right? Any other options? In article <8s85boFu2eU1@mid.individual.net>, Bob Eager <rde42@spamcop.net> writes: > On Fri, 18 Feb 2011 11:52:25 -0800, Wendell wrote: > >> I would like to set up OpenVMS+JDK on something I already have, which...

VMS-Ports SourceForge project
One more thing - The fact that you have been able to involve VMS Engineering in this project is a *major* acheivement, and one that should be noted frequently. We have been (over)exposed to posts and posters chanting the "VMS is dead" mantra and "HP does not care about VMS" for so long, that positive efforts like this may be overlooked. To paraphrase from another movement, "Folks, this is good. Come and get it." On Saturday, June 30, 2012 1:31:57 PM UTC-4, brad wrote: > One more thing - The fact that you have been able to involve VMS Engineering ...

GNAT x86 Port Access
A few days ago there was a thread about doing x86 IO port access. I eventually dug out my old laptop and found a little (very little) package I wrote to do this. It is only setup to do byte IO on the ports . It WILL NOT WORK under windows 2000, NT, XP or any OS that limits the instructions that user land applications can use. I have used this under windows 98 with success. with Interfaces; package PC_IO_Port_Access is -------------------------------------------------------------------------- ---- -- -- PROCEDURE/FUNCTION: Inportb -- -- PURPOSE: Performs a byte read of the give...

x86 to ARM porting Issues
Hi VxWorks Gurus, I have ported RADIUS protocol and PPPoA from netBsd to vxWorks. My target architecture was x86(PENTIUM ). Now I want the same code to work on an ARM processor board. can some one suggest what are the important things to take care when porting a protocol from x86 architecture to ARm architecture. I suppose ARM is also little Indian . ...

HP ports HPCL to VMS
HP to port HPCL to OpenVMS systems. Company announces the integration of its industry standard HPCL to OpenVMS systems. PALO ALTO, Calif., Jan. 9, 2005 In advance of the January 18th launch of the OpenVMS platform on HP's industry leading Itanium servers, HP is proud to announce the porting of its advanced HPCL language to the OpenVMS system. As part of the final phase of integration of products inherited from the Compaq merger, HP will retire Digital's old and proprietary command language and replace it with HP's industry standard HPCL language on OpenVMS systems. "Whil...