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,? ===>