New VSI Roadmap (yipee!)

[Neil Rieck]

Folks, here is the link for the latest VSI roadmap.

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

Everyone will have their favorite paragraphs. For me, it is hard not to like the whole thing but here are my three:

1) new TCP/IP stack
2) updated open source kits (Apache, gSOAP, Samba, SSL)
3) updated language standards (C and C++)

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

[Simon Clubley]

On 2015-02-25, Neil Rieck <n.r...@sympatico.ca> wrote:
> Folks, here is the link for the latest VSI roadmap.
>
> http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf
>

Yes, that looks more like a full roadmap with a number of questions
answered. :-)

Regarding languages, I did note the absence of Ada and Python.

Regarding Ada, I wonder if VSI will partner with ACT to continue
providing GNAT on VMS, including x86-64.

However, I wonder if Python would be a good choice for an official
VSI supported kit given it's increasing popularity elsewhere ?

(I know third parties have Python running on VMS at the moment, but
there's a big difference between a third party port and an official
vendor supported kit you can use in production.)

Simon.

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

[Neil Rieck]

On Wednesday, February 25, 2015 at 7:37:33 AM UTC-5, Simon Clubley wrote:
[...snip...]

>
> Regarding languages, I did note the absence of Ada and Python.
>
> Regarding Ada, I wonder if VSI will partner with ACT to continue
> providing GNAT on VMS, including x86-64.
>
> However, I wonder if Python would be a good choice for an official
> VSI supported kit given it's increasing popularity elsewhere ?
>
> (I know third parties have Python running on VMS at the moment, but
> there's a big difference between a third party port and an official
> vendor supported kit you can use in production.)
>
> Simon.
>
> --
> Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
> Microsoft: Bringing you 1980s technology to a 21st century world

Our shop still uses BASIC (we have ~ 500k lines) which is also missing from their list. Apparently it was once very popular with the American Insurance industry; not sure about 2015 (HP probably told VSI about popularity based upon paid support contracts)

But you are correct, Python seems to be popping up everywhere these days.

NSR

[Richard Maher]

Is no one else over the moon with the *8* in Java 1.8???

I also vote for Python support, and "g" or any other form of SOAP is
deemphasized to the point of willful neglect in the industry at large.
We've move on. Arne was saying something about the RESTful JSON support
in Java these days.

[li...@openmailbox.org]

On Wed, 25 Feb 2015 12:36:49 +0000 (UTC)
Simon Clubley via Info-vax <info...@rbnsn.com> wrote:

> On 2015-02-25, Neil Rieck <n.r...@sympatico.ca> wrote:
> > Folks, here is the link for the latest VSI roadmap.
> >
> > http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf
> >
>
> Yes, that looks more like a full roadmap with a number of questions
> answered. :-)

And some unanswered! What is the meaning of OpenVMS running as a VM guest
on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM guest?
Because of the binary translation comment I wonder if this is a stop-gap
way to support VMS on x86 until the code is (if ever) actually ported.

> Regarding languages, I did note the absence of Ada and Python.

If you have a standards-compliant C toolchain then Python shouldn't be
different from any other application. Ada is another story entirely.

> Regarding Ada, I wonder if VSI will partner with ACT to continue
> providing GNAT on VMS, including x86-64.

I hope not but there aren't many choices.

> However, I wonder if Python would be a good choice for an official
> VSI supported kit given it's increasing popularity elsewhere ?
>
> (I know third parties have Python running on VMS at the moment, but
> there's a big difference between a third party port and an official
> vendor supported kit you can use in production.)

Absolutely. But there are other popular scripting languages in use right
now (and newer ones next week) and whatever the script kiddies are using to
create e-commerce sites with (is Ruby on Rails dead yet?) is going to need
to be there too once they open that can.

[johnso...@gmail.com]

On Wednesday, February 25, 2015 at 7:02:09 AM UTC-5, Neil Rieck wrote:

> 1) new TCP/IP stack
> 2) updated open source kits (Apache, gSOAP, Samba, SSL)
> 3) updated language standards (C and C++)

The same ones stood out for me too. I see that C++ was in red on a subsequent slide.
Was unsure what that meant. Time will tell.

-Eric

[Jan-Erik Soderholm]

A few other notes...

On the software pages it says at the bottom:
"* Except compilers which are sold per user".

Is that "concurrent" or "named" user? I guess "concurrent"...
We currently have "named user" licenes for our compilers
and the questions is if they are transferable to "concurrent"
when (and definitely *if*!) we'd move to IA64 (or x86-64).

I know that "named" once was lower cost then "concurrent"
per user.

I also notice that all OS licensing is "per socket". So the
number of cores per single socket doesn't matter? Earlier there
was some extra "multiprocessing" licens for VMS systems with
more then 1 CPU, has that gone?

And would a dual socket/4 core system have double the
licencing cost then a single socket/8 core system? I do
not expect answers here, it is just a few thoughts... :-)

Jan-Erik.

[Craig A. Berry]

On 2/25/15 7:08 AM, li...@openmailbox.org wrote:
> On Wed, 25 Feb 2015 12:36:49 +0000 (UTC)
> Simon Clubley via Info-vax <info...@rbnsn.com> wrote:

>> Yes, that looks more like a full roadmap with a number of questions
>> answered. :-)
>
> And some unanswered! What is the meaning of OpenVMS running as a VM guest
> on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM guest?

Clair Grant has already stated, in answer to a question about Galaxy,
that Galaxy was a firmware implementation and VSI is not in the firmware
business and has no current plans to make VMS a virtualization host.

> Because of the binary translation comment I wonder if this is a stop-gap
> way to support VMS on x86 until the code is (if ever) actually ported.

As has been said many times, they are doing a native port to x86_64 just
as they did to Itanium. The binary translator is for user applications,
not the OS.

[Bill Gunshannon]

In article <f3dd76d3-c594-418c...@googlegroups.com>,

Neil Rieck <n.r...@sympatico.ca> writes:
> On Wednesday, February 25, 2015 at 7:37:33 AM UTC-5, Simon Clubley wrote:
> [...snip...]
>>
>> Regarding languages, I did note the absence of Ada and Python.
>>
>> Regarding Ada, I wonder if VSI will partner with ACT to continue
>> providing GNAT on VMS, including x86-64.
>>
>> However, I wonder if Python would be a good choice for an official
>> VSI supported kit given it's increasing popularity elsewhere ?
>>
>> (I know third parties have Python running on VMS at the moment, but
>> there's a big difference between a third party port and an official
>> vendor supported kit you can use in production.)
>>
>

> Our shop still uses BASIC (we have ~ 500k lines) which is also missing from their list. Apparently it was once very popular with the American Insurance industry; not sure about 2015 (HP probably told VSI about popularity based upon paid support contracts)
>

If you are in business, what, other than paying customers, matters?

> But you are correct, Python seems to be popping up everywhere these days.

And the cycle of "one size fits all" software engineering continues.

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Neil Rieck]

A few comments after reviewing the RM a second time:

The first chart on page 3 contains three columns: the first two are titled "architecture: Itanium" whilst the third column is titled "architecture; common".

I wonder if common includes Alpha; perhaps they meant "Itanium and x86-64"

###

Updated Language Standards is under an area titled "architecture: x86-64"; I am assuming this will not include Itanium; if so, this make me wonder (speculate) that HP might not have any rights to directly license VMS software implemented on x86-64 (but HP would be able to partner with VSI just like they do with Stromasys)

[John Reagan]

On Wednesday, February 25, 2015 at 7:50:21 AM UTC-5, Neil Rieck wrote:

> Our shop still uses BASIC (we have ~ 500k lines) which is also missing from their list. Apparently it was once very popular with the American Insurance industry; not sure about 2015 (HP probably told VSI about popularity based upon paid support contracts)
>

BASIC is on the list for the layered products DVD. We haven't forgot about it. You certainly aren't the only user.

Are you commenting on the list of languages getting standards updates? There is a real BASIC standard but nobody really cares about it. If there are some languages features that might help our existing BASIC customers, let me know. However, I'd guess that most of the BASIC code out there is mostly in maintenance mode so us adding 20 new BASIC features might go unused.

We aren't planning on adding object-oriented COBOL 2002 features either. We might cherry-pick some COBOL features if we see a need. There has always been some "match the IBM compiler" and "match the NonStop compiler" pressure over the years.

And I don't plan on finishing the Extended Pascal support in the Pascal compiler. Again, if somebody wants a specific feature, let me know. I added two new statements (SELECT and SELECTONE) right before I left several years ago based on a request. I didn't get around to the 64-bit descriptor support however. Maybe when I have a free weekend sometime in 2017... :)

[David Froble]

Simon Clubley wrote:
> On 2015-02-25, Neil Rieck <n.r...@sympatico.ca> wrote:
>> Folks, here is the link for the latest VSI roadmap.
>>
>> http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf
>>
>
> Yes, that looks more like a full roadmap with a number of questions
> answered. :-)
>
> Regarding languages, I did note the absence of Ada and Python.
>
> Regarding Ada, I wonder if VSI will partner with ACT to continue
> providing GNAT on VMS, including x86-64.
>
> However, I wonder if Python would be a good choice for an official
> VSI supported kit given it's increasing popularity elsewhere ?
>
> (I know third parties have Python running on VMS at the moment, but
> there's a big difference between a third party port and an official
> vendor supported kit you can use in production.)

This is a strange thing to write, at least from my perspective ...

I'm assuming that you mean VSI when you write "vendor supported kit",
since we are discussing the VSI roadmap.

So, if you purchase a wholesale distribution application from say, me,
which would not be suported by VSI, would you not consider it something
you could use in production? I'd assume you'd purchase it because you
intended to actually use the product.

[David Froble]

Neil Rieck wrote:

> Our shop still uses BASIC (we have ~ 500k lines) which is also
> missing from their list. Apparently it was once very popular with the
> American Insurance industry; not sure about 2015 (HP probably told
> VSI about popularity based upon paid support contracts)

Perhaps take another look at page 5 of the roadmap ....

[David Froble]

Bill Gunshannon wrote:

> If you are in business, what, other than paying customers, matters?

That's sort of short sighted. Even if a customer doesn't have BASIC on
a support contract, they just might have VMS and the HW on support
contracts.

What really matters is having as many users as you can get using your
stuff, as every one is a potential future "paying customer". I can
assume there were more than a few using linux before deciding to get
support from RedHat, or another provider.

[Jan-Erik Soderholm]

The thing with something like Python, is that it lives in a kind of
grey zone between traditional compilers and ordinary user applications.

Python is not a compiler of course, it knows nothing about the
actual architecure it runs on. As far as I understand, Python
is 100% C code and if it compiles, it "works". So in that way,
Python is just another application.

Now, a Python kit on VMS would be close to useless without the
added VMS specific APIs that *are* available in the current
Python port for VMS. So the "offical support" from VMS is more
about these modules/additions then the base Python distribution.

So, if you fully belive in the current maintainer and that his
support of Python is "good enough", fine. Then you might not
need any additional support from VSI.

I'd say that PERL and Python are very similar in this regard.
PERL *is* mentioned in the new roadmap and it would of course
be nice if Python was also... :-)

Some sees Python as the new "VSI Command Language", I do not.


Jan-Erik.

[li...@openmailbox.org]

On Wed, 25 Feb 2015 07:25:02 -0600
"Craig A. Berry via Info-vax" <info...@rbnsn.com> wrote:

> On 2/25/15 7:08 AM, li...@openmailbox.org wrote:
> > On Wed, 25 Feb 2015 12:36:49 +0000 (UTC)
> > Simon Clubley via Info-vax <info...@rbnsn.com> wrote:
>
> >> Yes, that looks more like a full roadmap with a number of questions
> >> answered. :-)
> >
> > And some unanswered! What is the meaning of OpenVMS running as a VM
> > guest on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM
> > guest?
>
> Clair Grant has already stated, in answer to a question about Galaxy,
> that Galaxy was a firmware implementation and VSI is not in the firmware
> business and has no current plans to make VMS a virtualization host.

I didn't suggest VMS would be a host. You quoted my comment but I don't see
how what you wrote has much to do with that.

>
> > Because of the binary translation comment I wonder if this is a stop-gap
> > way to support VMS on x86 until the code is (if ever) actually ported.
>
> As has been said many times, they are doing a native port to x86_64 just
> as they did to Itanium. The binary translator is for user applications,
> not the OS.

I am new here so the "has been said many times" doesn't mean much to me
right now but thanks for being a sport and filling me in anyway.

[Bill Gunshannon]

In article <816bd7cc-4ccc-483f...@googlegroups.com>,

