Scrolling doesn't seem to work (at least as expected)

[cdg]

Once I have written to line 25 of the screen, subsequent displays go to line 1. How do I get them to go below line 25 (and scroll the screen upward), as would happen with cmd.exe? I've tried "display .... with scroll up 1 line" and "...with scroll down 1 line", but neither seems to work.

[David Wall]

Probably the best way to show what the error you are getting is-
Attach a simple program to show what you are getting - that way people have something to work on and may be able to point you in the right direction.

I personally have NEVER tried to get anything to scroll up the screen - maybe because I tend to always want to know what's on the screen where - so I do my display from a table in W/S.
And my screen displays are 80 lines deep & up to 160 cols wide. (22" monitor) so I use it.

[cdg]

I've adequately described the problem. No "simple program" is going to describe it any better. But here goes.
[skipping Identification division, etc. as totally irrrelevant.]
PROCEDURE DIVISION.
DISPLAY "LINE 1" AT LINE 1.
DISPLAY "LINE 2" AT LINE 2.
DISPLAY "LINE 3" AT LINE 3.
. . .
DISPLAY "LINE 25" AT LINE 25.
DISPLAY "LINE 26" [AT LINE 26] *> DISPLAYS AT LINE 1 OF SCREEN

The reason I NEED it to scroll is precisely so I can see what went before, without it being overwritten. The size of the monitor is irrelevant (and mine is 27"), since you can set the properties of the DOS (CMD) box to thousands of lines, if you wish --- and then scroll via Windoze.

But the behavior of the display statement is NOT correct, and any attempt to display past line 25 results in displaying on line 1. My question is how to make it behave correctly, not how to increase the visible display.

[Anonymous]

Why are you using "AT LINE nn"
If you don't need it, get rid of it.
I believe the display will scroll as you want it to (sans "AT LINE".)

[cdg]

Obviously, I am using "at line" because I need to position the (forms) data I am displaying. My example doesn't go into unnecessary detail that would only confuse the issue. It simply describes and gives an example of a reproducible condition. If you would prefer that I show you an entire 12,000 line program, I suppose it could be arranged, but it would contribute nothing to the discussion.

The problem (bug) I'm reporting is that once "at line" (or any of the extended features) are used, the normal display doesn't work any more. And there is no logical reason for such a restriction.

There are (overly-complicated) ways around this issue, but it means rewriting every display statement in every program being converted, which is unacceptable. And the same applies to the following accept/display bugs as well:
1) If the program uses an extended accept or display, every subsequent accept or display needs to specify column and row, or it will go to line 1 column 1).
2) if the program uses an extended accept or display, subsequent display commands cannot specify more than open operand, i.e. "display variable-or-literal1 variable-or-literal2" will only display the first item at the current cursor position. The other item(s) will be displayed at line 1 column 1.
3) Version 3.1 does NOT display highlight, blink, underline, etc., possibly because of a different pdcurses package, possibly for some other reason, so even if the other items are fixed, we lose capabilities at the same time.
4) The compiler ignores invalid or unimplemented parameters without complaining about them, so we only discover problems (that the complier should report) with extensive debugging.

[Juan Carlos Escartí]

Hi Simon
Advancement in "solutions" for GNU COBOL we have tested a mechanism to generate scrolling screens in those terminals that support it.
It's not very "clean" but it works.
The solution is to define the scroll area with its escape sequence, for example:

       01 DEFINE-SCROLL-SCREEN.
               02 FILLER PIC 99 COMP VALUE 27.
               02 FILLER PIC X(6) VALUE "["
               02 SCROLL-START PIC 99 VALUE 1.
               02 FILLER PIC X VALUE ";".
               02 SCROLL-END PIC 99 VALUE 24.
               02 FILLER PIC X VALUE "r".

And move this to the screen.
The problem is that it cannot be done via the DISPLAY mechanism because it will filter out the escape sequences.
For this we use an iodev environment variable to export the tty from which we connect, it can be put in the bash script to launch the GNUCOBOL program or in the .profile

dd_iodev=`who am i|awk '{ print "/dev/" $2}'`; export dd_iodev

In the COBOL program we use a SEQUENTIAL file that we assign to "iodev", we open it and write to it with WRITE.
In the terminal we are left with the defined Scroll area.
Microfocus has a function in C called cobscroll, which did a similar function.
This will only work on Linux.
If anyone is more interested I can upload an example of a program using this.
Kind regards
Juan Carlos

[Simon Sobisch]

I'm definitely interested in an example program with this solution and the "more easy" variant you'd use with Micro Focus and cobscroll to get the picture (and to possibly be able to add the later in the future).

[Chuck Haatvedt]

Simon & Juan,

I should have a test version of the compiler with this functionality ready by tomorrow afternoon. I've sent Juan a DM requesting some clarification as to exactly how this is implemented by MF.

   Chuck Haatvedt

[Eugenio Di Lorenzo]

Just for your information.
If you need to manage a list of elements (or even file records) on the screen and scroll right, left, down, up... you can use the LISTVIEW.COB program found here:

https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS/GC26LISTVIEW.COB

documentation at:
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS/GC00TT-MANUAL-V02-20210308.odt

[Juan Carlos Escartí]

Thank you very much Eugenio
I'm going to take a look at your program and prepare the sample that replaces cobscroll.
The point is not having to reform the legacy code, and in this case replace cobscroll with a mechanism that provides the same functionality.

[Chuck Haatvedt]

Juan,

from what I can find in the PDCURSES documentation, scrolling vertically is supported. It is indicated as supported in NCURSES as well. So it may be possible to implement this in GNUCOBOL perhaps as a callable function. Let me know if you are interested.

Chuck Haatvedt

[Anonymous]

Juan,

First a bit of an explanation, in order to make GNUCOBOL more portable, it uses CURSES to support all extended screen / display functionality. There are CURSES ports for multiple operating systems.

I've been testing a scrolling program using scrl function from CURSES. It is supported in both PDCURSES and NCURSES variants. I can create a COBSCROLL callable function and implement it for testing in the Multiple Windows version of GNUCOBOL which I'm currently testing.

Please send me a request if you would like to have a test version of GNUCOBOL with the COBSCROLL implemented.

it does support bidirectional scrolling.

====>>> HOWEVER when a line is scrolled off the screen it is gone and can NOT be restored by scrolling in the opposite direction. I don't know if this is the same behavior which the MF COBOL has. I did see that COBSCROLL was only supported via native MF COBOL, so not available in RM or ACCUCOBOL dialects.

There is a CURSES element called a PAD which does allow for this type of vertical and or horizontal scrolling. Think of it as a virtual window of any size larger than the physical terminal screen size. Then you give the coordinates of the location with the pad for the portion of it which is to be displayed on the current window.

    Chuck Haatvedt