[comp.sys.att] Does anybody know anything about PMX/Term from AT&T?

psc@lznv.ATT.COM (Paul S. R. Chisholm) (06/24/88)

In article <1261@neoucom.UUCP>, wtm@neoucom.UUCP (Bill Mayhew) writes:
> I've been on vacation, so I've been somewhat behind in  catching
> up on reading, Usenet, etc.  I just got around to looking at the
> June 6 issue of Info World.  On page 19, they describe some stuff
> related to AT&T Mail (that is, the service that bears that proper
> name).  One related thing they mention is:
> 
> "AT&T also announced PMX/Term, a PC version of its Unix-based
> electronic mail system for minicomputers.  PMX/Term runs on AT&T
> 6386 WGS PCs and MS-DOS compatibles, will be available in July and
> costs $1,295."
>...
> Can anybody elaborate on PMX/Term?...
> --Bill, impulse!wtm@neoucom.UUCP  <- temporary email address

Sure enough.  All of the products mentioned in that article were
developed in my group.  We do two things:  provide nice user interfaces
for existing electronic mail solutions, and develop new solutions
(e.g., STARMail, a STARLAN electronic mail application).

AT&T Mail Access PLUS is a new MS-DOS program that acts as a front end
to the AT&T Mail service (and to local mail servers, as described
below).  Access PLUS helps you create, send, receive, and organize your
electronic mail messages.  Access PLUS can also run in the background,
calling the AT&T Mail service periodically to look for new mail.

PMX/Term provides a similar user interface, but runs under the UNIX
operating system, and works with vanilla UNIX system E-mail.  PMX/Term
does *not* run under MS-DOS.

Both Access PLUS and PMX/Term let you organize your mail messages into
"folders", and provide an editor to create and revise messages.  You
can also "attach" files to a message when you create it, and "detach"
the files when you receive such a message.

What if you've got a 3B2 or 6386 running the UNIX operating system, and
a bunch of PC users who want to exchange mail?  In this case, you can
run PMX/PC on your UNIX system.  PMX/PC simulates just enough of the
AT&T Mail service user interface to work with the PC-based Access
products.  (Yeah, it's kind of confusing at first that PMX/PC doesn't
run on PCs.)

I don't know of any AT&T products that let a PC running MS-DOS
communicate with uucp on a UNIX system.  You could run PMX/PC on your
UNIX system, and send mail to it from Access PLUS.  AT&T Mail *does*
know uucp, so you also could run Access PLUS on your PC to call up the
service, and go through a UNIX system that's registered with the
service.

-Paul S. R. Chisholm, {ihnp4,cbosgd,allegra,rutgers}!mtune!lznv!psc
AT&T Mail !psrchisholm, Internet psc@lznv.att.com
I'm not speaking for my employer, I'm just speaking my mind.
UNIX(R) is a registered trademark of AT&T.

paul@cgh.UUCP (Paul Homchick) (06/26/88)

In article <1387@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes:
>
>I don't know of any AT&T products that let a PC running MS-DOS
>communicate with uucp on a UNIX system.  You could run PMX/PC on your
>UNIX system, and send mail to it from Access PLUS.  AT&T Mail *does*
>know uucp, so you also could run Access PLUS on your PC to call up the
>service, and go through a UNIX system that's registered with the
>service.

Gee, that's too bad, I was rather hoping that STARMAIL did this.  Maybe
I have finally found someone who can explain how all of these AT&T E-mail
products work.

We have a STARLAN network in our office with a 3B1 running as a DOS
server, and which also allows remote-login via terminal emulator
(EM-4410 or MSKERMIT) over the STARLAN network.  There are 5 AT&T
PC-63xx machines running MS DOS also connected to the LAN, and the
3B1 has a modem connection to usenet.

I recently purchased a 6386 WGS with Unix/386 which I wish to use to
provide the same services as the 3B1, i.e: DOS server, and unix logins
via STARLAN.  Additionally, I want to be able to send E-mail between the
DOS workstations, AND unix accounts, AND uucp to the outside world.  I
was hoping I could do all of this with the Version 3 DOS Server program
for Unix/386, and a copy of STARMAIL for Unix/386.  Is this a hopeless
pipe-dream?  Or, did all of the recent announcements include the software
needed for this operation.  Where can I get some solid info as to what
it is that PMX/Mail, STARMAIL, etc actually do?