John Reagan <xyzz...@gmail.com> writes:
> On Wednesday, February 25, 2015 at 7:50:21 AM UTC-5, Neil Rieck wrote:
>> Our shop still uses BASIC (we have ~ 500k lines) which is also missing from their list. Apparently it was once very popular with the American Insurance industry; not sure about 2015 (HP probably told VSI about popularity based upon paid support contracts)
>>
> BASIC is on the list for the layered products DVD. We haven't forgot about it. You certainly aren't the only user.
> Are you commenting on the list of languages getting standards updates? There is a real BASIC standard but nobody really cares about it. If there are some languages features that might help our existing BASIC customers, let me know. However, I'd guess that most of the BASIC code out there is mostly in maintenance mode so us adding 20 new BASIC features might go unused.

Een if the user code isn't in "maintenance mode" your features would likely
go unused. DEC BASIC was always better than what was available elsewhere
and, like most language standards, ANSI Basic was pretty much an academic
endeavor done in a vacuum which brought nothing to the table for people
who had alerady done a good job on BASIC in the first place.

> We aren't planning on adding object-oriented COBOL 2002 features either. We might cherry-pick some COBOL features if we see a need. There has always been some "match the IBM compiler" and "match the NonStop compiler" pressure over the years.

See comment above. OO COBOL was pretty much the same. Nobody using COBOL
wanted it. Academia pushed it. And when the COBOL world rejected it
academia's response was to try and convince the world that COBOL was dead.
(Just like I did for VMS in the past, I am still actively trying to reverse
this. And that includes trying to work with a company that does a very
popular COBOL Compiler to come up with a usable educational program to
try and get COBOL back in the classroom and in the hands of students.
As an aside, am I tho only one who notices that while other disciplines
work very closely with their industry counterparts the IT world does not
seem to do that any more. The result is the articles that keep popping
up about how college graduates in IT seldom come out with the skills
needed by their potential hiring opportunities!!)

> And I don't plan on finishing the Extended Pascal support in the Pascal compiler. Again, if somebody wants a specific feature, let me know. I added two new statements (SELECT and SELECTONE) right before I left several years ago based on a request. I didn't get around to the 64-bit descriptor support however. Maybe when I have a free weekend sometime in 2017... :)

Pascal was intended as a teaching language. I know people used it for
real programming but in my opinion it is still best left in the classroom.

[clairg...@gmail.com]

On Wednesday, February 25, 2015 at 7:37:33 AM UTC-5, Simon Clubley wrote:

I'll be right up front on this one. We have not yet figured out what to do about Ada. It is very complicated and we are working on it.

Clair

[Bill Gunshannon]

In article <48568d71-7283-4d54...@googlegroups.com>,

Does DOD still "Validate" Ada Compilers? That being the case it
might be better to leave the work and cost of doing this in the
hands of someone who does only that, ie. ACT. Wasn't the VMS
Ada compiler dropped at the time of the move to Itanium, anyway?
Would there really be a need or reason to revive that?

[clairg...@gmail.com]

On Wednesday, February 25, 2015 at 7:50:21 AM UTC-5, Neil Rieck wrote:

There will always be a BASIC compiler on VMS. We have not had requests for updated standards compliance like we have for C, C++ and Fortran. Maybe that is mincing words but we have been making the distinction. We will certainly be maintaining and responding to customer needs regarding BASIC.

Clair

[clairg...@gmail.com]

'Also' as a guest.

Clair

[Bob Koehler]

In article <mailman.10.1424869752....@rbnsn.com>, <li...@openmailbox.org> writes:
>
> And some unanswered! What is the meaning of OpenVMS running as a VM guest
> on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM guest?
> Because of the binary translation comment I wonder if this is a stop-gap
> way to support VMS on x86 until the code is (if ever) actually ported.

While I have the same question as guest vs. guest-only, nobody yet
has made a binary translator for VMS priviledged code, and I really
don't see VSI doing the whole executive that way.

Booting on x86 just about has to be an actual port, guest or not.

[clairg...@gmail.com]

I have no idea why that is in red. Ignore it.

Clair

[clairg...@gmail.com]

Common means Itanium and x86.

Clair

[Stephen Hoffman]

On 2015-02-25 13:08:55 +0000, <li...@openmailbox.org> said:

> And some unanswered! What is the meaning of OpenVMS running as a VM guest
> on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM guest?
> Because of the binary translation comment I wonder if this is a stop-gap
> way to support VMS on x86 until the code is (if ever) actually ported.

Translating kernel-mode code? It's the architecture-dependent portions
of the kernel that provide the support and the infrastructure necessary
for the execution of the translated code, not the other way 'round.
The three previous kernels have no idea how to field x86-64 interrupts,
manage x86-64 memory management or the rest of the details of Intel 64.
Once that's all architected and written and debugged, and once the
cross-compilers or native compilers are working — and that's a whole
lot of work — then the architecture-independent portions of the kernel
will largely recompile and run. That's all based on the previous
port, and will obviously vary in the port-specific and
architectural-specific details, as well as decisions such as the use
LLVM as the compiler code generator.

Now translating user-mode code is something that VSI has already
commented on, and reportedly plans.

As for VMS as a VM guest, it means VMS booted and running as a guest
within (currently-unspecified) virtual machine.

VMS can already boot within emulation.

Something akin to user-mode VMS clearly isn't likely in the immediate
VSI plans, either. Folks can already use emulation to get there, after
all.

In short: Translating an OS kernel to run as the native kernel on a new
processor architecture? Nope. Not happening. Same sort of general
it's-code-for-the-wrong-architecture issue arises with suggestions to
translate the compilers, too. You end up with a compiler that
generates object code for its previous architecture, and not the
architecture you translated to. Not really what anybody wants. With
the OS, the OS doesn't know the necessary details of the new
architecture.


--
Pure Personal Opinion | HoffmanLabs LLC

[li...@openmailbox.org]

On Wed, 25 Feb 2015 07:32:24 -0800 (PST)
clairgrant71--- via Info-vax <info...@rbnsn.com> wrote:

> On Wednesday, February 25, 2015 at 8:10:05 AM UTC-5,
> li...@openmailbox.org wrote:
> > And some unanswered! What is the meaning of OpenVMS running as a VM
> > guest on Intel x86-64? Is that *also* as a VMS guest or *only* as a VM
> > guest? Because of the binary translation comment I wonder if this is a
> > stop-gap way to support VMS on x86 until the code is (if ever) actually
> > ported.
>

> 'Also' as a guest.

Thank you for clarifying. Sounds good!

[Simon Clubley]

On 2015-02-25, David Froble <da...@tsoft-inc.com> wrote:

> Simon Clubley wrote:
>>
>> However, I wonder if Python would be a good choice for an official
>> VSI supported kit given it's increasing popularity elsewhere ?
>>
>> (I know third parties have Python running on VMS at the moment, but
>> there's a big difference between a third party port and an official
>> vendor supported kit you can use in production.)
>
> This is a strange thing to write, at least from my perspective ...
>
> I'm assuming that you mean VSI when you write "vendor supported kit",
> since we are discussing the VSI roadmap.
>
> So, if you purchase a wholesale distribution application from say, me,
> which would not be suported by VSI, would you not consider it something
> you could use in production? I'd assume you'd purchase it because you
> intended to actually use the product.

No, it means that if you run something in production, you must be
able to get support for it, including a defined escalation procedure
which specifies when the problems you are experiencing will either
be fixed or worked around.

The current Python port is a best-effort port from a third party and
while it's a really good thing it's available, you have to consider
how you will fix any problems in the port if you make it a part of
your production infrastructure.

Buying something from your company would not be a problem in this
case as it would come with a support contract which would include
the above escalation procedures. However, before buying that product
and signing that support contract, some managers/organisations may
want to first establish if you are big enough to sue if something
goes wrong.

[David Froble]

John Reagan wrote:
> On Wednesday, February 25, 2015 at 7:50:21 AM UTC-5, Neil Rieck
> wrote:
>
>> Our shop still uses BASIC (we have ~ 500k lines) which is also
>> missing from their list. Apparently it was once very popular with
>> the American Insurance industry; not sure about 2015 (HP probably
>> told VSI about popularity based upon paid support contracts)
>>
>
> BASIC is on the list for the layered products DVD. We haven't forgot
> about it. You certainly aren't the only user.

Most definitely not.

> Are you commenting on the list of languages getting standards
> updates? There is a real BASIC standard but nobody really cares
> about it. If there are some languages features that might help our
> existing BASIC customers, let me know. However, I'd guess that most
> of the BASIC code out there is mostly in maintenance mode so us
> adding 20 new BASIC features might go unused.

And you'd guess wrong. We do new stuff every day.

However, with a few exceptions, which in my opinion aren't BASIC issues,
the BASIC implementation on VMS is very robust. While I don't get out
much, I'm not aware of any better. Not sure if you could find 20
reasonable new features.

I have used Visual Basic 6, and it does some things that are
interesting, but I'm not sure how efficient they are. Some of the data
types have got to be real hogs.

What I find very annoying is not being able to easily call some
non-BASIC routines. Usually the problem, (in my opinion) is C. Yes, I
can build structures that C will accept, but there are times when it
just doesn't work. OpenSSL comes to mind. But, that's on the roadmap,
so maybe happier times ahead.

> We aren't planning on adding object-oriented COBOL 2002 features
> either. We might cherry-pick some COBOL features if we see a need.
> There has always been some "match the IBM compiler" and "match the
> NonStop compiler" pressure over the years.
>
> And I don't plan on finishing the Extended Pascal support in the
> Pascal compiler. Again, if somebody wants a specific feature, let me
> know. I added two new statements (SELECT and SELECTONE) right before
> I left several years ago based on a request. I didn't get around to
> the 64-bit descriptor support however. Maybe when I have a free
> weekend sometime in 2017... :)
>

It's reasonable to do what you need, and not do that which would be a
waste of time.

[Kerry Main]

HP OpenVMS licensing changed with OpenVMS V8.4 and I2 Integrity
servers from per core to per socket.

Yes, there is a license cost savings with a move to I2 (now I4 as well) &
latest OpenVMS V8.4.

http://tinyurl.com/VMS-Licensing
"OpenVMS software is licensed on a per-socket basis on the new HP
Integrity family of servers (models BL8x0c i2, rx2800 i2). OpenVMS
software on all other Integrity servers is still licensed on a per-core
basis".

Regards,

Kerry Main
Back to the Future IT Inc.
.. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com

[Stephen Davies]

On Wednesday, 25 February 2015 15:26:21 UTC, clairg...@gmail.com wrote:

> I'll be right up front on this one. We have not yet figured out what to do about Ada. It is very complicated and we are working on it.
>
> Clair

I have always thought that Ada and VMS were a good match. Both underappreciated
by the masses but well designed with safety and readability as primary goals.

[Simon Clubley]

On 2015-02-25, clairg...@gmail.com <clairg...@gmail.com> wrote:
> On Wednesday, February 25, 2015 at 7:37:33 AM UTC-5, Simon Clubley wrote:
>>
>> Regarding languages, I did note the absence of Ada and Python.
>>
>> Regarding Ada, I wonder if VSI will partner with ACT to continue
>> providing GNAT on VMS, including x86-64.
>>
>> However, I wonder if Python would be a good choice for an official
>> VSI supported kit given it's increasing popularity elsewhere ?
>>
>> (I know third parties have Python running on VMS at the moment, but
>> there's a big difference between a third party port and an official
>> vendor supported kit you can use in production.)
>>
>

> I'll be right up front on this one. We have not yet figured out what to do
> about Ada. It is very complicated and we are working on it.
>

Thanks for the feedback. While my interest in Ada is more of a personal
projects interest, learning the Ada situation is complicated still does
not come as a major surprise. :-)

Thanks Clair,

[Jan-Erik Soderholm]

What about a 2 socket system with only 1 CPU module installed?

Now, I do not know for sure, but I do not think that the Rdb
license is arranged in the same way. It is still per core.

/Jan-Erik

[David Froble]

Simon Clubley wrote:
> On 2015-02-25, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> However, I wonder if Python would be a good choice for an official
>>> VSI supported kit given it's increasing popularity elsewhere ?
>>>
>>> (I know third parties have Python running on VMS at the moment, but
>>> there's a big difference between a third party port and an official
>>> vendor supported kit you can use in production.)
>> This is a strange thing to write, at least from my perspective ...
>>
>> I'm assuming that you mean VSI when you write "vendor supported kit",
>> since we are discussing the VSI roadmap.
>>
>> So, if you purchase a wholesale distribution application from say, me,
>> which would not be suported by VSI, would you not consider it something
>> you could use in production? I'd assume you'd purchase it because you
>> intended to actually use the product.
>
> No, it means that if you run something in production, you must be
> able to get support for it, including a defined escalation procedure
> which specifies when the problems you are experiencing will either
> be fixed or worked around.

I recall reading that Python is implemented in standard C, whatevr that
is, and if so, then anyone could make changes if needed / desired.
Well, not anyone. Definitely not me.

