On 6/30/2022 9:31 AM, Arne Vajhøj wrote:
> On 6/30/2022 9:02 AM, Bill Gunshannon wrote:
>> Should have used COBOL.  Then they could move to z/OS and DB2.
>> DB2 meet the relational database requirement.  And z/OS, well,
>> nobody ever got fired for going with IBM.   :-)
>
> VMS Cobol -> something else Cobol is undoubtetly easier than
> VMS Basic -> something else Basic.
>
> But people are moving off z/OS not on z/OS.
>
> And even though nobody got fired for choosing IBM
> 40 years ago, then the world is different today.
>
> Today the nobody get fired solution is more
> like Kubernetes and Linux in AWS/Azure/GCP.

And just like for 40 years ago it is sometimes
a good choice, often an OK choice and sometimes
a bad choice.

Arne

On 2022-06-30, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> Oh, and Dave, I thought you were the boss?
>:-)
>

$ set response/mode=good_natured

Actually, based on discussions here, David likes to _think_ he's
the boss (and always right). :-)

Simon.

PS: On a more serious note, enjoy your retirement David (and happy flying).

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

On 6/30/2022 9:02 AM, Bill Gunshannon wrote:
> On 6/29/22 22:01, Dave Froble wrote:
>> On 6/29/2022 3:36 PM, Arne Vajhøj wrote:
>>> On 6/29/2022 3:28 PM, Dave Froble wrote:
>>>> My days working with VMS, and computers in
>>>> general, seem to be coming to an end.
>>>
>>> What??
>>>
>>> We expect you to stick around for a few more decades!
>>>
>>> Arne
>>>
>>>
>>
>> Erik (the boss) is 80, I'm 76, Bill in early 70s, and Niel is late 60s, and
>> really want to retire.
>>
>> We made a pitch to the customers. Buy the software package, and we will give
>> you a year or whatever we can to train new people. They said they didn't want
>> to be in the software business. (Almost every business for the last 30-40
>> years has been in the software business, in some way.)
>>
>> Largest customer, now being run by original owner's children, had their
>> auditors come in, and were told:
>>
>> You can't use that ancient OS (VMS) ...
>> You can't continue with that ancient language (Basic) ...
>> You need a relational database ...
>> And a few more ridiculous claims ...
>> Above all, "you can't count on these old geezers" ...
>>
>> They refused to give them a successful audit ...
>>
>> Can't purchase business insurance without successful audit ...
>>
>> Then they pointed out a company with a cloud based solution for the customer
>> to talk to. Too bad they didn't mention that the company was a wholely owned
>> subsidiary of the auditing firm.
>>
>> :-)
>>
>> The app uses a single connection to the cloud. There is inadequate
>> throughput. It is slow. Every time the customer asks for a feature in Codis,
>> they are told that cannot be done. After several postponements, the customer
>> went live on the cloud solution. They are missing many features they counted
>> on. The system is inadequate. For example, (Bill likes to gather
>> statistics), max orders from Amazon have hit 100 per minute. The new system
>> is lucky to handle 5 Amazon orders per minute. Most people aware of this are
>> predicting that they're going to crater. There is also the penalties from
>> Amazon if a vendor does not perform as agreed.
>>
>> This customer might have spent a million over the last 30 years on Codis.
>> Already they have spent over 5 million trying to get the new cloud based
>> working, and it isn't doing so well.
>>
>> We have continually offered to help. Other customers are looking at the
>> clusterfuck, and are re-thinking about being in the software business. Codis
>> does all they need to run their companies. The main problem is the age of the
>> people involved. We'd really like to do something about that, but if we
>> could, we'd be rich and in the medical field, not software.
>>
>> Erik has told the customers, the company is shutting down at the end of 2023.
>> We'd like to continue, but we can't make any promises. We will do what we
>> can. But if the beer truck gets us ...
>>
>> We have told the customers:
>>
>> 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 ...
>>
>> The names were changed to protect the guilty ...
>>
>
> Should have used COBOL. Then they could move to z/OS and DB2.
> DB2 meet the relational database requirement. And z/OS, well,
> nobody ever got fired for going with IBM. :-)
>
> bill
>
> (Still time to do the conversion. :-)
>

I'm guessing that you're joking, cause that is rather stupid. This isn't a few
programs. It's a full (what they're calling an ERP) system. Very extensive.

