SOUP packet downloading peculiarity with PCPLUS
Jonathan Berry
Support couldn't help with this.
For several years I used the 1986 shareware version of Procomm (for
DOS) for scripted mail-and-news SOUP packet transmission. It
worked fine. But it didn't support higher than 19200 bps.
When I found for $5 a ProcommPlus package (with the diskette
envelopes still sealed!) at Literacy Nanaimo, it seemed too
good to be true.
The conversion was a bit annoying, as all the .CMD scripts had
to be converted to .ASP scripts (in most cases all that was
required was proc main at the beginning and end proc at the
end, but there were some inconsistencies such as pause "1" in a
.CMD file but pause 1 in .ASP) and then compiled.
At the beginning, I used ProcommPlus's "Auto Download" feature
but eventually turned it off because in maybe 20% of cases, it
would hang (= reset button) Windows 95.
Anyway, I now have 38,4 or maybe 115,5 or whatever, but a
peculiar thing happens about 75% of the time.
Here is an annotated log (>) file.
> The SOUP packet is 13383 bytes in size.
>
> Do you want to download it now? (Y/n) Yes
The script file feeds islandnet.com ^M, a blank line.
This activates the default response (Yes) and the script
then downloads via zmodem the SOUP packet island.sup
Now control returns to islandnet.com:
> Home> **
This is the peculiarity, about 80% of the time.
The ** should not appear. It is a zmodem initialization
string. I'm guessing that it was issued by ProcommPlus. I'm
not sure whether it was the initialization string for the file
transfer that islandnet.com failed to clear from its input
buffer (therefore a peculiarity of islandnet.com), OR a
duplicate copy of the initialization string (a bug in Procomm).
Remember, auto-download is set OFF, so that should not happen.
OR, am I doing something wrong?
> "**" is an unrecognised command.
> Home> B0100000027fed4
> "B0100000027fed4" is an unrecognised command.
> Home>
> " " is an unrecognised command.
> Home> bye
>
> Are you sure you want to quit and hangup? (Y/n) Yes
>
So the script successfully transacts the SOUP packets and logs
off, but I just don't like the garbage in between.
Here is the critical portion of the .ASP script
transmit "soup^M"
waitfor "now?" 300
set dldir "f:\maxth\comm\"
transmit "^M"
pause 1
getfile zmodem
WAITFOR "Home>"
transmit "^M"
transmit "bye^M"
pause 2
transmit "^M"
pause 5
hangup
quit
--
cheers,
Jonathan
Mark Morley
Jonathan Berry (jbe...@islandnet.com) wrote:
: This is the peculiarity, about 80% of the time.
: The ** should not appear. It is a zmodem initialization
: string. I'm guessing that it was issued by ProcommPlus. I'm
: not sure whether it was the initialization string for the file
: transfer that islandnet.com failed to clear from its input
: buffer (therefore a peculiarity of islandnet.com), OR a
: duplicate copy of the initialization string (a bug in Procomm).
: Remember, auto-download is set OFF, so that should not happen.
: OR, am I doing something wrong?
When Island Net starts a Z-Modem download, it's a completely independent
program that does it. In other words, there's no buffer to clear here.
It's possible that your end is simply echoing back part of what our end
sends it, and this is being "typed in" at the Home> prompt after
everything is done, but more likely it's generated on your end.
: transmit "soup^M"
: waitfor "now?" 300
: set dldir "f:\maxth\comm\"
: transmit "^M"
: pause 1
: getfile zmodem
Some Z-modem implementations will try to initiate the download rather than
wait for the sender to do so. I expect that's what might be happening
here. Both sides are sending the code to initiate a download, when only
one is desired (but neither are actually necessary). I don't think it was
ProComm, but I do remember using one comm program that did this once. It
had an option to turn off the auto-whatever-thingy in one of the menus.
Mark
Martin Hunt
In article <09AA14mi...@islandnet.com>,
jbe...@islandnet.com (Jonathan Berry) wrote:
>> "**" is an unrecognised command.
>> Home> B0100000027fed4
>> "B0100000027fed4" is an unrecognised command.
...
>So the script successfully transacts the SOUP packets and logs
>off, but I just don't like the garbage in between.
FWIW, I get the same string of garbage, characters, whatever
when I do a Zmodem transfer using QuickLink. I think the
characters are coming from Islandnet's Zmodem program. In
any case, they don't seem to do any damage; something over
95% of the time, Zmodem trasfers up or down go without a
hitch. The other 5%, they hang after the file transmission
is completed, and I have to hang up the modem. (sorry!)
--
Cogito, ergo sum. FAQs: http://www.ncf.carleton.ca/~av282/
L. Ron Hubbard: "Clears do not get colds." - Dianetics.
David Miscavige: "I guess one could." - Koppel interview.
Jonathan Berry
In article <OVQA1Mdl...@islandnet.com>,
mar...@islandnet.com (Martin Hunt) wrote:
:In article <09AA14mi...@islandnet.com>,
:jbe...@islandnet.com (Jonathan Berry) wrote:
:
:>> "**" is an unrecognised command.
:>> Home> B0100000027fed4
:>> "B0100000027fed4" is an unrecognised command.
:
:...
:
:>So the script successfully transacts the SOUP packets and logs
:>off, but I just don't like the garbage in between.
:
:FWIW, I get the same string of garbage, characters, whatever
:when I do a Zmodem transfer using QuickLink. I think the
:characters are coming from Islandnet's Zmodem program. In
:any case, they don't seem to do any damage; something over
:95% of the time, Zmodem trasfers up or down go without a
:hitch. The other 5%, they hang after the file transmission
:is completed, and I have to hang up the modem. (sorry!)
That could be a bummer, especially in an unattended session.
About 15% of the time, ProcommPlus "auto download" Zmodem
transmissions hang Win95 (reset button), *before* transmission
starts.
Procomm did not have a Zmodem protocol, I had to use Texas
Zmodem as an external program. ProcommPlus does have Zmodem
built in, but maybe I should still use TXZM as an external
protocol! It certainly was reliable.
--
cheers,
Jonathan
Jonathan Berry
In article <6dp9u6$6j2$2...@news.islandnet.com>,
ma...@islandnet.com (Mark Morley) wrote:
:Jonathan Berry (jbe...@islandnet.com) wrote:
:
:: This is the peculiarity, about 80% of the time.
:: The ** should not appear. It is a zmodem initialization
:: string. I'm guessing that it was issued by ProcommPlus. I'm
:: not sure whether it was the initialization string for the file
:: transfer that islandnet.com failed to clear from its input
:: buffer (therefore a peculiarity of islandnet.com), OR a
:: duplicate copy of the initialization string (a bug in Procomm).
:: Remember, auto-download is set OFF, so that should not happen.
:: OR, am I doing something wrong?
:
:When Island Net starts a Z-Modem download, it's a completely independent
:program that does it. In other words, there's no buffer to clear here.
That's interesting. So it operates differently from, say, the
file delete command, which does operate with a buffer. For
example, when you type del myfile <return> y <return>, it will
always delete myfile, it won't ask you again to confirm.
:It's possible that your end is simply echoing back part of what our end
:sends it,
Maybe, but why would Procomm do that? Echoing back characters
without a purpose strikes me as a recipe for disaster, and I
would think comms programmers would avoid it like the plague.
Enough can go wrong without that.
:and this is being "typed in" at the Home> prompt after
:everything is done, but more likely it's generated on your end.
:
:: transmit "soup^M"
:: waitfor "now?" 300
:: set dldir "f:\maxth\comm\"
:: transmit "^M"
:: pause 1
Eureka! When I change the above line to
pause 5
everything works properly.
:: getfile zmodem
:
:Some Z-modem implementations will try to initiate the download rather than
:wait for the sender to do so. I expect that's what might be happening
:here. Both sides are sending the code to initiate a download, when only
:one is desired (but neither are actually necessary). I don't think it was
:ProComm, but I do remember using one comm program that did this once. It
:had an option to turn off the auto-whatever-thingy in one of the menus.
:
Let's assume that ProcommPlus sends a zmodem initialization
string. We also know that the islandnet.com shell takes one or
two or three seconds to respond to any command. In the earlier
case, with the garbage, I was bringing up the ProcommPlus
'getfile zmodem' after 1 second. It would immediately send an
initialization string. But the islandnet.com zmodem program
has not fired up. When it does, it issues its own
initialization string and then the transaction takes place
normally. But where does the initialization string go?
But when pause is 5, then 5 seconds is plenty of time for
islandnet.com to fire up its zmodem program, and the program
itself either swallows the procommplus initialization string,
or suppresses it by sending its own first.
So the response of the system is different, depending on the
pause setting and also on server load.
I still think there's a buffer (at least, that's what I'd call
it) at play.
I wonder, are common executables held on a ramdisk, or are they
retrieved from the hard drive?
And while I'm asking weird questions: in the shell, I like to
quit, sign off, but I know there is "no harm done" if the
connection is broken suddenly. Is it better to sign off, or
just hang up?
--
cheers,
Jonathan
Mark Morley
Jonathan Berry (jbe...@islandnet.com) wrote:
: :When Island Net starts a Z-Modem download, it's a completely independent
: :program that does it. In other words, there's no buffer to clear here.
: That's interesting. So it operates differently from, say, the
: file delete command, which does operate with a buffer. For
: example, when you type del myfile <return> y <return>, it will
: always delete myfile, it won't ask you again to confirm.
Yes, it's different. The delete command is internal to the shell. File
transfer protocols are all external executables. There's no way for data
generated by one of the external executables to wind up in the Home>
prompt buffer unless the data is being echoed back from the client's side.
I'm not saying this is happening, just that it's the only way for data
generated by OUR side to get stuffed into the input buffer.
: Maybe, but why would Procomm do that? Echoing back characters
: without a purpose strikes me as a recipe for disaster, and I
: would think comms programmers would avoid it like the plague.
: Enough can go wrong without that.
Agreed, that's why I think it's more likely that ProComm is firing out
it's own start-up string.
: Let's assume that ProcommPlus sends a zmodem initialization
: string. We also know that the islandnet.com shell takes one or
: two or three seconds to respond to any command. In the earlier
: case, with the garbage, I was bringing up the ProcommPlus
: 'getfile zmodem' after 1 second. It would immediately send an
: initialization string. But the islandnet.com zmodem program
: has not fired up. When it does, it issues its own
: initialization string and then the transaction takes place
: normally. But where does the initialization string go?
You fire up ProComm and tell it to begin downloading. At that point it
sees no evidence of Z-Modem on the other end, so it sends it's own
start-up string, which goes into the shell's input buffer. Then the shell
fires up Zmodem, which sends it's own start-up string to ProComm. Things
proceed normally. After the transfer the Home> prompt returns and the
portion of the string sent from ProComm that is still in the command line
buffer is displayed just as if you had typed it in yourself.
: But when pause is 5, then 5 seconds is plenty of time for
: islandnet.com to fire up its zmodem program, and the program
: itself either swallows the procommplus initialization string,
: or suppresses it by sending its own first.
Could be either way, but the key seems to be to not have ProComm start
Z-Modem until it begins on our end. By the way, the pause on our end is
intentional. When I first wrote the shell there were problems with some
people's SOUP/QWK scripts when I fired up the download protocols two
quickly. Can't recall exactly what the problem was now, just that users
requested a delay be added. It's only 1 second (although the UNIX OS may
actually pause as long as 2 seconds). I'd have to check, but the Zmodem
program itself may have another 1 second pause in it.
: I wonder, are common executables held on a ramdisk, or are they
: retrieved from the hard drive?
Only a small fraction of Island Netters use the shell, so placing
executables in a RAM disk would basically be a waste of memory.
: And while I'm asking weird questions: in the shell, I like to
: quit, sign off, but I know there is "no harm done" if the
: connection is broken suddenly. Is it better to sign off, or
: just hang up?
To us it doesn't make a big difference, your call just gets logged with a
"lost-carrier" termination cause instead of "host-requested". It'll save
you a second or two of connect time if you log out "properly" though, as
there can be a small delay while the modem waits for the carrier to resume
(protects against carrier "brown-outs") and then signals the host that
you're gone.
Mark