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.
Using the SDSF REXX interface – Part 2
Here’s another REXX exec using the SDSF REXX interface. This one will issue a command to the local system.
/**REXX**************************************************************/ /* */ /* ISSUCMD - Issue a command. */ /* */ /* Input args: */ /* */ /* Delay - # secs to wait for command completion */ /* Command - Command to issue (do not need leading /) */ /* */ /* Output: return code from the command. */ /* */ /********************************************************************/ parse arg delay, command Address 'TSO' IsfRC = isfcalls( "ON" ) saved_delay=ISFDELAY /* save curr delay */ ISFDELAY=delay /* Set delay time */ address SDSF "ISFEXEC '/"command"'" saverc=rc ISFDELAY=saved_delay /* restore delay */ IsfRC = isfcalls( "OFF" ) return saverc
Using the above command to start a started task on the local system:
/* REXX */ rc=ISSUCMD(2,"S CICS1") return 0
