COBOL: Screen Section Questions

[Paul Raulerson]

I've been working with the COBOL screen section quite intensively the past few days, and it is very nice. I do have some questions though, which are probably elementary, but I will ask them anyways... :)

(1) Does anyone have recommendations on a terminal emulator that can be distributed with applications? I am currently using Putty, and have almost everything working. The function keys all work, page-up, page-down, etc. I can get everything to work in the editor (using DEFINE KEY= statements) but in the screen section, I have a few gotchas.

(2) Those gotchas are:

A) Screen traversal from field to field; backtab just does not want to work. I really don't like not being able to use back-tab to back up a field, and neither will my users. :)

(B) I can't get the terminal to cycle from the last field on the screen back to the first using the TAB (or any other!) key. Help? Kind of important that the user can navigate around the screen all he or she wants, especially with BACKTAB not working!

(C) I found I had to do a call to set NOLINE_EDITING for all the function keys to work; is there a standard way to do this in COBOL, or better yet, some tag or something in the screen processing that turns it (or whatever else eats up the function keys!) automatically?

Thanks -Paul Raulerson

[Phil.Howell]

1 Putty seems to be the best of the free ones
Reflection from wrq/attachmate is probably the best but it costs.

2a What does ctrl-H do? sometimes emulators have problems with backspace and linefeed
backspace may also be mapped to F12
and linefeed (ctrl-J) to F13

2b What does ctrl-L do? This might be used for new page? Maybe a shift-tab would go backwards? Some application define a "home" key to position at the first field.

2c no idea

[John Gillings]

Paul,

As you're probably aware, NOLINE_EDITING blocks "standard" DCL command line editing functions. See HELP LINE_EDITING for a description of which keys do what.

If you wish to use a line editing sequence for something else, you obviously need to disabling line editing, BUT the cost is you will no longer be able to use the other line editing features. This may not be desirable!

COBOL screen section is implemented using the SMG library. For more fine grained control than may be available from COBOL, you may want to call SMG directly. I'm not sure how feasible or easy it would be to mix COBOL and direct SMG calls in the same program. Check out a machine language listing of your COBOL modules to see what SMG routines are being used.

The COBOL and SMG documentation may help determine the exact character sequences are expected for various functions, in particular "BACKTAB". You may need to work out how to program your terminal emulator to send that sequence.

[Paul Raulerson]

Thank you Phil and John! (I assigned back points, but having no real idea of what to assign, let me know if the values were "incorrect." :)

Phil: Control-L will work to skip back a field, though why in the world inserting a page break would do that is beyond me. From the standard Putty keybaord, back-tab (Shift-Tab) produces a key input of KEYPAD(90), which I can reassign in Eve, but not, apparently, just from a define /key statement at the DCL prompt.

John: For the users, line-editing is not really an issue, as that happens at the DCL command line and the users never ever should even see a DCL command line. They are in the application all the time. :)

I being to understand now why people whose opnions I respect (thanks Hoff:) have steered me away from tyring to use 3270-like green sreen handling under VMS.

What I am doing is attempting to port a mainframe based CICS application to OpenVMS. In total there are about 300 programs with 1500 or so screens. They are all, of course, 3270 based screens.

The two hunks of logic that are different indeed under Open VMS are: the programs are all conversational and the screen handling is "unique." :)

I can deal with the conversational issues; all the user interaction is somewhat segregated in the code anyway.

The screen handling however, is another story. I need the screens to look at least similar to the 3270 screens, which means users are used to hitting function keys to do things.

Typically, the Functon keys are assigned things like this:
F1-Help F2-New F3-End F4-Alpha Index ...

Usually I show a line like the one above on the screen on line 23, with messages showing on line 24. Very consistant throughout the application, and the users are pretty well used to it.

Every VT emulator around seems to be different, and have a different idea of how to map the keyboard. (*sigh*)

For me it is simple, the users will be using a PC-style keyboard, whether on a desktop, a thin client, or a laptop. When they press "F1" the program needs to consistantly get back a code that means "F1". *Every time.*

Same if they press F6, or F13, etc. Page-Up and Page-Down have to return unique codes that the program can always match to page-up or page-down. Etc.

On-screen editing, while a form is in an ACCEPT, always needs to be consistent and use the keys labled on the keyboard. (i.e It is not okay for the key labeled DELETE to really be SELECT. That kind of stuff. :)

I'm perhaps a little unusual, as I don't care one bit about supporting old VT220 keyboards; my users will always be coming in from a PC emulator type environment.

Thanks again for the advice! :) -Paul

[Jan van den Ende]

Paul,

>>>
Thank you Phil and John! (I assigned back points, but having no real idea of what to assign, let me know if the values were "incorrect." :)
<<<

Well, _YOU_ are the only judge on that, but there are some guidelines:

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

And since you are obviously new to this forum:

WELCOME!!!

Prosst.

Have one on me.

jpe

[Phil.Howell]

some emulators (vt340?) also allow a line-25
which can be used as a "status" line.

as 3270 is similar to "block mode" screens, have you considered writing a module do all the screen handling based on calling parameters?

Phil

[John Gillings]

Paul,

>never ever should even see a DCL command line

Line editing works for input into programs. So if you want then to be able to use arrow keys to edit their input, you may want line editing enabled.

Facilities like the COBOL Screen Section often require you to modify your user interface to conform with the design limits of the I/O model conceived by whoever designed it. If you find that you're having trouble making it do exactly what you want, and have specific requirements for your UI, you may find it better for your sanity to build your own screen manager.