-- 
Paul Homchick                     {allegra | rutgers | uunet} !cbmvax!cgh!paul
Chimitt Gilman Homchick, Inc.; One Radnor Station, Suite 300; Radnor, PA 19087

major@eleazar.dartmouth.edu (Lou Major) (06/26/88)

In article <738@cgh.UUCP> paul@cgh.UUCP (Paul Homchick) writes:
>In article <1387@lznv.ATT.COM> psc@lznv.ATT.COM (Paul S. R. Chisholm) writes:
>>
>>I don't know of any AT&T products that let a PC running MS-DOS
>>communicate with uucp on a UNIX system.  You could run PMX/PC on your
>>UNIX system, and send mail to it from Access PLUS.  AT&T Mail *does*
>>know uucp, so you also could run Access PLUS on your PC to call up the
>>service, and go through a UNIX system that's registered with the
>>service.
>
>Gee, that's too bad, I was rather hoping that STARMAIL did this.  Maybe
>I have finally found someone who can explain how all of these AT&T E-mail
>products work.

There is a program called UUPC, which can act as a (almost) full uucp
site.  I'm sure that it will work through a serial port, as well as through
a modem.  The only things it doesn't do is
 (a) send a file in response to a request from the 'calling' node.
 (b) route mail past itself.  All mail not for the localhost goes to
     the "mail server" node.
 (c) verify usernames against a /etc/passwd file.

It seems as though this might fill some of your needs, though not
all of them.  The author(s) of uupc can be reached at
  sl@van-bc.uucp
 skl@van-bc.uucp
  (boht skl and sl)

I can answer any informal questions, as can a couple of my friends who
actually USE it within their own internal networks.  E-Mail me for
additional information.

les@chinet.UUCP (Leslie Mikesell) (06/28/88)

In article <738@cgh.UUCP> paul@cgh.UUCP (Paul Homchick) writes:
>
>We have a STARLAN network in our office with a 3B1 running as a DOS
>server, and which also allows remote-login via terminal emulator
>(EM-4410 or MSKERMIT) over the STARLAN network....
>...
>I recently purchased a 6386 WGS with Unix/386 which I wish to use to
>provide the same services as the 3B1, i.e: DOS server, and unix logins
>via STARLAN.

First, a question:  do you expect to be able to connect the 3B1 and the
6386 to the same Starlan network?  My impression is that when the 6386
unix starlan driver is released it will use the recently announced OSI
low-level protocol and I have heard nothing about a compatible release
for the 3B1.

>Additionally, I want to be able to send E-mail between the
>DOS workstations, AND unix accounts, AND uucp to the outside world. 

I am looking at the 3b2 version of PMX/STARMAIL, and it will indeed allow
this, although I don't like some of the design choices.  The thing I *do*
like is the fact that the mail is actually handled by the unix mailer
and can be read either by a unix program or the DOS PMX/STARMAIL (which
moves it out of the unix mailbox to a DOS file), depending on how/where
you happen to be connected.  The DOS machine can get visual notification
and beep when new mail arrives, and a pop-up program can be used to
retreive/read/reply.
The things I don't like:
-The DOS notification program doesn't bother to tell you if you have mail
waiting when the DOS client connection is established.
-The package comes with a new unix mail handler (undocumented except for
comments in its data file) that can be used to do routing etc, but
the DOS side will reject any attempt to send mail to anything that is
not found in the /etc/passwd or /usr/lib/uucp/Systems files. The DOS
program allows aliasing but requires the user to prepend a "~" to the
alias and then performs a client link to a database directory to look
up the expansion.  I would prefer to have the unix mailer do all the
lookups and just return anything that it can't deliver. The package can
be run with only a DOS server, but that is hardly an excuse for not
taking advantage of a unix server. 
-When DOS servers are used, they can exchange mail with other DOS servers
or unix machines running a special program, but not ordinary unix uucp.
With a unix server, there is no problem sending to other unix machines.
Both versions will (of course) connect to attmail which can forward
to about anything else.

 Les Mikesell

