In article <tcbnab$1klpf$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 8/2/2022 11:03 AM, Dan Cross wrote:
>> This is certainly valid, but something that these analyses tend
>> to omit is the ongoing maintenance cost over time. There was a
>> time when Digital and VMS had a large enough commercial presence
>> that VMS skills were relatively common; that time has passed.
>> Finding and training people to maintain these systems starts to
>> dominate the cost calculations after a while. As a result, it
>> makes no sense to invest in _new_ VMS development; going forward
>> it will be almost entirely maintenance (whatever new development
>> happens will be in support of legacy applications).
>>
>> VMS's best chances for survival arguably lie in open sourcing
>> the system. VSI has given it a shot in the arm, but I don't
>> see how that's sustainable as maintenance costs rise.
>
>I choose to disagree.

Very well.

>First, OpenSource is a non-issue. If the OS is up to date, and working, what
>else is needed? It is obvious to me that nothing is really changed from the
>past. VMS wasn't OpenSource then either. If it is still working, then it has
>proven itself, something no other OS has done in the existing environment.

Again, it's about ongoing maintenance. With the current closed
solution, you are dependent on the financial interests of one
quite small company, to keep things going. That's a lot of risk
to accept for something that's mission critical.

While it's axiomatic that the existing solution, targeting the
current platform is in some sense "proven" in a way that even
that same application moved to another platform is not, there's
a flip side to that as well: the existing system is being moved
to a new hardware architecture and software platform, which has
not had the same level of vetting as the existing solution.
Sure, you're changing fewer variables at once, but consider that
when running in a virtualized context under some hypervisor, you
are also subject to bugs in that hypervisor, and emergent bugs
that show up due to the unique interaction with this (new) guest
operating system and the hypervisor. So whereas now you are
dependent on one OS, soon you will be dependent on two.

I don't particularly like Linux, but it is likely that more
cycles run on a Linux kernel in a minute than have run across
all installations of VMS ever.

>If the application(s) are currently in use, then perhaps there is already people
>available for maintenance.

Perhaps. But consider the curious case of the governor of
Illinois pleaing for help from "cobalt" [sic] programmers at the
stard of the pandemic because all of a sudden the state's
unemployment insurance system was overloaded by a massive
increase in claims volumes. The existence of those people
is not guaranteed, and moreover, people leave jobs over time:
they switch jobs, they retire, and they die. Sometimes they
go on vacation. Who replaces them? How quickly are they
trained?

>If not, people can be trained.

You'd better factor the recurring cost of that into your ongoing
expenses.

>Expecting to hire
>people with required explicit knowledge just doesn't happen. Some may know how
>to click on WEENDOZE, or Linux, or anything else, but they do not know the needs
>of the specific customer/user. The concept that there are knowledgeable people
>out there that can step right in is bogus.

Sure each job is different and has its unique quirks, but many
skills are more or less transferable. Besides, knowing the
basics of working with a system is already a step up from
knowing nothing and having to start with learning how to
navigata an unfamiliar system structure. Hey, at least VMS is
a lot nicer in this regard than a mainframe.

>As far as cost, you get what you paid for. Find a cheap hacker, and that's what
>you get.

Sure. But that's a false dichotomy.

>>> Case 3:
>>>
>>> Some WEENDOZE or Linux bigot is involved and declares the new system must
>>> correspond to the alleged bigotry.
>>
>> This is an odd way to put it; another might be that ongoing
>> maintenance costs are reduced by going with something that's so
>> widespread. Note, I wouldn't advocate for Windows/MSFT for the
>> same reasons I wouldn't advocate for VMS for new development: it
>> is just too proprietary.
>
>Proprietary has nothing to do with anything. If you need to have staff to
>support Linux, they are either expensive, or worthless, or both. Better to have
>VSI software support, and any problems are their problem, not yours.

This is simple economics. There are probably two orders of
magnitude more highly skilled Linux people in the world than
there are VMS people total. Not only is there a massive pool of
talent to choose from, because the supply side of that equation
is much larger, it's more economical.

VSI is, presently, a tiny organization relatively speaking. Do
they have the resources to support existing VMS customers in the
manner you suggest?

>Some people think OpenSource is the cat's meow. I think they are wrong.

