[Info-vax] Any stronger versions of the LMF planned ?, was: Re: LMF Licence Generator Code

[Bill Gunshannon]

On 8/8/21 10:45 AM, Arne Vajhøj wrote:
> On 8/7/2021 10:25 PM, Dave Froble wrote:
>> On 8/7/2021 7:40 PM, Arne Vajhøj wrote:
>>> On 8/7/2021 6:42 PM, Bill Gunshannon wrote:
>>>> On 8/7/21 5:56 PM, Arne Vajhøj wrote:
>>>>> It becomes a problem if:
>>>>> - it is out of support
>>>>
>>>> Lack of support for one part of an IS should not be a reason to
>>>> abandon it in its entirety.
>>>
>>> If that part cannot be replaced: yes it is.
>>
>> Anything can be replaced.  The required effort may or may not be 
>> excessive.
> 
> The effort of creating a CPU replacement or an OS replacement
> or a database replacement will be excessive for sure.

They already exist.  Again, using VAX as an example, the CPU, in
fact,  the entire system is replaceable with SIMH or something
similar.  OS?  How many real world IT systems are so integrated
with the OS that another can't provide the services necessary to
accomplish the same task.  (I am  not talking about features some
users like, I am talking about accomplishing the requirements of
an IS.  And, databases are a dime a dozen today.  Most newer
databases can deliver everything the older ones can and much more.
And, usually, at a higher rate of efficiency.

> 
>>> And even if that part can be replaced then the question is at what
>>> cost compared top the replacement. And it also raises the question
>>> about whether other parts will go out of support soon.
>>
>> Vs the cost of doing a replacement?
> 
> The logic goes like:
> - if it cost 1 M$ to replace A
> - if it cost 2 M$ to migrate
> - then just looking at A make migration a bad  plan
> - but if B, C, D and E are all going to go out of support within
>    the next 3 years and they will also cost 1 M$ a piece to replace
>    the the migration business case looks much better
> 

There is a lot more to costing such a migration than this simple
example.  But migration can still be the better of the choices
especially if it is limited to what really needs to be done to
migrate and not blanket replacement of everything with something
else.

>>>>> - it is hard to find people with skills
>>>>
>>>> That is a fixable problem.
>>>>
>>>> https://edscoop.com/college-legacy-programming-langauges-grant-bill/
>>>
>>> That is a good proposal.
>>>
>>> But do you expect serious companies to base their future on that
>>> such a bill get approved, that funding will continue in the future
>>> and that students will be interested?
>>
>> Students are interested in getting jobs.
>>
>> Now, the damn educators who think they know everything, maybe they 
>> should not have jobs.
> 
> Business has to act according to how the world is not how
> the world should be.

Or, they can contribute to fixing things if it is in their best
interest.  GDIT has the contract for the DOD EMR System.  It is
at least hundreds of thousands of lines (maybe over a million,
I haven't actually seen it) of COBOL running in an IBM environment.
They have offered internships to college students for years.  I
expect that a number of the people now maintaining the system
started as interns.  The Bill mentioned above is just another
way to spur this movement on in spite of academia's attempts to
prevent it.

> 
>>>>> - it is expensive to maintain
>>>>
>>>> In the case of legacy systems expense is more objective than
>>>> subjective.  A little research will show how the majority of
>>>> these modernization projects usually run way over budget and
>>>> seldom accomplish their original goal.
>>>
>>> Huge IT projects are in general risky.
>>>
>>> Migration projects are no exception.
>>
>> And if it ain't broke, why fix it?
> 
> If you have commitments from vendors that the HW and SW
> will be supported for 10+ years and you get hundreds
> of qualified applicants when you put up a job ad and
> the users are happy with the cost and time to integrate with
> other solutions, then there is no reason to fix anything.
> 
> But ...
> 

Lack of currently qualified programmers should never be justification
for re-writing a program in a different language.  The real problem
is just too easy to solve.

bill