alf@poseidon.UUCP (Andrew L. Fryefield) (06/30/88)

Well, here's everything you always wanted to know about PMX/TERM and
PMX/STARMail...

Basically, PMX is a family of messaging software available from AT&T
which runs on UNIX systems (but as has been noted, there's a DOS-only
STARLAN version as well).  There are a number of PMX components, each designed
to interface to a particular type of equipment.  In addition, there are
AT&T Mail Access products which run on stand-alone MS-DOS PCs and Apple
Macintoshes.  All the products (PMX and Access) work with one another, and
give you a similar interface and set of capabilities.

The various products offered by AT&T include:

  Access PLUS: A very powerful, easy to use, MS-DOS package.  It's used to
     transfer mail between the PC and the public AT&T Mail network, or between
     the PC and a PMX machine.  All the work is done off-line on the PC.
     When you want to send or receive mail, the package will dial your modem
     (or ISN, or whatever) and call out to the "mail server" (AT&T Mail or
     PMX) and transfer the mail.  There's a real nice background capability
     that allows all the connects/sends/receives to go on in the background
     while you're doing other things.  In addition, there's a memory-resident
     "pop up" version of the mail program which allows you to send/receive/read
     mail without having to exit from the application you're using.  There's
     also a memory-resident "phone book" available as part of Access PLUS.
     As part of the background capability, users get notification when mail
     has been received, regardless of what application is currently being used.

  Access III: An Apple Macintosh mail package, designed for use with AT&T Mail
     and PMX.  It supports similar capabilities to what Access PLUS does.

  PMX/TERM: Designed for any async terminal you can define with terminfo
     (it uses curses).  It provides a nice, full-screen interface, and allows
     users to create/read/modify/send/store messages, etc.  It has the same
     interface and capabilities as Access PLUS.

  PMX/PC: The gateway that allows a PC or Mac running one of the Access
     programs to send/receive mail using the UNIX machine as the "post office".

  PMX/STARMail: A version of PMX designed for PCs connected together in a
     STARLAN network.  There are versions for MS-DOS file servers, 3B2 file
     servers, and 386 UNIX file servers.  The user interface is the same as
     Access PLUS... same capabilities, same pop-up programs, etc.  Users get
     automatic notification of new mail when it has arrived.  (Also, we are
     working on versions which will run on LANs other than STARLAN.)

  PMX/STARGATE: A gateway that allows a UNIX system (with or without any other
     PMX software) to exchange mail with a DOS-only STARMail LAN.  Thus, using
     STARGATE, you can send mail from a DOS STARMail network to a UNIX machine,
     and therefore, through uucp, etc.

  PMX/LITE: A PMX adjunct that works together with any or all of the UNIX-based
     PMX products.  It turns the "message waiting light" on a system 75/85
     phone on when mail arrives for you, and turns it off when you've retrieved
     your mail.

  PMX/X400: Provides X.400 connectivity to other mail systems.

As part of PMX, there is also a new, enhanced /bin/(r)mail command.  The two
main differences between the standard mail command and the PMX version is
that the new version supports the transfer of binary messages 
(e.g. spreadsheets, word processor files, etc), and supports a "surrogate"
capability that allows you to execute programs based on the sending and/or
delivery of a mail message.  All the PMX products use the mail command to
send messages, so PMX users can send to non-PMX users, and vice versa.  And,
obviously, PMX/TERM users can communicate with STARMail users, ...

PMX gives you transparent connectivity to the AT&T Mail network, assuming
your UNIX machine or LAN is registered with AT&T Mail.  Thus, you get access
to the capabilities provided by AT&T Mail, such as delivery to FAX machines,
devlivery to Telex, paper delivery, etc.

So, as a fully-loaded example, you could have a UNIX machine (3B2 for example)
that is acting as a STARLAN server, with normal tty access as well.  With all
various PMX and Access products, you could offer mail connectivity to all the
following types of users and systems:
  - Terminal users (PMX/TERM)
  - Stand-alone PC users connecting to the UNIX machine (Access PLUS talking
     to PMX/PC)
  - Stand-alone Macs (Access III and PMX/PC)
  - PCs connected via STARLAN (PMX/STARMail)
  - Local UNIX users who use non-PMX mailers (mail, post, PCS, etc.)
  - Remote UNIX systems and AT&T Mail (uucp)
  - Remote DOS STARMail LANs (STARGATE)
  - International email systems, and other vendor's systems, which support
     X.400 (PMX/X400)

