COBOL "Screen Section" - Examples and Suggestions

[John T. Farmer]

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

[Wim Van den Wyngaert]

I learned it very recently (1 hour ago).

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

Wim

[Robert Gezelter]

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]

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]

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]

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]

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.

[Richard J Maher]

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