PC-NFS Problems/Questions

[GEustace at massey.ac.nz]

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 at nz.ac.massey        Phone: +64 63 69099 x7440
CSnet/ACSnet/Internet: G.Eustace at massey.ac.nz      New Zealand = GMT+12

[[ Discussions about PC-NFS should take place on the "nfs" mailing list.
Submissions to "nfs at tmc.edu" and add request to "nfs-request at tmc.edu".
--wnl ]]