Depending on how the screens are currently defined (some kind of template?) it may be simpler to write yourself a parser to read your existing definitions and instantiate the screen using SMG (or, for a slightly higer level, any of the other forms packages DECforms, FMS etc..).

You then have complete control over keys, fields, everything, and since you'd be using common code, you can easily enforce your standards. Although it may sound like more work, it may be the opposite, and you may save yourself lots of future maintenance by centralising your UI.

[Paul Raulerson]

Thanks John-
I guess the real core of the problem here is that several terminal emualtors, all of which claim "exact" vt* emulation, all seem to do things differently.

Given that, I do not understand how going to lower level routines is going to help. I mean, the code for F1 should always and forever be the code for F1. And it should be generated when I press the F1 key on the keyboard.

In the COBOL compiler, it very much seems like the screen based accept is using it's set of processing, and that works pretty well. But still - how is *anything*, no matter how low level, supposed to know that the END key is mapped to previous screen by some goofy emulator???

Perhaps I simply don't understand what you are getting at. Of course, I can write or modify an emulator, or I can use the SNA routines to write a 3270 interface, or I can write or use a full client/server application. Or I can use DecForms or whatever. I am trying to avoid the later because they add significant cost, and to be honest, I do no see how DecFORMS or anythign like that is going to fix problems like end being mapped to next_screen.


The screens look pretty good, and operate faily quickly for the most part. I just need to overcome this ignorance issue and move ahead. Thanks! -Paul

[John Gillings]

Paul,

Sorry,I misunderstood the issue. I thought it was limitations on COBOL not allowing you to implement certain functionality, like "back tab".

The biggest issue in terms of "exact vt emulation" is that PC keyboards and VT keyboards are different. The function row on a "real" LK keyboard is different, especially F1 through F4, which are usually local terminal functions, never seen by OpenVMS. The keypad over the arrow cluster is also different. Some emulators give a choice of mapping functions to the key labels, or mapping according to "True LK" location (in which case the label won't match the function).

>But still - how is *anything*, no matter
>how low level, supposed to know that the
>END key is mapped to previous screen by
>some goofy emulator???

That particular goofy behaviour sounds like a location mapping (have a look at an LK keyboard).

You may need to fiddle with both the DCL terminal setting (SET TERMINAL/DEVICE=model) and the emulation setting in the emulator. The latter may change what character sequences are sent to the host when a particular key is pressed and the former may change how OpenVMS reacts to that sequence and/or how it gets mapped to an SMG key name (which presumably is what the COBOL action keys are based on).

SMG also allows you to define keys, just like the DCL or EVE DEFINE KEY commands, but you'll need to work out the keyboard variable COBOL is using for input (can be done). There's even a mechanism for defining a new terminal device type for SMG, and how the key sequences are interpreted

The easiest way to ensure consistency is obviously to use the same emulator everywhere. If that's not possible, you may need to provide some kind of mapping layer to compensate for differences. That's where using lower level routines helps, since you can "hijack" the keys between the screen management layer and your application.

Some emulators can be identified by their response to enquiry or Answerback sequences (for example, by default, Putty responds "PuTTY" to an answerback request, and identifies itself as a VT102). There are also emulators that pretty much allow any key to be mapped to any character sequence (also terminals, for example, the VT525). It may be possible for your application to send a setup sequence that forces keys to be mapped how you want them, but again, this requires recognition of the device or emulator and creation of the configuration information.

No matter what you do, inventive users will find a means for breaking it by redefining keyboards, changing settings or trying a new emulator or version. That's where a clear description of supported configurations is extremely valuable.

I've got a program around somewhere that will display exactly what characters are sent to the host for particular keystrokes. Let me know if you want a copy.

[Paul Raulerson]

Thanks John -that helped a lot.

SMG also allows you to define keys,

I've got to learn this -- shades of bad old termcap days in UNIX! :)

The easiest way to ensure consistency is obviously to use the same emulator everywhere.

I just happened to have a modified copy of Putty hanging around that lets me go in and modify what any key translates to based upon the scan code and Shift/Alt/Control modifiers. Needed it a few years ago when dealing with a fussy Wang VS emulator.

By setting the terminal string to this:
"set term/device_type=vt102/block/DEC_CRT/EDIT_MODE"
and working with the translations for the scan codes of the keys with odd mappings, I was able to get almost everything working.

The delete key is still defeating me in COBOL, but works well in EVE with a simple DEFINE. I wound up making the DELETE key send PF1, which I map to ERASE CHAR in EVE, and SHIFT-DEL will now send REMOVE.

Also, I haven't figured out how to make TAB just wrap around to the first field from the last field in COBOL, but that is perhaps not a killer problem. I am sure a few users will make it so though. Basic color also works, so the screens won't have to loose that!

This copy of Putty can of course, as you suggested, be redistributed and so ensure that the users get the exact same experience with the terminals everywhere. The Putty settings are also modified to write out to a file instead of the registry, so I can send along write a little install program that asks for their target IP host address and such, and then sets up the connection to a sane default.

The only Windows machines here are laptops, so I am not sure I handled a standard 102 keyboard yet. If anyone would like to try it out... let me know and I'll send you a copy! Address is paul@raulersonsDOTcom )

This is tested only under VMS 8.3 right now. Thanks again for the advice and commentary folks - if anyone feels like commenting, I am always up for some listening. :)


Thanks again - Paul