Well, I hope I've cleared things up a bit.  If anyone has any questions
on AT&T Mail or PMX (including info on availability or prices), the best bet
is to call the AT&T Mail Telemarketing Center at (800) 367-7225, or send mail
to attmail!atthelp (if you've got a connection to AT&T Mail).  Or, you can send
me mail.

Andy Fryefield
attmail!afryefield

rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/02/88)

in article <738@cgh.UUCP>, paul@cgh.UUCP (Paul Homchick) says:
> Gee, that's too bad, I was rather hoping that STARMAIL did this.  Maybe
> I have finally found someone who can explain how all of these AT&T E-mail
> products work.

If your host is running unix, then starmail will allow mailing to _any_
mail address available to the unix system.  If you register your
unix _system_ with attmail, instead of your users, you cna do this
quite nicely.

As far as ease of use for starmail, I have never acutally used the
product, so I can't say...

Stay away from PMX/TERM at ALL COTST!  This program is an _expensive_
_dog_ prone to screwing you up and getting in your way!

Rob.

D: Opinions are personal, but I make these decisions around here...

paul@cgh.UUCP (Paul Homchick) (07/04/88)

In article <738@cgh.UUCP> I wrote:
>
>>I recently purchased a 6386 WGS with Unix/386 which I wish to use to
>>provide the same services as the 3B1, i.e: DOS server, and unix logins
>>via STARLAN.

In article <5902@chinet.UUCP> les@chinet.UUCP (Leslie Mikesell) writes:
>
>First, a question:  do you expect to be able to connect the 3B1 and the
>6386 to the same Starlan network?  My impression is that when the 6386
>unix starlan driver is released it will use the recently announced OSI
>low-level protocol and I have heard nothing about a compatible release
>for the 3B1.

Of course I expect to be able to connect the 3B1 and the 6386 to the
same network.  Why should I want to throw away my 3B1?  This is a very a
very intriguing and very unpleasent train of thought which I had not,
until now, entertained.

I note from a passel of literature just received, that AT&T is offering
the following STARLAN products:

   3B2 Server Program, Version 3        3B2 OSI Network Program
   386 Server Program, Version 3        386 OSI Network Program
   DOS Server Program, Version 3        3B2 DOS Server Program, Version 1.01
   PC6300 Network Program, Version 2.0
   STARLAN Hardware                     STARLAN10 Hardware

Is it possible that not all of these items are compatible with each
other?  Might someone running a 3B1 with a DOS server and a few copies of
the PC6300 Version 2.0 Network Program be forced to throw it all away
and start over again if they want to add a 6386WGS Unix box to the
network?  What does STARLAN mean, if all of these are "STARLAN", but none
of them will talk to the others?  Will the *real* STARLAN please stand
up.

This is not idle curiosity on my part.  I have a real network with real
AT&T equipment in it, and there is a 6386WGS on my desk awaiting
integration.  If there is a helpful AT&T Network Guru out there I have
a few questions:

1. Can the "PC6300 Network Program, Ver 2" communicate with one of the
   Ver 3 Servers?

2. Does the DOS client software come bundled with the Ver 3 Server
   programs?

3. Can the 'old' STARLAN protocol and the new version 3 exist on the
   same physical network?  i.e: can there be a set of version 3 servers
   and clients, and version 1 servers and clients on the same network?

4. Will a 1:10 bridge provide connectivity between version 3 and version
   1 as well as connecting STARLAN and STARLAN10?

5. Is the "OSI Network Program" required to run the "Version 3 Server
   Program"?  If so, is it bundled with the Server, or is it an extra
   cost item?

6. If the answers to these questions are not resolved in my favor, does
   anyone want to buy a loaded 3B1?  (Or, maybe a 6386.  It isn't clear
   which "incompatible" hardware to dump.)  (Or^^2, where is the OSI
   support for the 1,000's of 3B1s??)
-- 
Paul Homchick                     {allegra | rutgers | uunet} !cbmvax!cgh!paul
Chimitt Gilman Homchick, Inc.; One Radnor Station, Suite 300; Radnor, PA 19087

rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/07/88)