Fixing it yourself can be considered "support".

> The current Python port is a best-effort port from a third party and
> while it's a really good thing it's available, you have to consider
> how you will fix any problems in the port if you make it a part of
> your production infrastructure.
>
> Buying something from your company would not be a problem in this
> case as it would come with a support contract which would include
> the above escalation procedures. However, before buying that product
> and signing that support contract, some managers/organisations may
> want to first establish if you are big enough to sue if something
> goes wrong.

I've never understood this "big enough to sue". In the US legal system,
you can sue someone if you don't like their face. Better be real good
at convincing people. No, we're not big enough to sue. That has no
bearing on the quality of the product.

What a potential customer should be doing is confirming that a potential
purchase does what it claims. This involves some serious testing.
Maybe too much work for some, and some may feel it's easier to hire a
lawyer.

[Bob Koehler]

In article <cl683c...@mid.individual.net>, bi...@server3.cs.scranton.edu (Bill Gunshannon) writes:
>
> Does DOD still "Validate" Ada Compilers? That being the case it
> might be better to leave the work and cost of doing this in the
> hands of someone who does only that, ie. ACT. Wasn't the VMS
> Ada compiler dropped at the time of the move to Itanium, anyway?
> Would there really be a need or reason to revive that?

Only if you consider gnat to be a "VMS Ada compiler". DEC stopped
producing thier own during the move to Alpha.

[John Reagan]

On Wednesday, February 25, 2015 at 12:52:15 PM UTC-5, David Froble wrote:

> John Reagan wrote:
> > However, I'd guess that most
> > of the BASIC code out there is mostly in maintenance mode so us
> > adding 20 new BASIC features might go unused.
>
> And you'd guess wrong. We do new stuff every day.

Thanks for the input. Just out of curiosity, how many lines?

>
> However, with a few exceptions, which in my opinion aren't BASIC issues,
> the BASIC implementation on VMS is very robust. While I don't get out
> much, I'm not aware of any better. Not sure if you could find 20
> reasonable new features.
>

>

> What I find very annoying is not being able to easily call some
> non-BASIC routines. Usually the problem, (in my opinion) is C. Yes, I
> can build structures that C will accept, but there are times when it
> just doesn't work. OpenSSL comes to mind. But, that's on the roadmap,
> so maybe happier times ahead.

Is that due to have having BASIC versions of C header files or some missing language feature?

[David Froble]

John Reagan wrote:
> On Wednesday, February 25, 2015 at 12:52:15 PM UTC-5, David Froble wrote:
>> John Reagan wrote:
>>> However, I'd guess that most
>>> of the BASIC code out there is mostly in maintenance mode so us
>>> adding 20 new BASIC features might go unused.
>> And you'd guess wrong. We do new stuff every day.
>
> Thanks for the input. Just out of curiosity, how many lines?

Not sure what you're asking. New lines, or total. Last I heard, we had
well over a million lines of code in the Codis application.

>> However, with a few exceptions, which in my opinion aren't BASIC issues,
>> the BASIC implementation on VMS is very robust. While I don't get out
>> much, I'm not aware of any better. Not sure if you could find 20
>> reasonable new features.
>>
>
>> What I find very annoying is not being able to easily call some
>> non-BASIC routines. Usually the problem, (in my opinion) is C. Yes, I
>> can build structures that C will accept, but there are times when it
>> just doesn't work. OpenSSL comes to mind. But, that's on the roadmap,
>> so maybe happier times ahead.
>
> Is that due to have having BASIC versions of C header files or some missing language feature?

Perhaps if there were something like the C header files, with C type
structures, things might be easier. But, I don't think I know enough to
give you a good answer to that question.

I """think""" my problem with OpenSSL was some internal structure that I
didn't understand, and sure wasn't documented well, or at all.

Some pieces of C code is NOT documentation.

[Richard Maher]

On 2/25/2015 8:02 PM, Neil Rieck wrote:
> Folks, here is the link for the latest VSI roadmap.
>
> http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf

On second read it struck me that are 3rd Party update (or link to Kevin
Duffy's pages) would be really useful.

Last I heard I got all exited about 11g for VMS going through
manufacturing (both client and server!!!) So what's happening?

12G been fast tracked like Java 8?

[Stephen Hoffman]

It's that various of the core security-related libraries are C-based
with C-friendly APIs, and entirely lack descriptor-based APIs for other
descriptor-based languages.

It's largely possible to call those APIs from BASIC or Fortran, just a
pain — either C-isms all through the code, or creating descriptor-based
jackets for the routines of interest.

That the core security-related libraries are stale with OpenSSL 0.9.8
due to fall off support at the end of the year, and that CDSA is long
dead, is a different but related discussion. FWIW, Apple punted on the
OpenSSL and CDSA interfaces, and created their own Secure Transport
interface for OS X and iOS, as well as Keychain (certificate and
password storage) and related frameworks.

[Neil Rieck]

On Wednesday, February 25, 2015 at 9:29:55 AM UTC-5, David Froble wrote:
> Neil Rieck wrote:
>
> > Our shop still uses BASIC (we have ~ 500k lines) which is also
> > missing from their list. Apparently it was once very popular with the
> > American Insurance industry; not sure about 2015 (HP probably told
> > VSI about popularity based upon paid support contracts)
>

> Perhaps take another look at page 5 of the roadmap ....

Ah! Apologies. I missed that.

Neil

[Neil Rieck]

This news will make some people in my shop very happy. I know you probably aren't soliciting for suggestions but here are my two:

1) BASIC needs a "/NAMES" compile time switch like most other so-called DEC languages

2) BASIC needs support for unsigned integers

Neil

[VAXman-]

In article <mcl1tt$jmn$1...@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2015-02-25, David Froble <da...@tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>>
>>> However, I wonder if Python would be a good choice for an official
>>> VSI supported kit given it's increasing popularity elsewhere ?
>>>
>>> (I know third parties have Python running on VMS at the moment, but
>>> there's a big difference between a third party port and an official
>>> vendor supported kit you can use in production.)
>>
>> This is a strange thing to write, at least from my perspective ...
>>
>> I'm assuming that you mean VSI when you write "vendor supported kit",
>> since we are discussing the VSI roadmap.
>>
>> So, if you purchase a wholesale distribution application from say, me,
>> which would not be suported by VSI, would you not consider it something
>> you could use in production? I'd assume you'd purchase it because you
>> intended to actually use the product.
>
>No, it means that if you run something in production, you must be
>able to get support for it, including a defined escalation procedure
>which specifies when the problems you are experiencing will either
>be fixed or worked around.
>
>The current Python port is a best-effort port from a third party and
>while it's a really good thing it's available, you have to consider
>how you will fix any problems in the port if you make it a part of
>your production infrastructure.

Are you telling me you can't ring up John Cleese, Terry Gilliam, Eric Idle,
Terry Jones or Michael Palin?

>Buying something from your company would not be a problem in this
>case as it would come with a support contract which would include
>the above escalation procedures. However, before buying that product
>and signing that support contract, some managers/organisations may
>want to first establish if you are big enough to sue if something
>goes wrong.
>
>Simon.
>
>--
>Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
>Microsoft: Bringing you 1980s technology to a 21st century world

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

I speak to machines with the voice of humanity.

[John Reagan]

On Wednesday, February 25, 2015 at 6:38:15 PM UTC-5, Neil Rieck wrote:

> This news will make some people in my shop very happy. I know you probably aren't soliciting for suggestions but here are my two:
>
> 1) BASIC needs a "/NAMES" compile time switch like most other so-called DEC languages
>
> 2) BASIC needs support for unsigned integers
>

I'm always soliciting suggestions. Happy customers are paying customers. :)

I'll add them to my list.

[John Reagan]

On Wednesday, February 25, 2015 at 5:46:04 PM UTC-5, Stephen Hoffman wrote:
> On 2015-02-25 20:10:11 +0000, John Reagan said:

> >
> > Is that due to have having BASIC versions of C header files or some
> > missing language feature?
>
> It's that various of the core security-related libraries are C-based
> with C-friendly APIs, and entirely lack descriptor-based APIs for other
> descriptor-based languages.
>
> It's largely possible to call those APIs from BASIC or Fortran, just a

> pain -- either C-isms all through the code, or creating descriptor-based

> jackets for the routines of interest.
>

Descriptors are mostly commonly used with strings.

Languages like Fortran, Pascal, Ada, etc. use array descriptors but other than "arrays of char", there really isn't many public interfaces that take "arrays of floats" or "arrays of structs", are there? (I think there are some in SMG$)

So basically (pardon the pun), it is dealing with nul-terminated strings from non-C languages?

I added some nul-terminated string support to Pascal several years ago if you needed to create nul-terminated strings or accept them as arguments. Perhaps we need something across all the languages? BLISS has %ASCIZ and Macro32 has .asciz.

Of course, the other hurdle is getting the .h files converted into .for, .pas, or .ada files. If we only finished the Rosetta tool (it was going to be a follow on to SDL), that would have helped. Rosetta was going to accept SDL source, Rosetta source, and .H files as input. It collapsed under its own weight.

[John Reagan]

On Wednesday, February 25, 2015 at 4:21:38 PM UTC-5, David Froble wrote:
> John Reagan wrote:

> > Thanks for the input. Just out of curiosity, how many lines?
>
> Not sure what you're asking. New lines, or total. Last I heard, we had
> well over a million lines of code in the Codis application.
>

That's what I want to see. People keep wanting to tell me that BASIC and Pascal are fringe languages. I keep saying there are lots of real (and large) applications, but I want real data points. Another customer contacted me via email today with a Pascal application just shy of 1 million lines.

[John Reagan]

On Wednesday, February 25, 2015 at 4:21:38 PM UTC-5, David Froble wrote:

>
> I """think""" my problem with OpenSSL was some internal structure that I
> didn't understand, and sure wasn't documented well, or at all.
>
> Some pieces of C code is NOT documentation.

Tell me about it. It isn't just C. I keep finding Macro-32 code or BLISS code with no comments (or worse, obsolete comments).

If you are going to change the code, either update the comments or just delete them. I keep wasting my time reading (and believing) worthless comments.

[David Froble]

John Reagan wrote:
> On Wednesday, February 25, 2015 at 6:38:15 PM UTC-5, Neil Rieck wrote:
>
>> This news will make some people in my shop very happy. I know you probably aren't soliciting for suggestions but here are my two:
>>
>> 1) BASIC needs a "/NAMES" compile time switch like most other so-called DEC languages
>>
>> 2) BASIC needs support for unsigned integers

Yes, this is something that would be appreciated. Very appreciated.
Don't know how much work it will be.

[Craig A. Berry]

I don't recall ever hearing of Rosetta in a DEC context (only Apple). If
you could convert .h to SDL, wouldn't SDL pretty much handle the rest?

Actually one thing it wouldn't handle would be automatically generating
the wrapper routines, which should be doable.

[JF Mezei]

On 15-02-25 18:38, Neil Rieck wrote:

> 2) BASIC needs support for unsigned integers

What sort of usage would require unsigned int in BASIC ?

With 64 bit values, do you really need that 1 extra bit ?

Do people do bit shifting in BASIC ?

[Paul Sture]

The following link was provided in an online forum in response to a
comment which scoffed that Pascal was only of use as a teaching language:

<http://delphi.wikia.com/wiki/Good_Quality_Applications_Built_With_Delphi>

Pascal is there, and in connection with good quality too.

--
Don't ever use the last two versions of GCC in serious stuff :)
-- fortune cookie seen on GCC Bugzilla – Bug List

[Paul Sture]

On 2015-02-26, John Reagan <xyzz...@gmail.com> wrote:

Your mention of Pascal reminds me that Borland's Delphi product provided
a Pascal version of the headers necessary for Windows system calls, and
that worked nicely - I managed to ignore Microsoft's insistence that
I needed to use C for such stuff :-)

[Joukj]

Neil Rieck wrote:
> Folks, here is the link for the latest VSI roadmap.
>
> http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf

wondering why the RX4640 is not listed amongst the "potential support"
servers.

Jouk

[li...@openmailbox.org]

On Thu, 26 Feb 2015 00:15:25 -0500
JF Mezei via Info-vax <info...@rbnsn.com> wrote:

> On 15-02-25 18:38, Neil Rieck wrote:
>
> > 2) BASIC needs support for unsigned integers

Fortran needs support for unsigned integers! But the Standards Committee is
making sure that never happens, revision after revision. Some vendors offer
it as an extension, but it's not interoperable with C and it's sometimes
(always?) not even interoperable with signed integers in the same program.

> What sort of usage would require unsigned int in BASIC ?

Mostly C and POSIX interop but also interop with other languages.

> With 64 bit values, do you really need that 1 extra bit ?

Yes, if you interoperate with other languages or data sources that use
unsigned integers i.e. POSIX.

