Redisplay forms like the VOS command list_users
*article and comment trail imported from previous forum platform.
In the VOS command List_Users (lui) the screen continuously redisplays the data. How do get this same effect using edit_forms, COBOL and a file that is being updated continuously? Do I use the accept command or one of the Perform Screen commands? Do I display the form, sleep and then read the file again? But if I do that how do I get the screen to stay up for an alotted time and then turn back to the program to receive new data. Obviously there is a better way. Any Ideas?
COMMENT 1: Comment by Charlie Spitzer | 6/24/2009 12:54pm
list_users does not use FMS.
There are numerous ways to do what you want.
You can use generic ttp sequences: display the screen, call s$sleep, display a goto top of screen and redraw.
You can use FMS. Display the form but use the timeout option on the input screen statement.
You can use FMS. Use s$set_io_time_limit on the input port before displaying the form.
There are a handful of others, but those are the most common and probably easiest to code.
COMMENT 2: Comment by Steve | 6/24/2009 3:25pm
I noticed the timeout option does not work with the accept statement. I get
The default error handler has been invoked.
Feature not available with this device attachment and/or runtime software.
What should I use instead of the accept statement?
Comment by Charlie Spitzer | 6/24/2009 4:09pm
the timeout form option is only available on the input screen statement.
COMMENT 4: Comment by Steve | 6/24/2009 4:13pm
The timeout did not work with edit_forms ... I had to use NLS_EDIT_FORMS
Comment by Steve | 6/24/2009 5:14pm
What do you mean the input screen statement. Can this still work with edit_forms? Is the input screen statement part of the accept statement or is it in the edit_form of the screen?
COMMENT 6: Comment by Charlie Spitzer | 6/25/2009 12:20pm
There are 2 versions of FMS; edit_form creates version 1 form .obj files and nls_edit_form creates version 2 form .obj files. Each version uses a different runtime .obj library. The compiler (of whatever language you're using) will compile both accept and screen statement types, although you are not supposed to mix them for the same form. The compiler doesn't know, or care, which version of FMS you will eventually bind into the .pm, as it generates code that can by both FMS versions.
You should probably read over the FMS manual in StrataDoc, R215 for example, for documentation and examples of the screen statements. If you have further questions, please contact your local CAC.
Comment by Paul Green | 6/25/2009 2:42pm
I think the choice of FMS vs. generic input or generic output sequences is something of a personal choice. FMS offers lots of nifty input editing capabilities and it takes the responsibility for managing the layout of the screen. The generic I/O requests are much more primitive; on output, you can basically position the cursor and write bytes at that location. You have the ability to use the various terminal modes, such as blinking or inverse video. On input, your code can be independent of the precise terminal type file that is in use; no matter what raw key sequence maps to the left arrow key, you always get back a standard code that means that the arrow key was depressed.
It may help to think of FMS as layered on top of generic I/O.
The generic input and output requests are documented in R194, the Window Terminal Programming Manual.
Here is a simple C program that uses generic output sequences to clear the screen and write an "away message".
int main (int argc, char **argv)
if (argc != 2)
printf ("Usage: away_message message\n");
printf ("%c%c", GSI, CLEAR_SCREEN_SEQ);
for (i=0; i<10; i++)
printf ("%c%c%c%c%s", GSI, POSITION_CURSOR_SEQ, i, i, argv);
This program clears the screen and then writes the away message 10 times. The output message is written to row 0, column 0 on the first iteration, and to row 1, column 1 on the second iteration, and so on.