HI!
It's time to play that wounderful game, sleuth or consequences!

The unpleasant issue of the day, STARLAN OSI protocols!

(the information in revealed in this is my "best research" on the
topic, and was done on myown networks behalf.  You will probably 
not like the answers.)

In basic summary: all of the "old" STARLAN stuff will _not_ talk
with any of the new stuff; the STARLAN and the STARLAN 10 are _not_
wire compatable, but any kind of bridge will make this relationship
hunky-dorry; there is _no_ hardware difference between the old and
new STARLAN boards, but the STARLAN 10 stuff is an entriely different
game (it should therefore be possible to replace the drivers for
non-suported systems).

THINGS YOU WILL LOOSE:
ISN SLIM-C cards (to be eventually replaced)
RS232-C NAU (totally history, no future plans to replace _ever_)
3B1 Connections (by omission, no word as to the future?)
STARLAN 10 _will not_ dasy-chain.
NRUs are no longer necesssary for long runs. (NHU now does this
	function.)

THINGS YOU WILL GAIN:
NHU (Network Hub Unit) differs in important diagnostic and protection
	functions from the NEU which is still useable for STARLAN.
	The major feature of the NHU is that it will isolate faulty
	network sub-segments, increasing system integrity.
6386 Servers can "host" printing for any printer attached to any client.
	This will not be available for 3B server software.
STARLAN and STARLAN 10  may be intermixed with ETHERNET <sp?> devices,
	or bridged to such segments.  This does not include TCP/IP
	and others, but it dosn't seem to preclude it either
new STARLAN drivers are (aledgedly) about twice as fast as the older
	stuff.
All Wire-feet distances are increased.
X.25 Bridging and SNA-STARLAN session bridging.
Servers can generate alert messages on (MS-DOS) client screens.  (i.e.
	warnings, alerts, and system condition messages)

(now for the questions...)

in article <740@cgh.UUCP>, paul@cgh.UUCP (Paul Homchick) says:
> AT&T equipment in it, and there is a 6386WGS on my desk awaiting
> integration.  If there is a helpful AT&T Network Guru out there I have
> a few questions:
> 
> 1. Can the "PC6300 Network Program, Ver 2" communicate with one of the
>    Ver 3 Servers?

NO.  The "new" packet structures are totally different than the older
	structures on the most primitive level.  while it should be
	possible to make a packet-type-translating bridge, there is
	no aparent intent to do so.

> 2. Does the DOS client software come bundled with the Ver 3 Server
>    programs?

YES.  The "dos server program, Version 3" is similar to the network
	software you are used to receiving, but it is now sold with
	a minimum client licence of 8.  (i.e. you pay more cash.)
	This seems to be a response to people liberally copying the
	client software.  I do not know if there is a built in
	protection against ilicit copying(??)

> 3. Can the 'old' STARLAN protocol and the new version 3 exist on the
>    same physical network?  i.e: can there be a set of version 3 servers
>    and clients, and version 1 servers and clients on the same network?

NO.  The packets and such from the "old" and "new" versions are supposed
	to be capible of totally scrambling eachother.  I have not tried
	this, so it may not actually be true.  (This is supposed to be
	an addressing issue.)

> 4. Will a 1:10 bridge provide connectivity between version 3 and version
>    1 as well as connecting STARLAN and STARLAN10?

NO.  The 1:10 bridge preforms promiscuous address evaluation on all the
	packets, and then retransmits necessary packets on the far side
	of the bridge compleetly unchanged.  Only necessary traffic is
	passed, so old format traffic would be filtered by default.

An other bridging no-no is connecting lan segments in a circle. (i.e.
	A || B || C || A )  If there is more than one way to get there
	the birdges will storm.

> 5. Is the "OSI Network Program" required to run the "Version 3 Server
>    Program"?  If so, is it bundled with the Server, or is it an extra
>    cost item?