Open source isn't about being "the cat's meow" nor is it some
ideological statement. It is an evolutionary characteristic
that works in favor of survivability over closed systems. It is
about durability of investment. Consider: if Linus Torvalds
gets hit by a bus tomorrow, does Linux disappear? Short answer,
no. On the other hand, if VSI goes under tomorrow, does VMS
disappear as a viable commercial system? Yes.

I suppose VSI has run the numbers (I don't think they are fools)
but it sure seems hard to reckon how they're going to build
their business beyond legacy customers. Maybe they expect that
they can pull an IBM and grow revenue in the same way the
mainframe business remains profitable.

- Dan C.

On 8/2/22 17:29, Dan Cross wrote:
> In article <tcbnab$1klpf$1@dont-email.me>,
> Dave Froble <davef@tsoft-inc.com> wrote:
>> On 8/2/2022 11:03 AM, Dan Cross wrote:
>>> This is certainly valid, but something that these analyses tend
>>> to omit is the ongoing maintenance cost over time. There was a
>>> time when Digital and VMS had a large enough commercial presence
>>> that VMS skills were relatively common; that time has passed.
>>> Finding and training people to maintain these systems starts to
>>> dominate the cost calculations after a while. As a result, it
>>> makes no sense to invest in _new_ VMS development; going forward
>>> it will be almost entirely maintenance (whatever new development
>>> happens will be in support of legacy applications).
>>>
>>> VMS's best chances for survival arguably lie in open sourcing
>>> the system. VSI has given it a shot in the arm, but I don't
>>> see how that's sustainable as maintenance costs rise.
>>
>> I choose to disagree.
>
> Very well.
>
>> First, OpenSource is a non-issue. If the OS is up to date, and working, what
>> else is needed? It is obvious to me that nothing is really changed from the
>> past. VMS wasn't OpenSource then either. If it is still working, then it has
>> proven itself, something no other OS has done in the existing environment.
>
> Again, it's about ongoing maintenance. With the current closed
> solution, you are dependent on the financial interests of one
> quite small company, to keep things going. That's a lot of risk
> to accept for something that's mission critical.
>
> While it's axiomatic that the existing solution, targeting the
> current platform is in some sense "proven" in a way that even
> that same application moved to another platform is not, there's
> a flip side to that as well: the existing system is being moved
> to a new hardware architecture and software platform, which has
> not had the same level of vetting as the existing solution.
> Sure, you're changing fewer variables at once, but consider that
> when running in a virtualized context under some hypervisor, you
> are also subject to bugs in that hypervisor, and emergent bugs
> that show up due to the unique interaction with this (new) guest
> operating system and the hypervisor. So whereas now you are
> dependent on one OS, soon you will be dependent on two.
>
> I don't particularly like Linux, but it is likely that more
> cycles run on a Linux kernel in a minute than have run across
> all installations of VMS ever.
>
>> If the application(s) are currently in use, then perhaps there is already people
>> available for maintenance.
>
> Perhaps. But consider the curious case of the governor of
> Illinois pleaing for help from "cobalt" [sic] programmers at the
> stard of the pandemic because all of a sudden the state's
> unemployment insurance system was overloaded by a massive
> increase in claims volumes. The existence of those people
> is not guaranteed, and moreover, people leave jobs over time:
> they switch jobs, they retire, and they die. Sometimes they
> go on vacation. Who replaces them? How quickly are they
> trained?

It was New Jersey and in the end it turned out to not have anything
to do with COBOL (or cobalt :-) or the backend mainframe. It was
a web server running on inadequate hardware.

bill

On 2022-08-02, Galen <no_email@invalid.invalid> wrote:
> Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> Can't be. He's grinded so much, the axe is totally gone.
>>
>
>
> Simon must be well into reducing the axe handle to so much sawdust. When he
> runs out of handle, will he start grinding down his hand?
> ?

No grinding, but Simon has opinions on a wide range of subjects and
doesn't mind expressing them. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <jktol4Fk3l7U1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 8/2/22 17:29, Dan Cross wrote:
>> Perhaps. But consider the curious case of the governor of
>> Illinois pleaing for help from "cobalt" [sic] programmers at the
>> stard of the pandemic because all of a sudden the state's
>> unemployment insurance system was overloaded by a massive
>> increase in claims volumes. The existence of those people
>> is not guaranteed, and moreover, people leave jobs over time:
>> they switch jobs, they retire, and they die. Sometimes they
>> go on vacation. Who replaces them? How quickly are they
>> trained?
>
>It was New Jersey

Ah, yes; I stand corrected.

>and in the end it turned out to not have anything
>to do with COBOL (or cobalt :-) or the backend mainframe. It was
>a web server running on inadequate hardware.

Which actually reinforces my thesis. The system was so opaque
to the maintainers that they couldn't see that until they got
someone in who knew enough to recognize the problem. That in
itself is a big problem.

- Dan C.

On 8/2/2022 7:00 PM, Bill Gunshannon wrote:
> On 8/2/22 17:29, Dan Cross wrote:
>> Perhaps.  But consider the curious case of the governor of
>> Illinois pleaing for help from "cobalt" [sic] programmers at the
>> stard of the pandemic because all of a sudden the state's
>> unemployment insurance system was overloaded by a massive
>> increase in claims volumes.  The existence of those people
>> is not guaranteed, and moreover, people leave jobs over time:
>> they switch jobs, they retire, and they die.  Sometimes they
>> go on vacation.  Who replaces them?  How quickly are they
>> trained?
>
> It was New Jersey and in the end it turned out to not have anything
> to do with COBOL (or cobalt  :-) or the backend mainframe.  It was
> a web server running on inadequate hardware.

Sure about that?

The observed problems was:
A) unemployment checks were many weeks late
B) people could not get into the web site to check status of their claim
C) many people ended up getting a wrong amount

