dennis@PEANUTS.NOSC.MIL (Dennis Cottel) (03/04/89)
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
achille@cernvax.UUCP (achille) (03/05/89)
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
tim@tim.UUCP (Tim Giebelhaus) (03/06/89)
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. "Unsupported" would be a better word than "secret". Routines which are not documented may change between releases without warning of any kind. Also, you will find no support from Apollo for unsupported system calls (unless you have a prior agreement with marketing which is usually only given to some OEMs). Thus, if you can't find the call in a public manual, use it at your own risk. If there is a system call you would like to see made public, please file an APR with the /com/crucr or /usr/apollo/bin/mkapr command. APR's are the only supported method of getting changes done to the operating system. APRs are also what Apollo uses internally to get changes done. -- UUCP: uunet!hi-csc!apcimsp!tim ARPA: tim@apollo.com Contents of this message has nothing to do with work.
hofkin@software.org (Bob Hofkin) (03/06/89)
It is possible to get the asknode insert files, but it is *NOT* easy. The calling sequence is weird enough that you probably can't deduce it; remote provides a simpler interface but it's an object module that isn't normally available, either. Your best bet for any of this stuff is to find a technical contact at Apollo and convince them you really need the stuff. Then be prepared to nag them for a few months. I had once been told that the calls are not unpublished, but just "undocumented" and unsupported, and that they'd all be public in SR11. But the insert files do say proprietary and confidential.