Update to the Enhanced 3270 User Interface Security Requirements

December 17, 2013 Leave a comment

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…?

December 3, 2013 Leave a comment

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

October 16, 2013 2 comments

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.

Categories: E3270UI, ITM, Mainframe Tags: ,

Arduino project update…

October 14, 2013 Leave a comment

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.

Categories: Uncategorized Tags: ,

Using the SDSF REXX interface – Part 2

October 12, 2013 Leave a comment

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
Categories: Mainframe, REXX Tags: ,

Using the SDSF REXX interface – Part 1

September 24, 2013 Leave a comment

I thought I’d post some of the REXX execs I have written that use the SDSF REXX interface. This first one determines if a job is executing, either on the specified lpar if passed in or anywhere in the sysplex if not (subject to shared JES spool limits). It returns a return code and, if executing, the lpar the job (or stc) is executing on separated by a space which you can then parse out.

/**REXX**************************************************************/   
/*                                                                  */      
/* JOBSTAT - Determine if a job is executing or not                 */   
/*                                                                  */   
/* Input args:                                                      */   
/*                                                                  */   
/*  Jobname - Required.                                             */   
/*  sysname - Optional. If specified will only look for job on that */   
/*                      system.                                     */   
/*                                                                  */   
/* Output:                                                          */   
/*  0 - Job is not executing (on requested system if specified)     */   
/*  1 - Job is executing + sysname of system job is running on      */   
/*                                                                  */   
/********************************************************************/   

parse arg jobn , sysname                                                 
upper jobn                                                               
upper sysname                                                           

Address 'TSO'                                                           

IsfRC = isfcalls( "ON" )                                                 

saved_delay=ISFDELAY                                                     
ISFDELAY=0                                                               

executing=0                                                             
executing_on=""                                                         

address SDSF "ISFEXEC ST "jobn                                           

if sysname <> "" then do                                                 
   do i = 1 to jname.0                                                   
      if queue.i = "EXECUTION" & actsys.i = sysname then do             
         executing=1                                                     
         executing_on=actsys.i                                           
         end                               
      end                                 
   end                                     
else do                                   
   do i = 1 to jname.0                     
      if queue.i = "EXECUTION" then do     
         executing=1                       
         executing_on=actsys.i             
         end                               
      end                                 
   end                                     

ISFDELAY=saved_delay                       

IsfRC = isfcalls( "OFF" )                 

return executing" "executing_on

Using the above exec to determine if a job is executing on the local lpar:

/**REXX**************************************************************/   
/*                                                                  */  
/* Call jobstat to see if job is running in the local system        */
/*                                                                  */   
/********************************************************************/  

sysname=MVSVAR('SYSNAME')   /* local sysname */

parse value jobstat("MYJOB",sysname) with executing lpar 
if executing then do                               
   /* do 'executing' stuff here */ 
   say 'Job is executing'         
   end                                             
else do                                           
   /* Do 'Not executing' stuff here */  
   say 'Job is not executing'                                 
   end 

return 0

Using the above exec to determine if a job is executing in the sysplex and on which lpar:

/**REXX**************************************************************/   
/*                                                                  */  
/* Call jobstat to see if job is running anywhere in the sysplex    */
/*                                                                  */   
/********************************************************************/  

parse value jobstat("MYJOB") with executing lpar 
if executing then do                               
   /* do 'executing' stuff here */ 
   say 'Job is executing on '||lpar         
   end                                             
else do                                           
   /* Do 'Not executing' stuff here */  
   say 'Job is not executing'                                 
   end  

return 0
Categories: Mainframe, REXX Tags: ,

Arduino project finished…

September 15, 2013 Leave a comment

The missing components turned up so I spent a day building the MIDI interface board. Figuring out where to place the various connectors and components on the prototyping board so that the connectors were not blocked by the sides of the box it would all live in was far harder than writing the code or designing the circuit. Once I had it all hooked up I tried it and…. nothing! Well, the switches worked as did the LEDs but I was not getting a MIDI signal out of the box, or if I was the other end was not detecting it. When I looked at the circuit for the commercial MIDI interface board I had it was a lot simpler than my over engineered effort so after some hesitation I ripped out the output circuit from my board and replaced it with a much simpler version based on the commercial units circuit (basically one wire and a couple of resistors, no transistors). Swapped over the output cables to account for the circuit changes and tried it…. nothing again!

Now  had been very careful about hooking up the output wires to the MIDI connector the right way around. Seems I was not careful enough! On a whim I swapped them and of course it worked. It was probably OK the first time, just the had the wires the wrong way round but at least it works now.

This is what the inside of the project looks like:

StompBoxInside

As you can see pretty cramped. The board you can see is the MIDI interface board I made. The Arduino is underneath that screwed to a piece of board that is then glues to the case to hold it in place and insulate it from the metal box.

I always think that it is a shame to hide all the electronics as so much effort goes into creating it. In some ways it’s like programming, you can put a lot of effort into making some code as elegant as possible but in the end, all people care about is ‘does it work’.

So with that in mind, this is what the completed project looks like:

StompBoxFinished

The power switch is on the other side of the box but that’s it. The left button controls the bypass on the effects unit and the right button switches between two patches. The LEDs just indicate the current setting that is selected for each switch. All pretty simple.

Time to go play!

Categories: General Stuff Tags: ,