longpelaexpertise.com.au/ezine/DoYouNeedAssembler.php?ezinemode=printfriend

LongEx Mainframe Quarterly - August 2013

Many of these sites have little or no assembler code, and those with existing code rarely touch it. Today it has become standard practice to avoid new assembler development, and even if you did want assembler skills, justifying assembler training expenses will always be a hard sell. So is it a good idea to have no assembler skills, or are these sites heading for disaster?

Assembler In the Past

When I first started with mainframes, assembler knowledge was an essential and required skill of every systems programmer. Let's look at some of the reasons:

• Exits. In previous years, customising MVS to suit your needs often needed an exit. This is a small piece of code fitting into a space provided by a product; always written in assembler. For example, sites needing to control user disk usage would use the IGGPRE00 and IGGPOST00 MVS exits. These exits would be called before (IGGPRE00) and after (IGGPOST00) every disk allocation request. Sites could then code anything they wanted: from using RACF to validate allocation requests, overriding disk volume specifications, and logging disk usage.
• System Generation. MVS systems prior to MVS/XA would be generated. This means taking an assembler macro provided by the vendor, filling in values, and then assembling the macro to create a system. IMS still uses this technique today. To do this, at least basic assembler knowledge was needed.
• Tools and Utilities. Tools and utilities included in MVS in the past were limited, forcing sites to purchase software products (if they existed), or write their own tools. And in many cases, these tools required system routines and APIs only available in assembler.
• Applications. Most major z/OS applications over 15 years old will probably have some assembler modules. These will have been created because they used facilities unavailable in COBOL or PL/1, or needed the additional speed of assembler.
• Dumps. In my early days as a systems programmer, dumps were regularly produced after errors. And we analysed every one. To analyse system dumps, assembler knowledge is a must.
• Documentation. If you've ever used the free Hercules mainframe emulator, the chances are you've used it with the freeware MVS 3.8J. During these times, IBM provided MVS source code. Early documentation could be poor, so systems programmers would sometimes delve into the source code to see how it worked. IMS was the same, and today you can still find some of the IMS source code in the ADFSSRC dataset.

So every site would have at least one systems programmer, and sometimes one applications programmer, with strong assembler skills.

Assembler Today

Today, there are far fewer reasons for assembler. Let's look at the previous reasons as they stand today:

• Exits. Some exits are no longer required with z/OS. They have been replaced with parameter values, or refer to obsolete functionality. For example, the IGGPRE00 and IGGPOST00 exits, although still available, are rarely required in a DFSMS world. However most sites will still have some exits, often written long ago. For example, the chances are that you site uses the IEFACTRT exit to format the output from batch jobs to show return codes. IBM supplies a popular sample in the SYS1.SAMPLIB dataset.
  Today assembler is no longer essential for exits. IBM provides the Metal-C compiler to create exit-capable C. DTS Software's Easy/Exit can be used to create exits without assembler. In many cases, exits can be purchased with commercial software, eliminating the need for internally developed code.
• System Generation. z/OS no longer requires system generations. In fact, the only product I'm aware of that does is IMS. IBM provides enough IMS generation samples that little assembler knowledge is needed.
• Tools and Utilities. z/OS functionality has increased, and some of those old tools and utilities are no longer required. Saying this, many sites continue to use and rely on tools written long ago. And IBM continues to supply sample utilities in Assembler language. Anyone looking to leverage freeware code from sites such as www.cbttape.org will still need assembler.
• Applications. Few application programmers will create new assembler modules, relying on improved APIs and functionality for high level languages. However there's a good chance that existing assembler modules are still used.
• Dumps. Assembler continues to be a requirement for reading system dumps. However most sites today simply don't do it. System dumps are ignored, or forwarded to the relevant vendor. Advances in Language Environment, CICS and IMS produce formatted dumps that are easier for non-assembler programmers to read. And dump analysis programs such as IBMs Fault Analyzer and Compuware AbendAid are common in many sites.
• Documentation. This no longer applies, and software products are almost always distributed as object code, with accompanying documentation. Only super-nerds would consider working through the IMS ADFSSRC dataset.

So the reasons have diminished, but not disappeared. And there are other good reasons why assembler may still be the best choice. For example:

• Performance. In most cases, assembler continues to outperform high level languages. So an assembler routine may save significant CPU seconds. For example, many sites use a high-speed assembler date routine rather than use slower supplied services such as CICS ASKTIME or Language Environment CEEGMT/CEELOCT. In one site, I saw a home-grown system acting as a gateway to IMS for their core applications. Because of the traffic loads involved, assembler-level performance was a must.
• Systems Routines. Some system routines and functions are only provided in assembler. For example, IBM supplies the assembler macro RACROUTE for user and security authentication. Other languages have only limited options in this area, relying on APIs provided by other systems such as the CICS QUERY SECURITY service.
• If you're using control blocks managed by z/OS or other software, then assembler will be your best choice. IBM supply assembler mapping macros for many control blocks. However they are not available in any other language.
• Functionality. Some things can only be done in assembler. For example, you may need a 'glue' routine to allow two non-compatible routines to communicate. This could be a legacy non-XPLINK program called from a new XPLINK routine, or an old 24-bit routine called from 31/64 bit programs.

To put this in perspective, it is rare that I won't use my assembler skills during a client project. Here are some examples:

• Updating an existing heavily-used assembler routine to improve performance and reduce CPU.
• Analysing existing assembler routines to determine if they are still required today.
• Create a more efficient assembler module to replace IBM IDCAMS DCOLLECT for DASD management.
• Analyse a suspicious module in the APFList.
• Create a routine to process DB2 Package Accounting SMF records.

Assembler Skills Today

Assembler is hard to learn. It requires a good understanding of the computer architecture, and many of the nice features high level programmers take for granted aren't available. And that's before you try to come to terms with the myriad of assembler instructions: currently over 900, and increasing with every new generation of processor. Years ago computing courses included an assembler component, giving graduates a leg-up when tackling mainframe assembler. Today, assembler is rarely relevant, and computing graduates will be starting from scratch. Excluding course costs, I can't see a graduate becoming comfortable with assembler in less than 160 hours of study and practice, and it will likely take more.

So today, most staff with assembler skills learnt them decades ago. And probably will not have used them for years. Existing assembler routines usually continue to work without ongoing maintenance. In the unlikely case that there's a problem, it will probably be after a systems upgrade, and a quick re-assembly will fix the problem.

Software development companies, and companies continuing to perform major new mainframe software development, are perhaps a little different. They will require assembler skills to maintain existing assembler code, and to create new modules requiring functionality only available to assembler. However the chances are that these sites will minimise their assembler-capable staff, performing the bulk of new development in high level languages.

Conclusion

In most sites, no new assembler programs are created. The people with assembler knowledge are the senior systems programmers ready for retirement. They haven't written more than a few lines of assembler in the past 10 years, and rarely use their assembler knowledge in dump analysis or application programming. In these sites, it is difficult to justify in-house assembler skills. However, it is a brave site that continues to rely on assembler assets with no access to assembler skills. So a better idea may be to access to assembler skills only when needed from an external consulting or development company.

Sites and software companies continuing assembler development are different. They will need at least some high quality assembler knowledge resources: interal or external. Without these, legacy code will be at risk, and new code will often suffer in quality and performance.

David Stephens