Path: utzoo!attcan!uunet!mcvax!cernvax!achille
From: achille@cernvax.UUCP (achille)
Newsgroups: comp.sys.apollo
Subject: Re: remote process info?
Message-ID: <949@cernvax.UUCP>
Date: 5 Mar 89 15:13:40 GMT
References: <8903032320.AA19843@cod.nosc.mil>
Reply-To: achille@cernvax.UUCP ()
Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland
Lines: 64

In article <8903032320.AA19843@cod.nosc.mil> dennis@PEANUTS.NOSC.MIL (Dennis Cottel) writes:
>A map listing of DSPST shows the following "secret" library calls:
>
>   rem_proc1_$info
>   rem_proc2_$info
>
>Would someone please mail me the calling sequence for these routines?
>What I'm specifically after is a way to get the process time for the
>idle process on remote machines, similar to what was done in the
>recently posted "load_stat" program.  Thanks.
>
>	Dennis Cottel  Naval Ocean Systems Center, San Diego, CA  92152
>	(619) 553-1645      dennis@nosc.MIL      sdcsvax!noscvax!dennis

Apparently there are lot of people interested in unreleased system calls
about process control.
Now I think is a good idea to explain a few things:
	1) rem_proc1_$info is a routine internal to dspst.
How can I say that ? try 'esa rem_proc1_$info' and then try 'esa proc1_$get_info'
and this will show you that the first call is not loaded in global space where
the second is.
	2) when I was fiddling around with those calls, the nearest thing
to rem_proc1_$info I found was asknode_$get_info I think. Unfortunately I believe
this beast asks more or less any kind of information, not just process status.
(I just dump'd dspst and the call is asknode_$info, not get_info).
	3) I've been asking Apollo these kind of information since 1985.
The answer has always been: unsupported, undocumented. May be if enough people
ask for that, you could finally get something (I personally gave up and only use
TCP/IP for communications, so I prefer to use a Sun for dev rather than an Apollo
for this particular things, any body remembers Apollo's TCP 3.0 features ? :-)
	4) Any way, here is the way I got a few syscalls calling sequence:
(Sorry is in fortran, because of better ftn support at the time)
	integer*4 i(16),j(16),k(16),l(16),m(16),n(16)
*
*	initialize all the arrays to something very unlikely to be
*	accepted by the syscall you're trying to find out the calling
*	sequence. All 0s is often good enough.
*
	call top_$secret(i,j,k,l,m,n)

Now is just matter of running this program under the debugger and:
	a) it aborts with access violation or the like: the call is
	expecting somewhere a pointer, so you can start substite one
	at a time the arrays with a valid pointer, until it doesn't
	fail any more.
	b) it doesn't abort, so look at the content of the first
	word of each array until you find something that looks like
	a status code, use stcode to find out what the status means,
	this will you a hook to what is wrong in your call
	(name not found == the call want a file name somewhere).
	Also the status code is always the last argument to a syscall
	so you've also found the number of args.
With a few iterations, you'll have your secret calling sequence.

In my experience, is pretty easy to find calling sequence for unreleased
syscall in know packages (i.e.: proc2_$suspend, proc2_$resume).
If you try with asknode_$info, you'll probably have a much harder time.

If you need more info I can try to help, but I still think it would pay
off to go TCP/IP, at least you won't be tied to Apollo.

Hope this helps,
	Cheers, Achille Petrilli
		Cray and PWS operations