[li...@openmailbox.org]

On Wed, 25 Feb 2015 18:28:22 -0800 (PST)
John Reagan via Info-vax <info...@rbnsn.com> wrote:

> That's what I want to see. People keep wanting to tell me that BASIC and
> Pascal are fringe languages. I keep saying there are lots of real (and
> large) applications, but I want real data points. Another customer
> contacted me via email today with a Pascal application just shy of 1
> million lines.

I think they are fringe languages and they're certainly on the verge of
death if not already buried on most other platforms.

As a developer and an outsider and a VMS n00b what strikes me most about
VMS is that the language products are real, professional good stuff.

Most people are using C-based OS so C is the best and only acceptable
choice for writing most code because all the system interface is in C and
anything else is cobbled together, incomplete, etc. Since no vendor is
maintaining it nobody knows how long it will last and when it breaks if it
will ever get fixed. That's not something the kind of "enterprises" I work
with could tolerate. And they don't.

It seems to me the VMS languages have really good system interface so that
even BASIC isn't a second or third class citizen. This allows application
people a lot of leeway in choosing what language they want to write their
application in- because you can do most anything in any VMS language
implementation. I may be wrong about this but that's what it seems from my
few days of going over manuals.

If that is correct then I think as long as the runtimes are updated to keep
pace with OS changes then all of the currently supported languages will
remain viable and very useful. There are people who can't stop tinkering
with perfectly good language implementations and in the process their
implementation becomes a bug-ridden unserviceable mess. It's a lot better
to leave a perfectly good language alone because most people are not
qualified to be language designers, and just work on keeping the runtime
updated and as useful as possible.

[Richard Maher]

On 2/26/2015 10:28 AM, John Reagan wrote:
A really really long line :-(

>

> Another customer contacted me via email today with a Pascal

>application just shy of 1 million lines.

Lotto number generator perhaps?

It has been my awful experience that DEC Europe was, to a large extent,
responsible for spreading/inflicting the cancer that is Pascal onto an
unwary public. All those also-rans come "Consultants" spreading the word.

I personally had the misfortune to work on the SPACE system and I know
LIFFE had at least one tumour in its billing system.

[clairg...@gmail.com]

For pre-i2 systems we are just thinking about system that have had at least a handful of customer requests. Take a look at Slide 21; if it isn't there, there hasn't been much interest.

[abrsvc]

Just an FYI:

The roadmap link on the site still points to the one dated in July, NOT the new one. The new roadmap can be seen under the UPDATES tab as an engineering update.

Dan

[Neil Rieck]

Mostly for dealing with things outside of BASIC. For example, I'm sure HP doesn't want people to do this (however this is MY employer's system), but I wanted to write a BASIC program to directly open SYSUAF where at least one of the keys (er, indexes) is an unsigned quadword. Since BASIC has no unsigned quads there was no way to do this with an indexed open so I resorted to a much more brute-force approach.

http://www3.sympatico.ca/n.rieck/demo_vms_html/bas_read_sysuaf.html

When DEC-BASIC (or whatever it is called these days) was created , we only saw 7-bit ASCII data and yet I longed for an unsigned byte to more easily convert back and forth. This has only gotten worse with the introduction of ISO-8859-1 but I have always been able to program my way around these little issues.

This brings me to two issues related to character processing:
Lots of our production code uses EDIT$ to upcase data. Whoever designed ISO-8859-1 did a really crappy job with the 8-bit characters so attempting to use EDIT$ to upcase a diacritical-marked character (eg. egrave) returns the wrong result. Okay, we understood the problem then just wrote our own upcase routines.
1) But it would be really nice if some new functionality was introduced to EDIT$ (perhaps a bit to say that all existing operations should conform to new 8-bit rules (this also means that 160 would be treated as 32 when removing whitespace)
2) It sure would have been nice to downcase data (once again, we wrote our own)

For anyone out there who thinks this is just nuts, between 2001 and 2011 it was my VMS-BASIC code which translated French and Spanish language set-top-box data from unicode into ISO-8859-1 before it was sent to TV-guide each night in Tulsa Oklahoma. We don't do that function anymore but this old code now parses French language web pages.

[John Reagan]

On Wednesday, February 25, 2015 at 11:52:15 PM UTC-5, Craig A. Berry wrote:

>
> I don't recall ever hearing of Rosetta in a DEC context (only Apple). If
> you could convert .h to SDL, wouldn't SDL pretty much handle the rest?
>
> Actually one thing it wouldn't handle would be automatically generating
> the wrapper routines, which should be doable.

Yes, just a .h to SDL converter would help but there was more to Rosetta. It was going to be an ASN.1 compiler (long before you could find an open source version), produce stub routines for RPC calls, interface into the CDD, etc. Plus SDL was written in PL/1 at the time so there was effort to rewrite it. SDL has since been rewritten out of PL/1 into C (or is it C++, I forget).

[Simon Clubley]

On 2015-02-25, John Reagan <xyzz...@gmail.com> wrote:
>
> Descriptors are mostly commonly used with strings.
>
> Languages like Fortran, Pascal, Ada, etc. use array descriptors but other
> than "arrays of char", there really isn't many public interfaces that take
> "arrays of floats" or "arrays of structs", are there? (I think there are some
> in SMG$)
>

Do any of the VMS specific math routines ? (I haven't had cause to ever
really use the VMS specific math routines instead of the language
supplied ones so I don't really know the answer to that question.)

The reason for asking is that passing arrays of floating point numbers is
quite common in some math areas. One example (chosen at random from the
FFTW library):

http://www.fftw.org/fftw3_doc/Complex-DFTs.html#Complex-DFTs

[Simon Clubley]

On 2015-02-26, JF Mezei <jfmezei...@vaxination.ca> wrote:
>
> With 64 bit values, do you really need that 1 extra bit ?
>

Wrong thinking. :-)

You should use the datatypes to try and model the problem at hand.
For example, it's not a good match to use signed integers to index
arrays (and there have been a number of security issues in code
written in C and friends over the years caused by the use of signed
integers).

[Bob Koehler]

In article <8c87e492-f54e-4411...@googlegroups.com>, Neil Rieck <n.r...@sympatico.ca> writes:
>
> 2) BASIC needs support for unsigned integers
>

So does Fortran, Java, ECMAScript, ...

But I don't expect VSI to jump out ahead of everyone else in this
reguard too early in thier lifetime.

[Bill Gunshannon]

In article <346eb384-6ca2-4691...@googlegroups.com>,

There are hundreds of millions if not billions of lines of COBOL code
out in the world. And places are doing new development in it everyday.
And yet it is still considered "fringe" and schools refuse to continue
to teach it even going so far as to tell students that even learning
COBOL will be dettrimental to their career opportunities.

Would you expect Pascal and especially BASIC (which has had a bad rep
since its earliest days!!) to fare any better?

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bill...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[John Reagan]

On Thursday, February 26, 2015 at 8:43:21 AM UTC-5, Simon Clubley wrote:
> On 2015-02-25, John Reagan <xyzz...@gmail.com> wrote:
> >
> > Descriptors are mostly commonly used with strings.
> >
> > Languages like Fortran, Pascal, Ada, etc. use array descriptors but other
> > than "arrays of char", there really isn't many public interfaces that take
> > "arrays of floats" or "arrays of structs", are there? (I think there are some
> > in SMG$)
> >
>
> Do any of the VMS specific math routines ? (I haven't had cause to ever
> really use the VMS specific math routines instead of the language
> supplied ones so I don't really know the answer to that question.)
>
> The reason for asking is that passing arrays of floating point numbers is
> quite common in some math areas. One example (chosen at random from the
> FFTW library):
>
> http://www.fftw.org/fftw3_doc/Complex-DFTs.html#Complex-DFTs
>

Those do exist. I was thinking more about OpenVMS interfaces.

If you had those FFTW routines on OpenVMS, yes they might need work to be
callable from both C and Fortran (and COBOL and Pascal and BASIC) depending on their usage.

[Stephen Hoffman]

On 2015-02-26 02:25:38 +0000, John Reagan said:

> On Wednesday, February 25, 2015 at 5:46:04 PM UTC-5, Stephen Hoffman wrote:
>> On 2015-02-25 20:10:11 +0000, John Reagan said:
>
>>>
>>> Is that due to have having BASIC versions of C header files or some> >
>>> missing language feature?
>>
>> It's that various of the core security-related libraries are C-based>
>> with C-friendly APIs, and entirely lack descriptor-based APIs for
>> other> descriptor-based languages.
>>
>> It's largely possible to call those APIs from BASIC or Fortran, just a>
>> pain -- either C-isms all through the code, or creating
>> descriptor-based> jackets for the routines of interest.
>>
>
> Descriptors are mostly commonly used with strings.
>
> Languages like Fortran, Pascal, Ada, etc. use array descriptors but
> other than "arrays of char", there really isn't many public interfaces
> that take "arrays of floats" or "arrays of structs", are there? (I
> think there are some in SMG$)

OpenVMS programming interfaces expanded past the system services and
RTLs years ago. In particular, OpenSSL and CDSA (R.I.P.) and LDAP —
which can provide something akin to what some folks use logical names
for, in VMS terms — for some projects. Here's what's involved with
calling OpenSSL from a descriptor-based language:
<http://labs.hoffmanlabs.com/node/1853> (That's both jackets, and a
simplified API.)

The whole Open Source Security area of OpenVMS is a complete and utter
mess; it's often ancient versions (OpenSSL 0.9.8 falls off support at
the end of 2015), and the whole area is most definitely not integrated
with the rest of OpenVMS. In the closed-source security arena, ACME
(sys$acm, sys$acmw) is exceedingly fun to use; there are some supported
parts of that API which the doc was a complete dog's breakfast, and
reading the source listings becomes the usual recourse. Then there's
certificate management, which would be an utter and hilarious joke on
VMS, if it weren't central to modern network security. The lack of
anything remotely similar to the OS X Keychain and its
cryptographically protected and shared certificate and password
storage, for that matter.

As for certificates, IIRC, CDSA (R.I.P) has a certificate store,
OpenSSL has a certificate store, Firefox has a certificate store,
Apache has a certificate store, ssh has a certificate store, sshd has a
certificate store, ACME tells folks to store their certificates into
SYS$MANAGER: (haven't checked that doc to see if the certificates are
protected, or if there's a private key around), and it wouldn't
surprise me to find other caches of certificates around the system.
The certificate and the TCP/IP Services example procedures are often
ill-constructed, confusing and generally a mess — that's before you get
into that utterly embarrassing example C code that Mr Adams blindly
re-used, too.

The other part of what Keychain provides is password storage, and
DECnet has a password store, clustering has a password store (and it
stores the cluster password used in "cleartext", IIRC), AMDS/AvailMan
has a password store, as do various end-user applications.

As for the OpenVMS Open Source pieces and Open Source Security pieces
in general, it's even worse if you're not using C or C++ to access what
is available.

> So basically (pardon the pun), it is dealing with nul-terminated
> strings from non-C languages?

That's a piece, and then there are the interfaces themselves that are
somewhat of a mess. Whether it's the OpenSSL and CDSA (R.I.P.)
interfaces, or the rather hideous decc$to_vms call, or everybody's
"favorite" SMG$CREATE_MENU call
<http://www.openvms.compaq.com/wizard/wiz_8111.html>.

> I added some nul-terminated string support to Pascal several years ago
> if you needed to create nul-terminated strings or accept them as
> arguments. Perhaps we need something across all the languages?

That'd help, certainly.

> BLISS has %ASCIZ and Macro32 has .asciz.

The declarations aren't difficult. None of this is difficult. It's
the combination of copying stuff into and out of %ASCIZ-style
declarations and ensuring the termination and the argument-passing via
%REF() and constructs like itemlists that's more of a hassle; that all
pushes the API details up into the calling code. In classic OpenVMS
terms, this is the distinction between using lib$getdvi and sys$getdvi
calls. For the descriptor-based languages, the RTL equivalents of the
system services calls are vastly easier to use.

I wouldn't object to adding pointers and objects and protocols and
delegation into BASIC, but I'd suspect some folks' heads might explode.
:-)

> Of course, the other hurdle is getting the .h files converted into
> .for, .pas, or .ada files. If we only finished the Rosetta tool (it
> was going to be a follow on to SDL), that would have helped. Rosetta
> was going to accept SDL source, Rosetta source, and .H files as input.
> It collapsed under its own weight.

Yes; but — having worked on various DEC-cancelled projects — it's less
about what was, and more about what is and what can be. I've been
using SDL for a while, and have done custom SDL back-ends for some
projects; one for COBOL, for instance. Data definitions can be a
hassle on most platforms, but — and John is already aware of this — VMS
wants to have a common source across multiple languages and that's just
not a particularly common problem, outside of something like SQL or
SQL-like database access and a few similar areas.