--
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 6/30/2022 12:27 PM, Bill Gunshannon wrote:
> On 6/30/22 11:06, Jan-Erik Söderholm wrote:
>> Den 2022-06-30 kl. 15:02, skrev Bill Gunshannon:
>>> On 6/29/22 22:01, Dave Froble wrote:
>>>> On 6/29/2022 3:36 PM, Arne Vajhøj wrote:
>>>>> On 6/29/2022 3:28 PM, Dave Froble wrote:
>>>>>> My days working with VMS, and computers in
>>>>>> general, seem to be coming to an end.
>>>>>
>>>>> What??
>>>>>
>>>>> We expect you to stick around for a few more decades!
>>>>>
>>>>> Arne
>>>>>
>>>>>
>>>>
>>>> Erik (the boss) is 80, I'm 76, Bill in early 70s, and Niel is late 60s, and
>>>> really want to retire.
>>>>
>>>> We made a pitch to the customers. Buy the software package, and we will
>>>> give you a year or whatever we can to train new people. They said they
>>>> didn't want to be in the software business. (Almost every business for the
>>>> last 30-40 years has been in the software business, in some way.)
>>>>
>>>> Largest customer, now being run by original owner's children, had their
>>>> auditors come in, and were told:
>>>>
>>>> You can't use that ancient OS (VMS) ...
>>>> You can't continue with that ancient language (Basic) ...
>>>> You need a relational database ...
>>>> And a few more ridiculous claims ...
>>>> Above all, "you can't count on these old geezers" ...
>>>>
>>>> They refused to give them a successful audit ...
>>>>
>>>> Can't purchase business insurance without successful audit ...
>>>>
>>>> Then they pointed out a company with a cloud based solution for the customer
>>>> to talk to. Too bad they didn't mention that the company was a wholely
>>>> owned subsidiary of the auditing firm.
>>>>
>>>> :-)
>>>>
>>>> The app uses a single connection to the cloud. There is inadequate
>>>> throughput. It is slow. Every time the customer asks for a feature in
>>>> Codis, they are told that cannot be done. After several postponements, the
>>>> customer went live on the cloud solution. They are missing many features
>>>> they counted on. The system is inadequate. For example, (Bill likes to
>>>> gather statistics), max orders from Amazon have hit 100 per minute. The new
>>>> system is lucky to handle 5 Amazon orders per minute. Most people aware of
>>>> this are predicting that they're going to crater. There is also the
>>>> penalties from Amazon if a vendor does not perform as agreed.
>>>>
>>>> This customer might have spent a million over the last 30 years on Codis.
>>>> Already they have spent over 5 million trying to get the new cloud based
>>>> working, and it isn't doing so well.
>>>>
>>>> We have continually offered to help. Other customers are looking at the
>>>> clusterfuck, and are re-thinking about being in the software business. Codis
>>>> does all they need to run their companies. The main problem is the age of
>>>> the people involved. We'd really like to do something about that, but if we
>>>> could, we'd be rich and in the medical field, not software.
>>>>
>>>> Erik has told the customers, the company is shutting down at the end of
>>>> 2023. We'd like to continue, but we can't make any promises. We will do
>>>> what we can. But if the beer truck gets us ...
>>>>
>>>> We have told the customers:
>>>>
>>>> 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 ...
>>>>
>>>> The names were changed to protect the guilty ...
>>>>
>>>
>>> Should have used COBOL. Then they could move to z/OS and DB2.
>>> DB2 meet the relational database requirement. And z/OS, well,
>>> nobody ever got fired for going with IBM. :-)
>>>
>>> bill
>>>
>>> (Still time to do the conversion. :-)
>>>
>>
>> I think that Davids application runs as a distributed system.
>> z/OS are usually very centralized systems.
>>
>>
>
> I guess my comment was too tongue-in-cheek. The same auditors who are
> trying to push VMS and BASIC out the door would apply equal pressure
> on z/OS and COBOL today.
>
> Oh, and Dave, I thought you were the boss?
> :-)
>
> bill
>

For Codis, I'm the R&D guy. For all else, I am the boss.

Did you ever spell boss backwards?

