On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
> On 7/1/22 16:38, Arne Vajhøj wrote:
>> On 7/1/2022 2:25 PM, Bill Gunshannon wrote:
>>> On 7/1/22 11:05, Arne Vajhøj wrote:
>>>> On 7/1/2022 8:14 AM, Dave Froble wrote:
>>>>> On 7/1/2022 4:30 AM, Andy Burns wrote:
>>>>>> Arne Vajhøj wrote:
>>>>>>> ensure that frontend/UI technology is modern, there are so much
>>>>>>> to choose from, I would suggest Grails
>>>>>>
>>>>>> I have no idea whether Grails is good or bad.  To my mind there
>>>>>> are too many of
>>>>>> these frameworks, it feels like a new one appears most days,
>>>>>> spreading
>>>>>> themselves too thinly.
>>>>>
>>>>> It is not so much the quantity of "new" that is occurring, as the
>>>>> contention of some that we all must embrace the "new", regardless
>>>>> of whether what exists is working well and is not broken.
>>>>
>>>> I don't think the claim is that you should embrace the new.
>>>
>>> Of course it is.  Just look at OOP.  COBOL users refused to accept it
>>> because it really offered nothing they needed to get the job done and
>>> added layers of unneeded complexity.  The result was a full force attack
>>> against COBOL that continues to this day.
>>
>> I don't think anyone is telling developers to embrace OOP.
>
> Of course they did.  Everything taught at University (at least on
> our side of the pond) went to OOP.  People, like the COBOL community,
> who refused to accept it became outcasts.  University's stopped
> teaching (or even discussing COBOL except to denigrate it).  Even
> CIS courses where COBOL was still the best fit dropped it.  I was
> there.  I saw it.  I fought it.  I still do.  But, alas, to no avail.
>
>> Modern software development is very much multi-paradigm. Procedural,
>> OOP, generic, FP and possibly with a tiny sprinkle of AOP. Developers
>> pick the tools they consider best for the task at hand.
>
> What non-OOP language is mainstream in Universities today?

I believe there are still places where they teach C. Either
for OS or for embedded.

But more important they are not teaching OO only languages. They
teach multi-paradigm languages that support OOP and other paradigms.

C++ was born with procedural, OO and generic support - plus some
rudimentary FP support that got expanded a lot in version 11.

Java was born with procedural and OO support - got generic support
in version 5 and FP support in version 8. No builtin AOP support,
but AspectJ provide both static weaving and dynamic weaving (the
latter via Spring DI).

C# was born with procedural and OO support - plus some
rudimentary FP support that got extended a lot in version 3.
Generic support was added in version 2.

PHP started procedural. Added OOP later (version 4.0?).
Added FP later (version 5.3). Genric does not make sense
in dynamic typed language.

Python started procedural and OO. Added FP later (not sure when).
Generic does not make sense in dynamic typed language.

JavaScript was born with procedural, OO and FP support.
Generic does not make sense in dynamic typed language.

Universities are not really pushing OOP. They are pushing
multi-paradigm.

And if comparing University usage to industry usage, then
I believe they are over-prioritizing FP and under-prioritizing OOP.

>> I know you think the reason why Cobol is not in demand is that
>> universities does not teach it and attack it. But demand rules.
>> If the companies wanted Cobol for the new application they
>> create, then it would be Cobol. But they don't.
>
> But they do.  Recent surveys have shown that not only is the number
> of lines of COBOL not decreasing it is increasing.  The only major
> COBOL IS I have seen go away went away not because of a desire to
> use another language but because the maintainer of the IS has been
> unable to find graduates who know or are willing to learn the
> language.  They don't know it because it isn't taught and they
> aren't willing to learn it because they had professors like some
> of ours who repeatedly told them even learning the language was
> detrimental to their futures.

You can always get people if you are willing to pay enough money.

"not being able to get people" really means "the stuff I am
doing generate less money than what other companies are doing
so the other companies get the people".

>>>> More like continuously evaluating whether new stuff has some
>>>> advantages over old stuff.
>>>
>>> Most of it does not.  It's the old risk/benefit argument.  Most of the
>>> changes foisted onto the IT world offered little if any needed benefit
>>> and brought a lot of risk that adversely affects business daily.
>>
>> If you look at the world, then I think you will see that companies
>> that are investing in new technologies thrive, while those that stick
>> to what just works fine as always dwindle.
>
> Most of the Fortune 500 still use mainframes and COBOL. Most major banks
> still use mainframes and COBOL.  Credit Card companies.  Airlines.  All
> of the major automobile companies.  All of the major Aircraft companies.
> The Government at all levels except maybe local who never made it past
> the PC.

There are a lot of Cobol code running. And there will continue to
be for decades.

But the new stuff are done with other languages.

And companies slowly migrate off. Not many, maybe just a few percent
per year. But it accumulate over many years.

Arne

On 7/1/2022 6:50 PM, Bill Gunshannon wrote:
> On 7/1/22 16:02, Arne Vajhøj wrote:
>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>> On 7/1/22 11:10, Arne Vajhøj wrote:
>>>> On 7/1/2022 10:52 AM, Dave Froble wrote:
>>>>> For some reason Arne, you seem to feel that that which isn't broken
>>>>> must regardless be fixed.  I just don't understand such.
>>>>>
>>>>> I do believe that I mentioned that the Codis application/ERP did
>>>>> what the users needed, is successfully running their businesses,
>>>>> and just about anything else would be a step down, not up.
>>>>
>>>> Progress is not about replacing things that are broken. Progress
>>>> is about replacing things that work with something that work better.
>>>>
>>>> Horse wagons did not stop working. But trains, cars and airplanes non
>>>> the less replaced them for transportation.
>>>>
>>>> Your Basic code running on PDP-11 did not stop working,
>>>
>>> Actually, it did.  But not because of the code but because someone
>>> decided to force the unneeded change by making the PDP-11 unobtanium!
>>>
>>>>                                                         but the
>>>> new shiny VMS VAX thing was just better.
>>>
>>> Was it?  My guess is that the only improvement that might have been
>>> needed for Dave's application was a faster processor.  And that was
>>> done even after the death of the PDP-11 in DEC's eyes.
>>
>> I don't think PDP-11 not being available was the driver behind the
>> move to VAX.
>
> Not lack of availability at first, but complete stoppage of development
> played a major role.

I am not PDP-11 knowledgeable but per wikipedia the last models
(93 and 94) was released in 1990 at the time when VAX was getting
close to retirement.

>> PDP-11 production continue until 1997 when people were migrating
>> from VAX to Alpha - not to VAX.
>
> How much development was done during that period?

Apparently some up to 1990. A decade after many did the move
to VAX.

> How many shrinks
> to increase speed?  How many new peripherals were made available?
> We didn't even get decent network cards or even disk controllers for
> things like SCSI except from third parties.  Trust me, people using
> PDP-11's could see the writing on the wall.

Both end customers, ISV's and DEC could see the writing on
the wall - 16 bit did not have a future.

Everybody (read: most) wanted first 32 bit and later 64 bit.

Arne

