[net.unix-wizards] Remote operation of a PC from a UNIX system using ``cu''

larry@kitty.UUCP (Larry Lippman) (10/06/86)

	I know very little about IBM PC's (I work with REAL computers :-) ),
and am looking for a little information and a few suggestions...

	I wish to control an IBM PC clone (NCR model PC-4, to be exact)
from a UNIX system running System V Release 2.2 (AT&T 3B2, to be exact).
The PC has some special hardware boards in it, and is pretty much running
a dedicated application.  There are occasions where it would be desireable
to control the PC from the above UNIX system, and to transfer files in
both directions (these would be TEXT files with all 7-bit characters).
	There is not enough file transfer nor PC access required to
justify any LAN hardware.
	I have the PC connected to a tty port of the UNIX system, and use
the PC-DOS ``ctty'' command to assign PC console control to the COM1 port.
No problem; ``cu'' accesses the PC just fine.  HOWEVER, I cannot interrupt
SOME of the PC functions with a CTRL-C, nor can I use the function keys,
nor can I do something like CTRL-BREAK.
	Needless to say, I have caused the PC to hang on various occasions,
which only a PC-DOS reboot will cure.
	I have carefully examined all of my PC-DOS documention, and can find
no mention of whether any ASCII characters and/or character sequences map
to non-ASCII PC keys (like the function keys, END, etc.).  Some PC programs
NEED these non-ASCII keys.
	Is there any character mapping as I have just mentioned?  If so,
is it the same for all PC-clones?  If so, where do I find the information,
and can someone give me a clue as to the nature of the mapping?
	I have transfered text files to and from the PC using a combination
of ``tee''ing a ``cu'' session and using the ``~$'' escape to send text
while in an editor on the PC (I have a ``vi''-like program for the PC).
Does anyone have a better suggestion for performing the above text file
transfers using EXISTING PC-DOS functions?  There is not enough text file
transfer to justify installing compatible communications software on the
PC (like a ``uucp'' lookalike, or say, X-MODEM).  My present approach,
while no doubt inelegant, does work - I just wonder if there is a _slightly_
better way...

==>  Larry Lippman @ Recognition Research Corp., Clarence, New York
==>  UUCP:  {allegra|decvax|rocksanne|rocksvax|watmath}!sunybcs!kitty!larry
==>  VOICE: 716/688-1231           {hplabs|ihnp4|seismo|utzoo}!/
==>  FAX:   716/741-9635 {G1,G2,G3}      "Have you hugged your cat today?" 

dalem@hpfcph.HP.COM ( Dale McCluskey) (10/07/86)

Have you investigated Kermit?  It is available for both systems and does
quite well at both file transfer and terminal emulation.  It is not a
builtin MSDOS utility, but it is free and easy to install.  You should 
be able to get it from Columbia University's Computer Center or most any 
BBS.            

					Dale McCluskey

					{ihnp4,hplabs}!hpfcla!hpfcps!dalem

bob@bakerst.UUCP (Bob White) (10/08/86)

There is a public domain program, called MS-KERMIT, which lets the PC
and compatibles act as a file server.  It can both send and receive files,
assuming you've got a program on the Unix box that can pass files to
the PC the way MS-KERMIT is expecting.  The file transfers use the Kermit
protocol.  The package is supported by Columbia University (I think that's
the right university...) and they can provide source for a number of different
machines, although I don't know if they support Unix yet.  I have the
MS-KERMIT program and documentation, if you're interested.

Bob


-- 

       Bob White

 Mail: 5123 Ramillie Run           Usenet:  ihnp4!kitty!bakerst!bob
       Winston-Salem, NC  27106        or:  ihnp4!gladys!bob 
Phone: (919) 924-0975

Reality is for those who aren't strong enough to read Science Fiction.

dave@rosevax.UUCP (Dave Marquardt) (10/09/86)

In article <275@bakerst.UUCP>, bob@bakerst.UUCP (Bob White) writes:
> There is a public domain program, called MS-KERMIT, which lets the PC
> and compatibles act as a file server.  It can both send and receive files,
> assuming you've got a program on the Unix box that can pass files to
> the PC the way MS-KERMIT is expecting.  The file transfers use the Kermit
> protocol.  The package is supported by Columbia University (I think that's
> the right university...) and they can provide source for a number of different
> machines, although I don't know if they support Unix yet.  I have the
> MS-KERMIT program and documentation, if you're interested.

Yes, there is a UNIX Kermit available, for most versions of UNIX (I've seen
it on V7, System III, System V, 4.2BSD, Ultrix, ...).  An additionaly
capability of a PC running Kermit in server mode is that you can also
run commands, as long as they don't require interaction.  For example, from
the UNIX Kermit, you could type

	REMOTE DIR