--
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 6/30/2022 9:58 AM, Arne Vajhøj wrote:
> On 6/29/2022 10:01 PM, Dave Froble wrote:
>> Erik (the boss) is 80, I'm 76, Bill in early 70s, and Niel is late 60s, and
>> really want to retire.
>>
>> We made a pitch to the customers. Buy the software package, and we will give
>> you a year or whatever we can to train new people. They said they didn't want
>> to be in the software business. (Almost every business for the last 30-40
>> years has been in the software business, in some way.)
>>
>> Largest customer, now being run by original owner's children, had their
>> auditors come in, and were told:
>>
>> You can't use that ancient OS (VMS) ...
>> You can't continue with that ancient language (Basic) ...
>> You need a relational database ...
>> And a few more ridiculous claims ...
>> Above all, "you can't count on these old geezers" ...
>>
>> They refused to give them a successful audit ...
>>
>> Can't purchase business insurance without successful audit ...
>
>> We have continually offered to help. Other customers are looking at the
>> clusterfuck, and are re-thinking about being in the software business.
>> Codis does all they need to run their companies. The main problem is
>> the age of the people involved. We'd really like to do something about
>> that, but if we could, we'd be rich and in the medical field, not software.
>>
>> Erik has told the customers, the company is shutting down at the end of
>> 2023. We'd like to continue, but we can't make any promises. We will do
>> what we can. But if the beer truck gets us ...
>>
>> We have told the customers:
>>
>> 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.

We tried that. Did you miss the part about the company now being run by the
founder's children? Don't know what's required, so count on outside help, and
the outside help turns out to be a bunch of crooks.

> Obviously I don't know the company or the product that well, so this is
> pure speculation, but something like:
> - keep VMS but switch to VMS x86-64,

which has been the plan

> it is supported and even though
> Linux is server OS king today then everybody does not need to run
> Linux, working with VMS is a learnable skill (someone that know
> Linux should be able to learn VMS in weeks)

> - keep VMS Basic, it is supported and a rewrite would cost a lot of
> money and create a lot of bugs that would need to be fixed, and
> programming in VMS Basic is a learnable skill (someone that
> know VB.NET/Delphi/C should be able to learn VMS Basic in a few
> months)

Try to port it, and just as well start from scratch. We've done evaluations.
Don't see any good in that direction.

> - get rid of the Macro-32, rewrite to VMS Basic or C, too difficult to
> get people onboarded with Macro-32

The only Macro-32 is the database.

> - change to a relational database, besides looking better in the audit
> report you will actually get some benefits in the form of less code

We looked at such a project. Again, might as well start over. We at least
implemented moving all the live data to a WEENDOZE based database so the
WEENDOZE weenies could pull out data they might want. But they cannot touch the
live data. And that is a VERY GOOD THING.

> And hire somebody new. Somebody at least below 50, preferably below 40.
> To give some assurance that there will be a team around for a long time.
>
> Maybe do a gradual phase in of more new people:
> 2022-2023: +1 new
> 2024-2024: +another new, let 2 of the old switch to part time
> 2025-2026: +another new, let 2 other old switch to part time

That is what we invited the customers to do.

>> Then they pointed out a company with a cloud based solution for the customer
>> to talk to. Too bad they didn't mention that the company was a wholely owned
>> subsidiary of the auditing firm.
>>
>> :-)
>>
>> The app uses a single connection to the cloud. There is inadequate
>> throughput. It is slow. Every time the customer asks for a feature in Codis,
>> they are told that cannot be done. After several postponements, the customer
>> went live on the cloud solution. They are missing many features they counted
>> on. The system is inadequate. For example, (Bill likes to gather
>> statistics), max orders from Amazon have hit 100 per minute. The new system
>> is lucky to handle 5 Amazon orders per minute. Most people aware of this are
>> predicting that they're going to crater. There is also the penalties from
>> Amazon if a vendor does not perform as agreed.
>>
>> This customer might have spent a million over the last 30 years on Codis.
>> Already they have spent over 5 million trying to get the new cloud based
>> working, and it isn't doing so well.
>
> Auditing and other services should not be mixed.
>
> I think that was one of the lessons from Enron!

You got that right.