Also on the subject of SDL, SDL (SDLC) picked up string descriptor
support and DCL support "recently", which helped a few projects move
forward. There was a gap in the BASIC back-end for SDL or in BASIC
itself that tripped up Neil Rieck within the last year or so, IIRC; one
of the API declarations wasn't usable from BASIC. Not sure if what's
on the OpenVMS Freeware is the most recent SDL (SDLC) version, either.

Re-doing something like SDL with .SDL and .H imports using LLVM would
be an interesting project. Using the LLVM pieces would allow complete
context-sensitive C syntax support when processing the .H files, which
is where the home-grown preprocessors usually fell over. But then I'm
not usually doing all that much past what SDL (SDLC) can provide now,
so...



--
Pure Personal Opinion | HoffmanLabs LLC

[dodecah...@gmail.com]

+1 and well put

Rapid development comes down to libraries and frameworks, at least for new stuff

My vote goes towards implementing something like MS's .net framework where they created their CIL layer for which all languages compile down to as an intermediary language. This can then be shipped to run anywhere, theoretically, independent of underlining Os version and hardware architecture

Windows created it's .net framework (whether they stole from the Java world isn't being debated here) but I think they did a brilliant job as they effectively unified their languages so that it didn't matter what language you ultimately code in

They did away with the code and compile to a specific architecture cycle and added a third logical layer that has some real benefits in terms of code portability and run-time

Their model is, Language -> CIL (common intermediate language) -> CLR (common language run-time)

This adds a logical layer between the application and the OS. It then doesn't matter if the OS changes as long as the version of .net relevant to the application assembly exists, the code can run, somewhat virtualised

Contrast this to having your compiler generate code specific to the OS version and OS architecture (already we have some system calls that are alpha specific! ).

I'm certainly no programmer but I think what MS did with it's whole .net framework was visionary and certainly moved windows on from a one language beast (visual basic was pushed because Bill Gates used it but now C# is the main flavour, contrast this with unix that is still pretty much C locked to this day)

MS did however have to bite the bullet and bring OO (in some cases, force) extensions into their languages. I remember the cry from many a basic programmer about how their language was being changed and made more complex, however, they did eventually move to a more modern construct of the language

Having some type of CIL code in VMS would free us (or go a long way towards) allowing us to change architectures (I'm thinking, Application code here) more easily going forward without the need to always recode, recompile, retest over and over again when VMS moves onto a new architecture. This whole recoding cycle is why, where I work, VMS is left to die in the back corner running an application that they refuse to modernise because of the huge recoding and retesting effort involved just because HP insisted on loving Itanium for too long

Running an existing application inside an emulated environment (charon etc) to escape hardware obsolescence is ok for a while but as the OS moves onwards and changes architectures then having to maintain several versions of an emulator will eventually wind us back in the same spot we are in today with the Vax and Alpha and Itanium architectures. Having code compile down to something like CIL will (should) make porting an application to a totally new architecture much easier as your not having to test for functional hardware changes as much

Just how far forward do we want to project our compiler and development efforts? I know short term we need to get VMS viable again but thought I thought it might also be relevant to be thinking about where we want to be eventually taking VMS software development to...

p.s.. I don't code on windows and I don't code much at all but I sat next to someone who used to write stuff for VMS but has moved onto windows and had to put up their ear-bashing about the virtues of .net for a few years :-) I guess some of it rubbed off on me

[dodecah...@gmail.com]

On Wednesday, February 25, 2015 at 11:02:09 PM UTC+11, Neil Rieck wrote:
> Folks, here is the link for the latest VSI roadmap.
>
> http://www.vmssoftware.com/pdfs/VMS_Software_Roadmap_20150224.pdf
>

> Everyone will have their favorite paragraphs. For me, it is hard not to like the whole thing but here are my three:
>
> 1) new TCP/IP stack
> 2) updated open source kits (Apache, gSOAP, Samba, SSL)
> 3) updated language standards (C and C++)

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

> 1) new TCP/IP stack

As long as it's easier to administer than the current. Let me refine that, as long as the documentation of whatever new stack we get has the traditional VMS extensive documentation, not the half arsed unix ported stuff we currently have. I will qualify this, I am no tcpip expert by any stretch of the imagination and I have found the current documentation very much geared towards a unix style of documentation, lists of commands and switches in isolation.

I'd like to see documentation with a functional approach. i.e. If you want to configure your system to handle this, here's how you would set it up from start to finish, not just screeds of commands that just tell you what and not why. I usually have to resort to google to get my answers, which can often lead to hoffs site

Let's hope the documentation also moves into the modern world and has embedded video etc as well. There's something extra about having someone take you through how to do something while talking to you and adding a wealth of background information as they go, far better than just reading a manual - you need both IMO. Documentation is also training manuals these days

> 2) updated open source kits (Apache, gSOAP, Samba, SSL)

I'd like to see VSI perhaps negotiate something with the maintainer of the WASD web server (and Python for that matter). WASD is cluster aware and administered, runs on all 3 architectures and outperforms Apache quite comprehensively in terms of throughput. Some large sites are running WASD

> 3) updated language standards (C and C++)

+1

Other directions and statements by VSI about he future of VMS I would like to see, would be:

Databases
---------
What is Oracle doing about RDB then?
Has VSI had discussions with them about keeping rdb releases rollowing forward with new functionality? I suspect Oracle will do a minimal amount of work on rdb hoping that people will migrate away to it's own servers? RDB8 must have been on the verge of release I would have thought? I've seen references to it in books by the rdb authors so it must have been close to release. From what I understand, it was supposed to run on NT (alpha?)

Most OS's years back used a database to cement themselves into businesses, what will VSI do as far as a db offering is concerned? I was looking at the likes of Cassandra (nosql db) and even hbase for ultra fast distributed db's, I would think the likes of Cassandra on a VMS cluster would be a good fit? In the predicted explosion of data that's going to be generated in the next decade, relational db's are supposedly going to go into a steady state growth curve, so some type of nosql offering might do VMS well

New file system
----------------
The notes state New File System
* Eliminate 2TB volume size limit
* Improved performance

Does this mean a totally new file system built from the ground up? or an enhanced file system supporting larger drives and a few tweaks?

Looks like the later. I was hoping for something like lustre support, yeah, I know, that's a very big ask and somewhat a dream but hey, one can always dream. Maybe the likes of Cassandra can be tweaked to create a high performance file system?
Eliminate 2Tb limit, replace it with what limit I wonder? I hope it's with something obscenely large so that a limit is never thought about again. Something supporting into the Yottabyte region will probably not be scoffed at in a few years as molecular storage starts to become more and more feasible

Training / Education
--------------------
On-line content coming?
Community learning programs perhaps?

Hobbyist Program
-----------------
Someone else already asked this on the facebook page, I never saw a reply to their question, so I'll state it here for them and for myself

What is going to happen with the hobbyist program?

What I did like
---------------
Per socket pricing

Even MS has didn't like per core pricing and has stuck with per socket

Better flexibility in licencing not trying to strangle every last cent out of everyone is a winner

In the data centres, the trend is to licence only what you have to and that means production. Everything else is being taken off licencing to reduce cost. For testing system, they will not bother with paying for a licence, they would rather add a month to the test cycle than pay for a licence. site wide licences and dynamic licensing are favoured

With OS's becoming fragmented and moving away from an all you can eat offering, just where does VMS want to be?

As a high secure OS protecting a corporates data? I don't think VMS can gain much in the embedded small system domain (i.e. your fridge!). The desktop market has been captured but is also slowly fading away to a web based one, so VMS isn't going to get traction there. As a high availability mail server? The world is hanging out for something other than exchange IMO, I think something developed on VMS that used it's clustering ability could be a winner but breaking into that market would be tough and a long drawn out battle.

Exciting times, and very much defining times ahead :-)

[JF Mezei]

With regards to the TCPIP stack.

If you are in a VMS-only shop, something which may have been common in
mid 1980s, but not anymore, it is OK to have proprietary VMS style commands.

However, in a mixed environment, having standard unix utilities with the
same switches and syntax as on other platforms becomes an advantage
despite them not being "VMS" in nature.

The above is geared more towards stuff like ping, traceroute, netstat,
ifconfig etc.

With regards to configuration, the most important thing is consistency.
Either all unix style or all VMS style.

[Stephen Hoffman]

On 2015-02-26 19:09:54 +0000, dodecah...@gmail.com said:

> Rapid development comes down to libraries and frameworks, at least for
> new stuff
>
> My vote goes towards implementing something like MS's .net framework
> where they created their CIL layer for which all languages compile down
> to as an intermediary language.

That'd be the calling standard and the common language environment, on VMS.

More typical on VMS is shipping new language-specific run-times, as
some of the compiler kits do.=

> This can then be shipped to run anywhere, theoretically, independent of
> underlining Os version and hardware architecture

The theoretical has a nasty habit of slamming into reality.

> Windows created it's .net framework (whether they stole from the Java
> world isn't being debated here) but I think they did a brilliant job as
> they effectively unified their languages so that it didn't matter what
> language you ultimately code in
>
> They did away with the code and compile to a specific architecture
> cycle and added a third logical layer that has some real benefits in
> terms of code portability and run-time
>
> Their model is, Language -> CIL (common intermediate language) -> CLR
> (common language run-time)
>
> This adds a logical layer between the application and the OS. It then
> doesn't matter if the OS changes as long as the version of .net
> relevant to the application assembly exists, the code can run, somewhat
> virtualised

This is one approach to avoiding DLL hell. Sort of. Everybody then
gets to deal with shipping and maintaining different versions of .NET.
<https://msdn.microsoft.com/en-us/library/ff602939(v=vs.110).aspx>.
VMS tried to make all RTL libraries and system services
upward-compatible, which means building on an other version usually
works. (Alas, it also means that there's a whole lot of effort
involved with maintaining that upward-compatibility, and VMS
engineering has been loathe to remove the oldest and gnarliest of the
code, for reasons of compatibility. See my references to the
compatibility millstone, posted earlier today.) On other platforms,
the frameworks are packaged into application bundles, which is akin to
packaging the app with its own DLLs or its own .NET or its own VMS
shareable images. On Android, Google used the Davlek bytecode scheme
with JIT akin to Java, but is now adding updates outside of the OS and
via an add-on package of Android Runtime (ART) routines. Different
solutions. All workable.

> Contrast this to having your compiler generate code specific to the OS
> version and OS architecture (already we have some system calls that are
> alpha specific! ).

Usual on VMS is to either a back-build, or to build for the oldest version.

There are architectural details that can derail Alpha and Itanium
source compatibility, but the two can generally work from the exact
same code-base. That's what VMS does, as do many applications.

> I'm certainly no programmer

That's somewhat of a handicap in this discussion.

> but I think what MS did with it's whole .net framework was visionary
> and certainly moved windows on from a one language beast (visual basic
> was pushed because Bill Gates used it but now C# is the main flavour,
> contrast this with unix that is still pretty much C locked to this day)

VMS isn't Unix. Or Windows. The VMS calling standard already permits
mixed-language programming, and entirely within the same application
executable, and VMS provides source portability for most operations
across platforms. It's common to see applications involving C,
assembler and other languages all mixed together in one executable
image, too. More than a little code is recompile and relink and run on
Alpha and Itanium, and there's little reason to assume that won't also
be the case with any VMS port to x86-64.

> MS did however have to bite the bullet and bring OO (in some cases,
> force) extensions into their languages. I remember the cry from many a
> basic programmer about how their language was being changed and made
> more complex, however, they did eventually move to a more modern
> construct of the language

Strictly for application platform portability across platforms and
versions, OO is not a central factor.

OO is a factor here when you push OO features into the OS APIs, such as
what Apple has done with OS X and iOS with Objective C and Swift.
Pushing OO into the APIs does make sense for various environments, too
— the final linkages between the various components are performed at
run-time, and modifications and "patches" and extensions become
available.

In practical terms, if you're going to go to the effort of creating a
bytecode portability layer, then having OO capabilities within that
layer is effectively a necessity. You're going to be interoperating
with OO languages, and Microsoft has more than a little C++ code around.

> Having some type of CIL code in VMS would free us (or go a long way
> towards) allowing us to change architectures (I'm thinking, Application
> code here) more easily going forward without the need to always recode,
> recompile, retest over and over again when VMS moves onto a new
> architecture. This whole recoding cycle is why, where I work, VMS is
> left to die in the back corner running an application that they refuse
> to modernise because of the huge recoding and retesting effort involved
> just because HP insisted on loving Itanium for too long

Might want to ponder what was done during the last two ports of VMS,
and toward the simplicity or the complexity of recompiling the source
code for the new architecture, then.

For running on older versions, you can back-link (unsupported, but
usually works) or can just build your code on the oldest release. Not
having to use lib$find_image_symbol to use newer system services or
newer RTL features would be nice, though.