On 7/1/2022 8:56 PM, Arne Vajhøj wrote:
> On 7/1/2022 6:50 PM, Bill Gunshannon wrote:
>> On 7/1/22 16:02, Arne Vajhøj wrote:
>>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>>> On 7/1/22 11:10, Arne Vajhøj wrote:
>>>>> On 7/1/2022 10:52 AM, Dave Froble wrote:
>>>>>> For some reason Arne, you seem to feel that that which isn't broken must
>>>>>> regardless be fixed. I just don't understand such.
>>>>>>
>>>>>> I do believe that I mentioned that the Codis application/ERP did what the
>>>>>> users needed, is successfully running their businesses, and just about
>>>>>> anything else would be a step down, not up.
>>>>>
>>>>> Progress is not about replacing things that are broken. Progress
>>>>> is about replacing things that work with something that work better.
>>>>>
>>>>> Horse wagons did not stop working. But trains, cars and airplanes non
>>>>> the less replaced them for transportation.
>>>>>
>>>>> Your Basic code running on PDP-11 did not stop working,
>>>>
>>>> Actually, it did. But not because of the code but because someone
>>>> decided to force the unneeded change by making the PDP-11 unobtanium!
>>>>
>>>>> but the
>>>>> new shiny VMS VAX thing was just better.
>>>>
>>>> Was it? My guess is that the only improvement that might have been
>>>> needed for Dave's application was a faster processor. And that was
>>>> done even after the death of the PDP-11 in DEC's eyes.
>>>
>>> I don't think PDP-11 not being available was the driver behind the
>>> move to VAX.
>>
>> Not lack of availability at first, but complete stoppage of development
>> played a major role.
>
> I am not PDP-11 knowledgeable but per wikipedia the last models
> (93 and 94) was released in 1990 at the time when VAX was getting
> close to retirement.
>
>>> PDP-11 production continue until 1997 when people were migrating
>>> from VAX to Alpha - not to VAX.
>>
>> How much development was done during that period?
>
> Apparently some up to 1990. A decade after many did the move
> to VAX.
>
>> How many shrinks
>> to increase speed? How many new peripherals were made available?
>> We didn't even get decent network cards or even disk controllers for
>> things like SCSI except from third parties. Trust me, people using
>> PDP-11's could see the writing on the wall.
>
> Both end customers, ISV's and DEC could see the writing on
> the wall - 16 bit did not have a future.
>
> Everybody (read: most) wanted first 32 bit and later 64 bit.

More important was virtual addressing. As in VAX ...

The VAX was a good follow-on to the PDP-11.

PDP-11 did not have the addressing capabilities for more complex systems.
Getting rid of (hawk, spit, gag) TKB was the best ever.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2022-07-02 00:50, Bill Gunshannon wrote:
> On 7/1/22 16:02, Arne Vajhøj wrote:
>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>> Was it?  My guess is that the only improvement that might have been
>>> needed for Dave's application was a faster processor.  And that was
>>> done even after the death of the PDP-11 in DEC's eyes.
>>
>> I don't think PDP-11 not being available was the driver behind the
>> move to VAX.
>
> Not lack of availability at first, but complete stoppage of development
> played a major role.

There wasn't. Last release of RSX was in 1999.

>> PDP-11 production continue until 1997 when people were migrating
>> from VAX to Alpha - not to VAX.
>
> How much development was done during that period?  How many shrinks
> to increase speed?  How many new peripherals were made available?
> We didn't even get decent network cards or even disk controllers for
> things like SCSI except from third parties.  Trust me, people using
> PDP-11's could see the writing on the wall.

There wasn't much demand for speed increase. But DEC even did offer
their own SCSI controller (RQZX1), so it wasn't just third party. You
are drawing conclusions from incorrect data.

The biggest reason for migration from PDP-11 to VAX was because of the
larger virtual memory addressing space.

People really did not (in general) enjoy trying to squeeze ever larger
software systems into the tiny addressing space. It was a lot of effort
that could be spent elsewhere.

Johnny

On 2022-07-02 05:23, Dave Froble wrote:
> On 7/1/2022 8:56 PM, Arne Vajhøj wrote:
>> On 7/1/2022 6:50 PM, Bill Gunshannon wrote:
>>>                                                 How many shrinks
>>> to increase speed?  How many new peripherals were made available?
>>> We didn't even get decent network cards or even disk controllers for
>>> things like SCSI except from third parties.  Trust me, people using
>>> PDP-11's could see the writing on the wall.
>>
>> Both end customers, ISV's and DEC could see the writing on
>> the wall - 16 bit did not have a future.
>>
>> Everybody (read: most) wanted first 32 bit and later 64 bit.
>
> More important was virtual addressing.  As in VAX ...

Uh. You forgot the 'X' as in *extension*. It wasn't that the PDP-11
didn't have virtual addressing... But the space was smaller.

> The VAX was a good follow-on to the PDP-11.
>
> PDP-11 did not have the addressing capabilities for more complex
> systems. Getting rid of (hawk, spit, gag) TKB was the best ever.

Well, the "capability" missing was the amount of bits available.

And yes, TKB, while very clever, was slow, and you had to work a lot to
get a good end result. Work time that could be better spent elsewhere.

Johnny

On 7/1/22 20:41, Arne Vajhøj wrote:
> On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
>> On 7/1/22 16:38, Arne Vajhøj wrote:
>>> On 7/1/2022 2:25 PM, Bill Gunshannon wrote:
>>>> On 7/1/22 11:05, Arne Vajhøj wrote:
>>>>> On 7/1/2022 8:14 AM, Dave Froble wrote:
>>>>>> On 7/1/2022 4:30 AM, Andy Burns wrote:
>>>>>>> Arne Vajhøj wrote:
>>>>>>>> ensure that frontend/UI technology is modern, there are so much
>>>>>>>> to choose from, I would suggest Grails
>>>>>>>
>>>>>>> I have no idea whether Grails is good or bad.  To my mind there
>>>>>>> are too many of
>>>>>>> these frameworks, it feels like a new one appears most days,
>>>>>>> spreading
>>>>>>> themselves too thinly.
>>>>>>
>>>>>> It is not so much the quantity of "new" that is occurring, as the
>>>>>> contention of some that we all must embrace the "new", regardless
>>>>>> of whether what exists is working well and is not broken.
>>>>>
>>>>> I don't think the claim is that you should embrace the new.
>>>>
>>>> Of course it is.  Just look at OOP.  COBOL users refused to accept it
>>>> because it really offered nothing they needed to get the job done and
>>>> added layers of unneeded complexity.  The result was a full force
>>>> attack
>>>> against COBOL that continues to this day.
>>>
>>> I don't think anyone is telling developers to embrace OOP.
>>
>> Of course they did.  Everything taught at University (at least on
>> our side of the pond) went to OOP.  People, like the COBOL community,
>> who refused to accept it became outcasts.  University's stopped
>> teaching (or even discussing COBOL except to denigrate it).  Even
>> CIS courses where COBOL was still the best fit dropped it.  I was
>> there.  I saw it.  I fought it.  I still do.  But, alas, to no avail.
>>
>>> Modern software development is very much multi-paradigm. Procedural,
>>> OOP, generic, FP and possibly with a tiny sprinkle of AOP. Developers
>>> pick the tools they consider best for the task at hand.
>>
>> What non-OOP language is mainstream in Universities today?
>
> I believe there are still places where they teach C. Either
> for OS or for embedded.

Not so much teach as read in things like OS classes where they still
use Tannenbaum's text books.

>
> But more important they are not teaching OO only languages. They
> teach multi-paradigm languages that support OOP and other paradigms.

Primary teaching languages are still things like Java although Python
is moving up the food chain. And OOP is still the primary paradigm.
Unless your side of the pond is very different.

>
> C++ was born with procedural, OO and generic support - plus some
> rudimentary FP support that got expanded a lot in version 11.
>
> Java was born with procedural and OO support - got generic support
> in version 5 and FP support in version 8. No builtin AOP support,
> but AspectJ provide both static weaving and dynamic weaving (the
> latter via Spring DI).
>
> C# was born with procedural and OO support - plus some
> rudimentary FP support that got extended a lot in version 3.
> Generic support was added in version 2.
>
> PHP started procedural. Added OOP later (version 4.0?).
> Added FP later (version 5.3). Genric does not make sense
> in dynamic typed language.
>
> Python started procedural and OO. Added FP later (not sure when).
> Generic does not make sense in dynamic typed language.
>
> JavaScript was born with procedural, OO and FP support.
> Generic does not make sense in dynamic typed language.
>
> Universities are not really pushing OOP. They are pushing
> multi-paradigm.
>
> And if comparing University usage to industry usage, then
> I believe they are over-prioritizing FP and under-prioritizing OOP.
>

If industry is prioritizing OOP it is only because universities pushed
them that way. Much like Unix and VMS. VMS was pushed out of academia
and Unix rose to the place of honor. And we all know ow that stands
today.

