A Real World Guide for the Mainframe Systems Programmer
by Joe Gallaher
Designing and implementing a new operating systems environment is fun and exciting. How about documenting your work afterwards? Well, maybe not so much. The same can be said for writing a resume. Most systems programmers I know are much better at doing their job than recounting their work later. Perhaps that is why finding a well-written systems resume is rarer than a 25 year old with MVS internals.
But why should detailing your own experiences be so
difficult? A quick search on Amazon yields hundreds of books on creating
the perfect resume. Every aspect of creating your curriculum vitŠ is
covered, including the use of power adjectives, selecting the perfect
font, and choosing the ideal paper stock – in other words, a lot of
useless fluff. So save your 15 bucks (plus shipping and handling) and
just keep reading. For the last 25 years I have reviewed and written
thousands of systems programmer resumes. So who is better qualified to
help you document you? Let’s get down to work.
The functional resume format is where you describe all your experience (usually broken down into categories) in one section and dates of employment (without job descriptions or titles) in a separate area. For someone trying to disguise the fact they have been out of systems for several years, this might be a useful format. For anyone else, I do not recommend it.
Since most employers prefer to see when and where you
did what, I always use the traditional reverse chronological resume
format. Start with your most recent job and work backwards. Include the
dates, company name, job title, and a job description for each
individual job title you’ve had.
Describing your work is the most difficult, yet most important, part of putting together an effective resume. For fear of saying too much, many resume writers do not include enough. I try and simplify things by breaking them down into categories. For a mainframe systems programmer, this includes the following:
Opening statement: You should start each job description with a general statement of the job function and the current or most recent software environment.
System and subsystem installs: This is where you describe the large, non-program product installs that you’ve done. If you are a z/OS systems programmer, then describe your z/OS install or upgrade. The same is true for the CICS, DB2, IMS, VTAM, or MQSeries systems programmer. An MVS-generalist may have a combination of the above. You should also include the degree to which you participated in the install. Were you the sole person, the team lead, a member of a two-person team, or were you just in charge of the coffee and doughnuts?
Troubleshooting: This is an important aspect of every systems programmer’s job. Don’t downplay this very important role. Whether it is stated in a want ad or not, it is a requirement for every single job. Include dump analysis if you’ve done it and how the dumps were formatted. Also include any third party monitors you’ve used or traces you’ve done. If you have written something yourself to track down bugs, all the better!
Performance Tuning: If you’ve done this, state the tools you’ve used to isolate throughput bottlenecks as well as the course of action used for eliminating them. This will likely include the use of third party tools such as the Omegamon or TMON family of monitors. It may also include the analysis of MVS source data either by using existing programs or writing your own SAS code. Tuning efforts may include things like setting WLM policies or adjusting buffer pools. Click here for a sample Performance Engineer resume.
Capacity Planning: If you’ve done capacity studies, state the tools you’ve used to forecast workload requirements. Your description will likely include the use of third party tools such as MAINVIEW or BEST/1. It may also include the analysis of MVS source data either by using existing programs or writing your own. Click here for a sample Capacity Planner resume.
Communications: List all the networking software and protocols that you have installed or supported. Also outline any tools or products used for network troubleshooting (GTF, NetView, etc.), network security (IDS, TLS, etc.), network performance, or communication with other platforms (OSAs). This is also a good place to include migrations from SNA to TCP/IP. Click here for a sample Network Systems Programmer resume.
Storage Administration: Include in your resume the size of the DASD farm, hardware used, and platforms supported as well as the software used to maintain it. Also include related activities such as coding ACS routines and Disaster Recovery testing. If your sole job is DASD administration, then this job description will obviously have to more storage-detailed than that of a generalist.
Coding (exits/utilities): Make sure to include any exits or systems-related utilities that you have written or modified.
Program product installs: List all the third party products you have installed and maintained.
Conversions/Upgrades: Have you converted from one product to a competing vendor’s equivalent? Or from one version of a product to a newer release? Make sure to add this to your resume.
Backup Support: Maybe you are not the leading CICS or IMS expert in your shop, but if you are the backup systems person for these products, why be modest?
Education and Vendor Training
If you have one or more degrees, put them on your
resume. However, I don’t usually include college coursework without
degrees unless it is recent or relevant to your work. Sometime it gives
the impression you don’t finish things you start. Your resume should
also contain all the expensive vendor training you’ve had. What
potential employer wouldn’t want to take advantage of all the internals
classes that you completed on someone else’s dime?
Use functional job titles instead of company titles. If you function as the Lead CICS Systems Programmer then use that instead of Senior Analyst IV.
Combine contract positions. In cases where you’ve had the same job with a particular government agency, but have worked for two or more contractors, combine the jobs into one. When contracts to change hands, it is not unusual for the incumbent to keep on some of the previous staff. So why make it seem like you’ve changed jobs three times in five years when you haven’t even changed desks? An example of this can be found on our sample z/OS Systems Programmer resume
Use proper capitalization and apostrophes for acronyms. Don’t capitalize the‘s’ for plural acronyms. You create multiple LPARs, not LPARS. And don’t use an apostrophe to make an acronym plural – only use one to make it possessive. You install PTFs, not PTF’s. You might interface with multiple DBAs, but you only oversee one DBA’s work.
Eliminate pronouns. It is repetitive (and almost sounds narcissistic) to start every sentence with ‘I did this… I did that.’ Why not just eliminate the pronoun altogether. It might not seem like there is much difference between “I installed and customized CICS” and “Installed and customized CICS,” but string together a dozen or so of those I’s and you’ll see what I mean.
Use the correct product form. For instance, IBM seems to prefer MQSeries – not MQ/Series, MQ Series or MQSERIES. Check the vendor’s website to see how their product should be spelled and capitalized. But, whatever form of a product name you decide on, be consistent with it throughout your resume.
Don’t spell out well-known acronyms. You certainly would not refer to CICS as the Customer Information Control System. (Do the CICS developers in Hursley even know what CICS stands for?)
This is not meant to be all-encompassing, but it should be useful as a template to get you started. Check back, as I will update this page regularly to keep it current with the latest technology — just like you should with your own resume. Good luck!
Note: Sample resumes can be found by using the drop down menu at the top of this page or by linking to them through our site map. If you have any suggestions on improving this page or our sample resumes, please email me at Joe@SPCI.net.