> Running an existing application inside an emulated environment (charon
> etc) to escape hardware obsolescence is ok for a while but as the OS
> moves onwards and changes architectures then having to maintain several
> versions of an emulator will eventually wind us back in the same spot
> we are in today with the Vax and Alpha and Itanium architectures.
> Having code compile down to something like CIL will (should) make
> porting an application to a totally new architecture much easier as
> your not having to test for functional hardware changes as much

First saw bytecode tools back with the Terak
<http://en.wikipedia.org/wiki/Terak_8510/a> and UCSD p-System and its
p-Code; back around 1980. The p-Code stuff and the JVM and .NET
intermediate layers are all neat ideas, but — admittedly being somewhat
dense — reasonable native source code portability seems to be a pretty
good alternative to the approach. Not having to debug run-time errors
back up through a bytecode layer is nice, too. p-Code and the JVM —
and the less-than-successful EFI byte code stuff, for that matter —
does mean not having to haul the rest of the run-time environment to
the target platform, but AFAIK the VSI plan here is to have native VMS
on x86-64, and to male available translation tools for applications
where no source code is available.

> Just how far forward do we want to project our compiler and development
> efforts? I know short term we need to get VMS viable again but thought
> I thought it might also be relevant to be thinking about where we want
> to be eventually taking VMS software development to...

I'd rather see more going into the compilers and tools, and not into
trying to emulate Microsoft's attempts to dig themselves out of
maintaining and updating their own products across a gazillion
different APIs and multiple older software versions.

> p.s.. I don't code on windows and I don't code much at all but I sat
> next to someone who used to write stuff for VMS but has moved onto
> windows and had to put up their ear-bashing about the virtues of .net
> for a few years :-) I guess some of it rubbed off on me

There can be reasons to roll out a .NET-like solution. But you haven't
yet sold me on the value of that implementation, here. There's still
a need to test in the various target versions, and somebody's going to
sign up to create and maintain the bytecode engine and the
cross-version compatibility layer, too. VSI probably isn't going to
be hauling much code back to Alpha, and it seems rather unlikely that
they'd create and backport a .NET framework for HP. It seems more
likely they'll be using common sources for their Itanium and x86-64
builds, as will most third-party vendors and customers.

[John Reagan]

On Thursday, February 26, 2015 at 11:31:10 AM UTC-5, Stephen Hoffman wrote:

> calls. For the descriptor-based languages, the RTL equivalents of the
> system services calls are vastly easier to use.

The phrase "descriptor-based languages" still confuses me. You are still taking strings, yes? BASIC's desire to use CLASS_D/DTYPE_T to manage strings, Fortran's default to use CLASS_S/DTYPE_T for string parameters, etc.

However, for the strongly-typed languages (Ada and Pascal), the passing mechanism is more a function of the prototype rather than the datatype of the actual parameter. All of that stuff is buried in the prototypes in the STARLET.PAS or STARLET.ADA files. Pascal is more than happy to pass a string by CLASS_S, CLASS_VS, or even CLASS_VSA. Ada prefers CLASS_SD for strings. It is only for languages that don't have descriptive prototypes that you have to know how many commas you need or which ones are passed by descriptor.

None of the languages use descriptors for scalars for instance (although you can get Pascal to automatically build CLASS_S/DTYPE_L,DTYPE_F, etc. when passing them as parameters). You can even get a CLASS_UBA if you ask nicely.

Fortran does use CLASS_NCA to manage dynamic arrays. It could have used anything, but it picked a documented descriptor (it helps with debugging since the debugger doesn't have to have special Fortran knowledge). Pascal's uses its own private 'descriptor' to manage run-time sized types. No descriptor can completely describe the various offsets (and that leads to ugly/incomplete debugging support).

I agree that none is difficult but the power of the OpenVMS descriptors and itemlists does require some extra knowledge beyond what a traditional C-style API requires. For a C-style, you normally only need to know if you use an ampersand or not.

I've spent many months over my career messing around trying to get the non-C headers as best as possible. Internal fights over who maintains the SDL backends, where the headers ship, etc.

Nobody is surprised that the C headers or Macro macros ship on the system since they describe the system, but tell me the fights I had trying to get the BASIC, Fortran (FORSYSDEF), and Pascal headers to ship on the system... They shipped on the compiler kits for years. I've had to update compiler kits just to include improved headers. The Ada headers never shipped on the system, only on the compiler kit (and are always out of date).

[Stephen Hoffman]

On 2015-02-26 21:32:21 +0000, John Reagan said:

> On Thursday, February 26, 2015 at 11:31:10 AM UTC-5, Stephen Hoffman wrote:
>> calls. For the descriptor-based languages, the RTL equivalents of
>> the> system services calls are vastly easier to use.
>
> The phrase "descriptor-based languages" still confuses me.

BASIC, Fortran and COBOL are three of the common ones. Languages that
use string descriptors for their argument-passing, and usually without
any explict references to descriptors within the source code of the
application programs. Languages where you don't tend to need or use
the str$analyze_sdesc call, and aren't calling lib$sget1_dd and friends.

C, C++, Bliss, Macro32, Macro64 are pointer-based, and these usually
include pointers to strings (char * or char str[whatever]) and usually
include explicit references to string descriptors and descriptor data
structures within the source code for the applications, when string
descriptors are needed. Languages where you do tend to need or use the
str$analyze_sdesc call, and where you can and variously are calling
lib$sget1_dd and lib$sfree1_dd and related.

Yes, I'm here quite intentionally ignoring Fortran and its support for
pointers. Sorry, Fortran fans.

> You are still taking strings, yes? BASIC's desire to use
> CLASS_D/DTYPE_T to manage strings, Fortran's default to use
> CLASS_S/DTYPE_T for string parameters, etc.

Yes; the languages that inherently and natively use string descriptors
for their string-related argument-passing.

> However, for the strongly-typed languages (Ada and Pascal), the passing
> mechanism is more a function of the prototype rather than the datatype
> of the actual parameter. All of that stuff is buried in the prototypes
> in the STARLET.PAS or STARLET.ADA files. Pascal is more than happy to
> pass a string by CLASS_S, CLASS_VS, or even CLASS_VSA. Ada prefers
> CLASS_SD for strings. It is only for languages that don't have
> descriptive prototypes that you have to know how many commas you need
> or which ones are passed by descriptor.

Pascal was the test-bed for every type of descriptor known to VMS, or
so it seemed. As I've previously stated, Pascal taught me about the
different descriptors used around VMS, and a whole lot about using the
VMS debugger to figure out which descriptor was being used for a
particular call. Pascal was where I first met the NCA descriptor, for
instance.

> I agree that none is difficult but the power of the OpenVMS descriptors
> and itemlists does require some extra knowledge beyond what a
> traditional C-style API requires. For a C-style, you normally only
> need to know if you use an ampersand or not.
>
> I've spent many months over my career messing around trying to get the
> non-C headers as best as possible. Internal fights over who maintains
> the SDL backends, where the headers ship, etc.
> Nobody is surprised that the C headers or Macro macros ship on the
> system since they describe the system, but tell me the fights I had
> trying to get the BASIC, Fortran (FORSYSDEF), and Pascal headers to
> ship on the system... They shipped on the compiler kits for years.
> I've had to update compiler kits just to include improved headers. The
> Ada headers never shipped on the system, only on the compiler kit (and
> are always out of date).

I'm well aware of the debates, and the subtle changes, and the bug
reports, and M.S. and L.D. and their __NEW_STARLET changes, and at
least parts of the rest of the declaration-related quagmire.

The VMS security APIs are a problem to use from the descriptor-based
languages; from languages including BASIC, Fortran and COBOL. Yes,
it's possible, but you either end up with jackets, or pushing the API
details up into the calling code, which tends to make a mess.

For the classic "assists" that were used here, see lib$getdvi versus
sys$getdvi.

[glen herrmannsfeldt]

Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2015-02-26 21:32:21 +0000, John Reagan said:

>> On Thursday, February 26, 2015 at 11:31:10 AM UTC-5, Stephen Hoffman wrote:
>>> calls. For the descriptor-based languages, the RTL equivalents of
>>> the> system services calls are vastly easier to use.

>> The phrase "descriptor-based languages" still confuses me.

> BASIC, Fortran and COBOL are three of the common ones. Languages that
> use string descriptors for their argument-passing, and usually without
> any explict references to descriptors within the source code of the
> application programs. Languages where you don't tend to need or use
> the str$analyze_sdesc call, and aren't calling lib$sget1_dd and friends.

Well, Fortran traditionally was %ref, but with Fortran 77 added
%descr for strings, and Fortran 90 added it for arrays (assumed shape).

PL/I has always been descripter based, except for non-string scalars.

An interesting difference between PL/I and Fortran array descriptors
is that Fortran uses the actual origin, where PL/I uses the virtual
origin. VMS descriptors include both.

(PL/I passed both the lower and upper bound for array dimensions,
where Fortran only passes the upper bound.)

-- glen

[John Reagan]

On Thursday, February 26, 2015 at 6:29:12 PM UTC-5, glen herrmannsfeldt wrote:

>
> An interesting difference between PL/I and Fortran array descriptors
> is that Fortran uses the actual origin, where PL/I uses the virtual
> origin. VMS descriptors include both.

When creating either a CLASS_A or CLASS_NCA descriptor, you need to provide
addresses since you don't know how the called routine will use it. Pascal
generates code that sometimes uses the actual origin or sometimes the
virtual origin depending on datatypes.

>
> (PL/I passed both the lower and upper bound for array dimensions,
> where Fortran only passes the upper bound.)
>

Uh, I don't think that is true. Fortran uses CLASS_A which includes lower and upper bounds. CLASS_A has a size field vs CLASS_NCA has a stride field to handle alignment holes. Or are you talking for strings? Pascal uses CLASS_A/CLASS_NCA for string arguments (eventhough the lower would always be 1) unless you override with an explicit CLASS_S attribute where the size is essentially the upper bound.

[glen herrmannsfeldt]

John Reagan <xyzz...@gmail.com> wrote:

(snip, I wrote)

The way that assumed shape (pass by descriptor works) the called
routine uses an origin of 1. That is convenient in that the
called routine doesn't have to keep track of the lower and upper
bounds in all its loops, and even more that you can easily mix
arrays with different upper/lower values but the same extent.

That is why I say it uses the actual origin. Take each subscript,
subtract one, multiply by a scale factor, add, and add the actual
origin. If upper and lower bounds are passed, use upper-lower+1.

The PL/I way of passing and using both lower and upper bounds
seems more logical, but not always convenient. Multiply each
subscript by a scale factor, add, and add virtual origin.
(The PL/I (F) compiler has the restriction that the virtual origin
has to be between -(2**24)-1 and +2**24-1, with 24 bit addreses.)

-- glen

[David Froble]

Bill Gunshannon wrote:
> In article <346eb384-6ca2-4691...@googlegroups.com>,
> John Reagan <xyzz...@gmail.com> writes:
>> On Wednesday, February 25, 2015 at 4:21:38 PM UTC-5, David Froble wrote:
>>> John Reagan wrote:
>>>> Thanks for the input. Just out of curiosity, how many lines?
>>> Not sure what you're asking. New lines, or total. Last I heard, we had
>>> well over a million lines of code in the Codis application.
>>>
>> That's what I want to see. People keep wanting to tell me that BASIC and Pascal are fringe languages. I keep saying there are lots of real (and large) applications, but I want real data points. Another customer contacted me via email today with a Pascal application just shy of 1 million lines.
>
> There are hundreds of millions if not billions of lines of COBOL code
> out in the world. And places are doing new development in it everyday.
> And yet it is still considered "fringe" and schools refuse to continue
> to teach it even going so far as to tell students that even learning
> COBOL will be dettrimental to their career opportunities.
>
> Would you expect Pascal and especially BASIC (which has had a bad rep
> since its earliest days!!) to fare any better?
>
> bill
>

I have no idea who would be giving it a bad rap. At least people from
DEC environments.

Basic was the #1 language on your beloved RSTS/E. I doubt many coming
from that environment would bad mouth Basic.

But if there is a bunch of idiots out there that want to talk about
something they most likely don't know anything about, what do I care, as
long as John takes care of Basic?

As for your beloved schools, I seem to remember a bit of wisdom. "Those
who can, do, and those who can't (attempt to) teach."

[David Froble]

:-( :-( :-(

Someone stole my rant ....

But yeah, most of that ..

[David Froble]

Stephen Hoffman wrote:
> On 2015-02-26 02:25:38 +0000, John Reagan said:

>> So basically (pardon the pun), it is dealing with nul-terminated
>> strings from non-C languages?

Actually, that's not so hard to pass a null terminated string. But if
it gets changed, I do believe there will be a problem.

For example:

Z$ = "Hi there" + Chr$(0%)
Call Something( Z$ By Value )

Anyway, I think that works, if the data is to be read only.

In the calling program, there is still the string descriptor with a
pointer to the data, and a length of the data. The called program won't
know anything about the descriptor. That could get very ugly.

[David Froble]

JF Mezei wrote:
> On 15-02-25 18:38, Neil Rieck wrote:
>

>> 2) BASIC needs support for unsigned integers
>

> What sort of usage would require unsigned int in BASIC ?

What if I'm setting up a structure as a descriptor? There is Byte,
Word, and Longword pieces of the descriptor, and they are usually unsigned.

> With 64 bit values, do you really need that 1 extra bit ?

Usually not.

> Do people do bit shifting in BASIC ?
>

Sometimes ...

[David Froble]

Is this an "it won't work" or just "we're not going to bother to test
and validate" ?

Just curious.

[li...@openmailbox.org]

On Fri, 27 Feb 2015 01:45:42 -0500
David Froble via Info-vax <info...@rbnsn.com> wrote:

> But if there is a bunch of idiots out there that want to talk about
> something they most likely don't know anything about, what do I care, as
> long as John takes care of Basic?

At the beginning BASIC and PASCAL were academic languages and were not
useful for general programming much less serious commercial applications.
Most people are simply not aware there have been a small number of really
good implementations that significantly upgraded these languages from their
former teaching status and are now on a par feature for feature with other
mainstream commercial languages.

[Bill Gunshannon]

In article <mcp3ek$u6i$1...@dont-email.me>,

David Froble <da...@tsoft-inc.com> writes:
> Bill Gunshannon wrote:
>> In article <346eb384-6ca2-4691...@googlegroups.com>,
>> John Reagan <xyzz...@gmail.com> writes:
>>> On Wednesday, February 25, 2015 at 4:21:38 PM UTC-5, David Froble wrote:
>>>> John Reagan wrote:
>>>>> Thanks for the input. Just out of curiosity, how many lines?
>>>> Not sure what you're asking. New lines, or total. Last I heard, we had
>>>> well over a million lines of code in the Codis application.
>>>>
>>> That's what I want to see. People keep wanting to tell me that BASIC and Pascal are fringe languages. I keep saying there are lots of real (and large) applications, but I want real data points. Another customer contacted me via email today with a Pascal application just shy of 1 million lines.
>>
>> There are hundreds of millions if not billions of lines of COBOL code
>> out in the world. And places are doing new development in it everyday.
>> And yet it is still considered "fringe" and schools refuse to continue
>> to teach it even going so far as to tell students that even learning
>> COBOL will be dettrimental to their career opportunities.
>>
>> Would you expect Pascal and especially BASIC (which has had a bad rep
>> since its earliest days!!) to fare any better?
>>
>> bill
>>
>
> I have no idea who would be giving it a bad rap.

Seriously?? You reall do need to get out more.

"It is practically impossible to teach good programming to students
that have had a prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration." -- Edsger
W. Dijkstra, 1975

> At least people from
> DEC environments.

I was talking about BASIC in general. DEC Basic has always been one of
the rare exceptions. ANSI BASIC may have tried to fix the original bad
rep, but it was too MS ingrained to accomplish that.

>
> Basic was the #1 language on your beloved RSTS/E. I doubt many coming
> from that environment would bad mouth Basic.

I certainly don't. But I was talking about the overall image in the IT world,
98% of whom have never heard of, much less used, any version of DEC BASIC.

>
> But if there is a bunch of idiots out there that want to talk about
> something they most likely don't know anything about, what do I care, as
> long as John takes care of Basic?

Well, I believe the earlier comments were about making languages (BASIC and
Pascal included) compliant with more current standards. While that might
help some languages it wold be a very large step backwards in the case of
DEC BASIC.

>
> As for your beloved schools, I seem to remember a bit of wisdom. "Those
> who can, do, and those who can't (attempt to) teach."

Don't tar me with that brush. I am a firm believer that one should not
be allowed to become a college professor until they have real world
experience. And that applies to every field. But especially to the
Computing Sciences where it is way to common to goi:
BS->MS->PHD->Professorship.

I didn't enter academia until I was almost 40.

[Bill Gunshannon]

In article <54ef7e18$0$57912$c3e8da3$c8b7...@news.astraweb.com>,

As, probably, the biggest Unix advocate here :-), I disagree. VMS
should look and work like VMS and unix should look and work like
unix. Trying to merge the userinterfaces won;t work and will cause
numerous support problems in the long run. Trust me, when we (the
University, not my particular department) were a primarily VMS shop
and unix started to appear, this was attempted using stuff in people's
LOGIN.COM. It cre4ated a nightmare. And when my department became
the last standout running VMS systems as well as our unix systems I
never di that and none of my faculty or students ever complained.

[Kerry Main]

Do you mean like a big ISP which supports over 4M Cust's and their
primary language is Basic/RMS files? Huge A-A OpenVMS very mission
critical cluster.

They do new functionality deployments approx. twice per month.

Regards,

Kerry Main
Back to the Future IT Inc.
.. Learning from the past to plan the future

Kerry dot main at backtothefutureit dot com

[JF Mezei]

On 15-02-27 09:35, Kerry Main wrote:

> Do you mean like a big ISP which supports over 4M Cust's and their
> primary language is Basic/RMS files? Huge A-A OpenVMS very mission
> critical cluster.

You mean that red cable company based in Toronto. Remember seeing VT220
terminals in their stores in early 1990s back when their wireless
service was called Cantel. But I have not seen any indication they
would still use VMS today.

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of JF
> Mezei
> Sent: 27-Feb-15 4:06 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>

Wrong company .. need to think about this with your cowboy hat on.

:-)

[David Froble]

John Reagan wrote:
> On Wednesday, February 25, 2015 at 6:38:15 PM UTC-5, Neil Rieck wrote:
>
>> This news will make some people in my shop very happy. I know you probably aren't soliciting for suggestions but here are my two:
>>
>> 1) BASIC needs a "/NAMES" compile time switch like most other so-called DEC languages