>>> I know you think the reason why Cobol is not in demand is that
>>> universities does not teach it and attack it. But demand rules.
>>> If the companies wanted Cobol for the new application they
>>> create, then it would be Cobol. But they don't.
>>
>> But they do.  Recent surveys have shown that not only is the number
>> of lines of COBOL not decreasing it is increasing.  The only major
>> COBOL IS I have seen go away went away not because of a desire to
>> use another language but because the maintainer of the IS has been
>> unable to find graduates who know or are willing to learn the
>> language.  They don't know it because it isn't taught and they
>> aren't willing to learn it because they had professors like some
>> of ours who repeatedly told them even learning the language was
>> detrimental to their futures.
>
> You can always get people if you are willing to pay enough money.

Businesses don't work that way. At some point the bean counters decide
the cut and run as was the case in the very large IS I know of. By the
way, the new replacement is not working out well but there is no going
back.

>
> "not being able to get people" really means "the stuff I am
> doing generate less money than what other companies are doing
> so the other companies get the people".

Not always. When one has spent four years (and a lot of money) being
indoctrinated into despising one particular option the result will be
very obvious. Sadly universities have more influence than some people
think (again, look at Unix vs. pretty much all other OSes other than MS)
and are more interested in driving the bus where they will rather than
getting the passengers to the place they need to be.

>
>>>>> More like continuously evaluating whether new stuff has some
>>>>> advantages over old stuff.
>>>>
>>>> Most of it does not.  It's the old risk/benefit argument.  Most of the
>>>> changes foisted onto the IT world offered little if any needed benefit
>>>> and brought a lot of risk that adversely affects business daily.
>>>
>>> If you look at the world, then I think you will see that companies
>>> that are investing in new technologies thrive, while those that stick
>>> to what just works fine as always dwindle.
>>
>> Most of the Fortune 500 still use mainframes and COBOL. Most major banks
>> still use mainframes and COBOL.  Credit Card companies.  Airlines.  All
>> of the major automobile companies.  All of the major Aircraft companies.
>> The Government at all levels except maybe local who never made it past
>> the PC.
>
> There are a lot of Cobol code running. And there will continue to
> be for decades.
> > But the new stuff are done with other languages.

Recent surveys say otherwise. When you look at percentages ot languages
used COBOL seems to be on the decline. But if you classify work by its
actual value, well, Candy Crush wasn't written in COBOL and neither was
Minecraft. But when it comes to banking, insurance and other really
needed application....

>
> And companies slowly migrate off. Not many, maybe just a few percent
> per year. But it accumulate over many years.

Very few of the important ones are migrating off and many of those
that do migrate into failures.

And, once again, this is something I would have thought the VMS
community was very familiar with.

bill

On 7/1/22 20:56, Arne Vajhøj wrote:
> On 7/1/2022 6:50 PM, Bill Gunshannon wrote:
>> On 7/1/22 16:02, Arne Vajhøj wrote:
>>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>>> On 7/1/22 11:10, Arne Vajhøj wrote:
>>>>> On 7/1/2022 10:52 AM, Dave Froble wrote:
>>>>>> For some reason Arne, you seem to feel that that which isn't
>>>>>> broken must regardless be fixed.  I just don't understand such.
>>>>>>
>>>>>> I do believe that I mentioned that the Codis application/ERP did
>>>>>> what the users needed, is successfully running their businesses,
>>>>>> and just about anything else would be a step down, not up.
>>>>>
>>>>> Progress is not about replacing things that are broken. Progress
>>>>> is about replacing things that work with something that work better.
>>>>>
>>>>> Horse wagons did not stop working. But trains, cars and airplanes non
>>>>> the less replaced them for transportation.
>>>>>
>>>>> Your Basic code running on PDP-11 did not stop working,
>>>>
>>>> Actually, it did.  But not because of the code but because someone
>>>> decided to force the unneeded change by making the PDP-11 unobtanium!
>>>>
>>>>>                                                         but the
>>>>> new shiny VMS VAX thing was just better.
>>>>
>>>> Was it?  My guess is that the only improvement that might have been
>>>> needed for Dave's application was a faster processor.  And that was
>>>> done even after the death of the PDP-11 in DEC's eyes.
>>>
>>> I don't think PDP-11 not being available was the driver behind the
>>> move to VAX.
>>
>> Not lack of availability at first, but complete stoppage of development
>> played a major role.
>
> I am not PDP-11 knowledgeable but per wikipedia the last models
> (93 and 94) was released in 1990 at the time when VAX was getting
> close to retirement.

And Mentec introduced at least one improved PDP-11 CPU but none of
them had any real new technology. Just minor clock speed ups. Not
what you were seeing in other processors where shrinks were resulting
in large speed ups.

>
>>> PDP-11 production continue until 1997 when people were migrating
>>> from VAX to Alpha - not to VAX.
>>
>> How much development was done during that period?
>
> Apparently some up to 1990. A decade after many did the move
> to VAX.

Not really development. Just the same thing warmed over.

>
>>                                                 How many shrinks
>> to increase speed?  How many new peripherals were made available?
>> We didn't even get decent network cards or even disk controllers for
>> things like SCSI except from third parties.  Trust me, people using
>> PDP-11's could see the writing on the wall.
>
> Both end customers, ISV's and DEC could see the writing on
> the wall - 16 bit did not have a future.

And when they same customers saw the same for 32 bit? Did Intel
throw out the X-86 architecture or make it fit the 64 bit world?
Granted, Intel almost missed the boat and might have if AMD hadn't
come along. Why could there not be a 32 bit PDP-11? Why did they
need a totally new and totally incompatible processor?

>
> Everybody (read: most) wanted first 32 bit and later 64 bit.
>

And I still don't see what part of the PDP-11 basic architecture
made them not be extensible to that. The PDP-11 architecture was
by far one of the best I have worked with and my experience goes
all the way back to the 8080 and 6800.

bill

On 7/2/22 06:16, Johnny Billquist wrote:
> On 2022-07-02 00:50, Bill Gunshannon wrote:
>> On 7/1/22 16:02, Arne Vajhøj wrote:
>>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>>> Was it?  My guess is that the only improvement that might have been
>>>> needed for Dave's application was a faster processor.  And that was
>>>> done even after the death of the PDP-11 in DEC's eyes.
>>>
>>> I don't think PDP-11 not being available was the driver behind the
>>> move to VAX.
>>
>> Not lack of availability at first, but complete stoppage of development
>> played a major role.
>
> There wasn't. Last release of RSX was in 1999.

That's OS development, not CPU. BSD for the PDP-11 continues to
develop today as far as I know.

>
>>> PDP-11 production continue until 1997 when people were migrating
>>> from VAX to Alpha - not to VAX.
>>
>> How much development was done during that period?  How many shrinks
>> to increase speed?  How many new peripherals were made available?
>> We didn't even get decent network cards or even disk controllers for
>> things like SCSI except from third parties.  Trust me, people using
>> PDP-11's could see the writing on the wall.
>
> There wasn't much demand for speed increase.

I don't think there was ever demand for speed increases in any CPU.
But users were always happy to see it.

> But DEC even did offer
> their own SCSI controller (RQZX1), so it wasn't just third party. You
> are drawing conclusions from incorrect data.

Was that SCSI developed for the PDP-11 or the MicroVAX and just
happened to work on the PDP-11? Why did they never release a DSSI
card for the PDP-11? (Actually, I am sure the VAX module would have
worked but I am not aware of any support for it in a PDP-11 OS.)

>
> The biggest reason for migration from PDP-11 to VAX was because of the
> larger virtual memory addressing space.

Which could have been developed into the PDP-11 while keeping most of
the good things in the architecture. I still think it would be fun to
use something like SIMH to build an "improved" PDP-11 just to see where
it could have gone but, alas, I am too far past my prime to actually
do it.

>
> People really did not (in general) enjoy trying to squeeze ever larger
> software systems into the tiny addressing space. It was a lot of effort
> that could be spent elsewhere.

