Sent: September-02-21 3:34 PM
Subject: Re: [Info-vax] OpenVMS developmen integration with Azure
Post by firstname.lastname@example.org
This type of conversation is where I like to trot out this 2014 timeless
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.
SQL Server had been abandoned for indexed files stored on VMS.
The rock stars had created a monstrosity of a database, consisting of
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.
Multi-tier programming was also abandoned, leaving business calculations
everywhere from within DIBOL code on VMS to the paint routine of a
So they dropped multi-tier but have business logic in multiple tiers. That
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).
hundreds of undocumented tables tied together with hundreds of
undocumented relations, all glued together with copious amounts of XML
Database tables are not glued together by XML.
Not sure, but perhaps its possible (likely?) the article was modified by a
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
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".
Kerry dot main at starkgaming dot com
This email has been checked for viruses by AVG.