VMS - problem with Cobol ACCEPT, PROTECTED clause interferes with DISPLAY statements

[davidbn123]

Hi                  (21/02/15 - shown a full small program that has this problem - see further below)

I have a question re a problem with VMS Cobol on Alpha & Integrity and controlling the line number of DISPLAY statements when programs contain ACCEPT PROTECTED. This is an odd problem so I'll explain with an example. If I create a simple one line program (test_cob) that does DISPLAY "Hello" and run this, then the text is displayed immediately below the RUN TEST_COB line. So if I was on line 20 the text appears on line 21. If I then add a second line that is an ACCEPT. Then if this is simply ACCEPT WS_TEXT then when I run this again, the text Hello appears on line 21 and the Accept is on line 22. If I change the accept to ACCEPT WS_TEXT PROTECTED and run from line 20 then what happens is that Hello appears on line 1and the accept is on line 2.

What is even more odd is that if I have a three line program:

DISPLAY "Hello"

ACCEPT WS_TEXT

ACCEPT WS_MORE_TEXT PROTECTED

The mere presence of the PROTECTED clause on the 2nd accept affects the behaviour of the program. The ACCEPT PROTECTED statement is affecting where the text is displayed even though it has not even been executed. The text Hello appears on line 1, the first accept on line 2 and the second on line 3. Even if the ACCEPT PROTECTED statement is never executed at all it is affecting the display (and that makes me think it's a VMS Cobol problem rather than something odd with the Terminal I'm using).

This is really annoying where you have a program where you just want the screen display to move forward from where you are and not jump back up to the top of the screen (I don't think this ever happened prior to Alpha's).

Does anyone know why this is and how to get around it ?

All I can do at the moment is sidestep the problem by clearing the screen totally and displaying from line 1 - but that's not what I really want to do.  The DISPLAY "abc" AT LINE x COLUMN y clauses don't help either - I would need to know the current location of the cursor to know what to set 'x' to.

I'd be grateful for any insights into this problem.

David Ben-Nathan (Cable & Wireless).

Entire program showing this problem:

IDENTIFICATION DIVISION.
PROGRAM-ID. DBN1_COB.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS_TEXT PIC X(30).
******************************************************************
PROCEDURE DIVISION.
******************************************************************
MAIN SECTION.
MAIN10-START.

    DISPLAY "Hello 1".
    ACCEPT WS_TEXT PROTECTED.

MAIN99-EXIT.
STOP RUN.

[B Claremont]

Please post the entire test program.

[abrsvc]

From page 6-72 of the Cobol reference Manual, I suspec that one of hte following ay be the trigger here:

74. When you use the PROTECTED phrase without the NO BLANK or FILLER

       phrase, the input field is filled with spaces prior to accepting data. If you also

       use the UNDERLINED, REVERSED, BOLD, or BLINKING phrase, those

       spaces have the specified character attributes.

75. If you use the PROTECTED phrase on a field that causes the cursor to

        position past the last column position of the screen, the results are undefined.

Hope this helps a bit.  If not, please post the code as requested earlier.

Dan

[John Gillings]

David,

    (Can you change the title of this post? "VMS" is a bit too generic!)

I'm not familiar with the behaviour of "ACCEPT PROTECTED", but from your description the issue seems to be your expectations of terminal input and output.

There are basically two ways a program can interact with a terminal.

1) Simple "scroll" behaviour. Output is simply to the screen, the terminal hardware handles scrolling. This is like teletype or typewriter behaviour where output is written to a scroll of paper. There is no possibility of going backwards. The underlying mechanism is to just send a stream of characters to the terminal.

2) Full screen behaviour. Output is written to a specific location on the screen. The order of output can be random. This is more complex to manage, as you need to design the program with a screen in mind. The underlying mechanism is a terminal control package. I think Cobol uses the SMG library.

Now, from what you've described, you want behaviour 1 (simple scroll), but the presence of the PROTECTED clause is telling Cobol that it (may?) need to use behaviour 2. The clause would have been detected by the compiler and will affect the terminal I/O initialisation in order to prepare the terminal for future full screen operations. That explains why the clause may have an influence before it's executed. I'd expect the presence anywhere in the program of any clause which implies full screen behaviour to have the same effect, for example "AT LINE or COLUMN", and possibly even formatting like BOLD or BLINK.

[John Gillings]

David,

   You can test my theory fairly easily. Compile and link your test program, generating a MAP file. Look for references to routine names starting with "SMG$". I predict that if you have plain vanilla "DISPLAY" and "ACCEPT" statements there will be no SMG$ references. As soon as you add "PROTECTED" there will be a calls to SMG$ routines.

[Hoff]

Which emulator?   Many terminal emulators are buggy, and the protected scrolling regions aren't commonly used features.

If you have an old Windows box around, test with the VTstar emulator available with the Freeware — that's the real VT source code.  Alternatively, test with a real VT.

[davidbn123]

Thanks for replies so far. Sorry the title ended up as "VMS" without the rest of the line I intended. Not sure how it can be changed now.

Below is a full program showing the problem. If the 'PROTECTED' clause is removed then the display text appears on the next line. With PROTECTED it jumps to top of screen:

---------------------------------------------------------------------------------------