>>
>> 2) BASIC needs support for unsigned integers
>>
>

> I'm always soliciting suggestions. Happy customers are paying customers. :)
>
> I'll add them to my list.
>

Ok, a couple of things. Bill Judy got tired of doing things manually
and wrote a utility to answer such questions.

Here is the line-counts...

**********************************************************
**********************************************************
Files Grand Total = 1,747
Lines Grand Total = 1,554,820
Chars Grand Total = 49,326,648

------ Biggest line counts ------
IM6201 Lines = 15,831 Chars = 592,095
ORDENT_ORDER Lines = 15,829 Chars = 554,339
SA1000 Lines = 15,180 Chars = 515,981
CUSCON Lines = 14,403 Chars = 493,675
OE3900 Lines = 11,175 Chars = 359,141
------ Biggest char counts ------
IM6201 Lines = 15,831 Chars = 592,095
ORDENT_ORDER Lines = 15,829 Chars = 554,339
SA1000 Lines = 15,180 Chars = 515,981
CUSCON Lines = 14,403 Chars = 493,675
IM0601 Lines = 10,140 Chars = 370,011

**********************************************************
**********************************************************


Bill Judy
Consolidated Data, Inc

Also, I asked Bill what enhancements he'd like to see in Basic.

We have a subprogram to round a D-float number:

Call NRound( Z , 2% )

The second parameter is the number of fraction decimal places.

Every time it's called, there is subprogram frame set-up and break-down,
and it has proven to be significant. I'm aware that we can compile in a
manner to suppress that overhead. Regardless, Bill's request is for a
built in rounding function. Something like:

Z = FRound( Z , 2% )

I'm not sure what this would mean for anything other than D-Float ..

How would you handle that, rounding for all the available floating point
types? Different function names for each?

[JF Mezei]

On 15-02-27 17:58, Kerry Main wrote:

> Wrong company .. need to think about this with your cowboy hat on.

Ahh, the company currently arguming at the CRTC that its IT costs and
other costs have increased so much they have to increase wholesale
telecom costs by some 40%. Not quite a good image for VMS if it causes
a telecommunications company's costs to increase instead of decrease.

Then again, those companies have "creative accounting" departments
(officially labeled "regulatory costing") whose role is to inflate costs
submitted to the regulator :-)

[Jonathan]

>
> This news will make some people in my shop very happy. I know you probably aren't soliciting for suggestions but here are my two:
>
> 1) BASIC needs a "/NAMES" compile time switch like most other so-called DEC languages
>
> 2) BASIC needs support for unsigned integers
>

> Neil

I strongly second unsigned integers.

/NAMES would have been useful a couple of times in the past.

Jonathan

PS. At least 1 million lines of Basic. 3.8 million lines in the source tree, but some duplication.
PPS A thousand files modifications or creations in the past year,

[Jonathan]

On Thursday, February 26, 2015 at 12:15:28 AM UTC-5, JF Mezei wrote:
> On 15-02-25 18:38, Neil Rieck wrote:
>

> > 2) BASIC needs support for unsigned integers
>

> What sort of usage would require unsigned int in BASIC ?

Unsigned arithmetic without overflow.
Descriptor lengths, address arithmetic

>
> With 64 bit values, do you really need that 1 extra bit ?

No with 16 bits I need that extra bit. :) for calling non-basic code.

>
> Do people do bit shifting in BASIC ?

Yup. Bit maps. Flag words. etc.

Jonathan

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of JF
> Mezei
> Sent: 27-Feb-15 7:07 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>

The VMS costs are the least of this companies issues. VMS is a stable,
rock solid platform (8 node cluster) that quietly sits in the back,
handles the huge IO loads, and pays the bills in an ultra-reliable manner.

In addition, the App groups keep cranking out new features to meet
their rapidly changing business requirements.

Nothing wrong with this image at all. All IT shops should be so lucky
as to not have to worry about 10-40+ monthly security patches or
regular reboots (crtl-alt-reboot stuff).

[Neil Rieck]

Hmm... A company headquartered in the western provinces perhaps :-)

Neil

[Neil Rieck]

While I am not a big fan of DEC-BASIC, it was chosen for us by corporate IS/IT back in the VAX days and now there is a ton of source code still running in various systems. Now to be fair, DEC-BASIC is the most powerful BASIC I have ever seen. It seems to have borrowed stuff from FORTRAN (the MAT functions spring to mind) while the ability to directly support ISAM files, and deal with DECIMAL datatypes appears to have been borrowed from COBOL.

IIRC, the decision to make ISAM standard on VMS (it was optional on RSX-11 and RT-11) was because this was a requirement for COBOL.

http://h71000.www7.hp.com/openvms/30th/t_past_text.html#1980

Anyway, I have been told numerous times by DEC employees that DEC-BASIC was very popular with the insurance industry. (must have been for data-extraction or report generation because I always assumed that COBOL dominated that industry)

[Stephen Hoffman]

On 2015-02-28 02:19:30 +0000, Kerry Main said:

> All IT shops should be so lucky as to not have to worry about 10-40+
> monthly security patches orregular reboots (crtl-alt-reboot stuff).

"Please, in the name of everyone’s sanity, just don’t play the
vulnerability counting game. It doesn't do anyone any good." --
<https://plus.google.com/+JustinSchuh/posts/CNEgtJWYTb5>

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman
> Sent: 28-Feb-15 10:18 AM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>

On one hand I agree the specific individual numbers are not that
much of interest, but the scale is at the very heart of very disturbing
trends over the last number of years.

Scenario 1 -
When OPS groups have hundreds / thousands of OS instances to
manage WW and they have a few (lets pick less than 10) security
patches per year, then that Is likely considered acceptable.

Scenario 2 -
When OPS groups have hundreds / thousands of OS instances to
manage WW and have 10-40+ security patches PER MONTH, then
what happens is a breakdown in best IT practices. This is the current
state with many med-large companies (ask Sony about this).

OPS groups simply do not have the time and they cannot get the Biz's
Support for App testing resources to test so many security patches
every single month.

Rather than properly test these security patches against important
Apps, what has happened is the adoption of patch-n-pray practices.

Now, if there had not been such a significant increase in the OS
instances, the monthly security patches might have been more
manageable, but the culture of 1 or 2 bus apps per OS instance that
was established in the distributed days of commodity OS's (and
significantly boosted by the likes of VMware) has resulted in the
OPS groups throwing up their hands and have adopted
patch-n-pray.

Imho, patch-n-pray cultures and associated issues has been at the
heart of many very public outages and security breaches.

Imho, commodity OS customers will soon begin to realize that
there is a cost to the adoption of any platform with a history of
many security patches per month combined with supporting VM
sprawl that has spun out of control.

Again - look under the covers at Sony and other well known, very
visible outages and you will likely find an over whelmed OPS group
struggling to keep up with the tsunami of monthly security patches.