and the remote Kermit (the one on the PC) would send back the output from
the DIR command.

Probably the best way to get Kermit is to check with others in your area who
might have it.

	Dave
-- 
Dave Marquardt			UUCP:		dave@rosevax.UUCP
Rosemount, Inc.			Telephone:	612/828-3057

"I do not like green eggs and ham.  I do not like them Sam I Am!"

wmf@chinet.UUCP (William M. Fischer) (10/10/86)

In article <275@bakerst.UUCP> bob@bakerst.UUCP (Bob White) writes:
>There is a public domain program, called MS-KERMIT, which lets the PC
>...assuming you have a program on the Unix end that can deliver files..
>...I don't know if Kermit is supported in UNIX C...
Just a coupla comments...
According to the KERMIT Users Guide .. A KERMIT program MUST be running on
both ends of the communication link for file transfers to occur. (i.e., no
other protocols work with Kermit).

The most current version of UNIX Kermit is 4C(057), written in "C".

Now as to the remote operation of a PC FROM a UNIX system, KS-KERMIT 2.29
is a little weak all by itself. Better to use a communications program
that offers a host mode. PIBTERM and PROCOMM are two Shareware / PD programs
that can do this. This may not be applicable in your case, but my biggest
concern in leaving KERMIT in the remote mode and having the modem set to
autoanswer is that if some unauthorized individual calls up, he download all
your files and even convince KERMIT to drop dowm to the DOS COMMAND shell.
From there, he could do something cute, like tell the PC to format all your
disks....

Using PROCOMM, for example, would require that a password be entered before
any access to the PC would be allowed. You could even use the TEF (Timed 
Execution Facility) with PROCOMM so that the PC would only respond during
a certain time period.

If the transfer protocol MUST be Kermit, then only PROCOMM will do. You should
know that Chuck Forsberg has developed and released to the PD a X/Y/Z MODEM
package for UNIX machines.

So... you can have it both ways... You can use PROCOMM or the like on the PC
end and use KERMIT on the UNIX end and do your transfers with KERMIT

or

Still using PROCOMM on the PC end, use CU on the UNIX end and do the file
transfers with X/Y/Z MODEM.


-- 
             ====================================================  
             |    Fortiter in re,       ||     Bill Fischer     |
             |       suaviter in modo.  ||    wmf@chinet.UUCP   |
             ==================================================== 

gkb@necntc.UUCP (Greg Busby) (10/10/86)

In article <275@bakerst.UUCP> bob@bakerst.UUCP (Bob White) writes:
>There is a public domain program, called MS-KERMIT, which lets the PC
>and compatibles act as a file server.  It can both send and receive files,
>assuming you've got a program on the Unix box that can pass files to
>the PC the way MS-KERMIT is expecting.  The file transfers use the Kermit
>protocol.  The package is supported by Columbia University (I think that's
>the right university...) and they can provide source for a number of different
>machines, although I don't know if they support Unix yet.  I have the
>MS-KERMIT program and documentation, if you're interested.
>
>       Bob White
>
KERMIT is available on many, many machines.  There are several
implementations for Unix, and several for the IBM PC and compatibles.
The program is used extensively here at NEC and we have only had one
small problem with an old version of the unix KERMIT.  I have adapted
KERMIT for several machines myself, and would like to say that it is
very well-written, highly modular (requiring only machine specific
changes in a small part of the program) and very-well thought out.  I
would highly recommend it to anyone who is looking for a public domain
computer to computer communications program.  Columbia University is
indeed the distributor, and you can reach them at:

	Columbia University
	Center for Computing Activities
	New York, NY 10027

The author is Frank da Cruz, who has recently published a book on the
subject of KERMIT.

Oops, I just realized I said "public domain".  The program is coyrighted
by Columbia University, but "Permission is granted to any individual or
institution to copy or use this document and the programs described in it,
except for explicitly commercial purposes" [from the manual].

Disclaimer:  NEC Electronics, Inc. provides and supports KERMIT for its
customers to aid in the development of programs.  We are in no other way
connected to Columbia University.

peter@catuc.UUCP@ndmce.uucp (Peter Collins) (10/18/86)

> Better to use a communications program
> that offers a host mode. PIBTERM and PROCOMM are two Shareware / PD programs
> that can do this. This may not be applicable in your case, but my biggest

I've been using procomm this way now for several weeks. Its worked just
fine for controlling my pc from a remote unix machine via cu. Just be sure
not to run any program that talks directly to the pc screen or keyboard.
Debug works fine remotely as does edlin and most c compilers I've tried.

pc