IDENTIFICATION DIVISION.
PROGRAM-ID. DBN1_COB.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS_TEXT PIC X(30).
******************************************************************
PROCEDURE DIVISION.
******************************************************************
MAIN SECTION.
MAIN10-START.

    DISPLAY "Hello 1".
    ACCEPT WS_TEXT PROTECTED.

MAIN99-EXIT.
STOP RUN.

--------------------------------------------------------------------------

I did try using NO BLANK clause and then the FILLER clause. I'm not sure exactly what these qualifiers do. In the actual program I am creating I need to use the WITH EDITING clause and also allow control key input (ie allow Up and Down arrow to scroll thru previous commands (same was as at DCL prompt - in fact I want the Accept line to work in a similar way to this. The overall effect I want is like the "$" prompt in DCL.

[Dennis Handly]

>Sorry the title ended up as "VMS" ... Not sure how it can be changed now.

By having each replier using the Post Options > Edit Reply (as you did) to change the subjects.

[John Gillings]

David,

   This is beginning to make more sense. I'm guessing that Cobol uses the SMG$ input routines to implement command line recall and editing. In theory you can use SMG for just input or just output, but it's possible in practice that Cobol is initialising both when perhaps only one is used.

  If you can't find the right combination of clauses, you could implement the kind of input you want using direct calls to SMG$ routines (SMG$CREATE_VIRTUAL_KEYBOARD and SMG$READ_COMPOSED_LINE).

[davidbn123]

Thanks very much for your help - I've never used SMG before but I'll take a look at the documentation and see if I can find what I' looking for

[H.Becker]

On OpenVMS/Alpha V8.3 and COBOL V2.8-1286 there are no smg$ routines in the main (cobol) image. This can be verified with a linker map file. "protected" seems to trigger a call to DCOB$SCR_ACCEPT - and I don't think this is news, as this can be seen in the linker map as well. But there are smg$routines in the DEC$COBRTL, their names can be retrieved:

$ pipe cob nla0:/list=sys$output |search sys$pipe "Page 1"
                                Source Listing                  26-FEB-2015 13:26:26  Compaq COBOL V2.8-1286            Page 1
$
$ search x.cob accept
    ACCEPT WS_TEXT protected.
$ cob x
$ link x
$ xpd x.exe
eXternal Procedure and Data list (Alpha), version 1.8
DEC$COBRTL:
offset 0x1e0 maps to DCOB$SIGNAL_HANDLER, type is procedure
offset 0x3b0 maps to DCOB$SCR_ACCEPT, type is procedure
offset 0x240 maps to DCOB$MAIN, type is procedure
offset 0x70 maps to DCOB$CALLED, type is procedure
offset 0x10 maps to DCOB$ACC_DISPLAY, type is procedure
offset 0xb0 maps to DCOB$$REGISTER_NAMES, type is procedure
SYS$PUBLIC_VECTORS:
offset 0x11a0 maps to SYS$NATIVE_TO_TRANSLATED, type is procedure
$
$ pipe xpd sys$share:DEC$COBRTL.exe |search sys$pipe smg
SMGSHR:
offset 0x510 maps to SMG$GET_TERM_DATA, type is procedure
offset 0x500 maps to SMG$INIT_TERM_TABLE_BY_TYPE, type is procedure
offset 0x40 maps to SMG$SET_KEYPAD_MODE, type is procedure
offset 0x550 maps to SMG$READ_KEYSTROKE, type is procedure
offset 0x0 maps to SMG$CREATE_VIRTUAL_KEYBOARD, type is procedure
$

[John Gillings]

David,

   Here's an example. There are 3 reads so you can test line recall and editing. Note that READ_COMPOSED can also prompt. See documentation.

IDENTIFICATION DIVISION.
PROGRAM-ID. DBN1_COB.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS_TEXT PIC X(30).
01 WS_KBD PIC 99999 COMP.
**************************************************.****************
PROCEDURE DIVISION.
**************************************************.****************
MAIN SECTION.
MAIN10-START.



    CALL 'SMG$CREATE_VIRTUAL_KEYBOARD' USING BY REFERENCE WS_KBD.
    DISPLAY "Hello 1".
    CALL 'SMG$READ_COMPOSED_LINE' USING BY REFERENCE WS_KBD, OMITTED, BY DESCRIPTOR WS_TEXT.
    DISPLAY "Hello 2",WS_TEXT.
    CALL 'SMG$READ_COMPOSED_LINE' USING BY REFERENCE WS_KBD, OMITTED, BY DESCRIPTOR WS_TEXT.
    DISPLAY "Hello 3",WS_TEXT.
    CALL 'SMG$READ_COMPOSED_LINE' USING BY REFERENCE WS_KBD, OMITTED, BY DESCRIPTOR WS_TEXT.



MAIN99-EXIT.
    STOP RUN.

 You need to be a bit careful, as SMG has dependencies. If there will be any SMG output, the SMG$CREATE_PASTEBOARD call needs to preceed  SMG$CREATE_VIRTUAL_KEYBOARD.

[davidbn123 · Accepted solution]

Thanks again - I will take a look at the SMG documentation then and see whether I can replace the Accepts with SMG calls