gcook@cps3xx.UUCP (Greg Cook) (07/17/89)
From article <3816@cps3xx.UUCP>, by gcook@cps3xx.UUCP (Greg Cook): > Recently, someone posted a request for help concerning procomm not being > able to find the dialing directory. I have just started to experience > the same difficulty. Whoever you were, do you know how to fix it? I seem to have found the problem, but it doesn't make sense to me. I have some programs that I install in my autoexec.bat such as kbfix2 and dosedit. I used the "> nul" to redirect the output to nothing so I won't see the messages those programs put on the screen. However, if I do this, procomm has problems. It won't find the dialing directory, it won't run command.com when using DOS gateway, and it won't run script files (cmd files). If I use > nul on only some of the programs, then procomm only acts up on some things (ie. it loads dialing directory, but won't do DOS gateway). This is very puzzling to me. I have two questions: 1. What exactly is the "nul" ? 2. Why is this affecting PROCOMM? Greg Cook gcook@horus.cem.msu.edu cook@frith.egr.msu.edu
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (07/17/89)
In article <3817@cps3xx.UUCP> gcook@cps3xx.UUCP (Greg Cook) writes: >I >have some programs that I install in my autoexec.bat such as kbfix2 and >dosedit. I used the "> nul" to redirect the output to nothing so I >won't see the messages those programs put on the screen. However, if >I do this, procomm has problems. When you execute something from autoexec.bat, and that thing makes itself memory-resident, and if its output has been redirected to something, some strange undocumented things happen inside MS-DOS. I suspect some files are remaining open permanently. (When the TSR's non-resident part exits, MS-DOS doesn't seem to close all its open files.) Why this should affect Procomm I don't know. Maybe you don't have FILES=xx large enough in your CONFIG.SYS file, and the one extra permanently open file is enough to cause Procomm to run out of file handles. -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi
kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/17/89)
In article <3817@cps3xx.UUCP> gcook@cps3xx.UUCP (Greg Cook) writes:
* From article <3816@cps3xx.UUCP>, by gcook@cps3xx.UUCP (Greg Cook):
* > Recently, someone posted a request for help concerning procomm not being
* > able to find the dialing directory. I have just started to experience
* I seem to have found the problem, but it doesn't make sense to me. I
* have some programs that I install in my autoexec.bat such as kbfix2 and
* dosedit. I used the "> nul" to redirect the output to nothing so I
* won't see the messages those programs put on the screen. However, if
* I do this, procomm has problems. It won't find the dialing directory,
* it won't run command.com when using DOS gateway, and it won't run
* script files (cmd files).
* If I use > nul on only some of the programs, then procomm only acts
* up on some things (ie. it loads dialing directory, but won't do
* DOS gateway). This is very puzzling to me.
I think you deserve to be puzzled by this one! It's probably _never_
a good idea to redirect the ouput of a TSR program, anyhow. Two
reasons... you may miss seeing messages (not necesarily 'ERRORS') taht
would let you know you are doing effectively unkind things to your system;
and programs (not just Procomm) that get down and low and use DOS or
BIOS interrupt vectors (even using them perfectly properly :-) ) may
end up just a bit confused.
*
* I have two questions:
*
* 1. What exactly is the "nul" ?
well, "nul" is not-a-file, or file-to-nowhere, or ignore-all-write-calls,
depending on which version of what level of whose port of DOS you have.
so, depending on your system configuration, there's mostly no way to
tell what really happens when a program thinks it's writing stdout that
happens to be redirected to nul.
* 2. Why is this affecting PROCOMM?
and when a TSR terminates, but does not get fully cleaned-out from memory,
whatever or nothing DOS may do with it's standard-out is not easy to
determine, and if the redirection is at some level lower than the level
of ignore-the-PROGRAM'S-write-calls, you may end up with other programs'
standard-out (and standard-in and con and kbd and ???) rather snarled
-------
BUT, REALLY, all of this is really _not_ likely to _really_ do any damage,
because most DOS versions end up keeping things reasonably cleaned-up.
------
What you really NEED to do is to give Procomm (and everthing else) a
reasonable amount of explicit info to work on, i.e.
SET the PROCOMM environment variable;
USE the PATH command;
ENSURE that PATH leads to a place where COMMAND.COM lives;
SET COMSPEC so that DOS and other things (like Procomm) explicitly
know where to find COMMAND.COM.
-----
regardz,
Ken
*
* Greg Cook
* gcook@horus.cem.msu.edu cook@frith.egr.msu.edukleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) (07/17/89)
In article <8234@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: * In article <3817@cps3xx.UUCP> gcook@cps3xx.UUCP (Greg Cook) writes: * >I * >have some programs that I install in my autoexec.bat such as kbfix2 and * >dosedit. I used the "> nul" to redirect the output to nothing so I * >won't see the messages those programs put on the screen. However, if * >I do this, procomm has problems. * When you execute something from autoexec.bat, and that thing makes * itself memory-resident, and if its output has been redirected to * something, some strange undocumented things happen inside MS-DOS. I * suspect some files are remaining open permanently. (When the TSR's * non-resident part exits, MS-DOS doesn't seem to close all its open * files.) * Why this should affect Procomm I don't know. Maybe you don't have * FILES=xx large enough in your CONFIG.SYS file, and the one extra Re: my earlier followup: ASIDE from clobbered internal paths to files which _are_ unlikely, Rahul has _this_ one RIGHT. I had forgotten about it, but it _is_ _very_ _easy_ _to_ _get_ _into_. * permanently open file is enough to cause Procomm to run out of file * handles. ---- Ken
Ralf.Brown@B.GP.CS.CMU.EDU (07/18/89)
In article <3817@cps3xx.UUCP>, gcook@cps3xx.UUCP (Greg Cook) wrote: }[ProComm not finding various files] }I seem to have found the problem, but it doesn't make sense to me. I }have some programs that I install in my autoexec.bat such as kbfix2 and }dosedit. I used the "> nul" to redirect the output to nothing so I }won't see the messages those programs put on the screen. However, if }I do this, procomm has problems. It won't find the dialing directory, }it won't run command.com when using DOS gateway, and it won't run }script files (cmd files). } }If I use > nul on only some of the programs, then procomm only acts }up on some things (ie. it loads dialing directory, but won't do }DOS gateway). This is very puzzling to me. } }I have two questions: } }1. What exactly is the "nul" ? The NULL device--anything sent to it goes to the bit bucket. }2. Why is this affecting PROCOMM? It seems that DOS doesn't close open files when a program goes TSR. Since the ">NUL" redirection opens a file for the duration of the program, that file stays open after the program goes TSR (files ARE closed on non-TSR termination). ProComm then cannot open various files because DOS doesn't have enough internal file table entries. The solution is to increase the FILES= statement in CONFIG.SYS. You should set it to FILES=20 or higher (each additional file uses 53 bytes of RAM). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? PROGRAM n. A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunies for reward. -- from a flyer advertising for _Inside_Turbo_Pascal_
Ralf.Brown@B.GP.CS.CMU.EDU (07/18/89)
In article <277@gvlv2.GVL.Unisys.COM>, kleonard@gvlv2.GVL.Unisys.COM (Ken Leonard) wrote: }* 1. What exactly is the "nul" ? }well, "nul" is not-a-file, or file-to-nowhere, or ignore-all-write-calls, }depending on which version of what level of whose port of DOS you have. All versions of DOS 2 and up that I am aware of have a NUL character device that simply returns success on all write calls, and returns zero bytes on any read calls. Under DOS 1.x, an explicit check was made for a number of devices (since there were no device drivers yet), one of them being NUL. If NUL was selected, DOS simply threw away the output. Interestingly enough, the NUL device is not replaceable, since DOS hangs it onto the front of the device driver chain after CONFIG.SYS runs (so the built-in NUL is always the first device in the chain--that's how programs which trace the device chain are able to find the chain). -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? PROGRAM n. A magic spell cast over a computer allowing it to turn one's input into error messages. tr.v. To engage in a pastime similar to banging one's head against a wall, but with fewer opportunies for reward. -- from a flyer advertising for _Inside_Turbo_Pascal_
gcook@cps3xx.UUCP (Greg Cook) (07/18/89)
From article <24c29f1b@ralf>, by Ralf.Brown@B.GP.CS.CMU.EDU: > In article <3817@cps3xx.UUCP>, gcook@cps3xx.UUCP (Greg Cook) wrote: > }[ProComm not finding various files] > It seems that DOS doesn't close open files when a program goes TSR. Since the > ">NUL" redirection opens a file for the duration of the program, that file > stays open after the program goes TSR (files ARE closed on non-TSR > termination). ProComm then cannot open various files because DOS doesn't have > enough internal file table entries. The solution is to increase the FILES= > statement in CONFIG.SYS. You should set it to FILES=20 or higher (each > additional file uses 53 bytes of RAM). Sure enough, I went back to look at my config.sys and it said "files = 8" I increased it to 20 and all is working well now! Thanks to everyone who responded to my posting. Greg Cook gcook@horus.cem.msu.edu cook@frith.egr.msu.edu
maa@nbires.nbi.com (Mark Armbrust) (07/18/89)
In article <24c29f1b@ralf> Ralf.Brown@B.GP.CS.CMU.EDU writes: > >It seems that DOS doesn't close open files when a program goes TSR. Since the >">NUL" redirection opens a file for the duration of the program, that file >stays open after the program goes TSR (files ARE closed on non-TSR >termination). I just looked at my 3.30 disassembly, this is indeed true. I'd guess that the rationale for this was that the TSR was going to use the files later in its life. There's only one problem with this -- MS didn't tell programmers how to save/change/restore the PID within the TSR so that it could use these files that were so [in]conveniently left open! -- Mark Armbrust maa@nbires.nbi.com maa@nbires.UUCP
mike@point.UUCP (Mike Andrews) (07/19/89)
The one command that you could have deleted from your autoexec that will cause trouble with PROCOMM Plus is the SET PCPLUS=C:\PATH command. PROCOMM Plus checks that environment variable to find out where its files are. For Procomm 2.42 it should be SET PROCOMM=PATH.
wek@point.UUCP (Bill Kuykendall) (07/20/89)
>are. For Procomm 2.42 it should be SET PROCOMM=PATH.
Make sure that you include a trailing backslash on the path. e.g.
SET PROCOMM=C:\\PROCOMM\\ in your autoexec.bat. At one point, (I think this
bug was fixed but I don't remember) it was necessary to copy command.com
into the directory that contained procomm's support files as well.
There is also a known bug (I think it's in 'DOS, not Procomm, as it affects
Ventura Publisher and CSAM Picture Perfect as well) that causes programs to
exibit variably strange behavior if there are more than about 1330 bytes
in your environment (regardless of the assigned size). Procomm is one of
the programs affected by this. I've seen this behavior under IBM 3.2 and
Compaq 3.31 Doses.
(In the path statement above, one backslash is needed in each location. My
editor interprets these, so there are two. If you see two, ignore the
seconds |*) )
Bill Kuykendall
...ddsw1!point!wek