358 lines
18 KiB
Plaintext
358 lines
18 KiB
Plaintext
|
|
|
|
|
|
Must have logged on with 8-N-1 for ALL binary transfers!
|
|
|
|
Options: C(rc xmodem), X(modem), B(atch ymodem), Y(modem),
|
|
|
|
K(ermit), A(scii), T(ype)
|
|
|
|
Commands: C,X,B,Y,K,A,T ===> a
|
|
|
|
|
|
Once the transfer starts, you may terminate it by typing a Control-K
|
|
|
|
Type a character to start the transfer when you are ready ===>
|
|
|
|
1/18/87 TROUBLESHOOTING PC PURSUIT CALLS
|
|
(Tips for helping Cust. Svc. help Pursuit callers)
|
|
|
|
This is a list of typical questions about PC Pursuit and some answers that
|
|
should help. I will not swear that everything--or anything--is accurate.
|
|
However, most of the explanations will, at least, help most PC Pursuit
|
|
customers.
|
|
|
|
|
|
GENERAL RULES
|
|
"""""""""""""
|
|
First, listen to what the customer is saying. Some of these guys have more
|
|
experience with data communications than anyone in this building, let alone in
|
|
this department. They will obviously not be impressed if you run on autopilot
|
|
through the typical "are you at 8 bits and no parity" sort of question. Calls
|
|
tend to be one of two types: general, simple informational questions and
|
|
specific technical problems. If you treat one of the latter as if it were one
|
|
of the former, you will do little to convice the customer that you are steering
|
|
him correctly.
|
|
Second, don't be too eager to dump the customer onto someone else or off the
|
|
line. This will make life easier for whoever has to eventually solve the
|
|
problem.
|
|
|
|
|
|
SPECIFIC PROBLEMS
|
|
"""""""""""""""""
|
|
"I can't connect to a port; I keep getting D/DCWAS/12 [or whatever] BUSY."
|
|
----------------------------------------------------------------------------
|
|
|
|
Explain that these are legitimate busies and that port expansion, both in
|
|
adding new cities and in expanding existing rotaries, is underway.
|
|
We *will* be adding several hundred new lines to the system. Many cities
|
|
have already been upgraded, and more are being completed all the time.
|
|
|
|
|
|
"I connect to a port but I get hung. Not even ATZ will appear."
|
|
------------------------------------------------------------------
|
|
|
|
If they're currently in the frozen port (some users know enough to hold it
|
|
open and call us on another line), run a port scan to see where they're
|
|
connected. Reset the port to knock them out, C-space to it, and if you can't
|
|
clear the trouble, busy it out and send a ticket to the field. (This should be
|
|
old hat by now, with the troubles we've recently found in the new DC modems.)
|
|
|
|
If they are not connected, your only approach is to try to connect directly
|
|
to each port and see if any refuses to respond. If you can't find a malfunc-
|
|
tioning modem, make sure the user was entering "ATZ" in capital letters.
|
|
|
|
|
|
"I connect to a port and enter ATZ but everything seems to hang."
|
|
--------------------------------------------------------------------
|
|
Check to see if they are using a Hayes compatible modem. The PCP modems use
|
|
a limited subset of the Hayes "AT" commands. In theory, a working Hayes or
|
|
compatible modem will ignore these commands while in a data transfer state. To
|
|
place such a modem in command mode, the user must rapidly enter three plus
|
|
signs (+) in a row and then wait until the modem acknowledges the command
|
|
before entering any more data.
|
|
|
|
However, malfunctioning modems or some of the not-quite-compatible (usually
|
|
cheaper) modems will act on "AT" commands from within data transfer. When the
|
|
user enters the ATZ command to wake up the PCP modem, it instead resets the
|
|
user's modem, usually dropping the connection. This would also happen if the
|
|
string "ATZ" was encountered during a file transfer.
|
|
|
|
There's not a lot we can do to diagnose this, and PCP users
|
|
take none too kindly to the suggestion that their bargain modems are no
|
|
bargain. As a test, have the user connect to a port and enter one of the Hayes
|
|
commands not supported by the PCP modems--for instance, ATH0, which hangs up
|
|
the modem, or ATH1, which "lifts" it off the hook. If they are actually
|
|
talking to the PCP modem, it will respond with an "OK" and do nothing else; if
|
|
they are talking to their own modem, it will drop carrier.
|
|
|
|
To use PCP successfully, they will either (1) have to replace or repair
|
|
their modem, (2) find a way to disable its break to command mode, or (3) try
|
|
to throw the PCP port into Racal-Vadic mode (with a Ctrl-E). Note that the
|
|
latter solution does not always work unless the modem has been reset with an
|
|
ATZ command--which, of course, is out of the question--and may not always be an
|
|
option, depending on hardware manufacturer and version.
|
|
|
|
I have yet to find an instance of this that was not trouble on the
|
|
customer's end, but I expect we will.
|
|
|
|
|
|
|
|
"I try to call this number from a PCP modem and I get a busy. I dial it
|
|
immediately after hanging up [or from another line] and I get through. I try
|
|
it again on PCP and get a busy."
|
|
--------------------------------------------------------------------------------
|
|
|
|
First, make sure that the number they are dialing is within the accepted
|
|
exchanges for a given city (see the list in the PCP guide). Note that there
|
|
are a few exchanges that can be reached that are not on the list; a slightly
|
|
more up-to-date list is available on the Net Exchange BBS.
|
|
|
|
If the number should be valid, see if you can isolate the port the user is
|
|
calling from. Connect to that port, issue "ATZ", and send the modem a Ctrl-E
|
|
and carriage return. This will throw the modem into Racal-Vadic mode, which
|
|
provides better diagnostics than Hayes mode. Try to dial the number and see
|
|
what transpires. Racal-Vadic mode will report on the absence of a dial tone,
|
|
each ring as it occurs, and the ultimate outcome of the call. Take appropriate
|
|
action. (Also, the new modems--the new ones in DC, not the ones that will be
|
|
used for the expansion--give a "NO DIAL TONE" message from within Hayes
|
|
emulation mode.)
|
|
|
|
If the user is certain that the exchange is local to the PCP city, ask him
|
|
to leave a message to the SysOp (i.e., Dave) on the Net Exchange board.
|
|
If you get a connection or what appears to be a legitimate busy, inform the
|
|
customer and chalk it up to chance and a busy BBS.
|
|
|
|
|
|
|
|
"Sometimes when I connect to a port, I get a message that says 'MANUAL ANSWER'
|
|
and I can't do anything but disconnect."
|
|
-------------------------------------------------------------------------------
|
|
|
|
Since the Racal-Vadic mode provides better diagnostics (see above), many
|
|
users shift into it before dialing their BBS. If they terminate abnormally
|
|
(that is, if the session, not the user, terminates abnormally), the modem may
|
|
be left in Racal-Vadic mode.
|
|
|
|
For instance, User A uses Racal-Vadic mode to call a board. He then gets
|
|
bumped off the line (or perhaps hangs up before returning the modem to Hayes
|
|
emulation) and User B connects to the port before the modem has a chance to
|
|
reset (assuming it resets at all). The modem has sent the Racal-Vadic prompt--
|
|
an asterisk--to User A and is waiting for a command. User B sees no response--
|
|
the prompt has already been sent--so he assumes the modem is in Hayes mode. He
|
|
enters "ATZ" and waits for the "OK". (To make matters worse, perhaps he is
|
|
using a command script that needs to "see" an "OK" before proceeding.)
|
|
|
|
The modem, currently ignorant of Hayes commands, interprets the "A" of the
|
|
"ATZ" as being the Racal-Vadic command to answer a call manually; that is, to
|
|
take the line off-hook and respond to the call. It does so, having first sent
|
|
the user the message "MANUAL ANSWER." Since people rarely dial *into* a PC
|
|
Pursuit line, nothing happens and the modem just sits.
|
|
|
|
To get the user out of this trap, have him enter carriage returns until the
|
|
modem drops the line and prompts him with another "*". At this prompt, have
|
|
the user enter "I". This is a nonintuitive command--the "I" stands for "IDLE"
|
|
--but it has the happy result of returning the modem to Hayes mode.
|
|
|
|
There is a file called rvprimer.txt on the Net Exchange which describes the
|
|
Racal-Vadic mode.
|
|
|
|
|
|
|
|
"I use XMODEM across the system and transfers take twice [or thrice] as long as
|
|
they should. Why?"
|
|
--------------------------------------------------------------------------------
|
|
|
|
As best as I can tell, the information we were passed from the Net Exchange
|
|
BBS was well-meaning but wrong. Here is the scenario as I figger it--someone
|
|
let me know if I'm wrong, too.
|
|
|
|
XMODEM sends data in a 132-byte block that resembles a mini-packet:
|
|
|
|
<------------------------- Direction of transmission
|
|
|
|
[SOH] [#] [#] [DATA] [CHK]
|
|
| | | | |___ "Checksum" (kinda) for error-detection
|
|
| | | |__________ 128 bytes of data
|
|
| | |_______________ "One's complement" of block number
|
|
| |___________________ Block number
|
|
|________________________ Start of header (ASCII 01)
|
|
|
|
|
|
This closely matches the size of a Telenet packet (generally 128 bytes) and
|
|
can, for our purposes, be considered a packet's worth of data. PC Pursuit is
|
|
set to forward data only on full packets and on expiration of idle timers
|
|
(which are set for 1/10 second).
|
|
|
|
The delay occurs because a connection through PC Pursuit goes through four
|
|
modems and two entirely separate data transmissions. Each block of data must
|
|
undergo the following (assuming a download from the BBS to the user):
|
|
_____ _________ __________
|
|
| |____ ( )____ | |
|
|
| BBS | /____( PDN ) /____| PCP user |
|
|
|_____| (_________) |__________|
|
|
|
|
|_______| |_______| |_______|
|
|
| | |_____ 1.1 seconds
|
|
| |_______________ Variable (0.1 to 1+ seconds)
|
|
|_________________________ 1.1 seconds
|
|
|
|
|
|
That's potentially 3+ seconds to transfer data that would take slightly over
|
|
1 second to transmit in a direct connection--maybe 35% efficiency.
|
|
|
|
To make matters worse, the acknowledgment (ACK) from the user to the BBS may
|
|
take upwards of a second--instead of a fraction of a second--to be transmitted
|
|
back into the network, have idle timers expire, be forwarded to the outdialer,
|
|
and be transmitted to the BBS. As you can see, though, the real delay is *not*
|
|
because of the delay in sending the ACK, but because the block size and packet
|
|
size so nearly match, the two computers are almost never working
|
|
simultaneously.
|
|
|
|
A protocol that uses a larger block size--YMODEM, for instance--will run
|
|
faster over the system, but not because it needs fewer acknowledgements.
|
|
Instead, while sending the larger block, it causes data forwarding on a full-
|
|
packet condition. After the first packet gets sent, both machines are doing
|
|
work for most of the rest of the transmission, as such:
|
|
|
|
BBS USER
|
|
""" """"
|
|
Start of 1K block Sends packet 1 Does nothing
|
|
Sends packet 2 Receives packet 1
|
|
Sends packet 3 Receives packet 2
|
|
Sends packet 4 Receives packet 3
|
|
Sends packet 5 Receives packet 4
|
|
Sends packet 6 Receives packet 5
|
|
Sends packet 7 Receives packet 6
|
|
End of 1K block Sends packet 8 Receives packet 7
|
|
Does nothing Receives packet 8
|
|
|
|
|
|
(Of course, the BBS is not really sending the *packet*, just a packet's worth
|
|
of data.) In effect, YMODEM wastes only 2 of every 9 128-byte transfers; it
|
|
should run at about 75% efficiency. In addition, since it only has a single
|
|
ACK per kilobyte (instead of 8), less time is spent in waiting for the idle
|
|
timer to expire.
|
|
|
|
Of course, to make things more confusing, there are XMODEM packages using
|
|
256-byte and 1K blocks and XMODEM packages that allow a "window" of
|
|
unacknowledged blocks to be sent, among other flavors. If the user is using
|
|
one of the strange XMODEMs, he'll usually know enough to mention it.
|
|
|
|
Recently, the default parameters for the PC Pursuit ports were changed; by
|
|
whom, I don't know. For best results, users should break to command mode and
|
|
set X.3 parameters 1 and 10 to 0 (disables break to command mode and word wrap)
|
|
and set ITI parameter 57 to 1 and parameter 63 to 0 (enable 8-bit transparent
|
|
mode). This is all done with similar commands as those issued when connecting
|
|
to Exec PC.
|
|
|
|
|
|
|
|
"I can't use PUNTER protocol across the network."
|
|
-------------------------------------------------
|
|
|
|
I have sent word (through a friend) for Steve Punter to call me to discuss
|
|
what might be going wrong with his procotol for Commodore machines. However,
|
|
as best as I can tell, PUNTER protocol has a severely restrictive time-out
|
|
setting--the amount of time it will wait for an acknowledgement back from the
|
|
receiving site before assuming a block was lost and retransmitting it. As the
|
|
diagram above shows, PC Pursuit introduces a lot of delay into the loop, and
|
|
this is too much for the BBS to take. It starts to send the "lost" block
|
|
again; the receiving station finally receives and acknowledges the block; and
|
|
everything falls apart. (This is complete assumption, by the way; I haven't
|
|
been able to find any hard info on PUNTER, although I am told it works in 256-
|
|
byte blocks.) If this is true, I doubt PUNTER would even work over a satellite
|
|
long-distance connection, so PUNTER BBSs will probably soon offer a "relaxed"
|
|
PUNTER. Often, Commodore users having no luck with PUNTER have been able to
|
|
run successful XMODEM transfers.
|
|
|
|
|
|
|
|
"I have no [or little] trouble downloading from a BBS, but my uploads often
|
|
fail."
|
|
-----------------------------------------------------------------------------
|
|
|
|
This also seems to be related to time-out periods, but I'm not sure.
|
|
Because a 132-byte block will be sent in 2 packets and, thus, activity on
|
|
sending and receiving ends may overlap slightly, it is conceivable that the
|
|
delay between sending the last byte of a data block and receiving the ACK would
|
|
be a tiny bit less than the delay between sending the ACK and receiving the
|
|
first byte of the next block. (Note: Here I am grasping for straws.) If the
|
|
BBS has a particularly unforgiving time-out setting, it might reject the block
|
|
or get out of sync (see the PUNTER hypothesis, above). Several Texas
|
|
Instrument computer users have been able to trick PC Pursuit into handling
|
|
transfers by calling into the networkj at 300 baud but calling out at 1200; I
|
|
haven't the foggiest idea why this works, unless the time-out period is
|
|
relatively more relaxed at the faster speed.
|
|
|
|
|
|
|
|
"I can't get the listing of BBSs on the Net Exchange BBS to download" or "I've
|
|
downloaded the listing of BBSs but can't read it; it's garbage."
|
|
-------------------------------------------------------------------------------
|
|
|
|
Files with the extension .SQ have been squeezed; there are a number of
|
|
slightly different programs and variations for doing this, some compatible with
|
|
others. Many machines have access to some sort of squeezing utility; whether
|
|
or not the file downloaded is in the proper format is another question.
|
|
|
|
Files with the extension .LBR have been libraried; this procedure combines a
|
|
number of files into a single file, usually without data compression. The
|
|
resulting file is easier to download and catalog than the individual files
|
|
would be, and takes up slightly less room. LU is the main program for
|
|
librarying files in the IBM-compatible environment; I know of no comparable
|
|
programs for other machines.
|
|
|
|
Files with the extension .ARC have been archived; this is a technique that
|
|
both squeezes and libraries files. Files are usually archived with ARC, a
|
|
user-supported program distributed by System Enhancement Associates. As far as
|
|
I know, there is only an official ARC for IBM-style computers; I think, but am
|
|
not sure, that there is a compatible program for CP/M-based machines (like the
|
|
Kaypro) and machines running Un*x. I know of no other computers that can make
|
|
use of .ARC files.
|
|
|
|
|
|
|
|
"What do NO CARRIER and NO ERROR CONTROL mean? I saw them in a recent
|
|
connection to Wash D.C. (D/DCWAS)."
|
|
------------------------------------------------------------------------
|
|
|
|
The modems in Wash D.C. are the new Vadic modems, which will also
|
|
support 2400 outdial when deployed. These new modems have expanded response
|
|
messages. NO CARRIER is seen in the Hayes mode when carrier has been
|
|
dropped between the Telenet outdial modem and the target BBS which the
|
|
user dialed. The user still has control of the modem and can dial a
|
|
new number in the city if desired.
|
|
|
|
NO ERROR CONTROL - is displayed whenever one of the new modems is
|
|
connected on-line with the target BBS. It simply means that the outdial
|
|
modem is not in the MNP reliable modem (with local loop error protection).
|
|
You see, MNP is built into these new modems, and that means that when these
|
|
new modems call another modem with MNP in it, they will hand-shake and
|
|
come up in the Microcom reliable mode - which provides error protection in
|
|
the local phone loop. If it is not using MNP and says NO ERROR CONTROL,
|
|
the call will still go through just fine to the remote BBS.
|
|
|
|
|
|
|
|
"How do I get the Racal-Vadic command mode?"
|
|
----------------------------------------------
|
|
|
|
The Hayes command mode is the only officially supported command mode for
|
|
PC Pursuit at this time - to simplify support and ease of use for users.
|
|
However, users may use the R-V mode, which does give some better
|
|
response messages (such as "Dialing", and also has re-dial). To get
|
|
to the R-V mode, type ATZ to get the OK, then ctrl-E and you should
|
|
wake up the modem into the R-V mode as it responds "Hello, I'm ready"
|
|
with a * . Type ? (cr) for a list of the commands available.
|
|
When done with your session, the modem will reset itself into the
|
|
Hayes mode as you enter I (cr) to Idle the modem. (or depending on
|
|
how you disconnect, it will automatically reset to Hayes mode for the
|
|
next user within 10 - 100 seconds).
|
|
|
|
|
|
|
|
Time left = 44 minutes and 51 seconds
|
|
Current download area = pcp
|
|
|
|
Current upload area = upload
|
|
Allowable daily download limit = 5416843 bytes
|
|
|
|
A(rea change) D(ownload) F(ile list) M(ain menu)
|
|
G(oodbye) T(oggle page) ?( help )
|
|
|
|
Commands: A,D,F,M,G,T,? ===> |