Thus the reason the processor should have seen more development and not
a complete and totally incompatible replacement.

But, at this point that is all water under the bridge.

bill

On Thursday, June 30, 2022 at 9:58:17 AM UTC-4, Arne Vajhøj wrote:
> On 6/29/2022 10:01 PM, Dave Froble wrote:

> > VSI is currently supporting VMS, and porting it to x86 ...
> > VSI is currently (I hope John) supporting Basic ...
> > The auditing firm is a bunch of crooks ...
> There are some reasons for concerns:
> - niche OS (VMS)
> - niche language (VMS Basic)
> - obsolete language (Macro-32)
> - probably non-optimal persistence technology (RMS index-sequential
> files aka NoSQL Key Value Store)
> - the team getting close to retirement
>
> But it is not an urgent problem:
> - all the software is supported and can be expected to be
> supported for many years
> - the team has not retired yet
>
> What you need is a roadmap showing a long term viable future.
>
OpenVMS has other niche languages as well. Our Pascal full of extensions (many
from the Extended Pascal standard but available nowhere else so they might as well
be considered vendor-specific). Some vendors have attempted to convert Pascal to
C but it looks ugly (IMHO).

Yes Dave, BASIC is still on the schedule. As mentioned, BASIC exposed a missing piece
of the G2L design and the solution is complex. While my model has been "don't touch the
frontends and make G2L look just like GEM", the best way out might involve changes to the
BASIC frontend.

I would never recommend BASIC inside the OS. It is too heavily dependent on its RTL to
implement certain language features. I suppose you could limit the set of features to allow
but that would be a big investment to isolate all of those. However, there are not enough
additional language features to make it a benefit.

There was a study decades about about using Pascal inside of OpenVMS much like how
EPASCAL is used inside of VAXELN. Pascal lost even though it had much more type
safety. Although a distant project for a "virtual VAX" was written in VAX Pascal. They weren't
happy to find out VAX Pascal used the HALT instruction to signal run-time errors.

As for retirement, I have no short term plans to retire. What would I do? Just sit around all
day on comp.os.vms and complain? ;)

And I did send in my DNA to 23AndMe so my DNA has been sequenced and is on a computer
somewhere. All you need is to wait for the human 3d printer to be developed. I've also looked
into putting my head in a jar https://futurama.fandom.com/wiki/Heads_in_Jars

On 7/2/2022 10:08 AM, John Reagan wrote:
> On Thursday, June 30, 2022 at 9:58:17 AM UTC-4, Arne Vajhøj wrote:
>> On 6/29/2022 10:01 PM, Dave Froble wrote:
>
>>> VSI is currently supporting VMS, and porting it to x86 ...
>>> VSI is currently (I hope John) supporting Basic ...
>>> The auditing firm is a bunch of crooks ...
>> There are some reasons for concerns:
>> - niche OS (VMS)
>> - niche language (VMS Basic)
>> - obsolete language (Macro-32)
>> - probably non-optimal persistence technology (RMS index-sequential
>> files aka NoSQL Key Value Store)
>> - the team getting close to retirement
>>
>> But it is not an urgent problem:
>> - all the software is supported and can be expected to be
>> supported for many years
>> - the team has not retired yet
>>
>> What you need is a roadmap showing a long term viable future.
>
> OpenVMS has other niche languages as well. Our Pascal full of extensions (many
> from the Extended Pascal standard but available nowhere else so they might as well
> be considered vendor-specific). Some vendors have attempted to convert Pascal to
> C but it looks ugly (IMHO).

Yes.

But neither VMS Basic nor VMS Pascal are difficult languages to learn.

Not the normal curly bracket style, but to pick a random combo - someone
that know C, Java and PHP should be able to learn those languages
relative quickly.

> As for retirement, I have no short term plans to retire. What would I do? Just sit around all
> day on comp.os.vms and complain? ;)
>
> And I did send in my DNA to 23AndMe so my DNA has been sequenced and is on a computer
> somewhere.

:-)

But relevant question: have you trained new people in the VMS compilers?

Arne

On 7/2/2022 10:08 AM, John Reagan wrote:
> On Thursday, June 30, 2022 at 9:58:17 AM UTC-4, Arne Vajhøj wrote:
>> On 6/29/2022 10:01 PM, Dave Froble wrote:
>
>>> VSI is currently supporting VMS, and porting it to x86 ...
>>> VSI is currently (I hope John) supporting Basic ...
>>> The auditing firm is a bunch of crooks ...
>> There are some reasons for concerns:
>> - niche OS (VMS)
>> - niche language (VMS Basic)
>> - obsolete language (Macro-32)
>> - probably non-optimal persistence technology (RMS index-sequential
>> files aka NoSQL Key Value Store)
>> - the team getting close to retirement
>>
>> But it is not an urgent problem:
>> - all the software is supported and can be expected to be
>> supported for many years
>> - the team has not retired yet
>>
>> What you need is a roadmap showing a long term viable future.
>>
> OpenVMS has other niche languages as well. Our Pascal full of extensions (many
> from the Extended Pascal standard but available nowhere else so they might as well
> be considered vendor-specific). Some vendors have attempted to convert Pascal to
> C but it looks ugly (IMHO).
>
> Yes Dave, BASIC is still on the schedule. As mentioned, BASIC exposed a missing piece
> of the G2L design and the solution is complex. While my model has been "don't touch the
> frontends and make G2L look just like GEM", the best way out might involve changes to the
> BASIC frontend.

Thank you. Not sure what it would entail to "touch the front end", but
sometimes doing forbidden things can actually be helpful.

> I would never recommend BASIC inside the OS. It is too heavily dependent on its RTL to
> implement certain language features. I suppose you could limit the set of features to allow
> but that would be a big investment to isolate all of those. However, there are not enough
> additional language features to make it a benefit.

It is a jack of all trades, and does that well.

> There was a study decades about about using Pascal inside of OpenVMS much like how
> EPASCAL is used inside of VAXELN. Pascal lost even though it had much more type
> safety. Although a distant project for a "virtual VAX" was written in VAX Pascal. They weren't
> happy to find out VAX Pascal used the HALT instruction to signal run-time errors.
>
> As for retirement, I have no short term plans to retire. What would I do? Just sit around all
> day on comp.os.vms and complain? ;)

John takes a vicious shot at Dave ...

> And I did send in my DNA to 23AndMe so my DNA has been sequenced and is on a computer
> somewhere. All you need is to wait for the human 3d printer to be developed. I've also looked
> into putting my head in a jar https://futurama.fandom.com/wiki/Heads_in_Jars
>

It is not your potential that matters, it's what you've done, what you are ..

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/2/2022 8:34 AM, Bill Gunshannon wrote:
> On 7/1/22 20:56, Arne Vajhøj wrote:
>> On 7/1/2022 6:50 PM, Bill Gunshannon wrote:
>>>                                                 How many shrinks
>>> to increase speed?  How many new peripherals were made available?
>>> We didn't even get decent network cards or even disk controllers for
>>> things like SCSI except from third parties.  Trust me, people using
>>> PDP-11's could see the writing on the wall.
>>
>> Both end customers, ISV's and DEC could see the writing on
>> the wall - 16 bit did not have a future.
>
> And when they same customers saw the same for 32 bit?  Did Intel
> throw out the X-86 architecture  or make it fit the 64 bit world?
> Granted, Intel almost missed the boat and might have if AMD hadn't
> come along.  Why could there not be a 32 bit PDP-11?  Why did they
> need a totally new and totally incompatible processor?

I don't think "totally incompatible" is an accurate description.

The VAX 7x0 had PDP-11 compatibility mode.

But overall yes: Intel and Microsoft did a far better job
than DEC at the 16->32->64 bit migration.

>> Everybody (read: most) wanted first 32 bit and later 64 bit.
>
> And I still don't see what part of the PDP-11 basic architecture
> made them not be extensible to that.  The PDP-11 architecture was
> by far one of the best I have worked with and my experience goes
> all the way back to the 8080 and 6800.

