crp files
Keith Bostic
keith at seismo.UUCP
Tue Aug 21 09:56:27 AEST 1984
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".
More information about the Comp.os.eunice
mailing list