Received: from IBM.COM (TCP 30001235007) by AI.AI.MIT.EDU 3 Aug 88 19:58:24 EDT Date: 3 Aug 88 16:54:00 PDT From: Michael Tharenos To: Info-PCNet-Request@AI.AI.MIT.EDU Message-Id: <080388.165418.interest@ibm.com> Subject: Distribution List Addition Could you please add Interest_Group_Server@ibm.COM to your distribution list? It acts as a single point of contact for all of IBM. This helps to reduce network traffic. Questions and administrative concerns should be directed to postmaster@ibm.com. Thank you for your support, Mike Michael Tharenos Networking Support and Development IBM, Almaden Research Center 408-927-2727  Received: from njitc.njit.edu (TCP 20072600401) by AI.AI.MIT.EDU 17 Aug 88 14:01:48 EDT Date: 17 Aug 88 13:45:00 EST From: "NJITX::HXN8477" Subject: addition request To: "info-pcnet-request" cc: hxn8477 Reply-To: "NJITX::HXN8477" Hello, I would appreciate it if you could put me on your mailing list . I am a PhD candidate at the New Jersey Institute of Technology and with interests in computers and communications. Hamed Nassar Internet: hxn8477%njitx.decnet@njitc.njit.edu ------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Aug 88 19:48:49 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 24 Aug 88 19:41:36 EDT Date: Wed, 24 Aug 88 19:40:16 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Wed, 24 Aug 88 19:40:14 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 4109 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 4109 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4109; Wed, 24 Aug 88 19:40:05 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 24 Aug 88 19:40:01 EDT 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 ---------------------------------------------------------------------- , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Aug 88 19:50:44 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 24 Aug 88 19:49:22 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Wed, 24 Aug 88 19:49 EDT Date: Wed, 24 Aug 88 19:48 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Wed, 24 Aug 88 19:47 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 4122 for 000544@PITTVMS; Wed, 24 Aug 88 19:47 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4109; Wed, 24 Aug 88 19:40:05 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 24 Aug 88 19:40:01 EDT 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@vb.cc.cmu.edu Subject: EMPLOYMENT OPPORTUNITY: PC's for Education. Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: EE/CS Dept. U.C. San Diego Message-Id: <5247@sdcsvax.UCSD.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 24 Aug 88 20:20:49 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Aug 88 20:16:38 EDT Date: Wed, 24 Aug 88 20:17:24 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 August 1988 19:29-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <432423.880824@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 24 Aug 88 20:44:54 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Aug 88 20:26:32 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Aug 88 20:20:59 EDT Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 24 Aug 88 20:17:11 EDT Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA21880; Wed, 24 Aug 88 20:16:08 EDT Date: Wed, 24 Aug 88 20:16:08 EDT From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8808250016.AA21880@rutgers.edu> To: <@mc.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 hobbit@gold.rutgers.edu... Host unknown ----- Unsent message follows ----- Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA21875; Wed, 24 Aug 88 20:16:08 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Aug 88 20:15:43 EDT 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@steinmetz.ge.com (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 24 Aug 88 21:15:20 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 24 Aug 88 21:13:38 EDT Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 24 Aug 88 21:14:19 EDT Received: from VLSI.JPL.NASA.GOV (INTERNET|128.149.16.4) by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 131132; 24 Aug 88 21:12:15 EDT Date: Wed, 24 Aug 88 18:09:55 PDT From: Delivr@VLSI.JPL.NASA.GOV Subject: Undeliverable Mail To: info-pcnet-request%mc.lcs.mit.edu%MC.LCS.MIT.EDU%AI.AI.MIT.EDU@VLSI.JPL.NASA.GOV Comment: reason for return -- Comment: %MAIL-E-SYNTAX, error parsing 'LYMAN@JATO.JPL.NASA.GOV' Comment: the affected addresses follow ... Comment: LYMAN Start of returned message Received: from AI.AI.MIT.EDU by VLSI.JPL.NASA.GOV with INTERNET ; Wed, 24 Aug 88 18:01:31 PDT 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 ---------------------------------------------------------------------- End of returned message  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Aug 88 21:32:35 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 24 Aug 88 21:30:56 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Wed, 24 Aug 88 21:30 EDT Date: Wed, 24 Aug 88 19:48 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Wed, 24 Aug 88 19:48 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 4123 for 334641@PITTVMS; Wed, 24 Aug 88 19:48 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4109; Wed, 24 Aug 88 19:40:05 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 24 Aug 88 19:40:01 EDT 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@vb.cc.cmu.edu Subject: EMPLOYMENT OPPORTUNITY: PC's for Education. Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: EE/CS Dept. U.C. San Diego Message-Id: <5247@sdcsvax.UCSD.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 25 Aug 88 00:25:32 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 24 Aug 88 23:55:58 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5029; Wed, 24 Aug 88 23:54:23 EDT Received: from TEMPLEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5028; Wed, 24 Aug 88 23:54:22 EDT Received: from TEMPLEVM.BITNET by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 5460; Wed, 24 Aug 88 23:52:29 EDT Date: Wed, 24 Aug 88 23:52:28 EDT From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 TEMPLEVM.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 TEMPLEVM.BITNET Hello MITVMA.MIT.EDU 050 TICK 4109 250 4109 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: V5041E 050 QUIT 221 TEMPLEVM.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 5459; Wed, 24 Aug 88 23:52:28 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4109; Wed, 24 Aug 88 19:40:05 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 24 Aug 88 19:40:01 EDT 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 25 Aug 88 00:27:07 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Aug 88 00:01:42 EDT Received: from buzzard.LCS.MIT.EDU (THEORY.LCS.MIT.EDU) by XX.LCS.MIT.EDU with TCP/SMTP; Thu 25 Aug 88 00:01:06-EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00557; Thu, 25 Aug 88 00:00:21 EDT Date: Thu, 25 Aug 88 00:00:21 EDT From: MAILER-DAEMON@buzzard.LCS.MIT.EDU (Mail Delivery Subsystem) Subject: Returned mail: Service unavailable Message-Id: <8808250400.AA00557@buzzard.LCS.MIT.EDU> To: <@xx.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- >>> DATA <<< 554 sendall: too many hops (17 max) 554 ... Service unavailable: Bad file number ----- Unsent message follows ----- Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00555; Thu, 25 Aug 88 00:00:21 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00547; Thu, 25 Aug 88 00:00:12 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00542; Thu, 25 Aug 88 00:00:02 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00534; Wed, 24 Aug 88 23:59:53 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00524; Wed, 24 Aug 88 23:59:42 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00515; Wed, 24 Aug 88 23:59:25 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00502; Wed, 24 Aug 88 23:59:12 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00490; Wed, 24 Aug 88 23:58:55 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00478; Wed, 24 Aug 88 23:58:43 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00467; Wed, 24 Aug 88 23:58:28 EDT Received: from THEORY.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00443; Wed, 24 Aug 88 23:58:03 EDT Received: from XX.LCS.MIT.EDU by buzzard.LCS.MIT.EDU via TCP with SMTP id AA00430; Wed, 24 Aug 88 23:57:49 EDT Received: from AI.AI.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Wed 24 Aug 88 20:15:11-EDT 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 27 Aug 88 18:31:48 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Aug 88 18:29:29 EDT Date: Sat, 27 Aug 88 18:30:36 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 August 1988 19:29-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <433688.880827@AI.AI.MIT.EDU> FAILED: W8SDZ at SIMTEL20.ARPA; Host appears to be permanently down or not accepting mail. FAILED: WANCHO at SIMTEL20.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 27 Aug 88 18:35:40 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Aug 88 18:33:44 EDT Date: Sat, 27 Aug 88 18:34:51 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 August 1988 19:29-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <433691.880827@AI.AI.MIT.EDU> FAILED: mjolsnes%vax.elab.unit.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: s_helmersen%use.uio.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: yngvar at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 27 Aug 88 18:35:53 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Aug 88 18:34:26 EDT Date: Sat, 27 Aug 88 18:35:31 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 August 1988 19:29-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <433692.880827@AI.AI.MIT.EDU> FAILED: gran!jan at NTA-ODIN.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 27 Aug 88 18:36:38 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 27 Aug 88 18:35:16 EDT Date: Sat, 27 Aug 88 18:36:23 EDT From: Communications Satellite Subject: Msg of Wednesday, 24 August 1988 19:29-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <433695.880827@AI.AI.MIT.EDU> FAILED: J.Bunch at UACSC1.ALBANY.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 29 Aug 88 13:47:55 EDT Received: from rice.edu (TCP 20012402401) by MC.LCS.MIT.EDU 29 Aug 88 13:45:55 EDT Received: from kappa.rice.edu by rice.edu (AA01551); Mon, 29 Aug 88 12:44:20 CDT Received: by kappa.rice.edu (AA06642); Mon, 29 Aug 88 11:46:51 CDT Date: Mon, 29 Aug 88 11:46:51 CDT From: Richard Murphey Message-Id: <8808291646.AA06642@kappa.rice.edu> To: INFO-PCNET-REQUEST@mc.lcs.mit.edu Subject: Subscribe Organization: Electrical and Computer Engineering, Rice University Dear Moderator, Please add me to your mailing list. My arpanet address is `rich@rice.edu'. thanks, rich Richard Murphey (713) 527-8101 X3649 ECE Rice U Box1892 Hou,TX 77251-1892 rich@rice.edu (standard disclaimer)  Received: from relay.ubc.ca (TCP 20057260451) by AI.AI.MIT.EDU 30 Aug 88 16:06:22 EDT Received: by relay.ubc.ca (5.59/1.14) id AA19521; Mon, 29 Aug 88 23:54:49 PDT Date: 29 Aug 88 23:33 -0700 From: List Master To: List Maintainer Message-Id: Subject: Change of Mailbox Entry You currently have an address such as info-pcnet%UBC.CSNET@RELAY.CS.NET on your distribution list. The relay.cs.net machine is no longer forwarding mail addressed with the ubc.csnet bit. You probably received an error message back if you sent something in the past few days. You can replace the above mailbox with info-pcnet@relay.ubc.ca If it is not too much trouble, could you please resend any undelivered mail. You may send a message to me if you have any questions. Thank you very much for your help and take care, Marilyn Martin CDNnet Headquarters, Listmaster  Received: from afotec2 (TCP 3202600060) by AI.AI.MIT.EDU 2 Sep 88 16:04:08 EDT Date: 2 Sep 88 13:57:00 MDT From: "VAX3::LEYBAEE" Subject: NEW SUBSCRIBER To: "info-pcnet-request" Please add my name to your INFO-PCNET interest group. tnx's.....LEYBAEE@AFOTEC2.ARPA  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Sep 88 20:52:26 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 2 Sep 88 20:36:43 EDT Date: Fri, 02 Sep 88 20:34:42 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Fri, 02 Sep 88 20:34:41 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 8309 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 8309 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8309; Fri, 02 Sep 88 20:34:32 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 Sep 88 20:34:28 EDT 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 , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Sep 88 20:52:45 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 2 Sep 88 20:45:12 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 8410; Fri, 02 Sep 88 20:40:33 EDT Received: from TEMPLEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8409; Fri, 02 Sep 88 20:40:16 EDT Received: from TEMPLEVM.BITNET by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 1962; Fri, 02 Sep 88 20:37:18 EDT Date: Fri, 02 Sep 88 20:37:17 EDT From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 TEMPLEVM.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 TEMPLEVM.BITNET Hello MITVMA.MIT.EDU 050 TICK 8309 250 8309 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: V5041E 050 QUIT 221 TEMPLEVM.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 1961; Fri, 02 Sep 88 20:37:17 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8309; Fri, 02 Sep 88 20:34:32 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 Sep 88 20:34:28 EDT 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 2 Sep 88 21:10:41 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 2 Sep 88 21:05:14 EDT Date: Fri, 2 Sep 88 21:07:00 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <436946.880902@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 2 Sep 88 21:14:42 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 2 Sep 88 21:11:38 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 2 Sep 88 21:12:25 EDT Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 2 Sep 88 21:06:31 EDT Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA04945; Fri, 2 Sep 88 21:05:00 EDT Date: Fri, 2 Sep 88 21:05:00 EDT From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8809030105.AA04945@rutgers.edu> To: <@mc.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 hobbit@gold.rutgers.edu... Host unknown ----- Unsent message follows ----- Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA04942; Fri, 2 Sep 88 21:05:00 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 2 Sep 88 21:04:29 EDT 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: exunido!edelhoff@unido.de (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 5 Sep 88 16:10:53 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 88 15:56:56 EDT Date: Mon, 5 Sep 88 15:59:07 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <437720.880905@AI.AI.MIT.EDU> FAILED: august at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: GIL at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: LYMAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: TUAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 5 Sep 88 16:11:14 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 88 15:59:06 EDT Date: Mon, 5 Sep 88 16:01:20 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <437723.880905@AI.AI.MIT.EDU> FAILED: incoming-info-pcnet at COLUMBIA.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 5 Sep 88 16:11:42 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 88 16:00:03 EDT Date: Mon, 5 Sep 88 16:02:16 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <437725.880905@AI.AI.MIT.EDU> FAILED: mjolsnes%vax.elab.unit.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: s_helmersen%use.uio.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: yngvar at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 5 Sep 88 16:12:07 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 88 16:01:29 EDT Date: Mon, 5 Sep 88 16:03:43 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <437727.880905@AI.AI.MIT.EDU> FAILED: gran!jan at NTA-ODIN.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 5 Sep 88 16:12:37 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Sep 88 16:02:26 EDT Date: Mon, 5 Sep 88 16:04:36 EDT From: Communications Satellite Subject: Msg of Friday, 2 September 1988 20:24-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <437729.880905@AI.AI.MIT.EDU> FAILED: J.Bunch at UACSC1.ALBANY.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 6 Sep 88 13:39:10 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 6 Sep 88 13:10:52 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Tue, 6 Sep 88 13:09 EDT Date: Fri, 2 Sep 88 20:38 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Fri, 2 Sep 88 20:37 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 8319 for 000544@PITTVMS; Fri, 2 Sep 88 20:37 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8309; Fri, 02 Sep 88 20:34:32 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 Sep 88 20:34:28 EDT 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@vb.cc.cmu.edu Subject: Call for discussion: PC-Network Operating System Comparison Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: University of Dortmund, W-Germany Message-Id: <576@laura.UUCP> 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 6 Sep 88 13:40:00 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 6 Sep 88 13:12:09 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Tue, 6 Sep 88 13:10 EDT Date: Fri, 2 Sep 88 20:38 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Fri, 2 Sep 88 20:38 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 8321 for 334641@PITTVMS; Fri, 2 Sep 88 20:37 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 8309; Fri, 02 Sep 88 20:34:32 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Fri, 02 Sep 88 20:34:28 EDT 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@vb.cc.cmu.edu Subject: Call for discussion: PC-Network Operating System Comparison Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: University of Dortmund, W-Germany Message-Id: <576@laura.UUCP> 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 relay.ubc.ca (TCP 20057260451) by AI.AI.MIT.EDU 7 Sep 88 17:38:17 EDT Received: by relay.ubc.ca (5.59/1.14) id AA22624; Wed, 7 Sep 88 14:33:44 PDT Date: 7 Sep 88 14:09 -0700 From: List Master To: List Maintainer Message-Id: Subject: Change of Mailbox Entry - Resend You probably saw this message earlier but I have not received any response or seen any mail with the new address. Would you please reply to this message, especially if you have any questions. You currently have an address such as info-pcnet%UBC.CSNET@RELAY.CS.NET or, with a UBC.CDN or UBC.CA part, on your distribution list. You probably received an error message a while back on the address and may have deleted it from your list. You can replace the above mailbox with info-pcnet@relay.ubc.ca Thank you very much for your help and take care, Marilyn Martin CDNnet Headquarters, Listmaster  Received: from nems.ARPA (TCP 3205400121) by AI.AI.MIT.EDU 8 Sep 88 14:00:48 EDT Received: by nems.ARPA id AA01158; Thu, 8 Sep 88 13:55:58 edt Message-Id: <8809081755.AA01158@nems.ARPA> Date: 8 Sep 88 13:55 EDT From: ginskow@nems.ARPA (Paul Genskow) Subject: Distribution Request for PCNET To: Info-PCNet-Request@AI.AI.MIT.EDU Cc: ginskow@nems.ARPA Dear Mr. Patton, Request that I be added to the distribution list for PCNET. I am Paul Genskow Address is ginskow at nems.arpa. Thank you Paul -------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 16:43:19 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 8 Sep 88 16:03:14 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 5296; Thu, 08 Sep 88 02:37:40 EDT Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5295; Thu, 08 Sep 88 02:37:07 EDT Received: by DBNRHRZ1 (Mailer X1.25) id 0328; Thu, 08 Sep 88 08:37:26 MEZ Date: Thu, 08 Sep 88 08:36:24 MEZ From: Ernst-Peter Beyer Subject: UNSUBSCRIBE To: info-pcnet-request@mc.lcs.mit.edu signoff Sign me off from the info-pcnet list. E.-P.B.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 19:05:57 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 8 Sep 88 19:01:13 EDT Date: Thu, 08 Sep 88 18:59:52 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Thu, 08 Sep 88 18:59:50 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 3251 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 3251 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3251; Thu, 08 Sep 88 18:59:42 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 08 Sep 88 18:59:39 EDT 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 | +-------------------------------+--------------------------------------------+ , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 19:25:37 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 8 Sep 88 19:20:43 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3386; Thu, 08 Sep 88 19:19:20 EDT Received: from TEMPLEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3385; Thu, 08 Sep 88 19:19:19 EDT Received: from TEMPLEVM.BITNET by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 1291; Thu, 08 Sep 88 19:15:05 EDT Date: Thu, 08 Sep 88 19:15:05 EDT From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 TEMPLEVM.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 TEMPLEVM.BITNET Hello MITVMA.MIT.EDU 050 TICK 3251 250 3251 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: V5041E 050 QUIT 221 TEMPLEVM.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 1289; Thu, 08 Sep 88 19:15:05 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3251; Thu, 08 Sep 88 18:59:42 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 08 Sep 88 18:59:39 EDT 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 8 Sep 88 19:29:46 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 8 Sep 88 19:25:09 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Thu, 8 Sep 88 19:25 EDT Date: Thu, 8 Sep 88 19:19 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Thu, 8 Sep 88 19:18 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 3260 for 000544@PITTVMS; Thu, 8 Sep 88 19:18 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3251; Thu, 08 Sep 88 18:59:42 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 08 Sep 88 18:59:39 EDT 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@vb.cc.cmu.edu Subject: New version of Advanced Netware(r) '286 Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Copper Electronics Inc. Louisville, KY Message-Id: <447@coplex.UUCP> 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 8 Sep 88 19:29:55 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 8 Sep 88 19:25:39 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Thu, 8 Sep 88 19:25 EDT Date: Thu, 8 Sep 88 19:19 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Thu, 8 Sep 88 19:18 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 3261 for 334641@PITTVMS; Thu, 8 Sep 88 19:18 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3251; Thu, 08 Sep 88 18:59:42 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 08 Sep 88 18:59:39 EDT 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@vb.cc.cmu.edu Subject: New version of Advanced Netware(r) '286 Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Copper Electronics Inc. Louisville, KY Message-Id: <447@coplex.UUCP> 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 8 Sep 88 19:40:22 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Sep 88 19:33:24 EDT Date: Thu, 8 Sep 88 19:37:21 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <439747.880908@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 8 Sep 88 19:42:12 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Sep 88 19:37:54 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 8 Sep 88 19:41:22 EDT Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 8 Sep 88 19:34:28 EDT Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA19676; Thu, 8 Sep 88 19:33:49 EDT Date: Thu, 8 Sep 88 19:33:49 EDT From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8809082333.AA19676@rutgers.edu> To: <@mc.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 hobbit@gold.rutgers.edu... Host unknown ----- Unsent message follows ----- Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA19673; Thu, 8 Sep 88 19:33:49 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 8 Sep 88 19:32:54 EDT 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 8 Sep 88 20:37:41 EDT Received: from venera.isi.edu (TCP 1200200064) by MC.LCS.MIT.EDU 8 Sep 88 20:32:17 EDT Date: Thu, 8 Sep 88 16:56:03 PDT From: katz@venera.isi.edu (Alan Katz) Posted-Date: Thu, 8 Sep 88 16:56:03 PDT Message-Id: <8809082356.AA06543@venera.isi.edu> Received: by venera.isi.edu (5.54/5.51) id AA06543; Thu, 8 Sep 88 16:56:03 PDT To: info-pcnet-request@mc.lcs.mit.edu Subject: please remove me Please remove me from info-pcnet.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Sep 88 06:55:09 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 10 Sep 88 06:50:34 EDT Date: Sat, 10 Sep 88 06:49:07 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Sat, 10 Sep 88 06:49:05 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 4599 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 4599 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4599; Sat, 10 Sep 88 06:48:57 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 10 Sep 88 06:48:54 EDT 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 | +-------------------------------+--------------------------------------------+ , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Sep 88 07:02:54 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 10 Sep 88 06:58:00 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4690; Sat, 10 Sep 88 06:56:32 EDT Received: from TEMPLEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4689; Sat, 10 Sep 88 06:56:31 EDT Received: from TEMPLEVM.BITNET by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 3984; Sat, 10 Sep 88 06:54:18 EDT Date: Sat, 10 Sep 88 06:54:17 EDT From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 TEMPLEVM.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 TEMPLEVM.BITNET Hello MITVMA.MIT.EDU 050 TICK 4599 250 4599 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: V5041E 050 QUIT 221 TEMPLEVM.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 3983; Sat, 10 Sep 88 06:54:17 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4599; Sat, 10 Sep 88 06:48:57 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 10 Sep 88 06:48:54 EDT 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 10 Sep 88 07:17:29 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Sep 88 07:11:15 EDT Date: Sat, 10 Sep 88 07:15:28 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <440699.880910@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 10 Sep 88 07:18:54 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Sep 88 07:14:02 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Sep 88 07:17:59 EDT Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 10 Sep 88 07:12:09 EDT Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA17518; Sat, 10 Sep 88 07:11:33 EDT Date: Sat, 10 Sep 88 07:11:33 EDT From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8809101111.AA17518@rutgers.edu> To: <@mc.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 hobbit@gold.rutgers.edu... Host unknown ----- Unsent message follows ----- Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA17509; Sat, 10 Sep 88 07:11:33 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 10 Sep 88 07:10:35 EDT 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 10 Sep 88 13:49:31 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 10 Sep 88 13:44:35 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sat, 10 Sep 88 13:44 EDT Date: Sat, 10 Sep 88 13:42 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sat, 10 Sep 88 13:42 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 4610 for 000544@PITTVMS; Sat, 10 Sep 88 13:41 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4599; Sat, 10 Sep 88 06:48:57 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 10 Sep 88 06:48:54 EDT 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@vb.cc.cmu.edu Subject: Apologies Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Copper Electronics Inc. Louisville, KY Message-Id: <449@coplex.UUCP> 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 10 Sep 88 18:32:42 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 10 Sep 88 18:28:00 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sat, 10 Sep 88 18:28 EDT Date: Sat, 10 Sep 88 18:26 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sat, 10 Sep 88 13:41 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 4613 for 334641@PITTVMS; Sat, 10 Sep 88 13:41 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4599; Sat, 10 Sep 88 06:48:57 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 10 Sep 88 06:48:54 EDT 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@vb.cc.cmu.edu Subject: Apologies Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Copper Electronics Inc. Louisville, KY Message-Id: <449@coplex.UUCP> 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 11 Sep 88 03:09:00 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 Sep 88 02:43:12 EDT Date: Sun, 11 Sep 88 02:41:40 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Sun, 11 Sep 88 02:41:38 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 6908 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 6908 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6908; Sun, 11 Sep 88 02:41:31 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sun, 11 Sep 88 02:41:28 EDT 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 , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Sep 88 03:10:50 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 11 Sep 88 02:46:01 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sun, 11 Sep 88 02:46 EDT Date: Sun, 11 Sep 88 02:45 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sun, 11 Sep 88 02:44 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6918 for 000544@PITTVMS; Sun, 11 Sep 88 02:44 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6908; Sun, 11 Sep 88 02:41:31 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sun, 11 Sep 88 02:41:28 EDT 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@vb.cc.cmu.edu Subject: call waiting Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Rutgers University Fido 107/330 (201) 932-3887 Message-Id: <48.232A18CA@rubbs1.FIDONET.ORG> 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 11 Sep 88 03:11:04 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 11 Sep 88 02:46:23 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sun, 11 Sep 88 02:46 EDT Date: Sun, 11 Sep 88 02:45 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sun, 11 Sep 88 02:45 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6919 for 334641@PITTVMS; Sun, 11 Sep 88 02:45 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6908; Sun, 11 Sep 88 02:41:31 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sun, 11 Sep 88 02:41:28 EDT 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@vb.cc.cmu.edu Subject: call waiting Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Rutgers University Fido 107/330 (201) 932-3887 Message-Id: <48.232A18CA@rubbs1.FIDONET.ORG> 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 11 Sep 88 03:11:15 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 Sep 88 02:47:47 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6994; Sun, 11 Sep 88 02:46:16 EDT Received: from TEMPLEVM.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6993; Sun, 11 Sep 88 02:46:15 EDT Received: from TEMPLEVM.BITNET by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 4726; Sun, 11 Sep 88 02:44:28 EDT Date: Sun, 11 Sep 88 02:44:28 EDT From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 TEMPLEVM.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 TEMPLEVM.BITNET Hello MITVMA.MIT.EDU 050 TICK 6908 250 6908 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: V5041E 050 QUIT 221 TEMPLEVM.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by TEMPLEVM.BITNET (Mailer X1.25) with BSMTP id 4725; Sun, 11 Sep 88 02:44:27 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6908; Sun, 11 Sep 88 02:41:31 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sun, 11 Sep 88 02:41:28 EDT 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 11 Sep 88 03:13:35 EDT Received: from R20.UTEXAS.EDU (TCP 20024600436) by MC.LCS.MIT.EDU 11 Sep 88 03:02:58 EDT Date: Sun 11 Sep 88 01:57:42-CDT From: The Mailer Daemon To: info-pcnet-request@MC.LCS.MIT.EDU Subject: Message of 11-Sep-88 01:57:18 Message failed for the following: SMP@EMX.UTEXAS.EDU.#Internet: 550 ... User unknown ------------ Received: from AI.AI.MIT.EDU by R20.UTEXAS.EDU with TCP; Sun 11 Sep 88 01:57:24-CDT XX-Header: The R20.UTEXAS.EDU node is going away. Make other mail routing arrangements!!!!! 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 11 Sep 88 03:16:26 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 03:05:16 EDT Date: Sun, 11 Sep 88 03:09:30 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441008.880911@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 11 Sep 88 03:19:25 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 03:14:25 EDT Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 11 Sep 88 03:18:26 EDT Received: from rutgers.edu (TCP 20001412411) by MC.LCS.MIT.EDU 11 Sep 88 03:10:52 EDT Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA25830; Sun, 11 Sep 88 03:10:00 EDT Date: Sun, 11 Sep 88 03:10:00 EDT From: Postmaster@rutgers.edu (Mail Delivery Subsystem) Subject: Returned mail: Host unknown Message-Id: <8809110710.AA25830@rutgers.edu> To: <@mc.lcs.mit.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- 550 hobbit@gold.rutgers.edu... Host unknown ----- Unsent message follows ----- Received: from MC.LCS.MIT.EDU by rutgers.edu (5.59/1.15) id AA25816; Sun, 11 Sep 88 03:10:00 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 03:04:51 EDT 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: Tom.Connolly@rubbs1.uucp (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 11 Sep 88 17:35:01 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:30:05 EDT Date: Sun, 11 Sep 88 17:34:21 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441209.880911@AI.AI.MIT.EDU> FAILED: august at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: GIL at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: LYMAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: TUAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:35:15 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:30:15 EDT Date: Sun, 11 Sep 88 17:34:34 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441210.880911@AI.AI.MIT.EDU> FAILED: august at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: GIL at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: LYMAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: TUAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:35:23 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:30:25 EDT Date: Sun, 11 Sep 88 17:34:44 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441211.880911@AI.AI.MIT.EDU> FAILED: august at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: GIL at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: LYMAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. FAILED: TUAN at VLSI.JPL.NASA.GOV; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:36:16 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:31:10 EDT Date: Sun, 11 Sep 88 17:35:26 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441212.880911@AI.AI.MIT.EDU> FAILED: incoming-info-pcnet at 10.3.0.89; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:36:34 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:31:19 EDT Date: Sun, 11 Sep 88 17:35:38 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441213.880911@AI.AI.MIT.EDU> FAILED: incoming-info-pcnet at 10.3.0.89; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:36:50 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:31:30 EDT Date: Sun, 11 Sep 88 17:35:47 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441214.880911@AI.AI.MIT.EDU> FAILED: incoming-info-pcnet at 10.3.0.89; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:39:50 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:34:55 EDT Date: Sun, 11 Sep 88 17:39:11 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441222.880911@AI.AI.MIT.EDU> FAILED: williams%blue.decnet at ARI-HQ1.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:40:00 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:35:04 EDT Date: Sun, 11 Sep 88 17:39:23 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441223.880911@AI.AI.MIT.EDU> FAILED: williams%blue.decnet at ARI-HQ1.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:40:10 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:35:15 EDT Date: Sun, 11 Sep 88 17:39:33 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441224.880911@AI.AI.MIT.EDU> FAILED: williams%blue.decnet at ARI-HQ1.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:41:30 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:36:35 EDT Date: Sun, 11 Sep 88 17:40:55 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441229.880911@AI.AI.MIT.EDU> FAILED: mjolsnes%vax.elab.unit.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: s_helmersen%use.uio.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: yngvar at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:41:40 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:36:44 EDT Date: Sun, 11 Sep 88 17:41:04 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441230.880911@AI.AI.MIT.EDU> FAILED: mjolsnes%vax.elab.unit.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: s_helmersen%use.uio.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: yngvar at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:41:49 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:36:55 EDT Date: Sun, 11 Sep 88 17:41:12 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441231.880911@AI.AI.MIT.EDU> FAILED: mjolsnes%vax.elab.unit.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: s_helmersen%use.uio.uninett at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. FAILED: yngvar at TOR.NTA.NO; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:42:38 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:37:40 EDT Date: Sun, 11 Sep 88 17:42:00 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441232.880911@AI.AI.MIT.EDU> FAILED: gran!jan at NTA-ODIN.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:42:50 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:37:49 EDT Date: Sun, 11 Sep 88 17:42:08 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441233.880911@AI.AI.MIT.EDU> FAILED: gran!jan at NTA-ODIN.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:43:05 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:38:00 EDT Date: Sun, 11 Sep 88 17:42:18 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441234.880911@AI.AI.MIT.EDU> FAILED: gran!jan at NTA-ODIN.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:47:14 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:42:21 EDT Date: Sun, 11 Sep 88 17:46:30 EDT From: Communications Satellite Subject: Msg of Thursday, 8 September 1988 18:53-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441243.880911@AI.AI.MIT.EDU> FAILED: uci-info-pcnet at ICS.UCI.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:47:29 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:42:47 EDT Date: Sun, 11 Sep 88 17:46:49 EDT From: Communications Satellite Subject: Msg of Saturday, 10 September 1988 06:43-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441244.880911@AI.AI.MIT.EDU> FAILED: uci-info-pcnet at ICS.UCI.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 17:47:39 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 17:43:01 EDT Date: Sun, 11 Sep 88 17:47:15 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <441245.880911@AI.AI.MIT.EDU> FAILED: uci-info-pcnet at ICS.UCI.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Sep 88 21:02:12 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 11 Sep 88 20:56:57 EDT Received: from spam.istc.sri.com (TCP 1200400153) by AI.AI.MIT.EDU 11 Sep 88 21:01:10 EDT Received: by spam.istc.sri.com (5.54/5.00) id AA00411 for @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu; Sun, 11 Sep 88 17:57:43 PDT Date: Sun, 11 Sep 88 17:57:43 PDT From: Mail Delivery Subsystem Message-Id: <8809120057.AA00411@spam.istc.sri.com> To: <@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Subject: Returned mail: Cannot send message for 3 days ----- Transcript of session follows ----- 421 aalps3.istc.sri.com.tcp... Deferred: Connection timed out during user open with aalps3.istc.sri.com ----- Unsent message follows ----- Received: by spam.istc.sri.com (5.54/5.00) id AA15309 for hutch@aalps3.istc.sri.com; Thu, 8 Sep 88 17:54:48 PDT Received-Date: Thu, 8 Sep 88 17:54:48 PDT 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 njitc.njit.edu (TCP 20072600401) by AI.AI.MIT.EDU 12 Sep 88 05:46:38 EDT Date: 12 Sep 88 05:19:00 EST From: "NJITX::HXN8477" Subject: Addition request To: "info-pcnet-request" Reply-To: "NJITX::HXN8477" Hello, I would appreciate it if you could put me on your mailing list. Thanks in advance. hn +--------------------------+-------------------------------------------------+ | Hamed Nassar | Internet : hxn8477%njitx.decnet@njitc.njit.edu | | EE Department | UUCP : bellcore!argus!mars!nancy | | NJ Inst. of Tech | CompuServe: 74000,130 | +--------------------------+-------------------------------------------------+ ------  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 12 Sep 88 16:27:26 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 12 Sep 88 16:22:18 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 4608; Mon, 12 Sep 88 16:20:30 EDT Received: from ccm.UManitoba.CA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 4606; Mon, 12 Sep 88 15:54:12 EDT Date: Mon, 12 Sep 88 09:50 CDT From: #YEUN14%ccm.UManitoba.CA@MITVMA.MIT.EDU To: , , Subject: signoff Please signoff from the mailing list. thank you! , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Sep 88 09:35:54 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 13 Sep 88 09:30:51 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0812; Tue, 13 Sep 88 09:29:11 EDT Received: from ITIVAX.BITNET (WAIHONG) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0810; Tue, 13 Sep 88 09:29:09 EDT Date: Tue, 13 Sep 88 19:08 U From: Subject: Unsubscribe To: info-pcnet-request@mc.lcs.mit.edu X-Original-To: info-pcnet-request@mc.lcs.mit.edu, WAIHONG PLease take me off the distribution list. Thanks!  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Sep 88 12:43:47 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 13 Sep 88 12:27:48 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2181; Tue, 13 Sep 88 11:00:50 EDT Received: from CORNELLC.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2180; Tue, 13 Sep 88 11:00:48 EDT Received: by CORNELLC (Mailer X1.25) id 7058; Tue, 13 Sep 88 11:00:42 EDT Date: Tue, 13 Sep 88 11:00:14 EDT From: Thomas Weyer Subject: request for inclusion To: sysop HELLO I would like to be placed on your SIG mailing list. Thanks for your time. Thomas Weyer Cornell University Acknowledge-To:  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 13 Sep 88 17:14:28 EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 13 Sep 88 16:00:22 EDT Date: Tue, 13 Sep 88 16:04:59 EDT From: Communications Satellite Subject: Msg of Sunday, 11 September 1988 02:34-EDT To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <442531.880913@AI.AI.MIT.EDU> FAILED: J.Bunch at UACSC1.ALBANY.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 11 Oct 88 12:47:46 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 11 Oct 88 12:42:58 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7227; Tue, 11 Oct 88 12:39:18 EDT Received: from DKAUNI11.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7226; Tue, 11 Oct 88 12:24:47 EDT Received: by DKAUNI11 (Mailer X1.25) id 5516; Tue, 11 Oct 88 16:55:22 MEZ Date: Tue, 11 Oct 88 16:51:01 MEZ From: Harald Graul Subject: Survey of Fileservers To: Howie Kaye , Micheal Patton , INFO-PCNET-REQUEST@MC.LCS.MIT.EDU To all Fileserver Organizations A Research on the Existing Fileserver Organizations This is the second mail within the scope of our international research project at the University of Karlsruhe/West Germany. The goal of this project is an information system, which will give every network user the possibility of an easier access to all important network services such as fileservers, listservs, netservs, digests, mailing lists etc. We'll just call them fileservers in the following, although we know, that there are differeces between them. The data about all existing fileservers is being collected with help of the accompanying questionnaire. U n f o r t u n a t e l y we haven't got a filled-in questionnaire from you, yet. Perhaps our first mail has been lost or deleted by mistake. But to add your fileserver to our information system, we need a more detailed description than one can find in the documentation-file 'Netinfo: INTER- EST-GROUPS' by Rich Zellich. Therefore we ask you once more to fill in the following questionnaire, which should characterize your institution, even if not every question exactly applies to your server, e.g. because you offer a mailing list. The results of our research will be offered in two ways: Information of interest to network users will be offered in an information system, which will be easy to access by everyone via BITNET. Additionally, we'll send a survey report with the results of this study to all respondents of the questionnaire. Please understand, that some questions are beyond the needs of the information system, but are important for our research project. Thanks in advance for supporting our project and answering the following 30 questions as far as known. If there are further people at your site, who are responsible for the range of fileservers, please forward a copy of this request to them. If you are responsible for several independent fileservers, we ask you to send back one copy of this questionnaire for each. Further inquiry: If there are further questions or unclarities, please contact Harald Graul Deadline: To obtain as complete a collection of the existing fileservers as possible, we ask you to send back the filled-in questionnaire by October 22, 1988 to the following electronic mail address: ----> RY84 at DKAUNI11.BITNET ------------------------------------------------------------------------- Questionnaire for the Research on the Existing Fileserver Organizations Note: For questions with a 'O' please replace the 'O' by a 'x' (if true); otherwise write the answer on the dotted line. If there is not enough space for your answer, please add lines. 1. Concerning your fileserver/listserver/digest etc. 1.1> Name of the server ...................................... Electronic mail address of the server (if different from the name) ...................................... 1.2> What kind of services do you offer ? supply of software O forums for discussions O single discussion list O others (please specify) ................................... ................................... 1.3> Are there peers or shadows of your fileserver ? yes O no O If "yes", please list them (incl. electronic mail address). ...................................... ...................................... 1.4> When did you start your server/service ? ................... 1.5> Please list the most important commands for the starting of a new user (e.g. HELP, DIR) and the informations he'll receive upon using them. Command Informations ....................... .......................................... ....................... .......................................... 2. Concerning the organization 2.1> How many persons are engaged in the management of the fileserver ? full-time ... part-time ... 2.2> How is your fileserver financed ? (e.g. university, government) ................................................................... 2.3> What is the annual budget for your server ? (in US dollars, please) .......$ 2.4> Please name persons users can mail for help. (incl. electronic mail address). ..................................................... ..................................................... 2.5> Do you gather data about users behaviour ? yes O no O If "yes", please answer the following questions 2.5.1 to 2.5.3. 2.5.1> What kind of method do you use ? (e.g. notebook, logfile) .................................... 2.5.2> Do you evaluate these data statistically ? yes O no O 2.5.3> How many inquiries do you receive per month on an average ? ........ 2.6> Is your fileserver active all day long ? yes O no O If "no", please answer the following questions 2.6.1 and 2.6.2. 2.6.1> What is the reason ? ........................................................... 2.6.2> When is your fileserver inactive ? ........................................................... 3. Fill out only if you offer forum(s) for discussions Please list your most important forums for discussions with the appro- priate parameters for: Subject, subscription (open/closed), notebook (yearly, monthly, weekly, irregularly, none), number of owners, number of peers, number of subscribed users and whether it is a redistribution list or not. Please copy the following part as often as you need. name of the forum .......................................... subject .......................................... subscription ............ notebook ............ number of owners ... number of peers ... number of subscribed users ... redistribution list (y/n) ... 4. Fill out only if you offer software 4.1 Where does the sofware you offer come from ? Programs developed by -your own site O -other universities (please specify) ............................ ............................ -other fileservers (please specify) ............................ ............................ -various authors of single programs O -further organizations (e.g. user ............................ groups,publishers.. , please specify) ............................ 4.2> Do you check the programs before adding them to the fileserver ? yes O no O If "yes", what kind of examination do you make ? (e.g. reliability, documentation, semantics etc.) ........................................................ 4.3> Who is allowed to get software from your fileserver ? closed user group O national users O everybody O 4.4> For which operating systems do you offer software ? ............................................................... ............................................................... 4.5> For what fields do you offer programs and how many ? field number of programs ........................................ ... ........................................ ... 4.6> What is the average number of new programs to be added to the server during a month/year ? ...per....... 5. Technical questions (as far as known) 5.1> Under which operating system does your fileserver run ? .................................................................. 5.2> What kind of machine does your fileserver run on ? .................................................................. 5.3> Did you develop the fileserver-program by your own ? yes O no O If "yes", how much time did the implementation take ? (in man-months or man-years, please) ... man-...... If "no", what kind of fileserver-program do you use and where does it come from ? .......................................................... .......................................................... 5.4> Did any problems occur with the installation of the fileserver or have you any recommendations ? yes O no O If "yes", please explain them. ...................................................... ...................................................... 5.5> What kind of commands are accepted ? via interactive message O via mail O via non-mail file O 5.5.1> What kind of transport formats are allowed ? Netdata O Punch O Print O Disk dump O others (please specify) ................................... 5.5.2> What kind of mail formats are allowed ? BSMTP RFC822 O RFC822 O IBM-'NOTE' O others (please specify) ...................................... 5.6> What formats do you use to send files ? ................................................................... 5.7> Are there any problems with data transmissions or do you have any recommendations ? yes O no O If "yes", please explain them. ...................................................... ...................................................... 6. Concerning projects in the future 6.1> Do you plan to run a fileserver in the future, as well ? yes O no O 6.2> Do you plan to expand your supply soon ? yes O no O If "yes", what do you want to add ? ......................................................... ......................................................... 7. Personal data 7.1> name: ............................. 7.2> electronic mail address: ............................. 7.3> What kind of job do you have with the server ? (e.g. owner of a list, postmaster, maintainer etc.) .................................... 7.4> Have you heard about other projects of making a collection of all existing fileservers, which will be offered in an information system to network users ? yes O no O If "yes", who is undertaking these projects ? .......................................... THANK YOU VERY MUCH FOR YOUR HELP ||| Acknowledge-To:  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Oct 88 00:28:13 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 13 Oct 88 23:06:31 EDT Date: Thu 13 Oct 88 22:14:43-EDT From: The Mailer Daemon To: info-pcnet-request@mc.lcs.mit.edu Subject: Message of 13-Oct-88 22:14:34 Message failed for the following: Ralph.Hyre@XX.LCS.MIT.EDU.#Chaos: Can't forward - unknown host "C.CS.CMU.EDU" ------------ Received: from AI.AI.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Thu 13 Oct 88 22:14:38-EDT 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 14 Oct 88 06:27:27 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Oct 88 06:05:04 EDT Date: Thu, 13 Oct 88 23:06:20 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Thu, 13 Oct 88 23:06:19 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 6641 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 6641 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6641; Thu, 13 Oct 88 23:06:12 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 13 Oct 88 23:06:07 EDT 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 , QUIT  Received: from lead-1.arpa (TCP 3201600066) by AI.AI.MIT.EDU 14 Oct 88 06:32:20 EDT Received: from dds-plexus01 by lead-1.arpa id ah22451; 13 Oct 88 16:07 EDT Received: from sds-intel04 by dds-plexus01.lead-1.arpa id ag10518; 13 Oct 88 15:07 EDT Date: Thu, 13 Oct 88 14:19:38 EDT From: Jmiller@lead-1.arpa To: info-pcnet-request@AI.AI.MIT.EDU cc: jmiller@lead-1.arpa Subject: Add to mailing list Please add jmiller@lead-1 to your mailing list. We have recently installed a PC-Network. thanks in advance, Jeff Miller  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Oct 88 21:43:00 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 17 Oct 88 21:26:51 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Fri, 14 Oct 88 01:33 EDT Date: Fri, 14 Oct 88 01:26 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Fri, 14 Oct 88 00:15 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6650 for 000544@PITTVMS; Fri, 14 Oct 88 00:14 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6641; Thu, 13 Oct 88 23:06:12 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 13 Oct 88 23:06:07 EDT 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@vb.cc.cmu.edu Subject: MSNet SMB protocol - where can I get it? Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Hewlett-Packard Vienna,Austria Message-Id: <649@hpuviea.UUCP> 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 17 Oct 88 21:43:20 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 17 Oct 88 21:27:02 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Fri, 14 Oct 88 01:34 EDT Date: Fri, 14 Oct 88 01:26 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Fri, 14 Oct 88 00:15 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6651 for 334641@PITTVMS; Fri, 14 Oct 88 00:14 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6641; Thu, 13 Oct 88 23:06:12 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Thu, 13 Oct 88 23:06:07 EDT 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@vb.cc.cmu.edu Subject: MSNet SMB protocol - where can I get it? Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Hewlett-Packard Vienna,Austria Message-Id: <649@hpuviea.UUCP> 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 22 Oct 88 16:25:06 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 22 Oct 88 16:07:04 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sat, 22 Oct 88 15:34 EDT Date: Sat, 22 Oct 88 15:32 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sat, 22 Oct 88 15:32 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6459 for 000544@PITTVMS; Sat, 22 Oct 88 15:32 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6449; Sat, 22 Oct 88 15:26:28 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 22 Oct 88 15:26:24 EDT 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@vb.cc.cmu.edu Subject: Re: MSNet SMB protocol - where can I get it? Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Apple Computer Inc, Cupertino, CA Message-Id: <19222@apple.Apple.COM> References: <649@hpuviea.UUCP> 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 22 Oct 88 18:15:27 EDT Received: from VB.CC.CMU.EDU (TCP 20000576422) by MC.LCS.MIT.EDU 22 Oct 88 18:07:14 EDT Received: from VMS.CIS.PITTSBURGH.EDU by VB.CC.CMU.EDU; Sat, 22 Oct 88 15:35 EDT Date: Sat, 22 Oct 88 15:33 EDT From: PMDF Mail Server <@VB.CC.CMU.EDU:Postmaster@Vms.Cis.Pittsburgh.Edu> Subject: Undeliverable mail To: info-pcnet-request@MC.LCS.MIT.EDU The message could not be delivered to: Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from JNET-DAEMON by vms.cis.pittsburgh.edu; Sat, 22 Oct 88 15:32 EDT Received: From MITVMA(MAILER) by PITTVMS with Jnet id 6460 for 334641@PITTVMS; Sat, 22 Oct 88 15:32 EDT Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6449; Sat, 22 Oct 88 15:26:28 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 22 Oct 88 15:26:24 EDT 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@vb.cc.cmu.edu Subject: Re: MSNet SMB protocol - where can I get it? Sender: info-pcnet-request%mc.lcs.mit.EDU@vb.cc.cmu.edu To: info-pcnet%mc.lcs.mit.EDU@vb.cc.cmu.edu Organization: Apple Computer Inc, Cupertino, CA Message-Id: <19222@apple.Apple.COM> References: <649@hpuviea.UUCP> 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 22 Oct 88 21:43:15 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 22 Oct 88 20:15:50 EDT Date: Sat, 22 Oct 88 15:26:39 EDT From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Sat, 22 Oct 88 15:26:38 EDT 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 6449 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 6449 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6449; Sat, 22 Oct 88 15:26:28 EDT Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Sat, 22 Oct 88 15:26:24 EDT 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. , QUIT  Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 23 Oct 88 16:26:19 EDT Received: from relay2.cs.net by RELAY.CS.NET id aa06961; 23 Oct 88 16:22 EDT Received: from cl.uh.edu by RELAY.CS.NET id aa21306; 23 Oct 88 16:08 EDT Date: Sun, 23 Oct 88 11:10 CST From: NUNN%cl.uh.edu@RELAY.CS.NET Subject: deletion from info-pcnet To: info-pcnet-request@AI.AI.MIT.EDU X-VMS-To: IN%"info-pcnet-request@ai.ai.mit.edu",NUNN Moderator, Please DELETE info-pcnet%uhcl.edu@sh.cs.net to the distribution list. Thanks, John Nunn Technical Liaison University of Houston-Clear Lake  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Oct 88 04:36:33 EDT Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 25 Oct 88 04:23:28 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 3750; Tue, 25 Oct 88 03:41:53 EDT Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3722; Tue, 25 Oct 88 03:41:51 EDT Received: by DBNRHRZ1 (Mailer X1.25) id 8094; Tue, 25 Oct 88 08:43:02 MEZ Date: Tue, 25 Oct 88 08:42:03 MEZ From: Ernst-Peter Beyer Subject: SIGNOFF To: info-pcnet-request@mc.lcs.mit.edu signoff Please remove me from the list. Thanks  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 25 Oct 88 23:41:02 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Oct 88 22:35:34 EDT Return-Path: <@MC.LCS.MIT.EDU,@AI.AI.MIT.EDU:postmaster@ames.arc.nasa.gov> Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Tue 25 Oct 88 21:53:04-EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Oct 88 20:17:16 EDT Received: from ames.arc.nasa.gov (TCP 20031411003) by AI.AI.MIT.EDU 22 Oct 88 20:34:21 EDT Received: Sat, 22 Oct 88 17:23:29 PDT by ames.arc.nasa.gov (5.59/1.2) Date: Sat, 22 Oct 88 17:23:29 PDT From: Mail Delivery Subsystem Subject: Returned mail: unknown mailer error 255 Message-Id: <8810230023.AA14328@ames.arc.nasa.gov> To: rutgers!mc.lcs.mit.edu!mit-eddie!@EDDIE.MIT.EDU To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:info-pcnet-request ReSent-Date: Tue 25 Oct 88 22:34:57-EDT ReSent-From: Rob Austein ReSent-To: info-pcnet-request@MC.LCS.MIT.EDU ReSent-Message-ID: <12441382447.11.SRA@XX.LCS.MIT.EDU> ----- Transcript of session follows ----- uux failed. code -1 554 pyramid!ncc!lyndon... unknown mailer error 255 ----- Unsent message follows ----- Received: Sat, 22 Oct 88 17:23:29 PDT by ames.arc.nasa.gov (5.59/1.2) Received: by rutgers.edu (5.59/1.15) with UUCP id AA13574; Sat, 22 Oct 88 16:12:05 EDT Received: from ai.ai.mit.edu by EDDIE.MIT.EDU via Chaosnet with SMTP with sendmail-5.45/4.7 id ; Sat, 22 Oct 88 15:50:07 EDT 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: rutgers!apple.com!lenoil (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: rutgers!mc.lcs.mit.edu!info-pcnet-request 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 25 Oct 88 23:53:15 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 25 Oct 88 23:49:28 EDT Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Tue 25 Oct 88 23:48:41-EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 25 Oct 88 23:43:22 EDT Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 23 Oct 88 20:20:42 EDT Received: from relay2.cs.net by RELAY.CS.NET id ab09244; 23 Oct 88 19:50 EDT Date: Sun, 23 Oct 88 19:35:28 EDT From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aq14170) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id aq14170; 22 Oct 88 15:40 EDT Received: from ai.ai.mit.edu by RELAY.CS.NET id aa21198; 22 Oct 88 15:31 EDT 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: 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 26 Oct 88 09:06:31 EDT Received: from rand.org (TCP 1200600007) by MC.LCS.MIT.EDU 26 Oct 88 06:34:46 EDT Received: from localhost by rand.org; Wed, 26 Oct 88 03:02:49 PDT Message-Id: <8810261002.AA15717@rand.org> To: info-pcnet-request@mc.lcs.mit.edu Subject: please remove me from info-pcnet Date: Wed, 26 Oct 88 03:02:45 PDT From: Steve Tepper  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 26 Oct 88 09:32:09 EDT Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 26 Oct 88 09:04:57 EDT Received: from MC.LCS.MIT.EDU by XX.LCS.MIT.EDU with Chaos/SMTP; Wed 26 Oct 88 09:04:06-EDT Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 26 Oct 88 06:35:05 EDT Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 14 Oct 88 00:52:04 EDT Received: from relay2.cs.net by RELAY.CS.NET id ae15670; 13 Oct 88 23:40 EDT Date: Thu, 13 Oct 88 23:29:20 EDT From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.ar05061) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU,@XX.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id ar05061; 13 Oct 88 22:57 EDT Received: from ai.ai.mit.edu by RELAY.CS.NET id aa14443; 13 Oct 88 21:52 EDT 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: 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 31 Oct 88 21:50:58 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 31 Oct 88 21:47:17 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0902; Mon, 31 Oct 88 21:47:41 EST Received: from UNO.BITNET (CSCT0PY7) by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0901; Mon, 31 Oct 88 21:47:40 EST Date: Mon, 31 Oct 88 16:14 CST From: Subject: Addition to PC-NET mailing list To: INFO-PCNET-REQUEST@MC.LCS.MIT.EDU X-Original-To: "INFO-PCNET-REQUEST@MC.LCS.MIT.EDU" Please add me to the INFO-PCNET mailing list. I am intrested in learning of the standards that has been defined by your group. Rene Campbell CSCT0PY7@UNO.BITNET  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 4 Nov 88 12:59:42 EST Received: from CC5.BBN.COM (TCP 20026200130) by MC.LCS.MIT.EDU 4 Nov 88 12:43:37 EST To: info-pcnet-request@MC.LCS.MIT.EDU Subject: please add Date: Fri, 04 Nov 88 12:41:37 -0500 From: "Miles R. Fidelman"  Received: from MITVMA.MIT.EDU (TCP 2227000003) by AI.AI.MIT.EDU 23 Nov 88 10:55:27 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7187; Wed, 23 Nov 88 10:45:52 EST Received: from EOVUOV11.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7186; Wed, 23 Nov 88 10:41:41 EST Received: by EOVUOV11 (Mailer X1.25) id 1795; Tue, 22 Nov 88 13:21:24 EDT Date: Tue, 22 Nov 88 13:20:07 EDT From: Jose Maria Fernandez Suarez Subject: suscription To: Info-PCNet-Request@AI.AI.MIT.EDU I'd like to be added to this List. Thanks a lot in advance. Jose Maria.  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 30 Nov 88 21:49:01 EST Received: from XX.LCS.MIT.EDU (CHAOS 2420) by MC.LCS.MIT.EDU 30 Nov 88 21:39:09 EST Received: from UDEL.EDU by XX.LCS.MIT.EDU with TCP/SMTP; Wed 30 Nov 88 21:38:13-EST Reply-To: BBoards Support To: info-pcnet-request@mc.lcs.mit.edu Subject: Please remove us from your distribution list Date: Wed, 30 Nov 88 16:39:06 -0500 Message-ID: <14253.596929146@udel.edu> From: BBoards Support (agent: Eric Luckenbaugh) At the University of Delaware we are currently moving from the old BBoard system to usenet newsgroups. We no longer need to be subscribed to your bboard, and messages sent to this bboard in the future will be rejected. Our address is: dist-info-pcnet@louie.udel.edu. Thank you for your cooperation in the past, your interest in the University's BBoard system has been appreciated. Eric Luckenbaugh BBoards Support University of Delaware  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Dec 88 23:27:04 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 88 22:18:37 EST Date: Mon, 5 Dec 88 22:18:58 EST From: Communications Satellite Subject: Msg of Monday, 5 December 1988 22:15-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <499107.881205@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GRAN!JAN@NTA-ODIN.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [PCNET;PCNET DIS]), from INFO-PCNET ============ Failed message follows: ============ 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 5 Dec 88 23:27:22 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 5 Dec 88 22:25:56 EST Date: Mon, 05 Dec 88 22:26:01 EST From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Mon, 05 Dec 88 22:26:00 EST 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 6803 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 6803 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6803; Mon, 05 Dec 88 22:25:50 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 05 Dec 88 22:25:46 EST 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. , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 5 Dec 88 23:28:52 EST Received: from unix.cis.pittsburgh.edu (TCP 20044602412) by MC.LCS.MIT.EDU 5 Dec 88 22:32:59 EST Received: by unix.cis.pittsburgh.edu (5.54/6.30) id AA04340; Mon, 5 Dec 88 22:32:53 EST Message-Id: <8812060332.AA04340@unix.cis.pittsburgh.edu> Date: Mon, 5 Dec 88 22:32 EST From: PMDF Mail Server Subject: Undeliverable mail To: info-pcnet-request@mc.lcs.mit.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from MITVMA.MIT.EDU by vms.cis.pittsburgh.edu; Mon, 5 Dec 88 22:32 EST Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6803; Mon, 05 Dec 88 22:25:50 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 05 Dec 88 22:25:46 EST 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@unix.cis.pittsburgh.edu Subject: NetBIOS Reference Sender: info-pcnet-request%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu To: info-pcnet%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu Message-Id: <6791@spool.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 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 5 Dec 88 23:29:07 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 5 Dec 88 22:33:49 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 7011; Mon, 05 Dec 88 22:33:52 EST Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7010; Mon, 05 Dec 88 22:33:51 EST Received: from DBNRHRZ1.BITNET by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 2426; Tue, 06 Dec 88 04:32:35 MEZ Date: Tue, 06 Dec 88 04:32:34 MEZ From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 DBNRHRZ1.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 DBNRHRZ1.BITNET Hello MITVMA.MIT.EDU 050 TICK 6803 250 6803 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: UZR506 050 QUIT 221 DBNRHRZ1.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 2423; Tue, 06 Dec 88 04:32:34 MEZ Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6803; Mon, 05 Dec 88 22:25:50 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 05 Dec 88 22:25:46 EST 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 6 Dec 88 00:13:23 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 88 23:00:39 EST Date: Mon, 5 Dec 88 23:01:01 EST From: Communications Satellite Subject: Msg of Monday, 5 December 1988 22:15-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <499108.881205@AI.AI.MIT.EDU> FAILED: WHITE at SUMEX-AIM.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: incoming-info-pcnet at COLUMBIA.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} FAILED: dist-info-pcnet at LOUIE.UDEL.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "dist-info-pcnet@LOUIE.UDEL.EDU"} FAILED: smith.umn-cs at RELAY.CS.NET; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "smith.umn-cs@RELAY.CS.NET"} Failed message follows: ------- 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 6 Dec 88 00:13:54 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 88 23:01:14 EST Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Dec 88 22:21:01 EST Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 5 Dec 88 19:21:15 PST Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AB04543; Mon, 5 Dec 88 19:21:22 PST Date: Mon, 5 Dec 88 19:21:22 PST From: MAILER-DAEMON@sumex-aim.stanford.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8812060321.AB04543@sumex-aim.stanford.edu> To: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- Connected to panda.stanford.edu: >>> RCPT To: <<< 550 ... User unknown: Not enough core 550 ... User unknown ----- Unsent message follows ----- Return-Path: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Received: from SAIL.Stanford.EDU by sumex-aim.stanford.edu (4.0/inc-1.0) id AA04541; Mon, 5 Dec 88 19:21:22 PST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 5 Dec 88 19:20:47 PST 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.cs.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 6 Dec 88 00:16:03 EST Received: from sumex-aim.stanford.edu (TCP 4413000006) by MC.LCS.MIT.EDU 5 Dec 88 23:13:07 EST Received: from LOCALHOST.stanford.edu by sumex-aim.stanford.edu (4.0/inc-1.0) id AA05181; Mon, 5 Dec 88 20:14:43 PST Message-Id: <8812060414.AA05181@sumex-aim.stanford.edu> To: info-pcnet-request@mc.lcs.mit.edu Subject: address change Date: Mon, 05 Dec 88 20:14:43 -0800 From: Carl Schaefer Please change the address mrc%panda@sumex-aim.stanford.edu to mrc@panda.com thanks, Carl  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Dec 88 00:16:18 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 5 Dec 88 23:14:10 EST Received: from VLSI.JPL.NASA.GOV (TCP 20045210004) by AI.AI.MIT.EDU 5 Dec 88 23:14:11 EST Date: Mon, 5 Dec 88 19:57:06 PST From: Delivr@VLSI.JPL.NASA.GOV Subject: Undeliverable Mail To: info-pcnet-request%mc.lcs.mit.edu%MC.LCS.MIT.EDU%AI.AI.MIT.EDU@VLSI.JPL.NASA.GOV Comment: reason for return -- Comment: %MAIL-E-SYNTAX, error parsing 'LYMAN@JATO.JPL.NASA.GOV' Comment: the affected addresses follow ... Comment: LYMAN Start of returned message Received: from AI.AI.MIT.EDU by VLSI.JPL.NASA.GOV with INTERNET ; Mon, 5 Dec 88 19:52:32 PST 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. End of returned message  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 6 Dec 88 04:41:50 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Dec 88 00:14:03 EST Received: from UACSC1.ALBANY.EDU (TCP 20063000402) by AI.AI.MIT.EDU 6 Dec 88 00:13:55 EST Date: 6 Dec 88 00:16 EST From: Postmaster@UACSC1.ALBANY.EDU To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Subject: Mail Delivery The message below has not been delivered. This message was automatically generated. %DELIVER-W-NO_MAILBOX, No Such user as 'J.Bunch' here ==== Unsent Message Follows ==== Received: from AI.AI.MIT.EDU by UACSC1.ALBANY.EDU ; 6-DEC-1988 00:14:14.31 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 6 Dec 88 05:14:25 EST Received: from beaver.cs.washington.edu (TCP 20027600401) by MC.LCS.MIT.EDU 6 Dec 88 01:06:34 EST Received: by beaver.cs.washington.edu (5.59/6.12) id AA10606; Mon, 5 Dec 88 22:06:46 PST Return-Path: Received: by ssc-vax (4.12/4.7) id AA16179; Mon, 5 Dec 88 20:22:35 pst Date: 6 Dec 88 01:18:05 GMT From: ssc-vax!MAILER-DAEMON@beaver.cs.washington.edu (Mail Delivery Subsystem) Subject: Returned mail: Remote protocol error Message-Id: <8812060422.AA16179@ssc-vax> To: uw-beaver!mc.lcs.mit.edu!info-pcnet-request@beaver.cs.washington.edu ----- Transcript of session follows ----- >>> MAIL From: <<< 501 Bad argument syntax 554 "payzer%eagle.decnet"@base-vax... Remote protocol error: Bad file number ----- Unsent message follows ----- Received: by ssc-vax (4.12/4.7) id AA16172; Mon, 5 Dec 88 20:22:35 pst Received: from AI.AI.MIT.EDU by beaver.cs.washington.edu (5.59/6.12) id AA09145; Mon, 5 Dec 88 19:47:30 PST 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: uw-beaver!speedy.wisc.edu!condon (Anne Condon) Subject: NetBIOS Reference Message-Id: <6791@spool.cs.wisc.edu> Sender: uw-beaver!mc.lcs.mit.edu!info-pcnet-request 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 6 Dec 88 06:25:41 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 6 Dec 88 03:36:58 EST Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 6 Dec 88 03:36:56 EST Date: Tue, 6 Dec 88 1:15:56 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aa05094) To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'INFO-PCNET@ADAM.DG.COM (host: adam.dg.com) (queue: dg)' for the following reason: ' ... User unknown: error 24' Your message follows: Received: from ai.ai.mit.edu by RELAY.CS.NET id aa05094; 5 Dec 88 23:00 EST 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 6 Dec 88 23:01:17 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 6 Dec 88 23:00:04 EST Received: by ucsd.edu (5.60/UCSD-1.0); Tue, 6 Dec 88 20:00:16 PST id AA26131 for @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Date: Tue, 6 Dec 88 20:00:16 PST Message-Id: <8812070400.AA26131@ucsd.edu> From: Postmaster@ucsd.edu Subject: Waiting Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 1 days (24 hours), your message to the following people: bam (host=bang) has not yet been delivered. Attempts to deliver the message will continue for 6 more days. No further action is required by you. ----- Queued message begins ----- Date: 6 Dec 88 01:18:05 GMT From: ucsd!chem.UCSD.EDU!condon@speedy.wisc.edu (Anne Condon) Subject: NetBIOS Reference To: mc.lcs.mit.edu!info-pcnet 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 .....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Dec 88 05:32:29 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 02:10:17 EST Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 7 Dec 88 02:10:49 EST Received: from relay2.cs.net by RELAY.CS.NET id bc24064; 6 Dec 88 21:13 EST Date: Tue, 6 Dec 88 20:16:34 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.ee03809) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id ee03809; 5 Dec 88 23:34 EST Received: from ai.ai.mit.edu by RELAY.CS.NET id aa05094; 5 Dec 88 23:00 EST 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: 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 7 Dec 88 12:32:41 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 12:28:34 EST Date: Wed, 7 Dec 88 12:29:10 EST From: Communications Satellite Subject: Msg of Wednesday, 7 December 1988 12:25-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <500173.881207@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GRAN!JAN@NTA-ODIN.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [PCNET;PCNET DIS]), from INFO-PCNET ============ Failed message follows: ============ 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 7 Dec 88 12:35:21 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Dec 88 12:33:41 EST Date: Wed, 07 Dec 88 12:33:39 EST From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Wed, 07 Dec 88 12:33:36 EST 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 7677 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 7677 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7677; Wed, 07 Dec 88 12:33:22 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 07 Dec 88 12:33:17 EST 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 , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Dec 88 12:57:26 EST Received: from unix.cis.pittsburgh.edu (TCP 20044602412) by MC.LCS.MIT.EDU 7 Dec 88 12:56:22 EST Received: by unix.cis.pittsburgh.edu (5.54/6.30) id AA03840; Wed, 7 Dec 88 12:56:26 EST Message-Id: <8812071756.AA03840@unix.cis.pittsburgh.edu> Date: Wed, 7 Dec 88 12:55 EST From: PMDF Mail Server Subject: Undeliverable mail To: info-pcnet-request@mc.lcs.mit.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from MITVMA.MIT.EDU by vms.cis.pittsburgh.edu; Wed, 7 Dec 88 12:54 EST Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7677; Wed, 07 Dec 88 12:33:22 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 07 Dec 88 12:33:17 EST 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@unix.cis.pittsburgh.edu Subject: Re: NetBIOS Reference Sender: info-pcnet-request%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu To: info-pcnet%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu References: <6791@spool.cs.wisc.edu> Organization: Amoco Production Co, Tulsa Research Center Message-Id: <652@flyer.apctrc.UUCP> 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 7 Dec 88 14:08:12 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 13:14:14 EST Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Dec 88 12:30:59 EST Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 7 Dec 88 09:31:12 PST Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AB19771; Wed, 7 Dec 88 09:31:12 PST Date: Wed, 7 Dec 88 09:31:12 PST From: MAILER-DAEMON@sumex-aim.stanford.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8812071731.AB19771@sumex-aim.stanford.edu> To: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- Connected to panda.stanford.edu: >>> RCPT To: <<< 550 ... User unknown: Address already in use 550 ... User unknown ----- Unsent message follows ----- Return-Path: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Received: from SAIL.Stanford.EDU by sumex-aim.stanford.edu (4.0/inc-1.0) id AA19769; Wed, 7 Dec 88 09:31:12 PST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 09:30:39 PST 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 7 Dec 88 14:14:58 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 13:37:16 EST Received: from VLSI.JPL.NASA.GOV (TCP 20045210004) by AI.AI.MIT.EDU 7 Dec 88 13:33:57 EST Date: Wed, 7 Dec 88 10:10:53 PST From: Delivr@VLSI.JPL.NASA.GOV Subject: Undeliverable Mail To: info-pcnet-request%mc.lcs.mit.edu%MC.LCS.MIT.EDU%AI.AI.MIT.EDU@VLSI.JPL.NASA.GOV Comment: reason for return -- Comment: %MAIL-E-SYNTAX, error parsing 'LYMAN@JATO.JPL.NASA.GOV' Comment: the affected addresses follow ... Comment: LYMAN Start of returned message Received: from AI.AI.MIT.EDU by VLSI.JPL.NASA.GOV with INTERNET ; Wed, 7 Dec 88 09:59:52 PST 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 End of returned message  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Dec 88 15:17:33 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 15:16:25 EST Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 7 Dec 88 15:14:58 EST Date: Wed, 7 Dec 88 13:16:25 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aa08167) To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'INFO-PCNET@ADAM.DG.COM (host: adam.dg.com) (queue: dg)' for the following reason: ' ... User unknown: error 24' Your message follows: Received: from ai.ai.mit.edu by RELAY.CS.NET id aa08167; 7 Dec 88 13:04 EST 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 7 Dec 88 16:22:08 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 15:35:07 EST Received: from RELAY.CS.NET (TCP 1201000005) by AI.AI.MIT.EDU 7 Dec 88 15:35:16 EST Received: from relay2.cs.net by RELAY.CS.NET id ac08747; 7 Dec 88 13:39 EST Date: Wed, 7 Dec 88 13:27:54 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aa18854) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id aa18854; 7 Dec 88 13:05 EST Received: from ai.ai.mit.edu by RELAY.CS.NET id aa08167; 7 Dec 88 13:04 EST 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: "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 7 Dec 88 16:36:13 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Dec 88 15:50:04 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0915; Wed, 07 Dec 88 15:50:04 EST Received: from STANFORD.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0913; Wed, 07 Dec 88 15:50:00 EST Date: Wed, 7 Dec 88 12:51:18 PST To: info-pcnet-request@mc.lcs.mit.edu From: "homo obsolescensis" Subject: please unsub me. thanks  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 7 Dec 88 17:36:07 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 7 Dec 88 17:34:57 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 2774; Wed, 07 Dec 88 17:34:50 EST Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 2772; Wed, 07 Dec 88 17:34:14 EST Received: from DBNRHRZ1.BITNET by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 3084; Wed, 07 Dec 88 23:32:28 MEZ Date: Wed, 07 Dec 88 23:32:28 MEZ From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 DBNRHRZ1.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 DBNRHRZ1.BITNET Hello MITVMA.MIT.EDU 050 TICK 7677 250 7677 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: UZR506 050 QUIT 221 DBNRHRZ1.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 3081; Wed, 07 Dec 88 23:32:27 MEZ Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 7677; Wed, 07 Dec 88 12:33:22 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 07 Dec 88 12:33:17 EST 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 7 Dec 88 19:19:56 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 13:05:06 EST Date: Wed, 7 Dec 88 13:05:41 EST From: Communications Satellite Subject: Msg of Wednesday, 7 December 1988 12:25-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <500174.881207@AI.AI.MIT.EDU> FAILED: WHITE at SUMEX-AIM.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: incoming-info-pcnet at COLUMBIA.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} FAILED: dist-info-pcnet at LOUIE.UDEL.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "dist-info-pcnet@LOUIE.UDEL.EDU"} FAILED: smith.umn-cs at RELAY.CS.NET; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "smith.umn-cs@RELAY.CS.NET"} Failed message follows: ------- 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 7 Dec 88 22:21:03 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 7 Dec 88 22:19:09 EST Received: from UACSC1.ALBANY.EDU (TCP 20063000402) by AI.AI.MIT.EDU 7 Dec 88 22:18:55 EST Date: 7 Dec 88 22:20 EST From: Postmaster@UACSC1.ALBANY.EDU To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Subject: Mail Delivery The message below has not been delivered. This message was automatically generated. %DELIVER-W-NO_MAILBOX, No Such user as 'J.Bunch' here ==== Unsent Message Follows ==== Received: from AI.AI.MIT.EDU by UACSC1.ALBANY.EDU ; 7-DEC-1988 22:16:28.16 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 8 Dec 88 11:33:34 EST Received: from beaver.cs.washington.edu (TCP 20027600401) by MC.LCS.MIT.EDU 8 Dec 88 03:45:26 EST Received: by beaver.cs.washington.edu (5.59/6.12) id AA09678; Thu, 8 Dec 88 00:45:40 PST Return-Path: Received: by ssc-vax (4.12/4.7) id AA29213; Wed, 7 Dec 88 17:42:47 pst Date: 6 Dec 88 20:25:44 GMT From: ssc-vax!MAILER-DAEMON@beaver.cs.washington.edu (Mail Delivery Subsystem) Subject: Returned mail: Remote protocol error Message-Id: <8812080142.AA29213@ssc-vax> To: uw-beaver!mc.lcs.mit.edu!info-pcnet-request@beaver.cs.washington.edu ----- Transcript of session follows ----- >>> MAIL From: <<< 501 Bad argument syntax 554 "payzer%eagle.decnet"@base-vax... Remote protocol error: Bad file number ----- Unsent message follows ----- Received: by ssc-vax (4.12/4.7) id AA29211; Wed, 7 Dec 88 17:42:47 pst Received: from AI.AI.MIT.EDU by beaver.cs.washington.edu (5.59/6.12) id AA06518; Wed, 7 Dec 88 09:55:02 PST 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: uw-beaver!uunet.uu.net!apctrc!zgel05 (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: uw-beaver!mc.lcs.mit.edu!info-pcnet-request 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 8 Dec 88 16:54:27 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 8 Dec 88 14:59:50 EST Received: by ucsd.edu (5.60/UCSD-1.0); Thu, 8 Dec 88 12:00:09 PST id AA06976 for @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Date: Thu, 8 Dec 88 12:00:09 PST Message-Id: <8812082000.AA06976@ucsd.edu> From: Postmaster@ucsd.edu Subject: Waiting Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 1 days (24 hours), your message to the following people: bam (host=bang) has not yet been delivered. Attempts to deliver the message will continue for 6 more days. No further action is required by you. ----- Queued message begins ----- Date: 6 Dec 88 20:25:44 GMT From: ucsd!chem.UCSD.EDU!apctrc!zgel05@uunet.uu.net (George E. Lehmann) Subject: Re: NetBIOS Reference To: mc.lcs.mit.edu!info-pcnet 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 .....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 9 Dec 88 05:13:49 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 88 04:33:23 EST Date: Fri, 9 Dec 88 03:50:00 EST From: Communications Satellite Subject: Msg of Monday, 5 December 1988 22:15-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <501324.881209@AI.AI.MIT.EDU> FAILED: CC.Padgett at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. FAILED: G.TI.DAK at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 9 Dec 88 05:14:03 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 88 04:33:33 EST Date: Fri, 9 Dec 88 03:50:08 EST From: Communications Satellite Subject: Msg of Wednesday, 7 December 1988 12:25-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <501325.881209@AI.AI.MIT.EDU> FAILED: CC.Padgett at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. FAILED: G.TI.DAK at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 9 Dec 88 23:10:29 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 88 23:09:17 EST Date: Fri, 9 Dec 88 23:10:10 EST From: Communications Satellite Subject: Msg of Monday, 5 December 1988 22:15-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <501988.881209@AI.AI.MIT.EDU> FAILED: rdavenport at GTEWIS.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 9 Dec 88 23:10:45 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 9 Dec 88 23:09:28 EST Date: Fri, 9 Dec 88 23:10:19 EST From: Communications Satellite Subject: Msg of Wednesday, 7 December 1988 12:25-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <501989.881209@AI.AI.MIT.EDU> FAILED: rdavenport at GTEWIS.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 cs2.wsu.edu (TCP 30007754064) by AI.AI.MIT.EDU 12 Dec 88 18:38:20 EST Received: by cs2.wsu.edu (5.59/25-eef) id AA15781; Mon, 12 Dec 88 18:06:42 EST Date: Mon, 12 Dec 88 18:06:42 EST From: Greg Bell - System Staff Message-Id: <8812122306.AA15781@cs2.wsu.edu> Apparently-To: info-pcnet-request@ai.ai.mit.edu Please add info-pcnet-user@cs2.wsu.edu to your mailing list. Thanks.  Received: from nswc-g.ARPA (TCP 3200200124) by AI.AI.MIT.EDU 13 Dec 88 14:29:12 EST Date: Tue, 13 Dec 88 14:28:03 est From: operator@nswc-g.ARPA Full-Name: nswc-g To: Info-PCNet-Request@ai.ai.mit.edu Subject: Please, Change SURF-PCNET Host. Cc: SURF-PCNET@relay-nswc.navy.mil, operator@nswc-g.arpa Michael A. Patton, Please, re-home local-ALIAS SURF-PCNET from "...@nswc-g.arpa" to "...@relay-nswc.navy.mil" I maintain the local-ALIAS. Mike Pabrinkis (K33) operator@nswc-g.arpa NAVAL SURFACE WARFARE CENTER operator@relay-nswc.navy.mil Dahlgren, VA 22448 (703)663-8166 - (AV)249-8166  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 15:13:48 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 14:46:25 EST Date: Wed, 14 Dec 88 14:47:56 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <504657.881214@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GRAN!JAN@NTA-ODIN.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [PCNET;PCNET DIS]), from INFO-PCNET ============ Failed message follows: ============ 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 15:46:14 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 15:22:41 EST Date: Wed, 14 Dec 88 15:24:19 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <504658.881214@AI.AI.MIT.EDU> FAILED: jedi at CLARK-EMH.ARPA; Funny reply from foreign host after sending message. Last reply was: {554-sndmsg could not deliver this message; exit status: 35 554 reason: No such file or directory.} FAILED: WHITE at SUMEX-AIM.STANFORD.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: incoming-info-pcnet at COLUMBIA.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: dist-info-pcnet at LOUIE.UDEL.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "dist-info-pcnet@LOUIE.UDEL.EDU"} Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 15:54:15 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 15:28:49 EST Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 88 14:50:08 EST Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:48:53 PST Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AB01407; Wed, 14 Dec 88 11:48:47 PST Date: Wed, 14 Dec 88 11:48:47 PST From: MAILER-DAEMON@sumex-aim.stanford.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8812141948.AB01407@sumex-aim.stanford.edu> To: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- Connected to panda.stanford.edu: >>> RCPT To: <<< 550 ... User unknown: Address already in use 550 ... User unknown ----- Unsent message follows ----- Return-Path: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Received: from SAIL.Stanford.EDU by sumex-aim.stanford.edu (4.0/inc-1.0) id AA01403; Wed, 14 Dec 88 11:48:47 PST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 11:48:17 PST 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 16:13:55 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 15:47:20 EST Received: from UACSC1.ALBANY.EDU (TCP 20063000402) by AI.AI.MIT.EDU 14 Dec 88 15:22:54 EST Date: 14 Dec 88 15:23 EST From: Postmaster@UACSC1.ALBANY.EDU To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Subject: Mail Delivery The message below has not been delivered. This message was automatically generated. %DELIVER-W-NO_MAILBOX, No Such user as 'J.Bunch' here ==== Unsent Message Follows ==== Received: from AI.AI.MIT.EDU by UACSC1.ALBANY.EDU ; 14-DEC-1988 15:18:59.98 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:06:46 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Dec 88 16:09:43 EST Date: Wed, 14 Dec 88 16:09:01 EST From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Wed, 14 Dec 88 16:08:59 EST 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 0608 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 0608 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0608; Wed, 14 Dec 88 16:08:46 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 14 Dec 88 16:08:06 EST 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 , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:07:08 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Dec 88 16:11:13 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 0702; Wed, 14 Dec 88 16:10:29 EST Received: from STANFORD.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0701; Wed, 14 Dec 88 16:10:27 EST Date: Wed, 14 Dec 88 13:04:36 PST To: info-pcnet-request@mc.lcs.mit.edu From: "homo obsolescensis" Subject: please unsubscribe me. thanks  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:08:11 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 16:16:50 EST Date: Wed, 14 Dec 88 16:18:31 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <504765.881214@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:08:46 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 16:20:15 EST Date: Wed, 14 Dec 88 16:21:52 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <504767.881214@AI.AI.MIT.EDU> FAILED: smith.umn-cs at RELAY.CS.NET; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "smith.umn-cs@RELAY.CS.NET"} Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:11:06 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 16:33:33 EST Received: from VLSI.JPL.NASA.GOV (TCP 20045210004) by AI.AI.MIT.EDU 14 Dec 88 16:35:01 EST Date: Wed, 14 Dec 88 12:34:08 PST From: Delivr@VLSI.JPL.NASA.GOV Subject: Undeliverable Mail To: info-pcnet-request%mc.lcs.mit.edu%MC.LCS.MIT.EDU%AI.AI.MIT.EDU@VLSI.JPL.NASA.GOV Comment: reason for return -- Comment: %MAIL-E-SYNTAX, error parsing 'LYMAN@JATO.JPL.NASA.GOV' Comment: the affected addresses follow ... Comment: LYMAN Start of returned message Received: from AI.AI.MIT.EDU by VLSI.JPL.NASA.GOV with INTERNET ; Wed, 14 Dec 88 12:16:09 PST 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 End of returned message  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:24:17 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 14 Dec 88 16:50:46 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 1334; Wed, 14 Dec 88 16:49:10 EST Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 1333; Wed, 14 Dec 88 16:45:47 EST Received: from DBNRHRZ1.BITNET by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 5624; Wed, 14 Dec 88 22:43:55 MEZ Date: Wed, 14 Dec 88 22:43:54 MEZ From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 DBNRHRZ1.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 DBNRHRZ1.BITNET Hello MITVMA.MIT.EDU 050 TICK 0608 250 0608 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: UZR506 050 QUIT 221 DBNRHRZ1.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 5621; Wed, 14 Dec 88 22:43:54 MEZ Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0608; Wed, 14 Dec 88 16:08:46 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 14 Dec 88 16:08:06 EST 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 17:24:29 EST Received: from unix.cis.pittsburgh.edu (TCP 20044602412) by MC.LCS.MIT.EDU 14 Dec 88 16:54:32 EST Received: by unix.cis.pittsburgh.edu (5.54/6.30) id AA11226; Wed, 14 Dec 88 16:54:20 EST Message-Id: <8812142154.AA11226@unix.cis.pittsburgh.edu> Date: Wed, 14 Dec 88 16:52 EST From: PMDF Mail Server Subject: Undeliverable mail To: info-pcnet-request@mc.lcs.mit.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from MITVMA.MIT.EDU by vms.cis.pittsburgh.edu; Wed, 14 Dec 88 16:51 EST Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 0608; Wed, 14 Dec 88 16:08:46 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Wed, 14 Dec 88 16:08:06 EST 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@unix.cis.pittsburgh.edu Subject: Micro to mainframe gateway connections Sender: info-pcnet-request%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu To: info-pcnet%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu Organization: ISC Systems Corp. Spokane, Wa. Message-Id: <188@tau-ceti.ISCS.COM> 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 19:21:18 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 19:06:24 EST Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 14 Dec 88 19:07:29 EST Received: from relay2.cs.net by RELAY.CS.NET id at13436; 14 Dec 88 17:55 EST Date: Wed, 14 Dec 88 17:32:49 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.ab08630) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id ab08630; 14 Dec 88 16:22 EST Received: from ai.ai.mit.edu by RELAY.CS.NET id aa11985; 14 Dec 88 16:20 EST 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: 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 19:43:23 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 14 Dec 88 19:28:41 EST Received: from optimis-pent.arpa (TCP 3201000032) by AI.AI.MIT.EDU 14 Dec 88 19:30:15 EST Date: 14 Dec 88 18:21:47 EDT From: "SMTP MAILER" Subject: Mail Delivery Problem To: "info-pcnet-request" <@ai.ai.mit.edu,@mc.lcs.mit.edu:info-pcnet-request@mc.lcs.mit.edu> ----Reason for mail failure follows---- Sending mail to recipient(s) kanti : Couldn't make final delivery. %MAIL-W-WRITEERR, error writing DJA2:[KANTI]MAIL.MAI;1 ----Transcript of message follows---- Received: from AI.AI.MIT.EDU by optimis-pent.arpa with SMTP ; Wed, 14 Dec 88 18:14:45 EDT 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 14 Dec 88 20:35:40 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 14 Dec 88 20:20:12 EST Received: by ucsd.edu (5.60/UCSD-1.0) Wed, 14 Dec 88 12:00:26 PST; id AA23308 for chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU Date: Wed, 14 Dec 88 12:00:26 PST Message-Id: <8812142000.AA23308@ucsd.edu> From: Postmaster@ucsd.edu Cc: Postmaster Subject: Failed Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 7 days (168 hours), your message to the following people: bam (host=bang) could not be delivered. ----- Unsent message follows ----- Received: from chema.ucsd.edu by ucsd.edu (5.60/UCSD-1.0); Wed, 7 Dec 88 11:50:16 PST id AA11095 for bam Received: by chem.chem.ucsd.edu (5.51) id AA13296; Wed, 7 Dec 88 11:51:08 PST Received: from nosc.UUCP by ucsd.edu (5.60/UCSD-1.0) via UUCP; Wed, 7 Dec 88 11:42:59 PST id AA10957 for Received: from AI.AI.MIT.EDU by trout.nosc.mil (5.59/1.27) id AA03791; Wed, 7 Dec 88 11:31:27 PST 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: ucsd!chem.UCSD.EDU!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: ucsd!chem.UCSD.EDU!info-pcnet-request@mc.lcs.mit.edu To: mc.lcs.mit.edu!info-pcnet 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 14 Dec 88 22:20:17 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 14 Dec 88 22:17:28 EST Received: by ucsd.edu (5.60/UCSD-1.0) Mon, 12 Dec 88 20:00:14 PST; id AA08846 for chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU Date: Mon, 12 Dec 88 20:00:14 PST Message-Id: <8812130400.AA08846@ucsd.edu> From: Postmaster@ucsd.edu Cc: Postmaster Subject: Failed Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 7 days (168 hours), your message to the following people: bam (host=bang) could not be delivered. ----- Unsent message follows ----- Received: from chema.ucsd.edu by ucsd.edu (5.60/UCSD-1.0); Mon, 5 Dec 88 19:48:15 PST id AA01067 for bam Received: by chem.chem.ucsd.edu (5.51) id AA29031; Mon, 5 Dec 88 19:49:11 PST Received: from nosc.UUCP by ucsd.edu (5.60/UCSD-1.0) via UUCP; Mon, 5 Dec 88 19:32:58 PST id AA00761 for Received: from AI.AI.MIT.EDU by trout.nosc.mil (5.59/1.27) id AA29154; Mon, 5 Dec 88 19:29:48 PST 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: ucsd!chem.UCSD.EDU!condon@speedy.wisc.edu (Anne Condon) Subject: NetBIOS Reference Message-Id: <6791@spool.cs.wisc.edu> Sender: ucsd!chem.UCSD.EDU!info-pcnet-request@mc.lcs.mit.edu To: mc.lcs.mit.edu!info-pcnet 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 Dec 88 05:35:49 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 88 03:01:21 EST Date: Thu, 15 Dec 88 02:47:19 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <505144.881215@AI.AI.MIT.EDU> FAILED: CC.Padgett at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. FAILED: G.TI.DAK at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Dec 88 16:34:25 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 15 Dec 88 16:31:43 EST Date: Thu, 15 Dec 88 16:33:34 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <505558.881215@AI.AI.MIT.EDU> FAILED: clmanager at GARFLD.MSFC.NASA.GOV; Recipient name apparently rejected. Last reply was: {550 User "clmanager" Unknown.} Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 15 Dec 88 17:05:23 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 15 Dec 88 17:00:50 EST Received: by ucsd.edu (5.60/UCSD-1.0) Thu, 15 Dec 88 14:00:10 PST; id AA23545 for @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Date: Thu, 15 Dec 88 14:00:10 PST Message-Id: <8812152200.AA23545@ucsd.edu> From: Postmaster@ucsd.edu Subject: Waiting Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 1 days (24 hours), your message to the following people: bam (host=bang) has not yet been delivered. Attempts to deliver the message will continue for 6 more days. No further action is required by you. ----- Queued message begins ----- Date: 14 Dec 88 00:07:24 GMT From: ucsd!chem.UCSD.EDU!iscuva!tau-ceti!gregb@uunet.uu.net (Greg Baker) Subject: Micro to mainframe gateway connections To: mc.lcs.mit.edu!info-pcnet 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. .....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Dec 88 18:27:24 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Dec 88 18:24:35 EST Date: Sat, 17 Dec 88 18:26:37 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <506800.881217@AI.AI.MIT.EDU> FAILED: rdavenport at GTEWIS.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Dec 88 20:49:34 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Dec 88 20:46:30 EST Date: Sat, 17 Dec 88 20:48:32 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <506854.881217@AI.AI.MIT.EDU> FAILED: ssc-vax!stanford at BEAVER.CS.WASHINGTON.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 18 Dec 88 23:22:05 EST Received: from PARIS.ICS.UCI.EDU (TCP 20060600062) by MC.LCS.MIT.EDU 18 Dec 88 23:19:33 EST Received: from ics.uci.edu by PARIS.ICS.UCI.EDU id ax05406; 18 Dec 88 19:58 PST Received: from ics.uci.edu by ICS.UCI.EDU id aa04057; 18 Dec 88 19:29 PST To: info-pcnet-request <@PARIS.ICS.UCI.EDU:info-pcnet-request@mc.lcs.mit.EDU> cc: record: ; Subject: Important Notice Date: Sun, 18 Dec 88 19:29:23 -0800 From: Mark Nagel Message-ID: <8812181929.aa04057@ICS.UCI.EDU> To the maintainer of info-pcnet: This letter is to inform you that the site name 'uci.edu' will soon be relegated to general campus use (as opposed to its current affiliation with the Department of ICS. Please change our destination address in this mailing list so that mail is delivered to the host 'ics.uci.edu' rather than 'uci.edu'. Ignore this letter if you already send to the host 'ics.uci.edu'. Please contact if you have any questions. Thank you, Mark Nagel UCI-ICS Support Group  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 19 Dec 88 08:42:52 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 Dec 88 08:39:53 EST Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 19 Dec 88 08:41:31 EST Date: Mon, 19 Dec 88 7:55:24 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Waiting mail (msg.aa11985) To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU After 5 days (110 hours), your message has not yet been fully delivered. Attempts to deliver the message will continue for 2 more days. No further action is required by you. Delivery attempts are still pending for the following address(es): INFO-PCNET@ADAM.DG.COM (host: adam.dg.com) (queue: dg) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message begins as follows: Received: from ai.ai.mit.edu by RELAY.CS.NET id aa11985; 14 Dec 88 16:20 EST 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 ...  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 20 Dec 88 07:03:26 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Dec 88 06:55:18 EST Date: Tue, 20 Dec 88 06:57:00 EST From: Communications Satellite Subject: Msg of Wednesday, 14 December 1988 14:38-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <507940.881220@AI.AI.MIT.EDU> FAILED: LOCAL-INFO-PCNET at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. FAILED: CONTRACTOR at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. FAILED: EStefferud at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Dec 88 10:00:29 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 21 Dec 88 09:53:19 EST Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 21 Dec 88 09:54:58 EST Date: Wed, 21 Dec 88 8:41:11 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aa11985) To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU After 7 days (159 hours), your message could not be fully delivered. It failed to be received by the following address(es): INFO-PCNET@ADAM.DG.COM (host: adam.dg.com) (queue: dg) Problems usually are due to service interruptions at the receiving machine. Less often, they are caused by the communication system. Your message follows: Received: from ai.ai.mit.edu by RELAY.CS.NET id aa11985; 14 Dec 88 16:20 EST 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 MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 21 Dec 88 19:10:32 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 21 Dec 88 17:01:16 EST Received: by ucsd.edu; id AA08381 sendmail 5.60/UCSD-1.0, Wed, 21 Dec 88 14:00:07 PST for @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu Date: Wed, 21 Dec 88 14:00:07 PST Message-Id: <8812212200.AA08381@ucsd.edu> From: Postmaster@ucsd.edu Cc: Postmaster Subject: Failed Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 7 days (168 hours), your message to the following people: bam (host=bang) could not be delivered. ----- Unsent message follows ----- Received: from chema.ucsd.edu by ucsd.edu (5.60/UCSD-1.0) Wed, 14 Dec 88 13:32:21 PST; id AA25350 for bam Received: by chem.chem.ucsd.edu (5.51) id AA13163; Wed, 14 Dec 88 13:33:00 PST Received: from nosc.UUCP by ucsd.edu (5.60/UCSD-1.0) via UUCP Wed, 14 Dec 88 11:59:45 PST; id AA23286 Received: from AI.AI.MIT.EDU by trout.nosc.mil (5.59/1.27) id AA07114; Wed, 14 Dec 88 11:54:59 PST 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: ucsd!chem.UCSD.EDU!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: ucsd!chem.UCSD.EDU!info-pcnet-request@mc.lcs.mit.edu To: mc.lcs.mit.edu!info-pcnet 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 csd360b.erim.org (TCP 4361020030) by AI.AI.MIT.EDU 16 Jan 89 15:25:25 EST Received: by csd360b.erim.org (4.0/SMI-4.0) id AA15950; Mon, 16 Jan 89 15:17:47 EST Date: Mon, 16 Jan 89 15:17:47 EST From: jgarb@erim.org (Joe Garbarino) Message-Id: <8901162017.AA15950@csd360b.erim.org> To: info-pcnet-request@ai.ai.mit.edu Subject: INFO-PCNET SUBSCRIBE INFO-PCNET info-pcnet-mail@csd360b.erim.org  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 89 16:40:30 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 89 16:22:37 EST Date: Mon, 16 Jan 89 16:29:53 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <520923.890116@AI.AI.MIT.EDU> ============ A copy of your message is being returned, because: ============ "GRAN!JAN@NTA-ODIN.ARPA" at AI.AI.MIT.EDU is an unknown recipient. This name came from the expansion of (@FILE [PCNET;PCNET DIS]), from INFO-PCNET ============ Failed message follows: ============ 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 16 Jan 89 18:36:14 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 89 17:31:09 EST Date: Mon, 16 Jan 89 17:38:23 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <520924.890116@AI.AI.MIT.EDU> FAILED: incoming-info-pcnet at COLUMBIA.EDU; Recipient name apparently rejected. Last reply was: {550 ... User unknown} FAILED: sguthery.slb-doll at RELAY.CS.NET; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "sguthery.slb-doll@RELAY.CS.NET"} FAILED: smith.umn-cs at RELAY.CS.NET; Recipient name apparently rejected. Last reply was: {550 (BHST) Unknown host/domain name in "smith.umn-cs@RELAY.CS.NET"} Failed message follows: ------- 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 16 Jan 89 19:42:16 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 16 Jan 89 18:48:20 EST Date: Mon, 16 Jan 89 18:48:03 EST From: SMTP@MITVMA.MIT.EDU To: info-pcnet-request@mc.lcs.mit.edu Subject: Undeliverable Mail Error in Batch SMTP Command Sequence. Unable to deliver mail to some/all recipients. Reply codes with first digit = '4' or '5' are error replies: 220 MITVMA.MIT.EDU running IBM VM SMTP R1.1 on Mon, 16 Jan 89 18:48:01 EST 050 HELO MITVMA.MIT.EDU 250 MITVMA.MIT.EDU 050 TICK 3751 250 OK 050 MAIL FROM: 250 OK 050 RCPT TO: 550 Host 'NOCMI.BITNET' Unknown 050 DATA 503 No Recipients specified ** Text of Mail follows ** HELO MITVMA.MIT.EDU TICK 3751 MAIL FROM: RCPT TO: DATA Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3751; Mon, 16 Jan 89 18:47:08 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 16 Jan 89 18:46:57 EST 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. , QUIT  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 Jan 89 19:47:12 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 89 19:19:42 EST Date: Mon, 16 Jan 89 19:26:51 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <521042.890116@AI.AI.MIT.EDU> FAILED: dist-info-pcnet at LOUIE.UDEL.EDU; Recipient name apparently rejected. Last reply was: {550 (USER) Unknown user name in "dist-info-pcnet@LOUIE.UDEL.EDU"} Failed message follows: ------- 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 16 Jan 89 22:50:13 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 89 22:39:50 EST Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 16 Jan 89 22:45:59 EST Received: from relay2.cs.net by RELAY.CS.NET id aa06688; 16 Jan 89 19:25 EST Date: Mon, 16 Jan 89 19:04:59 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.ae05598) To: @RELAY.CS.NET,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'robertj@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following reason: ' ... User unknown' Your message follows: Received: from relay.cs.net by RELAY.CS.NET id ae05598; 16 Jan 89 17:26 EST Received: from ai.ai.mit.edu by RELAY.CS.NET id aa04924; 16 Jan 89 17:30 EST 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: 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 16 Jan 89 23:22:34 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 16 Jan 89 23:13:00 EST Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 16 Jan 89 23:20:02 EST Date: Mon, 16 Jan 89 20:14:20 EST From: RELAY Mail System (MMDF) Sender: mmdf@RELAY.CS.NET Subject: Failed mail (msg.aa04924) To: @AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@MC.LCS.MIT.EDU Your message could not be delivered to 'INFO-PCNET@ADAM.DG.COM (host: adam.dg.com) (queue: dg)' for the following reason: ' ... User unknown: error 24' Your message follows: Received: from ai.ai.mit.edu by RELAY.CS.NET id aa04924; 16 Jan 89 17:30 EST 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 17 Jan 89 03:59:24 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jan 89 01:20:02 EST Received: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 17 Jan 89 01:27:03 EST Received: from mailgw.cc.umich.edu by life.ai.mit.edu; Tue, 17 Jan 89 01:15:53 EST Received: from umix.cc.umich.edu by mailgw.cc.umich.edu (5.59/1.0) id AA09183; Tue, 17 Jan 89 01:12:18 EST Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA23428; Tue, 17 Jan 89 01:17:05 EST Received: from umix.cc.umich.edu by um.cc.umich.edu via UMnet; Tue, 17 Jan 89 01:13:01 EST Received: by umix.cc.umich.edu id AA17124; Mon, 16 Jan 89 17:45:23 EST Date: Mon, 16 Jan 89 17:45:23 EST From: Mailer-Daemon@umix.cc.umich.edu Message-Id: <8901162245.AA17124@umix.cc.umich.edu> To: <@um.cc.umich.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Subject: Returned mail: Remote protocol error ----- Transcript of session follows ----- >>> MAIL From:<@um.cc.umich.edu,@AI.AI.MIT.EDU:@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> <<< 501 Syntax Error. Malformed Local Part 554 <@dsc.umich.edu:info-pcnet@umichda.bitnet>... Remote protocol error: Bad file number ----- Unsent message follows ----- Received: by umix.cc.umich.edu (5.54/umix-2.0) id AA17115; Mon, 16 Jan 89 17:45:23 EST Received: from umix.cc.umich.edu by um.cc.umich.edu via UMnet; Mon, 16 Jan 89 17:38:18 EST Received: by umix.cc.umich.edu id AA16446; Mon, 16 Jan 89 17:05:47 EST Received: from MC.LCS.MIT.EDU by AI.AI.MIT.EDU 16 Jan 89 16:24:06 EST Received: from BLOOM-BEACON.MIT.EDU 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 Date: 15 Jan 89 18:58:30 GMT From: martillo%cpoint%jjmhome%m2c.uucp@husc6.harvard.edu Organization: Clearpoint Research Corp., Hopkinton Mass. Message-Id: <1977@cpoint.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Subject: XNET Summary 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 17 Jan 89 04:18:25 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jan 89 03:47:25 EST Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 17 Jan 89 03:04:19 EST Received: from sumex-aim.stanford.edu by SAIL.Stanford.EDU with TCP; 16 Jan 89 23:56:44 PST Received: by sumex-aim.stanford.edu (4.0/inc-1.0) id AB02650; Mon, 16 Jan 89 23:56:29 PST Date: Mon, 16 Jan 89 23:56:29 PST From: MAILER-DAEMON@sumex-aim.stanford.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8901170756.AB02650@sumex-aim.stanford.edu> To: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> ----- Transcript of session follows ----- Connected to panda.stanford.edu: >>> RCPT To: <<< 550 ... User unknown 550 ... User unknown 550 sendmail-error... User unknown ----- Unsent message follows ----- Return-Path: <@sail.stanford.edu,@AI.AI.MIT.EDU,@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu> Received: from SAIL.Stanford.EDU by sumex-aim.stanford.edu (4.0/inc-1.0) id AA24576; Mon, 16 Jan 89 14:08:11 PST Received: from AI.AI.MIT.EDU by SAIL.Stanford.EDU with TCP; 16 Jan 89 14:07:48 PST 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 17 Jan 89 05:56:33 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Jan 89 05:34:08 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6528; Tue, 17 Jan 89 05:33:02 EST Received: from DBNRHRZ1.BITNET by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6527; Tue, 17 Jan 89 05:32:54 EST Received: from DBNRHRZ1.BITNET by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 5191; Tue, 17 Jan 89 02:10:34 MEZ Date: Tue, 17 Jan 89 02:10:33 MEZ From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 DBNRHRZ1.BITNET Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 DBNRHRZ1.BITNET Hello MITVMA.MIT.EDU 050 TICK 3751 250 3751 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: UZR506 050 QUIT 221 DBNRHRZ1.BITNET Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by DBNRHRZ1.BITNET (Mailer X1.25) with BSMTP id 5188; Tue, 17 Jan 89 02:10:31 MEZ Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3751; Mon, 16 Jan 89 18:47:08 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 16 Jan 89 18:46:57 EST 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 17 Jan 89 05:57:08 EST Received: from MITVMA.MIT.EDU (TCP 2227000003) by MC.LCS.MIT.EDU 17 Jan 89 05:35:13 EST Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with BSMTP id 6531; Tue, 17 Jan 89 05:33:48 EST Received: from NUSVM.NUS.AC.SG by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 6529; Tue, 17 Jan 89 05:33:42 EST Received: from NUSVM.NUS.AC.SG by NUSVM.NUS.AC.SG (Mailer X1.25) with BSMTP id 2329; Tue, 17 Jan 89 09:43:11 SST Date: Tue, 17 Jan 89 09:43:10 SST From: Network Mailer To: info-pcnet-request@mc.lcs.mit.edu Subject: mail delivery error Batch SMTP transaction log follows: 220 NUSVM.NUS.AC.SG Columbia MAILER X1.25 BSMTP service ready. 050 HELO MITVMA.MIT.EDU 250 NUSVM.NUS.AC.SG Hello MITVMA.MIT.EDU 050 TICK 3751 250 3751 ... that's the ticket. 050 MAIL FROM: 250 ... sender OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 RCPT TO: 250 ... recipient OK. 050 DATA 354 Start mail input. End with . 554-Mail not delivered to some or all recipients: 554 No such local user: NCBITI 050 QUIT 221 NUSVM.NUS.AC.SG Columbia MAILER BSMTP service done. Original message follows: Received: from MITVMA.MIT.EDU by NUSVM.NUS.AC.SG (Mailer X1.25) with BSMTP id 2326; Tue, 17 Jan 89 09:43:07 SST Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3751; Mon, 16 Jan 89 18:47:08 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 16 Jan 89 18:46:57 EST 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 17 Jan 89 19:03:21 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jan 89 18:32:34 EST Received: from VLSI.JPL.NASA.GOV (TCP 20045210004) by AI.AI.MIT.EDU 17 Jan 89 18:38:15 EST Date: Tue, 17 Jan 89 15:29:26 PST From: Delivr@VLSI.JPL.NASA.GOV Subject: Undeliverable Mail To: info-pcnet-request%mc.lcs.mit.edu%MC.LCS.MIT.EDU%AI.AI.MIT.EDU@VLSI.JPL.NASA.GOV Comment: reason for return -- Comment: %MAIL-E-SYNTAX, error parsing 'LYMAN@JATO.JPL.NASA.GOV' Comment: the affected addresses follow ... Comment: LYMAN Start of returned message Received: from AI.AI.MIT.EDU by VLSI.JPL.NASA.GOV with INTERNET ; Tue, 17 Jan 89 15:24:10 PST 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. End of returned message  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Jan 89 20:09:21 EST Received: from clark-emh.arpa (TCP 3200200131) by MC.LCS.MIT.EDU 17 Jan 89 19:36:17 EST Date: Wed, 18 Jan 89 00:33:27 GMT From: Daemon Subject: Undeliverable mail To: info-pcnet-request@mc.lcs.mit.edu Mail could not be delivered to the following address(es): /usr/infomail/mailboxes/jedi@clark-emh.arpa: No such file or directory ------- Unsent message is below ------- 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 17 Jan 89 20:12:32 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 17 Jan 89 19:53:23 EST Received: by ucsd.edu; id AA07356 sendmail 5.60/UCSD-1.0, Tue, 17 Jan 89 15:00:17 PST for chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU Date: Tue, 17 Jan 89 15:00:17 PST Message-Id: <8901172300.AA07356@ucsd.edu> From: Postmaster@ucsd.edu Subject: Waiting Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 1 days (24 hours), your message to the following people: bam (host=bang) has not yet been delivered. Attempts to deliver the message will continue for 6 more days. No further action is required by you. ----- Queued message begins ----- Date: 15 Jan 89 18:58:30 GMT From: ucsd!chem.UCSD.EDU!m2c!jjmhome!cpoint!martillo@husc6.harvard.edu (Joacim Martillo) Subject: XNET Summary To: mc.lcs.mit.edu!info-pcnet I wrote this summary description of XNET and would appreciate comments. .....  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 17 Jan 89 21:26:30 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 17 Jan 89 21:05:45 EST Date: Tue, 17 Jan 89 18:31:06 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <521443.890117@AI.AI.MIT.EDU> FAILED: LEU at CAD.UCLA.EDU; Recipient name apparently rejected. Last reply was: {550 User 'LEU' Unknown} Failed message follows: ------- 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 18 Jan 89 04:56:35 EST Received: from unix.cis.pittsburgh.edu (TCP 20044602412) by MC.LCS.MIT.EDU 18 Jan 89 02:20:14 EST Received: by unix.cis.pittsburgh.edu (5.54/6.30) id AA03941; Wed, 18 Jan 89 02:18:28 EST Message-Id: <8901180718.AA03941@unix.cis.pittsburgh.edu> Date: Tue, 17 Jan 89 22:05 EST From: PMDF Mail Server Subject: Undeliverable mail To: info-pcnet-request@mc.lcs.mit.EDU The message could not be delivered to: Addressee: 000544 Reason: %MAIL-E-NOSUCHUSR, no such user 000544 at node CISVM2 Addressee: 334641 Reason: %MAIL-E-NOSUCHUSR, no such user 334641 at node CISVM2 ---------------------------------------- Received: from MITVMA.MIT.EDU by vms.cis.pittsburgh.edu; Tue, 17 Jan 89 22:05 EST Received: from MITVMA by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 3751; Mon, 16 Jan 89 18:47:08 EST Received: from AI.AI.MIT.EDU by MITVMA.MIT.EDU (IBM VM SMTP R1.1) with TCP; Mon, 16 Jan 89 18:46:57 EST 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@unix.cis.pittsburgh.edu Subject: XNET Summary Sender: info-pcnet-request%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu To: info-pcnet%mc.lcs.mit.EDU@unix.cis.pittsburgh.edu Organization: Clearpoint Research Corp., Hopkinton Mass. Message-Id: <1977@cpoint.UUCP> 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 19 Jan 89 04:34:30 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 19 Jan 89 02:10:31 EST Date: Thu, 19 Jan 89 01:35:53 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <522518.890119@AI.AI.MIT.EDU> FAILED: LOCAL-INFO-PCNET at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. FAILED: CONTRACTOR at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. FAILED: EStefferud at ECLA.USC.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 20 Jan 89 05:34:10 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jan 89 04:57:28 EST Date: Fri, 20 Jan 89 02:56:19 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <523316.890120@AI.AI.MIT.EDU> FAILED: CC.Padgett at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. FAILED: G.TI.DAK at R20.UTEXAS.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 20 Jan 89 05:57:40 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jan 89 05:30:13 EST Date: Fri, 20 Jan 89 02:54:26 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <523314.890120@AI.AI.MIT.EDU> FAILED: J.Bunch at UACSC1.ALBANY.EDU; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 20 Jan 89 06:19:53 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jan 89 05:31:03 EST Date: Fri, 20 Jan 89 02:57:18 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <523318.890120@AI.AI.MIT.EDU> FAILED: rdavenport at GTEWIS.ARPA; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 20 Jan 89 06:20:45 EST Received: from AI.AI.MIT.EDU (CHAOS 3130) by MC.LCS.MIT.EDU 20 Jan 89 05:31:38 EST Date: Fri, 20 Jan 89 02:59:41 EST From: Communications Satellite Subject: Msg of Monday, 16 January 1989 16:24-EST To: "@MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu"@MC.LCS.MIT.EDU Message-ID: <523319.890120@AI.AI.MIT.EDU> FAILED: kanti at PENTAGON-OPTI.ARMY.MIL; Host appears to be permanently down or not accepting mail. Failed message follows: ------- 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 22 Jan 89 11:48:33 EST Received: from beaver.cs.washington.edu (TCP 20027600401) by MC.LCS.MIT.EDU 22 Jan 89 11:47:51 EST Received: by beaver.cs.washington.edu (5.59/6.12) id AA26262; Sun, 22 Jan 89 08:00:49 PST Return-Path: Received: by ssc-vax (4.12/4.7) id AA23422; Wed, 18 Jan 89 11:39:22 pst Date: 15 Jan 89 18:58:30 GMT From: ssc-vax!MAILER-DAEMON@beaver.cs.washington.edu (Mail Delivery Subsystem) Subject: Returned mail: Service unavailable Message-Id: <8901181939.AA23422@ssc-vax> To: uw-beaver!mc.lcs.mit.edu!info-pcnet-request@beaver.cs.washington.edu ----- Transcript of session follows ----- >>> HELO ssc-vax <<< 553 ssc-vax I refuse to talk to myself 554 "payzer%eagle.decnet"@base-vax \stanford... Service unavailable: Bad file number ----- Unsent message follows ----- Received: by ssc-vax (4.12/4.7) id AA23407; Wed, 18 Jan 89 11:39:22 pst Received: from AI.AI.MIT.EDU by beaver.cs.washington.edu (5.59/6.12) id AA06927; Mon, 16 Jan 89 14:10:25 PST 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: uw-beaver!husc6.harvard.edu!m2c!jjmhome!cpoint!martillo (Joacim Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. Subject: XNET Summary Message-Id: <1977@cpoint.UUCP> Sender: uw-beaver!mc.lcs.mit.edu!info-pcnet-request 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 23 Jan 89 21:01:04 EST Received: from ucsd.edu (TCP 20015410001) by MC.LCS.MIT.EDU 23 Jan 89 20:39:07 EST Received: by ucsd.edu; id AA24185 sendmail 5.60/UCSD-1.0 Mon, 23 Jan 89 15:00:17 PST for chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU Date: Mon, 23 Jan 89 15:00:17 PST Message-Id: <8901232300.AA24185@ucsd.edu> From: Postmaster@ucsd.edu Cc: Postmaster Subject: Failed Mail To: chem.UCSD.EDU!nosc!@AI.AI.MIT.EDU, @MC.LCS.MIT.EDU:info-pcnet-request@mc.lcs.mit.edu After 7 days (168 hours), your message to the following people: bam (host=bang) could not be delivered. ----- Unsent message follows ----- Received: from chema.ucsd.edu by ucsd.edu; id AA09158 sendmail 5.60/UCSD-1.0, Mon, 16 Jan 89 14:11:05 PST for bam Received: by chem.chem.ucsd.edu (5.51) id AA19547; Mon, 16 Jan 89 14:12:43 PST Received: from nosc.UUCP by ucsd.edu; id AA08492 with UUCP and sendmail 5.60/UCSD-1.0, Mon, 16 Jan 89 13:39:56 PST Received: from AI.AI.MIT.EDU by trout.nosc.mil (5.59/1.27) id AA01411; Mon, 16 Jan 89 13:38:57 PST 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: ucsd!chem.UCSD.EDU!m2c!jjmhome!cpoint!martillo@husc6.harvard.edu (Joacim Martillo) Organization: Clearpoint Research Corp., Hopkinton Mass. Subject: XNET Summary Message-Id: <1977@cpoint.UUCP> Sender: ucsd!chem.UCSD.EDU!info-pcnet-request@mc.lcs.mit.edu To: mc.lcs.mit.edu!info-pcnet 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 NMFECC.ARPA (TCP 3202200025) by AI.AI.MIT.EDU 15 Feb 89 10:05:35 EST Received: from mcl.sainet.mfenet by ccc.mfenet with Tell via MfeNet ; Wed, 15 Feb 89 07:04:00 PST Date: Wed, 15 Feb 89 07:04:00 PST From: MAGDITS%MCL.SAINET.MFENET@NMFECC.ARPA Message-Id: <890215070400.22200215@NMFECC.ARPA> Subject: request To: INFO-PCNET-REQUEST@AI.AI.MIT.EDU Comment: From MAGDITS@MCL.SAINET.MFENET on 15-FEB-1989 09:40:31.60 EST My name is Marc Magdits, I work for S.A.I.C. in McLean Virginia. I would like to be added to your distribution list. Thank You. My address is: MAGDITS%MCL.SAINET@NMFECC.ARPA Marc Magdits  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Feb 89 23:51:27 EST Received: from relay.ubc.ca (TCP 20057260451) by MC.LCS.MIT.EDU 24 Feb 89 23:46:02 EST Received: by relay.ubc.ca (5.59/1.14) id AA21420; Fri, 24 Feb 89 20:46:37 PST Date: 24 Feb 89 22:45 -0600 From: anthony yeung <#yeun14@ccu.umanitoba.ca> To: info-pcnet-request@mc.lcs.mit.edu Message-Id: <297*#yeun14@ccu.umanitoba.ca> Subject: mailing list Return-Receipt-To: anthony yeung <#yeun14@ccu.umanitoba.ca> sub info-pcnet anthony yeung  Received: from mitvma.mit.edu (TCP 2227000003) by AI.AI.MIT.EDU 16 Mar 89 06:27:56 EST Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 2756; Thu, 16 Mar 89 06:25:55 EST Received: from VM1.EARN-ULG.AC.BE by MITVMA.MIT.EDU (Mailer X1.25) with BSMTP id 5665; Thu, 16 Mar 89 06:25:54 EST Received: by BLIULG11 (Mailer R2.02) id 1016; Thu, 16 Mar 89 12:24:31 +0100 Date: Thu, 16 Mar 89 12:23:59 +0100 From: "A. Van de Paar" Subject: subscription To: info-pcnet-request@ai.ai.mit.edu I want to be added to INFO-PCNET List. Thanks  Received: from SCRI1.SCRI.FSU.EDU (TCP 20056402002) by AI.AI.MIT.EDU 16 Mar 89 17:56:26 EST Date: Thu, 16 Mar 1989 17:54:53 EST From: DUBRAVKO @ SCRI1.SCRI.FSU.EDU Message-Id: <890316175453.2941a45d@SCRI1.SCRI.FSU.EDU> Subject: Addition to the mailing list To: info-PCNet-request @ ai.ai.mit.edu X-Vmsmail-To: SMTP%"info-PCNet-request@ai.ai.mit.edu" Please add dubravko@scri1.scri.fsu.edu to the PCNet mailing list. Thanks. Dubravko Kakarigi, Florida A&M University, occasionally a guest at Florida State University. 904/599-3022  Received: from SCRI1.SCRI.FSU.EDU (TCP 20056402002) by AI.AI.MIT.EDU 16 Mar 89 18:02:45 EST Date: Thu, 16 Mar 1989 18:01:09 EST From: DUBRAVKO @ SCRI1.SCRI.FSU.EDU Message-Id: <890316180109.2941a45d@SCRI1.SCRI.FSU.EDU> Subject: EasyNet To: info-PCNet @ ai.ai.mit.edu X-Vmsmail-To: SMTP%"info-PCNet@ai.ai.mit.edu" Has anyone heard of EasyNet Syetems Inc.? I downloaded their EasyNet Software and am having problems with it. Tried to call 416/273-6410 but the number has been disconnected. Can anyone please provide pointers or help? D.K.  Received: from relay.nswc.navy.mil (TCP 20011400451) by AI.AI.MIT.EDU 20 Mar 89 15:18:21 EST Date: Mon, 20 Mar 89 15:15:24 est From: operator@relay.nswc.navy.mil Full-Name: gw2 To: MAP@ai.ai.mit.edu, info-PCNet-Request@ai.ai.mit.edu Subject: About . Cc: SURF-PCNET@relay, operator@relay Michael Patton (Info-PCNet Coordinator): 0. This is a [modified] form letter to about 50 list-honchos... ____ 1. For about two months we had problems in mail delivery |to| NSWC. We believe our Internet mail service is now stable. ^^^^ 2. You may have had "returns" or "refusals" of mail to an NSWC ID or ALIAS . You may have CUT US OFF. :-( [I don't know.] 3. Please, check our NSWC alias , and, as necessary, please, continue or resume list-mail to . 4. Please, make sure host is <...@relay.nswc.navy.mil>; ^ not <...@nswc-g.arpa> nor <...@relay-nswc.navy.mil> 5. Question? Gripe? Suggestion? Maybe, even confirmation, try... Mike Pabrinkis (E41) Naval Surface Warfare Center Dahlgren, VA 22448 (703)663-8166 (AUTOVON)249-8166  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 24 Mar 89 09:28:53 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 24 Mar 89 09:15:18 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 24 Mar 89 09:11:41 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: 24 Mar 89 13:28:02 GMT From: ncis.llnl.gov!helios.ee.lbl.gov!ace.ee.lbl.gov!jef@lll-winken.llnl.gov (Jef Poskanzer) Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Subject: Is comp.protocols.pcnet dead? Message-Id: <2209@helios.ee.lbl.gov> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu This newsgroup has not has any traffic in quite a while. Is it dead? Should we give it a decent burial? --- Jef Jef Poskanzer jef@helios.ee.lbl.gov ...well!pokey  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 27 Mar 89 19:01:50 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 27 Mar 89 19:01:24 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 27 Mar 89 18:53:36 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: 27 Mar 89 23:31:21 GMT From: jalil@topaz.rutgers.edu (Fo) Organization: Rutgers Univ., New Brunswick, N.J. Subject: Re: Is comp.protocols.pcnet dead? Message-Id: References: <2209@helios.ee.lbl.gov> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 31 Mar 89 09:51:20 EST Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 31 Mar 89 09:49:56 EST Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Fri, 31 Mar 89 09:34:46 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: 31 Mar 89 13:59:40 GMT From: shorty!rose@speedy.wisc.edu (Scott Rose) Organization: U of Wisconsin CS Dept Subject: Re: Is comp.protocols.pcnet dead? Message-Id: <7384@spool.cs.wisc.edu> References: <2209@helios.ee.lbl.gov> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I, for one, badly want this group not to be dead. Naturally, I want it to have traffic, too, which clearly hasn't been the case. Circumstance has forced me to take a closer look at the semantics of file-sharing under MSDOS, and I am a bit puzzled by what experimentation has revealed... First, let me say this: we have nodes running DOS 3.3 and an Artisoft Lantastic NOS running on their hardware. This is a NetBIOS NOS. The MSDOS Tech Reference informs me that specification of other than com- patibility mode sharing code is ignored if share is not installed. However, it does not seem to be necessary that sharing be installed on my machine, only on the machine on which the destination file resides. Compatibility mode is supposed to be compatible with itself and only itself. This implies to me that I should be able to open a network file many times in compatibility mode without sharing violation. What I have discovered is that this is true only if the opens are from the same node. Compatibility mode opens from two nodes generate a sharing violation on all but the first node to perform the open. It seems as if my NOS is behaving in a fashion that is not documented. Nowhere have I seen it said that the identity of the opener of a file should have an impact on the result of an open call. My questions boil down to this- 1. Is my NOS behaving in the specified fashion, or is this part of the under- specification of PCNet, or is Artisoft being creative, or is it broken, or WHAT? 2. If this behavior is expected, where do I read such a specification of the appropriate file system sematics so I can put an end to this little cycle I am in of thinking I have gotten to the point where I understand how the network file system will behave only to find some new surprise somewhere? I sure do wish that I could get a copy of the IBM reference manual for PCNet, but none of the roads that I went down in this quest a few months ago turned out to be other than dead ends... -Scott Rose  Received: from RELAY.CS.NET (TCP 30007663404) by AI.AI.MIT.EDU 31 Mar 89 23:08:13 EST Received: from relay2.cs.net by RELAY.CS.NET id ab22244; 31 Mar 89 21:21 EST Received: from cl.uh.edu by RELAY.CS.NET id ad01159; 31 Mar 89 21:16 EST Date: Fri, 31 Mar 89 19:09 CST From: NEWSMGR%cl.uh.edu@RELAY.CS.NET Subject: Addition to list To: info-pcnet-request@AI.AI.MIT.EDU X-VMS-To: IN%"info-pcnet-request@ai.ai.mit.edu",NUNN Moderator, Please add NEWSMGR%CL.UH.EDU@UHVAX1.UH.EDU to the distribution list for INFO-PCNET. Thanks, John Nunn (nunn@cl.uh.edu) Technical Liaison  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 10 Apr 89 05:35:43 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 10 Apr 89 05:35:12 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Mon, 10 Apr 89 05:20:54 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 Apr 89 00:31:06 GMT From: attcan!lsuc!ncrcan!ziebmef!mshiels@uunet.uu.net (Michael A. Shiels) Organization: Ziebmef Public Access Unix, Toronto, Ontario Subject: Re: Is comp.protocols.pcnet dead? Message-Id: <1989Apr8.203108.10673@ziebmef.uucp> References: <2209@helios.ee.lbl.gov>, <7384@spool.cs.wisc.edu> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I have a lot of experience with redirectors since I maintain one written for our network at work. Compatability mode is probably being translated into a sharing open since the server has share loaded. A lot of networks do this to get around the problem of people running single user software and complaining when files get trashed. Instead they complain about int24 errors.  Received: from ECLC.USC.EDU (TCP 1200200171) by AI.AI.MIT.EDU 11 Apr 89 19:55:11 EDT Date: Tue 11 Apr 89 16:55:12-PDT From: Christopher Ho Subject: address change To: Info-PCNet-Request@AI.AI.MIT.EDU Message-ID: <12485393558.19.CHRIS@ECLC.USC.EDU> Please change the address Local-Info-PCnet @ Ecla.Usc.Edu (or USC-ECLA.ARPA) to List-Info-PCnet @ Usc.Edu and acknowledge when done. Thanks. Chris Ho, USC-UCS -------  Received: from relay.nswc.navy.mil (TCP 20011400451) by AI.AI.MIT.EDU 25 Apr 89 15:51:17 EDT Date: Tue, 25 Apr 89 15:48:34 edt From: operator@relay.nswc.navy.mil Full-Name: gw2 To: Info-PCNet-Request@ai.ai.mit.edu, MAP@ai.ai.mit.edu Subject: About Cc: SURF-PCNET@relay, operator@relay Mike Patton, Local readers ask me to ask... IS ALIVE AND WELL? If "Yes!", IS in distribution? We hope for two "Yes's". Mike Pabrinkis (E41) Naval Surface Warfare Center Dahlgren, VA 22448 (703)663-8166 (AV)249-8166  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 3 May 89 21:21:19 EDT Received: from BLOOM-BEACON.MIT.EDU (TCP 2224000021) by MC.LCS.MIT.EDU 3 May 89 21:16:50 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Wed, 3 May 89 19:38:15 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: 3 May 89 15:24:43 GMT From: gwusun!viraf@uunet.uu.net (Viraf Bankwalla) Organization: The George Washington University, Washington, D.C. Subject: Need help sharing Laser Printer Message-Id: <1365@gwusun.gwu.edu> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu Hi, I need to share a HP LaserJet between 12 AT's, as cheaply as possible. Does anyone have any suggestions ? Can I connect them using RS232, and is there some PD client/server software which will enable me to do the spooling. Please respond via E-Mail. Thanks in advance. viraf bankwalla viraf@gwusun.gwu.edu uunet!gwusun!viraf  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 11 May 89 19:11:30 EDT Received: from LIFE.AI.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 207179; 11 May 89 19:03:06 EDT Received: from mitvma.mit.edu by life.ai.mit.edu (4.1/AI-4.10) id AA19848; Thu, 11 May 89 19:04:02 EDT Message-Id: <8905112304.AA19848@life.ai.mit.edu> Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 9115; Thu, 11 May 89 19:04:08 EDT Received: from MITVMA.MIT.EDU by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 4342; Thu, 11 May 89 19:00:47 EDT Received: from TWNMOE10.BITNET by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 4341; Thu, 11 May 89 19:00:47 EDT Received: by TWNMOE10 (Mailer R2.02A) id 6612; Thu, 11 May 89 22:33:48 CST Date: Thu, 11 May 89 22:30:22 CST From: ROBERT MING Subject: sub info-pcnet To: info-pcnet-request@ai.ai.mit.edu help index request:info topic:help sub info-pcnet min min reply to : nccut015%twnmoe10.bitnet@cunyvm.cuny.edu  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 16 May 89 07:59:01 EDT Received: from mitvma.mit.edu (TCP 2227000003) by MC.LCS.MIT.EDU 16 May 89 07:51:11 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2) with BSMTP id 6159; Tue, 16 May 89 07:49:37 EDT Received: from UNIPAD.INFN.IT by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 9391; Tue, 16 May 89 07:49:36 EDT Message-id: <1314> Date: Tue, 16 MAY 89 13:23 N From: MUSIC01%UNIPAD.INFN.IT@mitvma.mit.edu Subject: Insertion in mailing list To: INFO-PCNET-REQUEST@MC.LCS.MIT.EDU X-Original-To: INFO-PCNET-REQUEST@MC.LCS.MIT.EDU Dear Sir, my name is Andrea Provaglio, and I work with the Centro di Sonologia Computazionale of the University of Padua, Italy. The aim of our Centre is to perform research in the field of applications of computer technology to the analysis, synthesis and digital processing of sound, intended both for scientific and musical purposes. We work on mainframe machines (IBM 4381, VAX 8650) as well as on personal machines (IBM AT, ATARI), and a large part of our software and hardware has been developed here. I would be grateful if you wish insert my name into your mailing list. My address is: MUSIC01@UNIPAD.INFN.IT I wish to thank you in advance for your courtesy. Sincerely Yours, Andrea Provaglio  Received: from REAGAN.AI.MIT.EDU (CHAOS 13065) by AI.AI.MIT.EDU 19 May 89 02:12:03 EDT Received: from MITVMA.MIT.EDU by REAGAN.AI.MIT.EDU via INTERNET with SMTP id 210955; 19 May 89 02:11:25 EDT Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3114; Thu, 18 May 89 22:16:45 EDT Received: from UDCVAX.BITNET (HGOLDSTE) by MITVMA.MIT.EDU (Mailer R2.03B) with BSMTP id 6886; Thu, 18 May 89 22:16:43 EDT Date: Thu, 18 May 89 22:13 EDT From: Subject: add to list To: info-pcnet@ai.ai.mit.edu X-Original-To: info-pcnet@ai.ai.mit.edu, HGOLDSTE please add my name to the info-pcnet list ... thank you harold Goldstein  Received: from MC.LCS.MIT.EDU (CHAOS 3131) by AI.AI.MIT.EDU 22 May 89 13:05:45 EDT Received: from lcs.mit.edu (CHAOS 15044) by MC.LCS.MIT.EDU 22 May 89 13:05:28 EDT Received: from BLOOM-BEACON.MIT.EDU by mintaka.lcs.mit.edu id aa03110; 20 May 89 18:49 EDT Received: by BLOOM-BEACON.MIT.EDU with sendmail-5.59/4.7 id ; Sat, 20 May 89 16:45: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: 16 May 89 17:32:25 GMT From: "Dave P. Wiltzius" Organization: CRG, Lawrence Livermore Labs Subject: Multicast source addresses Message-Id: <2480@lll-lcc.UUCP> Sender: info-pcnet-request@mc.lcs.mit.edu To: info-pcnet@mc.lcs.mit.edu I'm currently in a discussion with two vendors (who shall remain nameless); one makes a brouter and another sells a network management software package. The software not only recognizes 802.3 format packets (and not "Ethernet") but also - get this - sets the multicast bit in the MAC level source address. Unfortunately, the brouter notices this and drops the packet. I know at least one bridge that will *learn* the multicast address (which could result in defeating that multicast address - I didn't check). I would like the brouter to be a bit more lenient (i.e. forward the packet as appropriate but don't learn the multicast source address) and the software vendor to fix the code (let "Blue Book" Ethernet - type field in bytes 12-13 be supported, not just 802.3 - length in bytes 12-13 . . .) and don't set that multicast bit in the source address. Could people send me the names of LAN software that they have found that puts a multicast/broadcast in the MAC level source address? I know of two, and one was just recently fixed. Thanks much. Dave Wiltzius (wiltzius@lll-lcc.llnl.gov) Lawrence Livermore Nat'l Lab  Date: Thu, 1 Jun 89 14:23:26 EDT From: "Michael A. Patton" Subject: [HGOLDSTE%UDCVAX.BITNET: add to list] To: INFO-PCNET-REQUEST%AI.AI.MIT.EDU@MINTAKA.LCS.MIT.EDU Message-ID: <602745.890601.MAP@AI.AI.MIT.EDU> Date: Thu, 18 May 89 22:13 EDT From: To: info-pcnet at ai.ai.mit.edu Re: add to list X-Original-To: info-pcnet@ai.ai.mit.edu, HGOLDSTE please add my name to the info-pcnet list ... thank you harold Goldstein