Welcome to my little z/OS web space. I don't have much here yet except some interesting rexx utilities that you might find useful. Keep checking back though!

For those that are interested, I have my resume available in Microsoft Word and plain text format. Feel free to download it and pass it around. I'll always consider any telecommuting opportunities that come my way!

I have been working in computers in general since 1980, and the world of MVS since 1986. I've made a couple of half hearted attempts at leaving this operating system for greener pastures, but each time I've been drawn back. I simply love working with MVS, warts and all (the OS, not me!). What can I say? It just feels like home.

In addition to the usual daily MVS system programmer tasks, I've done a number of OS upgrades, a couple of large data center moves, LPAR mergers, a dozen or more disaster recovery tests and several significant conversions such as TSS to RACF and CA-1 to TLMS.

I also spent a year doing MVS Level II support for IBM in Poughkeepsie, New York, the IBM Meca. I was very new to dump reading at the time. The person who interviewed me for the contract tested my knowledge with a few questions on machine language, and just by chance asked me the two or three instructions that I knew. He enthusiastically reported that I was a prime candidate for the job, and three weeks later I found myself on the phone in Poughkeepsie trying to walk customers through their system dumps. It was not a pleasant experience at first, but within a short time I was able to become a valuable member of the team, and was complimented numerous times by the IBMers I worked with. It was definately one of the most challenging and interesting times in my career.

I do have non-MVS experience too, such as a year of SNA support. We had a fairly large network of around 20 subareas of 3745s and MVS LPARs. Fairly soon after I joined the group I decided to rewrite our path definitions manually due to the mess they were in, and I was able to pull it off with nary a network error. The few who could appreciate it were mighty impressed. So was I. Har har.

I did about a year of Unix support, mostly working on SNA configuration tweaking between the servers and the mainframe. It was a network of about 120 servers, not too large by today's standards, but back then it was considered very significant. During my time there I properly configured and tuned APPN to make the network smooth and robust. I may be in the minority, but I actually liked APPN. To me it was the best of SNA and the best of IP rolled into one. Too bad it never caught on.

As a learning exercise, I wrote a fully functional FTP client for Windows 98 some years ago. It was 25,000 lines of C++ code using Borland's Object Windows Library. I had a lot of fun with it, especially when someone decided to translate my resource DLLs into German. It was neat to see several thousand downloads from Europe soon after the German version was released.

The problems with designing large business applications using Java and .NET vs. the mainframe are:

1. The applications are generally far more complex, which means they will inherently and invariably generate more problems, and
2. There are fewer native debugging/diagnostics tools available when the inevitable problems DO arise.

When a large client/sever application goes belly-up, you will find a gaggle of programmers scribbling on multiple whiteboards for hours or possibly days (I've actually witnessed this), and the outcome is often "try upgrading xxx and see if the problem goes away".

On the other hand, I had to diagnose one of our very rare mainframe crashes in July 2004. Because I had a stand alone dump and IPCS, IBM and I (three people in all) were able to determine the exact fix for the problem via email. No muss, no fuss.

For the mainframe, the emphasis has always been on maintainability and reliability, with the resultant diagnostics tools developed over the years: GTF, slip traps, system trace, branch trace, master trace, component trace, stand alone dump, IPCS, etc. For server cluster technology, the emphasis is on eye-candy and pizzazz, and whether they work reliably or not is of secondary concern.

This mainframe advantage is completely lost on the latest generation of systems architects, mostly because that generation and the schools that have taught them have bought into the myth that the mainframe is an extinct technology that has nothing to offer the modern computing age.

If only they knew. Which technology would you bet your large business on?

That's all I've got for you for now. Don't forget to stop by my rexx utilities pages. Feel free to send me mail!
//