Archive for the ‘Uncategorized’ Category

A Little bit of History…

September 22, 2020 Leave a comment

I came across these gems from my early career while sorting out some old filing boxes.

S/360 JCL Reference, circa 1972.

S/370 Reference Summary, circa 1976

Categories: Uncategorized

Linux, Windows and related fun…

April 25, 2020 Leave a comment

So let me make this clear. I am NO Linux expert, in fact I barely touch it. I have a web server running an old version of SuseLinux under my desk that I NEVER touch. The web site is just static pages, easily updated simply by replacing them and it works so why mess with something that is not broken!

That said, my wife recently ‘donated’ here old desktop PC to me as she was not using it any more. It’s a decent machine (DELL) but running Windows 10 it was sooooo sloooooow it was painful to use. So I decided to put Linux on it as I had something that I wanted to run on it long term and the problem with Windows is that, in its wisdom it periodically just updates itself and reboots the PC.

So, I downloaded the latest OpenSuse iso, burnt a CD and installed it. Well, after about two days of fighting with it, I installed it!. Most of the installs were because I’d configure it, decide that was not what I wanted (Figuring out which desktop to use was the worst, settled on Gnome in the end but only after about four different attempts at the install) and so it was just easier to wipe it al out and start again.


So, now to the whole point of this post.  My workspace is pretty large (it’s actually made from a kitchen counter top) but also pretty cluttered so having yet another screen, mouse and keyboard on there was not really an option.

My primary monitor had a spare VGA input so I used that but I still had to switch the display over and put the mouse/keyboard on my desk while I used the Linux box and picking up the wrong mouse or typing on the wrong keyboard soon got annoying.

So I looked into remote access.

At first I looked at using X11 but after a lot of messing and experimenting I decided it was messy to set up, still needed a lot of knowledge to use and really only brought individual apps over to the Windows desktop, not the whole Gnome desktop. I am no power user so I need all the help I can get and configurig individual Linux apps to run via X11 on my Windows desktop just seemed like a lot of extra work!

So I opted for VNC which gives you the full desktop experience.

Now you’d think that this would be easy and like all things, once you know how, it is but getting to that stage still took a couple of days! So this is the output from that ‘learning’ experience.

I am running Windows 10 and OpenSuse Leap 15.1 so this information should work for that configuration but like all software, as it moves forward (for better or worse!) who knows how long it will stay valid. Still…

One Time Setup Stuff

So first off, on the Linux box, using Yast, in in Network Services Remote Administration (VNC) , I set:

Allow Remote Administration with Session Management
The alternative was:
Allow Remote Administration without Session Management

I have no idea how that changes things, except perhaps in relation to sessions staying active when I disconnect the remote VNC session.

So then I used Putty on the Windows box to connect to my Linux box, LINBOX:

I set:

Hostname LINBOX Port 22
Under Connection:SSH:Tunnels add
Source port 5901
Destination LBOX:5901

I then saved that as a profile for future use.


I needed to do this next bit because up to this point, I could connect with VNC to my Linux desktop but all I got was a black screen. So for this next bit of the setup I needed to edit a file on the Linux box as a root user but rather than login as root, apparently never a good idea, I logged in as myself then did the following:

sudo vncserver                      This will start session with ROOT authority (enter root password when prompted)
Note session number or use vncserver -list to list sessions numbers (should be only one at this stage!)

Back on Windows I launched my VNC viewer (Tightvnc in my case) using host:port (so it was LINBOX:2) in my case
You will connect as root so enter root password when/if prompted.

This put me into my Gnome desktop on the Linux box.

I then selected the files application from the application pull down on the desktop menu and navigated to:


I then right clicked on custom.conf and selected edit (so you are now editing this file as a root user).

Locate [xdmcp] and just below it add this line:

Then save the file, exit the files application and
logoff as root (top right corner of screen)
End vnc session (close the widow)

Now back in the putty command window, restart xdm by entering:

sudo systemctl restart xdm

Now kill that vncserver process (the one that was using root) with

