[Info-vax] Any stronger versions of the LMF planned ?, was: Re: LMF Licence Generator Code
Dave Froble
davef at tsoft-inc.com
Sat Aug 7 22:31:24 EDT 2021
On 8/7/2021 8:24 PM, Bill Gunshannon wrote:
> On 8/7/21 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:
>>>> On 8/7/2021 7:59 AM, Bill Gunshannon wrote:
>>>>> Go read some
>>>>> of the stuff on LinkedIn about "Legacy Systems". Not specifically
>>>>> about VMS but the attitude is even if it still does the job if it
>>>>> is old (ie. COBOL) it is bad and a problem.
>>>>
>>>> Being old is not a problem in itself.
>>>
>>> Being old is never a problem in itself. I'm old and regularly
>>> compete with people less than half my age, successfully.
>>>
>>>> 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.
>
> If your running a VAX then it might be a problem. But, believe it
> or not, most legacy systems are not running on old or non-existant
> hardware. VMS being the main exception. :-)
People are using VAX emulators that run quite a bit faster than any VAX.
>> 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.
>
> As has been stated here numerous times in the past, unless you are
> running custom hardware and doing things like device control this
> is not likely to be a problem. let's limit this to the kind of
> things VMS is actually used for in most cases.
What? Common sense in c.o.v? No, we can't have any of that.
>>>> - 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,
>
> I have little doubt that it will be approved. Financially it is a
> totally non-apparent bump in the budget.
>
>> that funding will continue in the future
>
> That will depend on whether or not academia decides to swallow their
> pride and get behind the idea. I am doing what I can to try and help
> it, but for totally non-technical reasons it is going to be a hard sell.
>
>> and that students will be interested?
>
> I had students interested in legacy systems when I still worked at
> the University even with members of the faculty attacking much of
> what I was selling.
>
>>
>>>> - it does not integrate with newer system that it need to
>>>> integrate with
>>>
>>> With the exception of Dave's system (I actually know very little
>>> about VMS BASIC) I can think of no legacy system that can not be
>>> integrated into a modern system. I have had no problems doing web
>>> programming with COBOL.
>>
>> Anything can be somewhat integrated using various hacks.
>
> I needed no hacks to get COBOL running on the web. It's a mindset
> problem, not a technical one.
>
>>
>> But good integration will often be either impossible or
>> expensive.
>
> I would like to see examples of this, Real ones, not some of the
> typical contrived examples I usually see where the target moves
> with every new iteration. There are a lot of modern, used everyday
> ISes that are based on what are called legacy systems and languages.
> MOst of the users never notice.
>
>>
>>>> - 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.
>>
>
> Which is all the more reason to stay the course and clearly
> understand "modernization" before you start throwing terms
> around. A COBOL IS running on a PDP-11 or TOPS system does
> not need a new language. Re-writting it in Java or C# or
> even Python will get you nothing but a potential for new
> bugs, inefficiencies and business logic problems.
>
> bill
>
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
More information about the Info-vax
mailing list