The potential causes are:
1) lack of mainframe HW
2) lack of Cobol skills
3) lack of x86-64 HW
4) lack of Java skills (the frontend was supposedly JSF based)
5) lack of case handlers to perform manual steps

As far as I can see then #3 can only be a part explanation for #B.

Arne

abrsvc schrieb am 01.08.2022 um 18:32:
> On Monday, August 1, 2022 at 12:17:35 PM UTC-4, Bill Gunshannon wrote:
>> [...]
>>>
>> As an interesting side note....
>>
>> What happened to all those VAX we heard about as recently as
>> last year that were running production floors or being used
>> by government sites where things like certification prevent
>> moving to a more modern platform?
>>
>> I know they probably had/have non-expiring licenses but the
>> consensus now seems to be that the only VAX users are hobbyists.
>> Did all those production VAX just vanish overnight?
>>
>> bill
> Many are now running using emulators. I know of many that moved within the last year with more moves scheduled for the next year. All had (or will have) their licenses transferred via contact with HP Financial. VAX systems are still going (with real hardware too!!). I am aware of many still at V5.5-2, many at V6.2 and V7.3.
>
> Dan

When moving from physical hardware to an emulator, you don't need tpo
"transfer" the licenses. For this case, there are special "extension
licenses", one for the OS and one for (almost) all LPs, for both VAX and
Alpha.

Last time I checked, these extension licenses also were available from
HPE Financial (the "preowned equipment" group).

Hans.

On Monday, August 8, 2022 at 1:58:11 PM UTC-4, Hans Bachner wrote:
> abrsvc schrieb am 01.08.2022 um 18:32:
> > On Monday, August 1, 2022 at 12:17:35 PM UTC-4, Bill Gunshannon wrote:
> >> [...]
> >>>
> >> As an interesting side note....
> >>
> >> What happened to all those VAX we heard about as recently as
> >> last year that were running production floors or being used
> >> by government sites where things like certification prevent
> >> moving to a more modern platform?
> >>
> >> I know they probably had/have non-expiring licenses but the
> >> consensus now seems to be that the only VAX users are hobbyists.
> >> Did all those production VAX just vanish overnight?
> >>
> >> bill
> > Many are now running using emulators. I know of many that moved within the last year with more moves scheduled for the next year. All had (or will have) their licenses transferred via contact with HP Financial. VAX systems are still going (with real hardware too!!). I am aware of many still at V5.5-2, many at V6.2 and V7.3.
> >
> > Dan
> When moving from physical hardware to an emulator, you don't need tpo
> "transfer" the licenses. For this case, there are special "extension
> licenses", one for the OS and one for (almost) all LPs, for both VAX and
> Alpha.
>
> Last time I checked, these extension licenses also were available from
> HPE Financial (the "preowned equipment" group).
>
> Hans.
You are correct. for simplicity, we always reference these as a transfer which covers both options. In essence, the license is being transferred from real hardware to software. Conceptually similar.