vncserver -kill :n n was 2 in my case (see above)

And that’s it for the one time setup stuff.


Regular Logon

You should now be able to VNC as a regular user to your desktop (Gnome in my case) as a regular user as follows:

Start putty as before and select the same LINBOX config options

Hostname LINBOX Port 22
Under Connection:SSH:Tunnels add
Source port 5901
Destination P390:5901

Login with your user id and password
vncserver This will start session as a normal user. NOTE NO SUDO command before vncserver.
Note session number or use vncserver -list to list sessions

Launch VNC Viewer or Tightvnc using host:port (so LINBOX:3 if the session number from vncserver was 3)
Enter YOUR password if required

And you should be good to go!!!

Also note that at this point you can close the putty window (type exit) and your VNC session will still work.

You can also just close the VNC window and come back to it later and it’s all still there, with apps open etc. No need to do the putty/vncserver steps, just use the same session number as before.

When you area ‘really’ done on your Linus desktop, open a putty window to your server as before and type:

vncserver -kill :n

Where n is the session number you were using. This will get rid of the background process.

I installed Regina Rexx and wrote a little exc to automate a lot of the regular logon stuff. It’s not perfect because it has hard coded passwords in it and currently only establishes a new session, cannot reuse an old one but it’s a start (and fun to figure out how to do anyway!)

I believe you can get around the hard coded password problem by setting up certificates to authenticate the session/user but that’s way beyond me at this point in time.


Here’s my (suspended) Linux Gnome desktop in a VNC window on my Windows desktop.






Categories: Uncategorized

Optional Instructions…!

April 8, 2019 Leave a comment

One great thing about the development of the IBM mainframe hardware of the last few years has been the addition of lots of nice new, shiny instructions especially those that allow for the use of all or part of the ‘grande’, I.E. 64 bit, registers. For example, to do a locked update on a double word (8 bytes) in the past you would need to use two pairs of registers, for example, zero and one and fourteen and fifteen and use a Compare Double and Swap (CDS) instruction to do the update. Oh, and those pairs of registers had to be even-odd  as well. Now you can just use two 64 bit registers and use a Compares and Swap Grande (CSG) instruction to do the update and the registers do not need to be an even-odd pair either.

Basically, code that used to take several instructions and registers can often be simplified into fewer instructions and use less registers by using the newer instructions from the instruction set. The benefit is less CPU time consumed and faster execution.

This is great and I’ve been doing this sort of thing for a good few years now. However, if you read the POP (Principles of Operation) you may notice next to some instructions under the ‘Program Exceptions’ heading something along the lines of:

  • Operation (if …… facility is not installed)

What this means is that this instruction is ‘optional! What that means is that it may not be physically implemented on the machine and what that means is that if you try to execute it, you will get an operation exception (S0C1 abend).

There are fields in the PSA you can test to see if a facility is installed before attempting to use an instruction or feature of the hardware but to be honest, in all my forty some years of coding, I have never had to do that…..Until now.

Well, actually, not even now which I will explain in a minute.

I wrote some code recently and wanted to do a divide. Because of the size of the numbers, I used the grande version of the divide instruction. Before doing the divide I needed to clear the high word of the registers so I used the SHHHR Subtract High instruction.

This worked great on my test machine but failed on another machine with an S0C1 abend. Yep, that other machine did not have the high-word feature installed.

It was easy enough to replace the instruction with another (The ICMH version of Insert Character under Mask) which is not feature based and so should be there on all hardware but this is the first time in all my years of coding that I’ve ever had to even consider to availability of a feature.

I’ve always thought of the instruction set in the machine as being like an engine in a car, every car has an engine, but I’ve never really considered that not all car engines are the same. If you want more power, it typically costs more to buy a car with a more powerful engine. A more powerful car will (speed limits aside) get you from A to B more quickly and if time is money, spending money up front to get a more powerful car will save you time (and money) later on. In the computer world, you can pay more up front to buy a machine with more features (better instruction set) and get faster execution which save CPU time and thus chargeable MSUs or you can pay less and pay the money when you consume the extra MSUs due to the smaller and thus slower instruction set available to code running on the machine.

