For the entire life of z/OS, over 50 years, the operating system has relied on skilled assembler programmers to maintain and enhance the system.  Assembler skills are still almost required to initially configure and customize z/OS.  This is true for doing things like specifying the separator page on print out, coding up a logo for the logon screen, or time setting limits.

In the last couple releases we have begun to introduce capability that allows customization without requiring assembler skill.  This includes introducing policy based parmlib support such as SMFLIMxx which lets you set many of the memory limits in z/OS using a declarative style rather than having to code assembler.  This parmlib member got a little smarter in z/OS 2.4, we also added support for some of the RACF requirements for assembler code in z/OS 2.3 and we are planning to support a general policy based facility in JES2 in z/OS 2.4.  None of these mechanisms remove the existing assembler exits but instead provide you with an alternate way to specify some of the more common items.

The idea being that one should eventually be able to administer a z/OS system without requiring assembler programming skills.  But there is still a need to be able to extend the operating system by our independent software vendors.  In that case we are also concerned about the ongoing assembler skill and to that end have begun shipping C header files for common z/OS control blocks.  This support is available starting in z/OS 2.4 and ships the headers in both a PDS dataset as well as in the zFS file system.  Initially in z/OS 2.4 we are shipping a subset of headers that will cover SMF records and some system data areas.  Over time we would hope to be able to expand that to more of the mapping macros shipped in SYS1.MACLIB and SYS1.MODGEN.

I’d be interested in knowing if our approach of reducing assembler skill requirements is something that you see value in.

Several releases back z/OS JES2 introduced the job correlator.  This is a string that can be used for several things.  First it acts as a longer jobname.  When you submit a job with the job correlator you can select up to 32 characters additional data to be added to the job.  You can select a job or query it by correlator.  You pick a name and then you select by that name.

JES2 will carry the name in the spool structures for the job and you can either continue to look for the jobname and optionally the jobnumber… or you can do a query using the correlator.  It is your responsibility to make the correlator unique if that is a requirement you have.  This is reasonably easy… generate a name, query for the name and if not found it is unique.

This can be particularly useful if you have your own job scheduling package and you want to be able to generate your own job naming and locate the jobs yourself.

The job correlator is also queryable in SDSF, as well as through the z/OSMF REST JOBs API and of course the normal assembler subsystem interface (SSI) of z/OS.

To specify the job correlator you can modify the batch job and add UJOBCORR= on the job card to the value you want.  If you don’t want to modify the job, you can specify the JES symbol SYS_CORR_USRDATA on the invocation of the internal reader DD statement of the submitting address space.  The z/OSMF REST JOBs API can also assist with that.

Have you ever used the job correlator?

For most z/OS system programmers one of the “goto” tools is SDSF.  Some have said a day doesn’t go by without them going into SDSF.  For many non-system programmers they also have access to SDSF but often a small general use subset.  The SDSF user interface is available in a 3270 (green screen) form as well as in a browser based format in z/OSMF.  There is also a REXX programming interface that is heavily used and a much less used JAVA programming API.

Being able to see the processes (address spaces) and what they are doing (DA – Display Active), what resources they are consuming, is a key feature of SDSF.  This data is displayed in tabular form and can be sorted, filtered and otherwise manipulated.  But you can also look at the queues of work arriving and waiting to run (I – Input), work that has completed(S – Status), and the output that work produced as it is waiting to be processed (often printed, using O – Output).   There is a special queue for output or jobs that have completed but are ‘held’ meaning they are there to be seen on request (H – Held).   This was arguably the first thing that the SDSF product showed and is also what most operations and developers use.

Beyond seeing the data you can also manipulate the data.  For example you can see a held job and if you want to get rid of it you can purge it with a single keystroke.  You can also print output if and delete it or even print it and keep it in the held queue.  One the coolest things is SJ, which allows you to look at a job, get the JCL back and edit it and resubmit it.

Beyond this kind of work SDSF lets you look at many other parts of z/OS.  One of my favorite commands is the SYS command which will give you a LOT of information about the system.  If you are running in a sysplex then the SYS command will display one row per system and you can compare them.  There are many more detailed subcommands under SYS that can show you more detail.

In recent releases of SDSF there have been many new primary commands added which you may or may not have access to.  The main menu is a scrollable menu and there are options to show or hide options that you don’t have access to.

What is your favorite part of SDSF?  Do you have suggestions for new capability?  Leave a comment…

z/OS 2.4 which was previewed in February of 2019 contains a new feature called Container Extensions.  It is entitled with z/OS 2.4 which means it is part of the z/OS deliverable.  It gives you the ability to run any Linux on z Docker container on z/OS.  It runs in a started task in an address space just like any other middleware service on z/OS.  This means it fits into your existing system without requiring the definition of a new LPAR (logical partition) and can use the hardware that the existing z/OS is using.  This means you don’t need to define new networking hardware, or new disk.

You can read more about it here – https://www.ibm.com/support/z-content-solutions/container-extensions/

I made a short video here https://youtu.be/xOuoTqaBqqU

There is also a podcast here http://terminaltalk.net/PodcastGenerator/?name=gary_puchkoff_-_z_os_container_extensions.mp3

A couple articles as well http://ibmsystemsmag.com/mainframe/trends/z-os/z-cx/ and http://ibmsystemsmag.com/mainframe/hot-topics/container-extensions-faq/

I will write more about z/OS 2.4 once we announce the GA.