Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

COBOL "Screen Section" - Examples and Suggestions

John T. Farmer
Regular Advisor

COBOL "Screen Section" - Examples and Suggestions

I recently learned (yes, just recently) about the COBOL Screen Section. From prior posts, I mentioned we don't use a screen management package, but do individual field displays and accepts. The Screen section seems to be a nice middle of the road, and it's built in. Given that, I don't find a lot of reference to that other than

http://www.uni.edu/coboldoc/cobum_036.htm

1. Any big "Gotcha's" when working with the Screen section?

2. Anyone have the control key mappings for the VT keyboard (PF1-PF4, F1-F20, Next, Prev, etc.)?

3. Can you control data entry CASE for character data?

4. Any compelling reason not to use the COBOL screen section for moderate-to-heavy screen-io design?

Thanks,

John
john dot farmer at genworth dot com
7 REPLIES
Wim Van den Wyngaert
Honored Contributor

Re: COBOL "Screen Section" - Examples and Suggestions

I learned it very recently (1 hour ago).

http://www.opengroup.org/bookstore/catalog/c192.htm gives you the X/OPEN standard description.

Wim
Wim
Robert Gezelter
Honored Contributor

Re: COBOL "Screen Section" - Examples and Suggestions

John,

If you are doing a restructuring of code at this point, I would recommend isolating the screen handling in a separate procedure.