You can't really extend from X bit to Y bit. You can create
a CPU with X and Y modes and an OS that supports both X and Y modes
in a more or less elegant way.

Arne

On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
> On 7/1/22 20:41, Arne Vajhøj wrote:
>> On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
>>> On 7/1/22 16:38, Arne Vajhøj wrote:
>>>> On 7/1/2022 2:25 PM, Bill Gunshannon wrote:
>>>>> On 7/1/22 11:05, Arne Vajhøj wrote:
>>>>>> On 7/1/2022 8:14 AM, Dave Froble wrote:
>>>>>>> It is not so much the quantity of "new" that is occurring, as the
>>>>>>> contention of some that we all must embrace the "new", regardless
>>>>>>> of whether what exists is working well and is not broken.
>>>>>>
>>>>>> I don't think the claim is that you should embrace the new.
>>>>>
>>>>> Of course it is.  Just look at OOP.  COBOL users refused to accept it
>>>>> because it really offered nothing they needed to get the job done and
>>>>> added layers of unneeded complexity.  The result was a full force
>>>>> attack
>>>>> against COBOL that continues to this day.
>>>>
>>>> I don't think anyone is telling developers to embrace OOP.
>>>
>>> Of course they did.  Everything taught at University (at least on
>>> our side of the pond) went to OOP.  People, like the COBOL community,
>>> who refused to accept it became outcasts.  University's stopped
>>> teaching (or even discussing COBOL except to denigrate it).  Even
>>> CIS courses where COBOL was still the best fit dropped it.  I was
>>> there.  I saw it.  I fought it.  I still do.  But, alas, to no avail.
>>>
>>>> Modern software development is very much multi-paradigm. Procedural,
>>>> OOP, generic, FP and possibly with a tiny sprinkle of AOP. Developers
>>>> pick the tools they consider best for the task at hand.
>>>
>>> What non-OOP language is mainstream in Universities today?
>>
>> I believe there are still places where they teach C. Either
>> for OS or for embedded.
>
> Not so much teach as read in things like OS classes where they still
> use Tannenbaum's text books.
>
>> But more important they are not teaching OO only languages. They
>> teach multi-paradigm languages that support OOP and other paradigms.
>
> Primary teaching languages are still things like Java although Python
> is moving up the food chain.  And OOP is still the primary paradigm.
> Unless your side of the pond is very different.

I don't see that at either side of the pond.

Java today is multiparadigm.

>> Java was born with procedural and OO support - got generic support
>> in version 5 and FP support in version 8. No builtin AOP support,
>> but AspectJ provide both static weaving and dynamic weaving (the
>> latter via Spring DI).

If you took 100 Java applications either written or updated in
recent time (last 8 years), then I would expect to see:

100 using OOP
100 using generic
50 using FP
25 using procedural
10 using AOP

>> Universities are not really pushing OOP. They are pushing
>> multi-paradigm.
>>
>> And if comparing University usage to industry usage, then
>> I believe they are over-prioritizing FP and under-prioritizing OOP.
>
> If industry is prioritizing OOP it is only because universities pushed
> them that way.  Much like Unix and VMS.  VMS was pushed out of academia
> and Unix rose to the place of honor.  And we all know ow that stands
> today.

No. Universities push multi-paradigm with a slight overweight on FP.

>>>> I know you think the reason why Cobol is not in demand is that
>>>> universities does not teach it and attack it. But demand rules.
>>>> If the companies wanted Cobol for the new application they
>>>> create, then it would be Cobol. But they don't.
>>>
>>> But they do.  Recent surveys have shown that not only is the number
>>> of lines of COBOL not decreasing it is increasing.  The only major
>>> COBOL IS I have seen go away went away not because of a desire to
>>> use another language but because the maintainer of the IS has been
>>> unable to find graduates who know or are willing to learn the
>>> language.  They don't know it because it isn't taught and they
>>> aren't willing to learn it because they had professors like some
>>> of ours who repeatedly told them even learning the language was
>>> detrimental to their futures.
>>
>> You can always get people if you are willing to pay enough money.
>
> Businesses don't work that way.

Of course they do that is how a market economy works.

There is a supply and a demand - and price is determined from that.

If price goes up the supply increases and demand decreases.

Adam Smith's invisible hand.

>> "not being able to get people" really means "the stuff I am
>> doing generate less money than what other companies are doing
>> so the other companies get the people".
>
> Not always.  When one has spent four years (and a lot of money) being
> indoctrinated into despising one particular option the result will be
> very obvious.

Money matters.

There are other languages that has never been popular at universities
but the industry has been able to find people anyway.

VB6, VBS and VB.NET are good examples. Universities never liked Basic.
Typical did not like MS either. Those languages was practically never
taught - and I am sure Dijkstra was quoted quite a bit. But the industry
was able to hire millions of developers for those technologies anyway.
Students learned C++/Delphi/Java/C# and they got a good job offer
doing one of those and they accepted.

>>>>>> More like continuously evaluating whether new stuff has some
>>>>>> advantages over old stuff.
>>>>>
>>>>> Most of it does not.  It's the old risk/benefit argument.  Most of the
>>>>> changes foisted onto the IT world offered little if any needed benefit
>>>>> and brought a lot of risk that adversely affects business daily.
>>>>
>>>> If you look at the world, then I think you will see that companies
>>>> that are investing in new technologies thrive, while those that stick
>>>> to what just works fine as always dwindle.
>>>
>>> Most of the Fortune 500 still use mainframes and COBOL. Most major banks
>>> still use mainframes and COBOL.  Credit Card companies.  Airlines.  All
>>> of the major automobile companies.  All of the major Aircraft companies.
>>> The Government at all levels except maybe local who never made it past
>>> the PC.
>>
>> There are a lot of Cobol code running. And there will continue to
>> be for decades.
>> But the new stuff are done with other languages.
>
> Recent surveys say otherwise.

Really.

Usually Cobol surveys prefer to discuss the size of the code base
not how much is being added.

>   When you look at percentages ot languages
> used COBOL seems to be on the decline.  But if you classify work by its
> actual value, well, Candy Crush wasn't written in COBOL and neither was
> Minecraft.  But when it comes to banking, insurance and other really
> needed application....

Cobol is becoming a pretty small part of what the financial sector use.

They prefer C++, Java, Python etc. for new projects.

>> And companies slowly migrate off. Not many, maybe just a few percent
>> per year. But it accumulate over many years.
>
> Very few of the important ones are migrating off and many of those
> that do migrate into failures.

Some succeed.

And it accumulates.

> And, once again, this is something I would have thought the VMS
> community was very familiar with.

Hmmm.

Question: how many VMS systems was around in 1992 and how many VMS
systems are around today?

Seems like a lot of companies managed to migrate.

Arne

On 2022-07-02, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> And Mentec introduced at least one improved PDP-11 CPU but none of
> them had any real new technology. Just minor clock speed ups. Not
> what you were seeing in other processors where shrinks were resulting
> in large speed ups.
>

It has been argued that the spirit of the PDP-11 lives on in the MSP-430...

Simon.

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

On 2022-07-02 14:46, Bill Gunshannon wrote:
> On 7/2/22 06:16, Johnny Billquist wrote:
>> On 2022-07-02 00:50, Bill Gunshannon wrote:
>>> On 7/1/22 16:02, Arne Vajhøj wrote:
>>>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>>>> Was it?  My guess is that the only improvement that might have been
>>>>> needed for Dave's application was a faster processor.  And that was
>>>>> done even after the death of the PDP-11 in DEC's eyes.
>>>>
>>>> I don't think PDP-11 not being available was the driver behind the
>>>> move to VAX.
>>>
>>> Not lack of availability at first, but complete stoppage of development
>>> played a major role.
>>
>> There wasn't. Last release of RSX was in 1999.
>
> That's OS development, not CPU.  BSD for the PDP-11 continues to
> develop today as far as I know.

You said "complete stoppage of development". Now you say you only meant
hardware. And actually just CPU development.
There wasn't any actual CPU development after about 1980. Way earlier.
The last expansion was CIS, which noone ever actually even cared about.

Move to VAX happened primarily because of address space limitations on
the PDP-11.

On the other hand, DEC never managed to successfully migrate customers
away from the PDP-11 even through they tried. The PDP-11 was simply just
better for some tasks.
So I don't really get what you are trying to claim.

>>>> PDP-11 production continue until 1997 when people were migrating
>>>> from VAX to Alpha - not to VAX.
>>>
>>> How much development was done during that period?  How many shrinks
>>> to increase speed?  How many new peripherals were made available?
>>> We didn't even get decent network cards or even disk controllers for
>>> things like SCSI except from third parties.  Trust me, people using
>>> PDP-11's could see the writing on the wall.
>>
>> There wasn't much demand for speed increase.
>
> I don't think there was ever demand for speed increases in any CPU.
> But users were always happy to see it.

There was definitely a demand for faster PDP-11s up to a point. But
somewhere along the way, it became a non-issue as the effort in
developing ever larger software solutions on the PDP-11 became a huge
effort in just fitting it into the address space. And so large, complex
software development moved away from the PDP-11 to the successor - VAX.
But the PDP-11 didn't die because of that. It just became a little more
limited in what customers used it for, and for that, the speed was
already acceptable. As was the other parameters.
The one thing asked for later in life was improvements in tools and
networking, and reduction of price.

Demand for faster CPUs exists also today. But we've sortof hit a wall
for single CPU speeds, so now we're mainly adding more and more cores.

>>                                               But DEC even did offer
>> their own SCSI controller (RQZX1), so it wasn't just third party. You
>> are drawing conclusions from incorrect data.
>
> Was that SCSI developed for the PDP-11 or the MicroVAX and just
> happened to work on the PDP-11?  Why did they never release a DSSI
> card for the PDP-11? (Actually, I am sure the VAX module would have
> worked but I am not aware of any support for it in a PDP-11 OS.)

The controller was for Qbus, and talked the same MSCP as any other Qbus
MSCP controller, so it was as viable for any system.
DEC certainly added support in the PDP-11 systems for the device, but of
course they also added it to VMS.

As far as DSSI goes, it's a bit more complicated, but basically, there
was one DSSI controller that worked just fine on PDP-11s. I don't
remember the name of it right now, but there was one Qbus controller
that spoke MSCP. So, worked just as well as any other MSCP controller.

However, with DSSI you also had controllers that talked SCA, over which
then MSCP was used. But SCA was a different protocol with some added
complexity which DEC never added drivers for in the PDP-11. Reasons
might have been several, but I would say the main one is that unless you
created new boot roms, and did some major work on the OSes at that
point, you would not have been able to boot from those controllers
anyway, so what would be the value? And I suspect it would have been
pretty much impossible to write a boot strap rom that would have booted
over SCA in just 64 bytes, which is the size available for the M9312
boot roms.

Again, memory space is the thing that comes back to bite you.

>> The biggest reason for migration from PDP-11 to VAX was because of the
>> larger virtual memory addressing space.
>
> Which could have been developed into the PDP-11 while keeping most of
> the good things in the architecture.  I still think it would be fun to
> use something like SIMH to build an "improved" PDP-11 just to see where
> it could have gone but, alas, I am too far past my prime to actually
> do it.

That is really what the VAX was. You would never be able to run actual
PDP-11 code on anything that had a larger address space. You need a
compatibility mode for this, just as on the x86 and god knows what else.
With the VAX, the compatibility mode was limited to user space code, but
doing a compatibility mode that worked all the way would have been
possible. But I don't think it would have been a good idea, since that
would have crippled the VAX.

As soon as you do some change to address space that is more directly
visible, it cease to be able to run a PDP-11 binary to begin with, so
you can't do it better than that. We've talked about this before, and
you seem to constantly fail to understand this.

You can't "expand" the PDP-11 to 32 bits and still have it be a PDP-11.
You can at best make something spiritually the same. But that is already
what the VAX was.

>> People really did not (in general) enjoy trying to squeeze ever larger
>> software systems into the tiny addressing space. It was a lot of
>> effort that could be spent elsewhere.
>
> Thus the reason the processor should have seen more development and not
> a complete and totally incompatible replacement.
>
> But, at this point that is all water under the bridge.

I just wished you had the technical understanding to see why what you
seem to imagine is not possible.

Johnny

On Monday, July 4, 2022 at 5:30:34 PM UTC-5, Johnny Billquist wrote:
....
> There was definitely a demand for faster PDP-11s up to a point. But
> somewhere along the way, it became a non-issue as the effort in
> developing ever larger software solutions on the PDP-11 became a huge
> effort in just fitting it into the address space. And so large, complex
> software development moved away from the PDP-11 to the successor - VAX.
> But the PDP-11 didn't die because of that. It just became a little more
> limited in what customers used it for, and for that, the speed was
> already acceptable. As was the other parameters.
> The one thing asked for later in life was improvements in tools and
> networking, and reduction of price.
>
> Demand for faster CPUs exists also today. But we've sortof hit a wall
> for single CPU speeds, so now we're mainly adding more and more cores.
>
> Johnny
....

It was clear to many of us doing real-time acquisition that the PDP-11 cpu and bus(es) had run their course as well. We looked at VAX offerings (rtVAX) and it was apparent our cost, OS (RT-32 anyone?) cpu/address and bus/device needs were not going to be satisfied. Most of the analysis code was in a semi-portable language, so that wasn't a limiting factor. We were prepared to rewrite the time or performance critical code to another system. The 68xxx series resembled the PDP-11 instruction approach in some ways and took a some share of this niche. Dedicated microcontrollers took the rest..

Jerry

On 7/1/2022 6:32 PM, Bill Gunshannon wrote:
> On 7/1/22 18:02, Chris Townley wrote:
>> On 01/07/2022 22:34, Dave Froble wrote:
>>> On 7/1/2022 12:54 PM, Scott Dorsey wrote:
>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?=  <arne@vajhoej.dk> wrote:
>>>>> On 7/1/2022 10:52 AM, Dave Froble wrote:
>>>>>> For some reason Arne, you seem to feel that that which isn't
>>>>>> broken must
>>>>>> regardless be fixed.  I just don't understand such.
>>>>>>
>>>>>> I do believe that I mentioned that the Codis application/ERP did what
>>>>>> the users needed, is successfully running their businesses, and just
>>>>>> about anything else would be a step down, not up.
>>>>>
>>>>> Progress is not about replacing things that are broken. Progress
>>>>> is about replacing things that work with something that work better.
>>>>
>>>> SAP seldom works better.
>>>
>>> If the goal is destroying the user, then SAP works very well ...
>>
>> SAP Relies on the business changing its business processes to match
>> SAP, where I imagine that most of us wrote software to fit around the
>> way the business worked.
>
> And that was the argument I have always presented for any talk of
> moving to a canned program.  As far back as the 80's when places
> like Radio Shack (back when they actually had Computer Stores and
> sold things like Xenix, COBOL, Fortran, Informix and other real
> computer systems) offered AR, AP, Payroll, GL, Inventory, etc.  You
> had to change your business model to the model built into their
> packages.   Fast forward a couple decades.  Banner knocks at the
> University's door and bingo here we go again.  Throw out all the
> in house written systems that were designed around how we did business
> and bring in Banner changing how we did business to how Banner
> perceived business.

SAP can be customized.

25 M$, 50 M$, 75 M$, ... - just say stop when you are out of money. :-)

But customers (at least the smart customers) want to limit
customization of SAP and similar products.

They understand why they are going with a standard package
instead of a custom application. They want all the features
available now and all the new features coming in the future
without paying 100% for them (share cost with the 100 or 1000
or 10000 or 100000 other customers).

If everything is customized then the current functionality
and the future enhancements becomes approx. as expensive as
a custom application.

