Debug (wd) run-time problem

Just installed qnx on a computer for addition to our lab. This machine
will run stand alone for a little while before joining the network. We
have installed Watcom C 10.6 for some testing we will be doing.
Installation went fine. Configuration and startup also fine. The
problem came when we start debug?? We got an error unable to estabilish
virtual terminal ( or words to that affect). We did a little testing
and discovered that if we specify the the console debug will run. I
would guess this to be an environmental element. I have review the
manuals and found nothing that helped. I also reviewed the
configuration of our other systems (2) that run debug just fine.

What have we missed???

Thanks for ideas and suggestions.


Larry

You are being a little unspecific about the error message You got. Does it happen to be ‘Cannot find a free pseudo tty’ ?

If so, it will help to modify Your /etc/config/sysinit… file and start ‘Dev.pty’ using the ‘-n’ option. The online docs say about this option:

-n number
The maximum number of pseudo tty pairs. Device pairs will be numbered incrementally in hexadecimal notation. Values
greater than 16 (f) are possible but are not recommended for UNIX compatibility reasons. (default is 4)

A ‘Dev.pty -n16’ has proven to be sufficient in most cases, whereas the default of 4 may turn out to be little tight, especially when using ‘wd’, which always seems to grab a pseudo tty at startup.


T. Haupt
BitCtrl Systems GmbH


Larry Sams wrote:

Just installed qnx on a computer for addition to our lab. This machine
will run stand alone for a little while before joining the network. We
have installed Watcom C 10.6 for some testing we will be doing.
Installation went fine. Configuration and startup also fine. The
problem came when we start debug?? We got an error unable to estabilish
virtual terminal ( or words to that affect). We did a little testing
and discovered that if we specify the the console debug will run. I
would guess this to be an environmental element. I have review the
manuals and found nothing that helped. I also reviewed the
configuration of our other systems (2) that run debug just fine.

What have we missed???

Thanks for ideas and suggestions.


Larry

Sorry for not being specific. I was at home last night when I wrote this and my notes were at the office. The specific error is:

unable to open system console

I have six consoles loaded at accessible. I can get debug to run with the following command:

wd -console=n program_name

Thanks,


Larry

thomas haupt wrote:

You are being a little unspecific about the error message You got. Does it happen to be ‘Cannot find a free pseudo tty’ ?

If so, it will help to modify Your /etc/config/sysinit… file and start ‘Dev.pty’ using the ‘-n’ option. The online docs say about this option:

-n number
The maximum number of pseudo tty pairs. Device pairs will be numbered incrementally in hexadecimal notation. Values
greater than 16 (f) are possible but are not recommended for UNIX compatibility reasons. (default is 4)

A ‘Dev.pty -n16’ has proven to be sufficient in most cases, whereas the default of 4 may turn out to be little tight, especially when using ‘wd’, which always seems to grab a pseudo tty at startup.


T. Haupt
BitCtrl Systems GmbH

Larry Sams wrote:
Just installed qnx on a computer for addition to our lab. This machine
will run stand alone for a little while before joining the network. We
have installed Watcom C 10.6 for some testing we will be doing.
Installation went fine. Configuration and startup also fine. The
problem came when we start debug?? We got an error unable to estabilish
virtual terminal ( or words to that affect). We did a little testing
and discovered that if we specify the the console debug will run. I
would guess this to be an environmental element. I have review the
manuals and found nothing that helped. I also reviewed the
configuration of our other systems (2) that run debug just fine.

What have we missed???

Thanks for ideas and suggestions.


Larry

If you have a console that has no login running on it (or any
other program, for that matter), wd should find and use it.
This generall means you should remove any reference to one or more
console from the “-t” option to tinit. You might want want more than
one console if your app forks, for example.

Richard


Dixie Sams wrote:

Sorry for not being specific. I was at home last night when I wrote this and my notes were at the office. The specific error is:

unable to open system console

I have six consoles loaded at accessible. I can get debug to run with the following command:

wd -console=n program_name

Thanks,

Larry

thomas haupt wrote:

You are being a little unspecific about the error message You got. Does it happen to be ‘Cannot find a free pseudo tty’ ?

If so, it will help to modify Your /etc/config/sysinit… file and start ‘Dev.pty’ using the ‘-n’ option. The online docs say about this option:

-n number
The maximum number of pseudo tty pairs. Device pairs will be numbered incrementally in hexadecimal notation. Values
greater than 16 (f) are possible but are not recommended for UNIX compatibility reasons. (default is 4)

A ‘Dev.pty -n16’ has proven to be sufficient in most cases, whereas the default of 4 may turn out to be little tight, especially when using ‘wd’, which always seems to grab a pseudo tty at startup.


T. Haupt
BitCtrl Systems GmbH

Larry Sams wrote:
Just installed qnx on a computer for addition to our lab. This machine
will run stand alone for a little while before joining the network. We
have installed Watcom C 10.6 for some testing we will be doing.
Installation went fine. Configuration and startup also fine. The
problem came when we start debug?? We got an error unable to estabilish
virtual terminal ( or words to that affect). We did a little testing
and discovered that if we specify the the console debug will run. I
would guess this to be an environmental element. I have review the
manuals and found nothing that helped. I also reviewed the
configuration of our other systems (2) that run debug just fine.

What have we missed???

Thanks for ideas and suggestions.


Larry

We have noted/reported a similar problem. Our testing seems to indicate that wd cannot use pseudo-teletypes outside the first 16 (‘p’). When those are all engaged, we use the -c= option. Neither QSSL
nor we have ever gotten to the bottom of the problem.

Dixie Sams wrote:

Sorry for not being specific. I was at home last night when I wrote this and my notes were at the office. The specific error is:

unable to open system console

I have six consoles loaded at accessible. I can get debug to run with the following command:

wd -console=n program_name

Thanks,

Larry

thomas haupt wrote:

You are being a little unspecific about the error message You got. Does it happen to be ‘Cannot find a free pseudo tty’ ?

If so, it will help to modify Your /etc/config/sysinit… file and start ‘Dev.pty’ using the ‘-n’ option. The online docs say about this option:

-n number
The maximum number of pseudo tty pairs. Device pairs will be numbered incrementally in hexadecimal notation. Values
greater than 16 (f) are possible but are not recommended for UNIX compatibility reasons. (default is 4)

A ‘Dev.pty -n16’ has proven to be sufficient in most cases, whereas the default of 4 may turn out to be little tight, especially when using ‘wd’, which always seems to grab a pseudo tty at startup.


T. Haupt
BitCtrl Systems GmbH

Larry Sams wrote:
Just installed qnx on a computer for addition to our lab. This machine
will run stand alone for a little while before joining the network. We
have installed Watcom C 10.6 for some testing we will be doing.
Installation went fine. Configuration and startup also fine. The
problem came when we start debug?? We got an error unable to estabilish
virtual terminal ( or words to that affect). We did a little testing
and discovered that if we specify the the console debug will run. I
would guess this to be an environmental element. I have review the
manuals and found nothing that helped. I also reviewed the
configuration of our other systems (2) that run debug just fine.

What have we missed???

Thanks for ideas and suggestions.


Larry