This missive began in the pre-sleep twilight of last night, wherein the idea of server-centric applications remains ever more true, given the soon to be death of the java plug-in, aka applets. I went to CSC a lifetime ago to do, as it was told to me, "heavy weight database development". Turned out to be VSAM files ported to DB2 on z, run by the existing 40 year old COBOL with revised copybooks and a bit of front-end lipstick. Yikes!! Still COBOL doing RBAR against file data. The products actually ran shitier with the port. Enough so that a few, wise, clients stayed with the VSAM release. Since source code licensing was generally used, such clients took over the modification and extension.
The new and improved version used an applet as the browser front-end, and one of my retread COBOL java colleagues told a prospect "we prefer to do transactions in the client". Heavy weight database development, my eye. A total waste of DB2 fees.
In the olde days of COBOL/CICS/VSAM, the distinction twixt client and datastore was a bit fuzzy, since it's all COBOL and
CICS controls the transaction.
The true beauty of the CICS/DB2 attachment is that it's designed to be a two-phase commit process.
(Or, one might say, it's
two TPMs in a death match! You have to read that piece, which I found after I wrote my snark; it's a hoot.) But the danger of being hung out by an unsupported infrastructure is minimal. After all, no one got fired for buying IBM.
So, reports re-appeared recently that
java 9 will be minus the plug-in. No more applet. When I returned to quant employment, the major aspect was Progress 4GL/database applications. As it turned out, the Progress database at that time was SQL-86 compliant; which means it was just grandfathered into The Club. So, the 4GL was a RBAR language against indexed tables/files. The thing about proprietary languages is that you're betting that the vendor will out survive your business. Progress has. The plug-in and applets haven't.
So, today we find
Godzilla SSD release.
The PM5 SAS SSD sets new records by offering capacities of up to 30.72 TB in a 2.5" form factor, and sequential transfer speeds of up to 3350 MB/s (reads) thanks to support for four-port SAS MultiLink. SAS has always supported dual-port drives, with the two ports either used in a failover configuration for high availability or bonded for high throughput.
The end result of all this is that highly (if not massively) parallel processing of relational data on the server is now really quite cheap. Time to treat the browser as an xterm; just another I/O device with all the smarts in the database. The gates to the Emerald City are just ahead. Let's build our applications the way Dr. Codd told us to. OK?