rbraun@spdcc.COM (Rich Braun) (05/14/91)
On a related topic, I'm wondering if there's a way to run cu through a TCP/IP connection. I've got a few workstations running System V, and a "server" system is connected to them via TCP/IP. This other system (an RS/6000 running AIX) has a couple of modems on it, allowing one to run 'cu' outbound. There's a really great program called 'ecu' which looks something like Procomm, but it runs on System V and is free. I'd love to be able to run this program and have it automagically connect to a modem on the RS/6000 via TCP/IP. Any hints? -rich
larry@nstar.rn.com (Larry Snyder) (05/16/91)
what we do is to telnet (or rlogin) to a machine on the network -
then fire up ProYam over the network - everything runs just dandy
--
Larry Snyder, NSTAR Public Access Unix 219-289-0287/317-251-7391
HST/PEP/V.32/v.32bis/v.42bis
regional UUCP mapping coordinator
{larry@nstar.rn.com, ..!uunet!nstar.rn.com!larry}wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (05/16/91)
In article <7525@spdcc.SPDCC.COM> rbraun@spdcc.COM (Rich Braun) writes: >On a related topic, I'm wondering if there's a way to run cu through >a TCP/IP connection. I've got a few workstations running System V, and > >There's a really great program called 'ecu' which looks something like >Procomm, but it runs on System V and is free. I'd love to be able to >run this program and have it automagically connect to a modem on the >RS/6000 via TCP/IP. Thank you for the compliments on ecu. However, it insists on talking to a tty driver directly. The driver must reside on the same system as the port unless you have an, er, ahm, more recent generation of UNIX than I do. One solution would be to rlogin to the 6000 through conventional means and run ecu -on the 6000-. This would work well except that ecu has not been ported there. I have a new version in work that does well to pave the way for porting ecu to any System V-ish system which also supports select(2). select(2) is a very popular thing for System V these days with TCP/IP and X11 running on so many of them. The new version appears ready to work on ISC very soon. This means more than you may think, because though both SCO and ISC are very similar in many ways, the vagaries of shared in/out modems, locking, tty naming and so forth are very, very different. I miss SCO's dialer features on ISC and will be carrying that concept over for ecu's private use. There is a gentleman in California that is looking into a port for the 6000. It (AIX) has a very bizarre mixture of System V and BSD and just plain IBMisms in it, so a successful port to it will uncover so many areas of system dependence that it may become readily apparent what needs changing for a port to the Commodore 64 :-). (I do expect ecu procedures will run faster on the 6000 than they ever have anywhere else, though.) I hope to post ecu 3.10 this summer. If anyone is seriously interested in helping port, I will be happy to send copies of the work in progress and to assist. I give good credit. ------------------------------------------------------------------------ Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US "An ANSI C elephant: just like the real one, but the position, shape and length of the trunk and tail are left to the vendor's discretion." -- me
lh@aega84.UUCP (L. Hirschbiegel) (05/16/91)
In article <409@n4hgf.Mt-Park.GA.US> wht@n4hgf.Mt-Park.GA.US (Warren Tucker) writes: >> >>There's a really great program called 'ecu' which looks something like >>Procomm, but it runs on System V and is free. I'd love to be able to >>run this program and have it automagically connect to a modem on the >>RS/6000 via TCP/IP. > >Thank you for the compliments on ecu. However, it insists on >talking to a tty driver directly. The driver must reside on the >same system as the port unless you have an, er, ahm, more recent >generation of UNIX than I do. > I'm running ecu on a less recent unix generation :-) ISC 2.2 and I am perfectly able to connect over TCP/RFS to our RFS server and use the serial modem ports there from the remote machine. So if there is RFS available for RS6000 (is it?) this should work. >The new version appears ready to work on ISC very soon. This >means more than you may think, because though both SCO and ISC Hey, don't bash your own product :-) ! Since V2.x I'm using it under ISC and besides some hacking in the keyboard routines and smaller changes it was not too complicated to port. Keep on improving ecu - IMHO it's still the best communiciation prog ! -- ==================================================================== L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany) unido!aega84!lh -49-69-66414316 ====================================================================
les@chinet.chi.il.us (Leslie Mikesell) (05/16/91)
In article <1060@aega84.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes: >I'm running ecu on a less recent unix generation :-) ISC 2.2 and I am perfectly >able to connect over TCP/RFS to our RFS server and use the serial modem ports >there from the remote machine. So if there is RFS available for RS6000 (is it?) >this should work. You should note that this depends on the structs used by ioctl() being identical on the client and server machines, which is pretty unlikely among different CPU types, especially if one of them happens to be an Intel and the other isn't. Also, things like lockfiles for the ports will be done wrong, although HDB uucp seems to use kernel locks on the device itself, which does work over RFS (so you should probably modify ecu to do that also if it doesn't already). Les Mikesell les@chinet.chi.il.us
lh@aega84.UUCP (L. Hirschbiegel) (05/17/91)
In article <1991May16.154418.24131@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1060@aega84.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes: > >You should note that this depends on the structs used by ioctl() being >identical on the client and server machines, which is pretty unlikely >among different CPU types, especially if one of them happens to be >an Intel and the other isn't. Also, things like lockfiles for the ports >will be done wrong, although HDB uucp seems to use kernel locks on the >device itself, which does work over RFS (so you should probably modify >ecu to do that also if it doesn't already). > >Les Mikesell > les@chinet.chi.il.us Our RFS server is of course the same type of machine (all Compaqs) running the identical os version. But anyway: the structs used by the ioctl's should never be dependend on the type of cpu - as long as it is all SysV.3 or SysV.4 (and this IS in fact the limiting factor for RFS:-). I didn't find any differences in struct termio (which is obviously used here) depending on the version of SysV. Furthermore is it VERY unlikely you wouldn't find TCGETA and TCSETA in any version of SysV, and thats what ecu is actually using (and maybe TCSBRK but thats quite easy to avoid). Regarding lockfiles: no problem here. What could prevent you from sharing /usr/spool/locks all over the RFSnet?? As long as the usual lockfile format is used I wouldn't expect any fighting for devices. Even then I did some (admittedly quick n'dirty:-) solutions by wrapping the application into a shell script which creates some locks prior to accessing the device. To conclude, we have used shared serial devices via RFS very extensively with almost zero problems, but the question still remains: can it be done with an RS6000? (Think this was the original posters equipment). If there is no RFS for the beast the problem is void. L. Hirschbiegel -- ==================================================================== L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany) unido!aega84!lh -49-69-66414316 ====================================================================
les@chinet.chi.il.us (Leslie Mikesell) (05/18/91)
In article <1061@aega84.UUCP> lh@aega84.UUCP (L. Hirschbiegel) writes: >Our RFS server is of course the same type of machine (all Compaqs) >running the identical os version. >But anyway: the structs used by the ioctl's should never be dependend >on the type of cpu - as long as it is all SysV.3 or SysV.4 (and this >IS in fact the limiting factor for RFS:-). I didn't find any differences >in struct termio (which is obviously used here) depending on the >version of SysV. Furthermore is it VERY unlikely you wouldn't find >TCGETA and TCSETA in any version of SysV, and thats what ecu is actually >using (and maybe TCSBRK but thats quite easy to avoid). RFS passes ioctl() structs in straight binary. That means that differences in byte ordering and field padding will affect operation even though the termio.h files say the same things. For example, I have 3B2's and 386's RFSed together both running AT&T SysVr3.2 and a program on one cannot ioctl() the devices on the other. In fact, I haven't been able to get uucico to work over RFS to a remote device on an identical machine, although cu will do it on the 386's. >Regarding lockfiles: no problem here. What could prevent you from >sharing /usr/spool/locks all over the RFSnet?? As long as the usual >lockfile format is used I wouldn't expect any fighting for devices. Several problems. First you need a unique name for every device (shared or not) on the net that uses lockfiles, and you have to make sure that the RFS link is up before you start any of the processes that use them (like uugetty). Second, uugetty doesn't remove its lockfile. How can it - it's gone at the time it should be removed? So programs that use lockfiles to contend with uugetty check to see if the locking program is still running by sending signal 0 to the process and checking the status returned from kill(). If the process is actually on another machine, kill() isn't going to find it and the program will assume the lockfile is invalid. The correct approach here is to use kernel locks since they work over RFS. Even on local devices it is the best approach - I've seen uucico's debug output indicate that it succeeded in obtaining a lockfile but still failed to get the kernel lock (which really indicates that the lockfile scheme didn't work). >Even then I did some (admittedly quick n'dirty:-) solutions by wrapping >the application into a shell script which creates some locks prior to >accessing the device. I'm pretty sure it isn't possible to do locks right in a shell script. Creating a tmp file and using /etc/link to attempt to rename it to the agreed-upon lockfile name is OK if it works, but you can never safely test or remove an existing file. Some version of ln might do what you want, but SysVr3 removes the target before attempting the new link. Les Mikesell les@chinet.chi.il.us
lothar@tmcsys.UUCP (L. Hirschbiegel) (05/18/91)
In article <1991May17.171141.27309@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >RFS passes ioctl() structs in straight binary. That means that differences >in byte ordering and field padding will affect operation even though >the termio.h files say the same things. Sorry: as far as I know this is simply not true. Anyway there is passing of different structs for other affected syscalls as open(), creat() lockf() and so on. You wouldn't deny they are working :-) ? And if there is some kind of xdr (or basically some hton* and n*toh) why should just ioctl() be left out? Makes no sense for me... >In fact, I haven't been able to >get uucico to work over RFS to a remote device on an identical machine, >although cu will do it on the 386's. Hmmm, this can have many reasons. Dunno what didn't work with uucico, but cu is just needing the (shared) device and some Systems and Dialers file, whereas uucico would need some more shared directories over RFSnet. > >>Regarding lockfiles: no problem here. What could prevent you from >>sharing /usr/spool/locks all over the RFSnet?? As long as the usual >>lockfile format is used I wouldn't expect any fighting for devices. > >Several problems. First you need a unique name for every device >(shared or not) on the net that uses lockfiles, and you have to >make sure that the RFS link is up before you start any of the processes >that use them (like uugetty). C'mon, this is trivial. You even have to make sure your home directory is mounted on the local disk before trying to log in, don't ya :-) ? Thats just a simple "/etc/mount | cut -f 3 -d ' ' | grep your_RFS_resource". And giving unique names to all of the tty devices in a local RFSnet isn't THAT impossible. I've done it by appending the host name to the appropriate tty0[01] entry, so you can even identify the locking host very easy in case you need that. I did not say you just turn the key and have a perfect RFSnet with shared tty devices... >Second, uugetty doesn't remove its >lockfile. How can it - it's gone at the time it should be removed? You are right here. But there are some hundred reasons more besides problems with RFS not to use uugetty. >uucico's debug output indicate that it succeeded in obtaining >a lockfile but still failed to get the kernel lock (which really >indicates that the lockfile scheme didn't work). This is really strange. All I can say is that it worked here. Buggy RFS version? Configuration problem? >I'm pretty sure it isn't possible to do locks right in a shell script. >Creating a tmp file and using /etc/link to attempt to rename it to >the agreed-upon lockfile name is OK if it works, but you can never >safely test or remove an existing file. Do you expect race conditions or what? >Les Mikesell > les@chinet.chi.il.us Lothar Hirschbiegel -- ----------------------------------------------- L. Hirschbiegel, AEG - A84, Frankfurt (Germany) email: unido!aega84!lh tel: -49-69-66414316 -----------------------------------------------
les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)
In article <377@tmcsys.UUCP> lothar@tmcsys.UUCP (L. Hirschbiegel) writes: >[Re: RFS vs. ioctl()...] >Sorry: as far as I know this is simply not true. >Anyway there is passing of different structs for other affected syscalls >as open(), creat() lockf() and so on. You wouldn't deny they are working :-) ? >And if there is some kind of xdr (or basically some hton* and n*toh) why >should just ioctl() be left out? Makes no sense for me... The other structs are known ahead of time. Ioctl() passes structs that are specific to the device driver so there is no general way for another machine to interpret them. It doesn't have to make sense, they are the phone company... >>In fact, I haven't been able to >>get uucico to work over RFS to a remote device on an identical machine, >>although cu will do it on the 386's. >Hmmm, this can have many reasons. Dunno what didn't work with uucico, but >cu is just needing the (shared) device and some Systems and Dialers file, >whereas uucico would need some more shared directories over RFSnet. No, it shouldn't need any other shared files and I could get it to go as far as logging into the remote system but it would fail as it started to go into the file transfer protocol. >You are right here. But there are some hundred reasons more besides problems >with RFS not to use uugetty. Huh? I haven't had any problems at all with uugetty. I'd prefer something smarter about handling modems that tell you the speed they are using, but other than that it works just fine. Why don't you like it? There is the possibility of an incoming call being picked up by an outbound call going off-hook to dial, but the only way to completely close the window on that is to not enable auto-answer on the modem until you see it say 'RING', then obtain the lock before picking up. >>uucico's debug output indicate that it succeeded in obtaining >>a lockfile but still failed to get the kernel lock (which really >>indicates that the lockfile scheme didn't work). >This is really strange. All I can say is that it worked here. >Buggy RFS version? Configuration problem? No, this didn't involve RFS at all - it was entirely local. It just shows that lockfile locking is not robust (actually it is only a problem to remove lockfiles that some other process created). >>I'm pretty sure it isn't possible to do locks right in a shell script. >>Creating a tmp file and using /etc/link to attempt to rename it to >>the agreed-upon lockfile name is OK if it works, but you can never >>safely test or remove an existing file. >Do you expect race conditions or what? Of course I expect race conditions. The whole idea of trying to lock the resource is that you expect more than one process to try to use it at once. Since no operation you can use to test the validity of a lockfile can be atomic with removing it or creating your own, you never know that the file you remove is the same one you tested or one belonging to a process running a time-slice ahead of you that just went through the same steps. As it happens, uucico would eventually give up and retry later if it did happen to get two copies running on the same line, but other programs might not be so forgiving. Les Mikesell les@chinet.chi.il.us
lothar@tmcsys.UUCP (L. Hirschbiegel) (05/20/91)
In article <1991May19.041007.14192@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >The other structs are known ahead of time. Ioctl() passes structs that >are specific to the device driver so there is no general way for another >machine to interpret them. It doesn't have to make sense, they are >the phone company... Where ends meet. This is what I said: if cpu's are similar or (even better) equal, things will work. At least ioctl's are implemented in ISC. (I remember some of the first RFS implementations a while ago, which still were in the public domain. Have it somewhere buried on my archive tapes. They didn't implement ioctl and select, so you could open, read, write and close a remote tape drive but retensioning, erasing or rewinding the tape did not work...:-) >Huh? I haven't had any problems at all with uugetty. I'd prefer something >smarter about handling modems that tell you the speed they are using, Did you try "agetty", which came over usenet some time ago? It implements exactly this. Should be quite easy to add some uugetty-like routines for lockfile handling if you like this kind of handshaking. >Of course I expect race conditions. The whole idea of trying to lock >the resource is that you expect more than one process to try to use >it at once. Since no operation you can use to test the validity of >a lockfile can be atomic with removing it or creating your own, you >never know that the file you remove is the same one you tested or >one belonging to a process running a time-slice ahead of you that >just went through the same steps. As it happens, uucico would eventually >give up and retry later if it did happen to get two copies running >on the same line, but other programs might not be so forgiving. Some times ago I was in a design and implementation group for a parallel multiprocessor OS (256 68020 cpu's). We had to spend a lot of time avoiding deadlocks and race conditions in our system... This is a fundamental problem. It has been shown by others that even a system with sufficient atomic (and/or semaphore) operations will suffer from that, as long as there is any kind of asynchronicity in message passing or data access. Strictly speaking this means that ALL multitasking operating systems are basically instable. So far for the scientific approach. [ maybe we should shift this discussion to comp.os.race.conditions :-) ? ] In practice I do not care if in fifty remote accesses to my (RFS shared) tty ports there is one race condition occuring. Just try again. I DO care if this happens every second time, but even with a locking scheme realised by shell scripts I'm far from that... :-) >Les Mikesell > les@chinet.chi.il.us Lothar Hirschbiegel -- ----------------------------------------------- L. Hirschbiegel, AEG - A84, Frankfurt (Germany) email: unido!aega84!lh tel: -49-69-66414316 -----------------------------------------------
cmf851@anu.oz.au (Albert Langer) (05/21/91)
In article <1991May17.171141.27309@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >I'm pretty sure it isn't possible to do locks right in a shell script. >Creating a tmp file and using /etc/link to attempt to rename it to >the agreed-upon lockfile name is OK if it works, but you can never >safely test or remove an existing file. Some version of ln might >do what you want, but SysVr3 removes the target before attempting the >new link. I was under the impression it is safe to use mkdir since unlike linking a file, that is atomic. Anyone disagree? e.g.: [ mkdir $lockdir ] || echo "Already locked" -- Opinions disclaimed (Authoritative answer from opinion server) Header reply address wrong. Use cmf851@csc2.anu.edu.au
wes@harem.clydeunix.com (Barnacle Wes) (06/01/91)
In article <1061@aega84.UUCP>, lh@aega84.UUCP (L. Hirschbiegel) writes: > [Discussion of ioctl's not working across RFS on heterogeneous > machines...] > Our RFS server is of course the same type of machine (all Compaqs) > running the identical os version. > But anyway: the structs used by the ioctl's should never be dependend > on the type of cpu - as long as it is all SysV.3 or SysV.4 (and this > IS in fact the limiting factor for RFS:-). I didn't find any differences > in struct termio (which is obviously used here) depending on the > version of SysV. The C code for the structure is not the problem; the problem comes with such things as byte order and data element alignment. One machine may stick "gaps" of unused memory in the middle of a struct - such as the MIPS where nearly everything gets aligned on a 4-byte (32-bit word) boundary. And, of course, if you try to go from a little-endian to a big-endian (say, Intel to Motorola) cpu without byte-swapping, you're really screwed. > To conclude, we have used shared serial devices via RFS very extensively > with almost zero problems, but the question still remains: can it be > done with an RS6000? (Think this was the original posters equipment). > If there is no RFS for the beast the problem is void. I Dunno, but I doubt it. What's the byte order on the RS? Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes