kds@intelca.UUCP (Ken Shoemaker) (08/20/84)
Has anyone else had files named "crp" show up in your directories?
It seems to have something to do with using pipes in Eunice. Is
there any way to make sure that they don't get generated, or at
least, if they must be generated, that they will go away?
And another thing I find particularily (!) annoying with Eunice,
has anyone figured out how to create unique process name related
files for files that stay around after a process "dies." In
Eunice, a process just doesn't die, but for performance reasons,
is stays around, waiting to be used by the next fork that comes
around. As a result, process numbers are no longer unique
in non-concurrent processes (at least in Unix, you have to
wait for 30000 other procs before your number comes up again).
Also, because VMS has such long process number, the Eunice
process number isn't the real process number, as far as I
can tell. It seems that 187, 186, 191, 194 are very common
process number reported by Eunice shells (using the $$
shell thingy). Anyway, anybody out there found a cheap way
around this? What I have managed to do is pull some of the
fields out of "date" and used them, but that requires using
something like "awk."
--
Ken Shoemaker, Intel, Santa Clara, Ca.
{pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!kds
---the above views are personal. They may not represent those of Intel.keith@seismo.UUCP (Keith Bostic) (08/21/84)
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@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".