The most likely evolutionary path is from a dump terminal interface to some web-based interface. Compartmentalizing the screen IO in a separate module will mean that the code is contained, and can later be replaced with the functional equivalent (please see the notes from my 2000 Enterprise Technology Symposium session " OpenVMS Shareable Libraries: An Implementor's Guide" at http://www.rlgsc.com/cets/2000/460.html )

- Bob Gezelter, http://www.rlgsc.com
John T. Farmer
Regular Advisor

Re: COBOL "Screen Section" - Examples and Suggestions

Not really looking to put a web-face on the system. However, I completely agree with creating some level of separation between presentation and logic. Currently, both are intermingled in the program code.

I was more interested in making a move to using the Screen section, so it's more of a screen-at-a-time, instead of our current field-at-a-time entry, cursor control and data editing. I can't justify any dollars for additional products such as DEC/Forms, and hope to avoid a steep learning curve to implement a chaning in screen handling. Just wasn't sure if the screen section was robust enough to be worth making a change. Currently testing a small maint program to learn my way around. Having said all that, all suggestions are welcomed.

Thanks,

John
Robert Gezelter
Honored Contributor

Re: COBOL "Screen Section" - Examples and Suggestions

John,

Concur. My comment was more in the nature of "pre-adapting" the system to future evolution.

- Bob Gezelter, http://www.rlgsc.com
John T. Farmer
Regular Advisor

Re: COBOL "Screen Section" - Examples and Suggestions

The VMS system has a 24-30 month expected life. No long term plans to extend the interface to current technologies. However, we are sorely behind on where a character-based app should be. No plans to reengineer the current app, but want to promote a new standard for new development. Screen section seems to be a way to clean-up screen control without any heavy dollar invenstments.

Thanks,

John
John Gillings
Honored Contributor

Re: COBOL "Screen Section" - Examples and Suggestions

John,

My recollection is the COBOL SCREEN SECTION is compiled into SMG calls, so things like key mappings are most likely lifted directly from SMG. Similarly, the control over data input is most likely mapped from SMG$READ_COMPOSED.

Try some simple examples and look at the generated machine code.

Gotcha's -

Most likely you should avoid any other terminal I/O.

Remember DEFINE DBG$INPUT and DBG$OUTPUT to debug screen based applications with 2 terminals, or use the DECWindows debugger

Compelling reasons - from your experience, it looks like there isn't much expertise around. On the other hand, HP support for COBOL is exceptional, so it should be easy to get answers to any questions you might have.
A crucible of informative mistakes
Richard J Maher
Trusted Contributor

Re: COBOL "Screen Section" - Examples and Suggestions

John,

I have never used the Screen Section available on Alpha (and presumably Itanium) but I have been working with COBOL on VMS since 1983 in various industries and countries and FWIW these are my thoughts.

(Here's the Reader's Digest bullet point version. If you'd like me to expand any given point then let me know)

. What's wrong with ACCEPTs and DISPLAYs? The Screen Section will give you block/form input but do you really want to move to an IBM 3270 user interface? Does it let you display the Employee Surname after you've entered the Id field, or do you have to wait until the rest of the Form is filled-in and Enter/Submit is pressed?

. FMS is the best character cell forms package ever available on VMS and gives you a fully functional panel editor and field by field functionality. But you don't seem to want that, and HP still have the nerve to charge an arm and a leg for FMS even though it has received not development budget for almost 20 years :-(

. If you want free and full-function use the SMG$ library directly. (No panel editor)

. Don't even consider DECforms or TDMS! (Ask the HP people when it was decided to port TDMS to Alpha)

So my advice is stick with what you've got. Your users have been hitting those screens for 20 years now and are probably not keen on change.

If, however, you get serious about putting a modern interface on your trusted Cobol code then please look at the e-mail below that I recently sent to the Rdb Listserver. I will supply the html/JavaScript code as an attachment here, and put the Cobol server code as an attachment to your earlier "Modernizing. . ." thread.

It really is very, very simple to get a high quality Browser based GUI front end without having several layers of morphing crud on your server. (See the bit where I say "No JVM, No JDK, No PHP, No ASP, No JDBC, No WebServer. . . .") And *no* rolling out new versions of your client software!

Cheers Richard Maher


Hi,

We're not geared up at present to host this sort of demo application on the web (Sure wish that's what HP's TestDrive cluster was for!) but I simply cannot contain my enthusiasm for this VMS Web Application Development example a moment longer. I'll try to sort out a locked-down internet-accessible server so that you can Browser over to it and have a look but, in the meantime, here's just a taster of what it does, and some of the HTML/JavaScript code involved, to whet your appetites.

The example requirement is a straight-forward VMS Queue Management application, and while this example doesn't use Rdb as a database (purely for portability and simplicity reasons) it has been specifically designed with Rdb data access requirements in mind. My example is intended as a "How-To" for accessing your rock-solid, high-performance 3GL code, and data, on the high-availability VMS servers that we all know and love, and then presenting the results via the ubiquitous, and feature-rich, HTML/JavaScript GUI.

Here's some of the functionality-catwalk highlights: -

1) Full, one-time, context-specific, VMS User Authentication. No Cookies, Session IDs, Password Caching or generic Work-Station or Browser credentials! When you load the demo_client_web.html page into your browser, a Java Applet is automatically activated that prompts the user for their VMS Username and Password via a modal dialogue box. If authorization fails, the "Access Denied" page will be displayed and VMS Intrusion Detection (in accordance with the policy set out by your System Manager) will be enforced, and Login-Failures is incremented in SYSUAF. Alternatively, if authorization is successful (and you left the "Display Logon Confirmation" box ticked) then a Welcome dialog box will be displayed detailing last login times and the number of unsuccessful login attempts (if any). Login-Failures is now set to zero and last non-interactive login time is set to the current time.

If you refresh this page, or move to a different page, then the server connection is broken and you must be re-authorised before continuing to access the Demo Queue Manager application.

2) A Hot-Abort button! After you have pressed the "Get Job Info" button you'll notice that the "Abort Request" button becomes active and turns red. (Actually you probably won't notice 'cos this query completes too quickly :-) You can edit the DEMO_UARS.COB code and change the value of the DEBUG_DELAY field if you want to see your 3GL Interrupt routine in action.) In this case the cancel-flag I've set in the AST routine is picked up in the mainline code, resulting in the graceful termination of the loop that controls "next queue" (or "next row") retrieval. (The full ramifications of this hot-abort functionality only come into view when Paul Mead publishes the API for the recent Query Governor functionality that can Interrupt Rdb "Mid-Query" and not *after* it starts returning rows! More on that later - Exec Mode notwithstanding!) Note that this functionality can only be provided due to the fact that you're now operating in a connection-oriented, context-rich Tier3 environment.

Also, if you look at the getResponse() function in query_lookup.html, you will see how the chan.setTimeout() method has been deployed to provide an erstwhile "blocking" socket Read with the ability to surrender the event-thread for things like processing the Abort button and ticking over the clock. (all of this, and much more, "infrastructure-code" is already there and doesn't have to be re-invented)

3) Predictive text on the Queue Name field so that all matching VMS queues are retrieved on-demand as the user types. As is now common-place with many websites, a drop down select list of matching options is automatically retrieved from the server and made available for the user to select from.

4) Result-set drill-down. Many database queries return a result-set of rows for the user to scan through and possibly drill-down into for more detail. I've provided a reasonably generic example of this, where all matching Job Entries have been populated into a dynamic HTML select list. Once again the user was able to see the select-list grow, the scroll-bar diminish, and "Jobs Found" field tick over in real-time, whilst continually being empowered (by the Abort button) to curtail the results at any time!

If you click on an entry in the Select List then the changes and the entry_details.html page appears. See the parent.entry_details.getReady() call in queue_lookup.html to see how the handover to the new frame takes place. (Also see goBack() in entry_details.html to see how simply that operation is reversed.)

