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