.NA.  The Version 3 stuff has been "re-engineered" to conform to the 
	OSI 7-layer spesifications and protocol requirements.  There
	is no "OSI Network Program" per-se.  All the "new" programs
	are "OSI Network Programs" while all the "old" stuff are the
	"Proprietary Network Programs"

> 6. If the answers to these questions are not resolved in my favor, does
>    anyone want to buy a loaded 3B1?  (Or, maybe a 6386.  It isn't clear
>    which "incompatible" hardware to dump.)  (Or^^2, where is the OSI
>    support for the 1,000's of 3B1s??)

The 386 software and hardware is far superrior for use on the STARLAN
and STARLAN 10 networks.  Their capacity (in network connections/sessions)
is more than twice that for the 3B2/600 et. al.  If and when the SCSI
adapter comes out for the 386 systems, they will become the network
server of choice.  At present 3B2/600 is the best mass-disk server
while a 386 server will handle the MS-DOS clients better.  A
multiple service network using one STARLAN-DOS server and an RFS link
seem to be the best ideas for combining the capacities of the two.

As far as the 3B1 are concerned, the best answer I have gotten on that
is "that hardware isnolonger supported."

Oh well.....


Rob.

Disclaimer:  This is my research, not "official" AT&T party line;
	The first, however, is damn close to the second.
> -- 
> Paul Homchick                     {allegra | rutgers | uunet} !cbmvax!cgh!paul
> Chimitt Gilman Homchick, Inc.; One Radnor Station, Suite 300; Radnor, PA 19087

les@chinet.UUCP (Leslie Mikesell) (07/08/88)

In article <1094@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>
>The unpleasant issue of the day, STARLAN OSI protocols!
>
>THINGS YOU WILL LOOSE:
>3B1 Connections (by omission, no word as to the future?)
  ^^^
Thanks for the input - I raised the issue because I had reached the same
conclusion from looking at the descriptions of the new products.  The
AT&T sales people that I deal with were unable (or unwilling) to give
an answer about a 3B1 version for OSI.  

>The 386 software and hardware is far superrior for use on the STARLAN
>and STARLAN 10 networks. 
>...
>As far as the 3B1 are concerned, the best answer I have gotten on that
>is "that hardware is no longer supported."
>
>Oh well.....

At the same meeting where the 3B1 issue was brought up, I asked the
AT&T sales people why I should buy their 6386 machine as opposed to
the many others on the market.  Their answer: "Well, you want to buy
from a company that is going to be around to support it's equipment,
don't you?"

>Disclaimer:  This is my research, not "official" AT&T party line;
>	The first, however, is damn close to the second.

Anyone have an "official" reply?

  Les Mikesell

rgb@mtung.ATT.COM (Rich Bantel) (07/09/88)

The question was asked, "Can old STARLAN SW coexist with new (ISO) SW?"
A followup response stated NO.

The answer is indeed YES. The proprietary set of protocols can run
on the same media as the new protocols. So, if you want to keep an old
server (and some clients) running the old stuff, you can do so while
also having ISO traffic on the same network. Isolation is provided
by the LLC protocol. 

pete@tutor.UUCP (Peter Schmitt) (07/09/88)

In article <5957@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) writes:
> At the same meeting where the 3B1 issue was brought up, I asked the
> AT&T sales people why I should buy their 6386 machine as opposed to
> the many others on the market.  Their answer: "Well, you want to buy
> from a company that is going to be around to support it's equipment,
> don't you?"

That's what they said when people were buying 7300's and 6300+'s

bill@carpet.WLK.COM (Bill Kennedy) (07/12/88)

In article <334@tutor.UUCP> pete@tutor.UUCP (Peter Schmitt) writes:
>In article <5957@chinet.UUCP>, les@chinet.UUCP (Leslie Mikesell) writes:
LM At the same meeting where the 3B1 issue was brought up, I asked the
LM AT&T sales people why I should buy their 6386 machine as opposed to
LM the many others on the market.  Their answer: "Well, you want to buy
LM from a company that is going to be around to support it's equipment,
LM don't you?"

PS That's what they said when people were buying 7300's and 6300+'s

And the 6300, 6310, 6312, 3B1, etc. etc. etc.  Everyone catching on?
-- 
Bill Kennedy  Internet:  bill@ssbn.WLK.COM
                Usenet:  { killer | att-cb | ihnp4!tness7 }!ssbn!bill

