Microwave Popcorn, REXX and ISPF

(Originally posted 2013-01-21.)

To me learning is like Microwave Popcorn.

Specifically, turning

into

Part of the fun of making popcorn is watching the bag and listening to the poppings: As each kernel pops it pushes the bag out.

And so it is with learning: Every piece of knowledge contributes to the overall shape.

Anyhow, enough of the homespun “philosophy”. 🙂

I was maintaining some ISPF REXX code recently and it caused me to come across two areas where REXX can really help with ISPF applications:

• Panel field validation.
• File Tailoring

The introduction of REXX support is not all that recent – I think z/OS R.6 and R.9 were the operative releases – but I think most people are unaware of these capabilities.

I’m not an ISPF application programmer so if you want the technical details look them up in the ISPF manuals. But here’s the gist of why you might want to consider them.

Panel Field Validation

On one of our ISPF panels we have eight fields that together represent a time/date range. You can (with VER(), as you probably know) check these fields – two sets of year, month, day, hour, minutes – have numeric values and aren’t blank. I don’t think you can check things like whether the end date is after the start date, or whether these two dates are before today. For that you need REXX:

With *REXX in the )PROC section of the panel (terminated with *ENDREXX) you can inject REXX code. If you set variable zrxrc to 8 (and set zrxmsg to an appropriate ISPF message number) you can fail the validation. If you set zrxrc to 0 you can pass it.

Of course you might be in a position to do this all in the REXX that causes the panel to be displayed in the first place. But there are two reasons why I think you’d want to do it in the panel definition itself:

• It’s a lot simpler than having the driving REXX redisplay the panel if the fields don’t validate.
• Keeping all the field validation logic together – VER() and REXX – is much neater.

But you have the choice.

File Tailoring

Again driven by REXX, the code I maintain uses ISPF File Tailoring to create JCL from skeleton files, based on variables from ISPF panels.

You can write some quite sophisticated tailoring logic without using REXX. But with REXX you can do so much more.

(My first test case used the REXX strip() function to remove trailing blanks. Of course you can do that with )SETF without REXX.)

If you code )REXX var1 var2 … then some REXX then a terminating )ENDREXX you can use the full power of REXX.

In the above var1 etc are quite important: If you want to use any of the File Tailoring variables (or set them in the REXX code) you have to list them.

Note: You can use say to write debugging info to SYSTSPRT.

I don’t believe you can directly emit lines in REXX but you could set a variable to 1 or 0 and use )SEL to conditionally include text.

Again, you could perhaps do some of this in the REXX that calls File Tailoring. But I’d prefer as much of the generation logic as possible to be in the one place: The File Tailoring skeleton. This is particularly true of variable validation when you consider you can use )SET in the skeleton to set the value of a variable – after the validation code has run.

---

So these two items – panel field validation and file tailoring – were areas I unexpectedly found myself researching. I won’t claim they’re core to my “day job” or particularly profound but certainly they proved handy. If you find yourself developing with ISPF facilities they might save you a lot of time.

And certainly I feel my grasp of ISPF is that much better – but maybe because of the 2000 lines of ISPF REXX I reformatted and adopted in the process. 🙂