If customization is kept minimal then there is a chance
that the business case for choosing a standard package
hold.

So potential customizations need to be carefully evaluated.
"We want X because our old system did X and before that
we did X using paper" is not worth it. "We want X because
it would be nice to have but doesn't really impact revenue
or cost" is not worth it. Only "We need X because otherwise
we will loose revenue and/or our cost will increase" is good.

Arne

On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
> On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
>> On 7/1/22 20:41, Arne Vajhøj wrote:
>>> On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
>>>> Most of the Fortune 500 still use mainframes and COBOL. Most major
>>>> banks
>>>> still use mainframes and COBOL.  Credit Card companies.  Airlines.  All
>>>> of the major automobile companies.  All of the major Aircraft
>>>> companies.
>>>> The Government at all levels except maybe local who never made it past
>>>> the PC.
>>>
>>> There are a lot of Cobol code running. And there will continue to
>>> be for decades.
>>> But the new stuff are done with other languages.

>>                              When you look at percentages ot languages
>> used COBOL seems to be on the decline.  But if you classify work by its
>> actual value, well, Candy Crush wasn't written in COBOL and neither was
>> Minecraft.  But when it comes to banking, insurance and other really
>> needed application....
>
> Cobol is becoming a pretty small part of what the financial sector use.
>
> They prefer C++, Java, Python etc. for new projects.
>
>>> And companies slowly migrate off. Not many, maybe just a few percent
>>> per year. But it accumulate over many years.
>>
>> Very few of the important ones are migrating off and many of those
>> that do migrate into failures.
>
> Some succeed.
>
> And it accumulates.

A recent case: Fedex.

They are moving from Cobol/IBM mainframe/own data center
to "cloud native"/Azure & Oracle cloud.

The CIO announced when this thread was going on that
they has already moved 80% of applications and that
the remaining 20% would all be done in 2024.

He did not mention what "cloud native" covers,
but elsewhere it is revealed to be:
- Angular for client side
- Java and Spring Boot for applications
- kubernetes and docker for infrastructure

Which is not really surprising. In the 1980's nobody got fired
for choosing IBM. Today nobody get fired (in a large conservative
company) for choosing above stack.

Arne

On 7/9/2022 7:42 PM, Arne Vajhøj wrote:
> Which is not really surprising. In the 1980's nobody got fired
> for choosing IBM. Today nobody get fired (in a large conservative
> company) for choosing above stack.

But some are more courageous.

Chase and Lloyds have announced that they will be
replacing their current custom retail banking systems with
a standard cloud based system Vault developed by a fintech
startup and (supposedly) written in Go and Python.

Arne

On 7/9/22 19:42, Arne Vajhøj wrote:
> On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
>> On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
>>> On 7/1/22 20:41, Arne Vajhøj wrote:
>>>> On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
>>>>> Most of the Fortune 500 still use mainframes and COBOL. Most major
>>>>> banks
>>>>> still use mainframes and COBOL.  Credit Card companies.  Airlines.
>>>>> All
>>>>> of the major automobile companies.  All of the major Aircraft
>>>>> companies.
>>>>> The Government at all levels except maybe local who never made it past
>>>>> the PC.
>>>>
>>>> There are a lot of Cobol code running. And there will continue to
>>>> be for decades.
>>>> But the new stuff are done with other languages.
>
>>>                              When you look at percentages ot languages
>>> used COBOL seems to be on the decline.  But if you classify work by its
>>> actual value, well, Candy Crush wasn't written in COBOL and neither was
>>> Minecraft.  But when it comes to banking, insurance and other really
>>> needed application....
>>
>> Cobol is becoming a pretty small part of what the financial sector use.
>>
>> They prefer C++, Java, Python etc. for new projects.
>>
>>>> And companies slowly migrate off. Not many, maybe just a few percent
>>>> per year. But it accumulate over many years.
>>>
>>> Very few of the important ones are migrating off and many of those
>>> that do migrate into failures.
>>
>> Some succeed.
>>
>> And it accumulates.
>
> A recent case: Fedex.
>
> They are moving from Cobol/IBM mainframe/own data center
> to "cloud native"/Azure & Oracle cloud.
>
> The CIO announced when this thread was going on that
> they has already moved 80% of applications and that
> the remaining 20% would all be done in 2024.
>
> He did not mention what "cloud native" covers,
> but elsewhere it is revealed to be:
> - Angular for client side
> - Java and Spring Boot for applications
> - kubernetes and docker for infrastructure
>
> Which is not really surprising. In the 1980's nobody got fired
> for choosing IBM. Today nobody get fired (in a large conservative
> company) for choosing above stack.
>

There has been some talk of this in Mainframe groups. Can't wait to see
how it turns out. Diehard VMS advocates should be very concerned. The
same logic applies to their systems.

bill

On 7/9/2022 8:25 PM, Bill Gunshannon wrote:
> On 7/9/22 19:42, Arne Vajhøj wrote:
>> On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
>>> On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
>>>> Very few of the important ones are migrating off and many of those
>>>> that do migrate into failures.
>>>
>>> Some succeed.
>>>
>>> And it accumulates.
>>
>> A recent case: Fedex.
>>
>> They are moving from Cobol/IBM mainframe/own data center
>> to "cloud native"/Azure & Oracle cloud.
>>
>> The CIO announced when this thread was going on that
>> they has already moved 80% of applications and that
>> the remaining 20% would all be done in 2024.
>>
>> He did not mention what "cloud native" covers,
>> but elsewhere it is revealed to be:
>> - Angular for client side
>> - Java and Spring Boot for applications
>> - kubernetes and docker for infrastructure
>>
>> Which is not really surprising. In the 1980's nobody got fired
>> for choosing IBM. Today nobody get fired (in a large conservative
>> company) for choosing above stack.
>
> There has been some talk of this in Mainframe groups.  Can't wait to see
> how it turns out.

With 80% completed and the last 20% in progress, then it
seems like a done thing.

The Chase projects would be interesting to see how pans out.

>   Diehard VMS advocates should be very concerned.  The
> same logic applies to their systems.

VMS is different.

VMS is moving to low cost hardware and standard cloud with VMS x86-64,
so that side is OK.

The problem is on the software side - VMS needs more. More open
source support and more ISV support.

Arne

On 7/9/2022 9:42 PM, Arne Vajhøj wrote:
> On 7/9/2022 8:25 PM, Bill Gunshannon wrote:
>> On 7/9/22 19:42, Arne Vajhøj wrote:
>>> On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
>>>> On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
>>>>> Very few of the important ones are migrating off and many of those
>>>>> that do migrate into failures.
>>>>
>>>> Some succeed.
>>>>
>>>> And it accumulates.
>>>
>>> A recent case: Fedex.
>>>
>>> They are moving from Cobol/IBM mainframe/own data center
>>> to "cloud native"/Azure & Oracle cloud.
>>>
>>> The CIO announced when this thread was going on that
>>> they has already moved 80% of applications and that
>>> the remaining 20% would all be done in 2024.
>>>
>>> He did not mention what "cloud native" covers,
>>> but elsewhere it is revealed to be:
>>> - Angular for client side
>>> - Java and Spring Boot for applications
>>> - kubernetes and docker for infrastructure
>>>
>>> Which is not really surprising. In the 1980's nobody got fired
>>> for choosing IBM. Today nobody get fired (in a large conservative
>>> company) for choosing above stack.
>>
>> There has been some talk of this in Mainframe groups. Can't wait to see
>> how it turns out.
>
> With 80% completed and the last 20% in progress, then it
> seems like a done thing.

We in the homebuilt aircraft have a saying.

90% done, 90% to go.

All too often it's true.