--
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 6/30/2022 12:36 PM, Arne Vajhøj wrote:
> On 6/30/2022 9:58 AM, Arne Vajhøj wrote:
>> On 6/29/2022 10:01 PM, Dave Froble wrote:
>>> Erik (the boss) is 80, I'm 76, Bill in early 70s, and Niel is late 60s, and
>>> really want to retire.
>>>
>>> We made a pitch to the customers. Buy the software package, and we will give
>>> you a year or whatever we can to train new people. They said they didn't
>>> want to be in the software business. (Almost every business for the last
>>> 30-40 years has been in the software business, in some way.)
>>>
>>> Largest customer, now being run by original owner's children, had their
>>> auditors come in, and were told:
>>>
>>> You can't use that ancient OS (VMS) ...
>>> You can't continue with that ancient language (Basic) ...
>>> You need a relational database ...
>>> And a few more ridiculous claims ...
>>> Above all, "you can't count on these old geezers" ...
>>>
>>> They refused to give them a successful audit ...
>>>
>>> Can't purchase business insurance without successful audit ...
>>
>> > We have continually offered to help. Other customers are looking at the
>> > clusterfuck, and are re-thinking about being in the software business.
>> > Codis does all they need to run their companies. The main problem is
>> > the age of the people involved. We'd really like to do something about
>> > that, but if we could, we'd be rich and in the medical field, not software.
>> >
>> > Erik has told the customers, the company is shutting down at the end of
>> > 2023. We'd like to continue, but we can't make any promises. We will do
>> > what we can. But if the beer truck gets us ...
>> >
>> > We have told the customers:
>> >
>> > 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.
>>
>> Obviously I don't know the company or the product that well, so this is
>> pure speculation, but something like:
>> - keep VMS but switch to VMS x86-64, it is supported and even though
>> Linux is server OS king today then everybody does not need to run
>> Linux, working with VMS is a learnable skill (someone that know
>> Linux should be able to learn VMS in weeks)
>> - keep VMS Basic, it is supported and a rewrite would cost a lot of
>> money and create a lot of bugs that would need to be fixed, and
>> programming in VMS Basic is a learnable skill (someone that
>> know VB.NET/Delphi/C should be able to learn VMS Basic in a few
>> months)
>> - get rid of the Macro-32, rewrite to VMS Basic or C, too difficult to
>> get people onboarded with Macro-32
>> - change to a relational database, besides looking better in the audit
>> report you will actually get some benefits in the form of less code
>
> - and ensure that frontend/UI technology is modern, there are so much
> to choose from, I would suggest Grails - not the most common choice,
> but I think it would be easy to integrate with your backend
>
> Arne
>

Why? There isn't much front end usage anymore. Just about everything has been
automated, with rules and procedures specific to the vertical market these
customers are in. Most customer input comes in via web servers communicating
with Codis. Not much happening on terminals anymore.

--
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 6/30/2022 2:35 PM, Dave Froble wrote:
> On 6/30/2022 12:36 PM, Arne Vajhøj wrote:
>> - and ensure that frontend/UI technology is modern, there are so much
>>   to choose from, I would suggest Grails - not the most common choice,
>>   but I think it would be easy to integrate with your backend
>
> Why?

All part of the solution and something that may be easier to
update.

>   There isn't much front end usage anymore.  Just about everything
> has been automated, with rules and procedures specific to the vertical
> market these customers are in.

I don't know the application, but most application has some
end user UI and some admin UI.

>   Most customer input comes in via web
> servers communicating with Codis.  Not much happening on terminals anymore.

Most go for web UI today (unless targeting smartphone and
tablet devices). But the web browser need to talk to something
that talk to the application.

CGI scripts are no good today.

Arne

On 6/30/2022 2:30 PM, Dave Froble wrote:
> On 6/30/2022 9:58 AM, Arne Vajhøj wrote:
>> - change to a relational database, besides looking better in the audit
>>   report you will actually get some benefits in the form of less code
>
> We looked at such a project.  Again, might as well start over.

That I don't get.

You have something that conceptually look like:

frontend layer (VT, web, web service, whatever)---[API] business logic
layer---[API] persistence layer---actual storage

If you change the actual storage then the persistence layer need
to change, but the rest should not need to change.

Some manage to mess up business logic layer, persistence layer and
storage by putting business logic in stored procedures in the database,
but that is not the case here as RMS index-sequential files does not
support SP at all.

>   We at
> least implemented moving all the live data to a WEENDOZE based database
> so the WEENDOZE weenies could pull out data they might want.  But they
> cannot touch the live data.  And that is a VERY GOOD THING.

Sounds like you already have the database structure in place.

:-)

MS SQL Server?

Arne

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.

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.

Once again I refer to the wheel, which isn't broken, and doesn't need replaced.

--
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/1/22 04:30, 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.
>

Just like ego languages du jour.

bill

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.

It is not generally better than so many other. But I just think it is a
good fit here.

Traditional Basic programmers may like Groovy's approach to language.

Very good integration options.

>   To my mind there are too
> many of these frameworks, it feels like a new one appears most days,
> spreading themselves too thinly.

It can be quite overwhelming to try and understand what is out there.

But this is not brand new technology - Groovy is from 2007 and Grails
are from 2008.

And it has a significant user base even though there are other
technologies in that space that are more widely used. Small slice
of a huge pie.

