Home > Coding, Development Tools, General Stuff, jQuery > ISPF via the web

ISPF via the web

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.

So far it only delivers simple fixed web pages and css style sheets. I’m still trying to figure out how best to support images and javascript (thinking JQuery and other tools minimized packages here which can have looooong lines) but so far it works really well.

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!

Advertisements
  1. Jeffrey
    May 8, 2014 at 3:54 pm

    I have been absolutely devouring all of your posts and am particularly curious about this post. Utilizing the HTTP Server on our mainframe, I have developed a web based application that allows the user to interface with the mainframe to look at code and such. However, the HTTP server is a trap door; it only allows things out, but not back in. To wit, to only BROWSE code in a browser window. This post has some intrigue to perhaps circumvent that trap door and to use a browser window to perhaps EDIT code in a browser and put it back on the mainframe?

  2. May 8, 2014 at 5:59 pm

    There are a lot of difficulties associated with editing a mainframe data set in a browser, not least of which is how to hold an enqueue on it while you edit it ‘off platform’ and yet, still allow other browser requests to be processed. Web servers are really not designed to provide that sort of function directly so you need to hand off the request to something that can issue that enqueue and hold it until you commit the changes.

    • Jeffrey
      May 8, 2014 at 7:08 pm

      That is an excellent thought, David. I never considered the enqueue. Currently, I use FTP to pull source to my PC to do the editing, changing and testing. Then FTP it back up to the mainframe. And since there is no way to ‘check out’ a member from a PDS library, this will be a moot point. Thanks for pointing this out !!

  3. May 8, 2014 at 7:20 pm

    A web server is really designed to process a request and send a response and then be done so you really have to hand off ‘long running’ work to another address space. But then, since the front and back end are ‘disconnected’ you need to pass some sort of token back and too from the browser to the ‘other address space’ via the web server so that the serving address space can find your work again for each request. You also need to have some sort of heart beat between the front end and back end so that he back end can abort things if you close the browser window (vs just leaving the screen while you go get lunch or whatever!).
    Of course you could just go the way you are doing currently except via a browser. download the file and edit in the browser then simply put it all back once you are done. You could keep something like the dataset’s last update date/time as a token in the browser when you read it and pass it back for the update and have the back end check that against the dataset to see if it has changed before overwriting it. It’s not as nice a user experience because of the potential for someone else to update the dataset while you are ‘editing’ it off platform but it is a simpler implementation.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: