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

[kemain.nospam at gmail.com]

>-----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. I would have assumed they left the files in RMS indexed files.

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

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

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

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


Regards,

Kerry Main
Kerry dot main at starkgaming dot com




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