crp files

[Keith Bostic]

Yeah, the process number plays hell will programs running under Eunice,
especially if they ran on a UNIX system and you're porting them.  Waits
for specific process numbers tend to fail, for one thing.  What we did
to solve the problem was to write:

	#define MAX	300000
	#define LOCK	"NEXT"
	#define FNAME	"/etc/next"
	next()
	{
		register int	val;
		register FILE	*fp;
		int	lock;
		char	*fgets();

		vmlock(LOCK,&lock);
		if (fp = fopen(FNAME,"r+")) {
			val = atoi(fgets(gbuf,sizeof(gbuf),fp));
			rewind(fp);
			fprintf(fp,"%d\n",!val || val > MAX ? 1 : val + 1);
		}
		vmunlock(lock);
		return(val ? val : getpid());
	}
This can be used from a shell program (the program /usr/local/next calls
this routine and writes the number to the standard output) and as a call
in any C program.  I didn't have my VMS manuals at hand so if you want
to have the source for vmlock (it's just one humongous VMS call) and
vmunlock (another VMS call) let me know.  Or, if you don't mind
exploiting a Eunice bug, just open a well-known file for writing -- since
no two programs can have the same file open for writing, it effectively
locks the system until the file you want is available for you.

Admittedly, this isn't all that elegant -- but, if you enforce its
usage by everyone on the system, it works.

		Keith 
			ARPA: keith at seismo 
			UUCP: seismo!keith

p.s.	Note, the code above is *not* debugged, I just dashed it off,
	and while it looks okay to me, lint it and test it before you
	trust it.  If space is a problem, you might want to get rid of
	the call to fprintf and use some form of fputs of a call to
	an itoa routine; make sure that you put the EOL in, however,
	it makes the fgets work, keeping you from having to worry
	about changing the size of the number, i.e., "30000" is bigger
	than "45".