Received: from andrew.cmu.edu (TCP 20000405603) by AI.AI.MIT.EDU 12 Feb 89 02:57:30 EST Received: by andrew.cmu.edu (5.54/3.15) id for Info-PCNet@ai.ai.mit.edu; Sun, 12 Feb 89 02:54:07 EST Received: via switchmail; Sun, 12 Feb 89 02:54:04 -0500 (EST) Received: from loretto.andrew.cmu.edu via qmail ID ; Sun, 12 Feb 89 02:51:26 -0500 (EST) Received: from loretto.andrew.cmu.edu via qmail ID ; Sun, 12 Feb 89 02:50:04 -0500 (EST) Received: from VUI.Andrew.3.20.CUILIB.3.45.SNAP.NOT.LINKED.loretto.andrew.cmu.edu.rt.r3 via MS.5.6.loretto.andrew.cmu.edu.rt_r3; Sun, 12 Feb 89 02:50:01 -0500 (EST) Message-Id: Date: Sun, 12 Feb 89 02:50:01 -0500 (EST) From: "Johnny J. Chin" To: Info-PCNet@ai.ai.mit.edu Subject: test msg Please ignore this. Just a test message. (ext.in.info-pcnet)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 89 16:24:06 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 16 Jan 89 16:14:54 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 16 Jan 89 16:07:14 EST Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 15 Jan 89 18:58:30 GMT From: m2c!jjmhome!cpoint!martillo@husc6.harvard.edu (Joacim Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. Subject: XNET Summary Message-Id: <1977@cpoint.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I wrote this summary description of XNET and would appreciate comments. Development Memorandum 0001 To: XNET Developers From: Joachim Martillo Subject: XNET Essentials Date: January 11, 1989 ____________________________________________________________ I. Introduction Originally, communications networks were used only for remote login and file transfer. Thus, kermit is actually the modern incarnation of the original network programs. Fairly quickly people realized that more sophisticated resource sharing is desirable. The most lucrative sophisticated network application is probably remote database systems. The most flashy sophisticated network application is probably network transparent window systems. The most ubiquitous is probably network file systems. Network file systems being an obvious generalization of remote file transfer is one of the earliest developed of the genuine resource sharing systems. When I was a student in 1978, we already had remote file systems for the PDP-10 working. Remote file systems are apparently the most complicated and least standardized of genuine resource sharing systems. Important network file systems (sometimes actually remote virtual disk systems) include NFS, RFS, XNET (Xenix Net, basically equivalent to MS-Net), Novell and Vines. The Berkeley Unix developers have recently implemented a new network file system, and proprietary remote file systems like Primenet and DECNET remote disks have been around for years. The plethora of remote file systems and the complication in network file systems probably originates in the inherent difficulty of joining communications to such a basic operating system service like file service. Unlike the implementer of a network transparent window system, the implementer of a remote file system has to know lots about networking and the target operating system. Data caching, concurrency and security issues are really complicated, and there is no particular consensus on handling these issues. When I was a student, a computer scientist proved his machismo by implementing a debugger. Nowadays, implementing a network file system seems to be the current proof of machismo. II. TCP/IP Most current popular network file systems take TCP/IP virtual circuits (or UDP/IP datagram service) as a starting point. TCP/UDP/IP was developed by DARPA as a means to interconnect different physical networking systems. (It is not obvious that most commercial TCP/IP based file systems actually make use of the ability to interconnect different physical networks.) IP datagrams provide a network independent means for gateways to move data packets from one physical network to another. Gateways are allowed to fragment IP datagrams when the maximum packet size on the next subnetwork is smaller than the maximum packet size on the current subnetwork. TCP and UDP identify specific source and target applications on the source and target machines. TCP, UDP and IP are typically implemented as protocol processing finite state automata in an operating system kernel. While about 10 years old, TCP/IP is one of the few network protocol suites which effectively makes of network bandwidth and avoids thrashing and hysteresis problems which arise in packet counting based flow control. A system interface is necessary for user applications to actually use TCP or UDP services. In Berkeley Unix, the system designers developed a generalization of files to provide the interface. The process file table contains entries associated with file or socket descriptor indices pointing either to entries in the global kernel file table or to entries in a global network data connection table. The double table formalism allows various forms of file or connection sharing. The details are straightforward but not so important at this point. The essentials are: 1. operations on file descriptors, pipe descriptors and socket descriptors are essentially identical and 2. sockets are a generalization of pipes which can handle multiplexed data streams and non- simultaneous rendezvous between several processes. There is no requirement that the interface to TCP/IP look like sockets. Inside the unix kernel there is actually another less general interface to TCP/IP which is used by kernel processes. In the local environment, both TCP/IP and the socket interface are provided by Excelan. III. NetBIOS NetBIOS is both a protocol suite and user interface defined in the IBM PC Net Technical Reference. The protocol suite does not provide internetting (connectivity between different networks) but does provide a device independent way of using network services which in the case of netbios consists of reliable point-to-point virtual circuits. NetBIOS can handle media providing only broadcast communications or media providing only point-to-point service or media providing both types of service. In NetBIOS, a machine (in the DOS case) or a process (in the XENIX case) allots itself a name with the local NetBIOS Name Server (NBSS) and then sends a packet to the NetBIOS Datagram Distribution Server (NBDDS) which connects to the NBNS to find the address of the destination host and then redirects the connection to the destination host. In a pure broadcast system the connection setup is slightly different. NetBIOS is a much more chatty communications system than basic TCP/IP. It seems to use either single-frame- acknowledged or packet-counting flow control. In the Xenix case, both the NBNS and NBDDS are implemented on each node so that many of the steps of connection setup do not actually require the transmission of network data. In one LAN environment, Excelan implements NetBIOS on top of TCP/IP. This sort of implementation immediately provides internetting capabilities to NetBIOS. Yet, NetBIOS does not provide any service that TCP/IP does not already provide. In fact, NetBIOS provides less than TCP/IP and in terms of network bandwidth utilization actually provides this service much less efficiently. One might legitimately ask why anyone would implement NetBIOS on top of TCP/IP and thereby cripple network performance. In fact, many companies have done the inverse by implementing TCP/IP on top of NetBIOS so that a NetBIOS network is simply treated as another type of physical network. The reason for implementing NetBIOS on top of TCP/IP is that there are many applications like XNET or MS-NET which assume a NetBIOS interface to the network. Implementing NetBIOS on top of TCP/IP gives the ability to make quick and dirty ports of NetBIOS applications to a TCP/IP environment. The major complexity of implementing NetBIOS on top of TCP/IP seems to be naming. A NetBIOS name (or a group of names in the case of a multiprocessing Xenix system) needs to be mapped to a TCP/IP domain name which is then mapped to an IP address. NetBIOS names and Domain Names have different sets of legal characters. The high and low nibble of each byte of the NetBIOS name is added to 'A' and put into a separate byte which produces an all caps name twice as long as the original NetBIOS name. The local domain suffix is then added to the new name. This new name plus suffix is used as the domain name. These names can be seen with the Excelan Lanalyzer. The NetBIOS application interface uses the int 5c DOS system calls. Excelan provides an int5c interface for Xenix so that application developers can actually make direct calls and write NetBIOS applications (like xfserv -- the XNET file server daemon) under Xenix. The manuals do not document this interface very well. Really no more information is provided than can be found in the system include file. There seems to be no way to wait on several NetBIOS virtual circuits at the same time using the int5c interface, and there seems to be no interface from select() to the NetBIOS virtual circuits. As a consequence, each client process gets associated with its own xfserv server process on the file server machine. IV. Local and Remote File Systems Understanding local file systems helps understanding remote file systems. I suppose it might be possible to define a network representation of files and file systems which is completely independent of the source and target operating system file systems, but operating systems tend to consider different types of information important. XNET is influenced by the MS-DOS file system while NFS is influenced by the Unix file system. A. The DOS File System A hard disk which contains a DOS partition starts off with a partition table which identifies DOS partitions and how to get to them. A DOS partition starts off with a system block which contains boot and partition parameter information. The system block is followed by N (specified in the system block) FATs (File Allocation Tables). The root directory follows the partition table. The root directory contains a list of files (including directories) in the root directory. With each file entry is associated the files first cluster. (Clusters are sequentially numbered groups of disk sectors) To get the next cluster, DOS looks at this cluster index in the FAT. If the cluster index references 0xFFFF (for a 16 bit FAT), the file has but one cluster. Otherwise the FAT entry referenced by the first cluster index contains the index for the second cluster. The FAT entry for the Nth cluster contains the cluster index for the Nth+1 cluster of the file or 0xFFFF if the current cluster is the last cluster in the file. B. The UNIX File System A hard disk which contains a Unix partition starts off which a partition table which identifies Unix partitions and how to get to them. A Unix partition starts off with a boot block, a system block (which parameterizes the file system), an inode list which includes the root inode and then data blocks. Every file has an inode which identifies the first N blocks of a file (which can be a directory). The N+1 block entry in the inode actually is an indirect block which contains M+1 entries identifying M indirect blocks and one indirect block. The amount of permitted indirection depends on the Unix implementation. Unix file system access tends to be faster than DOS file access because inode access is simply faster than FAT chaining and because Unix maintains read and write inode and disk block caches. DOS can only be enhanced to contain a write through cache. Because Unix maintains a write cache, disk write strategy can be optimized. Read strategy is harder to optimize and database programs for this reason prefer to treat disks as raw devices and do their own caching. Directories contain a list of pairs of the files contained in the directory and the associated inodes. Reading a unix file involves opening the directory which contains the file to get the file inode (namei routine), getting the inode and then getting data out of the disk blocks. Each process maintains its own fixed-length process file table which contains N file read and write buffers and a pointer to an entry in the fixed-length global file table which points to an entry in the fixed-length global inode table. An inode can only have one entry in the global inode table, while several global file table entries can point to the same inode. If two processes open the same file the process file table entries point to two different global file table entries which point to the same inode table entry. If the two processes are related by a fork, the process file table entries point to the same global file table entry which obviously points to but one global inode table entry. One file system can be mounted on another file system at an empty directory inode which is then marked as a "mounted" inode and references an entry in the fixed-length mount table. The mount table identifies the disk device which contains the second file system. The Unix user unlike the DOS, VMS or PRIMOS user generally does not have to worry about how the file system is laid out on the underlying disk partitions. C. XNET and NFS XNET uses the SMB protocol to convey information from the server machine so that a client DOS process when invoking DOS system calls can read remote files as if they were local. That means virtual disk FATs, cluster indices and clusters can be built out of SMB (XNET) protocol blocks. SMB protocol blocks are passed over NetBIOS virtual circuits. Cluster caching is on the remote server. The SMB protocol provide an unacceptable form of passworded directory security, and is a stated protocol which means that it is possible for bad things to happen to a file system if one side of an XNET connection goes away and the other side then gets out of synchronization in terms of what it believes about the file system. Fortunately, there is not much in the way of state associated with the DOS file system, so that if both client and server are DOS machines, there is not much problem with crashes. Aborted circuits on Xenix clients are probably a symptom of loss of synchronization and are probably the equivalent of the DOS critical error Abort, Ignore, Retry? prompt which is always a pain when it occurs. NFS uses the NFS protocol to convey information from the server machine so that a client Unix process when invoking Unix system calls can read remote files as if they were local. This means that virtual disk inodes and virtual disk blocks are built out of NFS protocol blocks. NFS protocol blocks are passed via UDP datagrams. Generally inode and block caching is on the remote server. NFS also lacks for security. NFS is a stateless protocol in which a remote read requires the remote file system to be instantaneously mounted with a request to the remote mount daemon, followed immediately by a remote open request, then a remote lseek request, then a remote read and then a remote close all done more or less atomically. Other file system operations are handled similarly so that it is next to impossible for server and client file system states to get out of synchronization. Since mount tables are not file system structures but rather are in-core kernel structure, it is not possible on a client machine to access file systems which are mounted on remote file systems. In many respects NFS is more work than XNET, but the NFS and UDP/IP protocol suites actually make a much more efficient use of bandwidth. Further a Xenix XNET server basically takes Unix file information translates it into the SMB protocol in anticipation that the remote client will be converting this information will be converted by the client into DOS file system information. It is possible that such conversion does happen, and then the DOS information is converted into Unix inode/disk block information. With NFS, the NFS protocol is optimized to carry information to be converted back into inodes and disk blocks. V. Conclusion Generally, one would expect a Unix-based remote file system like NFS to work better in the Unix environment than a system like XNET. If someone has the time to look into the int5c() interface, it may be possible to clean up aborted circuits via direct NetBIOS calls. Unfortunately, it might not be possible to get sufficient information from SCO actually to write such applications. I am still looking for the IBM PC Net Technical Reference which would probably be helpful. Another way to handle the problem might be to run the file servers as DOS machines. XNET under DOS is probably stabler. Also, with such a configuration effective Unix/DOS conversion contortions would only occur at the communications servers and not also at the file servers. It might be worth a try just for the sake of curiosity.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 14:37:47 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 14 Dec 88 14:34:14 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 14 Dec 88 14:19:06 EST Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 14 Dec 88 00:07:24 GMT From: iscuva!tau-ceti!gregb@uunet.uu.net (Greg Baker) Organization: ISC Systems Corp. Spokane, Wa. Subject: Micro to mainframe gateway connections Message-Id: <188@tau-ceti.ISCS.COM> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I am looking for a list of companies that allow connection to a mainframe thru a PC gateway using SNA/SDLC. The software must support the following logical unit types: 0, 1, 2, 3, 4, and 7. Any information would be greatly appreciated. Thanks, Greg Baker  Received: from po3.andrew.cmu.edu (TCP 20000406037) by AI.AI.MIT.EDU 11 Dec 88 16:44:09 EST Received: by po3.andrew.cmu.edu (5.54/3.15) id for Info-PCNet@ai.ai.mit.edu; Sun, 11 Dec 88 16:36:32 EST Received: via switchmail; Sun, 11 Dec 88 16:36:25 -0500 (EST) Received: from loretto.andrew.cmu.edu via qmail ID ; Sun, 11 Dec 88 16:33:40 -0500 (EST) Received: from loretto.andrew.cmu.edu via qmail ID ; Sun, 11 Dec 88 16:31:51 -0500 (EST) Received: from VUI.Andrew.3.20.CUILIB.3.45.SNAP.NOT.LINKED.loretto.andrew.cmu.edu.rt.r3 via MS.5.6.loretto.andrew.cmu.edu.rt_r3; Sun, 11 Dec 88 16:31:47 -0500 (EST) Message-Id: Date: Sun, 11 Dec 88 16:31:47 -0500 (EST) From: "Johnny J. Chin" To: +dist+/afs/andrew.cmu.edu/usr0/postman/CampusLists/Tops20/ibmpc.dl@andrew.cmu.edu, Outbound News Subject: Detecting EGA/VGA presence Cc: info-pascal@brl.arpa, Info-PCNet@ai.ai.mit.edu, <@andrew.cmu.edu:turboc-l@UCF1VM.BITNET>, Outbound News Does anyone out there know how to detect to see if there is an EGA or VGA adapter present in a computer? How about CGA, Monochrome, or Hercules? Does determining the present video mode tell me enough to assume that one of these display adapters are present? If you do, could you please send me the sub-routine which will do this for me? It doesn't matter if its in Assembly, C or Pascal. If you curious why I need this, I am writing a program which has to perform differently for each display mode (particularly, EGA and VGA). Thanks in advance for all replies. -- J. Chin (a.k.a. Computer Dr.) xxxxxxxxxx xxx xxx xx ------------------ Carnegie Mellon University ------------------ xxx xxx xx 4730 Centre Ave. #412 ARPAnet: Johnny.J.Chin@andrew.cmu.edu xxxxxxxxxxxx Pittsburgh, PA 15213 BITnet: jc58@andrew.BITNET x xxxxxxxx x (412) 268-8936 UUCP: ...!harvard!andrew.cmu.edu!jc58 xx xx ---------------------------------------------------------------- xxxxxxxxxx Smile! Disclaimer: The views expressed herein are STRICTLY my own, and not CMU's.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Dec 88 12:25:51 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 7 Dec 88 12:23:20 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 7 Dec 88 12:19:21 EST Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Dec 88 20:25:44 GMT From: apctrc!zgel05@uunet.uu.net (George E. Lehmann) Organization: Amoco Production Co, Tulsa Research Center Subject: Re: NetBIOS Reference Message-Id: <652@flyer.apctrc.UUCP> References: <6791@spool.cs.wisc.edu> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu In article <6791@spool.cs.wisc.edu> condon@speedy.cs.wisc.edu (Anne Condon) writes: >(actually rose@cs.wisc.edu) >I am looking very hard to find any kind of reference for NetBIOS. RFCs 1001 >and 1002 refer to a very lovely IBM document called the PC Network Technical >Reference, but this appears to be out of print- certainly, neither I am holding in my hand (actually it's sitting on the desk) a copy of same. It is IBM # 6322916, Technical Reference, PC Network, First Edition, September 1984. Chapter Titles 1. The IBM PC Network 2. IBM PC Network Software Description 3. IBM PC Network Hardware Description 4. Network Design A. IBM PC Network Schematics B. IBM PC Network Specifications C. IBM PC Network Protocols D. Adapter BIOS E. Multitasking Considerations Glossary Bibliography Index I know I can't sell you this copy (it belongs to Amoco), but I can answer any further questions you have about it. Cheers... -- ----------------------------------------------------------------------------- To live and not fly is not living... George Lehmann PP/ASEL/IFR ...!uunet!apctrc!zgel05 Amoco Production Co. PO BOX 3385, Tulsa, Ok 74102 Voice:918-660-4066  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Dec 88 22:15:11 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 5 Dec 88 21:08:09 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 5 Dec 88 20:59:40 EST Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 6 Dec 88 01:18:05 GMT From: condon@speedy.wisc.edu (Anne Condon) Subject: NetBIOS Reference Message-Id: <6791@spool.cs.wisc.edu> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I am looking very hard to find any kind of reference for NetBIOS. RFCs 1001 and 1002 refer to a very lovely IBM document called the PC Network Technical Reference, but this appears to be out of print- certainly, neither the local IBM sales office nor any of the places they refered me to could help me find it. There was some discussion (in this group?) about one or two new (poorly rated) paperbacks on the subject, but neither Books in Print nor Forthcoming Books in Print had an entry for anything like that. I am hoping that somebody out there can send me a pointer on how to get the original reference or a second- or third-best alternative. This posting is *really* from rose@cs.wisc.edu header notwithstanding.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Nov 88 03:35:01 EST Received: from ICS.UCI.EDU (TCP 20060600001) by MC.LCS.MIT.EDU 15 Nov 88 01:48:40 EST Received: from [128.195.0.1] by ICS.UCI.EDU id aa19177; 14 Nov 88 22:43 PST To: info-pcnet@mc.lcs.mit.EDU from: Roy Tobin Subject: good reviews on a pair of products Reply-To: rtobin@ICS.UCI.EDU Date: Mon, 14 Nov 88 22:43:07 -0800 Message-ID: <19175.595579387@ics.uci.edu> Sender: rtobin@ICS.UCI.EDU I have used a product called Disk Manager-N from Ontrack computer to install a non-standard hard disk into a Novell file server. The product worked very well. It enabled me to use a high capacity RLL drive in a true-blue IBM AT as a Netware 2.0a volume. The drive, a Miniscribe 6128 is also performing well. I choose the drive after a bit of research. $945 for 110 MB. The Disk Manager-N installation shouldn't be too hard for people familar with Netware volume installations. It takes about 1 day. Again, thumbs up on both of these products. No connection with the companies, just a satisified consumer. Roy Tobin  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 Oct 88 15:16:51 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 22 Oct 88 14:15:26 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Fri 21 Oct 88 16:20:34-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 21 Oct 88 16:18:45 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 21 Oct 88 19:45:31 GMT From: apple!lenoil@bloom-beacon.mit.edu (Robert Lenoil) Organization: Apple Computer Inc, Cupertino, CA Subject: Re: MSNet SMB protocol - where can I get it? Message-Id: <19222@apple.Apple.COM> References: <649@hpuviea.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu In article <649@hpuviea.UUCP> mah@hpuviea.UUCP (Michael Haberler) writes: >I am looking for a specifcation of the Microsoft Net Server message block >protocol (which are the 'server' and 'redirector' layers on top of NetBIOS). Copies are available from Microsoft and (I believe) Intel. However, a formal published version was published by IBM's Entry Systems Division. It's "IBM Personal Computer Seminar Proceedings" volume 2, number 8-1, dated May 1985. It obsoletes volume 2 number 8, which was published in October 1984. This document only covers the original SMB specification, not the extensions that were put in for OS/2. Robert Lenoil Apple Computer, Inc.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Oct 88 21:34:00 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 20:58:00 EDT Received: from BLOOM-BEACON.MIT.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Thu 13 Oct 88 14:17:14-EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 13 Oct 88 12:18:55 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 10 Oct 88 11:09:12 GMT From: mcvax!tuvie!hpuviea!mah@uunet.uu.net (Michael Haberler) Organization: Hewlett-Packard Vienna,Austria Subject: MSNet SMB protocol - where can I get it? Message-Id: <649@hpuviea.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I am looking for a specifcation of the Microsoft Net Server message block protocol (which are the 'server' and 'redirector' layers on top of NetBIOS). Any hints? ------------ Michael Haberler mah@hpuviea.UUCP Hewlett-Packard Austria GmbH, ...mcvax!tuvie!hpuviea!mah A-1220 Vienna, Austria ...hplabs!hpfcla!hpbbse!hpuviea!mah (0043) (222) 2500 x412 (9-18 CET) michl@awiwuw11.bitnet -- Michael Haberler mah@hpuviea.UUCP Hewlett-Packard Austria GmbH, ...mcvax!tuvie!hpuviea!mah A-1220 Vienna, Austria ...hplabs!hpfcla!hpbbse!hpuviea!mah (0043) (222) 2500 x412 (9-18 CET) michl@awiwuw11.bitnet  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Sep 88 02:34:11 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 11 Sep 88 02:09:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sun, 11 Sep 88 01:59:56 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 11 Sep 88 05:31:33 GMT From: rubbs1!Tom.Connolly@rutgers.edu (Tom Connolly) Organization: Rutgers University Fido 107/330 (201) 932-3887 Subject: call waiting Message-Id: <48.232A18CA@rubbs1.FIDONET.ORG> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu does anyone know how to disable csall waiting on an amiga 500 1200 rsmodem please send mail to tom connolly -- Tom Connolly - via FidoNet node 1:107/330 UUCP: ...!rutgers!rubbs1!Tom.Connolly ARPA: Tom.Connolly@rubbs1.FIDONET.ORG \...!rutgers!rubbs1!Tom.Connolly  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Sep 88 06:43:13 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Sep 88 06:38:41 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 10 Sep 88 06:30:51 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 9 Sep 88 10:47:35 GMT From: coplex!johnv@bloom-beacon.mit.edu (John Vaccaro) Organization: Copper Electronics Inc. Louisville, KY Subject: Apologies Message-Id: <449@coplex.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu From the mail I recieved this morning,I'd say comp.protocols.pcnet was NOT what I thought it was! My sincerist apologies for posting to what was is obviously an unrelated newsgroup! john +---------------------------------------------+------------------------------+ |"...I've miles & miles of files pretty files | John Vaccaro | |of your forefathers fruit and now to suit | Hi-Tek Polymers Inc. | |the great computer....you're magnetic ink!" | 9800 E.Bluegrass Pkwy | +-------------------------------+-------------+ Louisville, KY 40299 | |DISCLAIMER: | UUCP:mit-eddie!bloom-beacon!coplex!johnv | | These are my opinions....... | BELLNET: 502-499-4020 | +-------------------------------+--------------------------------------------+  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 18:52:32 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 8 Sep 88 18:38:15 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Thu, 8 Sep 88 18:28:09 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 8 Sep 88 10:38:34 GMT From: coplex!johnv@bloom-beacon.mit.edu (John Vaccaro) Organization: Copper Electronics Inc. Louisville, KY Subject: New version of Advanced Netware(r) '286 Message-Id: <447@coplex.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Hello NetWorld; My LAN vendor called me yesterday to say that my upgrade to Advanced Net- ware '286 would be to version 2.12 and not 2.11. In addition he said that the rep from Novell told him that as of 2.12 the keycard/copy protection scheme has been removed. You >>supposedly<< no longer need a KEYCARD!! I believe that the new versions starts shipping either today or Monday. Has anyone else heard ANYTHING about version 2.12? Email me any info you might have and I'll summarize to the NET if interest warrants. Also, I'll post my impres- sions of the new version as soon as our upgrade is finished. thanx +---------------------------------------------+------------------------------+ |"...I've miles & miles of files pretty files | John Vaccaro | |of your forefathers fruit and now to suit | Hi-Tek Polymers Inc. | |our great computer....you're magnetic ink!" | 9800 E.Bluegrass Pkwy | +-------------------------------+-------------+ Louisville, KY 40299 | |DISCLAIMER: | UUCP:mit-eddie!bloom-beacon!coplex!johnv | | These are my opinions....... | BELLNET: 502-499-4020 | +-------------------------------+--------------------------------------------+  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 Sep 88 15:09:18 EDT Received: from cayuga.cs.rochester.edu (TCP 1200000017) by MC.LCS.MIT.EDU 3 Sep 88 15:05:46 EDT Received: by cayuga.cs.rochester.edu (5.52/k) id AA09383; Sat, 3 Sep 88 15:04:01 EDT Received: by cursa.cs.rochester.edu (3.2/k) id AA09822; Sat, 3 Sep 88 15:03:58 EDT Date: Sat, 3 Sep 88 15:03:58 EDT From: ken@cs.rochester.edu Message-Id: <8809031903.AA09822@cursa.cs.rochester.edu> To: info-pcnet@mc.lcs.mit.edu Subject: testing  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Sep 88 20:24:17 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 2 Sep 88 20:21:43 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 2 Sep 88 20:14:49 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 2 Sep 88 15:21:15 GMT From: mcvax!unido!laura!exunido!edelhoff@uunet.uu.net (Volker Edelhoff) Organization: University of Dortmund, W-Germany Subject: Call for discussion: PC-Network Operating System Comparison Message-Id: <576@laura.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Currently I'm using a 3COM PC-Network with 3COM Software and 3COM Hardware and it performs quite miserably. Even optimizing the (much too many) parameters of the 3COM Operating system does not result in any performance gain. The problem seems to (partialliy!) located in the application software, which is stored in many files sized about 60k each - and stored its data in many small ASCII files. The whole application consists of about 1500 files (data and program). So maximizing or minimizing 3COM's Buffer size will definite not work. (PS.: TurboShare with 2048k EMS is installed!) Now I would like to know whether the other major Operating Systems for PC-Network will perform better than 3COM! What are Your experiences with PC Network Operating Systems? What do You think about BANYAN and it's VINES - it seems to bee unlimited in its facilities, but what about PERFORMANCE? Awaiting Your Replies Volker E-MAIL: edelhoff@exunido.BITNET  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Aug 88 19:29:31 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Aug 88 19:26:32 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 24 Aug 88 19:11:20 EDT Received: from USENET by bloom-beacon.mit.edu with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon.mit.edu if you have questions) Date: 24 Aug 88 21:39:49 GMT From: beowulf!pluto@sdcsvax.ucsd.edu (Mark E. P. Plutowski) Organization: EE/CS Dept. U.C. San Diego Subject: EMPLOYMENT OPPORTUNITY: PC's for Education. Message-Id: <5247@sdcsvax.UCSD.EDU> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu A progressive company in Phoenix needs a computer networker for all phases of development of a PC-based computer education system. This is a small division of a much larger national company. I wish i could do it myself, but i'm into neural networks, not LAN-lines. Serious inquiries may obtain the phone number and/or address of the vice-president CFO in charge by contacting me. DO NOT POST REPLY TO THIS BULLETIN BOARD. CONTACT ME DIRECTLY. ---------------------------------------------------------------------- Mark Plutowski Department of Computer Science, C-024 University of California, San Diego La Jolla, California 92093 Home: 3010 Glendora St., #10, San Diego, CA 92109-5743 INTERNET: pluto%cs@ucsd.edu pluto@beowulf.ucsd.edu BITNET: pluto@ucsd.bitnet UNIX: {...}!sdcsvax!pluto ----------------------------------------------------------------------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Jul 88 12:39:56 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Jul 88 12:36:47 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8207; Thu, 14 Jul 88 12:35:27 EDT Received: from MAINE.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8206; Thu, 14 Jul 88 12:35:26 EDT Received: by MAINE (Mailer X1.25) id 9054; Thu, 14 Jul 88 12:32:08 EDT From: CSMA193%MAINE.BITNET@MITVMA.MIT.EDU To: INFO-PCNET@MC.LCS.MIT.EDU Date: Thu, 14 Jul 88 12:30:58 EDT LIST  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Jul 88 18:36:33 EDT Received: from SIMTEL20.ARPA (TCP 3200000112) by MC.LCS.MIT.EDU 5 Jul 88 18:34:07 EDT Date: Tue, 5 Jul 1988 16:31 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: (John Lundin Jr) Cc: Info-PCNET@MC.LCS.MIT.EDU Subject: missing persons, versions and doc files In-reply-to: Msg of 4 Jul 1988 16:09-MDT from (John Lundin Jr) John, be aware that the PCNet name has been used by a commercial company and is now copyrighted. The group talked about challenging that but apparently it was never done. --Keith  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Jul 88 17:14:03 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 5 Jul 88 17:10:11 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1659; Tue, 05 Jul 88 17:09:19 EDT Received: from DACTH01.BITNET (YIJ) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1657; Tue, 05 Jul 88 17:09:18 EDT Received: from CY175.RZ.RWTH by DACTH01.BITNET (outbound name server) with BSMTP; 5 Jul 88 23:07:10 MEZ Message-ID: <880705230518108.HRPM@CY175.RZ.RWTH> (UMass-Mailer 4.04) Date: Tue, 5 Jul 88 23:05:36 MEZ From: Yij%DACTH01.BITNET@MITVMA.MIT.EDU Subject: HELP To: INFO-PCNET@MC.LCS.MIT.EDU HELP  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Jul 88 14:03:43 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 5 Jul 88 11:26:35 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7839; Tue, 05 Jul 88 11:24:35 EDT Received: from URVAX.BITNET (LUNDIN) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7837; Tue, 05 Jul 88 11:24:34 EDT Date: Mon, 4 Jul 88 18:09 EDT From: (John Lundin Jr) Subject: missing persons, versions and doc files To: INFO-PCNET@MC.LCS.MIT.EDU X-Original-To: "INFO-PCNET@MC.LCS.MIT.EDU", LUNDIN HELP!!! Information wanted... assistance welcomed. While looking for a protocol for a remote "smart" session handler, the descrip- tion of PCNet looked interesting. Now I have the material from Simtel20 and REM's fiche (Robert Elton Maas), and am more interested than ever. The result will not be the original PCNet, but will certainly do many of the same things. The initial micro versions are expected to be in Forth and Pascal, then ported to C. Access to a more complete, later HLL version would change this order. I'll be using an Atari ST, DEC Rainbow or PC clone, and also VAX/VMS for the remote terminal project (probably in Pascal unless I can locate the C version). One volunteer would be using Apple ][+ and ][e. Both current volunteers want machine readable material first... (sigh). Do you have any knowledge of anyone using PCNet, having used PCNet, or who has versions and/or documentation on PCNet? Please send a reply if you have information or if you would be interested in a revived project. * * * * * I am trying to track down the later HLL versions and documentation (Simtel20 only includes material through '82). In particular, I would like to locate Fylstra's and Heller's C versions, the rumored Forth version (never submitted) and the set of INFO files used for documentation (late '84?). REM has been unable to locate these on backup... Even incomplete versions would be welcome. I have heard that *someone* got a Forth version going, but haven't found out who or where yet. One suggestion (again from REM) was that I contact Kim Harris to see if he had this version. No network or USNail address... Again, even a partial implementation would help. People and versions of interest: I am looking for addresses for Dave Fylstra (was ) and Robert Heller (was ), both of whom had versions in C. Both are of great interest, neither was submitted that I know of. Fylstra's version is no longer on SRI-UNIX, Heller's was "too VMS specific" and so would probably be ideal if I could find it. Another version of interest was a Ratfor low level implementation by "MAP" (was , possible newer address , no answer but attempt not returned as invalid either). David C. Harris is listed in the Arpanet list of lists as "the organizational leader and in charge of releasing documents to the public". Mail has either vanished or (once) returned "no such user". Dave Caulkins once kept much of the PCNET documentation according to notes in the fiche. Last known address: . The cdp machine is apparently no longer there... * * * * * Thanks for your help. -john - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - John Lundin, Jr. VAX785::LUNDIN (UR/MCV Decnet) Richmond Forth Group LUNDIN @ URVAX (BITNET) 211 E. Grace St. lundin%urvax.bitnet@cunyvm.cuny.edu (Internet) Richmond, VA 23219 ...!psuvax1!urvax.bitnet!lundin (UUCP)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 May 88 21:15:43 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 21:28:14 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 25 May 88 14:27:23 EDT Received: from USENET by bloom-beacon with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 25 May 88 16:50:08 GMT From: zodiac!meridian!pkahn@ames.arpa (Phil Kahn) Organization: Advanced Decision Systems, Mt. View, CA (415) 941-3912 Subject: Re: HELP Me!!! Message-Id: <4067@zodiac.UUCP> References: <5823@cup.portal.com> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu In article <5823@cup.portal.com> JJ@cup.portal.com writes: >Poor College Student needs Your Help!! :-( > >Hi. I just finished my junior year in college, and now I'm >faced with a major problem. I can't afford to pay for my senior >year. I've tried everything. I can't get any more student loans, >I don't qualify for any more scholarships, and my parents are as >broke as am I. So as you can see, I've got a major problem. But >as far as I can see, there is only one solution, to go forward. >I've come along way, and there is no chance in hell that I'm going >to drop out now! I'm not a quiter, and I'm not going to give up. > >But here is why I'm telling you all this. I want to ask a favor of every >one out here on the net. If each of you would just send me a one >dollar bill, I will be able to finish college and go on with my life. >I'm sure a dollar is not much to any of you, but just think how it >could change a person's life. I'd really like to encourage all of you >to help me out, I've no other place to go, no other doors to knock >on. I'm counting on all of you to help me! (PLEASE!) >If you would like to help a poor boy out, please send $1 (you can >of course send more if you want!! :-) > *flame on* First, this and all the other newsgroups you posted this message are NOT the place for this shit. Do you REALIZE what it cost to send this dumb-ass message to the universe over so many newsgroups? That money alone would have sent you and probably several others through your senior year. It's not bad enough you want a free ride from us, but you also want a free ride from the net operators. Makes me wonder if your current situation isn't due to your own personality or behavior. I sincerely hope that some net administrators are listening to all of this and they cut you off. Second, I was in the same situation. So you "work 25 hours a week, go to classes, AND find time to study." Wow. Super awesome individual. Give me a break, will you? You're going to school to better yourself, and that doesn't only mean getting out in 4 years with a good GPA so you can get a fantastic job to pay for your BMW. If you can't hack it all, then reduce your course load, go the extra year and increase your work hours. Then again, if you can't live on working 25 hours a week (in Nebraska?), then you're probably at minimum wage. Then find a higher paying position. Cash in on all that marvelous knowledge you've acquired "in college" or use your cleverness to do something other than beg on a network at our expense. I have great empathy for your situation, it was a very difficult period in my life, but I have absolutely no patience for your misuse of this net and lack of self-initiative. *flame off*  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 May 88 14:07:02 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 25 May 88 13:27:23 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Tue, 24 May 88 20:53:43 EDT Received: from USENET by bloom-beacon with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@bloom-beacon if you have questions) Date: 24 May 88 00:55:37 GMT From: portal!cup.portal.com!JJ@uunet.uu.net Organization: The Portal System (TM) Subject: HELP Me!!! Message-Id: <5823@cup.portal.com> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Poor College Student needs Your Help!! :-( Hi. I just finished my junior year in college, and now I'm faced with a major problem. I can't afford to pay for my senior year. I've tried everything. I can't get any more student loans, I don't qualify for any more scholarships, and my parents are as broke as am I. So as you can see, I've got a major problem. But as far as I can see, there is only one solution, to go forward. I've come along way, and there is no chance in hell that I'm going to drop out now! I'm not a quiter, and I'm not going to give up. But here is why I'm telling you all this. I want to ask a favor of every one out here on the net. If each of you would just send me a one dollar bill, I will be able to finish college and go on with my life. I'm sure a dollar is not much to any of you, but just think how it could change a person's life. I'd really like to encourage all of you to help me out, I've no other place to go, no other doors to knock on. I'm counting on all of you to help me! (PLEASE!) If you would like to help a poor boy out, please send $1 (you can of course send more if you want!! :-) Jay-Jay's College Fund PO BOX 5631 Lincoln, NE 68505 PS. Please don't flame me for posting this to so many newsgroups, I really am in dire need of help, and if any of you were as desparate as I am, you just might resort to the same thing I am. Also, please don't tell me to get a job! I already have one and work over 25 hrs a week, plus get in all my classes, plus find time to study! So hey, please consider it! It would really mean a lot to me. Thank you! NOTE: Any extra money I receive will go to a scholarship fund to help others in the same situation. :-)  Received: from po2.andrew.cmu.edu (TCP 20000574551) by AI.AI.MIT.EDU 4 May 88 20:13:59 EDT Received: by po2.andrew.cmu.edu (5.54/3.15) id for Info-PCNet@ai.ai.mit.edu; Wed, 4 May 88 20:12:32 EDT Received: via switchmail; Wed, 4 May 88 20:12:22 -0400 (EDT) Received: from norwich.andrew.cmu.edu via qmail ID ; Wed, 4 May 88 20:11:50 -0400 (EDT) Received: from norwich.andrew.cmu.edu via qmail ID ; Wed, 4 May 88 20:11:28 -0400 (EDT) Received: from Messages.6.14.CUILIB.3.44.SNAP.NOT.LINKED.norwich.andrew.cmu.edu.rt.r2 via MS.5.3.norwich.andrew.cmu.edu.rt_r2; Wed, 4 May 88 20:11:26 -0400 (EDT) Message-Id: Date: Wed, 4 May 88 20:11:26 -0400 (EDT) From: "C. V. R. Murthy" X-Andrew-Message-Size: 1008+0 To: Info-PCNet@ai.ai.mit.edu Subject: Somebody teach this novice ? Hello, Is this a proper forum to ask some fundamental questions on the IBM PC - Ethernet Interface card (NIC) interface ? (hardware as well as software). If not so : please skip reading this beyond this line with a request for any pointers to sources of information. If so I would appreciate some body suggest me answers to following questions ? (some references journals etc also will do ) Hardware Questions : What kind of interface is generally used : DMA etc ? How does PC CPU and NET CPU talk to each other via extension slot ? Is there a speacial mechanism for interface between PC and NIC : eg FIFO or custom built chips ? Software Questions : Does this networking require a device driver to be written (in order to interface to MSDOS)? What is the usual interface to a programmer writing network applications : such as telnet or tftp ? I need to understand these points to implement an interface between a serial world and the Ethernet. Thanks Very Much, -- Murthy.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Apr 88 09:05:37 EDT Received: from mitre.arpa (TCP 3200000021) by MC.LCS.MIT.EDU 4 Apr 88 09:03:32 EDT Full-Name: LT Sheri Smith USN Message-Id: <8804041251.AA15917@mitre.arpa> Organization: The MITRE Corp., Washington, D.C. To: info-pcnet@mc.lcs.mit.edu Subject: please remove me from your mailing list Date: Mon, 04 Apr 88 07:51:44 EST From: LT Sheri Smith USN  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Apr 88 00:47:23 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 3 Apr 88 23:09:14 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Sun, 03 Apr 88 23:06:24 EST Received: from Uofmcc.Bitnet by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7831; Sun, 03 Apr 88 23:06:01 EST Date: Sun, 03 Apr 88 22:05 cdt From: #YEUN14%UOFMCC.BITNET@MITVMA.MIT.EDU To: info-pcnet@mc.lcs.mit.edu, info-postscript@su-score.arpa Subject: mailing list I want to be on your mailing list , QUIT  Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by AI.AI.MIT.EDU 1 Mar 88 08:10:47 EST Received: from CSUOHIO.BITNET by CUNYVM.CUNY.EDU ; Tue, 01 Mar 88 08:07:25 EST Date: 01 Mar 88 08:10 EDT From: C0144%CSUOHIO.BITNET@CUNYVM.CUNY.EDU To: info-pcnet@ai.ai.mit.edu Subject: Sending Mail to Fidonet from the Internet (Reply to Fred Baube, forwarded to Info-pcnet) In the event that you can't get through to Tim Pozar through the address that Stef gave, feel free to try using the Usenet/Fido gateway here in Cleveland. The To: line would be as follows: To: ihnp4!necntc!ncoast!ohiont!125!406!Tim_Pozar@husc6.harvard.edu You can run it successfully through the BITNET gateway at CUNYVM. You can reasonably expect a couple days delay before getting a reply, however, since the message will have to go from Cleveland to San Francisco via FidoNet. Generally, I handle traffic for FidoNet Region 11 (the midwest), but am capable of forwarding mail for anyone having difficulty elsewhere. Good luck - if you have any questions, please give me a hollar at one of the addresses below. -Dave +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From the North Coast David Chatfield, Computer Services Dept. _____ of America...._-! Cleveland State University ! --___ ___-- ! ! ------(*) ! Bitnet: C0144@CSUOHIO ! Cleveland ! Arpa: C0144%CSUOHIO.BITNET@CUNYVM.CUNY.EDU ! ! Usenet: {ihnp4}!necntc!ncoast!ohiont!davec ! O H I O ! Fidonet: Sysop, OHIONet Express, 1:157/512 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++  Received: from nrtc.nrtc.northrop.com (TCP 20030600001) by AI.AI.MIT.EDU 29 Feb 88 19:58:09 EST Received: by nrtc.nrtc.northrop.com id aa13941; 29 Feb 88 16:53 PST Received: from nma.com by nrtc.nrtc.northrop.com id aa13725; 29 Feb 88 16:35 PST Received: from localhost by nma.com id aa27218; 29 Feb 88 16:35 PST To: Fred Baube cc: LUNDIN%URVAX.BITNET@cunyvm.cuny.edu, info-pcnet@ai.ai.mit.edu, Tom Jennings FIDOnet , Tim Pozar FIDOnet Subject: Re: Help! In-reply-to: Your message of Mon, 29 Feb 88 17:17:20 -0500. <8802291717.aa17700@note.nsf.gov> Reply-to: Stef@nrtc.northrop.com From: Einar Stefferud Date: Mon, 29 Feb 88 16:34:58 -0800 Message-ID: <27215.573179698@nma.com> Sender: stef@nrtc.northrop.com > Last week I asked for FidoNet info, and have gotten some replies > (Thank you!). I can't, though, seem to get a reply thru to "Tim", for > whom I've been given the email addresses below. Can anyone help? I'm > on the Internet and on Bitnet. For all who want to reach FIDOnet, I believe these addresses work to reach two of the principal people in FIDOnet. I also suggest that you include your phone number in strong pleas for ehlp when the network addresses you have do not sdeem to work. I forwarded your original plea for help to these addresses so they could attempt to contact you. ...\Stef  Received: from note.nsf.gov (TCP 1202200024) by AI.AI.MIT.EDU 29 Feb 88 17:39:20 EST To: LUNDIN%URVAX.BITNET@CUNYVM.CUNY.EDU, info-pcnet@AI.AI.MIT.EDU Subject: Help! Date: Mon, 29 Feb 88 17:17:20 -0500 From: Fred Baube Message-ID: <8802291717.aa17700@note.nsf.gov> Last week I asked for FidoNet info, and have gotten some replies (Thank you!). I can't, though, seem to get a reply thru to "Tim", for whom I've been given the email addresses below. Can anyone help? I'm on the Internet and on Bitnet. Sysop@fidogate.ifna.org This one did not work. From the FidoNet Gateway : 1:125/406 ...!{hoptoad, lll-winken}!node406.net125.zone1.IFNA.ORG I could not get the bang path to work. Someone suggested that the form should be something like node406!net125!zone1 (i.e. "!"s instead of some "."s). I assume "org" is the domain for "ifna". If someone can get me connected to FidoNet via this gateway, I'll post the results. Thanx /f  Received: from note.nsf.gov (TCP 1202200024) by AI.AI.MIT.EDU 26 Feb 88 17:28:46 EST To: info-pcnet@AI.AI.MIT.EDU Subject: FidoNet Date: Fri, 26 Feb 88 17:09:38 -0500 From: Fred Baube Message-ID: <8802261709.aa23770@note.nsf.gov> Is this where I can find out about FidoNet ? Please reply directly, I'm not on the mailing list. Thanx !  Received: from XX.LCS.MIT.EDU (CHAOS 2420) by AI.AI.MIT.EDU 19 Dec 87 18:28:08 EST Return-Path:<> Date: Sat, 19 Dec 1987 18:19 EST Message-ID: From: Rob Austein To: Rahul Dhesi <00R0DHESI%bsu.csnet@RELAY.CS.NET> Cc: Postmaster@íc.lcs.mit.edu¬info-pcnet@ÍC.LCS.MIT.EDU¬info-pcnet-request@ÍC.LCS.MIT.EDUŠ Subject: INFO-PCNET@MC.LCS.MIT.EDU shut down Reply-To: Postmaster@mc.lcs.mit.edu In-reply-to: Msg of 18 Dec 1987 09:25-EST from Rahul Dhesi <00R0DHESI%bsu.csnet@RELAY.CS.NET> Date: Friday, 18 December 1987 09:25-EST From: Rahul Dhesi <00R0DHESI%bsu.csnet@RELAY.CS.NET> To: info-pcnet@MC.LCS.MIT.EDU Re: Darned info-pcnet list--get me off it ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Postmaster at MC.LCS.MIT.EDU ReSent-Date: Sat 19 Dec 1987 12:45-MST Keith, thanks for forwarding this. Does anybody know who is responsible for the info-pcnet fiasco, and why they can't fix it? I keep receiving messages from this list, despite repeated attempts to get removed from this list. Probably because the original moderator/coordinator went away and the person who revived the list didn't take responsibility for taking over coordination. The Postmaster at mc.lcs.mit.edu seems to just ignore my requests that something be done about this infernal list, and so does the info-pcnet-request address. I don't recall having seen any previous message on this subject sent to Postmaster@MC, unless you're the person who sent the nastygram a month or so ago threatening to send repeat copies of that message every hour until somebody did what you wanted (I intentionally forget about messages like that). In any case, there are better ways to introduce yourself to random strangers when you're about to ask them to do something for you. Can anybody supply me with a telephone number for the culprits responsible for this list? Or a US postal address? Perhaps verbal threats or through the US mail will have some effect. Or, if you happen to be in the area, I respectfully request you to unplug the computer system responsible for this list, or use any other means necessary to shut it down. Thank-you. Again, a little courtesy would be appreciated. For your sake, I do hope you weren't serious about the last part of this; the MIT campus police take a dim view of this sort of thing. Effective immediately, the INFO-PCNET@MC.LCS.MIT.EDU list is shut down, pending someone willing to step forward to act as a responsible coordinator. --Rob Austein (for Postmaster@MC.LCS.MIT.EDU)  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Dec 87 11:43:26 EST Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 19 Dec 87 11:45:22 EST Received: from [128.89.1.80] by RELAY.CS.NET id aa01100; 19 Dec 87 11:37 EST Received: from bsu by csnet-relay.csnet id ab03889; 19 Dec 87 11:34 EST Date: Fri, 18 Dec 87 09:25 EST From: Rahul Dhesi <00R0DHESI%bsu.csnet@RELAY.CS.NET> To: info-pcnet@mc.lcs.mit.edu Subject: Darned info-pcnet list--get me off it X-VMS-To: IN%"info-pcnet@mc.lcs.mit.edu",00R0DHESI Does anybody know who is responsible for the info-pcnet fiasco, and why they can't fix it? I keep receiving messages from this list, despite repeated attempts to get removed from this list. The Postmaster at mc.lcs.mit.edu seems to just ignore my requests that something be done about this infernal list, and so does the info-pcnet-request address. Can anybody supply me with a telephone number for the culprits responsible for this list? Or a US postal address? Perhaps verbal threats or through the US mail will have some effect. Or, if you happen to be in the area, I respectfully request you to unplug the computer system responsible for this list, or use any other means necessary to shut it down. Thank-you. R. Dhesi dhesi@bsu.edu or 00r0dhesi@bsu.edu or dhesi%bsu@relay.cs.net etc.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Dec 87 14:33:58 EST Received: from MATHOM.CISCO.COM (TCP 30007603421) by MC.LCS.MIT.EDU 17 Dec 87 14:35:14 EST Date: Thu 17 Dec 87 11:33:41-PST From: William Westfield Subject: Re: Does the Info-PCnet list exist? To: LUNDIN%URVAX.BITNET@CUNYVM.CUNY.EDU cc: info-pcnet@MC.LCS.MIT.EDU In-Reply-To: Message from " (John Lundin Jr)" of Thu 17 Dec 87 11:17:55-PST Message-ID: <12359254688.7.BILLW@MATHOM.CISCO.COM> The PCNet project was essentially killed by the entry of more powerful computers and faster modems in the market, not to mention data services like compuserve. After all, why work hard defining a standard and then implementing it, when you can get full TCP on your PC anyway... There were soem ideas in PCNet that are still interesting, but these days it isn't worth redefining the world to get just a couple of interesting features... Bill Westfield -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Dec 87 14:00:53 EST Received: from CUNYVM.CUNY.EDU (TCP 20071000402) by MC.LCS.MIT.EDU 17 Dec 87 13:57:57 EST Received: from URVAX.BITNET by CUNYVM.CUNY.EDU ; Thu, 17 Dec 87 12:54:10 EST Date: Thu, 17 Dec 87 12:49 EDT From: (John Lundin Jr) Subject: Does the Info-PCnet list exist? To: info-pcnet@mc.lcs.mit.edu X-Original-To: "info-pcnet@mc.lcs.mit.edu.interbit", LUNDIN I've tried sending to info-pcnet-request@mc.lcs.mit.edu (listed for contact in the "arpanet.list" postings on Bitnic) five times over the last few months, with no replies and no bounces. This time I'm posting to the list itself. How about it, does this group still exist? If it does, what's the project status, how do you join in, and how do you get the software and/or back messages over Bitnet (or USnail). Many thanks. ------------------------------------------------------------------------ John Lundin, Jr. Bitnet: LUNDIN@URVAX Internet: lundin%urvax.bitnet@cunyvm.cuny.edu  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Dec 87 08:46:35 EST Received: from jade.berkeley.edu (TCP 20010104011) by MC.LCS.MIT.EDU 5 Dec 87 08:42:09 EST Received: by jade.berkeley.edu (5.54 (CFC 4.22.3)/1.16.17) id AA28281; Sat, 5 Dec 87 05:40:27 PST Message-Id: <8712051340.AA28281@jade.berkeley.edu> Date: Sat, 5 Dec 1987 08:38:39 EDT From: FAC0395%UOFT01.BITNET@jade.berkeley.edu (J. Feustle) To: info-pcnet@mc.lcs.mit.edu Please add me to your distribution list. Thanks. Joe Feustle. FAC0395@UOFT01.BITNET  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Dec 87 07:13:59 EST Received: from clark-emh.arpa (TCP 3200200131) by MC.LCS.MIT.EDU 5 Dec 87 07:06:30 EST Date: 5 Dec 87 11:49:43 GMT From: jedi @ Clark-EMH.arpa To: INFO-PCNET @ MC.LCS.MIT.EDU Please add me to your list for distribution. Thank you, Mike Hampton  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Nov 87 08:50:35 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 16 Nov 87 08:51:56 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU ; Mon, 16 Nov 87 08:47:15 EST Received: from TWNMOE10.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2747; Mon, 16 Nov 87 08:47:11 EST Received: by TWNMOE10 (Mailer X1.25) id 6033; Mon, 16 Nov 87 21:46:56 CST Date: Mon, 16 Nov 87 21:45:43 CST From: Mu Hwa Harn Subject: Help To: INFO-PCNET@MC.LCS.MIT.EDU HELP  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 Nov 87 02:14:33 EST Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 9 Nov 87 02:16:45 EST Received: by ucbvax.Berkeley.EDU (5.58/1.27) id AA19139; Sun, 8 Nov 87 22:48:57 PST Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Nov 87 05:56:36 GMT From: ddl@husc6.harvard.edu (Dan Lanciani) Organization: Harvard University Computer Services Subject: how to "NET SEND" Message-Id: <3136@husc6.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Does anyone know to which name object to connect (or send datagrams) to in order to convince the PC Network Program that it received a message similar to that generated by a "NET SEND" command? (And the format of the data would be useful too...) Dan Lanciani ddl@harvard.*  Received: from esdvax.arpa (TCP 3202000102) by AI.AI.MIT.EDU 25 Oct 87 10:31:20 EST Date: 24 Oct 87 11:27:00 GMT+109:13 From: Subject: COS in house protocols To: "info-pcnet" Reply-To: I N T E R O F F I C E M E M O R A N D U M Date: 24-Oct-1987 11:27 From: Gerry Schmid Username: SCHMIDG Dept: Tel No: (617)-256-3969 TO: _MAILER! ( _DDN[INFO-PCNET@AI.AI.MIT.EDU] ) TO: _MAILER! ( _DDN[PROTOCOLS@RUTGERS.EDU] ) TO: _MAILER! ( _DDN[CLYDE!WATMATH!UTGPU!UTZOO!HENRY@RUTGERS.EDU] ) TO: _MAILER! ( _DDN[KPETERSON@SIMTEL20.ARPA] ) Subject: COS in house protocols Subject: [TCP/IP Mail From: <@AI.AI.MIT.EDU:KPETERSEN@SIMTEL20.ARPA>] OSI Return-Path: <@AI.AI.MIT.EDU:KPETERSEN@SIMTEL20.ARPA> Received: from AI.AI.MIT.EDU by esdvax.arpa ; 1 Sep 87 08:56:12 GMT+0:42 Received: from SIMTEL20.ARPA (TCP 3200000112) by AI.AI.MIT.EDU 1 Sep 87 08:36:41 EDT Date: Monday, 31 August 1987 13:09-MDT Message-ID: Sender: clyde!watmath!utgpu!utzoo!henry@RUTGERS.EDU (Henry Spencer) From: clyde!watmath!utgpu!utzoo!henry@RUTGERS.EDU (Henry Spencer) To: protocols@RUTGERS.EDU Subject: OSI ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-PCNET at AI.AI.MIT.EDU ReSent-Date: Tue 1 Sep 1987 06:32-MDT > The entire globe needs yet anotehr new protocol like it needs 5 billion > new holes, one each in the heads of the earth's 5 billion people. > Interesting that you should say this in the context of an article that > basically says "run OSI". Ever heard of TCP/IP? :-) > -- > "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology > than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry This item appears on page 15 of the June 1987 issue of Data Communications. ============================================ For Own In-House Network, COS Selects TCP/IP That's right. The consortium of vendor and user heavyweights, the Corporation for Open Systems (COS), which exists solely to accelerate the development and deployment of products based on the Open Systems Interconnection (OSI) specifications, confirms that its own in-house computer network will use the renegade transmission control protocol/internet protocol (TCP/IP) set, and not OSI transport and network protocols, at least not initially. "I realize it may look bad, but we *do* plan to migrate [to the OSI protocols]," says Steve Smith, a COS researcher. COS expects its in-house network -- consisting largely of Unix-based Sun Microsystem workstations, Unix-based file servers, and Ethernet connections supplied by Bridge Communications -- to be up and running within the next few weeks. Aware that charges are likely to fly that COS isn't practicing what it preaches when it comes to implementing OSI, COS officials declined further comment. It seems the decision to go with TCP/IP -- even though several COS members, including IBM, Retix, and Touch Communications, for example, now offer OSI network/transport-layer products -- was made reluctantly, because the vendors whose gear COS researchers wanted (Sun, Bridge) do not offer OSI connections. There could, however, be another reason for the interim acceptance of TCP/IP: COS is long overdue in setting up a test facility for checking out OSI network/transport product implementations and certifying their intercompatibility. And selecting an OSI product for use in its own network, which has not passed COS's own certification muster, might have been viewed as an even bigger political gaffe than going with TCP/IP. ------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Sep 87 18:37:46 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 21 Sep 87 14:52:01 EDT Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 09/21/87 at 14:03:55 EDT Received: from YALEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3513; Mon, 21 Sep 87 13:58:04 EDT Received: by YALEVM (Mailer X1.24) id 7419; Mon, 21 Sep 87 13:57:02 EST Date: Mon, 21 Sep 87 13:56:17 EST From: Naama Zahavi-Ely Subject: add to list To: INFO-PCNET digest Please add me to your mailing list. Thanks in advance, Naama Zahavi-Ely  Received: from SIMTEL20.ARPA (TCP 3200000112) by AI.AI.MIT.EDU 1 Sep 87 08:36:41 EDT Date: Monday, 31 August 1987 13:09-MDT Message-ID: Sender: clyde!watmath!utgpu!utzoo!henry@RUTGERS.EDU (Henry Spencer) From: clyde!watmath!utgpu!utzoo!henry@RUTGERS.EDU (Henry Spencer) To: protocols@RUTGERS.EDU Subject: OSI ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-PCNET at AI.AI.MIT.EDU ReSent-Date: Tue 1 Sep 1987 06:32-MDT > The entire globe needs yet anotehr new protocol like it needs 5 billion > new holes, one each in the heads of the earth's 5 billion people. Interesting that you should say this in the context of an article that basically says "run OSI". Ever heard of TCP/IP? :-) -- "There's a lot more to do in space | Henry Spencer @ U of Toronto Zoology than sending people to Mars." --Bova | {allegra,ihnp4,decvax,utai}!utzoo!henry  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 28 Aug 87 14:39:57 EDT Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 28 Aug 87 14:38:24 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa18170; 28 Aug 87 14:30 EDT Received: from btl by csnet-relay.csnet id bf03064; 28 Aug 87 14:23 EDT To: info-pcnet%mit-mc.arpa@RELAY.CS.NET From: booth%vax135.att.com@RELAY.CS.NET Date: Fri 28 Aug 1987 12:43:10 Original-From: vax135!booth (David Booth) Original-To: research!arpa!info-pcnet@mit-mc.arpa Subject: Explanations of acronyms/abbreviations Moderator: would you please post this to INFO-PCNET? I am told that I will get a horrendous number of returned messages if I try it myself. Thanks. -- David Booth ---------- The following list (hopefully) explains most of the non-obvious acronyms/abbreviations that appeared in the previous message from Einar Stefferud . There was an extraordinary number of them, several of which baffled me, so I thought others might benefit by my posting this list. Thanks to Einar for filling in the explanations. Please also let this serve as a reminder to avoid any unnecessary acronyms/abbreviations in your postings, and define those that you do use. Thanks. ACSE Association Control Service Entity (ISO/CCITT layer 7) ASN Abstract Syntax Notation One (ISO/CCITT ASN.1) CAMTEC Probably an ac.uk host address or user address therein CCITT Consultative Committee on Int'l Telephone & Telegraph DIS Draft International Standard (eg ISO) DMF Probably part of an X.400 address in Europe EAN Ceratinly part of an X.400 Address in Europe FTAM File Transfer And Management (ISO upscale FTP) GOSIP Government Open Systems Interconnection Profile (calls for government procurement of ISO/CCITT products) IS International Standard (Beyond the DIS Stage) ISO International Standards Organization ISODE ISO Development Environment (defined inn the text) MHS Mail Handling System (Defined in the Text) NBS National Bureau of Standards (USA) NIFTP (a file transfer network in the UK) NPL National Physical Laboratory (UK) OI (this one escapes me -- Typo? Part of an address?) OSI Open Systems Interconnection (per ISO 7 layer model) PSS (unknown to me, but something in the UK environment) RARE Research Academic R(something) Europe (a Research Network) RFC Request For Comments (ala ARPA Internet) ROSE Remote Operations Service Entity (per ISO/CCITT layer 7) SUN Stanford University N(something) SUN MicroSystems Computer TP from TP0 and TP4 (ISO/CCITT Transport Services; like TCP) UBC University of British Columbia UCL University College London WG Working Group David Booth UUCP: {harvard, seismo, ucbvax}!vax135!booth Arpanet: vax135!booth@ucbvax.berkeley.edu  Received: from nrtc.arpa (TCP 20030600001) by AI.AI.MIT.EDU 26 Aug 87 18:18:12 EDT Received: from nma.com by nrtc.northrop.com id a019181; 26 Aug 87 15:14 PDT Received: from localhost by nma.com id aa01432; 26 Aug 87 14:09 PDT To: Info-PCNet-Request@ai.ai.mit.edu cc: INFO-PCNET@ai.ai.mit.edu In-reply-to: Your message of Tue, 25 Aug 87 01:24:00 -0400. <245929.870825.MAP@AI.AI.MIT.EDU> Reply-to: Stef@nrtc.arpa Date: Wed, 26 Aug 87 14:09:20 -0700 Message-ID: <1429.557010560@nma.com> From: Einar Stefferud I am sending this to the whole list, plus -request because I think it is important to immediately press a vital issue, as follows: The entire globe needs yet anotehr new protocol like it needs 5 billion new holes, one each in the heads of the earth's 5 billion people. We have seen much effort put into development of the new OSI stuff (ISO/CCITT/NBS/...). I would much prefer to see you and others put their efforts into spreading the new OSI stuff around and making it available and useful on lower order machines of the class we commonly call PC's today. In particular this includes the use of dialup public switched telephone connections to pass Mail, Transfer Files, and do Remote Logins. There is a reasonably large gap in the ISO/CCITT OSI suite in this special area. Use of DialUp connections is very hard to accomplish. But, at the higher levels (Session, Presentation, ASN.1, ROSE, ACSE, FTAM, et al) much of the desired work has been done. Much, but not all is freely available to the public (almost but not quite public domain). X.400 Mail Handling Systems are already available for MSDOS for prices under $500 per copy. I would propose that this revived PCNET effort be focused on taking this existing body of OSI stuff and porting it down to PC Class machines. And then add to it the ability to use DialUp connections at the Network Layer, under TP0 for use by Session and the other Higher Layers. You can freely obtain copies of the relevant ISO Development Environment stuff from several sources in the US and Europe. See my attached notice of a new FTAM Service that is offered in the UK. OIn shoort, there is a really massive movement already underway, and it is my proposal that you all work to take advantage of it by hooking the PCNET effort to it to make it available tro the masses of Isolated PC Class Systems out there in the DialUp World. ------- Included FTAM Service Announcement Date: Sat, 22 Aug 87 11:27:59 +0100 Subject: FTAM Service at UCL From: Steve Kille To: rare-wg2%vax.runit.unit.uninett@cs.ucl.ac.UK, rare-wg1%vax.runit.unit.uninett@cs.ucl.ac.UK, mailgroup@cs.ucl.ac.UK, osi-tg%aucc.ac.uk@cs.ucl.ac.UK, isode@gremlin.nrtc.northrop.COM cc: service@cs.ucl.ac.UK I am pleased to announce an experimental FTAM service at UCL. Let me explain what I mean by this, and why I have sent this message to such a large group of people. By FTAM, I mean the ISODE implementation, which is to DIS, with a few pieces of critical information taken from the IS. By service, I mean that from now on, we intend to make all public files at UK.AC.UCL.CS (currently available by NIFTP), also available by FTAM. I believe that the software we have is now in a state where this will start to be useful to some sites. We have already shipped many megabytes over PSS, and have some confidence that this system is usable. To start with, the following are available: 1) UCL Service documents and guides 2) RFCs (the UCL collection, which is substantial, but not complete) 3) Mailgroup documents 4) ISODE Sources The service is available on PSS (23421920030016) and on Janet (0000051160016). It is also available on the Internet, at CS.UCL.AC.UK on the ISODE socket. The transport selector is 256, which should be ASCII encoded (we do also accept the rather bizarre US GOSIP encoding). There are no other selectors. Username "anon" will give public access. The locations of the files should be "obvious". Why announce this now? 1) This so far appears to be the only DIS FTAM implementation around. I do not really believe this, and hope that this may encourage some of the others to creeep out of the woodwork. Interworking tests are clearly desirable. Perhaps I should note here, is that UCL's interest is in promoting and using OSI. We are not intending to do FTAM development. 2) The timing is so that this topic may be discussed at the RARE WG1 and WG2 meetings, where it is relevant. In particular, I believe that this system is appropriate for an experimental RARE service, perhaps along the lines of the EAN experimental MHS service that has been emerging. This could be a core activity for WG2. WG1 have a need for document and table update. 3) It might be useful to someone What is the software? The ISODE software is written in C, and targetted initially for UNIX (it is aimed to be as independent of UNIX as possible). There will be a new release (ISODE 3.0) available in the near future. This will contain support for three different X.25 interfaces: SUN (Sunlink) Vax (CAMTEC Dexpand) Vax (DMF 32 + UBC interface) Announcements will be made to the ISODE list (contact isode-request@gremlin.nrtc.northrop.com). Europeans may be added to the European expansion of this list (contact isode-request@cs.ucl.ac.uk). Who is responsible: Most of the system has been written by Marshall Rose of Northrop. Credit should also go to John Pavel of NPL and George Michaelson of UCL for making the X.25 fly, and to George for setting up the service. onward with OSI! Steve ------- End of included FTAM Service Announcement  Date: Tue, 25 Aug 87 01:24:00 EDT From: Info-PCNet-Request@AI.AI.MIT.EDU Sender: MAP@AI.AI.MIT.EDU To: INFO-PCNET@AI.AI.MIT.EDU Message-ID: <245929.870825.MAP@AI.AI.MIT.EDU> PCNet rises from the dead I am about to embark on a project which has many goals in common with the original PCNet project. Since there is nothing available that will meet our needs I will be writing all new software for the most part, with minor borrowing from other programs. I expect to build on the work originally done for the PCNet project, adapting some of it based on new knowledge about networking but keeping most parts as is. There are several goals of the original PCNet project which are not strictly required for this work, however I personally feel that they are important and should be allowed for. Since I am the principal architect of the new work, I will leave the hooks there. As I begin to think about the project I have several observations and many questions. First the observations: o It is my observation that in order to get the best possible design it is desirable to get as much input as possible on each design decision. This is why I am sending out this notice to the PCNet group at this time, to solicit contributors. o On the other hand designs are more coherent when there is one person who coordinates the inputs. o The original PCNet project was a noble effort, however it is my feeling that it was in fact slightly ahead of it's time. There has been quite a lot of development in recent years which can be adopted wholesale for use in such an endeavor, much effort was expended the first time around trying to design things that can now be "copied". o As the maintainer of the Info-PCNet list, I have noticed quite an increase in the number of people expressing interest in this type of endeavor. I feel that it may be the right time to try and actually build something. Now the questions which I feel should be answered first: o Is this the appropriate group to discuss something new on? It is my feeling that, since the original project has in fact become so moribund, it is probably a reasonable start. There doesn't seem to actually be much discussion of the existing PCNet and I feel that those who were interested in that effort would be interested in any new proposals. o Does anybody know of any other work that I should look at before starting to think about this design? Now for perhaps the most important question of them all: What should the new thing be called? Here are several points I have pondered in this line: o One idea is to assign the original name (i.e. PCNet) to the new project and officially declare the original work a "Preliminary" design. Before I did this I would want to hear from most of the main characters in the original design team. I also wonder whether there is anyone other than me actually using any portion of the original design. There is also the question of Copyright/Trademark. Wasn't there some company that came out with a product with this name? What ever became of them? Did the PCNet project ever succeed in the effort to challenge them? I see much discussion, but no resolution to this in a quick reading of the archives. There is also the problem with this name that the letters PC have come to mean a specific machine rather than being a general term. o A quick perusal of all words ending in -net (using our on-line webster's dictionary) did not generate any names that immediately inspired me as words to try and fit an acronym to. I expect if we want to come up with a new name we should think about it some. I have one candidate, and if it comes to that I will solicit others. Finally, I would like to request that anyone who wants to comment on the above (particularly any of the prime-movers in the original effort), should send a short note to Info-PCNet-Request. I will collect the full text of all responses (unless requested otherwise) and make them available for anonymous FTP. I will also summarize the specific responses to these questions (so please be clear about it): 1: Do we discuss it here or create yet another list? 2: Should we come up with a new name? 2a: Any suggestions?  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Jul 87 19:34:14 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 31 Jul 87 19:35:02 EDT Received: from (MAILER)MITVMA.BITNET by MITVMA.MIT.EDU on 07/31/87 at 19:34:53 EDT Received: from ACAD2A.BITNET (VFWDE) by MITVMA.MIT.EDU (Mailer X1.24) with BSMTP id 6907; Fri, 31 Jul 87 19:34:48 EDT Date: Fri, 31 Jul 87 15:34 ADT From: Subject: To: info-pcnet@mc.lcs.mit.edu X-Original-To: info-pcnet@mc.lcs.mit.edu, VFWDE Please add me to your mailing list.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Jul 87 16:11:37 EDT Received: from CC5.BBN.COM (TCP 20026200130) by MC.LCS.MIT.EDU 20 Jul 87 16:08:52 EDT Received: from cca.bbn.com by CC5.BBN.COM id aa09939; 9 May 87 22:22 EDT Date: Sat, 9 May 87 22:13:13 EDT From: Root on BBNCCA Subject: Undeliverable mail To: root@CC5.BBN.COM Resent-Date: Mon, 20 Jul 87 16:01:55 EDT Resent-From: ezf@CC5.BBN.COM Resent-To: info-pcnet@MC.LCS.MIT.EDU Mail to host "[255.255.255.255]" could not be sent. Destination host is unknown. ------- Unsent message is below ------- Date: Sat, 9 May 87 22:08:08 EDT From: Root on BBNCCA Subject: Undeliverable mail To: CS527@ouaccvmb.bitnet Mail to host "[255.255.255.255]" could not be sent. Destination host is unknown. ------- Unsent message is below ------- Received: from BBN.COM by CCA.BBN.COM ; 9 May 87 22:07:32 EDT Received: from ai.ai.mit.edu by BBN.COM id aa23331; 9 May 87 22:10 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 May 87 21:46:50 EDT Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 9 May 87 21:46:02 EDT Received: from OUACCVMB.BITNET by wiscvm.wisc.edu ; Sat, 09 May 87 20:43:12 CDT Date: Sat, 09 May 87 21:41:53 EDT To: info-pcnet@MC.LCS.MIT.EDU From: CS527%OUACCVMB.BITNET@WISCVM.WISC.EDU Date: 9 May 1987, 21:41:13 EDT From: Mitchell Aidelbaum (614) 592-9841 CS527 at OUACCVMB To: INFO-PCNET@MC.LCS.MIT.EDU at EDU sub: info Can I have info on pc-net. Thank you.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Jul 87 16:01:37 EDT Received: from CC5.BBN.COM (TCP 20026200130) by MC.LCS.MIT.EDU 20 Jul 87 15:57:43 EDT Received: from cca.bbn.com by CC5.BBN.COM id aa00402; 8 May 87 18:54 EDT Date: Fri, 8 May 87 18:46:01 EDT From: Root on BBNCCA Subject: Undeliverable mail To: root@CC5.BBN.COM Resent-Date: Mon, 20 Jul 87 15:51:36 EDT Resent-From: ezf@CC5.BBN.COM Resent-To: info-pcnet@MC.LCS.MIT.EDU Mail to host "[255.255.255.255]" could not be sent. Destination host is unknown. ------- Unsent message is below ------- Date: Fri, 8 May 87 18:45:48 EDT From: Root on BBNCCA Subject: Undeliverable mail To: #JFDOBB@wmmvs.bitnet Mail to host "[255.255.255.255]" could not be sent. Destination host is unknown. ------- Unsent message is below ------- Received: from BBN.COM by CCA.BBN.COM ; 8 May 87 18:41:01 EDT Received: from ai.ai.mit.edu by BBN.COM id aa03104; 8 May 87 18:43 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 May 87 18:13:45 EDT Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 8 May 87 18:12:52 EDT Received: from WMMVS.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 17:09:51 CDT DATE: 05/08/87 18:10:36 EST TO: INFO-PCNET@MC.LCS.MIT.EDU FROM: #JFDOBB%WMMVS.BITNET@WISCVM.WISC.EDU SUBJECT: info-pcnet Could you please add me to your mailing list for INFO-PCNET? Thank you. John Dobbin  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Jun 87 14:15:30 EDT Received: from nrtc.northrop.com (TCP 20030600020) by MC.LCS.MIT.EDU 20 Jun 87 14:12:15 EDT Received: from localhost by isd.nrtc.northrop.com id aa29513; 20 Jun 87 11:11 PDT To: EarlShaffer cc: info-pcnet@mc.lcs.mit.edu Subject: Re: LU6.2 / APPC In-reply-to: Your message of 19 Jun 87 19:31:40 +0000. <1374@super.upenn.edu.upenn.edu> Date: Sat, 20 Jun 87 11:10:59 -0700 Message-ID: <29510.551211059@nrtc-isd> From: Einar Stefferud I suggest that you contact your friendly ibm salesperson. They to be loaded with literature. I have seen tons of stuff with the ibm logo. Or are you seeking independent sources of unbiased evaluation information. Have you checked DataCommunications Magazine, and all the other trade literature. There has been a lot of it out in the past. I trip to your local libraries should be quite fruitful, unless they fail to carry subscriptions to the computing and communications industry trade press. Also, you can find more or less technical information in the ibm systems journal. Cheers - Stef  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Jun 87 23:25:14 EDT Received: from ucbvax.Berkeley.EDU (TCP 1200400116) by MC.LCS.MIT.EDU 19 Jun 87 22:52:46 EDT Received: by ucbvax.Berkeley.EDU (5.57/1.26) id AA06314; Fri, 19 Jun 87 19:36:12 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-pcnet@mc.lcs.mit.edu (info-pcnet@mc.lcs.mit.edu) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 19 Jun 87 19:31:40 GMT From: super.upenn.edu!operations.dccs.upenn.edu!shaffer@RUTGERS.EDU (Earl Shaffer) Organization: University of Pennsylvania Subject: LU6.2 / APPC Message-Id: <1374@super.upenn.edu.upenn.edu> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu We are doing some research into LU6.2's impact on communication systems. Could anyone direct me to LU6.2 or APPC literature? Any help would be appreciated. ============================================================================== Earl Shaffer - University of Pennsylvania - Data Communications Department "Time was invented so that everything wouldn't happen at once." Steven Wright ==============================================================================  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 May 87 21:46:50 EDT Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 9 May 87 21:46:02 EDT Received: from OUACCVMB.BITNET by wiscvm.wisc.edu ; Sat, 09 May 87 20:43:12 CDT Date: Sat, 09 May 87 21:41:53 EDT To: info-pcnet@mc.lcs.mit.edu From: CS527%OUACCVMB.BITNET@wiscvm.wisc.edu Date: 9 May 1987, 21:41:13 EDT From: Mitchell Aidelbaum (614) 592-9841 CS527 at OUACCVMB To: INFO-PCNET@MC.LCS.MIT.EDU at EDU sub: info Can I have info on pc-net. Thank you.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 May 87 18:13:45 EDT Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 8 May 87 18:12:52 EDT Received: from WMMVS.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 17:09:51 CDT DATE: 05/08/87 18:10:36 EST TO: INFO-PCNET@MC.LCS.MIT.EDU FROM: #JFDOBB%WMMVS.BITNET@wiscvm.wisc.edu SUBJECT: info-pcnet Could you please add me to your mailing list for INFO-PCNET? Thank you. John Dobbin  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 May 87 20:52:38 EDT Received: from wiscvm.wisc.edu (TCP 20032201015) by MC.LCS.MIT.EDU 6 May 87 20:51:31 EDT Received: from OUACCVMB.BITNET by wiscvm.wisc.edu ; Wed, 06 May 87 19:49:07 CDT Date: Wed, 06 May 87 20:48:50 EDT To: info-pcnet@mc.lcs.mit.EDU From: ALDSTF04%OUACCVMB.BITNET@wiscvm.wisc.edu Subject: info Date: 6 May 1987, 20:47:46 EDT From: ALDSTF04 at OUACCVMB To: INFO-PCNET at MC.LCS.MIT sub pcnet Aaron Denney  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Feb 87 09:54:19 EST Received: from ORNL-MSR.ARPA (TCP 3200600051) by MC.LCS.MIT.EDU 21 Feb 87 09:54:11 EST Received: by ORNL-MSR.ARPA (5.51/4.9) id AA08132; Sat, 21 Feb 87 09:51:00 EST Date: Sat, 21 Feb 87 09:51:00 EST From: jcm@ORNL-MSR.ARPA (James A. Mullens) Message-Id: <8702211451.AA08132@ORNL-MSR.ARPA> To: JSOTTILE@LOYVAX.BITNET, info-pcnet@mc.lcs.mit.edu Subject: Re: This Distribution List RE: Inquiry about this list and mailing lists in general I don't think this list is active. If there is someone out there who can offer a better report on the status, please do so! If there is someone out there who is interested in the subject of this list, speak up... To find out more about mailing lists in general, talk to someone on your side of the Internet (the Bitnet side). I'm from the ARPAnet side and would not be of much use. (PCNET was intended to be a volunteer effor to create a computer network for personal use. The network referred to is the not the one we are using today, but a unregulated, free-access, world-wide network of personal computers.) jim mullens / jcm@ornl-msr.arpa / oak ridge national laboratory  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Feb 87 21:40:46 EST Received: from MIT-MULTICS.ARPA (TCP 1200000006) by MC.LCS.MIT.EDU 20 Feb 87 21:40:38 EST Received: from LOYVAX(JSOTTILE) by MITVMA (Mailer X1.23) id 6960; Fri, 20 Feb 87 21:32:26 EST Date: Fri, 20 Feb 87 21:29 EDT From: Subject: This Distribution List To: info-pcnet@mc.lcs.mit.edu X-Original-To: info-pcnet@mc.lcs.mit.edu, JSOTTILE I would like to know more about this distribution list and distribution lists in general. Could someone be of any assistance ? - John Sottile Loyola College in Maryland  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Feb 87 00:42:27 EST Received: from RELAY.CS.NET (TCP 1201000005) by MC.LCS.MIT.EDU 10 Feb 87 00:33:04 EST Received: from relay2.cs.net by RELAY.CS.NET id dq12763; 10 Feb 87 0:27 EST Received: from ti-csl by csnet-relay.csnet id bm10686; 9 Feb 87 21:56 EST Received: by tilde id AA24017; Mon, 9 Feb 87 10:49:51 cst Date: Mon, 9 Feb 87 10:49:51 cst From: Joe Ramey To: info-pcnet@MC.LCS.MIT.EDU Subject: change of address Please change info-pcnet-incoming%csl60@ti-csl.csnet to info-pcnet-incoming@ti-csl.csnet Thank you, Joe Ramey TI Computer Science Center  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Feb 87 14:49:51 EST Received: from braggvax.arpa (TCP 1201000046) by MC.LCS.MIT.EDU 5 Feb 87 14:41:34 EST Message-Id: <8702051942.AA27142@braggvax.arpa> To: info-pcnet@mc.lcs.mit.edu Cc: 20s2-s3@braggvax.arpa Subject: HELLO ! Date: Thu, 05 Feb 87 14:42:32 EST From: 20s1-s4@braggvax.arpa Testing, 1- 2- 3! Is anybody out there ? If so, do you have any info on networking that anti-social animal (don't laugh!), the WANG ? We have a tol'able passel of PCs down here, and would like to have an intra-brigade e-mail system. Nice typing at you-- Dave Wegener, 20th Engineers (BAMO)  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 18 NOV 86 19:13:17 EST Received: from WISCVM.WISC.EDU (TCP 30003006015) by MC.LCS.MIT.EDU 18 Nov 86 19:10:14 EST Received: from (JCLS700)CALSTATE.BITNET by WISCVM.WISC.EDU on 11/18/86 at 18:06:56 CST Date: Tue, 18 Nov 1986 16:02 PST From: "A.C. GERMANN" Subject: REQUEST To: "A.C. GERMANN" , PLEASE ADD ME TO MAILING LIST. THANK YOU.  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 24 OCT 86 16:35:19 EDT Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 24 Oct 86 16:33:49 EDT Received: from (BUSU)UOFMCC.BITNET by WISCVM.WISC.EDU on 10/24/86 at 15:33:24 CDT Date: Fri, 24 Oct 86 15:25 CDT To: info-pcnet@mc.lcs.mit.edu From: BUSU%UOFMCC.BITNET@WISCVM.WISC.EDU Subject: PCNET forum inclusion Please add my id to the forum on the PCNET work. Any info as to what would be the best way to become familiar with the discussions, files, etc would be a help. Thanks in advance. Dan Keizer BITNET: BUSU@UOFMCC  Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU via Chaosnet; 15 SEP 86 10:22:17 EDT Received: from WISCVM.WISC.EDU by MC.LCS.MIT.EDU 15 Sep 86 10:18:20 EDT Received: from (MAILER)RYERSON.BITNET by WISCVM.WISC.EDU on 09/15/86 at 09:16:57 CDT Received: by RYERSON (Mailer X1.23) id 2994; Mon, 15 Sep 86 10:12:45 EST Date: Mon, 15 Sep 1986 10:12:11 EST From: Nash Dhanani Subject: Subscription. To: INFO-PCNET Please add my name to your mailing list for INFO-PCNET. Thank you.  Received: from C.CS.CMU.EDU by MC.LCS.MIT.EDU 24 Mar 86 22:18:30 EST Received: ID ; Mon 24 Mar 86 22:15:55-EST Date: Mon 24 Mar 86 22:15:47-EST From: "Ralph W. Hyre, Jr." Subject: Remote access protocol proposal (v 0.0) To: remote-access-people: ; cc: protocols@RED.RUTGERS.EDU, info-pcnet@MC.LCS.MIT.EDU Work-phone: (412) CMU-BUGS Message-ID: <12193401657.26.RALPHW@C.CS.CMU.EDU> This (preliminary) proposal is based on ideas in the Dec '85 BYTE Article 'Local power in a remote link', by Chuck McManis. It is also influenced by research I was involved with at MIT (the Boston Community Information System Project) on query protocols for remote databases. If you are interested in working on this problem please respond and I will add you to the mailing list. I'd also appreciate the names and addresses of people and companies (not necessarily reachable by ths network - I'm willing to send small amounts of snail mail) involved in software development for remote database access. (I'm sure there are some big interested here.) I'm interested in any sort of system that involves database access, although the problem that motivated me to do this was the general poor quality of user interfaces in computer-based messaging systems. This protocol lets will allow the user to develop any interface suitable to his or her needs. If a remote procedure call model of communications is considered then I propose the following procedures. These would be implemented in the remote (server) program and called by the local (client) program. Conventions on encoding procedural requests and data objects (ints, strings) can be decided later. Semantics are also undefined, to be developed later. Copyright (c) 1986 Ralph W. Hyre, Jr. [This interface is placed in the public domain, although I'd prefer that nobody go farther than implementing the procedure call interface to their database system in these early stages, especially until there is agreement on the communications protocols. Otherwise nobody will benefit. Feel free to distribute the document, but please send comments back to me. Any particular implementation of this protocol is copyrightable by the author, of course] {Very preliminary data type definitions - please comment} TYPE article_id, conference_id, status, user_id, password = integer TYPE date = record [...] TYPE article_ids = list of article_id TYPE conference_ids = list of conference_id TYPE article = record[author, subject, text : string, creation_date : date] TYPE conference = list of articles Authenticate (user_id, password) returns (status) {Might be required in both directions (client <-> server) for} {two-way authentication} Retrieve_article (article_id) returns (article) Submit_article (article) returns (status, article_id) Delete_article (article_id) returns (status, article_id) {conference is synonomous with database or message base in this context} Scan_conferences () returns (conference_ids) Scan (conference) returns (article_ids) Scan_since_date (conference, date) returns (article_ids) Scan_with_text (conference, string) returns (article_ids) {Keyword search} Scan_general (conference, scan_procedure) get_Subject (article_id) returns (string) get_Author (article_id) returns (string) get_Date (article_id) returns (date) get_Summary (article_id) returns (string) {First line of text} get_Description (article_id) returns (string) {Pieces of the above 4} Thank you for your interest and support. - Ralph -------  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 22 Mar 86 00:16:48 EST Date: 1986 March 21 19:59:27 PST (=GMT-8hr) From: Robert Elton Maas To:INFO-PCNET@MIT-MC Subject:anyone have access to SRI machines and willing to FTP files out? I have finally located the file where I saved the directory listing of PCNET files (mostly C language source code) on the Fylstra directory on some SRI machine (the names have been juggled so I don't currently know the name of the machine, formerly SRI-UNIX or SRI-AI). Is there anyone with an account on that machine who is willing to FTP all the files out to a more accessible machine? (Nobody on the outside has succeeded at gaining FTP access to the files.) I would like to make them accessible in machine readable form to the several people who have recently expressed a desire to continue PCNET work using the C language, and I would like to include the files in my next batch of PCNET computer-output micro-fiche. If I can't find anyone willing&able to FTP those files, I'll have to manually retype them from listings I have from 1980 (before they ever went to SRI), in which case we'll lose any work that Fylstra did on the files at SRI.  Received: from SU-AI.ARPA by MC.LCS.MIT.EDU 8 Jan 86 06:29:26 EST X-Sent: to SU-AI.ARPA by IMSSS.FRONSTAD.EDU via ETHERNET with PUPFTP; 1986-Jan-08 03:27:09 PST (=GMT-8hr) X-Mailer: EMACS -> PSL (FORMAT+SEND-ALL) -> PUPFTP Date: 1986 January 07 23:58:12 PST (=GMT-8hr) Message-id: SU-IMSSS.REM.A132546120415.G0353 From: Robert Elton Maas To:INFO-PCNET@MIT-MC CC:PROTOCOLS@RUTGERS Subject:PCNET files online at SIMTEL20 Sender: REM%IMSSS@SU-SCORE.ARPA (for undeliverable-mail notifications) Reply-to: REM%IMSSS@SU-SCORE.ARPA (temporary until IMSSS.STANFORD.EDU registered) | From: "Frank J. Wancho" | The PCNET files are now in place here in PD:. When I was in the process of pulling all the PCNET files I could identify (I missed a few but I got a vast majority) from backup tapes to make Computer Output Microfiche, I also made the original files available to Frank Wancho for copying to SIMTEL20, where they are available for FTP over the TCP/IP portion of the ARPA-Internet. We don't yet have access to any of the C-language source files that Dave Fylstra claims to have online at SRI-UNIX (nobody has volunteered instructions for interacting with their FTP server), but virtually every other important PCNET-related file is online at SIMTEL20 and on microfiche. Inquire with WANCHO@SIMTEL20.ARPA for directory of files at SIMTEL20 and procedures for FTP access. Inquire with me, i.e. REM%IMSSS@SU-SCORE.ARPA, for directory&descriptions of files on microfiche, or for information about ordering a set of fiche. Partial information about FTP access is included below, which may be sufficient and thus make messages to Frank Wancho unnecessary. | From: "Frank J. Wancho" | ... the files you sent me that comprised those you converted to | fiche. They are in place, ... in PD: on SIMTEL20. | People may FTP them using login ANONYMOUS and any non-null password.  Received: from battenkill by MIT-MC.ARPA 16 Nov 85 19:48:41 EST From: <@ge-crd.arpa:montnaro@battenkill> Subject: Spurious messages To: Received: by battenkill.steinmetz.uucp (2.0/3.14) id AA00496; Sat, 16 Nov 85 19:47:22 est Date: Sat, 16 Nov 85 19:47:22 est From: montnaro@battenkill (Montanaro) Return-Path: Message-Id: <8511170047.AA00496@battenkill.steinmetz.uucp> To: @csbvax:info-pcnet@mit-mc.arpa Subject: Spurious messages Dear info-pcnet manager: I received two messages today that apparently were addressed to info-pcnet, one from montgmry@deway.udel.EDU, the other from postel@usc-isib.arpa. I do not wish to receive info-pcnet. The only net groups that I receive directly are Sun-Spots-Digest from Rice University and the two gnu-emacs related boards (one from MIT-PREP, perhaps a crossed wire?). If my name and e-mail address got on your mailing list by mistake, please remove it. Thanks, Skip Montanaro montanaro@ge-crd.arpa  Received: from USC-ISIB.ARPA by MIT-MC.ARPA 16 Nov 85 17:10:51 EST Date: 16 Nov 1985 14:06:05 PST From: POSTEL@USC-ISIB.ARPA Subject: LAN Management To: info-pcnet@MIT-MC.ARPA Doug Montgomery I would take it as a goal of LAN design that no management would be required. This goal is not always met, so you may find some references. --jon. -------  Received: from Dewey.UDEL.EDU by MIT-MC.ARPA 16 Nov 85 16:45:25 EST Date: Sat, 16 Nov 85 16:38:13 EST From: Doug Montgomery To: info-pcnet@mit-mc.ARPA Subject: LAN management references I am interested in gathering information on the management of LANs. In particular, I am interested in the automated management/control of LANs. Information/references/comments pertaining to: * LAN management goals and philosophies. * LAN management architectures. * LAN management protocols. * LAN management applications. * management of LANs based upon IEEE 802 MAC-sublayer standards. * potential application of AI techniques to the automated management of LANs. would be greatly appreciated. If there is interest I will summarize responses. Network Addresses: ARPA: montgmry@udel-dewey CSNET: montgmry%udel-dewey@csnet-relay UUCP: ...!harvard!montgmry@udel-dewey  Received: from SU-SCORE.ARPA by MIT-MC.ARPA 28 Oct 85 17:20:38 EST Received: from IMSSS by Score with Pup; Mon 28 Oct 85 13:32:10-PST Date: 28 Oct 1985 1328-PST From: Rem@IMSSS Subject: Last call for PCNET fiche To: INFO-PCNET%MIT-MC@SCORE The Computer-Output-Microfiche of PCNET files has been made and looks good. On twelve little pieces of plastic are virtually all PCNET-related files that ever existed, from the founding days in 1977 up to the latest MIT-MC files as of this year when I FTP'd the files to IMSSS to make the fiche. My cost has been $3.50/original (total $42) plus $.25/copy ($3 per copy set), i.e. $(42 + 3*n) where n is the number of copy sets made. I'm still looking for other people to share costs, somebody who would rather have this compact memory of PCNET instead of a bulky incomplete set of paper listings or a lot of disk space tied up permanently. Reply to REM@MIT-MC.ARPA or REM%IMSSS@SCORE Hurry, I need to know in a day or so how many copies to order. -------  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 17 Oct 85 11:53:28 EDT Received: from localhost by .Louie.UDEL.EDU id a027671; 17 Oct 85 11:56 EDT To: info-pcnet@louie.udel.EDU Subject: info on commercially available LANs Date: 17 Oct 85 11:56:38 EDT (Thu) From: marwaha@louie.udel.EDU I am looking for information about commercially available LAN products. This is for a survey report on commercially available LAN systems and how they map onto the various network standards proposed by the various committees. If any body has any pointers to manufacturers/developers of LAN products or knows where I can get such information (e.g. a LAN manufacturers directory) I would be happy to know about it. Thanx. Samar Marwaha 214 Smith Hall University of Delaware Newark DE 19716 marwaha@udel-dewey  Received: from Louie.UDEL.EDU by MIT-MC.ARPA 17 Sep 85 15:01:15 EDT Received: from dewey.udel.edu by .Louie.UDEL.EDU id a027717; 17 Sep 85 14:47 EDT Received: from vogon by .Dewey.UDEL.EDU id ah15986; 17 Sep 85 14:47 EDT Received: from UDel-Dewey.ARPA by Dewey.UDel.EDU id a009865 ;17 Sep 85 13:00 EDT Received: by vax3.acs.udel.edu (4.12/4.7) id AA06435; Tue, 17 Sep 85 13:00:44 edt Date: Tue, 17 Sep 85 13:00:44 edt From: ANDERSEN Message-Id: <8509171700.AA06435@vax3.acs.udel.edu> To: info-pcnet@louie.udel.EDU Subject: REQUEST for inclusion Please add my name to the distribution for Info-PCNet. Thanks. sigurd@vax3  Received: from MCC.ARPA by MIT-MC.ARPA 14 Sep 85 22:10:37 EDT Date: Sat 14 Sep 85 21:11:04-CDT From: Mayank Prakash Subject: Please add me to the list To: info-pcnet@MIT-MC.ARPA Thanx. -mayank. -------  Received: from SU-SCORE.ARPA by MIT-MC.ARPA 21 Aug 85 17:52:25 EDT Received: from IMSSS by Score with Pup; Wed 21 Aug 85 14:50:00-PDT Date: 21 Aug 1985 1451-PDT From: Rem@IMSSS Subject: PCNET archives on microfiche soon To: INFO-PCNET%MIT-MC@SCORE I will soon be creating Computer-Output-Microfiche of all the PCNET files I can find. This will include (1) all the major files online at MIT-MC a few months ago when I made preliminary conversion of them, (2) all the PCNET-related files I had on the Datacomputer at the beginning of 1980, (3) any random PCNET-related files that I backed up at SU-AI from 1980 to 1984, minus a few files that were lost due to unreadable SU-AI tapes. Group (1) is a little more than five full fiche. Groups (2) and (3) I haven't yet made preliminary conversion so don't know how much. Each fiche costs me $3.50 for the master plus $0.25 for each copy. If any of you might want your copy of this set of fiche, I'll charge you the $0.25 per fiche-copy plus your share of the $3.50 original plus postage. (I.e. I make no profit from this.) Anybody with microfiche readers interested in getting the fiche set? Contact me by net mail now and I'll let you know more info as it develops. -------  Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 16 MAR 85 23:38:32 EST Received: from UCB-VAX.ARPA by SU-SCORE.ARPA with TCP; Sat 16 Mar 85 20:39:02-PST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.42) id AA01030; Sat, 16 Mar 85 20:31:58 pst Received: by ucbjade.CC.Berkeley.ARPA (4.19/4.34.1) id AA08482; Sat, 16 Mar 85 20:34:12 pst Date: Sat, 16 Mar 85 20:34:12 pst From: calengr%ucbjade.CC@Berkeley (Suresh K. Sastry) Message-Id: <8503170434.AA08482@ucbjade.CC.Berkeley.ARPA> To: info-apple@brl-tgr Subject: Mailing List. Please add me to your mailing list. Thank you in advance. Suresh K. Sastry (calengr@ucbjade)  Received: from csnet-relay by MIT-MC.ARPA; 16 MAR 85 20:57:34 EST Received: from vpi by csnet-relay.csnet id ae02637; 16 Mar 85 20:55 EST Date: Sat, 16 Mar 85 15:55 EST From: Ed Fox To: info-pcnet@mit-mc.ARPA cc: fox%vpi.csnet@csnet-relay.arpa Subject: Please drop me from the list Please drop me, listed as foxea%vpivm1.bitnet@berkeley from your list. Many thanks, Ed Fox (postmaster%vpi@csnet-relay.arpa)  Received: from IMSSS by Score with Pup; Mon 4 Feb 85 17:12:23-PST Date: 4 Feb 1985 1711-PST From: Rem@IMSSS Subject: Forwarding this mis-addressed mail for your handling To: INFO-PCNET%MIT-MC@SCORE 4-Feb-85 15:39:32-PST,741;000000000001 Mail-from: SU-NET host Score rcvd at 4-Feb-85 1539-PST Received: from MIT-MC by SU-SCORE.ARPA with TCP; Mon 4 Feb 85 15:23:53-PST Date: 4 Feb 1985 16:42:27 CST Subject: Request for Inclusion From: DSDC-SDT2@GUNTER-ADAM.ARPA To: REM@MIT-MC.ARPA cc: DSDC-SDT2@GUNTER-ADAM.ARPA Being new to the ARPANET, not to data processing, and coming across the INFO-PCNET@MIT-MC, I would like to be included in the mailing list for this SIG. Am trying to write and define an American Red Cross Disaster Services network in my spare time (not much lately), and from reading the info on this SIG, feel it would benefit me, and maybe me benefit the SIG. Would appreciate being included in the "list". Many thanks... Walt Livingston ------- -------  Received: from umass-cs by csnet-relay.csnet id al00018; 11 Dec 84 1:25 EST Date: Mon, 10 Dec 84 16:17 EST From: Steven Gutfreund To: info-nets%mit-oz@mit-mc.ARPA cc: info-pcnet%mit-mc%umass-cs.csnet@csnet-relay.arpa, info-apple@brl-tgr.ARPA, info-micro@brl-vgr.ARPA Subject: mini electronic mail net Could someone give me some advice: I have a person who wants to set an electronic mail delivery system between two Apple machines. The primary consideration is minimization of cost. Currently he is doing this by using MCI mails 800 number and leaving scratch copies of letters in a shared account. This option is soon going to be unfeasable. Other options such as SOURCE are deemed to expensive. USEnet conections (at least as I understand them) are probably out. (or is there an equivelent for apples? They users are currently in Springfield Mass and Providence RI, but this will soon expand to about 40 cities around the country. The question then is: What sort of electronci mail delivery system do you see as most feasable (given their frugality) and what sort of packages are currently available for the Apple-IIc for doing this? (suppliers and price please!) The best I can suggest is a Terminal Emulator package that would force mail up at off hourse to the Source. But I don't even know who sells this sort of package. But maybe some of the micro people have a better solution than this! Reply directly to me (I am not on this list): Steven Gutfreund gutfreund%umass@csnet-relay.arpa  Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16) id AA13795; Thu, 8 Nov 84 10:19:43 pst Message-Id: <8411081819.AA13795@sri-spam.ARPA> Date: 08 Nov 84 10:19:41 PST (Thu) To: arpanet-bboards-request@mit-mc, sun-spots-request@rice, editor-people@su-score, info-pcnet@mit-mc, works-request@rutgers, aviation-request@mit-ai, poli-sci-request@rutgers Subject: Request to be added to list. From: "Reginald R. Hutcherson( Reggie or hutch will do )" hello, if at all possible, could you add me to your list. -- hutch --------  Date: 26 Oct 1984 9:37:06 EDT (Friday) From: Marshall Abrams Subject: Expert Systems Symposium To: microgroups:@mitre Cc: karna@mitre, abrams@mitre I am helping to organize a Symposium on Expert Systems in the Federal Government. In addition to papers, I am looking for people to serve on the program committee and the conference committee, and to serve as reviewers and session chairmen. The openings on the conference committee include local arrangements, publicity, and tutorials. Please contact me or the program chairman (karma @ mitre) with questions and suggestions. The call for papers is available on request. Marshall Abrams  Date: 15 Oct 1984 1527-EST From: CHARLIE at WPAFB-INFO1 Subject: Please remove my name from your mailing list. To: INTO-CPM at AMSAA Cc: INFO-MICRO@BRL,INFO-PCNET@MIT-MC Reply-To: CHARLIE at WPAFB-INFO1 ------  Date: 10 Oct 1984 13:50 MDT (Wed) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@AMSAA, INFO-MICRO@BRL Cc: INFO-PCNET@MIT-MC Subject: FIDO files available The files described below are now available on SIMTEL20 in MICRO: using ANONYMOUS FTP and any non-null password. The standard CRC list follows the announcement. The files come through the courtesy of Bernie Eiben (EIBEN@DEC-MARLBORO). FIDO, written by Tom Jennings in Lattice C (author keeps sources for control-reasons) supports RBBS-operation on the following mini-systems: DEC-Rainbow , IBM-PC and PC-Jr , Otrona Attache and Compaq MS-DOS V 2.0 or higher required, hard-disk desirable, plus Modem (auto-dial for support of FIDO-NET. FIDO supports "typical" BBS operation plus inter-FIDO mail using telephone access. See NODELIST.BBS for current list of FIDO's - also see article in October issue of BYTE and/or DOC-files. FIDO currently supports all dialects of MODEM and will shortly include support for KERMIT protocol. Short synopsys of files (all in 8-bit format): FIDO.DOC,FIDONET.DOC and INSTALL.DOC - Wordstar based documentation DECMINI.* - Rainbow's MINITEL (MODEM-like communication package) BBS-FILS.LBR - Library of short BBS-files FIDOHLP.LBR - Library of short HELP-files FIDODEC.EXE - Rainbow based FIDO system (V 9H) FIDOXDEC.EXE - Rainbow based FIDO system (V 9L) FIDOXIBM.EXE - IBM-PC based FIDO system (V 9L) RENUM.EXE - Utility for MAIL-handling SYSOP.EXE - SYSOP utility TIMELOG.EXE - SYSOP utility V9K.DOC - doc-addendums FIDOLIST.* - user-written NETWORK-Node handler Nodelist.BBS - list of current FIDO systems. Filename Type Bytes CRC Directory MICRO: BBS-FILS.LBR.1 BINARY 11264 F5A7H DECMINI.DQC.1 BINARY 22528 51DFH DECMINI.EXE.1 BINARY 37376 C6A0H FIDO.DOC.1 BINARY 65681 08C5H FIDO.TXT.2 ASCII 1267 6D6EH FIDODEC.EXE.1 BINARY 83968 F60EH FIDOHLP.LBR.1 BINARY 7552 54BAH FIDOLIST.DOC.1 BINARY 1217 C3A0H FIDOLIST.EXE.1 BINARY 17024 3492H FIDONET.DOC.2 ASCII 50666 EF77H FIDOXDEC.EXE.1 BINARY 86016 C9EDH FIDOXIBM.EXE.1 BINARY 65536 53BEH INSTALL.DOC.1 BINARY 70431 BFEDH RENUM.EXE.1 BINARY 26240 348EH SYSOP.EXE.1 BINARY 20992 C0F7H TIMELOG.EXE.1 BINARY 9216 1892H V9K.DOC.1 BINARY 3820 F488H  Received: from vortex.UUCP by rand-unix.ARPA; Thu, 4 Oct 84 12:33:12 pdt Date: Thu, 4-Oct-84 12:10:53 PDT From: Lauren Weinstein Subject: MSDOS UUCP Message-Id: <8410041210.193.2.VT3.4@vortex.UUCP> To: RICK@MIT-MC Cc: BUDD@MC, INFO-PCNET@MC In-Reply-To: Your message of 4 October 1984 02:40-EDT Thanks for the info. Well, MSDOS UUCP/mail/netnews is now up and running, and I have test sites already on the UUCP net happily receiving mailing lists and replying and other typical kinds of things. The mail program generates 822 compatible mail. It handles incoming and outgoing calls automatically (including automatic scheduling of outgoing calls via "crontab"), and can receive and send Usenet netnews as a special case of mail. (I don't currently try to forward netnews due to disk space limitations, but I'll probably come up with a program (running from my "crontab") to do that sometime down the line -- for now you can participate fully with netnews if you have an existing conventional netnews site to feed you). As for UUCP mail -- all the typical features including foo!bar!mock multi-hop mail forwarding is fully supported, including aliasing and distribution lists. The mail program lets you edit your mail with your favorite editor if you choose, of course. For people who are only one hop away from an ARPA/MILNET gateway machine, I have special features to make Internet mail very natural to send (i.e. direct use of @ signs and headers that will work properly even in our current non-domain environment). Everything is there for both interfacing to the larger UUCP network or for complex local PC networks if desired. Anyway, it's pretty neat, though it was a lot of work. I don't have reasonable docs yet, but I'm taking names of "brave soles" who want to buy it using a long READ.ME type file/doc for installation -- ideally people who have some experience with UUCP. After much consideration of the the numerous factors involved, I'm currently planning to charge $335 for the full package of everything. This seems to be in line with other telecommunications packages that have far less useful functionality... in my opinion, anyway. The big advantage of this package, of course, is that you can instantly tie into the established networks and read your mail at home with local speeds. --Lauren--  Date: 4 October 1984 02:40-EDT From: Richard P. Wilkes Subject: FIDO To: vortex!lauren @ RAND-UNIX cc: BUDD @ MIT-MC, INFO-PCNET @ MIT-MC In-reply-to: Msg of Wed 3-Oct-84 10:39:54 PDT from Lauren Weinstein Yes, it is QUITE crude. Basically, it uses a modified XMODEM and simply grabs messages and "attached files". Calling is only one direction so that the CALLER has to pay for the info it wants to send. Yuck. Tom Jennings (the creator) is a good hacker. However, he suffers from the all-too-common blindness of his own ambition. He wanted to get a system working, and he HAS. But in the process, he ignored several analyses from people like myself who felt he was ignoring all the current methods of mail / file transfer. I, too, am much more interested in am MSDOS based uucp/mail/netnews program than running fidomail. I receive 50+ messages per day here; a fido host may get 5. Which is more useful? -Rick at MIT-MC Fido #2 remote sysop P.S. BTW, what is the status of that project, Lauren?  Date: Thu 4 Oct 84 01:05:40-EDT From: Ralph W. Hyre Jr. Subject: Re: Maccommunications To: decvax!genrad!enmasse!guy@UCB-VAX.ARPA cc: info-pcnet@MIT-MC.ARPA In-Reply-To: Message from "decvax!genrad!enmasse!guy@Berkeley" of Thu 4 Oct 84 00:57:35-EDT Well, there's an XMODEM implementation with MacTerminal. There's also KERMIT, but I haven't been able to get that to work very well with our Vax. Mark Sherman at Dartmouth has ported pieces of the PCIP (TCP/IP for the IBM PC) packaged developed at MIT to the Mac. It runs over the Applebus, which might also support some other sort of low-level protocols. - Ralph Hyre -------  Received: by UCB-VAX.ARPA (4.24/4.31) id AA13927; Wed, 3 Oct 84 21:54:28 pdt From: decvax!genrad!enmasse!guy@Berkeley Return-Path: Received: by decvax.UUCP (4.12/1.0) id AA07397; Thu, 4 Oct 84 00:06:09 edt Received: by genrad.UUCP (4.12/4.7) id AA21641; Wed, 3 Oct 84 23:33:36 edt Date: Wed, 3 Oct 84 23:33:36 edt Message-Id: <8410040333.AA21641@genrad.UUCP> To: info-pcnet@mit-mc.ARPA Subject: Maccommunications Does the Apple Mac support any kind of file transfer or networking protocol? --Guy Hillyer decvax!genrad!enmasse!guy@ucbvax.UUCP  Date: 3 Oct 1984 16:42-PDT Sender: BILLW@SRI-KL Subject: other PCNet like protocols From: William "Chops" Westfield To: info-pcnet@MC Message-ID: <[SRI-KL] 3-Oct-84 16:42:15.BILLW> I think that the people on this list would be interested in reading SRI-NIC::RFC914.TXT on "thinwire protocols". It discussesa number of methods of reducing the overhead associated with a TCP packet so as to make it more practical to transmit TCP/IP over low speed lines... TCP/IP would provide many of the capabilites of the low level PCNet protocols, and has thhe added advantage of being a standard... Bill Westfield  Received: from vortex.UUCP by rand-unix.ARPA; Wed, 3 Oct 84 11:29:11 pdt Date: Wed, 3-Oct-84 10:39:54 PDT From: Lauren Weinstein Subject: Re: FIDO Message-Id: <8410031039.147.1.VT3.4@vortex.UUCP> To: BUDD@MIT-MC Cc: INFO-PCNET@MC In-Reply-To: Your message of 3 October 1984 06:39-EDT I haven't seen any details, but apparently it is pretty crude, judging from the fact that I'm getting lots of inquiries about my MSDOS UUCP/mail/ netnews package from people that already have it... --Lauren--  Date: 3 October 1984 06:39-EDT From: Philip Budne Subject: FIDO To: INFO-PCNET @ MIT-MC What do people know about "FIDO"? Its supposed to run on an XT, and provide mail service as well as 'normal' BBS access. It looks like it provides only one way connections, which are secure, but require more calls; and provides 2 layer routing (ie; each "area" can have a router that will make long distance calls). I'm not in the market, but I thought it would be a good topic for this list. My impression is that FIDO is becomming quite popular for PC-like systems. I'm not sure where the best place to get the documentation is, but I have some on a system at work...  Date: 1 Oct 1984 1124-EST From: CHARLIE at WPAFB-INFO1 Subject: Reguest that my name be deleted from your mailing list. To: INFO-PCNET at MIT-MC.ARPA Cc: CHARLIE@ARI-HQ! Reply-To: CHARLIE at WPAFB-INFO1 ------  Date: 29 September 1984 11:15-EDT From: Christopher R. Eliot To: INFO-PCNET @ MIT-MC Request my name be deleted from the mailing list. The name "ELIOT@MIT-MC" may also be on the list, which no longer exists, and comes to me by accident.  Date: Fri, 28 Sep 84 15:15:03 EDT From: Edmund S. Kijak (MISD-PMD) To: info-pcnet@Mit-Mc.ARPA Request my name be added to mailing list.  Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34) id AA01203; Thu, 6 Sep 84 13:58:54 pdt Message-Id: <8409062058.AA01203@decwrl.ARPA> Date: Thursday, 6 Sep 1984 14:05:40-PDT From: waters%viking.DEC@decwrl.ARPA (Lester Waters) To: info-pcnet@mit-mc.ARPA Subject: Add to mailing list please I would like to be added to your INFO-PCNET digest mailing list. Thank you. - Lester Waters - Rainbow PC Development Group Digital Equipment Corporation WATERS%viking.DEC@DECWRL.ARPA  Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.33) id AA10821; Sun, 12 Aug 84 11:36:28 pdt Message-Id: <8408121836.AA10821@decwrl.ARPA> Date: Sunday, 12 Aug 1984 10:36:51-PDT From: muslin%ny1mm.DEC@decwrl.ARPA To: info-pcnet@mit-mc, phil-sci@mit-mc Subject: Mailing List Please change my address from MUSLIN@DEC-MARLBOR to decwrl!rhea!ny1mm!muslin@Shasta If I am not on the mailing list currently, please place me on it. Thanks.  Date: 26 Jul 1984 1456-PDT From: Waiming Mok Subject: Request for info on MIT LEP (Local Editor Protocol) report To: Cc: MAILER!EDITOR-PEOPLE@SU-SCORE Reply-To: Could anyone tell me more about the MIT Local Editor Protocol (LEP) report? Specifically, the publication date, full title, author, ..., maybe how I can obtain a copy. Please send response to: wmm@ACC Much thanks in advance, Waiming Mok ------  Date: 21 June 1984 04:49-EDT From: Robert Elton Maas Subject: new maintainer for mailing lists To: INFO-PCNET @ MIT-MC MAP at MIT-MC has volunteered to take over maintenance of the various PCNET mailing lists. This change should be transparent except that service will be faster since I have been too busy lately to respond to requests immediately. Continue to use INFO-PCNET-REQUEST@MIT-MC.ARPA for requests related to INFO-PCNET. I'll still be available to answer technical questions regarding protocol or implementation methods, should any arise.  Date: Sun, 13 May 84 18:31:58 BST From: Hans-Juergen Kugler To: human-nets@rutgers.arpa, info-graphics@utexas-20.arpa, info-pcnet@mit-mc.arpa, info-printers@mit-mc.arpa, info-terms@mit-mc.arpa, info-vax@sri-csl.arpa, laser-lovers@washington.arpa, texhax@su-ai.arpa, unix-tex@washington.arpa, unix-wizards@brl.arpa cc: hjkugler@ucl-cs.arpa Subject: Protext I Conf. on Text Processing Systems PROTEXT I The First International Conference, Exhibition and Workshop on Text Processing Systems, Dublin, Ireland, 22-26 October 1984, for people from business, industry and academia interested in computer-aided text processing systems. Keynote speakers include J.Carmichael (ICL), B.Kernighan (Bell Labs), P.MacKay (Seattle), B.Reid (Stanford), V.Quint (Grenoble), I.Wieselman (Dataproducts) plus speakers possibly from Hewlett-Packard, Wang, Toshiba (Japan) and University of Tokyo (Dept.of Information Sciences). Emphasis will be placed on the following areas: Computer-aided generation of generalised copy (graphics, mathematical, non-English language); computer-generated book-quality masters for print production; interactive editing systems; interactive document composition; computer-aided typography; and human factors as well as current research and future developments in hardware and software (including laser printers). The workshop will be concerned with state-of-the-art computer-aided text processing systems, with live demonstrations of actual systems and their use (including SCRIBE, TEX, TROFF and EDIMATH). Companies marketing related hardware and software will exhibit during the Workshop and Conference and it is expected that several new products will be announced at this exhibition. Contact : PROTEXT I Organising Committee c/o Boole Press Limited P.O.Box 5 51 Sandycove Road Dun Laoghaire Co. Dublin IRELAND telephone : +353-1-808025 telex : 30547 SHCN EI (ref: BOOLE)  Date: Tue 3 Apr 84 13:11:14-EST From: Willie Subject: Re: copy of protocall To: info-pcnet@MIT-MC.ARPA In-Reply-To: Message from "Davids@HIS-PHOENIX-MULTICS.ARPA" of Fri 30 Mar 84 09:30:38-EST Me too! Where can I lay my hands on a copy? Thanks a lot. --- Wmt@XX ("Little" Willie) -------  Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 30-Mar-1984 09:19:12-est Date: Fri, 30 Mar 84 07:16 MST From: Davids@HIS-PHOENIX-MULTICS.ARPA Subject: copy of protocall To: Info-PCNet@MIT-MC.ARPA Message-ID: <840330141655.228215@HIS-PHOENIX-MULTICS.ARPA> Where can I get a copy of the protocall (Can't talk about it if I don't know what it says).  Date: 21-Mar-84 14:06 PST From: Rich Zellich Subject: Re: Lisa/Macintosh Mailing List To: GARY R. PORTER Cc: info-apple@BRL.ARPA, info-pcnet@MIT-MC.ARPA Cc: gporTER@USC-ISI.ARPA Message-ID: <[OFFICE-3.ARPA]GVT-RICH-4C49I> In-reply-to: EXT-CDR-4C3XG Send your net address to INFO-MAC-REQUEST@SUMEX-AIM.ARPA to get added to the Info-Mac mailing-list. This is a direct-redistribution mailing list, not a digest (yet). For more information, see the Info-Mac entry in SRI-NIC file INTEREST-GROUPS.TXT - SRI-NIC allows FTP using ANONYMOUS login with password ARPA. Cheers, Rich  Date: 21 Mar 1984 1009-PST Subject: Lisa/Macintosh Mailing List From: GARY R. PORTER To: info-apple@BRL.ARPA, info-pcnet@MIT-MC.ARPA cc: gporTER@USC-ISI.ARPA Sender: CDR Gary R. Porter Address: Code 55PT, NPS Monterey, CA 93940 Phone: 408-646-2493 or AV 878-2493 Anyone know of a Lisa or Macintosh mailing list? Anyone have some facts on the mythical big discount Apple is offering to Universities? I'm not on this mailing list so please send responses directly to my mailbox. Thanks.....Gary -------  Date: 8 March 1984 03:28-EST From: Robert Elton Maas Subject: PCNET and name domains To: INFO-PCNET @ MIT-MC Naming-authority domains are coming in a few months. I propose that PCNET change its form of node IDs to be compatible. I think the only change needed will be to avoid periods in the middle of node IDs, which can be accomplished by using apostrophe instead of decimal point and using degrees&minutes instead of degres&hundredths accordingly. Then if we have a nameserver on the ARPA-internet which knows at least one reliable PCNET gateway in each geographical area then suddenly all of PCNET becomes accessible in a clean way from the internet (vice versa is already easy since we can control that). Other than remarks about how this is moot because PCNET is already dead (some think not), any rebuttal? Under this proposal, my personal return address (if this was mailed from my Altair) would be: FROM:REM@37'28N122'08W415-323-0720.PCNET while on the Internet side of a gateway (compatible with naming domains established by internet RFC) FROM:37'28N122'08W415-323-0720,REM while on the PCNET side of a gateway (left-to-right decoding ease for small machines, due to left-to-right ordering of high-to-low-order data and fixed-size fixed-location fields up thru phone number)  Date: 26 Feb 1984 1755-PST From: MONGE.NSF@USC-ECL.ARPA Subject: Mailing list To: info-pcnet@MIT-MC.ARPA Please add me to your mailing list. CONTRACTOR@USC-ECL -------  Date: Tue, 10 Jan 1984 03:56 EST Message-ID: To: Bruce Nemnich Cc: decwrl!rhea!atfab!wyman@SU-SHASTA.ARPA, protocols@RUTGERS.ARPA, Elmo%MIT-OZ@MIT-MC.ARPA, Info-PCNET@MIT-MC, REM@MIT-MC From: "Eliot R. Moore" Reply-to: Elmo%Mit-Oz@Mit-MC Sender: Elmo%MIT-OZ@MIT-MC.ARPA Subject: KERPAC -- An answer to the MAIL need??? In-reply-to: Msg of 8 Jan 1984 22:17-EST from Bruce Nemnich Date: Sunday, 8 January 1984 22:17-EST From: Bruce Nemnich To: decwrl!rhea!atfab!wyman at SU-SHASTA.ARPA cc: info-kermit at COLUMBIA-20.ARPA, protocols at RUTGERS.ARPA Re: KERPAC -- An answer to the MAIL need??? Yes, there is a better protocol already designed called PCNET. The name has nothing to do with a product of the same name sold by Orchid Technologies; the people working on the PCNET I am writing of were using the name long before Orchid. > The problem is that little work has been done recently on PCNET. The > protocol was originally designed about 5 years ago (there have been > changes since), but there is only one full implementation I know of (by > Robert Elton Mass on MIT-MC). There are many implementations partially > completed. I think the above paragraph hits the nail squarely on its head. Yes, PCNET is a better conception, and a better protocol, but it is still but semi-defined and has yet to be implemented. Stick with KERMIT, where there is a significant interest and work being done. Regards, Elmo  Date: 30 Dec 1983 13:34:41 EST (Friday) From: Marshall Abrams Subject: Call for Papers To: microgroups:@mitre Cc: abrams@mitre The IEEE Computer Society has issued a call for papers which I think would be of special interest to those of us involved with small computers. The conference title is The Small Computer (R)Evolution. The call for papers sys that the program will encompass a wide scope of applications: as tools for managers, professionals, non-professionals, students, home-users, hobbyists and as embedded elements of other systems. The program will include tutorials, panels, demonstartions, and technical papers." The schedule includes:Jan 3 1984 Proposals for tutorials due (these are all-day tutorials of professional quality with the speaker being paid) April 2 Paper, session, and panel proposals due April 16 Demonstration descriptions due The papers (due April; 2) are to be submitted in three copies and should range from 1000 to 5000 words. All mail is addressed to: Small Computer (R)Evolution c/o IEEE Computer Society P. O. Box 639 Silver Spring, MD 20901 I will be happy to supply further information, including a copy of the physical call for papers, on request. I would especially encourage formation of sessions concentrating on subjects/applications which from a group of co-workers.  Date: 30 Nov 1983 22:02:26 EST (Wednesday) From: Marshall Abrams Subject: Donate computer for tax credit To: microgroups:@mitre Cc: abrams@mitre A charitable organization in the Washington, DC area would like to receive a donation of a computer. The donor would get a tax credit based on his/her valuation of the hardware and software. This would be an excellent opportunity to do a good deed and recover one's investment so that a newer configuration could be purchased. Please contact me to discuss this further. My telephone at work is 703/827-6938 and at home is 301/588-1005. Marshall Abrams  Date: Saturday, 26 November 1983 13:13 est From: Bruce Nemnich Subject: Re: what to do now? To: Robert Elton Maas cc: INFO-PCNET@MIT-MC.ARPA In-Reply-To: Message of 26 November 1983 03:03 est from "Robert Elton Maas" Message-ID: <831126181358.141890@MIT-MULTICS.ARPA> First of all, Orchid Technology is indeed selling a LAN for IBM-PCs called PCnet. It has been on the market for quite a while now, and it seems to be a reasonable product, judging from the specs (I have not used it). I am under the impression they filed for and received a trademark on the name, but I am not sure. If our PCNET is to die, I suppose it doesn't matter. Foo. I speak as one of those who said they would try to contribute, but have not. I have no real excuse, except the one we all have: not much time. I was really excited about PCNET when I first learned of it a little over a year ago. It is a good protocol; better than any I have seen for its medium. At the time, I was in charge of software development for a software-for- the-masses startup. I suggested to REM at least three times the possibility of doing a set of PCNET applications as a commercial product, assuring him that the protocols and specs would remain public domain (though the product would be the property of my employer). I had the authority and the manpower to get it done in a relatively short time, and I wanted to see it developed. Robert failed to respond in any way to any of my suggestions. I guess that took a little of the wind out of my sails, and I punted the idea. Meanwhile, Kermit is taking over the world as a file transfer protocol. Kermit was a nice, simple protocol (not nearly as robust as PCNET), but it is becomming a beast as more and more things are being hung onto it. People are wanting out of Kermit things which were designed into PCNET from the beginning. Still, there are *so* many Kermits out there it may be difficult for another protocol to displace it. When I needed a dailup file transfer protocol for Symbolics 3600s at my current job, I began working on Kermit, because all the other machines I needed to talk to already ran Kermit. Sigh. PCNET would have blown Kermit away if it had been ready a year ago. Enough rambling. --bjn  Date: 26 November 1983 03:03 EST From: Robert Elton Maas Subject: what to do now? To: INFO-PCNET @ MIT-MC Does anybody have any suggestions what to do about PCNET? About a year ago suggestions were made that our protocol wasn't really complete because not all the application programs that a user might want weren't yet designed, in particular a non-forwarding end-to-end file-transfer protocol (we already had a message-style file-transfer protocol, but that wasn't deemed enough). Also suggestions were made that the overall design of the net wasn't finished because some subtle high-level things like how to interface the PCNET software with the local mail-generating/reading/editing software weren't yet described in our documentation. So I reactivated the PCNET-PROTOCOL mailing list to finish the formal protocol specs, and created a new PCNET-DESIGN mailing list to discuss the design and implementation of software that used PCNET protocol. Unfortunately neither the people who made these suggestions nor others who joined the mailing lists have made sufficient contributions to get the tasks done, in fact in many cases they haven't even reviewed the proposals that I sent to the lists. I've been trying to run an online software workshop, whereby we specify the software interfaces that correspond to the protocol interfaces, then proceed to write actual code in various languages. Tim.UCI and Heller contributed some fine work, and I did a considerable job of indexing the PCNET documentation and the workshop notes in a tree structure for easy understanding of relationships between different parts of protocol/software and for easy access of relevant material, but hardly anybody else did anything useful, and to date we don't have any major results from this experiment, like the several working implementations of PCNET that we had hoped for. Meanwhile behind our back, Orchid Technology has (according to reports from several people; I haven't seen this myself) been advertising a completely unrelated product, and using the brand name "PCNET", a clear violation of our trademark. As far as I know, nobody official (at PCC, our parent organization since we merged several years ago) has filed suit or even notified them of the infringement. It's as if nobody really cares about PCNET. Should we throw in the towel, or what???  Date: 28 Oct 1983 19:58:19-PDT From: CCVAX.trest@Nosc To: INFO-PCNET@MIT-MC Please Add Me to your List. THANKS!! trest@nosc trest@nosc-tecr Mike Trest 4065 Hancock Street San Diego, Ca 92110 (619)225-1980  Received: from CU20B by CUCS20 with DECnet; 12 Oct 83 14:29:41 EDT Date: Wed 12 Oct 83 08:37:27-EDT From: Victor Muslin Subject: Pcent To: INFO-PCNET%MIT-MC@COLUMBIA-20.ARPA [Marquis of the Dark Force] Please add me to your mailing list. My current address is: Dec.Muslin%CU20B@COLUMBIA-20 - Thanks, Vic. -------  Received: from ucbcory.ARPA by ucbvax.ARPA (4.12/4.7) id AA07198; Sun, 2 Oct 83 20:36:27 PDT Date: Sun, 2 Oct 83 20:38:18 PDT From: jsc%ucbcory@Berkeley (James S. Carrington) Message-Id: <8310030338.AA05419@ucbcory.ARPA> Received: by ucbcory.ARPA (4.4/3.31) id AA05419; Sun, 2 Oct 83 20:38:18 PDT To: INFO-PCNET@MIT-MC Subject: mailing list if the pcnet mailing list is in operation please place me on the mailing list... jsc%ucbcory@Berkeley.ARPA james carrington  Date: 22 September 1983 03:08 EDT From: Robert Elton Maas Subject: demise of PCNET soon?? To: CCVAX.revc @ NOSC-CC cc: INFO-PCNET @ MIT-MC My answer to the following message (excerpt below) may be of interest to the rest of you, and since there hasn't been much activity on this mailing list lately I decided to give it a try. Date: 21 Sep 1983 07:34:16-PDT From: Bob Van Cleef Could it be that the day of PCnet has come and gone? I wondering if perhaps we are in the last days of the standard, modem systems, and that if anything we do in this area will be replaced in the next year or so. There are three major things I can think of that might replace modems&UARTs soon (anyone who thinks of another feel free to contradict me): (1) Local area nets, such as Ethernets - unfortunately although the tap may be cheap soon, the leased coax from your personal computer to the nearest longhaul-net interface will be too expensive for most personal computer users; (2) Digital telephone service - unfortunately Ma Bell isn't moving fast enough in this are for us to expect it in a year for the whole USA, not even for the major metropolitan areas; (3) New modems and synchronous X.25 interfaces - I dunno about this. Anybody think this will be available for all the popular microcomputers at a price we can afford in a year or so? Other ideas like satellite dishes and packet radio don't look reasonable, because satellite dishes are too expensive for each household to own one, and packet radio doesn't work out in the boonies where there is no other node within line-of-sight distance. Thus I think there'll still be a market for modems and UARTs for linking personal computers together into a WorldNet, for a few years at least. Perhaps the long-haul service will be done by direct dial in rural areas and by sharing satellite dishes or by cooperating cable-TV systems in the metropolitan areas. (Of course if communication is going to exist between somebody rural and somebody metropolitan, direct dial is the only thing the two have in common, so even the people in metropolitan areas will need direct dial modems in addition to whatever else they have.) Feel free to rebut. These are my informed opinions, not any concensus of the PCNET committee.  Date: 9 Sep 1983 1439-EDT From: AUSTIN at DEC-MARLBORO To: INFO-PCNET at MIT-MC Subject: LIST MEMBERSHIP Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11950300126.20.647.8137 at DEC-MARLBORO> PLEASE ADD ME TO YOUR INFO-PCNET DISTRIBUTION LIST. MY NAME IS TOM AUSTIN AND MY NETWORK ADDRESS IS AUSTIN@DEC-MARLBORO. THANKS! --------  Date: 7 September 1983 08:39 edt From: TMPLee.DODCSC at MIT-MULTICS Subject: Query: GTE Telenet blk xfr protocol? To: Header-People at MIT-MC, Human-Nets at RUTGERS, info-pcnet at MIT-MC, protocols at RUTGERS cc: TMPLee.DODCSC at MIT-MULTICS (list moderators: please feel free to ignore this if you don't think it fits your list) Does anyone know the details (i.e., protocol) for doing block transfers to/from GTE Telenet public dial-up access points? I'm using a personal computer as my terminal and getting to an ARPAnet machine via gte-telenet. I'd like to be able to store/retrieve and local edit traffic from the net but to do that I have to have some kind of simple protocol for transmission of blocks of text to and from GTE Telenet. I think they support such a protocol, but have no information about it. (not asking for a reliable transmission protocol -- lines here are pretty good -- just one to do speed and buffer matching) Ted Lee  Date: 31 August 1983 11:10 EDT From: Robert Elton Maas Subject: MIT-MC leaving net, where does PCNET go? To: INFO-PCNET @ MIT-MC I haven't been able to get solid info, but there are official hints and solid rumors that MIT-MC will leave the net this September 30 when funding for the Macsyma Consorticum ends. Does somebody on another host have the capability of taking over (1) this mailing list (2) the tree-structured database (3) the online programming workshop (4) the LISP-based test node (5) anything else related to PCNET which currently lives here? Preferably the new host should have EMACS with INFO and RMAIL/BABYL, MacLISP, and enough disk space to keep the data around. I'll start archiving the PCNET stuff at SU-AI (on magtape; SU-AI doesn't have spare disk space for this, nor do they have facilities such as EMACS) just in case we have to go offline for a while, but being able to stay online would be nicer.  Date: 21 July 1983 18:27 EDT From: Richard P. Wilkes Subject: UCLA/FTP To: INFO-PCNET @ MIT-MC, INFO-MICRO @ MIT-MC One of the systems we use has implemented UCLA/FTP on the IBM/370 and on the Apple, IBM, and Osborne. Unfortunately, we use other machines, and they don't intend to give us much help. Questions: Is anyone out there familar with this protocol. Is it in the "public" domain? Is there Z80/8080 ASM source floating around, or can it be had? Any help would be greatly appreciated. -r  Date: 11 July 1983 22:33 EDT From: Gail Zacharias Subject: [cc.fdc: KERMIT Available on the ARPANET] To: INFO-PCNET @ MIT-MC Date: Mon 11 Jul 83 17:49:18-EDT From: Frank da Cruz To: INFO-IBMPC at USC-ISIB, INFO-CPM at MIT-MC, TOPS-20 at SU-SCORE cc: SY.FDC%cu20b at BRL, SY.DAPHNE%cu20b at BRL, OC.WBC3%cu20b at BRL, Chris at COLUMBIA-20, Hu at COLUMBIA-20, Eiben at DEC-MARLBORO, CERRITOS at USC-ECL, JS5A%cmccta at BRL, JO2F%cmccte at BRL Re: KERMIT Available on the ARPANET KERMIT is a protocol for transferring files between computers of all sizes over ordinary asynchronous telecommunication lines using packets, checksums, and retransmission to promote data integrity. Microcomputer implementations of KERMIT (and some of the mainframe implementations) also provide terminal emulation. KERMIT is non-proprietary, thoroughly documented, well tested, and in wide use. The protocol and the original program implementations were developed at Columbia University and have been shared with many other institutions, some of which -- particularly Stevens Institue of Technology -- have made contributions of their own. * KERMIT Implementations KERMIT is presently available for the following systems: Machine Operating System Language ------- ---------------- -------- DECSYSTEM-20 TOPS-20 MACRO-20 DECsystem-10 TOPS-10 MACRO-10 VAX-11 VMS Bliss-32, Macro-32 IBM 370 Series VM/CMS IBM Assembler VAX,PDP-11,SUN,etc UNIX C PDP-11 RT-11 OMSI Pascal 8080, 8085, or Z80 CP/M ASM 8086, 8088 PC DOS, MS DOS IBM PC Macro Assembler Apple II 6502 Apple DOS DEC-10/20 CROSS All but the UNIX version and RT-11 versions use or imitate the TOPS-20 style of user interface - command keyword recognition and completion, ?-help, etc. The 8080 version runs on the DEC VT180, DEC Rainbow-100 (speeds up to 1800 baud only), DECmate II (CP/M), Heath/Zenith-89 and 100, Intertec Superbrain, Apple II with Z80 Softcard, TRS-80 II (CP/M), Osborne 1, Osborne Executive, Kaypro II, Vector Graphics, Ohio Scientific, Telcon Zorba, and others. The 8086 version runs on the IBM PC and lookalikes (such as the Compaq portable) and on the Heath/Zenith-100. * Distribution Policy The KERMIT software is free and available to all, sources and documentation included. Columbia University has been charging a reproduction fee of $100 for mailing tapes to recover its costs. Other sites are free to redistribute KERMIT on their own terms, and are encouraged to do so, with the following stipulations: KERMIT should not be sold for profit; credit should be given where it is due; and new material should be sent back to Columbia University so that we can maintain a definitive and comprehensive set of KERMIT implementations for further distribution. * Distribution Mechanisms: In addition to direct distribution from Columbia, KERMIT (all the versions listed above, as they existed in June 1983) has been placed on the DECUS VAX/VMS and RSX-11 SIG tapes, and may, at some point, be added to the DECUS library for DEC-10's and -20s, and also distributed through IBM SHARE. In addition, the KERMIT distribution is available at Columbia to users of BITNET on host CUVMA. * ARPAnet Distribution: Now KERMIT is available in its entirety to the ARPAnet community. An up-to- date KERMIT distribution area will be maintained on the Columbia University Computer Science Department DECSYSTEM-20, a new machine which as just been added to the ARPAnet. The KERMIT distribution can be found at ARPAnet host COLUMBIA-20 in the directory PS:, accessible via anonymous FTP. This is a large area, containing sources (and in some cases binaries or hex) of all implementations, plus documentation and various utility programs -- presently over 2000 DEC-20 pages in about 170 files -- so you probably don't want to take the whole area blindly. First, look at the short file 00README.TXT (starts with two zeros, always appears at the top of a directory listing), which explains what is where, and then take the parts that are of interest to you. The KERMIT area on COLUMBIA-20 should now be considered the definitive source for KERMIT on the ARPAnet; other areas where parts of the KERMIT distribution have been available will not necessarily remain current or complete. The major documentation for KERMIT is the KERMIT USERS GUIDE and the KERMIT PROTOCOL MANUAL, on line as USER.DOC and PROTO.DOC, respectively. The User's Guide gives an overview, general instructions for use, and details about the use and installation of each version, including procedures for initially downloading microcomputer versions from a mainframe host. The Protocol manual is supposed to describe the protocol in sufficient detail to allow new implementations of KERMIT to be written. KERMIT is an active project. Features are being added to existing implementations, bugs are fixed, new implementations are being developed. Towards the end of August (when I return from vacation), I'll set up a KERMIT mailing list for reporting bugs, trading information, announcing new versions, etc. In the meantime, send comments and inquiries to me at this ID, though I won't be able to answer for a while. * Disclaimer No warranty of the software nor of the accuracy of the documentation surrounding it is expressed or implied, and neither the authors nor Columbia University, nor any other contributor, acknowledge any liability resulting from program or documentation errors. - Frank da Cruz Manager of DEC Systems Columbia University Center for Computing Activities CC.FDC@COLUMBIA-20  Redistributed-Date: 14 June 1983 22:31 mst Redistributed-By: VaughanW.REFLECS at HI-MULTICS Redistributed-To: info-pcnet at MIT-MC Date: 27 May 1983 19:08 mst From: VaughanW at HI-MULTICS (Bill Vaughan) Subject: Call For Papers To: HUMAN-NETS at RUTGERS cc: sf-lovers at MIT-AI, info-micro at MIT-MC Last year at this time I put the Call for Papers for the PC3 conference out to these mailing lists and bulletin boards. We seemed to get a good response, so here it is again. Notice that this year's theme is a little different. Further note that we are formally refereeing papers this year. If anyone out there is interested in refereeing, please send me a note. --------------- Third annual Phoenix Conference on Computers and Communications CALL FOR PAPERS Theme: THE CHALLENGE OF CHANGE - Applying Evolving Technology. The conference seeks to attract quality papers with emphasis on the following areas: APPLICATIONS -- Office automation; Personal Computers; Distributed systems; Local/Wide Area Networks; Robotics, CAD/CAM; Knowledge-based systems; unusual applications. TECHNOLOGY -- New architectures; 5th generation & LISP machines; New microprocessor hardware; Software engineering; Cellular mobile radio; Integrated speech/data networks; Voice data systems; ICs and devices. QUALITY -- Reliability/Availiability/Serviceability; Human engineering; Performance measurement; Design methodologies; Testing/validation/proof techniques. Authors of papers (3000-5000 words) or short papers (1000-1500 words) are to submit abstracts (300 words max.) with authors' names, addresses, and telephone numbers. Proposals for panels or special sessions are to contain sufficient detail to explain the presentation. 5 copies of the completed paper must be submitted, with authors' names and affiliations on a separate sheet of paper, in order to provide for blind refereeing. Abstracts and proposals due: August 1 Full papers due: September 15 Notification of Acceptance: November 15 Conference Dates: March 19-21, 1984 Address the abstract and all other replies to: Susan C. Brewer Honeywell LCPD, MS Z22 PO Box 8000 N Phoenix AZ 85066 ---------------- Or you can send stuff to me, Bill Vaughan (VaughanW @ HI-Multics) and I will make sure Susan gets it.  Date: 7 June 1983 02:48 EDT From: Robert Elton Maas Subject: organized discussion/debate on Honeywell and PCNET To: INFO-PCNET @ MIT-MC A crucial policy decision is whether to change the PCNET protocol for Simple mode yet one more time to avoid the use of atsign and other characters that Honeywell systems refuse to pass to user programs. Anyone wanting to help resolve this question/issue should ask me for the introduction subnode and any other subnodes of interest. So far we don't seem to be coming to any concensus on this question. Tonight I've reorganized this information in a tree structure: File: DEBATE, Node: Computers that can't handle ASCII, Up: Debate in progress What to do about Honeywell and Interdata computer systems that refuse to pass atsign to user programs? * Menu: * Introduction and proposed options:honeyw options REM * Feedback in reply to above options:option replies * IMportance of Honeywell implementations:honeyw clusters * Details about Honeywell problem:honeyw innards * Reprogram Honeywell rather than change protocol:reprogram Honeywell * ANSI standards vs. workable protocols:ANSI stds * IF we decide to change Simple-mode protocol, details:new simple details  Date: 7 June 1983 02:44 EDT From: Robert Elton Maas Subject: Where do we spend our energy to make PCNET happen? To: INFO-PCNET @ MIT-MC There are some design and protocol questions yet unresolved, and hardly any implementation except bits and pieces here and there. The question arises, where should we spend our energies? Below is the toplevel DEBATE/DISCUSSION frame in the PCNET info tree, pointing to the hot issues recently under discussion. If you want to discuss the toplevel question "which of these topics should we take pains to resolve and which should we ignore?", ask me for the "Overall policy" debate node and whichever other nodes interest you. I'll be sending one more frame in a couple minutes. File: DEBATE, Node: Top, Up: (MC:PCNET;PCNET INFO)Top This is where major PCNET decisions will be made! * Menu: Policy issue discussed on general INFO-PCNET forum... * Overall policy:: where we should spend our energy, what will PCNET be? * Computers that can't handle ASCII:: such as Honeywell? If and when we have a firm policy decision to change the protocol again, this topic will switch to PCNET-PROTOCOL to finalize the details. Protocol design getting done via PCNET-PROTOCOL working group... * Faster than 600 baud:: Handling triple-modems et al? * Details of FTP1 protocol:deb FTP1 Software design, especially overall mail system, via PCNET-DESIGN ... (This also includes some high-level network design)... * General intro to topics covered here:deb design * Mail system:deb mail * FTP system:design ftp * Stacking application programs:design stack * Node control, changing modes:deb node * Blocking&unblocking streams:deb blocking * Old software-design flowcharts, on SU-AI backup tapes:old flow  Date: 29 May 1983 16:44 EDT From: Frank J. Wancho Subject: PCnet (tm) To: INFO-PCNET @ MIT-MC On page 103 in the June 83 issue of BYTE, AST Research Inc. has an ad, headlined: AST & PCnet (tm) for IBM PC On the botton, in fine print: PCnet is a trademark of Orchid Technology, Inc... Note that it does NOT say "registered". Once again, I must point out that companies will assume a trademark unless challenged. If not challenged, it can be registered! (and if registered, it can still be challenged for some period, but, if it sticks, YOU will have to move aside and come up with a new name.)  Date: 4 May 1983 06:22 EDT From: Robert Elton Maas Subject: Recent progress, capsule summary of PCNET To: INFO-PCNET @ MIT-MC Not much has happened lately in the PCNET-PROTOCOL working group (which was supposed to be finishing the specs for the FTP1 application program and tidying up other loose ends). There's a hot debate on whether to change the Radix-41 characterset again and also whether to change the packet framing and half-duplex turnaround characters. Perhaps we need some new members who are eager to criticize the current FTP1 protocol specs and choose between the alternatives at certain places in the protocol. Not much has happened in the PCNET-DESIGN working group (which was supposed to be discussing overall design of PCNET software to satisfy our network desiderata such as forwarding of mail and structured programming). Perhaps we need some new eager members. Some progress has been made in my online workshop. One volunteer has written specs for the C language for one of the major software interfaces and has written stubs to emulate the lower layers so the upper layers can be tested/debugged without the lower layers. Another person has volunteeredto do the same for Pascal. In the course of editing the tree-structured databases for the online workshop and the protocol specs, I've come up with a capsule summary of PCNET protocol, which may be of interest to some of you... PCNET protocol/software has two major interfaces: - the lower interface, whereby PCNET protocol/software talks to the hardware (modem&uart) drivers, - the upper interface, whereby application programs talk to the PCNET packet protocol/software. When connecting, disconnecting, or changing modes in a dangerous way that requires dropping out of packet protocol, only the lower interface exists. The hello or bye or dangerous-mode-change protocol/software talks through the lower interface to the hardware drivers. At all other times when online, both interfaces exist. The application program talks through the upper interface to the PCNET packet protocol/software, which in turn talks through the lower interface to the hardware drivers. PCNET packet protocol/software provides error- and flow-control, including multiple logical streams. Application programs provide services desired by the user, such as electronic mail, file transfer, loopback testing, remote virtual-terminal login, or whatever.  Date: 6 Apr 1983 0848-PST From: Drcpm-Otds-Sdsc-1 at OFFICE-7 Subject: Replicated Data in Distribued DBMSs To: arpanet-bboards at MIT-ML cc: info-pcnet at MIT-MC Attention DBMS enthusiasts --- In an effort to complete a local research project, information regarding the following topic is being sought: Replicated Data in Distributed Data Base Management Systems. If there are known periodical articles or studies which address this topic, please advise this organization. Thanks in advance, CPT C. Stanley U.S.A. CECOM Software Development Support Center DRCPM-OTDS-SDSC-1@OFFICE-7 -------  Date: 1 Apr 1983 1459-PST From: Dhuewe at OFFICE-10 (Dwaine Huewe) Subject: Subscription To: INFO-PCNET at MIT-MC Please send information on how to get put on the distribution list for INFO-PCNET. We're looking into networking techniques and would probably benefit from reading your archives if any exist. Thanks. --Neil Petersen -------  Date: 27-Mar-83 20:55:43-EST From: jalbers@BNL To: Info-PCNet@MIT-MC I am very interested in helping with your network. I have to say I'm not much of a programmer, but I like to say I am a professional thinker (even though I'm not out of HS) I am willing to learn. Jon Albers Address: jalbers@bnl  Date: 20 March 1983 18:57 EST From: Gail Zacharias Subject: IBM character set compatibility To: INFO-PCNET @ MIT-MC In-reply-to: Msg of 20 Mar 1983 17:46 EST from Devon S. McCullough In regard to the previous discussion of [,] chars on IBM systems: Maybe I'm a little confused here, but I don't quite see what is meant by this. As far as I can tell, one doesn't send characters over phone lines, one sends binary data. Now for example the ascii code for "A" is 65 (decimal), which doesn't even have a name in the EBCDIC chart I have here, so probably cannot be easily received by application programs on an IBM system. Conversely, the EBCDIC code for "A" is 193 which cannot be received by any ascii system which strips the parity bit. So just what kind of compatibility are we talking about here. PS: The ascii codes for [,] are the EBCDIC codes for $ and ), probably the only ascii codes in the radix-41 set which can be easily received by EBCDIC systems!  Date: 11 Mar 1983 1524-EST From: Ralph W. Hyre Jr. Subject: APPLE OBJECT CODE FOR PCNET To: INFO-PCNET@MIT-MC DOES ANYBODY HAVE ANY THAT THEY COULD MAIL ME SOMEHOW? I HAVE A PROGRAM THAT WILL CREATE AN APPLE TEXT FILE FROM MACHINE LANGUAGE. THANK YOU. - RALPH HYRE -------  Return-Path: <@MIT-MULTICS.ARPA:RMann.HDSA@M.PCO.LISD.HIS> Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 07-Mar-1983 16:36:16-est Date: 7 March 1983 1412-mst From: Roger Mann Subject: Re: Honeywell and atsign To: INFO-PCNET @ MIT-MC Just to try and clarify (or confuse) a point made about Honeywell mainframes and the @, I would like to point out that the front-end to the mainframe provides the line editing for input to the mainframe. As it turns out Honeywell is now selling a new front end called the Datanet 8 that permits terminal devices to statically change their line editing characters by configuration and to dynamically change their line editing characters by meta-command to the front end. This means, of course, that when connecting to a L66, DPS88 or DPS8 with a DN8 front-end, the host can be made insensitive to @. --Roger  Return-Path: Date: 4 Mar 83 09:01-EST (Fri) From: Robert (LISPer DM) Heller Subject: mainframes & PCnet: line editing characters, etc. To: info-pcnet@mit-mc Via: UMASS-CS; 4 Mar 83 13:21-EST I just want to say that even such horrible beasts as CDC Cyber's running NOS, can handle PCNET. On the CDC machine, one just does the I/O in "transparent" mode - only CR is interpreted (and is needed to terminate input). On a VAX (VMS), the terminal driver allows both reading and writing characters (one or several) in transparent modes (ie no munging around with editing/formating). (one can even pass a ^Y straight to a non-privliged user program - real fun if that program loops while reading chars!). This must be true of just about all of DEC's machines & OS's, or else TECO (or EMACS) would not work! While this coding may be less pleasent than using higher level I/O (ie readln in Pascal) and usually means grubby assembly code (ie COMPASS), it can be done. I don't know about IBM's (or Univac's or Honeywell's) mainframes, but if one can get around the line editing on a CDC monster, you should be able to on the other beasts - probably with some grubby assembly code. Control characters should not be a problem, since PCNET uses none - ALL of the PCNET characters are printably ASCII! (except in binary mode, which probably would not work on the mainframes...) robert heller heller.umass-cs@udel-relay  Date: 4 March 1983 02:06 EST From: Robert Elton Maas Subject: administrivia To: INFO-PCNET @ MIT-MC Just a reminder, requests to be added or deleted should be sent to INFO-PCNET-REQUEST at MIT-MC (except for Xerox and other places that have sub-distribution lists), not to the whole INFO-PCNET mailing list. When you tell new people about this list, be sure to tell them about the -request mailbox too.  Return-Path: <@MIT-MULTICS.ARPA:Nemnich@MIT-MULTICS> Date: 3 March 1983 1312-est From: Bruce J Nemnich Subject: IBM isn't a problem To: Info-PCnet @ MIT-MC As I am sure you all know, IBM mainframes are EBCDIC. If there was ever an intention to talk to these machines, I question the decision to include non-EBCDIC characters in the radix-41 character set ([ and ]). The default logical-line-delete character on 370's running VM is the EBCDIC cent-sign. Since there is no ASCII cent-sign, the systems usually translate it into an ASCII character which is not in EBCDIC in order to talk to ASCII devices and still have default editing characters. Most seem to translate cent-sign into left-bracket ([). I have seen at least one which translates it into backslash (\). All that aside, it is easy to change the logical editing characters with a CP command. By far the biggest problem in talking to these machines is their lack of full-duplex support. --bjn  Date: 3-Mar-83 08:18:29-PST (Thu) From: unicom!vandal@LBL-CSAM.ARPA Subject: Addition to INFO-PCNET Return-Path: Message-Id: <8302031618.20634@LBL-CSAM.ARPA> Received: by LBL-CSAM.ARPA (3.284 [1/5/83]) id AA20634; 3-Mar-83 08:18:29-PST (Thu) To: lbl-csam!info-pcnet@mit-mc.ARPA Cc: lbl-csam!rem@mit-mc.ARPA Please add: unicom!vandal@lbl-csam Thanks, Jim C. unicom!vandal@lbl-csam  Date: 3 Mar 83 09:38 EST From: wegeng.wbst@PARC-MAXC.ARPA Subject: Re: Honeywell and atsign In-reply-to: RALPHW's message of 2 Mar 83 15:24 EST To: Ralph W. Hyre Jr. cc: INFO-PCNET@MIT-MC.ARPA Just to make my point more clear... I was not implying that ALL pcnet sites should support each and every protocol that is in use somewhere. Only the sites which connect to these "strange" sites need support the expanded protocol set. On the other hand, a forth mode which would allow for connecting sites to negotiate what mods to the Simple mode are needed seems to make sense. I like the idea of flexibility-by-design in the protocols. It allows for pcnet to handle communication with any new brain-damaged system which may come along in the future. ==dw  Date: 3 March 1983 09:24 EST From: Frank J. Wancho Subject: Can't handle atsign!?! To: REM @ MIT-MC cc: INFO-PCNET @ MIT-MC In-reply-to: The message of 3 Mar 1983 04:06 EST from Robert Elton Maas The UNIVAC mainframes have at least two losing features: 1. You cannot bypass the ^D intercept. 2. The at-sign, if appearing in column 1, will be taken as an exec-level command. Two at-signs (in column 1 and 2) will be taken as a transparent command. I am not sure that #2 can be bypassed, but I do know that #1 cannot. The reason is that I asked our UNIVAC SEs to remove the ^D intercept (which causes an immediate disconnect and logout when detected at *any* time - unlike Unix, where such effect only occurs at the shell prompt). He made that minor change on a test system and only that change and was unable to bring up the system. He investigated no further due to other pressing problems at the time. This was on a UNIVAC 1108 running EXEC 8 Level 31. They are now moving up from Level 33 to 37 in preparation for a move to a UNIVAC 1100/62 and when that is complete, I will ask again. --Frank  Date: 3 March 1983 04:06 EST From: Robert Elton Maas Subject: Can't handle atsign!?! To: Schauble.Multics @ MIT-MULTICS cc: INFO-PCNET @ MIT-MC Date: 2 March 1983 19:35 est From: Schauble.Multics at MIT-MULTICS Gee, I hadn't realized that IBM also had problems with the PCNet character set. I am not aware of any problem an IBM machine would have with our current protocol (unless Gilmore's latest change in the Radix-41 characterset, adding ":;<=>" to replace "()+-*", will upset it). Of course if it loses or if the other node starts transmtting while turnaround is still in progress there'll be a turnaround-failure causing a timeout to occur causing a 10-second pause before processing can resume (or less if timeouts are changed). So, as the protocol stands now, it cannot be implemented on the mainframes or mini's (which usually use the same conventions) of IBM, Univac, and Honeywell. I don't quite agree. Only old Univacs are at fault I think (can somebody confirm whether new Univacs use a 6-bit characterset where atsign is the null character used for padding and not passed to programs?). I think all IBMs will work but none of them have ever been offered as nodes (except the IBM PC) so we don't know yet. Thus the number one (IBM) and number two (DEC) mainframe manufacturers should be able to get all their machines into PCNET.  Date: 3 March 1983 03:51 EST From: Robert Elton Maas Subject: test msg for Xerox sublist To: INFO-PCNET @ MIT-MC Taft.PA@PARC-MAXC.ARPA has set up a local (Xerox) sub-distribution list called XeroxInfoPCNET^.pa@PARC-MAXC for INFO-PCNET recipients at PARC-MAXC and related sites. This is a test to make sure this all works. From now on, PARC-MAXC et al people should add/delete their name directly to/from that list instead of sending a query to INFO-PCNET-REQUEST@MIT-MC. There are a few other sub-lists for UUCP and CSNET sites already.  Date: 2 Mar 1983 2200-PST Subject: PLEASE DELETE ME From: Tom Carnahan To: INFO-PCNET@MIT-MC cc: FJW@MIT-MC POSTAL-ADDRESS: Tom Carnahan, SMC 1819, NPS, MONTEREY,CA 93940 Phone: (Home) 408-372-7480 (NPS office) 408-646-2174 AV 878-2174 I'm getting bogged down from all of the various mail I'm getting from various mailing lists.......Please delete me from this one. Thanks, Tom -------  Date: 2 March 1983 23:29 EST From: Gail Zacharias Subject: Honeywell and atsign To: REM @ MIT-MC cc: INFO-PCNET @ MIT-MC In-reply-to: The message of 2 Mar 1983 21:09 EST from Robert Elton Maas I cannot believe that these machines do not provide ways for programs to do terminal i/o without system-provided editing. The usurping of PCNET characters for editing functions simply means that PCNET implementations cannot call the high level read-a-line type routines to do their i/o. But I'm sure there are "raw" or "super-image" input modes which let you read without editing. I think you all are fooling yourselves if you think that you can build a PCNET implementation on mainframes without doing some low-level hacking in the code. Most systems have an interrupt character (^Z on ITS, ^C on TNX, ^Y on VMS etc.) which exits the running program. This character could always appear on the line due to noise. So a PCNET implementation needs to disable this. Any code which knows how turn off ^Z/^C/^Y will have no trouble turning off rubout or @ or anything else. Note also that many systems will mung output done with high-level routines, adding padding, maybe expanding tabs, etc. So you need to do output at a lower level too.  Date: 2 March 1983 23:27 EST From: Frank J. Wancho Subject: At-Signs, etc. To: INFO-PCNET @ MIT-MC I think something's wrong here. It is being assumed that a PCNET connection will be run an ordinary user dialup job on these mainframes in question, and thus run into line/char editing codes. I would expect that the PCNET program that is eventually invoked on the mainframe end would turn off all those editing conventions. Besides the PhoneNet Protocol of MMDF, KERMIT also attempts to do character-set negotiations, in particular with IBM mainframes. I never really did see the *absolute* need for having framing at-signs in the protocol anyway... --Frank  Date: 2 March 1983 21:39 EST From: Robert Elton Maas Subject: Re: PCNET expansion to handle deficient character sets To: FISCHER @ RUTGERS cc: INFO-PCNET @ MIT-MC If other manufacturers besides Honeywell are putting out system that can't handle the characters @[] QWERTYUIOPASDFGHJKLZXCVBNM 0123456789 :;<=> and if these lacks aren't all the same, like if some can't handle < and some can't handle ; etc., then maybe instead of having a special mode for Honeywell we can have a special mode for deficient computers in general. Normal nodes will just use the above characterset after a trivial negotiation for standardness, while deficient nodes will do a trivial negotiation to determine they are deficient and then use the PhoneNet standard or something similar for negotiating the actual characterset. On the other hand if atsign is the only problem character, I'm leaning towards a special Simple-but-no-atsign node. But I don't think we're close to a concensus yet, so keep up the discussion...  Date: 2 March 1983 21:09 EST From: Robert Elton Maas Subject: Re: Honeywell and atsign To: wegeng.wbst @ PARC-MAXC cc: INFO-PCNET @ MIT-MC PCNET already a protocol defined for HELLO, which includes first the host-specific JCL for logging in, then a simple negotiation for PCNET protocol mode (Simple, Binary, Binary-at-higher-speed). The pending question is whether to add a fourth option Simple-but-no-atsign which invokes some mutant of Simple, or to accomodate Honeywells by another method, or not to accomodate them at all.  Date: 2 Mar 1983 2016-EST From: Ron Subject: Re: PCNET expansion to handle deficient character sets To: Schauble.Multics@MIT-MULTICS, info-PCNet@MIT-MC In-Reply-To: Your message of 2-Mar-83 1935-EST I concur with Mr. Schauble. As he mentioned, character set deficient mainframes are a large percentage of computers in general, as well being a large percentage of the computers where PCNET would find its greatest audience: university computing centers. If PCNET is going to claim to support standard mainframes it will need a reasonable way of handling deficient character sets... eventually. The phonenet technique seems like a good place to begin thinking. In the mean time the PCNET implementors also have to carefully spread their thin manpower resources to cover the basic goals of the project. Until a portable implementation of current PCNET is up perhaps this expansion should be shelved? If only this hot air could be used to fan (fuel?) the implementors' fires... (ron) -------  Date: 2 March 1983 19:35 est From: Schauble.Multics at MIT-MULTICS Subject: Can't handle atsign!?! To: info-PCNet at MIT-MC Gee, I hadn't realized that IBM also had problems with the PCNet character set. So, as the protocol stands now, it cannot be implemented on the mainframes or mini's (which usually use the same conventions) of IBM, Univac, and Honeywell. That's not writing off "a few brain-damaged mainframes". IBM, Univac, and Honeywell are 1, 2, and 3 of all computer manufacturers. That's writing off the vast majority of large scale systems. Do you really want to do this?? Paul  Return-path: Mail-From: RALPHW created at 2-Mar-83 15:24:40 Date: 2 Mar 1983 1524-EST From: Ralph W. Hyre Jr. Subject: Re: Honeywell and atsign To: RALPHW@MIT-OZ In-Reply-To: Your message of 2-Mar-83 0946-EST Remailed-date: 2 Mar 1983 1618-EST Remailed-from: Ralph W. Hyre Jr. Remailed-to: info-pcnet@MIT-MC One of the first things that the Unix uucp package does when it establishes a connection with another site is decide what protocol to use. It would seem that PCNET could do something similar (if it doesn't already). The problem being PCnet could get so large from having to keep extra protocols around that it won't run reasonably on small systems and be able to talk to everybody it should be able to talk to. (As is the intention of PCNET.) Sites which talk to Honeywell systems (and similar brain-damaged systems) could support a protocol which can talk to those sites, but everyone else could simply support the primary set of protocols. I think it is cleaner to have one protocol. A gateway would allow anybody to talk to it, since it would speak true PCNET. A gateway would also have the useful feature that it could operate stand-alone if need be. If for some reason the operator of a certain site suddenly refused to be connected to PCNET, everything wouldn't be lost since the gateway could function standalone. -------  Date: 2 Mar 83 09:46 EST (Wednesday) From: wegeng.wbst@PARC-MAXC.ARPA Subject: Re: Honeywell and atsign In-reply-to: REM@MIT-MC.ARPA's message of 2 Mar 83 04:24 EST To: Robert Elton Maas cc: INFO-PCNET@MIT-MC.ARPA If I may throw in my two cents worth (although I haven't seen the specifics of the PCNET protocol)... One of the first things that the Unix uucp package does when it establishes a connection with another site is decide what protocol to use. It would seem that PCNET could do something similar (if it doesn't already). Then, sites which talk to Honeywell systems (and similar brain-damaged systems) could support a protocol which can talk to those sites, but everyone else could simply support the primary set of protocols. This scheme also allows for future upward expansion. ==dw  Date: 2 March 1983 04:24 EST From: Robert Elton Maas Subject: Honeywell and atsign To: INFO-PCNET @ MIT-MC Here's one more idea. If we could find some minor protocol change that required no software change whatsoever at the receiving end and only a minor change at the transmitting end, that wouldn't be too bad. We did that sort of thing once before. We added a after half-duplex turnaround in simple mode, so that systems running in half-duplex line mode at the system level could still receive PCNET transmissions. The receiver on character-oriented systems doesn't have to be changed because it has already stopped listening at the third bracket and thus never sees the . The transmitter just has to send one extra character after brackets, a simple modification. One really crufty idea would be to transmit /@/ instead of just @ as packet framing. Normal nodes would ignore the / characters and use @ as packet framing, while software for Honeywell would be modified to accept / instead of @ as packet framing (the system would rub out the first /, leaving just the second / to the user program). If the UART were out of frame, the @ would reframe it the same as before. -- I hope we end up deciding on something less crufty!  Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 02-Mar-1983 02:48:21-est Date: 1 March 1983 2353-mst From: Paul Schauble Subject: Honeywell systems can't handle atsign To: INFO-PCNET @ MIT-MC If I may jump in... I think REM accurately defines the choices. The Honeywell GCOS line reserves @ and # for character and line delete. These are not changeable. My comments on his proposals: - Such systems aren't using ASCII thus can't be in PCNET until their change their ways; If they want to exchange electronic mail they will have to use some other protocol. Well, maybe they aren't. The systems that use backspace for correction aren't ASCII either. But that's no defense. The real question is "Are these systems "worth" supporting?" I have perhaps a different view on PC networks than you people do. I see them as being a cluster of PC's centered on a mainframe. The mainframes will have the least capable communications systems in the net. But they will also have an order of magnitude more storage than all of the PC's put together. I think that communication with the mainframes is essential. And the Honeywell systems mentioned represent a thousand large scale sites and several thousand large mini sites. Too much to ignore. - Gateways may be used to interface between standard PCNET nodes and these funny PCNET nodes that use some character other than atsign for packet framing but which otherwise can talk PCNET. Works. But that defeats the goal of having network connections use the same ports as interactive terminal connections. It also requires considerable effort from the site to get one running. - We define an option for substituting characters on such systems, and allow any PCNET node to talk to these funny nodes once this option is invoked; The option may be specified at HELLO time or may be passed along in node IDs or may need to be known a priori. This is my recommendation. More follows. - We change the PCNET protocol once again, forcing everyone on the whole net to avoid atsign just because of one manufacturer that refuses to conform to ASCII standards. Well, the previous is a protocol change also. Before I spoke with REM, I discussed the topic with several others. The consensus is that it doesn't matter what fixed character set you pick, you will sooner or later run into trouble with some machine. This may be the first time PCNet has had character problems, but then there aren't many mainframe PCNet implementations. I won't attempt to predict what other problems may be in store, the manufactureres do too many strange things. What I suggest is to follow the lead of the PhoneNet protocol. This begins its connection assuming that the only legal data is short packets containing only 0-9 and A-F ended by CR. It then exchanges descriptions of the communication facilities on each end and develops a full description of the link. Characters that cannot be sent are known to both ends and avoided. Paul  Return-Path: <@MIT-MULTICS.ARPA:Schauble@M.PCO.LISD.HIS> Received: from M.PCO.LISD.HIS by MIT-MULTICS.ARPA dial; 02-Mar-1983 02:48:21-est Date: 1 March 1983 2353-mst From: Paul Schauble Subject: Honeywell systems can't handle atsign To: INFO-PCNET @ MIT-MC If I may jump in... I think REM accurately defines the choices. The Honeywell GCOS line reserves @ and # for character and line delete. These are not changeable. My comments on his proposals: - Such systems aren't using ASCII thus can't be in PCNET until their change their ways; If they want to exchange electronic mail they will have to use some other protocol. Well, maybe they aren't. The systems that use backspace for correction aren't ASCII either. But that's no defense. The real question is "Are these systems "worth" supporting?" I have perhaps a different view on PC networks than you people do. I see them as being a cluster of PC's centered on a mainframe. The mainframes will have the least capable communications systems in the net. But they will also have an order of magnitude more storage than all of the PC's put together. I think that communication with the mainframes is essential. And the Honeywell systems mentioned represent a thousand large scale sites and several thousand large mini sites. Too much to ignore. - Gateways may be used to interface between standard PCNET nodes and these funny PCNET nodes that use some character other than atsign for packet framing but which otherwise can talk PCNET. Works. But that defeats the goal of having network connections use the same ports as interactive terminal connections. It also requires considerable effort from the site to get one running. - We define an option for substituting characters on such systems, and allow any PCNET node to talk to these funny nodes once this option is invoked; The option may be specified at HELLO time or may be passed along in node IDs or may need to be known a priori. This is my recommendation. More follows. - We change the PCNET protocol once again, forcing everyone on the whole net to avoid atsign just because of one manufacturer that refuses to conform to ASCII standards. Well, the previous is a protocol change also. Before I spoke with REM, I discussed the topic with several others. The consensus is that it doesn't matter what fixed character set you pick, you will sooner or later run into trouble with some machine. This may be the first time PCNet has had character problems, but then there aren't many mainframe PCNet implementations. I won't attempt to predict what other problems may be in store, the manufactureres do too many strange things. What I suggest is to follow the lead of the PhoneNet protocol. This begins its connection assuming that the only legal data is short packets containing only 0-9 and A-F ended by CR. It then exchanges descriptions of the communication facilities on each end and develops a full description of the link. Characters that cannot be sent are known to both ends and avoided. Paul  Return-Path: Date: 28 Feb 83 18:34-EDT (Mon) From: the Golux Subject: How about VAXen? To: info-pcnet@UMass-ECE Cc: coar@UMass-ECE Via: UMASS-ECE; 1 Mar 83 23:09-EST Just what is an 'auto-answer' modem? The sort of thing that mainframes use for dial-in lines? And if so, has anyone done anything in the direction of connecting a VAX 780 running VMS? ken coar.umass-ece@udel-relay  Date: 1 Mar 1983 at 1927-PST To: Info-PCNET at MIT-MC Subject: Radix-41 Heresy From: fylstra at Sri-Tsca Received: from SRI-Tsca.micom by SRI-TSC.micom with rs232; 1 Mar 83 19:34-PST We really should leave these link-level protocol issues alone and concentrate on the FTP protocol, where gaping holes remain. Nonetheless, against my better judgement, I'm going to dump my 2 bits into the bucket... The idea of line editing is really external to the ASCII code. I don't believe that the ASCII standard says anything about what characters are to be used for such things as char-delete, line-delete, or line-retype. Ctl-H, for example, is just a format effector that moves the printing position in a specified way, but has no meaning as far as buffered input is concerned. Many of us have grown up with DEC's style of terminal IO (copied by CP/M) and thus confuse it with the ASCII standard. Interdata DOS, as I recall, uses @ as an attention character, # for line-delete, and _ for char-delete. There are probably many other examples. There is nothing in the ASCII standard that prescribes against using graphic characters for line editing functions. The issue is thus which subset of ASCII is "most likely" to be transparent with respect to the terminal IO performed on timesharing computers of the type likely to have dial-in ports. I take it for granted that all personal computers are completely flexible to use any subset of ASCII that we select. I'd be willing to bet that the subset of ASCII most likely to be passed transparently by all operating systems is ... the FORTRAN character set. Contrary to what some people believe, the FORTRAN character set is not ASCII; it is ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 =+-*/(),.$ and blank. (ANSI FORTRAN standard X3.9-1966, section 3.1; 1977 FORTRAN added only two characters, ' and :, to the 1966 character set.) A FORTRAN compiler exists on virtually every timesharing operating system known to man, and the non-transparent character set (consisting of line editing, flow control, and attention characters) is highly unlikely to conflict with the FORTRAN set. I basically like the idea of Radix-41 as the default method of achieving 8-bit transparent communication with any type of computer. I would like to argue that the Radix-41 set (along with the framing characters @ [ and ]) should be modified to use FORTRAN characters only. After all, if PCNet can be implemented in portable FORTRAN, it will certainly run on any timesharing computer anywhere. Why do you think Software Tools was so successful? Dave Fylstra  Return-Path: <@MIT-MULTICS.ARPA:Hess@MIT-MULTICS> Date: 1 March 1983 1911-est From: Brian N. Hess Subject: @ on systems To: Info-PCNET @ MIT-MC Honeywell certainly isn't all to blame. (And I wonder what new machine can't change to another character -- MY Multics environment no longer uses @...) For example, your average IBM VM/370 uses "[" (or "]") to delete the entire line and "@" to delete a character. I believe that this falls into the same category as the question of "how does a PCNET node log into the remote machine?" -- Every machine is different. Just as you don't yet have uniform JCL for testing out your PCNET node with ITS or VM/370, you don't yet have uniform character usage. When and if each machine you want to talk to has a dedicated phone line for PCNET, both these questions will not matter -- you will get the correct phone number, and the TTY line will already be set up to do PCNET-style conversation, and the host will know not to use its strange characters to mean line or character delete. For now, just as you have to run some random JCL through to the host to get logged on to a PCNET node, you will also have to run through some random JCL to turn off or reassign the host's line and character delete codes. Does this make any sense? Postponing the issue and saying that ANY host will sooner or later be able to be made to conform to the proposed standard, i.e. "PCNET is PCNET; Honeywell can be MADE not to lose."? Brian  Date: 1 Mar 1983 1631-EST From: Ralph W. Hyre Jr. Subject: Re: Honeywell systems can't handle atsign To: info-pcnet@MIT-MC In-Reply-To: Your message of 1-Mar-83 0020-EST The question is, what if anything should PCNET do to accomodate these nonstandard computer systems? My first impression is to say something like: "Nothing. PCNET is PCNET; Honeywell loses." But this seems unreasonable. Options that come to mind are: - Gateways may be used to interface between standard PCNET nodes and these funny PCNET nodes... I personally like this best - all you really need for a gateway is a small (and cheap) machine that talks real PCNET. It could do the work of translating into the appropriate protocol/file format, and it could even serve as a bridge to other networks. (UUCP, Phonenet, etc.) Even if the machine doesn't treat characters normally for users, any reasonable operating system (Unix comes to mind) lets you redefine characters to do more 'reasonable' things. For example, the network remote-login programs on MIT systems let you type characters that would normally abort the programs themselves (such as ctrl-c from TELNET on Twenex). I'd rather put the translation burden on large systems than small ones, which is the reason I'm not really excited about the option below. - We define an option for substituting characters on such systems, and allow any PCNET node to talk to these funny nodes... This shifts the burden from large systems to small - let THEM substitute or have gateways. - We change the PCNET protocol once again... No. - Ralph Hyre -------  Date: 1 March 1983 1452-cst From: Paul Stachour Subject: Re: Honeywell systems can't handle atsign??? To: PCNET-Mailing-List Curious as to what "new" Honeywell system you are talking about. And I'm also curious why @ is a problem. Many systems prempt printing and non-printing characters for their own ideosyncracies. The number is legion and I could prbably cite at least one example from every system I'm familiar with. And, by-the-way, as I read the ASCII standard, use of the BS (ctl-h) character as a character-delete character is also in violation of the standards. So-doing disallows the multiple-characters in one character posisition, a long-time favorite with hard-copy folks, and those who like to underline text. And, as long as 'my-local-system' handles whatever I think the correct deletions mechanism is, any remote-login or remote-mail system should just pass the characters along. PCNET (or any other protocol) should as least have one transparent mode where EVERYTHING that is given to it is passed EXACTLY as given. IF it doesn't, then we have great problems already. P.S. Honeywell Multics allows ANY character (or none at all) to be used as the character-delete or line-delete characater, to enable the system to accomodate itself to the user's ideosyncracies (like using ctl-h for character-delete, which is very wierd to me), rather than forcing the user to accomodate himself/herself to the system's ideology. ...Paul  Date: 1 March 1983 00:20 EST From: Robert Elton Maas Subject: Honeywell systems can't handle atsign To: INFO-PCNET @ MIT-MC It has recently come to my attention that Honeywell has come out with a new computer system that usurpts atsign (@) for an editing character (delete character, in lieu of DEL/RUBOUT or BS/BACKSPACE/CTRL-H). This is in violation of ASCII which has been a standard for about twenty years, where atsign is supposed to be a printing character just like letters and numbers. The alleged reason for this nonstandard use for upward compatibility with a long line of older Honeywell computers, and unwillingness to retrain users to use some a more correct editing character instead of what they've been used to on older Honeywell systems. The question is, what if anything should PCNET do to accomodate these nonstandard computer systems? Options that come to mind are: - Such systems aren't using ASCII thus can't be in PCNET until their change their ways; If they want to exchange electronic mail they will have to use some other protocol. - Gateways may be used to interface between standard PCNET nodes and these funny PCNET nodes that use some character other than atsign for packet framing but which otherwise can talk PCNET. - We define an option for substituting characters on such systems, and allow any PCNET node to talk to these funny nodes once this option is invoked; The option may be specified at HELLO time or may be passed along in node IDs or may need to be known a priori. - We change the PCNET protocol once again, forcing everyone on the whole net to avoid atsign just because of one manufacturer that refuses to conform to ASCII standards. I'm leaning toward either of the middle options, ostracizing direct contact but allowing and encouraging gateways, or defining a HELLO or node-ID option. I'm sending this to the whole list instead of just PCNET-PROTOCOL because it's a general policy issue. I suppose that if the general concensus is to make some sort of protocol change (option or overall), the protocol working group will then discuss the specifics.  Return-Path: Date: 28 Feb 1983 13:12:04-PST From: tom.arizona@Rand-Relay To: info-pcnet@mit-mc Via: Arizona; 28 Feb 83 17:31-PDT Please take me off the mailing list!! --Tom  Date: 28 Feb 1983 0126-EST From: Ralph W. Hyre Jr. Subject: MODEMS To: INFO-PCNET@MIT-MC ARE THERE CURRENTLY PROVISIONS FOR CHANGING TRANSMISSION SPEEDS IN CASE TWO SYSTEMS HAVE HIGHER SPEED MODEMS? I THINK IT WOULD BE A SHAME TO GIVE UP BANDWITH FOR SIMPLICITY. RALPH HYRE -------  Date: 27 February 1983 20:49 EST From: Eliot Scott Ramey Subject: Volunteering To: INFO-PCNET @ MIT-MC Hi. I have (for some reason) a certain affection for Pascal, and would like to work on the Pascal-PCNET code. You mentioned something about "finishing..." the Pascal code. Has it indeed been started? Where can I find it? I may not be able to get to it before summer, but definatly I am interested in it. -Eliot at Mit-MC  Date: 27 February 1983 20:12 EST From: Robert Elton Maas Subject: Ignore preceding messages unless you're curious To: INFO-PCNET @ MIT-MC Some recent test- and new-member-messages directed to the sub-list at UMass-ECE got mistakenly forwarded back to the Arpanet and to the whole INFO-PCNET list. Here's a partial explanation: Return-Path: Date: 27 Feb 83 14:59-EDT (Sun) From: Charles Hutchinson Subject: PCNET INFO To: REM@MIT-MC Cc: HUTCHINSON.UMASS-ECE@UDEL-RELAY Via: UMASS-ECE; 27 Feb 83 19:04-EST ... However, I sent the wrong address for the public PCNET digest at Umass-ECE ... PS: OUR PUBLIC PCNET DIGEST ADDRESS IS : INFO-PCNET-DIGEST.UMASS-ECE@UDEL-RELAY The erroneous address was INFO-PCNET.UMASS-ECE@UDEL-RELAY which seems to loop back to the entire list.  Date: 27 February 1983 19:23 EST From: Robert Elton Maas Subject: TEST To: INFO-PCNET @ MIT-MC Test message to determine whether INFO-PCNET bbs at UMASS is looping back to the main INFO-PCNET distribution list.  Return-Path: Date: 26 February 1983 19:41 EST From: Robert Elton Maas Subject: INFO-PCNET Received: from MIT-MC.ARPA by udel-relay.ARPA ; 26-Feb-83 19:57:57-EST (Sat) To: hutchinson.UMass-ECE@UDEL-RELAY Cc: INFO-PCNET.UMASS-ECE@UDEL-RELAY Via: UMASS-ECE; 27 Feb 83 19:06-EST Test message.  Return-Path: Date: 26 February 1983 19:42 EST From: Robert Elton Maas Subject: INFO-PCNET Received: from MIT-MC.ARPA by udel-relay.ARPA ; 26-Feb-83 19:58:04-EST (Sat) To: hutchinson.UMass-ECE@UDEL-RELAY Cc: INFO-PCNET.UMASS-ECE@UDEL-RELAY Via: UMASS-ECE; 27 Feb 83 19:05-EST [Note that due to the Arpanet NCP-->TCP switchover, SU-AI and some other of our favorite nodes have been off the Arpanet since Feb 1 and may continue to be off the net for several weeks or a few months. Also due to problems with the subnet/backbone, communication with MIT-MC is VERY VERY difficult, with lost packets several times per minute, each of which takes 15-16 seconds before it's retransmitted, thus more than half the time I'm connected here I am waiting for output to pick up rather than proceeding with what I'm trying to do. (For example, there have already been about ten of these 15-16 second pauses just during trying to type these past ten lines!!) For these reasons, several files are inaccessible at the present time and access to other files will be very difficult. Most PCNET-related work that relies on the Arpanet is more or less suspended at the present time. For example, my online 8080/z80 workshop for example is completely inactive at present, as is all development of my LISP implementation of PCNET and all work on specs for the new end-to-end-realtime file-transfer-application protocol to augment the existing forwardable mail&file-application protocol. Activity will continue to be very diminished until such time as everybody has TCP working completely and the Arpanet is back together again.] Usual INFO-PCNET introductory message now follows: INFO-PCNET is used to notify our large list of curious folks on the net (now appx. 150) when we get something new accomplished, and to occasionally solicit help. Unfortunately nearly everybody on the list is just a sponge, waiting for somebody else to do the work and then trying to get the results for free. To my knowledge, only nine people have contributed anything useful to PCNET recently: Dave Fylstra has been working on the C version of PCNET, adapting it to BDS C and to Unix, and upgrading the software towards the latest protocols. He's also proofread the latest draft of the main protocol document and is helping finish the protocol for the FTP and MAIL "application programs". David Harris has been working on the protocol document. He also loaned me an Apple for a couple weeks so that I could check out the 6502-asm/Apple-BASIC implementation of PCNET. I've been upgrading the LISP version of the PCNET program, maintaining the mailing lists, corresponding with members, working on finishing the FTP/MAIL protocol, and now during the TCP-switchover lull reorganizing the PCNET files into a tree-structured database and providing an information retrieval service for those who don't have direct access to the access program for the database. Danielson supplied us with critical information about the SDLC CRC algorithm so that binary mode could be implemented. Mead installed my 8080/Z80 assembly-language program on his computer in Pasadena so that I could verify my code runs on at least one other machine and so that his machine could be used as a test node in case somebody else gets a node running. Harry Chesley, Frank Wancho and Gail Zacharias are helping me finish the FTP/MAIL protocol so that we can start programming the FTP protocol soon. Roger Long converted my IO1 module to Microsoft assembler then uploaded the result so I could compare it with my original CROSS assembler source and write a conversion program someday. But the remaining people on the mailing list haven't really contributed anything lately, except for a few people in my online workshop who are just starting to produce code for various I/O devices to be used by PCNET software but haven't really gotten any I/O interface modules working yet (if I've missed somebody in the listing of recent contributions above, please send me a correction). PCNET is built upon volunteer effort, but without volunteers we can't get anything done. We need a few more people developing software and installing and operating active nodes so that we can have an actual (small starting) network instead of just a bunch of specs and programs but with it all not really being used for anything. We need somebody to finish our software for 8080 6502 or 6809 assembly language, and in BASIC, PASCAL, FORTH, and FORTRAN, or to start (and also finish!!) new implementations in other languages (68000-asm, MESA, SMALLTALK, ?). We don't want too many different implementations right now (in case any further protocol changes are made, especially in the mail and file transfer "application programs"), but it sure would be nice if we had at least 1 (ONE, UNO, EIN, ICHI) completely implemented (originate&answer, current protocol, complete repertory of ECHO/FTP/MAIL "application programs") test node up and running for others to call into when testing their software. If you have access to any computer (micro, mini, maxi, whatever) which has an auto-answer modem, and on which you have permission to install a PCNET node (you own the computer, or the owner/administrator has authorized PCNET to be installed), we need you to adapt our existing software to run on your computer, writing the modem-interface routines if your modem is different from ours, fixing any remaining bugs we haven't tracked down yet, upgrading the program for the latest software if it hasn't been done yet, and adding code for the parts of the protocol we haven't had time to write yet; or to translate our existing software to a language you have, then proceed with fixing bugs & finishing it as above. How about investing some of your time in a network capable of connecting all the personal computers in the world (except those without modems), and many large computers, into one big network for everyone to use? If nobody volunteers, nothing gets done.  Date: 23 February 1983 15:12 EST From: Robert Elton Maas Subject: problems with this mailing list during TCP transition To: INFO-PCNET @ MIT-MC Several hosts aren't on the Arpanet, or at least can't be reached via electronic mail at present. Below is an excerpt from PCNET;PCNET DIS listing all recent deletions from the mailing list, some because the recipient's mailbox or account is gone but others merely because the Arpanet is in a funny state due to TCP. If somebody who does receive this message happens to know for a fact that some of these hosts or mailboxes really are accessible, please tell me how to reach them. ;;Temporarily deleted because host temporarily not on Arpanet ; chayashi@BBN-UNIX, ; LES@SU-AI,MRC@SU-AI,TVR@SU-AI, ; JINTACCS.WAGNER@AFSC-HQ,Pace@AFSC-SD, ; HAGAN@WHARTON,LITWA@WHARTON, ; CLAIII@MIT-MC, ;;Recently deleted because no such mailbox: ; DRUBIN.ES@PARC-MAXC,STEF@SRI-KA,JEFFH@MIT-MC,DOUCET@CMU-20C, ; UCBVAX.decvax!cwruecmp!group12@Berkeley, ; infopcnet.cornell@Udel, ;Maintained by pavel.cornell@UDel-Relay ; ETAC-SY@BBNB,medin@ucb-c70 ;;Recetly deleted because no more forwarding: ; ESVAX.Jimbo@Berkeley,  Date: 23 February 1983 15:06 EST From: Robert Elton Maas Subject: info-ized document To: INFO-PCNET @ MIT-MC I've created a new version of the PCNET introductory document (originally authored by John Gilmore) which is tree-structured for use by the INFO program here on ITS. This new file is PCNET;INTRO INFO, but you don't need to know that because it's linked into the main PCNET;PCNET INFO tree in the topic "Protocols". At present it's only a one-level indexing, and two of the sections are huge: Validation & checksumming & sequence numbers & putting packets back into sequence after out-of-sequence retransmissions -- all in one section Half-duplex turnaround & packet framing & translation -- all in one section I plan to further divide these two sections at some time. The rest of the sections are already of managable size. Anyway, it should now be possible to receive just the part of the protocol you are interested in (modulo those two oversized sections) instead of having to FTP the whole info file. Just ask for the toplevel index of the protocol document, then later after you've had a chance to look at that, ask me for the particular frames you want.  Date: 23 February 1983 12:25 EST From: Robert Elton Maas Subject: Change of name of archive To: INFO-PCNET @ MIT-MC The person who created an archive of INFO-PCNET messages called the archive file PCNET;INFO PCNET. Unfortunately, the convention for tree- structured information files is * INFO, thus when I created the tree- structured information file for PCNET I called it PCNET;PCNET INFO. The similarity of names led me to fear that I might accidently get the names backwards and clobber one file or the other with a copy of the other, or that somebody might be generally confused. I have therefore changed the name of the archive file to be PCNET;INFPCN ARCHIV. I've updated the pointer to it in the mailing list, and I'll now update the pointer in the info tree. I think that's all the pointers other than private memories.  Return-Path: Date: 21 Feb 83 11:52-EST (Mon) From: Robert (LISPer DM) Heller Subject: pcnet info (or rather the lack therof) To: info-pcnet.mit-mc@udel-relay Cc: rem.mit-mc@udel-relay Via: UMASS-CS; 21 Feb 83 19:49-EST I have been trying for the past several weeks to get enough information about the PCNET protocol to be able to design the software needed on a 68000 based workstation to set it up as a PCNET node. I have been very unsuccessfull. Part of the problem is that I am not on ARPANET proper, and thus cannot either set host to MIT-MC (where the files are), nor FTP the files to my own host. What I would like is for someone (ANYONE) to send me (via eletronic ARPANET mail to HELLER.UMASS-CS@UDEL-RELAY) low-level protocol specifications. Specificly, packet organization, checksum & encoding algorithms, etc. Also: I would be interested in specifications for the high level application programs MAIL & FTP. If & when I get a PCNET node up, I will put a message on this mailling list with full information (ie telephone number, BAUD rates, modem protocols, etc.) Thanks in advance. Robert Heller heller.umass-cs@udel-relay (ps: either our csnet mailer or the software at UDEL-RELAY is messing up the From: & Return-path: headers and the result may not work, so you should send mail to HELLER.UMASS-CS@UDEL-RELAY. RPH)  Date: 14 February 1983 21:55 EST From: Robert Elton Maas Subject: Expanding the Scope of this list (INFO-PCNET). To: RALPHW @ MIT-OZ cc: HUMAN-NETS-REQUEST @ MIT-MC, INFO-PCNET @ MIT-MC Date: 13 Feb 1983 1603-EST From: Ralph W. Hyre Jr. Subject: Expanding the Scope of this list. To: info-PCnet at MIT-MC No, I don't think the aims of PCNET (establishing protocols for error-protected transfer of data between computers, and a network based on these protocols, whereby anyone with a computer&modem can join the net by installing network software and then starting to communicate with other machines already in the net) and the aims of CBBS (establishing a large number of isolated local message systems whereby people with dumb terminals can call up to create and read messages, but with no major emphasis on creating a large network that automatically forwards messages to other nodes) are close enough to warrant having the PCNET list double as a CBBS list. Both topics are inside the general topic of HUMAN-NETS, in fact the HUMAN-NETS list was originally formed as a union of INFO-PCNET and two other lists to avoid a large number of messages that were sent to all three lists due to overlapping general interest even though many people were on two or three of the lists thus received two or three copies of messages sent to all three lists. Now (since the formation of HUMAN-NETS), INFO-PCNET is once again specifically for PCNET only, not more general topics and not other specific but non-PCNET topics. May I suggest that messages of a general CBBS-related subject be sent to HUMAN-NETS, but if these messages start to overwealm HUMAN-NETS and are of too specific a subject then a new list INFO-CBBS or somesuch could be created to handle messages of a narrow CBBS-related subject?  Date: 13 February 1983 23:22 EST From: Roger L. Long Subject: Expanding the Scope of this list. To: INFO-PCNET @ MIT-MC cc: ralphw @ MIT-OZ I would suggest you keep this list as it is: as a point of reference and discussion among the PCNET implementors. The correct forum for CBBS discussions would probably be HUMAN-NETS or INFO-MICRO. -roger  Date: 13 Feb 1983 1603-EST From: Ralph W. Hyre Jr. Subject: Expanding the Scope of this list. To: info-PCnet at MIT-MC Right now, info-pcnet is a rather narrowly-targeted list. I was wondering if we might increase its usefulness by including discussions of CBBS's in general. Many people who operate CBBS's would be interested in bringing up PCnet nodes, and this would be a good way to include them in the project. We could also provide a useful service by keeping track of the CBBS 'network' and compiling lists from time to time. - Ralph Hyre -------  Date: 4 Feb 1983 1606-EST From: Ron Subject: Re: PCNET's *present*! To: info-pcnet@MIT-MC REM has answered my question; he speaks for PCNET. The best way to learn about PCNET is probably by reading the INFO documentation at MIT-MC. It should now point to all the right places (thanks to REM). Efforts by the implementors of PCNET seem stalled right now. Here at Rutgers we're going to play with the Apple software. There might even be interest in recoding REM's MACLISP version in PASCAL, eventually. (ron) -------  Date: 24 January 1983 05:26 EST From: Robert Elton Maas Subject: 8080-asm translator To: INFO-PCNET @ MIT-MC I've just completed writing and debugging a LISP program that translates 8080 programs from CROSS assembler syntax to Microsoft assembler syntax. Test data for this program was my I/O package for PMMI & 88-2SIO, the original I wrote and the Microsoft version that Roger Long translated by hand from my version. Next to make the program go the other way, from Microsoft to CROSS. This facility will make it easier to exchange software between those of us who cross-assemble and download the binary, and those of us who download the source edit assemble-locally and upload the finished source.  Date: 22 Jan 1983 1638-PST From: JTSCHUDY at USC-ISIE Subject: MAILING LIST ADDITION To: info-pcnet at MIT-MC Hi! My name is Jim. I am presently attending the Naval Post Graduate School in Monterey California. I am in the Air Force enrolled in a DOD sponsored graduate degree in Command Control and Communications Systems Technology. i would like to be added to your mailing list. My net address is JTSCHUDY at ISIE. Thanks - Jim. -------  Date: 14 January 1983 0950-est From: Bruce J Nemnich Subject: Re: PCNET's future To: Robert Heller CC: info-pcnet @ MIT-MC I also have a Wicat 150, but is is currently in disrepair. I eventually intend to have it fixed, after which I also would like to put it up as a PCNET node (I would like to have one "big" node surrounded by several "little" nodes (e.g., Apples)). -bjn  Return-Path: Date: 13 Jan 83 09:34-EST (Thu) From: Robert (LISPer DM) Heller Subject: PCNET's future To: Bruce J Nemnich Cc: info-pcnet@mit-mc, rem@mit-mc Via: UMASS-COINS; 13 Jan 83 20:14-EST Bruce: I have volunteered to setup a PCNET node here in western mass., but don't have a copy of the protocol specs., (nor a machine yet). As soon as I get some specs. (I sent mail to Robert Elton Mass last december - am still waiting for a reply (may have gotten it today, but the disk where my mail file is down...so i don't know)). My partner, Ephriam Robbins & I are getting a 68000 based workstation soon - we are investigating WICAT's 150-1 system. robert heller heller.umass-coins@udel-relay  Date: 13 Jan 1983 1440-EST From: Ron Subject: Re: PCNET's future?! PCNET's *present*! To: info-pcnet@MIT-MC In-Reply-To: Your message of 12-Jan-83 0040-EST I don't much worry about PCNET'S future as I can't find any people working on it right now! A group of people at Rutgers were interested in using PCNET as a basis for a network of micros and our Dec-20s. However because we never received any word from the "implementors" of PCNET we had to drop it and go another route. [We sent 7 blanks disks to a fellow in California who supposedly was to copy the current PCNET sources onto them, we never got the disks back or heard from this person again]. When last I inquired about PCNET I was pointed to a file on MC that contained what amounted to an advertising blurb, no content and all promises. What is really going on? Is there really any software at all out there written for PCNET? Or is it just an empty acronym? A well coordinated and *communicative* voluteer effort can accomplish wonders (and this one very well may have). But who speaks for PCNET? (ron) -------  Date: 12 January 1983 0040-est From: Bruce J Nemnich Subject: PCNET's future To: info-pcnet @ MIT-MC What are the latest plans for the future of PCNET? I only recently learned about it, and I really like its concepts and would like to see it happen. However, for it to happen, it must be developed and marketed soon: before another (lesser) protocol catches the fancy of the masses. I doubt we are very far from a big demand for voice-line device- independent data-communications system. As soon as one fills the market, it is likely to become "standard." The volunteer effort seems to lack the effort required to accomplish all it needs to in a reasonable time; I certainly cannot complain (I just joined the group), but it seems to be progressing rather slowly, based on what I have read in various archives. What are the (realistic) expectations? How do people feel about throwing this into high (read "commercial") gear? What is the status of the rights to PCNET? I am eager to learn how y'all feel. --bjn  Date: 25 December 1982 17:27-EST From: Robert Elton Maas Subject: Temporary demise of this mailing list To: INFO-PCNET @ MIT-MC Due to NCP-->TCP switchover and lack of working TCP software at MIT-MC (KLH is working hard at it and might get it done in time, in which case this part of this message will be inoperative), this mailing list will probably cease to exist temporarily starting Jan 01. Because of lack of working TCP software at SU-AI and other places, even if MIT-MC has TCP working, many of us active PCNET workers will be inactive until these other places get TCP working. I have decided this is a good time to summarize current work on PCNET. As far as I know the only active work currently is Fylstra.tsca@SRI-UNIX fixing up the C software and G.Harris@SU-SCORE fixing up the documentation. Perhaps early next year we'll be able to announce these two tasks done. As far as I know, there doesn't currently exist even one (1) full PCNET node up and running with current protocol and available for people to call into to test new software they are developing. Various partial implementations on micros are around, but don't conform yet to current protocol specs. The node at MIT-MC does conform, but can't dial out and will be down due to TCP switchover, and it requires a login to use. Perhaps next year we'll finally have a small network of genuine PCNET nodes all available for anyone to call into and all conforming to current protocol specs. A file at MIT-MC that I send out to new members of this mailing list has a little more info about work on PCNET in recent months, but there's nothing much exciting in it so look at it if you feel like it. PCNET;VOLUN MSG So, Happy New Year. The last year before 1984!  Mail-from: SU-NET host Shasta rcvd at 1-Dec-82 2047-PST Date: Wednesday, 1 Dec 1982 20:46-PST To: William "Chops" Westfield Cc: info-pcnet at MC Subject: Re: big trouble... In-reply-to: Your message of 1 Dec 1982 1719-PST. <[SRI-KL] 1-Dec-82 17:19:51.BILLW> From: Brian Reid My understanding of trademark law (I am not a lawyer, and don't even look like one....) is that "to trademark" is not an active verb. One can file for trademarks, and one can claim ownership of trademarks, and some trademarks are "clear" while others are "limited". It is worth investigating, but I think that prior use of the term PCnet in print is pretty good claim to be able to use the term. Trademark law is complicated, and I would never pretend to claim that I know the truth, but I would bet we can keep on calling it PCnet, and maybe even prevent them from calling theirs PCnet. Send a note to Info-Law explaining the problem (briefly) and see if anybody there can enlighten.  Date: 1 December 1982 23:42-EST From: Frank J. Wancho Subject: big trouble... To: BillW at SRI-KL cc: INFO-PCNET at MIT-MC It is a very simple matter to challenge their trademark, BUT, SOMEONE *MUST* make that challenge *SOON*. I had already pointed this problem out to REM early last month, when a New Product item appeared in InfoWORLD. More likely than not, the company simply indicated/assumed trademark right to the name, unless they actually are in the process of registering it - there is a difference! If they didn't use the word "registered", then you can be certain it isn't, and by law, they cannot say "registered" until it is. If so, then it is even easier to challenge, since you cannot assume a trademark for a name of something already in existence - and that can be shown from the published material in DDJ. So, someone from PCC ought to send a letter and copies of the articles to the Office of Patents and Trademarks, with a copy to Orchid Technology, challenging the use of the name, and requesting them to crease-and-desist. Competent legal counsel should be secured to draft the exact wording of such correspondence, which should also point out the potential confusion of such closely related products - a key point in the challenge. Find a patent attorney who happens to personally own a micro...and have that attorney send the documents under his letterhead. --Frank  Date: 1 Dec 1982 1719-PST Sender: BILLW at SRI-KL Subject: big trouble... From: William "Chops" Westfield To: info-pcnet at MC Message-ID: <[SRI-KL] 1-Dec-82 17:19:51.BILLW> A company called Orchid technology showed a system called PCNet at CMDEX. Its a local area network for IBM Personal Computers. They trademarked PCNet.... Anybody have a different name ? BillW  Date: 17 November 1982 20:35-EST From: Robert Elton Maas To: INFO-PCNET at MIT-MC Somebody sent me a message with the return address JENSON.NCA at MIT-MC. There's no such mailbox, so COMSAT returned my message undelivered. Will the sender of that message please identify self to me so I can get the message thru?  Date: 17 November 1982 02:21-EST From: Robert Elton Maas Subject: test message and summary of recent work To: INFO-PCNET at MIT-MC This message is to verify the INFO-PCNET mailing list is up to date, and to summarize what's been going on lately. This list now has over 150 mailboxes, except that a few of them are really bulletin boards on USENET or CSNET which are each read by more than one individual. Dave Fylstra has been working on the C version of PCNET, adapting it to BDS C and to Unix, and upgrading the software towards the latest protocols. He's also proofread the latest draft of the main protocol document and is helping finish the protocol for the FTP and MAIL "application programs". David Harris has been working on the protocol document. He also loaned me an Apple so I could check out the 6502-asm/Apple-BASIC implementation of PCNET. I've been upgrading the LISP version of the PCNET program, maintaining the mailing list, corresponding with members, and am now working on finishing the FTP/MAIL protocol. Danielson supplied us with critical information about the SDLC CRC algorithm so that binary mode could be implemented. Mead installed my 8080/Z80 assembly-language program on his computer in Pasadena. Harry Chesley, Frank Wancho and Gail Zacharias are helping finish the FTP/MAIL protocol. We still don't have even one complete test node up and available with ECHO, MAIL1 and FTP1 services via the current PCNET protocol, although I hope to get my LISP program in that state soon by installing FTP1 (it now does ECHO and MAIL1, and does conform to the current protocol as far as I can tell with no other node to test it against). If anybody knows of any other recent PCNET work, please tell me so I can update this listing.  Date: 11 November 1982 21:43-EST From: Phillip C. Reed To: INFO-PCNET at MIT-MC Hi there. I've been trying to get some definitive technical information on PCNet for some time now. I wrote a letter to the address in an old Dr. Dobb's Journal, but there was no response, and it has been a month now. How can I find out the status of the PCNET Project, info on node requirements, protocols, etc, etc? (I'd be interested in exploring the possibility of setting up a note.) Is there an active address to get information? (I'm not on the mailing list, so reply directly please.) ...phil  Date: 28 Oct 1982 2018-EDT From: GREENFIELD at DEC-MARLBORO Subject: mailing list addition To: info-pcnet at MIT-MC Please add me to the INFO-PCNET interest list. Thank you very much! Mike -------  Date: 12 Oct 1982 1237-PDT From: Dick Subject: PCNET for APPLE II To: info-pcnet at MIT-MC if anyone has the software available, and is willing to let me copy it, please let me know. -------  Date: 12 October 1982 03:46-EDT From: Robert Elton Maas Subject: Another test node available, in LA area To: INFO-PCNET at MIT-MC A couple weeks ago I came across a new PCNET interested person who happened to have a PMMI modem like mine and for local I/O a SIO board very much like my 88-2SIO board, in fact functionally identical as far as we can tell. We tried relocating my serial I/O package, called IO1, for his memory arrangement, cross-assembling it, and downloading, and it worked (with a little test program). Next we tried relocating my PCNET protocol program, called PCN80B, and tonight we did the first live test of it with me calling his node from my home. It too seems to work!! Thus I think we can now say that my 8080/Z80 PCNET program (PCN80B) is now up and running in Pasadena. Now the question for you-all: does anybody else presently have any PCNET program up and running on a personal computer (not an Arpanet host such as MIT-MC where my LISP PCNET program has been up and running for many months now), so that this guy in Pasadena can exchange a few test messages with another personal computer using PCNET protocol? If we can get say 3 nodes up at the same time we might be able to say we really have a network, i.e. that the Personal Computer Network really exists now! On a related matter, protocol upgrades 3 and 4 still need to be done in this program (PCN80B). My Altair has been down with power-supply problems for several months, I might get off my duff and get it fixed now that I have motivation, but meanwhile is there anyone willing to translate the code in my LISP program related to protocol upgrades 3 and 4 to 8080/Z80 code (I might do that myself), or write new code from scratch from the specs in the protocol document, and then debug it (I can't do that without a working machine)? It would be nice if this small finishing touch could be done soon so that we could say the test node in Pasadena really implements the current (correct) PCNET protocol. All we need essentially is one function to create validated (numbered and checksummed etc.) blocks for transmitting, and another function to check the validation on blocks that have been received. It's complicated in the new protocol because the length is implicit, and because in Radix-41 there might be a zero byte that has to be dropped to make the length correct (look at the LISP code or read the documention for details).  Date: 3 Oct 1982 1211-PDT From: Dick Subject: Info & sources To: info-pcnet at MIT-MC Being unfamiliar with the PCNET setup, would someone briefly tell me what is available for Z80 S100 systems/Apple II systems and what is needed to implement it? I currently run a CBBS/RCPM system in So. Cal. (Pasadena 213-799-1632) and wonder whether the PCNET system can co-exist if, for instance, it can run under MP/M. I have read INTRO, SOURCE INDEX, but gained little. Thanks for any help.... -------  Date: 16 September 1982 03:15-EDT From: Robert Elton Maas Subject: Improvement in LISP PCNET program, and urgent CRC query To: INFO-PCNET at MIT-MC (1) I've added a new debug feature to PCNSR6 (my LISP program for PCNET protocol). If G:STUB:HEX is on, all normal (protocol) input/output passes thru hexadecimal conversion. On input, you type two hexadecimal characters, which echo, then it echoes a space so you can see the bytes clearly. The 8-bit byte represented by the two characters is passed to the protocol, thus you can emulate mark and space parity without having a META key on your terminal. On output, the program converts each 8-bit byte of output into two hexadecimal characters followed by a comma. Thus you can see exactly what the protocol is generating even if your terminal doesn't display the parity bit (for example by an alternate characterset). By using space for input and comma for output, it's easy by looking at a transcript to see what was input and what was output. (Of course the commas can be edited to spaces after incorporating the transcript into a document, but having them commas initially makes it easier to avoid confusing input and output when preparing the document.) This mode isn't too useful when using Radix-41, but will make it possible to develop 8-bit protocol. (2) Does anybody out there in PCNET land understand CRC (in particular the SDLC version, which claims to use X^(16,12,5,1) as the polynomial, initial value FFFF hexadecimal, complement of CRC transmitted MSB first, and hexadecimal F0B8 result upon receipt if two CRC bytes included in CRC accumulation)? I have tried to implement SDLC CRC here from basic principles, but I don't get F0B8 an I have no idea why not. The only claimed-correct algorithm available is a 6800 assembly language program which doesn't make sense at all to me. I need this info to correctly implement 8-bit PCNET protocol. All CRC experts, please speak up now!  Date: 6 September 1982 23:38-EDT From: Robert Elton Maas Subject: test, and improvements in PCNSR6 To: INFO-PCNET at MIT-MC This is to test the recent changes to the INFO-PCNET mailing list to see if they're ok. Also, today I added a new feature to PCNSR6, the MacLISP implementation of PCNET. Now it's possible to open a PREAD/PWRITE level transcript, so that every call to PREAD or PWRITE will leave an entry in the transcript. This is very useful for preparing documentation of the higher levels of protocol (i.e. application programs such as ECHO and MAIL1, the node-control program). I have used this feature to prepare test data showing how to use the ECHO and MAIL1 programs. Anyone wanting these annotated transcripts may request them from me. Beware, if you don't understand PCNET protocol in general, these transcripts won't be very meaninglful, but if you're trying to create or debug your PCNET software and you've finished the lower levels and are working on the server (application program) level, they could be quite useful. As usual, requests to be added or deleted should go to INFO-PCNET-REQUEST at MIT-MC, not to the whole INFO-PCNET mailing list.  HNIJ@MIT-AI 08/09/82 18:25:43 To: info-pcnet at MIT-MC please add me to your mailing list. thanx. john.  Date: 20 July 1982 18:40-EDT From: Robert Elton Maas Subject: Errata in protocol document To: INFO-PCNET at MIT-MC Those of you who have already obtained a copy of PCNET;INTRO > should be aware of some character-translation errors which have just today been discovered by a careful reader. Please make these changes in your copy and then check the result to be sure there are no remaining errors. Those who haven't previously obtained a private copy of PCNET;INTRO > may ignore this message since the master file has now been corrected. ;COMPARISON OF DSK:PCNET;INTRO 6 AND DSK:PCNET;INTRO 7 ;OPTIONS ARE /3 **** FILE DSK:PCNET;INTRO 6, 7-23 (43060) C0 240 @ +top Start/end of block; *turnaround ack DB 333 [ +top *The originate node has finished sending DD 335 ] +top *The answer node has finished sending 82 202 DLE+top The next character is encoded data 82 40 202 040 DLE+top @ The data character C0/240/@+top 82 5B 202 133 DLE+top [ *The data character DB/333/[+top from orig 82 5D 202 135 DLE+top ] *The data character DD/335/]+top from ans 82 02 202 002 DLE+top DLE The data character 82/202/DLE+top **** FILE DSK:PCNET;INTRO 7, 7-23 (43060) C0 300 @ +top Start/end of block; *turnaround ack DB 333 [ +top *The originate node has finished sending DD 335 ] +top *The answer node has finished sending 90 220 DLE+top The next character is encoded data 90 40 220 100 DLE+top @ The data character C0/240/@+top 90 5B 220 133 DLE+top [ *The data character DB/333/[+top from orig 90 5D 220 135 DLE+top ] *The data character DD/335/]+top from ans 90 10 220 020 DLE+top DLE The data character 82/202/DLE+top *************** If you aren't familar with SRCCOM output, the first section above, headered by "INTRO 6" is the old (bad) table while the second section, headered by "INTRO 7" is the new (hopefully good) table.  Date: 6 Jul 1982 2323-PDT From: Zellich at OFFICE-3 (Rich Zellich) Subject: Mailing-list for "List of lists" update notices To: All mailing-lists: cc: ZELLICH For those of you not previously aware of it, I maintain a master list of ARPANET mailing-lists/digests/discussion groups (currently 756 lines or ~29,000 characters) on OFFICE-3 in file: INTEREST-GROUPS.TXT For ARPANET users, OFFICE-3 supports the net-standard ANONYMOUS login within FTP, with any password. To keep people up to date on the large number of such lists, I have established a mailing list for list-of-lists \update notices/. I do not propose to send copies of the list itself to the world at large, but for those ARPANET users who seriously intend to FTP the updated versions when updated, I will send a brief notice that a new version is available. For those counterparts at internet sites who maintain or redistribute copies for their own networks (DECNet, Xerox, etc.) and can't reach the master by ARPANET FTP, I will send out the complete new file. I do \not/ intend to send file copies to individual users, either ARPANET or internet; our system is fairly heavily loaded, and we can't afford it. There is no particular pattern to the update frequency of INTEREST- GROUPS.TXT; I will occasionally receive a burst of new mailing-lists or perhaps a single change of address for a host or mailing-list coordinator, and then have a long period with no changes. To get on the list, send requests to ZELLICH@OFFICE-3, \not/ to the mailing-list this message appears in. Cheers, Rich -------  Date: 2 July 1982 22:31-EDT From: Steven E. Hillson Subject: Disk drives, and expansion boxes (Medium length message) To: INFO-MICROS at MIT-MC cc: INFO-PCNET at MIT-MC, H19-PEOPLE at MIT-MC Greetings. I would like to install a disk drive into my H88. I would rather install the Soft-sectored double density floppy controller and the single sided floppy drive. My Heathkit friend insists that I have to first install the hard-sectored single-density controller. (Note, these are to be installed, so that my H88 becomes a H89) I am currently using their cassette operating system, which bytes (groan). I am thinking of switching to disk, but would like to get the most memory for my money. Also, I would appreciate any remarks about CP/M, HDOS, CP/NET, and TurboDOS. At the moment TurboDOS seems to be the best bet. One more thing: While reading my Byte, I came across this ad: H89/Z89 USER The M89 is an I/O expansion box for the H89/Z89 computer, please call or write us for more details. MicroFlash Co. 4916 B Carol St. Skokie, Ill. 60077 (312) 677-4928 Has anyone heard of such a thing, or anything about it? Sounds good, especially since the H89 has *so* little room for expansion. If anyone knows anything about the above 3 questions, PLEASE reply. Your comments are *MOST* welcome. Thanks in advance, -Steve Hillson  Date: 1 July 1982 16:08 cdt From: VaughanW at HI-Multics (Bill Vaughan) Subject: Call for Abstracts Sender: VaughanW.REFLECS at HI-Multics To: HUMAN-NETS at SU-SCORE cc: info-pcnet at MIT-MC CALL FOR ABSTRACTS (Abridged) 2d Annual Phoenix Conf. on Computers & Communication March 14-16, 1983 ------------ Sponsored by IEEE, IEEE Computer and Communications Societies, and IEEE Phoenix Section. Topics appropriate for this conference include: COMPUTER SYSTEM ARCHITECTURE Multiprocessing, functional distribution; performance prediction/analysis; computer/communication networks; architectures taking advantage of new technology RAS (RELIABILITY/AVAILABILITY/SERVICEABILITY) Systems/hardware/software testing methods, failure analysis, life testing COMPUTER AIDED PROCESSES CAD: tools for S/W development; applications in electrical, mechanical, robot design; CAM flexible automation; CIM (computer integrated manufacturing); pattern recognition, resource planning; CAT (computer aided testing), auto. test program generation; S/W testability, test equipment SOFTWARE FOR DISTRIBUTED SYSTEMS Data base; operating systems; high-level language support; debugging and testing; decentralized control structure and protocols INTEGRATED CIRCUITS AND DEVICES Silicon/compound semiconductors; VLSI/VHSIC; micro/supercomputers; radar, ECM/ESM;novel circuits and devices; direct satellite communications SOFTWARE DEVELOPMENT AND DELIVERY All phases of S/W life cycle; real time and other systems; technical and managerial aspects; tools, measures, methodologies; languages; validation, verification; field support, enhancement; documentation THE HUMAN ELEMENT Ease of use; man/machine communications; psychology, human factors; education and training; the effect on people/organizations/society of networking, personal computers, electronic mail/meetings Authors with papers on related topics are also encouraged to submit abstracts. Papers covering innovative ideas in related areas are especially welcome. Please include authors' names, return address, telephone number on the abstract. Note these important dates: September 15: Abstract (300 words) due October 11: Completed papers due December 1: Notification of acceptance January 10: Camera-ready manuscript due Send abstract and other correspondence to Gerald Fetterer, GTE Automatic Electric Labs, 2500 W. Utopia, Phoenix AZ 85027. ---------------- (Or send to VaughanW at HI-Multics and I will make sure it gets to Gerry.)  Date: 16 April 1982 05:47-EST From: Robert Elton Maas Subject: 6809 code available To: INFO-PCNET at MIT-MC Some students have implemented PCNET on a 6809 using assembly language. Unfortunately they had to get back to their studies before they had time to test the program against existing implementations to verify their implementation really worked correctly, nor to clean up the modem interface. Is there anyone on this list who has a 6809 and is willing to install this code (source online at MIT-MC now) and give it a full test, and maybe even fix bugs that are found? Note that 6502, 6800 and 6809 are all different machines that use a similar but not identical instruction set. This 6809 code was translated from our 6502 code. We don't presently have a 6800 implementation.  Date: 15 Apr 1982 21:41:27-EST From: bucky at CCA-UNIX (Bennett Marks) To: info-pcnet at mit-mc Subject: Mailing list Please include me on the pcnet mailing list. Thank you, Bucky@cca-vax  Date: 6 Apr 1982 21:39:49-PST From: jef at LBL-UNIX (Jef Poskanzer [rtsg]) To: info-pcnet-request at mit-mc, info-pcnet at MIT-MC Cc: jef at LBL-UNIX Please add me to this list. I am considering implementing PCNET in the Software Tools environment. We have two Modcomps and a VAX, all running the tools. Currently transferring files is done via magtape, which is a pain. Questions: - What implementations currently exist or are being written? - Approximately what level of effort is involved in a full implementation? - How amenable is PCNET to partial implementation? - Is there any documentation I should look at besides MC:PCNET;INTRO >? Thank you. (Note: if anyone answers these questions on the list, please cc: me to avoid a race condition.) --- Jef