Pitfalls of reusing storage with ATTACH(X)

So here's a little something that bit me, and it's something that I know, and has bit me before. Be careful if you reuse storage.

Some development shops have macros that set up CALL parameter lists in a particular area. Or maybe you've done that yourself. It's tempting to use that area for parameters passed to an attached program (PARAM, MF=(E,area)). However, if the attaching program uses this area again before your attached program has a chance to get it, the attached program will pick up whatever is there. So the pointer you expect , maybe to a program communications vector table, may wind up being something completely different, say a log process block. The famous IBM line "unpredictable results will occur" becomes prophetic. In my case, it was an S052-0101 error, which is a problem with LXRES. Now my PC was not executing LXRES, but because the loaded address came from not the expected area, whatever garbage was picked up was identical to LXRES.

A little caveat if you are playing with DCB= on LINK/LOAD

So, as we all remember, you can specify a DCB address for LINK/LOAD, which is an open BPAM DCB pointing at a PDS concatenation from which CSV looks for the requested load module. This makes LINK/LOAD (and CSVDYLPA) flexible and can help with debugging or a quick, temporary override.

Unfortunately, if you specify DCB=(r) and that register does not point to a DCB, you don't get a fancy return code saying the DCB was not a DCB. No, what you will probably get is a strange S0C4-0011 in CSVGETMD in the nucleus.

Moral of the story: if you are cloning code, and you use lots of register operands in your macro invocations, make sure you load all the registers.

Note: CSVDYLPA has additional checks on the DCB parameter and it will give return and reason codes.

Wrapping your own macro code around vendor-supplied macros without changing source

One of the great IBM z/OS performance and measurement gurus, Martin Packer, made a comment in a recent blog entry about he wished he could wrap his code around macros supplied from an external source. I told him that this was possible, and that I had recently done this with the IBM High Level Assembler Toolkit structured programming macros. In this case, I added support for using just name or !name for testing a bit flag in conjunction with a bit-flag-generating macro. The key is the OPSYN assembler command.

I will demonstrate how to do this using something I wish the DCB macro had that its ACB sibling has - the ability to use the label field as the default DDNAME=.

I apologize in advance for the crappy formatting; I still need to come up with some good formatting for the examples. Google's default doesn't do well. (Martin, yes, I still have your email with suggestions. :)  )

I will create CHS.MACLIB(DCB), which will call SYS1.MACLIB(DCB).

First, we clone the DCB prototype:

         MACRO

&NAME    DCB   &DDNAME=0,&MACRF=,                      FOUNDATION BLOCK* 

               &BFTEK=,&BFALN=,&EODAD=1,&RECFM=,&EXLST=0,     EXTENSION* 

         Snipped rest of prototype

And then we add our logic:

         PUSH  PRINT,NOPRINT         Obfuscate

         PRINT OFF,NOPRINT

DCB_     OPSYN DCB                   Change CHS.MACLIB(DCB)'s name

DCB      OPSYN ,                     DCB now refers to SYS1.MACLIB(DCB)

         POP   PRINT,NOPRINT         No more obfuscation

         LCLC  &N

&N       SETC  '&DDNAME'

         AIF   ('&N' NE '').GOTDD

&N       SETC  '&NAME'

         AIF   ('&N' NE '').GOTDD

         MNOTE 8,'Missing label or DDNAME'

         AGO   .EXIT

.*

.GOTDD   ANOP  ,

&NAME    DCB   DDNAME=&N,MACRF=&MACRF,BFTEK=&BFTEK,BFALN=&BFALN,       &

               EODAD=&EODAD,RECFM=&RECFM,EXLST=&EXLST,                 &

         Snipped rest of invocation 

.EXIT    ANOP  ,

         PUSH  PRINT,NOPRINT         Obfuscate again

         PRINT OFF,NOPRINT

DCB      OPSYN DCB_                  Now DCB refers to CHS.MACLIB(DCB)

         POP   PRINT,NOPRINT         No more obfuscation (again)

         MEND  