The user is now free to move forward, back, first, last, refresh, and delete queue entries, or return to the previous frame. (Thanks to the deployment of the VMS Persona functionality, the user is only permitted to see those queue entries that the Username they signed in under is permitted to see. They can also *only* delete those entries that this username is allowed to delete.) It is one of my most heart-felt laments that Rdb engineering refuses petulantly to embrace this functionality, at great cost to Rdb and its users :-(

5) Floating
s. You'll see that any queue names are highlighted in bold and italics; if you mouseover any of these fields when they are not blank then the current status information for that queue will be retrieved from the server and displayed in a quasi-popup DIV.

==========================================

OK, that's enough to take-in without pictures :-) If you want to see what this looks like on your servers and with your own queues then let me know an I can have a version up and running in somewhere between 2 hours and a day of your time! (I also have a couple of screen-shots if you're interested?)

Thanks for listening!

Client Infrastructure requirements:-

. I have to-date, only tested the client HTML and JavaScript on Internet Explorer 6 on Windows2000 (There is an Applet tag there for FireFox et al, but I'm expecting a couple of days debugging to get it working, so IE6+ only at the moment I'm afraid) When it comes to IE7, I believe you're asked to accept the Applet. This will go away when I get a chance to test it.

. You obviously need JavaScript enabled from whatever address will host the example html pages.

. Microsoft is pulling the plug on it's own JVM so if you haven't already done so, you should download Sun's JVM. (I'm running with 1.6 but we have a test site still running on 1.4 without any problems) You also need a 1.4+ JDK on some platform somewhere, just to compile four small Java files and build the Archive (JAR) file.

. Apart from that minimum requirement, there is absolutely *no* software installation required at the client site! If you want to roll-out new versions of your application then just update the HTML pages and/or Applet Archive file on your web-server and it's all downloaded on demand.

Server infrastructure requirements: -

. VMS Alpha 7.2-2 or later or VAX 6.2 or later

. COBOL compiler. The example server code is in COBOL.

. COBOL RTL 2.8 or later

. Tier3 V3.1 (Free 3 month evaluation copies available)

. If you're not running a webserver on VMS at the moment then I'll give you a Mickey-Mouse DCL http webserver to test with, until I finish my lightweight Applet-Uploader. Alternatively install one of the free (and smallest footprint) webservers you can find. It is important to note that the HTML web pages in this example can be hosted by any old webserver (Unix, Windows etc) at all! It's just that your Applet Archive JAR file needs to be hosted on the same VMS server box that the Applet will connect back to. (Otherwise the Applet has to be signed) Change the tag for my CornuCopiae applet to FTP if you'd prefer that to HTTP and the browser requirement.

. Most importantly, No JDK, No JVM and, as you've seen from above, No Web Browser requirement *at all* on your VMS box! No SOAP, No Waste of Substantial Investment in Technology (WSIT), No JDBC, No ASP, No JSP, No PHP No CGI! Just the bare bones grunt, functionality and reliability of VMS, your choice of 3GL, and your choice of database (And I think we all know what that should be.)

Cheers Richard Maher

Attachments: -

[demo_client_web.html]
Framset definition page

[cornucopiae.html]
Constant banner page (username, host, connect time clock) Look here for Applet definition

[queue_lookup.html]
This is the main driver page that gets loaded (by the Applet) into the second Frame. To see what's going on here it's probably best to search for "
[entry_details.html]
When you click on a Select-List item (other than the header) detail information for the matching queue entry is retrieved and this page replaces the queue_lookup page in the bottom Frame. (Or rather the other Frame shrinks and this one grows). Don't forget to mouseover the Queue Names for a queue status update.

[common.js]
Some common functions and variables that are used by more than one frame/page. (I am open to any philosophical (or otherwise) argument about whether it is best to call a "not variant" and stateless function in another Frame or merely to in-line a copy of that same function in the local Frame).

========================================

NB: It would be ever so *much* easier to understand what's going on with this example if you simply had a working version in front of you! Surely, only the meanest of spirits could look upon a day's investment in examining "What JavaScript and HTML can do for me" as time ill-spent? Even if you walk away tomorrow and don't spare Tier3 another thought, the code is definitely worth a look, and it might just help your strategists to understand some of what's wrong with XMLHttpRequest.

What are you waiting for?

PS. I don't lay claim to being a JavaScript, Java, or HTML expert (in fact far from it), which only goes to show just how easy this stuff is to pick up. My understanding of Cascading Style Sheets is rudimentary at best, there's not one single "Image" in there, and maybe you should opt for over