XEROXBUSINESS SYSTEMSSystems Development DepartmentTo:Gateway AdministratorsDate:March 23, 1981 12:04 AMFrom:Hal Murray Org:SDD/CommSubject:Alto Gateway Operation Filed:[IVY]Mesa6>AltoGateway.pressThis memo documents the operation of the Mesa 6 version of the Alto Gateway program. You areassumed to be reasonably familiar with Altos. Familiarity with Mesa and the Tools environmentwill be very helpful.I have avoided any details of the current network topology since it is changing frequently. Thereare two documents that are very helpful when trying to track down network troubles. They are[MAXC2]NetTopology.press and [IVY]Pup-Network.txt. Isuggest that you keep a reasonably up to date copy handy.0. Changes since the Mesa 5 versionThere have been several major changes in the Gateway program since Mesa 5.The user interface has changed drastically. The Gateway program now uses the Toolsinterface. You will need SysFont.strike on your disk.The name of the typescript file has changed from Mesa.typescript to Gate.typescript.The name of the parameter file has changed. User.cm now contains a pointer to the realparameter file, which is now named hostname.txt, where hostname is the name of theGateway. The format of the parameter file has changed drastically. The details aredescribed in GateParameter.press.The Gateway program now includes an FTP Server TimeChecker, LineWatcher,NetWatcher, and HostWatcher.The boot server now make occasional long range probes. This will propagate new versionsof boot files past Gateways that don't have enough room for them on their disk.Password protection is now available for dialup lines and the FTP server.The EFTP portion of the GateControl Server has been removed. Use FTP to store and/orretrieve files.1. Normal OperationPower Up and suchThere is nothing special about turning the power on or off for an Alto that is being used asa Gateway.Starting the Gateway Program%D`vp!^Bqi O\rX Xst)s-t Tst )s-t Qqstu)s-t% K>U ID H6 EQE CS BIv"tNOvt @9 ;u# 9 tJ6(5461 I.N-Vrt rt+G *N vt'iY'Z!%#X!}OIM/ \u wrtD *r >/XUAlto Gateway Operation2Type the command Gateway followed by carriage return. The program will read theparameter file, turn off the display, pause for a while, and finally print the message "AltoGateway of date-time in operation". Since the display is normally off, you won't be able tosee the last message. Control-Shift-D should turn the screen back on. At this point theGateway program is running. It takes a few seconds for new routing information to bepropagated throughout the inter-network, more if a packet gets lost, so it may not bepossible for connections to be established through the Gateway immediately.After the Gateway proper is running, other servers, primarily as the Boot Server and TimeServer, are started sequentially.The Alto DisplayThe Gateway program uses the Tools environment to control the display, mouse andkeyboard. (The Tools environment is also used by the Mesa Debugger, so most Mesaprogrammers will be able to give you a quick introduction.) If you are not familiar with theTools environment, you should probably read the Tools User's Guide from[Iris]Doc>TUG-main.press.The display is normally turned off while the Gateway program is starting. This conservesCPU cycles. Normally the screen will be all black. Control-Shift-D will complement theON/OFF state of the display. Control-Shift-I will invert the black/white mode of thedisplay. If you type anything on the keyboard, even while the display is off, the screen willblink to let you know that the program is still alive.There is a background process that wakes up every 1/4 second. If the display is off, itsmashes the cursor to a big G, moves the cursor down one step, and moves the cursor rightone step for each packet that was forwarded since the last time the process got to run.Actually, that description is a bit misleading. The background process really moves themouse. The Tools keyboard watching process then moves the cursor to track the mouse.That's why the cursor will momentarily switch to other strange shapes as it wanders acrossthe screen. If the cursor overflows the bottom or right edge, it wraps around and starts overagain. If the display is on, cursor is not moved. When you turn the display on, the cursorwill probably be left as a big G. It will get fixed up it you move it across a windowboundary.Most messages printed on the screen are also saved in Gate.typescript.If the Gateway has an SLA line driven by an EIA board, there are troubles keeping theclock accurate when the display is on. To avoid sending out bogus information, the PupTime Server is disabled whenever the display is turned on. It is automatically reset whenthe display goes off.Gateway Program CommandsThe Gateway program has a simple menu driven command interpreter. Again, it uses the Toolsinterface, so if you have problems figuring out how to do things, find a Mesa programmer to helpyou (it won't take long) and/or look at the Mesa Debugger documentation. Remember, if you areusing an EIA board, the time server is disabled whenever the display is on. This discussion does notmention many of the obscure operations that are possible. If you discover an interesting one that Ileft out, please tell me so that I can update this memo.GateThis menu is available when the mouse is within the main Alto Gateway window,or when the mouse in not inside any window.GateThis will print out a summary of various operating statistics, including the fuGbtvt/`1+_ rt2]B\;Z-(YKV!$5T! QrNt1MO5KEJGBHvtE<DZst%0B-(ARU?6<1';eD9!68]0(6#25U--32,2LA0A/D,_F){%st&'&1&s/+$ " r %tD ` Jr wr?t &> 8ut AC+ ^u yt7 ~ 2>/]eAlto Gateway Operation3length of time Gateway program has been running (hours:minutes:seconds),the number of times each server has been invoked (explained later in thismemo), and a matrix showing number of packets forwarded from onedirectly-connected network to another. The number of discarded packets isalso listed. Discard of packets is not cause for alarm: it is a normalconsequence of the great disparity in speed between the Ethernet and theleased lines, and does not give rise to loss of information in file transfers orterminal connections.RouteThis will print the routing table used by the Pup Software to determinewhere to send a pup to get it to its final destination. 0 hops means that thisgateway is directly connected to that network by the net and host numberindicated. If the hop count is greater than 0, then the pup will beforwarded to another gateway at the indicated address for furtherprocessing.Recent and TotalThese commands print out reams of statistics. The numbers printed byTotal include everything that has happened since the Gateway program waslast restarted. The numbers printed by Recent include only what hashappened since the last time the Recent Statistics were printed.QuitThis is how you stop the Gateway program. You must confirm thiscommand by poking the left mouse button. Any other mouse button abortsthe command. It may take a while for the Gateway program to unwind if,for example, the boot server is retrieving a new boot file.DeviceInfoThis menu is available only when the mouse in not inside any window.Ether1-xxThis simply prints out the statistics for the Ethernet interface (there may bemore than one) connected to net xx.SLA-7This prints out operating summaries for the Synchronous Line Adaptor(SLA) i.e. the EIA board or the CommProc. For each line, the number ofpackets successfully sent and received on that line is printed, followed bythe number of instances of three types of errors: CRC (CyclicalRedundancy Check) errors, Sync errors (bit synchronization was lost), andControl sequence errors. The total number of errors should be much lessthan one percent of the packets successfully received. If a high error rateoccurs on a single in-use line (whose state is "Up"), the line or modem issuspect, whereas if frequent errors occur on all lines (or particularly on"Looped back" lines), the SLA interface is suspect.This command also prints out the SLA routing table. Under normalcircumstances, the routing table for a particular Gateway should show thatit can reach all other Gateways through one or more of the connected lines.Booter - Table fuGbt"&`1_%]&$\< Z"&YPWTuQt1P4:N >M,8 KAAJ# G?utuDZt-ButCARut?@Mesa6>Gateway.signals) willprobably help translate it into English. The third catagory of trouble is an inconsistencydiscovered by the Pup Software. Again an octal number will be printed, and you will needa listing of Gateway.signals to translate it into English.One common uncaught SIGNAL is InsufficientVM (1015B). This normally means that thefirst 64k of memory didn't have enough room to swap in a large code segment. The arg isthe number of pages that were needed. The normal cause for this problem is allocating toomany buffers. Try adjusting the Buffers parameter to leave more space, but be carefulnot to go too far.Another common SIGNAL is DiskFull (2201B). This normally happens while it is trying toextend the typescript file during retrieval of a new copy of a boot file that won't fit. The fuGbt*,`:]u Zt@WuUt ,s"St!ut ut Qut+utPzMuJt!/I-Z9[G6F$ Ar>tA=SM ;D:KD82(7Bvt5":4:P2!st/12`/V.*sts tvt,vt0st+"vtvt))T(N&G %vtvt"-N &9%*1.st vtv#tM 9:st*(+- P !vt ! stB 3<! :9^Alto Gateway Operation5simple case of retrieving a new boof file that doesn't fit normally recovers without crashing.The easy way to avoid this problem is to leave enough space for a new copy of the biggestboot file in your list. Othello is over 400 pages, and the system needs another 100.Another SIGNAL that happens occasionally is UnrecoverableDiskError (605B). This probablymeans that your disk is sick. Try running the Scavenger. If it has troubles with a boot file,you should delete the damaged file to be sure that garbage doesn't propagate around thenet. If the boot file number is less than 100000, the boot server will retrieve a new oneautomatically.A Code Trap from Interrupt Routine is either a software bug, or the result of a hardwarefailure. Please contact me if your hardware is healthy.2. Functions Performed by the Alto GatewayThe primary purpose of the Gateway is to forward Pups (Parc Universal Packets) from one networkto another. However, the fact that the Alto is somewhat underutilized by this task and that it is inoperation all the time makes it a desirable source of other services as well. These services arenecessarily limited to those that are relatively easy to implement and whose resource requirementsdon't significantly impact the primary role as a Gateway, but they make life considerably morepleasant for Alto users than would be the case were these services not available.The Gateway program provides the following services:Gateway InformationThis service is actually related intimitely with the Alto's role as a Gateway. It providesrouting information to all hosts on directly-connected networks. It is by means of thisrouting information that Pup software such as FTP is able to communicate with hosts onother networks.Date and TimeThe Gateway program maintains the date and time in a form usable by Altos. The SetTimeEXEC command obtains the date and time by this means.Name LookupThis service translates inter-network name/address expressions into addresses usable forcommunication. When an Alto subsystem is requested to establish contact with a hostaddressed symbolically (e.g., "Maxc"), it generates a name lookup request, to which thegateway responds by supplying the corresponding inter-network address (e.g., "3#200#").BootMany machines are capable of boot-loading over the Ethernet if a suitable server is availableto provide the boot files. The Gateway provides this service for a limited set of boot filesthat are useful on a machine with no disk loaded or with a disk that won't boot (e.g., DMT,Scavenger, FTP, CopyDisk, and a NetExec providing more convenient access to the otherboot files). There is no intention, however, of making available a complete set ofsubsystems by this means.EchoThis service consists simply of a process that echoes all received packets back to their source.It is useful for hardware and software diagnosis.In addition to these services, the Gateway program also implements several internal support fuGbt S`D_#2\1st.Z@Y):WRV! S<rt!Q8 Ku* HtW Gb EK Db BG A Q >&4 ;Ar8]tN 6B5U.st"3 0r .t!6,st1 )r &t L%5@#)."-W Hrct@=[J st st <S-& rtX 1 2) U>/]4Alto Gateway Operation6protocols, such as the one that automatically updates the network directory data base.3. Contents of the Gateway DiskThe Alto Gateway disk contains all of the files needed for normal operation of the Alto Gateway.Since space is tight, it probably does not contain much else. Be sure to keep at least 400 free pageson your Gateway disk. If you don't have enough there won't be any way to update big files. If youare trying to clean up your disk, you can delete *$ and Gate.typescript, they will be created againwhen needed.Gateway.imageThis is the Gateway program itself. This file is updated when a new version of theGateway program is released.User.cm, hostname.txtThese are the parameter files needed by the Gateway program. SeeGateParameter.press for a description of the required contents.MesaGateEIAChain.br or MesaGateCPChain.br or ....This is the microcode loaded into the RAM.Pup-Network.DirectoryThe local copy of the inter-network name data base. The master source is[Ivy]Pup-Network.Directory. Pup-Network.Directory isupdated automatically by the Gateway program (and other name lookup servers).DMT.Boot, Chat.boot, NewOs.Boot, FTP.Boot, Scavenger.Boot, CopyDisk.Boot,NetExec.boot, and a number of othersThese are Alto bootstrap files, given out by the Gateway program when an Alto isboot-loaded over the Ethernet. The master copies are stored on[Maxc]. They are updated automatically by the Gateway programfrom neighboring Gateways. They may have been "reformatted" so that they areNOT useable by the BootFrom command to the Exec.*.Scratch$, NewGateway.image*.Scratch$ are temporary files used while getting a new version of Pup-Network.Directory, new boot files, or during remote updating of files fromGateControl. There must be enough room on the disk for it to hold a copy of thebiggest file that will ever be remotely updated. NewGateway.image is a temporarycopy of the Gateway program used when remotely distributing a new version of theGateway software. It is needed for remote updating and automatic restartingbecause Mesa uses Gateway.image for code swapping, and is automatically deletedby the Restart command from GateControl.SYS.boot, Swat, Swatee, Executive.run, FTP.run (and whatever)These are just the normal files/programs needed to get any Alto off the ground.FTP isn't really needed, but it is the simplest way to put things back togetherand/or save information needed to chase bugs.SYSFont.strikeThe Tools environment needs a strike format font. I use Gacha10. If you usesomething different, some printout may overflow a line or something equally fuG btV ]u Zt)7 YL7/ W\ VDM T Q NOMrJrtI j<kG?D1A&st>;-:nsv"t,-vt8$)6XI4$1@0/.vt1-3+st-(%=?>$>? "7!6E =.7x t&(A=\?&)T-o  E ") J ?/]L'Alto Gateway Operation7harmless.EDP.run, PupTest, Scavenger.run (and whatever)These are just the normal files/programs needed to get an Alto running again ifsomething goes wrong. You don't really need them on your Gateway disk, but youneed to keep a copy someplace handy since you can't boot them over the Ethernetif the Gateway program/disk/Alto is busted.Gate.typescriptGate.typescript is a log of everything that gets printed on the Alto display.RunMesa.runRunMesa.run is the bootstrap program that loads the normal Mesa microcode intothe RAM, and then loads Gateway.image into memory and starts running it.XDebug.image, MesaDebugger, Debug.logThese are the Mesa Debugger. They will be on your disk only if it is setup fordebugging -- there isn't room for them normally. NB: Do not move or delete anyof them unless you know what you are doing. They contain FPs.PupTypes.bcd, BufferDefs.bcd, DriverDefs.bcd, ...These files contain the symbol tables for the Mesa Debugger. Again, they will beon your disk only if you are chasing a nasty bug.4. Gateway Disk MaintenanceThe Gateway software includes the capability for remote updating of files on the Gateway disk. Itis also possible to remotely command the Gateway to restart, to reset its date and time, and toperform other operations. We use this remote control capability at Parc to release new versions ofthe Gateway program and to update the boot files. Therefore the following procedures should notbe needed in the ordinary course of events.Note that you are in deep trouble if your last Gateway disk gets clobbered. It is a very good idea tokeep a backup copy. You can easily make one using CopyDisk.A Gateway disk can also be configured to run on any XM Alto. It won't be able to forward packetsto any other network, but it will provide luxuries like a Time server and a Boot server which makeworking on Altos much more pleasant.Obtaining Updated FilesThis section describes procedures for obtaining new Gateway software or other files from Parc andinstalling them on the Gateway disk. This involves stopping the Gateway program briefly, so oneshould first make certain that there are no users who might be affected.The following procedure assumes that the file being updated is Gateway.image, but it applies to anyother file. [IVY] is the normal location for released Gateway software. A few of the boot filescome from [MAXC]. The procedure requires use of a second Alto connected to the sameEthernet as the Gateway Alto.1. While the Gateway is still in operation, run FTP on an second Alto, connect to IVY, andretrieve the file Mesa6>Gateway.image. After closing the connection to IVY,leave the Alto running FTP. fuGbt_9.\T6Z/YL3W+TQMO L5?JstAG%D3CcD A>>1<::1 6(u 3Ct W 10/ 0;!B .U -3+ *NrM (t) % %st+ $a] "$ r ta Q  H ';(  s t7  s t. 1stst2vtst st g>/[Alto Gateway Operation82. Type the Quit command on the Gateway keyboard to return control to the AltoExecutive.3. Run the FTP program on the Gateway Alto, connect to the second Alto, and retrieveGateway.image. Note that since no name server is running at this point, it is necessary torefer to the second Alto by number rather than name (e.g., if its Ethernet address is 123,you Open a connection to "123#"). After retrieving the file, quit out of FTP to the AltoExecutive.4. If desired, back up the Gateway disk.5. Restart the Gateway program by issuing the Gateway command.One might wonder why it is not possible simply to connect directly to IVY from the Gateway inorder to retrieve files. In order to do this, FTP would have to communicate over the SLA line toParc. However, FTP (and other standard subsystems) does not contain the software for driving theSLA interface, but only contains a driver for the Ethernet. Hence, FTP running on the Gateway cancommunicate only with machines on the directly connected Ethernet.5. PupTest OperationPupTest is a program developed primarily for checkout of the Pup software; however, some of itscapabilities are helpful in locating and troubleshooting network problems. Be sure to keep a fewcopies of PupTest.run on various disks because you can't boot it from the Gateway when you reallyneed it.We describe here only those PupTest commands useful for troubleshooting network problems.The usual symptom of failure is likely to be that a user at a remote location is unable to accessMaxc or some other machine not on the local Ethernet. There are a multitude of problems that cancause this, and one should not jump to the conclusion that the leased line or the Gateway is down.The following procedure should pinpoint the failing link.The simplest test is to try to connect to some other server that is known to be on the same remotenetwork. If you can connect to either MAXC2 or IVY, but cannot connect to MAXC, then MAXC isprobably down.The PupTest command used in this procedure is Echo. It requests the name or address of a hostrunning an Echo Server, and it then sends Echo requests to that server. All Gateways have Echoservers, and any machine running PupTest itself has an Echo server. For each reply PupTestreceives, it prints "!", and if no reply is received, it times out after 1.5 seconds, prints "?", and triesagain. It prints "#" whenever it gets an packet with an incorrect sequence number. Normally thishappens just after it printed a "?", which simply means that it didn't wait long enough. The testterminates when any key (e.g., space) is pressed.1. Run PupTest on two Altos connected to the same Ethernet, and direct one of them toEcho to the other. One should address the other Alto by number rather than name; e.g., ifthe other Alto's Ethernet address is 123, one should say "Echo to: 123#". If this doesn'twork, then the local Ethernet is broken. It is not necessary for the Gateway to be up forthis test to work.2. Echo to the local Gateway; that is, say "Echo to: n#", where n is the Gateway'saddress on the local Ethernet. If this doesn't work, then the Gateway program is down orthe Gateway or its Ethernet interface is broken.3. Echo, in turn, to each of the other Gateways along the path from the local Gateway tothe unreachable destination. The topology is geting pretty complicated now, so you willhave to be careful doing this. (It should be possible to reference these machines by namesince the name lookup is performed by the local Gateway, which is known to be up by step fuGbt yt5` ]stF\1[ZAY)("st W T)Q/yt N=st Mr'st$st Kst1 Jjst-st HB D}u At V @@ r >V =  :'tO 7B,5 5B 4:5- 29 /4. .M'stststst , ).ut+ (`L &S %XX #B "P] 1Sc PQ[ L7rtrtnV0: O H y)/ 2?/]rAlto Gateway Operation92.) If this doesn't work, then there are a number of possibilities, some of which can bechecked out by running PupTest on the Gateway (see step 4). If it is possible to echo tothe last Gateway along the path to some desired host, then the most likely reason forinability to reach that host is that the host itself is down. If it is possible to echo to thesecond Gateway along the path to the unreachable destination (the local Gateway is thefirst), but it is not possible to echo to the last Gateway, then the failure is in the firstunreachable Gateway or the modems or leased line between it and the next nearer Gateway.Determining which component has gone down requires cooperation with personnel at othersites.4. Unplug the line to the modem and put in an echo plug. Be sure to unplug the echo plugsparked in any spare slots. Activate PupEcho and tell it to echo to itself through the loopedback line; that is set Target to: 7#n# where n is the assigned SLA network address for yourmachine, and poke Start!. The normal behavior in this case is to flip the indicator boxreasonably rapidly. Try it sometime so you will know how fast it should go. A "?" will beprinted each time a packet is not returned correctly. If this doesn't work, the SLA interfaceis probably broken. Be sure to plug the modem back in.5. After plugging the modem back in, press the AL (Analog Loopback) button on themodem so that it stays in its "in" position. Again, direct PupEcho to echo to itself throughthe SLA driver. If this doesn't work, the modem is probably broken. When you arefinished with this test, be sure the modem's AL button is in its "out" position.6. If the previous test worked, but it was not possible to echo to the Gateway at the otherend of the link, then the failure is in the other Gateway or the modem at the far end of thelink or in the leased line itself. Determining which component has gone down requirescooperation with personnel at the far end.To force Echoing to go through a particular line, unplug all of the others.The Bell 209 modems that are used for most of the Xerox-Pup network have several diagnostic aids.If you push in the AL button, the modem should loop things back locally. The SLA statistics shouldshow a state of Looped-back within 5 seconds. If you push the DL button at the remote modem, itwill send back whatever it receives. Again, the SLA line should show a state of Looped-back. If aline gets looped back when the local modem is in AL mode, but not when the remote modem is inDL mode, the line or one of the modems is probably sick. You might learn something by trying thetests in the other direction.There is one nasty problem that we noticed once. If the DL and AL tests work from both ends, yetthe Gateways can't talk to eachother, it may be because the baud rate switch on one of the modemshas been bumped.6. Notes to Gateway MaintainersBe sure to keep at least 400 free pages on your Gateway disk after *.scratch$ has been deleted. Ifyou don't have enough there won't be any way to update big files. If your Gateway is also a bootserver providing Othello to D0s, you should have at least 600 free pages.When receiving a new copy of Gateway.image via FTP, the Gateway program automatically changesthe name of the incoming file on the Gateway disk to be NewGateway.image. The GateControlRestart command looks for this filename. The running program is swapping code out ofGateway.image, and it will probably die horribly if the code were changed out from underneath it.If a file already exists when an update starts, the incoming data is stored in a temporary file until itis all collected to protect against clobbering things if the EFTP transfer fails. If a file does not existwhen the update starts, the incoming data is written directly into the target file to avoid filling up fuGbt?`Q_M]X\OZ NYEW2$US9sQt vt1P-stNvt 3MHKLst J7G0st E&1+</';* 89K 5U*7 3 st9st 2L1 st 01st /D!st* -stP ,< )W9stst 'O &O u tQ u:' I  st+ 1) @ O H U U L?/\{Alto Gateway Operation10the disk with two copies. If the transfer fails, the partial file is deleted.The Restart command appends a few commands into Rem.cm, so you can do almost anything youwant to a Gateway disk remotely by storing your own commands in there ahead of its restartsequence. If NewGateway.image exists when the Gateway is being restarted, Gateway.image will bedeleted and NewGateway.image will be renamed into Gateway.image. At the end is a command torun Gateway.image.Whenever the Gateway program starts up, it will reformat any boot files in its list that have notbeen previously reformatted. That takes a while if it actually does any reformatting. This shouldnot happen very often.If the Gateway program is forwarding a great deal of traffic, there will not be any CPU cycles leftover for other things. This will probably only be noticable if you are trying to get a boot file whilerunning PupTest between two machines connected to different Ethernets via the same Alto Gateway.The Gateway will support about 400 kilobits of throughput, but it may take over a minute to get abig boot file while that is happening.7. Hardware RequirementsTo run the Alto Gateway software requires appropiate hardware. Here is a quick checklist:First, you need an Alto with at least 128K of memory. You need a 3K RAM or, XMesa5.0, or Mesa 6 must be blown into ROM1. Beware, there are some proms with strangeversions of XMesa that don't work with the Gateway microcode. A D0 can be used if you don'tneed to use any phone lines.If you are sending a set of proms to another site, I suggest that you test them first. It maysave a lot of time. Similarly, if you are having troubles bringing up the Gateway softwareon a new machine, try testing your disk on a different Alto. The Gateway program usesseveral features of the hardware that are not normally used, and they may never have beendebugged.A single Alto disk is quite full if you have the normal collection of boot files. If you want alarge collection of boot files, or the Mesa Debugger and some symbols, a second disk drivewill be necessary.If your Gateway is going to talk to a phone line, you will need either an EIA board(s) or aCommProc. An EIA board costs about $1200 per line. It does not seem to run faster thanabout 20KB, but I don't know why it doesn't. A CommProc costs about $4500 plus $500per line. It works ok at 56KB. 6 lines should work ok at 9600 buad.If you are using an EIA board, MRT must be made Ram-Related. Connect MRTACTIVE (slot11, pin 109) to either TASKA' (slot 10, pin 13) or TASKB' (pin 14) whichever isn't being usedby other devices. The CommProc uses TASKA'. SmallTalk won't work on a machine with thismodification.The CommProc needs another backplane jumper from J11 pin 108 (for 9600 baud, pin 111for 57KB) to pin 105 of the slot containing the LIM driving the line. That brings aninternal clock out to pin 18, which is normally unused, on the modem connector. TheLoopBack Plug (described below) expects the Alto to provide a clock on pin 18.If you are going to connect to more than one Ethernet, you will have to aquire and installextra Ethernet boards. See [IVY]ExtraEther.press. An Alto can handleup to three Ethernets. The Gateway software expects the first extra Ethernet to use task 2and SIO bits 12 and 13. It also expects the second extra Ethernet to use task 1 and SIO bits10 and 11. CopyDisk won't work if you have added a third Ethernet board.If you have a CommProc, and you are adding a third Ethernet, you will have to undo the fuG? btN _9U ]Q \1 S Z] Y) VDa T?$ S< PWTst NU MO1/ KO JG& Eu Bt)1?7st >m"st+<#s;e8tA6H5xN3@2p/^.+/,)M (Y&,(%E"-stst$st stst$%sts+ t0$8?#10NK6$vt C@stIst ; s= Vt st. ?/]hAlto Gateway Operation11CommProc timer. It is not used by the Gateway software. Remove the wires connectingpin 119 on slot 16 to pin 119 on slot 11 (1ACT'), and pin 114 on slot 16 to pin 114 on slot11 (WAKE1'), or simply omit them when you install the CommProc.Modem Cable:The Alto-to-modem cable has a female DB-25 connector at the Alto end and a male DB-25at the modem end. Do not connect pin 18 straight through. The Bell 209 modems getconfused by the loopback clock. The following signals should be transmitted through thecable:PinSignal1Protective ground2Transmit data3Receive data4Request to Send5Clear to Send6Data Set Ready7Signal ground15Transmit clock17Receive clock20Data Terminal ReadyIn practice, you can save 4 wires by jumpering pins 4 to 5 and pins 6 to 20 at both themodem and the Alto end of the cable.Modem Options:The cable described above and a CommProc do not seem to work with some Bell 209modems. I have not tracked down the problem, but the following set of jumpers works atthe Bayhill building. They are located inside the front cover of the modem. You have tobend the plastic a bit to unhook the 4 hooks that hold the cover on.WN, WK, WSWF, WH,WP, WB, WDYX, XIYC, WJ, YI, YMThe factory defaults are XG instead of XI, and YN instead of YM. XI controls thegeneration of carrier, so if it is wrong, you will discover it promptly. YM is only interestingwhen using the AL test mode. If your modem has XG, move it to XI and things willprobably work. Similarly, move YN to YM if necessary. You will probably need a smallpair of pliers since YN and YM are hidden between the switches and the frame. It isprobably a bad idea to change any of the other jumpers even if they are different from thislist.LoopBack Plug:A loop-back-plug is very useful for debugging. It is just a female DB-25 connector with thefollowing jumpers:PinsSignals2-3Transmit data to Receive data4-5Request to Send to Clear to Send6-20Data Set Ready to Data Terminal Ready15-17-18Transmit clock and Receive clock to Internal clock8. Building a Gateway DiskOne way is simply to copy a disk that you like and modify it as necessary. In this case, you willneed to: fuG?bt8`F_? \1 ZOY) r'tW@V!S<QP4 N M,K J# H G E DBOrtA $ >& <F;W9M 8D51 32) 0z/!t z,")43';&,5$Q #$ ? =7RJ%B2 u tQ Mv >/]7Alto Gateway Operation12rename HostName.txt to be YourHostName.txtupdate the Indirect section of User.cm to point to YourHostName.txtchange the hardware configuration in YourHostName.txt, andupdate the [BootServer] and [TimeServer] sections as appropriate.Alternatively, you can start from scratch by using the following recipe:get a new disk (or two) and install NewOS.boot with the Erase option,retrieve [Ivy]Mesa6>NewGatewayDisk.cm and run it,copy and/or merge NewGateway-user.cm into User.cm,run the Gateway by typing Gateway and RETURN.This will start up the Gateway program using a default parameter file. After it finishes retrievingnew boot files and things (this takes several minutes), you can update the Indirect section ofUser.cm and Edit/Rename NewGateway.txt to YourHostName.txt.See [Ivy]Mesa6>GateParameter.press for the details of parameter files.In either case, there is a slight problem editing the parameter file because there is not normallyroom enough on a Gateway disk for Bravo. If you don't make any errors, you can use the Tajoeditor. If you keep copies of the initial files, you can even recover from errors that kill the Gatewayby copying them over again. Another approach is to delete enough boot files (or do the edits beforethey arrive) to make room for Bravo. You can also use FTP.run to move the files to a disk that isalready setup with an editor.Remember, if you smash your last copy of the Gateway disk, you may become cutoff from theworld. A backup copy is good insurance.Revision history:October 13, 1978, initial releaseDecember 7, 1978, XMesa, 209 testing hints, LineWatcher, variousDecember 22, 1978, 209 options, SysFontJune 18, 1979, Update for Mesa 5November 21, 1979, Minor updatesJune 11, 1980, YM/YN optionDecember 2, 1980, Mesa 6 updateDecember 8, 1980, Dialup passwordsJanuary 12, 1981, FTP Server and HostWatcherMarch 11, 1981, Split out parameter file info fuG?bt{vt{ v`tvt { v_t%{ vt] v tv t ZHY)$s tWv%t V!vtvtTstst SF QF Pvtv t{ vt Lv't$ IL H6;! F ] E-A# C$> B% >Y =v( 6X25x!23@22p'202/h2-2,_2*"2)W,2'- '>/@LOGO TIMESROMAN  TIMESROMAN  TIMESROMAN TIMESROMAN  TIMESROMAN GACHA  TIMESROMAN HELVETICA   TIMESROMAN  TIMESROMAN  GACHA   x'/7 @ J SZ*_j/b `属AltoGateway.bravoMurray.PA, HalMarch 23, 1981 12:06 AM