The magic is in the OPSYN assembler instructions. Assuming CHS.MACLIB is ahead of SYS1.MACLIB in the SYSLIB concatenation, our DCB macro is picked up first. During processing, we change the name of our DCB macro to DCB_, and then we tell the assembler that DCB from this point forward refers to whichever DCB it finds. Since our DCB is now DCB_, the assembler now burrows further into the concatenation and finds SYS1.MACLIB(DCB) when it gets to the DCB macro coded inside CHS.MACLIB(DCB), and the assembler now uses it. After the DCB invocation, OPSYN is used again to undo what we did at the beginning, so that subsequent invocations of DCB will use CHS.MACLIB(DCB).

It's a little bit confusing at first, but if you stick an MNOTE in your wrapper macro, or use MHELP and ACONTROL LIBMAC, you can see what the assembler is doing. And you'll find this can be a very powerful tool for certain situations, such as prohibiting usage of certain macro operands by developers.

SHARE experiences

(Cross-posted to the z390 Assembler blog.)

Well, I just discovered that the post I thought I made to this blog about presenting at SHARE was never published. No big worries, though, as I certainly posted it in a lot of places.


Last Tuesday, Feb 5, I presented at SHARE Winter 2013 in San Francisco, on z390, zCOBOL, zCICS, and the associated add-ons. This was my first time ever presenting at SHARE, or any user group at all. It was also my first attendance at a user group since, wow, 1989. (I am not counting my non-attendance at SHARE Summer 2012 in Anaheim, or the time I came down to SF to meet my boss at a Software AG user conference in the late 1990s.) it had been 18 months since Don Higgins presented on z390, and I thought that since SHARE was local, it would be a great opportunity to describe what is new, and what is coming.

I went in a bit nervous. The voice of my GA from my COMS 103 class at Sac State, Brie Adams, was whispering in my head on things not to do. I knew some friends of mine such as Ed Jaffe were attending. And then things got even more nervous. Not only was Mr. HLASM, Dr. John Ehrman, attending, but his successor. Sharuff Mousa (from Hursley) as well. And people I knew like Kristine Harper, and people I knew but had just finally met in person, like Rich Smrcina, Tom Conley, and Scott Fagen, were attending. And complete strangers as well. (I found out later that day that Mr. z/OS himself, Bob Rogers, wanted to attend but had a conflict. I think I would have died if he had made it.)

But onward I went. And I think I did pretty well. I handled questions, even having to answer some off the cuff. I made new contacts. I will admit that I haven't looked at the evaluations yet; I'm a bit scared to do so. And I probably was nervous some as well. Mary Anne Matyaz snapped a photo of me during my session, and my wife Cheri says I look nervous. I'm not surprised. (And having just looked again at the photo, I'm grabbing the chair.)

The rest of the day was a bit of a blur. Because of Mary Anne's gentle arm-twisting, I chaired a couple of sessions in the afternoon, and in one I finally met Kirk Wolf in person. Then I helped with some subterfuge and got my friend Chris Craddock (again, whom I had not met in person until he came to collect the badge) into the Expo. The next couple of hours were just tagging along with Chris and meeting even more folks whom I knew from the various mainframe-oriented mailing lists and Facebook. That evening was a CA-hosted party on the 45th floor, where I saw Meral Temel (sadly, I had no real chance to talk with her other than a quick "hello") and met Skip Robinson and Sam Knutson (again, finally in person!). And I'm sure I met a couple of others, and I apologize for forgetting already.

A big thanks to Crash Craddock for letting me crash at his place.

Unfortunately, unless the Braves are playing the Sox interleague that week, I won't be in Boston. But Winter 2014 is in Anaheim and I am already making plans. I hope to see you there!

My presentation can be downloaded from the SHARE web site (Session 12252), or if you are patient it can be loaded from the z390 or Cat Herder Software's web site later this week. (I will update with links when they are ready; I have to fix a couple of types I found.)