Conditional Assembly Language…
If you’ve ever read or written a macro you have no doubt at least seen conditional assembly language. It’s all that AIF and AGO stuff that forms a sort of ‘program’ within the macro so that it can generate code or whatever depending on whatever the input parameters are.
What’s really cool though is that it is not just limited to macros, you can use it within open code as well. So you might ask ‘why would you need to do that?’ but even if you don’t ask, here’s one interesting situation that came up recently.
I had some code that used a macro to generate a DSECT to map a control block. However we were switching version of the product that supplied the macro and a field within the macro had changed names even though it’s content had not. The result was that my code would only assemble with one version of the macro since with the other one it would get a not found error for the changed label. Since I did not want to have to co-ordinate my source code change with a build tool change the problem I had was how to make my source code support both versions of the macro and DSECT that it generated?
In case you have not guessed, the answer is conditional assembly language.
Here’s an example.
The old macro/DSECT:
MYMACRO SOMENAME DSECT MYFIELD DS CL8
The new version of the macro/DSECT
MYMACRO SOMENAME DSECT NEWNAME DS CL8
So my code originally looked something like this:
USING SOMENAME,R2 CLC MYFIELD,=CL8'AAAAAAAA'
Obviously if I switch to the new macro library, my assembly will fail since the field ‘MYFIELD’ is no longer defined within the DSECT.
However, what you can do is to test to see if the variable ‘MYFIELD’ is defined and if not then conditionally change the code that gets assembled. Thus:
USING SOMENAME,R2
AIF (T'MYFIELD EQ 'U').NEWMAC
CLC MYFIELD,=CL8'AAAAAAAA'
AGO .CONT
.NEWMAC ANOP
CLC NEWNAME,=CL8'AAAAAAAA'
.CONT ANOP
The AIF tests to see if the ‘type’ specification for the field MYFIELD is ‘U’, that is undefined. If it is undefined that means it has not been seen by the assembler (yet) so jump to the label .NEWMAC and continue to generate the code from there, which of course generates the code using the new field label of NEWNAME.
If the field MYFIELD is not ‘undefined’ then the assembler generates the code using the old field name, MYFIELD and then jumps (AGO) to the label .CONT to continue the assembly.
As a result, no matter which version of the macro library I am using, my code still assembles and works correctly.
There are other ways of achieving the same effect; For example by using the conditional assembly language to control the redefining of the old or renamed symbol to a common name and using that common name in the open code.
One gotcha though to be aware of. The macro/DSECT has to be defined in the source code BEFORE the conditional assembly code. If it is defined after the conditional code then, since the assembler has not seen either field at the time it encounters the test for the field being defined, it will always treat it as being undefined which would cause an assembly error when using the old macro/DSECT library because it would generate the code to use the new field name.
Share…
I shall be at Share in Orlando next week so if you seem me (picture on my about page), please do say hi.
Tools – COPYMBR
During my daily work I often need to copy members from one PDS to another. The Partitioned data sets are always the same ones, just different members. I could use the ISPF Move/Copy Utility screens but it quickly gets tiresome to have to keep entering the data set and member information into the screens.
Since I’ve got my REXX library allocated to SYSPROC so that I can run execs from it directly using the TSO execname command on the ISPF command line I put together the following exec called COPYMBR to automate the process:
/* rexx */
/* exec to copy a member from one pds to another */
parse arg frommbr tombr '/' repl
tombr = strip(tombr)
upper repl
if frommbr = '' then do
say "Syntax is COPYMBR from_mbr [to_mbr] [/r]"
say "Specify to_mbr name to rename the copied member"
say "Specify /r to replace the member in the target PDS"
return 0
end
if tombr='' then tombr=frommbr
if length(frommbr) > 8 then do
say "Source member name greater than 8 chars"
return 0
end
if length(tombr) > 8 then do
say "Target member name greater than 8 chars"
return 0
end
address ispexec
"CONTROL ERRORS RETURN"
indsn="'"userid()||".LOAD'" /* Source PDS */
outdsn="'"userid()||".LOAD2'" /* Target PDS */
"LMINIT DATAID(IN) DATASET("indsn") ENQ(SHR)"
"LMINIT DATAID(OUT) DATASET("outdsn") ENQ(SHR)"
opt=''
if repl = 'R' then opt = "REPLACE'
"LMCOPY FROMID("in") FROMMEM("frommbr") TODATAID("out") ",
"TOMEM("tombr") "opt
lastcc=rc
ins=''
if lastcc = 0 then nop
else if lastcc=12 then do
if frommbr <> tombr then ins = 'as '||tombr
say frommbr' not copied'||ins
say tombr' already exists on target library.'
end
else if lastcc=8 then do
say frommbr' not found in source library.'
end
else do
say 'rc from LMCOPY='lastcc
end
"LMFREE DATAID("in")"
"LMFREE DATAID("out")"
return 0
You can edit the lines marked “Source PDS” and “Target PDS” to specify any compatible load libraries. I just used my LOAD and LOAD2 libraries as an example.
The general syntax of the COPYMBR command on the ISPF command line is then:
TSO COPYMBR member_name [new_name] [/r]
Where:
member_name is the name of the member to copy from the source PDS
new_name is optional and is the new name to assign to the member on the target PDS. If not specified it defaults to the same name as the source member.
/r tells the exec to replace the member (or new member name if renaming) on the target PDS.
Note that when the copy is successful, the exec does NOT output any messages so there’s no need to press the enter key to clear a message except when there is something wrong.
Examples:
TSO COPYMBR MYPROG1 /r
Copy MYPROG1 from the source PDS to the target PDS and replace any existing version.
TSO COPYMBR MYPROG1 MYPROG2
Copy MYPROG1 from the source PDS to the target PDS and rename it to MYPROG2. Do not do the copy if MYPROG2 already exists on the target PDS.
TSO COPYMBR MYPROG1 MYPROG2 /r
Copy MYPROG1 from the source PDS to the target PDS and rename it to MYPROG2. Replace any existing version of MYPROG2 on the target PDS.
Customizing SYSPROC at TSO Logon time
One of the things I like to do is to allocate my own REXX library to SYSPROC at TSO logon time so that I can execute REXX commands simply by typing in “TSO command_name” on the ISPF command line.
On the TSO logon screen I have a command setup to invoke a REXX exec that will do that for me:
BEFORE just says to allocate my REXX library before the existing allocations so that anything in my library overrides anything in the existing allocation with the same name (useful for testing changes to existing EXECs). Specify ‘AFTER’ or let it default to allocate your library AFTER the existing allocations.
This is the exec (called ALLOCREX in the above screen shot):
/* rexx */
/* logon exec to concat my rexx library to SYSPROC so that */
/* I can run my own rexx commands easily without having */
/* to specify the dataset name. EG TSO MYEXEC */
/* */
parse arg opt /* BEFORE or AFTER (default) */
lib=userid()||".REXX" /* dsn of rexx lib to alloc */
if x> 4 then do
say "Unable to locate '"lib"'."
say 'SYSPROC alloc not changed.'
signal exit
end
rc=ddns('SYSPROC') /* get current SYSPROC allocation */
/* extract dsns and check for my rexx lib already alloc */
list=''
comma=''
do while queued() > 0
parse pull dsn
if dsn=lib then do
say lib 'already concat to SYSPROC.'
say 'SYSPROC alloc not changed.'
signal exit
end
list=list||comma||"'"||strip(dsn)||"'"
comma=','
end
oldlist=list
/* add my rex lib to the list and realloc the DD */
if opt = 'BEFORE' then do
list="'"lib"',"||list
end
else do
list=list||",'"lib"'"
end
"ALLOC F(SYSPROC) DATASET("list") SHR REUSE"
allocrc=rc
if allocrc <> 0 then do
say 'Alloc of SYSPROC faiuled with rc='allocrc
say 'Restoring original allocation'
"ALLOC F(SYSPROC) DATASET("oldlist") SHR REUSE"
end
/* queue an ISPF command so this exec can end */
exit:
queue 'ISPF'
return 0
/*---------------------------------------------------------*/
ddns: procedure
/*---------------------------------------------------------*/
/* Find dsns allocated to a specified ddname */
/* Output returned on the stack */
/*---------------------------------------------------------*/
/* */
parse arg ddname
upper ddname
x=outtrap("out.","*","noconcat",1)
address TSO 'listalc status'
if out.0 = 0 then do
return 0 /* Nothing found */
end
foundDD="N"
do i=1 to out.0 by 2
parse var out.i dsn .
j=i+1
ddn=strip(substr(out.j,3,8))
if ddn <> "" & ddn = ddname then foundDD="Y"
if ddn <> "" & ddn <> ddname then foundDD="N"
if foundDD = "Y" then do
push dsn
end
end
return 0
Wow, it’s been a year already…
I know I have not posted anything here for almost a year but I have not died! I’ve just been very busy learning new products and product architectures.
I have to say though that it has been are really fabulous year for me that I have thoroughly enjoyed. With a bit of luck (and time) I’ll get back to posting a few things from time to time here.
A time for change…
It’s been a lot a fun working at IBM and I’ve had the opportunity to work with some truly amazing people and software products over the years but there comes a time when you have to look beyond the ‘safe’ zone and to take that leap of faith. It’s been quite a while since I’ve taken this sort of leap but I have to announce that today, I have left IBM and will be starting a new adventure very soon.
I hope to continue to post to this blog but obviously the topics for the most part will change although they will continue to be mostly about mainframe topics. So I hope that you, my few readers, continue to find something of interest here that will lure you back from time to time.
Update to the Enhanced 3270 User Interface Security Requirements
In this post I mentioned that the recent OB700 IF1 update had added additional security checking for KOBASE and 04SRV resources and that without suitable RACF (or other security product) profiles to give the user read access to these resources, users would not be able to log on to the Enhanced 3270 UI.
PTF UA71750 is now available and removes the security checking on these resources. As a result, these additional security profiles are no longer required.
New to PARMGEN…?
If you need to know more about the PARMGEN configuration tool for the ITM z/OS environment, here are a couple of videos about it.
What is PARMGEN
Convert an ICAT RTE to PRMGEN and Upgrade the Products
Securing the Enhanced 3270 User Interface with RACF and OB 700 IF1
In this post I talked about securing the enhanced 3270 User Interface with RACF
Since then a new level of the base code (FMID HKOB700) called Interim Feature One (IF1) has arrived in the form of PTF UA69877. But before you go off and apply that, don’t! Instead apply UA70618 which fixes some issues with the original code that may impact certain users.
In the hold doc (you do read all the hold doc don’t you!) for UA70618 are instructions on setting up new RACF profiles that may be needed if you are using security to protect the Enhanced 3270 User Interface environment. These are the new resources being checked:
KOBUI.USER.COMMAND.<command_name> KOBUI.ADMIN.PREFS.AUTOUPDATE KOBUI.ADMIN.LISTUSERS KOBUI.ADMIN.TRACE.UI.<trace_type> KOBUI.ADMIN.TRACE.INTERNAL.<trace_type> KOBUI.ADMIN.USEHUB.<hub_name> KOBUI.ADMIN.MEMBER.WRITE.<dd_name>.<member_name> KOBUI.ADMIN.ITM.<hub_name>.SERVICEINDEX KOBUI.ADMIN.ITM.<hub_name>.<servicepoint_name>.SERVICECONSOLE KOBUI.ADMIN.ITM.<hub_name>.<servicepoint_name>.SOAPCONSOLE SYSTEM.<managed_system_name>.<table_name>
You could protect these with the following RACF profiles:
PERMIT KOBUI.USER.** PERMIT KOBUI.ADMIN.** PERMIT SYSTEM.**
Recently I came across a problem where a customer needed additional RACF profiles setting up in order to log on to the Enhanced 3270 UI. These are:
KOBASE.** O4SRV.**
The easiest way to add these would be with a UACC or READ but your installation standards may require a different implementation. I believe a tech note will be forthcoming on the issue soon.
This particular user had a default profile of * in the RACF class with a UACC of NONE so anything that was not specifically permitted was rejected. If you do not have such a profile in the RACF class used by the Enhanced 3270 UI then the default action is to allow the request if a profile does not exist which basically allows anyone to do anything unless you specifically lock it down. That approach results in the least amount of work to secure the Enhanced 3270 UI environment.
Arduino project update…
Having ‘completed’ my Arduino ‘stomp box’ project I immediately realized that I needed it to do more (of course!). Originally my intention was to have one switch control the wet/dry mix on my effects unit and the other to control the selected patch, flip flopping between them, all pretty simple stuff. But then I thought about ‘soloing’. My MIDI keyboard controller (a keytar) does not send MIDI volume information, nor can I program it to do so, so I needed some way to be able to easily switch from normal playing mode (medium volume) to solo playing mode (boosted volume). Guitar players usually have a pedal they just stomp on to boost the signal to a pre set level for solos so I figured it’d be useful to be able to do that using my stomp box.
The two switches gives me four conditions, although because you cannot really use the normal (I.E. not pressed) state that leaves three conditions. Left button pressed, right button pressed or both pressed. Since I was using the first two conditions already that left the ‘both buttons pressed’ condition to use to switch between normal and solo mode.
Well that turned out to be a lot more complex that you’d think. I could not simply look at the switches and wait for them both to be pressed because the chances of my foot hitting them both at the exact same time is pretty much nil so the code would always detect one or the other on it’s own initially and I was using that state to switch the mix or patch. Waiting to see if the other switch was pressed was not really an option because how long do you wait?
What is interesting though is that a binary switch has more than just an on or off state. It also has the ‘changed state’ condition. I.E. It was open but is now closed and it was closed but is now open, often referred to as leading and trailing edge (of a square wave which is what you’d see on an oscilloscope if you tracked the voltage on the switch contacts).
So what I did was to switch the mix and patch selects to work on the trailing edge signal, that is when you release the switch and I made the volume switch occur on the leading edge, that is when both switches closed. That way I could distinguish between the events quite easily.
But wait, there’s more!
Originally I hard coded the normal volume level but than I thought, well what if I want to change it for a particular setup (I figured leaving the ‘solo’ setting at max all the time was fine), I’ve only got two switches and I’ve used them all and how do I indicate what is going on to the user, I’ve only got two LEDs?
Well it turns out a switch can have yet another state and that is how long it has been pressed. Since the mix setting now triggers on the switch release, I can now time how long a single switch has been pressed and if it exceeds a certain time (I figured five seconds was a good value, not too long, not too short) then I put the unit into ‘program’ mode. To indicate this to the user I made the LED next to the switch flash.
Once in ‘program’ mode I can listen for the other switch being pressed and each time it is pressed, increase the ‘volume’ setting. Rather than have the user step through 127 values I figured having ten steps would be enough that I convert into MIDI signal levels by multiplying by 12 which gives me ten settings of 12 through 120.
To indicate the current volume ‘setting’ I make the second LED flash using a slow setting for the lowest volume and increasing the speed for each click up to ten at which point it cycles around back to the lowest setting.
Pressing the first switch again takes it out of program mode and saves any new volume setting.
But wait, there’s even more!
The chip on the Arduino has 1024 bytes of EEPROM that can be used to save data even when the device is turned off. So after setting a new volume I now save the setting in the EEPROM so that when the device is switched on I can restore the volume setting from the save value in the EEPROM. I also flash the second LED one to ten times (depending on the save volume level) at switch on to indicate to the user (me!) the current ‘normal’ volume level in use.
Summary
I have been very impressed with the quality of the Arduino IDE and the programming libraries available for it. In the past I have done micro processor (PIC) programming but used assembler. That’s fine but you have to do EVERYTHING yourself and testing can be ‘interesting’ to say the least. Writing in C and using existing libraries made development and testing very easy and speedy, especially when used in conjunction with the Arduino IDE’s ‘serial monitor’ and loads of debugging messages in the code (wrapped in #if defined statements so I can easily remove them for the ‘live’ code).
If I have on criticism of the Arduino IDE (or rather the doc) it is that as well as the extensive Arduino specific libraries you can also use code from the AVR project, which I wanted to do for the EEPROM support since it has more function (block read/write) than the Arduino library. However even though the AVR library is included in the Arduino IDE, it is not very well documented in the Arduino doc. It was only by chance (thank you Google) that I even came across the AVR library and I then spent quite a long time trying to figure out how to add it to the Arduino IDE before I found that it was already there.