So I wonder, why isn't that last 20% also done? Perhaps it doesn't work so well
in the cloud. Or with the new languages. Or the new developers.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 7/9/2022 7:20 PM, Arne Vajhøj wrote:
> On 7/1/2022 6:32 PM, Bill Gunshannon wrote:
>> On 7/1/22 18:02, Chris Townley wrote:
>>> On 01/07/2022 22:34, Dave Froble wrote:
>>>> On 7/1/2022 12:54 PM, Scott Dorsey wrote:
>>>>> =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>>>>>> On 7/1/2022 10:52 AM, Dave Froble wrote:
>>>>>>> For some reason Arne, you seem to feel that that which isn't broken must
>>>>>>> regardless be fixed. I just don't understand such.
>>>>>>>
>>>>>>> I do believe that I mentioned that the Codis application/ERP did what
>>>>>>> the users needed, is successfully running their businesses, and just
>>>>>>> about anything else would be a step down, not up.
>>>>>>
>>>>>> Progress is not about replacing things that are broken. Progress
>>>>>> is about replacing things that work with something that work better.
>>>>>
>>>>> SAP seldom works better.
>>>>
>>>> If the goal is destroying the user, then SAP works very well ...
>>>
>>> SAP Relies on the business changing its business processes to match SAP,
>>> where I imagine that most of us wrote software to fit around the way the
>>> business worked.
>>
>> And that was the argument I have always presented for any talk of
>> moving to a canned program. As far back as the 80's when places
>> like Radio Shack (back when they actually had Computer Stores and
>> sold things like Xenix, COBOL, Fortran, Informix and other real
>> computer systems) offered AR, AP, Payroll, GL, Inventory, etc. You
>> had to change your business model to the model built into their
>> packages. Fast forward a couple decades. Banner knocks at the
>> University's door and bingo here we go again. Throw out all the
>> in house written systems that were designed around how we did business
>> and bring in Banner changing how we did business to how Banner
>> perceived business.
>
> SAP can be customized.
>
> 25 M$, 50 M$, 75 M$, ... - just say stop when you are out of money. :-)
>
> But customers (at least the smart customers) want to limit
> customization of SAP and similar products.
>
> They understand why they are going with a standard package
> instead of a custom application. They want all the features
> available now and all the new features coming in the future
> without paying 100% for them (share cost with the 100 or 1000
> or 10000 or 100000 other customers).
>
> If everything is customized then the current functionality
> and the future enhancements becomes approx. as expensive as
> a custom application.
>
> If customization is kept minimal then there is a chance
> that the business case for choosing a standard package
> hold.
>
> So potential customizations need to be carefully evaluated.
> "We want X because our old system did X and before that
> we did X using paper" is not worth it. "We want X because
> it would be nice to have but doesn't really impact revenue
> or cost" is not worth it. Only "We need X because otherwise
> we will loose revenue and/or our cost will increase" is good.
>
> Arne
>
>
>

Have to wonder if Arne ever ran a real business ...

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Arne Vajhøj
> via Info-vax
> Sent: July-09-22 8:43 PM
> To: info-vax@rbnsn.com
> Cc: Arne Vajhøj <arne@vajhoej.dk>
> Subject: Re: [Info-vax] For sale: VAXstation 4000/90 128MB Fully Working and
> Tested
>
> On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
> > On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
> >> On 7/1/22 20:41, Arne Vajhøj wrote:
> >>> On 7/1/2022 6:45 PM, Bill Gunshannon wrote:
> >>>> Most of the Fortune 500 still use mainframes and COBOL. Most major
> >>>> banks still use mainframes and COBOL. Credit Card companies.
> >>>> Airlines. All of the major automobile companies. All of the major
> >>>> Aircraft companies.
> >>>> The Government at all levels except maybe local who never made it
> >>>> past the PC.
> >>>
> >>> There are a lot of Cobol code running. And there will continue to be
> >>> for decades.
> >>> But the new stuff are done with other languages.
>
> >> When you look at percentages ot
> >> languages used COBOL seems to be on the decline. But if you classify
> >> work by its actual value, well, Candy Crush wasn't written in COBOL
> >> and neither was Minecraft. But when it comes to banking, insurance
> >> and other really needed application....
> >
> > Cobol is becoming a pretty small part of what the financial sector use.
> >
> > They prefer C++, Java, Python etc. for new projects.
> >
> >>> And companies slowly migrate off. Not many, maybe just a few percent
> >>> per year. But it accumulate over many years.
> >>
> >> Very few of the important ones are migrating off and many of those
> >> that do migrate into failures.
> >
> > Some succeed.
> >
> > And it accumulates.
>
> A recent case: Fedex.
>
> They are moving from Cobol/IBM mainframe/own data center to "cloud
> native"/Azure & Oracle cloud.
>
> The CIO announced when this thread was going on that they has already
> moved 80% of applications and that the remaining 20% would all be done in
> 2024.
>
> He did not mention what "cloud native" covers, but elsewhere it is revealed
> to be:
> - Angular for client side
> - Java and Spring Boot for applications
> - kubernetes and docker for infrastructure
>
> Which is not really surprising. In the 1980's nobody got fired for choosing IBM.
> Today nobody get fired (in a large conservative
> company) for choosing above stack.
>
> Arne
>

The case for App modernization as part of changing the companies business model from self-supporting to outsourcing (aka public cloud) has been around for 40+ years.

The justification usually means reducing the companies IT staff headcount (shows up as big benefit for the financial bottom line). It often provides short term benefits (read senior execs BOD get bonuses), but long term challenges (read execs making those decisions will be gone by then).

While decisions like this at the top of a company like this might make the senior execs look they are "forward thinking" to their shareholders and CEO, the reality is that "rip-and-replace" projects like this inevitably:

- cost much more (in some cases, astronomically) than originally budgeted when the full picture is evaluated
- take much longer than originally anticipated
- those making this original decision are usually never held accountable for those business model changes

Hence the "upgrade and integrate" strategies are becoming more common i.e. private or on-prem cloud with a small bit of public cloud (aka hybrid strategy).

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG.
https://www.avg.com

On 7/9/2022 9:50 PM, Dave Froble wrote:
> On 7/9/2022 9:42 PM, Arne Vajhøj wrote:
>> On 7/9/2022 8:25 PM, Bill Gunshannon wrote:
>>> On 7/9/22 19:42, Arne Vajhøj wrote:
>>>> On 7/3/2022 8:13 PM, Arne Vajhøj wrote:
>>>>> On 7/2/2022 8:26 AM, Bill Gunshannon wrote:
>>>>>> Very few of the important ones are migrating off and many of those
>>>>>> that do migrate into failures.
>>>>>
>>>>> Some succeed.
>>>>>
>>>>> And it accumulates.
>>>>
>>>> A recent case: Fedex.
>>>>
>>>> They are moving from Cobol/IBM mainframe/own data center
>>>> to "cloud native"/Azure & Oracle cloud.
>>>>
>>>> The CIO announced when this thread was going on that
>>>> they has already moved 80% of applications and that
>>>> the remaining 20% would all be done in 2024.
>>>>
>>>> He did not mention what "cloud native" covers,
>>>> but elsewhere it is revealed to be:
>>>> - Angular for client side
>>>> - Java and Spring Boot for applications
>>>> - kubernetes and docker for infrastructure
>>>>
>>>> Which is not really surprising. In the 1980's nobody got fired
>>>> for choosing IBM. Today nobody get fired (in a large conservative
>>>> company) for choosing above stack.
>>>
>>> There has been some talk of this in Mainframe groups.  Can't wait to see
>>> how it turns out.
>>
>> With 80% completed and the last 20% in progress, then it
>> seems like a done thing.
>
> We in the homebuilt aircraft have a saying.
>
> 90% done, 90% to go.
>
> All too often it's true.

There is a big difference between:
- 80% of the estimated work for porting an application
is done
and:
- 80% of applications migrated, the old servers
they run on is shutdown and hauled out and production
running in the new environment

Experience show that the first has a significant risk
of going over estimate.

But for the second what is running is running and
risk is reduced to the remaining stuff.

> So I wonder, why isn't that last 20% also done? Perhaps it doesn't work
> so well in the cloud. Or with the new languages. Or the new developers.

You don't start migrating everything in parallel.

You move chunks at a time.

Arne