mark@cbnews.ATT.COM (Mark Horton) (07/14/88)

>>First, a question:  do you expect to be able to connect the 3B1 and the
>>6386 to the same Starlan network?  My impression is that when the 6386
>>unix starlan driver is released it will use the recently announced OSI
>>low-level protocol and I have heard nothing about a compatible release
>>for the 3B1.
>
>Of course I expect to be able to connect the 3B1 and the 6386 to the
>same network.  Why should I want to throw away my 3B1?  This is a very a
>very intriguing and very unpleasent train of thought which I had not,
>until now, entertained.

I am not very familiar with Starlan, but in case it doesn't work out,
here is an alternative.  I have a 3B1 and a 6386 right next to each
other, on the same TCP/IP/Ethernet network.  They talk to each other
quite reliably, although certain things don't work.

The 3B1 uses the WIN/3B1 stuff from AT&T.  There is an Ethernet board
from AT&T for the 3B1 that it works with.

The 6386 uses a TCP/IP package from Micom/Interlan and a board from
the same outfit.  Rumor has it that there are several other sources
of TCP/IP/Ethernet for the 6386 now or soon.

Remote login, file copy, and remote execution work well.  In fact, I
plug a 630 into the serial port on the 6386, run layers, and rlogin
one of the layers into the 3B1 for all my use of the 3B1.  This way
the machines can both go in another room where their noisy fans and
tiny screens don't bother me.  Since I can change the escape char on
rlogin from ~ to something else, I'm much happier with the rlogin
link than when I cu out from the 3B1 on the modem, where I'm stuck
with ~.  Frustrating if I dkcu out from the other end or read mail.

I have a laser printer plugged into the 3B1 which I use from the 6386.
(This is because I have spare serial ports on the 3B1 but not the 6386.)
The "lp" command on the 6386 is now a shell script that rsh'es the lp
command on the 3B1.  It works very reliably, although everything I spool
seems to print but keep sitting in the printer queue on the 3B1 taking
up disk space.  And of course it would lose if the 3B1 were down, but
I keep them up 24 hours/day.

RFS does not work, because it's not supported on the 3B1.

Thin ethernet is an obvious thing here for a 2 machine ethernet,
but the 3B1 only supports thick.

Email does NOT work over the ethernet, because the Micom/Interlan
port does not include sendmail or anything like it.  This is frustrating
because I have to read my mail on the 3B1, which is a much slower machine.

The Micom/Interlan stuff also does not support netstat or other commands
that like to poke in /dev/kmem, because the TCP/IP is offloaded onto the
board where the CPU can't get at it.  This makes debugging difficult.

ruptime works in one direction only - one of the machines can't see
the other.  I can't remember which one, but it has something to do
with a flag setting on the 6386, I think.  I never bothered to fix it.

In general, the 3B1 isn't getting enhanced anymore.  I would not hold
my breath looking for an OSI or RFS for it.  Unless the Starlan people
are continuing to develop for it, which might be possible, I don't know.

	Mark

les@chinet.UUCP (Leslie Mikesell) (07/17/88)

In article <656@cbnews.ATT.COM> mark@cbnews.ATT.COM (Mark Horton) writes:
>
>Remote login, file copy, and remote execution work well.  In fact, I
>plug a 630 into the serial port on the 6386, run layers, and rlogin
>one of the layers into the 3B1 for all my use of the 3B1.  This way
>the machines can both go in another room where their noisy fans and
>tiny screens don't bother me.

Rats.. I do something like the reverse of this using the 3B1 as a terminal
with an rlogin-like program that connects via starlan-TLI to any/all of
6 3B2's on the net.  I usually fire up the connection with a shell script
that uses windy to create a full-screen window with the name of the host
that window is connected to.  Then I can use <suspend> and pop to any
of the 3B2's with all of the screen contents kept intact.  Perhaps not
quite up to x-windows, but I like it.  Other that this, our 3B1's are
mostly just running as DOS file servers and can be replaced but I really
hate to spend the $$$ after having these machines only a year or less.

 Leslie Mikesell