GEustace@massey.ac.nz (05/11/89)
We have been using Sun's PC-NFS product for about 6 months now. And in general are very pleased with it. Congratulations to Geoff Arnold for bringing life to our many ageing PCs. It is our intention to provide many services on our network based around this product, however we have come up against a number of problems which we need solutions for. Problems/Questions. 1. Compiler version. The PC-NFS/TK v1.0 has been compiled using MSC4.0. This compiler is not available anymore according to the Microsoft people here in NZ. I used v5.1 for a while but the resulting programs would never run correctly. I was told there are some code incompatibility between releases. Anyway a v4.0 was procurred and those problem went away. I would much rather use v5.1 of MSC, can we get a version of the toolkit that is compiled using v5. 2. The Small model library has a number of routines which have Uppercase names, this means that one cannot use /NOI during the LINK, although not a bug it is annoying. 3. NFSDRIVE Environment Variable. Between versions 2 and 3 of PC-NFS the NFSDRIVE Environment variable was introduced. Its intention is to tell the software where the local databases are. The telnet, ftp etc work as stated. However the toolkit routines for db lookup don't take any notice of it. We have set things up so that a very small hosts file is on the PC and the real one is one the server, thus as soon as the network drives are mounted we set NFSDRIVE to the network drive P:. 4. EM.SES Environment. Related to the above is this variable which is supposed to tell telnet where to write its EM.SES file. Our Network P: drive with \NFS on it is RO so every time telnet is used it always comes up with XON on! To get around this I have tried set EM.SESS=C:\ but to no avail. What I have now is a bat file that does; set NFSDRIVE=C telnet %1 set NFSDRIVE=P Not an ellegant solution but it works. 6. Server Shutdown. We are using a Pyramid 9815 and a Sun386i as File Servers. The Sun and PCs are our NFS clients. As part of the shutdown procedure on the Pyramid a program called /etc/nfswarn is run. It tells all its clients that it is going down. The Sun displays a message in is command window. The PCs do nothing, they just get a DRIVE NOT READY ERROR when they try accessing the server. It would be great if the PC NFS could blink a Blob like it does when there is RPC activity so that PC users can save their work before the server goes away. 7. Almost invariably people never NET USE /d their remote drives before turning off their PCs. Consequently /etc/rmtab for each PC tends to grow. It would be great if NET START do the same as the unix umount -a at boot time, i.e. tell all servers to dismount any remote filesystems for this client. I have tried doing it myself with the mount RPC call MOUNTPROC_UMNTALL. It seems to work but I always get a non-zero return saying RPC_SYSTEMERROR. My code is: client = clntudp_create( &server_addr, (u_long)100005, (u_long)1, pertry_timeout, &sock ); ... client->cl_auth = authunix_create_default(); ... clnt_stat = clnt_call( client, (u_long)4, xdr_void, 0, xdr_void, 0, total_timeout ); ... clnt_perror prints 'Remote System Error'. Any clues?. 8. Communicating with PCNFS.SYS. We have got to the stage where a number of our projects require that we have access to information stored internally by PCNFS.SYS. This information is accessible as the NET Command and LS command can print it. It is my believe that by calling the DOS IOCTL function and passing appropriate parameters that the information will be returned. We don't want to spend hours reverse engineering the product but we will have a go if no-one can help. The information we need includes; Drive to Remote file system mappings. i.e. as shown by NET USE. DOS to UNIX Name mapping cache. i.e. as shown by LS -b. I am sure that there is probably alot more useful information inside PCNFS.SYS that we could use if we could get at it. 9. IO Redirection. We have tried IO Redirection from a network drive and found that PCNFS dies. i.e. TYPE < P:MYFILE kill system. TYPE < C:MYFILE no problem. If anyone has addressed any of these areas or knows why or how, please let me know, I would love to here from you. Glen Eustace, Software Mgr, Comp.Cntr, Massey Uni, Palmerston Nth, N.Z. Janet/Greybook: G.Eustace@nz.ac.massey Phone: +64 63 69099 x7440 CSnet/ACSnet/Internet: G.Eustace@massey.ac.nz New Zealand = GMT+12 [[ Discussions about PC-NFS should take place on the "nfs" mailing list. Submissions to "nfs@tmc.edu" and add request to "nfs-request@tmc.edu". --wnl ]]