[Info-vax] OpenVMS developmen integration with Azure DevOps.

[Arne Vajhøj]

On 9/3/2021 4:05 PM, kemain.nospam at gmail.com wrote:
>> -----Original Message-----
>> From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj via
>> Info-vax
>> Sent: September-02-21 3:34 PM
>> To: info-vax at rbnsn.com
>> Cc: Arne Vajhøj <arne at vajhoej.dk>
>> Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
>> DevOps.
>>
>> On 9/1/2021 8:25 PM, kemain.nospam at gmail.com wrote:
>>> This type of conversation is where I like to trot out this 2014 timeless
>> OpenVMS article:
>>> <https://thedailywtf.com/articles/Jurassic-Programmers->
>>
>> You have posted it before.
>>
>> And it is very funny.
>>
>> And such things happen.
>>
>> But most likely this particular story is made up.
> 
> No idea, but You could always contact the author for details on where and/or
> what the story was based on.
> <https://thedailywtf.com/authors/alex-papadimoulis>
> 
>> <quote>
>> SQL Server had been abandoned for indexed files stored on VMS.
>> ...
>> The rock stars had created a monstrosity of a database, consisting of hundreds
>> of undocumented tables </quote>
>>
>> So the dropped the relational database for VMS index-sequential files, but
>> when they needed to convert back they had a relational database.
>> That does not add up.
>>
> Not sure where article stated what the repository was when they converted
> back.

See second part of quote above.

>      I would have assumed they left the files in RMS indexed files.

They said they did in first part of quote above.

>> <quote>
>> Multi-tier programming was also abandoned, leaving business calculations
>> everywhere from within DIBOL code on VMS to the paint routine of a
>> Windows cont
>> </quote>
>>
>> So they dropped multi-tier but have business logic in multiple tiers. That does
>> not add up.
>>
> 
> They likely had the Dibol business code running on the same server as the
> RMS indexed files. As I know you know, placing the App and DB tier on the
> same OS instance (even Web) is very common in the OpenVMS world. Placing the
> App/DB on the same OS instance is not something typically done in the
> Windows/Linux culture (even on VMware, they are separate OS instances).

Yes.

But the quote explicitly say code on Windows and VMS - that makes two
tiers.

>> <quote>
>> hundreds of undocumented tables tied together with hundreds of
>> undocumented relations, all glued together with copious amounts of XML
>> </quote>
>>
>> Database tables are not glued together by XML.
>>
> 
> Not sure, but perhaps its possible (likely?) the article was modified by a
> non-technical editor?

That is certainly possible.

But then it may be more of "fiction based on true events" than
"documentary".

>> <quote>
>> new team of sharp-minded programmers to completely rewrite the software
>> as a Windows application using VisualBasic.NET ...
>> version 2's data structure was built by programmers fresh out of college
>> </quote>
>>
>> Some Colleges teach C# but practically none teach VB.NET. New graduates
>> and VB.NET is just a non-existing combination.
>>
> 
> Let's not forget the article was from 2008 - 13 years ago.

Same back then.

VB.NET was never a thing in education. Pascal, C++, Java, C#, Python,
maybe some OCAML or Haskell - not VB.NET. VB.NET existed for the
millions and millions of VB6 and ASP/VBS programmers that existed
late 90's/early 00's.

> Having stated this, the article drives home the point that many, many
> companies in the last number of years have been bamboozled into converting
> to the next big shiny technology only to find that the grass is not always
> greener on the other side. They often learn a very painful and very
> expensive lesson. Experienced programmers that understand the company
> culture and business logic used in these Apps are critical resources to a
> companies future success.
>
> Its why many Med-Large Customers with battle proven applications that run
> the business now (albeit on older technologies) now typically choose a
> strategy of "upgrade and integrate" v.s. the strategy that vendors all to
> often push of "rip and replace".

It is a fact that many big IT projects fail. Going over time, over
budget and below expected functionality is common. Being
cancelled after spending lots of money is not unheard of.

Add unrealistic expectations, poor project management
and inexperienced developers and failure changes from
potential risk to almost certainty.

Having developers with domain/company experience is
critical for maintenance, enhancements and small system
migrations. But for large system migrations then I would
prioritize experience with large system migrations over
domain/company experience.

Arne