Arne

On 7/1/2022 9:40 AM, Arne Vajhøj 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.
>
> It is not generally better than so many other. But I just think it is a
> good fit here.
>
> Traditional Basic programmers may like Groovy's approach to language.
>
> Very good integration options.
>
>> To my mind there are too many of
>> these frameworks, it feels like a new one appears most days, spreading
>> themselves too thinly.
>
> It can be quite overwhelming to try and understand what is out there.
>
> But this is not brand new technology - Groovy is from 2007 and Grails
> are from 2008.
>
> And it has a significant user base even though there are other
> technologies in that space that are more widely used. Small slice
> of a huge pie.
>
> Arne

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.

The problem isn't the software, it's the geezers, and, well, the rather
dishonest auditing firm.

--
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/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.

More like continuously evaluating whether new stuff has some
advantages over old stuff.

> Once again I refer to the wheel, which isn't broken, and doesn't need
> replaced.

If you took the wheels from your first car and put on your current car,
then I suspect that you would not like them.

The old wheels worked but some progress has been made since then.

Arne

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, but the
new shiny VMS VAX thing was just better.

And so on.

Arne

=?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.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

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.

>
> 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.

>
>> Once again I refer to the wheel, which isn't broken, and doesn't need
>> replaced.
>
> If you took the wheels from your first car and put on your current car, > then I suspect that you would not like them.

But is that due to a flaw in the wheel or the fact that they forced
changes in the car to require different wheels?

>
> The old wheels worked but some progress has been made since then.

Not in their general design. I suppose you are one of those
people who think low profile tires are the cat's pajamas.

bill

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. Even faster
one's could be manufactured today with minimal required engineering.
But someone decided to fix something that wasn't really broken and
force it's users to follow them.

>
> And so on.

And so on.....

bill

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.

PDP-11 production continue until 1997 when people were migrating
from VAX to Alpha - not to VAX.

Arne

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.

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.

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.

>> 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.

>>> Once again I refer to the wheel, which isn't broken, and doesn't need
>>> replaced.
>>
>> If you took the wheels from your first car and put on your current
>> car, > then I suspect that you would not like them.
>
> But is that due to a flaw in the wheel or the fact that they forced
> changes in the car to require different wheels?
>
>>
>> The old wheels worked but some progress has been made since then.
>
> Not in their general design.  I suppose you are one of those
> people who think low profile tires are the cat's pajamas.

A wheel is defined as a round thing you drive on, so that
cannot change - else it would not be a wheel anymore.

But wheels has changed over time.

Antique massive wood wheels to middleage/renaissance wood with spokes
and iron "tire" to metal with tension spokes and round rubber tire with
tube to massive metal wheels with with more square rubber ties with tube
to alloy wheels with tubeless radial tires.

Just with the tires the design, the thread patterns and the rubber
compound has changed a lot to improve characteristics.

Arne

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.
> --scott
>
>

Depends ...

If the goal is destroying the user, then SAP works very well ...

--
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 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.
>> --scott
>>
>>
>
> Depends ...
>
> 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.

--
Chris

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.
>>> --scott
>>>
>>>
>>
>> Depends ...
>>
>> 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.

The more things change the more they stay the same.

bill

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 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.

>
>>> 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.

>
>>>> Once again I refer to the wheel, which isn't broken, and doesn't
>>>> need replaced.
>>>
>>> If you took the wheels from your first car and put on your current
>>> car, > then I suspect that you would not like them.
>>
>> But is that due to a flaw in the wheel or the fact that they forced
>> changes in the car to require different wheels?
>>
>>>
>>> The old wheels worked but some progress has been made since then.
>>
>> Not in their general design.  I suppose you are one of those
>> people who think low profile tires are the cat's pajamas.
>
> A wheel is defined as a round thing you drive on, so that
> cannot change - else it would not be a wheel anymore.
>
> But wheels has changed over time.
>
> Antique massive wood wheels to middleage/renaissance wood with spokes
> and iron "tire" to metal with tension spokes and round rubber tire with
> tube to massive metal wheels with with more square rubber ties with tube
> to alloy wheels with tubeless radial tires.
>
> Just with the tires the design, the thread patterns and the rubber
> compound has changed a lot to improve characteristics.

And the same is true about legacy IT Systems. But some people
still see mainframes and COBOL or Fortran or PL/I, etc. as old
and needing replacement. I would think the VMS community would
be well aware of this by now.

bill

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.

>
> 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.

bill