I have an upcoming technical interview with a former employer that will focus on PL/I, DB2, and ISPF. The job will be with systems that I architected and wrote myself 20 years ago. The few years of professional programming that I did since then was all assembly language. The problem is that I haven't programmed professionally in 15 years, and the personal programming that I've done since then has been in other "modern" languages. My question is whether there are new features in PL/I and DB2 that I should be aware of. (When browsing through the latest "Principles of Operation" I saw machine instructions to support C style strings that weren't there in ancient times - cool.)
PL/I at all as a has not changed much at all as a language. The implementation has changed drastically as under the covers the compiler is effectively a pre processor for the C++ compiler. This change has made native PL/I multi-threading problematic.
ISPF is just the same as it ever was, nothing noticeable has changed in the last 20 years. Most Z/OS shops that are doing any amount of development are using the the Rational workstation based tools which allow the development, and, debugging to take place on the PC (even though the compiling and execution are running in the mainframe itself).
DB2 is moving nicely with the times. CLOBS, BLOBS, 64 bit integers, native XML support plus a myriad of performance and connectivity enhancements.
The interesting changes in zOS over the last few years are:-
Some things never change though, JCL is still there, CLISTs are as horrible as ever and IBM rename their products every few weeks so you can never find the manuals on the web..
One nice change with DB2 is that the z/OS and LUW (Linux/UNIX/Windows) code is coming closer and closer together as far as functionality is concerned. Since V8, DB2 now stores everything internal in its system tables as Unicode, translating to the specified ZPARM CCSIDs as needed. It's also a lot more flexible with different CCSIDs and Unicode in character data.
ISPF has great support for files stored in the USS file system - for example, in the "other data set" field, you can put path names. If you have a directory, you will get a file list similar to the standard PDS member listing.
One thing you may remember from that long ago was the rather dismal opinion of Language Environment (LE). It took several years, but LE is now a stable run-time, and it makes combining languages like PL/I and C much easier in an environment. COBOL and Assembler still have a few quirks in this area, but they're easy to handle.
From the assembler side of things, pick up the latest POP and look at all the neat new instructions. Depending on the hardware at the shop, though, some of the really neat new ones may not be available, such as the compare-and-branch instructions (introduced with the current z196/z114). All machines are 64-bit now, and C/C++ can generate code for AMODE 64.
If you dabbled on the system side in assembler, C has a METAL feature designed for use in places where you could only use assembler in the past; the METAL code does not use LE and has a limited number of standard C library routines.