(no title)
ibiza | 2 years ago
I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs running w/o change (at the time) on Unix. This was in the 90s.
ibiza | 2 years ago
I was part of a 4 person team that knocked this out in under a year. 1,000's of mainframe programs running w/o change (at the time) on Unix. This was in the 90s.
hermitdev|2 years ago
I worked with both DB2 & UDB during my internship 2 decades ago, and while largely compatible with core SQL functionality, that changed quickly after you got off the "normal" path. UDB was released at a much faster cadence, and if you developed to the latest features of UDB, you'd often find yourself unable to deploy against DB2.
A few of my last projects as an intern: 1) storing BLOB objects in DB2 from a .Net app and 2) porting an "interactive" batch-processed COBOL app to ASP.Net form 3) getting DB2 Connect clustering on windows working (I never did get this working despite spending an entire summer on the phone with IBM support).
I've some fond memories of working with the mainframe. Like the time I managed to crash the entire development LPAR with a specific SQL query that broke the DB2 query optimizer... The phone call from the NOC was immediate and went something along the lines of "I don't know what you did, but don't do it again, you just took down all of development". Development was something like +10k users...
ibiza|2 years ago
We actually targeted Oracle on Unix. Fortunately, the app developers never got too deep into DB2-isms, so it worked out fine.
rvba|2 years ago
tracker1|2 years ago
I'm not really a fan of mainframes, only pointing out that the companies still on them are generally on them as a direct replacement to general purpose servers isn't purpose fit, and conversion is excessively costly, even compared to IBM mainframe contracts.
stcroixx|2 years ago
ibiza|2 years ago
redandblack|2 years ago