In my case, rather than test to see if the feature (instruction) was available before using it I just replaced it with an instruction that I know will always be there. This reason for this is that this is very low use code and it was two instances of one instruction. It would take longer to execute the code to test for the feature and branch to alternate code than it would to just always just execute an alternative instruction. That test and branch also adds slightly more complexity to the code which adds to the possibility of errors and makes it just that bit harder to maintain.

Had the block of code been high use and/or very complex it may have been worth while to test for the feature and use the faster instructions/simpler code when available but that was not the case here. Simple is good in my book!


Categories: Uncategorized

ISPF Edit ‘Count’ macro

August 22, 2017 Leave a comment

Just a little macro I put together to count the number of occurrences of a string in a file when editing it.

/* rexx */ 
if text = '' then do 
 say 'Nothing to search for. Enter text to search for ith cmd' 
 return 0 
address isredit "find all "text 
address isredit "(num,lines) = FIND_COUNTS" 
if num > 1 then s='s' 
if lines > 1 then ls='s' 
if lines > 0 then on = ' on 'lines' line'ls 
say 'Found 'num' occurance's' of 'text||on

To run it, just type count followed by the string to search for, and any other parameters such as the column number on the command line when in edit and press enter. E.G.

COUNT ‘some string’







Categories: Uncategorized

The humble EJECT statement…

March 17, 2017 Leave a comment

Back in the day when dinosaurs still roamed the earth and programmers still knew how to use a card punch, there were printers. Not your desktop printer of today but huge big, noisy things with all the characters on a chain, a ‘ribbon’ as wide as the paper that fed vertically on rollers and a a row of hammers that stuck the correct character as it went past on the chain, if you got it setup right that is! These things also used a paper loop for carriage control that told it where various spots where on the page, in particular the top of the page. Happy days!

In those days your program listing got printed out, so to make it more readable you’d put EJECT statements into the source code, usually before a subroutine so that the subroutine and all the comments about what it did, its inputs and outputs etc; (you did document all that stuff  didn’t you?) were at the top of a page.

Fast (or not) forward to today and I doubt anyone actually prints program listings anymore. If you are anything like me it’s all online, either in SDSF, sent to a member of a ‘listings’ dataset or, if your source is off platform, your tool set grabs the output after the assembly has run and FTPs it back to your workstation/PC where again, you can view it online.

So, since the output is now all just one big stream, why would you bother putting EJECT statements into your source, other than from habit?

Now I will admit that I did this from habit until I got to thinking about it (hence this post!) and there is actually a very good reason to include EJECT statements in your source, especially before the start of a subroutine.

Here’s a little test program:

TEST     CSECT                   
         BAKR  14,0              
         LR    R10,R15           
         USING TEST,R10          
         USING WSA,R2            
         XR    R15,R15           
SUB1     DS    0H                
         LA    R1,FIELD1         
         XR    R15,R15           
         BR    R14               
WSA      DSECT                   
FIELD1   DS    F'0'              
FIELD2   DS    F'0'              

If you assemble this, the output looks like this:

                                     20 TEST     RMODE ANY          
000000                00000 00018    21 TEST     CSECT              
000000 B240 00E0                     22          BAKR  14,0         
000004 18AF                          23          LR    R10,R15      
                 R:A  00000          24          USING TEST,R10     
                 R:2  00000          25          USING WSA,R2       
                                     26 *                           
                                     27 *                           
000006 17FF                          28          XR    R15,R15      
000008 0101                          29          PR                 
000010                               30          LTORG              
                                     31 *                           
000010                               32 SUB1     DS    0H           
000010 4110 2000            00000    33          LA    R1,FIELD1    
000014 17FF                          34          XR    R15,R15      
000016 07FE                          35          BR    R14          
                                     36 *                           
000018                               37          LTORG              
                                     38 *                           
