This has been a bit of a detective story so I thought I’d mention it here in case it helps anyone.
As part of my efforts to move my web based ISPF interface to the stand alone IBM HTTP server I needed to run the REXX execs under USS. Now to be honest I rarely ever touch USS on z/OS but that’s where I needed to be so that’s where I am.
I typically write my REXX execs in lower case so I might end up with one exec invoking another with something like this:
Where myfunc is another REXX exec in the standard search order (SYSPROC and SYSEXEC typically). This works fine because even though the function name is written in lower case, REXX converts it to upper case and that matches the member name in the library just fine. Everything works great.
BUT! Move over to USS land and things are not so simple. REXX in USS land is case sensitive. Using the example above, I had created the ‘myfunc’ exec file in USS with a lower case file name and was surprised when the calling exec could not find it.
Eventually (after two days) I found that by default, REXX makes function names coded like this into UPPER CASE before searching for them (I knew this, I had just forgotten about it) so REXX was searching for a file called ‘MYFUNC’ whilst the file I had created was called ‘myfunc’. Not the same animal in a case sensitive environment.
I could make all my exec file names upper case to address this, but in the event you need to call a lower case function name you can code it like this:
And amazingly it will now find the lower case exec file.
Just a quick update, more details and info to follow soon.
My initial iteration of ISPF on the web required the user to still log on to TSO/ISPF on a 3270 and then start the web server inside their TSO/ISPF session before accessing it via a browser.
Whilst this was an interesting exercise and learning experience, obviously it’s about as useful as a chocolate fireguard in practice.
Hence the move to version 2!
The UI experience in the browser is the same but the back end is significantly different, running inside the IBM stand alone HTTP web server.
I am still developing this in my spare time, but as soon as I get a demo up and running I shall be adding more information so stay tuned.
It’s taken a little bit of experimentation but I’ve come up with a basic drag and drop interface. So far there’s no back end interaction so all the interface does is pop up an alert to display the properties of what was dropped. There’s also a lot of ‘hard coded’ stuff to make things happen, but at this point but I’m more interested in the interface itself than the how.
On the right I’ve got a little tool box containing a trash can and a JES card reader (or at least the best impression I can come up with of one). By dragging the icons next to the files and data sets or PDS members onto the tools the idea is that you’d get the appropriate action. I had to use icons rather than the whole dataset name because the length of the dataset name meant I was getting a lot of ‘misses’ when dropping the elements onto the tools due to the way the jQuery UI drag and drop functionality works. Limiting it to the icons just made things a lot easier to use.
Oh, and although I didn’t demo it, if you scroll the page up and down, the toolbox stays in the same location so it’s always there to interact with.
The next steps are:
- Add some front end code to the trash can to confirm you actually want to delete the item and then send the request to the back end
- Add some code to send the job submission request to the back end where the REXX will have to try to confirm that this is actual JCL you are submitting, or at least that it has a job card.
This is actually pretty fun stuff to do!
Well, it’s been a bit of a battle but I’ve managed to get the basic dataset member and contents list function working to my satisfaction.
I decided to use the jQuery UI dialog function to create dialog boxes to display member lists and member and sequential dataset contents. I hit a few road blocks along the way, not least of which was propagating the capture of links so that I could get the data using jQuery Ajax functions.
Turns out that the jQuery Ajax functionality ($.get) executes the script before it invokes my callback routine to process the data. Since my callback has not run yet, the elements the script wants to manipulate (in the returned data) are not there yet so nothing worked!
In the end I managed to come up with a mechanism that propagated the link activity without having to embed script into the fragments but it was a pain to do.
One benefit though is that I am able to resize the dialog pop ups if need be inside that code. The best part was trying to find out if the pop up had scroll bars or not. Why is that so hard to do? Although in the end I found a really nice example of some code that I was able to modify to my needs.
Anyway, enough talk, here’s a couple of screen shots. The first shows multiple dialogs open with dataset member lists and contents.
The second screen shot shows that you can switch tabs and the dialogs remain open. Imagine this was another ISPF type function. Now you can mix and match the pop ups.
Because I am displaying info in pop up dialogs on the page, now I can start to think about drag and drop. For example I could drag a member from one member list to another to move or copy a member from one dataset to another.
Or I could copy a member or a dataset (from the dataset list) even onto a trash can icon to delete it.
Another thought I had was to have pre built jobs. Drag a job member onto a reader icon and it submits the job.
See, this stuff can be really REALLY cool!
Many (many) moons ago, way before I’d even heard of AJAX and JQuery and such tools, I wrote (as a proof of concept) a REXX based web server using REXX sockets and a ‘framework’ address space I’d developed some time previously that provided several facilities like multi-tasking and console access.
Recently I was looking at one of our ISPF based applications and wondering how the heck you could give it a web interface. There’s an ISPF GUI client but really, it just brings a 3270 interface onto the desktop and you still need a real 3270 session going (usually via an emulator) to use it. All pretty pointless in my opinion.
But then I thought (as you do), hang on, what if I could run my REXX web server INSIDE my ISPF session? Since it would be running under ISPF it would have access to all the ISPF facilities and yet it could do it’s own thing as far as the UI in the browser was concerned.
As it would be running inside my TSO/ISPF session, it would only need to be a single user server so I would not need the multi-tasking facilities of the framework address space I’d used before and as it was running inside my session, it would be subject exactly the same security rules as if I were on the ISPF session itself (since I am really).
It only took a couple of hours to merge the old client code with the main server code to give me a workable single user web server.
The following image is taken from the web page served right out of my TSO/ISPF session:
See, I’ve even made it look like a 3270 screen!