Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Switching to application mode

12 views
Skip to first unread message

Volker Englisch

unread,
Aug 5, 2011, 4:46:40 PM8/5/11
to
Hi!

Recently I migrated from a old Linux machine to a new FreeBSD one. I've
got several terminals attached to that machine, i.e. DEC VT 510 and
Honeywell Bull. They are all initialized as vt220.

Now there are several applications written in COBOL. On the old Linux
box, there was no problem using function and cursor keys within that
applications.

Now, on the new machine, I watch that COBOL applications switching the
terminals to application mode when they are executed. The function keys
(and the cursor keys) aren't recognized properly any more. When
manually resetting the terminal(s) to normal mode, the application work
fine.

So... Is there any way to prevent the terminals to be switched into
application mode? Maybe some command that locks the terminals before
the application is run and reset the terminal after the app has
terminated?

Besides Putty, I don't see a way to permanently lock the terminals to
not being switched into application mode.

And idea?

TIA
Volker

Volker Englisch

unread,
Aug 8, 2011, 4:27:02 PM8/8/11
to

Really noone with any idea?

Dave Wade

unread,
Aug 8, 2011, 5:39:25 PM8/8/11
to

"Volker Englisch" <env...@efrafa.yagii.de> wrote in message
news:j1pgqm$ea8$1...@viena.rsli.de...

depends. are cobol apps using termcap....

RedGrittyBrick

unread,
Aug 9, 2011, 4:40:10 AM8/9/11
to

As Dave implies, you may be able to amend something relevant (e.g.
initialisation code) from the relevant termcap or terminfo entries. You
can probably use the TERMCAP and/or TERMINFO variable to direct the
program to a custom file/database.

--
RGB

Volker Englisch

unread,
Aug 9, 2011, 5:20:15 AM8/9/11
to
Am 08.08.11 schrieb Dave Wade:

They use ncurses, which itself makes use of termcap.

When changing the TERM environment, the behaviour of the apps changes,
too. But, I didn't find any termcap entry that works _and_ solves that
problem...

Volker Englisch

unread,
Aug 9, 2011, 8:29:33 AM8/9/11
to
Am 09.08.11 schrieb RedGrittyBrick:

Any pointer to a detailed description of the termcap database? I tried
to find out what entry in the termcap is responsible for switching
into application mode, but I can't find a explanation of the entries.

RedGrittyBrick

unread,
Aug 9, 2011, 11:34:26 AM8/9/11
to

I don't know of a really good online description (other than the man pages)

I have O'Reilley's "Termcap & Terminfo"

is= Initialization string for terminal initialization
if= Initialization file containing long initialization string
rs= Reset string: reset terminal to sane modes.
rf= Reset file

--
RGB

RedGrittyBrick

unread,
Aug 9, 2011, 11:41:39 AM8/9/11
to
>>>>> Really noone with any idea?
>>>>
>>>> depends. are cobol apps using termcap....
>>>
>>> As Dave implies, you may be able to amend something relevant (e.g.
>>> initialisation code) from the relevant termcap or terminfo entries. You
>>> can probably use the TERMCAP and/or TERMINFO variable to direct the
>>> program to a custom file/database.
>>
>> Any pointer to a detailed description of the termcap database? I tried
>> to find out what entry in the termcap is responsible for switching
>> into application mode, but I can't find a explanation of the entries.
>
> I don't know of a really good online description (other than the man pages)
>
> I have O'Reilley's "Termcap & Terminfo"
>
> is= Initialization string for terminal initialization
> if= Initialization file containing long initialization string
> rs= Reset string: reset terminal to sane modes.
> rf= Reset file
>

P.S. The VT100 escape sequences are