000000                00000 00008    39 WSA      DSECT              
000000                               40 FIELD1   DS    F'0'         
000004                               41 FIELD2   DS    F'0'         
                                     42 *                           
                                     43          END

In this code, I have let the using for WSA in the main line code ‘fall through’ into the sub routine (something I normally hate to do except for working storage based on R13). The only way you can tell that the LA,R1,FIELD1 instruction in the subroutine is using R2 as a base register for WSA is by looking at the assembled instruction.

However, if you add an EJECT before the SUB1 label like this:

SUB1     DS    0H            
         LA    R1,FIELD1

The output now looks like this:

000000                00000 00018    21 TEST     CSECT              
000000 B240 00E0                     22          BAKR  14,0         
000004 18AF                          23          LR    R10,R15      
                 R:A  00000          24          USING TEST,R10     
                 R:2  00000          25          USING WSA,R2       
                                     26 *                           
                                     27 *                           
000006 17FF                          28          XR    R15,R15      
000008 0101                          29          PR                 
000010                               30          LTORG              
                                     31 *                           
  Active Usings: WSA(X'1000'),R2  TEST(X'1000'),R10                 
  Loc  Object Code    Addr1 Addr2  Stmt   Source Statement          
000010                               33 SUB1     DS    0H           
000010 4110 2000            00000    34          LA    R1,FIELD1    
000014 17FF                          35          XR    R15,R15      
000016 07FE                          36          BR    R14          
                                     37 *                           
000018                               38          LTORG              
                                     39 *                           
000000                00000 00008    40 WSA      DSECT              
000000                               41 FIELD1   DS    F'0'         
000004                               42 FIELD2   DS    F'0'         
                                     43 *                           
                                     44          END

The difference is that you now get one or more lines (depends on how many usings are active) that show the current usings in effect at the very start of the subroutine. As a result I can see exactly which usings are active and whether I have inadvertently ‘inherited’ one from an earlier routine that should have been dropped.

As a matter of coding style, I prefer to always drop all active usings, including code base regs except for working storage that is based on R13, at the end of each routine. That way I
know I am using the correct registers and usings in each routine and by putting an EJECT statement in the source before each routine, I can easily see from the listing that I am not inadvertently inheriting a using from an earlier block of code that may allow the code to assemble but ultimately fail when it runs because I picked up the wrong base register.

Categories: Uncategorized

Drag and Drop with Regina Rexx…

June 13, 2016 Leave a comment

Since I’m a mainframe guy I’ve spent most of my career writing REXX whenever I needed a quick script which means that I know REXX pretty well. Lately I’ve been playing with REXX on Windows thanks to an implementation of REXX called  Regina Rexx, see here.

Of course, one of the things you can do on Windows is drag and drop so I wanted to be able to drop a file onto a Regina REXX program and have the REXX program then process the file.

Typically you access input parms in a REXX exec by using the “parse arg varname” statement but I found that this did not work when dropping a file onto a Rexx exec on my Windows machine.

After some research I found that I needed to create a shortcut to the Regina REXX.EXE program with a parameter that is the path and name to the REXX program to run. You then have to drop your files onto the SHORTCUT.


So let’s say I have the following exec called “test.rexx” on my desktop:

parse arg parms
say parms
say "Press enter to end" 
parse pull .

I then create a shortcut on my desktop that looks like this:

"C:\Program Files\\Regina\rexx.exe" "C:\Users\ltlfrari\Desktop\test.rexx"

So if I drop a file called “test.txt” onto the shortcut, this is the output that I see:


Basically the exec receives the full path and file name as an input argument.




Categories: Uncategorized


August 5, 2015 Leave a comment

I shall be at Share in Orlando next week so if you seem me (picture on my about page), please do say hi.

Categories: Uncategorized Tags: ,

Wow, it’s been a year already…

January 4, 2015 4 comments

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.

Categories: Uncategorized

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.


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: ,

Conference calls…

March 7, 2013 Leave a comment

This has been around a while but I’ve only just seen it. I’m pretty sure I’ve been on this call…!

Categories: Uncategorized Tags: ,