[Kerry Main]

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

> Stephen Hoffman
> Sent: 28-Feb-15 10:18 AM

> To: info...@info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>

Open source security vs proprietary?

This article has a huge hole in that he does not address the third
security model i.e. closed / proprietary, but with state-of-the-art
high end security firms hired to review / test / find security holes on
a regular basis using the latest means they have at their disposal.

This is the model used by banks who regularly do this to test their
security. They do not publish the plans for their alarms/ vaults on
the Internet and ask people for review.

It does not mean that things will not be missed, but it does give Custs
very high confidence that the bank is doing as much as it can to provide
them with a very secure environment.

[Stephen Hoffman]

On 2015-02-28 15:57:39 +0000, Kerry Main said:

>>
>> -----Original Message-----
>>
>> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
>>
>> Stephen Hoffman
>>
>> Sent: 28-Feb-15 10:18 AM
>>
>> To: info...@info-vax.com
>>
>> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>>
>>
>>
>> On 2015-02-28 02:19:30 +0000, Kerry Main said:
>>
>>
>>
>>> All IT shops should be so lucky as to not have to worry about 10-40+
>>>
>>> monthly security patches orregular reboots (crtl-alt-reboot stuff).
>>>
>>
>>
>> "Please, in the name of everyone’s sanity, just don’t play the
>>
>> vulnerability counting game. It doesn't do anyone any good." --
>>
>> <https://plus.google.com/+JustinSchuh/posts/CNEgtJWYTb5>
>>
>>
>>
>> --
>>
>> Pure Personal Opinion | HoffmanLabs LLC
>>
>>
>>
>
>
> On one hand I agree the specific individual numbers are not that
>
> much of interest, but the scale is at the very heart of very disturbing
>
> trends over the last number of years.

Sure; as computers become smaller and cheaper and more common, the
older policies and practices become less economical, and newer attacks
and newer defenses continue to evolve.

> Scenario 1 -
>
> When OPS groups have hundreds / thousands of OS instances to
>
> manage WW and they have a few (lets pick less than 10) security
>
> patches per year, then that Is likely considered acceptable.
>
>
>
> Scenario 2 -
>
> When OPS groups have hundreds / thousands of OS instances to
>
> manage WW and have 10-40+ security patches PER MONTH, then
>
> what happens is a breakdown in best IT practices. This is the current
>
> state with many med-large companies (ask Sony about this).

Ayup. But you're going to need a much better alternative to the
current mess. VMS is not that better alternative; not for the
near-term, and quite possibly for the foreseeable future.

As Sony and others have realized, phishing and social engineering is a
knotty problem. DEC VMS Engineering was quite effectively phished,
some years ago. That led to a whole lot of work, and a number of
changes to policies and procedures. This all atop the usual
protocol-level and server-level attacks that are common, and are only
increasing.

> OPS groups simply do not have the time and they cannot get the Biz's
>
> Support for App testing resources to test so many security patches
>
> every single month.

Welcome to assuming that your own internal network is pwnd, as more
than a few organizations know, or are realizing. Best to assume the
internal networks are breached, and work from there.

> Rather than properly test these security patches against important
>
> Apps, what has happened is the adoption of patch-n-pray practices.

Which has been happening in many places, as budgets get thinner and
deployments faster.

> Now, if there had not been such a significant increase in the OS
>
> instances, the monthly security patches might have been more
>
> manageable, but the culture of 1 or 2 bus apps per OS instance that
>
> was established in the distributed days of commodity OS's (and
>
> significantly boosted by the likes of VMware) has resulted in the
>
> OPS groups throwing up their hands and have adopted
>
> patch-n-pray.

Not having patches and not having updates concerns me as much — if not
more — than having patches to apply. VMS just is not that secure.
Which implies it's not being targeted, and folks are sitting on
SMG-style vulnerabilities. That in addition to the unencrypted storage
transports, weak password hashes, etc.

> Imho, patch-n-pray cultures and associated issues has been at the
>
> heart of many very public outages and security breaches.

Attackers need but one vulnerability or one successful phish.
Defenders have to deal with everything, and everything is evolving, and
specializing.

> Imho, commodity OS customers will soon begin to realize that
>
> there is a cost to the adoption of any platform with a history of
>
> many security patches per month combined with supporting VM
>
> sprawl that has spun out of control.

As much as I'd like to see that, that's doubtful. Not until there's a
massively better way. Maybe seL4 is on that path? Maybe VSI can
overhaul and upgrade VMS to provide that — but that's a tremendous
amount of work, and VMS has not seen the sorts of attacks that Windows
sees and that OS X and Linux are increasingly encountering. Which
means VSI and the third-party VMS developers have yet to see those
attacks and to learn some of the associated lessons.

> Again - look under the covers at Sony and other well known, very
>
> visible outages and you will likely find an over whelmed OPS group
>
> struggling to keep up with the tsunami of monthly security patches.

Per reports, Sony got phished. Phish the person with the Active
Directory or Open Directory LDAP keys, and VMS (with external
authentication configured) is just as breached.

If VSI succeeds with VMS and starts to grow the installed base, then
you will see increasing numbers of patches as the existing
vulnerabilities are explored and exercised and remediated, and as more
secure versions and updates are deployed. But if you're running any
infrastructure of interest to attackers and you're still thinking "no
patches is good", then your networks and your servers are probably
already toast.

Telling folks that the current approach is not without problems, and
that we're on a treadmill of patches and of VM sprawl? That's known
and widely acknowledged, and it's an unfortunate cost of IT. Better
solutions are far more interesting to folks. VMS isn't a solution to
any of this, though. Not by a long shot. Whether VSI can eventually
address any of this mess?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax...@info-vax.com] On Behalf Of
> Stephen Hoffman
> Sent: 28-Feb-15 12:46 PM
> To: info...@info-vax.com
> Subject: Re: [New Info-vax] New VSI Roadmap (yipee!)
>

[snip...]

>
> If VSI succeeds with VMS and starts to grow the installed base, then
> you will see increasing numbers of patches as the existing
> vulnerabilities are explored and exercised and remediated, and as more
> secure versions and updates are deployed. But if you're running any
> infrastructure of interest to attackers and you're still thinking "no
> patches is good", then your networks and your servers are probably
> already toast.
>

This is an old wives tale whereby the platform with issues tries to smear
everyone else with the same mud so as not to make their issues seem
as bad as they are.

A similar analogy would be to compare banks and corner stores. Using
this same thinking, the only reason corner stores (liquor stores?) have
more breakins and robberies than banks is because there are more
corner stores than banks.

Core architecture and support culture have a lot to do with it as well.

I agree OpenVMS has been neglected by its previous owners and there
Is lots of additional work to be done to raise the bar to the level where
OpenVMS stds used to be in the forefront.

Having stated this, as you know, OpenVMS is used in many Lotteries,
Banks, Stock Exchanges, Financial clearing houses, Manufacturing and
many other high profile environments that would be considered huge
successes for the hackers of the day.

If there really were this "stock pile" of known OpenVMS security issues
then we would have heard about this as it would be headline news i.e.
some high profile company had been hacked.

> Telling folks that the current approach is not without problems, and
> that we're on a treadmill of patches and of VM sprawl? That's known
> and widely acknowledged, and it's an unfortunate cost of IT. Better
> solutions are far more interesting to folks. VMS isn't a solution to
> any of this, though. Not by a long shot. Whether VSI can eventually
> address any of this mess?

No one here is saying OpenVMS does not have to add features which
other platforms have or that certain existing features do not need to
be upgraded or that there are no security issues lurking in OpenVMS.

Having stated this, stating OpenVMS security is a mess when there
are no successful recent hack attempts in the press is just not correct.

When hacks are successful, they make it known as it is a huge bragging
right that is part of hacking culture. OpenVMS is still a very secure, very
stable environment that hackers have avoided because imho, there
are far easier commodity OS targets to go after ..

And just to repeat .. yes, just like banks, there is always enhancement
work to be done.

[Stephen Hoffman]

On 2015-02-28 19:22:36 +0000, Kerry Main said:

> OpenVMS is still a very secure, very
>
> stable environment that hackers have avoided because imho, there
>
> are far easier commodity OS targets to go after ..
>

The bulk of the attackers haven't (openly) targeted VMS because —
unless you're aiming at a very specific target that's running VMS — VMS
effectively doesn't exist in the IT market. Until there are enough
VMS boxes to become a botnet or until there's a sufficiently valuable
bug bounty program, there's little incentive for most attackers to look
for vulnerabilities, much less to expose any previously-unknown
vulnerabilities; to burn zero-days.

For known vulnerabilities in VMS, OpenSSL is down-revision and upstream
support for OpenSSL 0.9.8 ends this year, Apache is very old, SMH "has
issues", and there are other areas of concern. Not the least of which
includes the unencrypted cluster data storage transport available to
anyone with a privileged network position. But what else lurks akin
to that SMG buffer-handling bug that somebody found and leaked a while
back, who knows?

But I suspect we will continue to disagree here. So rather than
showing me yet more bug counts, show me a better solution. Show me
something that'll run my apps. That's cheaper and/or more efficient
than my current and often-patched solution, and with a migration path
that I can afford. Then I'll care. Without application support and
various other factors that VSI will undoubtedly be targeting, VMS
doesn't even enter into this discussion.

I'm skeptical that the bug-of-the-month club can be avoided on anything
as complex and as a feature-competitive operating system in widespread
use, and skeptical around whether folks really even look at the counts
or merely expect that as a cost of doing IT. OpenBSD
<http://www.openbsd.org> claims only two remote exploits in the base
install "in a heck of a long time", though has certainly had its share
of security bugs in various components over the years. seL4
<https://sel4.systems> claims "end-to-end proof of implementation and
security enforcement".

But like VMS on an x86-64 NUC server box or even VMS on a ProLiant box,
until there's a solution that runs my applications — cost-efficiently —
few folks outside the VMS installed base will be particularly
interested. That includes the folks that target and that make money
from exploiting security vulnerabilities, of course.

[Craig A. Berry]

On 2/28/15 2:38 PM, Stephen Hoffman wrote:
>
> For known vulnerabilities in VMS, OpenSSL is down-revision and upstream
> support for OpenSSL 0.9.8 ends this year, Apache is very old,

Luckily both of those are on the roadmap as getting updates in Q4 2015.

[JF Mezei]

On 15-02-28 15:38, Stephen Hoffman wrote:

> The bulk of the attackers haven't (openly) targeted VMS because —

The biggest danger right is are not hackers in the open, but rather the
5-eyes that include NSA, GCHQ, CSEc. (CSEC recently removed the last
C (Canada) as part of the plan to give it the powers to act outside of
Canada).

Consider Gemalto, one of the largest makers of SIM cards. 5-eyes hacked
into their systems and downloaded a huge database of the SIM card data,
whichl included encryption keys WITHOUT ANYONE NOTICING.

The only reason we know of this is due to leaks by Mr Snowden.


So when the level of sophistication and power by those agencies includes
intercepting router deliveries to "update" the firmware to allow that
agency to remotely manage the router and intercept traffic, or steal
whole datbases without anyone noticing, then it is a far greater problem
because it is no longer just a PR image problem as suffered by Sony but
a real problem.

Theoretically, any/all wireless carriers who have distributed Gemalto
SIM cards should be issuing new SIMs to all of their customers due to
this breach.

I recently received a phishing email that was adressed to me with full
name, last 4 digits of credit card, valid expiry date (and of course my
email address). It was (fake) from Netflix and asked that I access
netflix to update my account information. As I do not display HTML I saw
the real URL and knew it was fake.

This indicates some on-line store I have done business with in the last
few years had has a breach of their database. The criminals didn't get
my full credit card number otherwise they wouldn't have been asking me
to access their web site to give them my full credit card. BTW, Netflix
took this more seriously than the bank who simply cancelled my credit
card , re-issued a new one and didn't ask I send them a copy of email).

This is where VMS could mame a compelling offering: make store "engines"
run on a separate VMS instance from the web server to make it very
hard/mpossible for hackers to access the database if they compromise the
web server.

[David Froble]

You're going to make Kerry unhappy ........

You're both right, today's practices are poor to downright bad.

Look at the anti-virus programs. They may check for known problems, but
otherwise they just let things go through. Perhaps this is the real
problem.

Now, I'm not saying the following would work. But it's what I've been
thinking about.

Instead of letting communications happen unless a known problem is
found, perhaps what needs to happen, at least in some cases, is only
letting communications pass that are known and expected. Yeah, that
would be a lot of work, perhaps way too much. Sure wouldn't work for
Susie doing Facebook.

Maybe some type of communications manager that controls what traffic can
reach the computer. Actually knows what the communications are and what
they will be doing.

While I don't have what I'd consider an answer, I do feel that the way
things are done now just isn't ever going to work.