\E[?1h cursor key application mode on
\E[?1l cursor key application mode off
\E= keypad application mode on
\E> keypad application mode off

according to http://vt100.net/docs/vt100-ug/chapter3.html

--
RGB

Volker Englisch

unread,
Aug 9, 2011, 4:07:19 PM8/9/11
to
Am 09.08.11 schrieb RedGrittyBrick:

> On 09/08/2011 16:34, RedGrittyBrick wrote:
>> I don't know of a really good online description (other than the man pages)
>>
>> I have O'Reilley's "Termcap & Terminfo"

Maybe it's worth of buying for me, too..

>> is= Initialization string for terminal initialization
>> if= Initialization file containing long initialization string
>> rs= Reset string: reset terminal to sane modes.
>> rf= Reset file
>>
>
> P.S. The VT100 escape sequences are
>
> \E[?1h cursor key application mode on
> \E[?1l cursor key application mode off
> \E= keypad application mode on
> \E> keypad application mode off
>
> according to http://vt100.net/docs/vt100-ug/chapter3.html

Great! Thanks a lot! With this information, I'll find the responsible
entries.

Dave Wade

unread,
Aug 13, 2011, 5:55:40 PM8/13/11
to

"Volker Englisch" <env...@efrafa.yagii.de> wrote in message

news:j1qu4f$jol$1...@viena.rsli.de...

> blem...

In that case you will have to craft your own entry. Do you still have the
Linux machine so you can compare entries?

Volker Englisch

unread,
Aug 14, 2011, 12:08:10 PM8/14/11
to
Am 13.08.11 schrieb Dave Wade:

The Linux machine isn't actually within reach. I'm just trying another
approach - starting the cobol application with "displaying" the suitable
code for switching to normal mode before the screen is built.

If this doesn't lead to success, I'll revive the Linux machine.

Bart Lindsey

unread,
Aug 16, 2011, 8:48:01 PM8/16/11
to

Hi Volker,

In particular, compare the "te" entry in TERMCAP between the bsd
system and the linux system. (TERMINFO equiv is "rmcup").

I reckon you'll find the linux system is sending something extra to
reset the terminal state (enabling cursor keys etc) when you exit the
cobol applications.

I find on linux I need to add the -X argument to the less command to
stop linux from sending the "te" sequence which blanks the screen when
I exit from less. I find this very annoying. I don't have to do this
on any other flavour of *nix.

Bart.

Volker Englisch

unread,
Aug 17, 2011, 4:13:04 PM8/17/11
to
Am 17.08.11 schrieb Bart Lindsey:

Hi Bart,

> In particular, compare the "te" entry in TERMCAP between the bsd
> system and the linux system. (TERMINFO equiv is "rmcup").

i tried to boot the linux system once again, it failed with errors at
the self test stage. On the weekend, I'll try to fix that, maybe with
success...

>
> I reckon you'll find the linux system is sending something extra to
> reset the terminal state (enabling cursor keys etc) when you exit the
> cobol applications.

I catched the output of the app on the BSD machine, a hexdump of the
first and last characters reads like this:

00000000 1b 5b 31 3b 32 34 72 1b 5b 6d 1b 5b 3f 37 68 1b |.[1;24r.[m.[?7h.|
00000010 5b 3f 31 68 1b 3d 1b 5b 48 1b 5b 4a 20 1b 5b 48 |[?1h.=.[H.[J .[H|
00000020 1b 5b 4a 45 48 1b 5b 36 43 1b 5b 31 3b 32 37 48 |.[JEH.[6C.[1;27H|
00000030 1b 5b 31 6d 20 20 20 20 42 55 43 48 55 4e 47 53 |.[1m BUCHUNGS|
[...]
000004a0 34 3b 34 35 48 1b 5b 37 3b 33 32 48 1b 5b 32 34 |4;45H.[7;32H.[24|
000004b0 3b 31 48 0d 1b 5b 3f 31 6c 1b 3e |;1H..[?1l.>|
000004bb

At the end, I see the ESC > sequence to reset the keypad. But sending
that code at the beginning of the screen section of the cobol app just
ends up in displaying "'[>" on the screen.

Weird thing. I hope I will be able to bring the Linux machine up again
to compare the dumps. Well, that machine is 12 years old :-)

> I find on linux I need to add the -X argument to the less command to
> stop linux from sending the "te" sequence which blanks the screen when
> I exit from less. I find this very annoying. I don't have to do this
> on any other flavour of *nix.

I never cared about that. If the Linux machine comes up again, I'll try
that, too. Just tested on FreeBSD - as you mentioned, it doesn't blank
the screen without the "-X"...

Volker

Volker Englisch

unread,
Aug 19, 2011, 12:08:16 PM8/19/11
to
Am 17.08.11 schrieb Volker Englisch:

Shame on me :-( First of all, the string for putting the keypad into
application mode was found in "ks" field of the termcap. I changed that
entry, but nothing changed in the behavior.

Well, at last I found out why. On FreeBSD, the program cap_mkdb must be
run for the changes being recognized :-(

Now all works as expected. Thanks to all out there!

Volker

0 new messages