wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (12/05/90)
We all would like to set the rights of a file once in a while, don't we?
Now Apollo has some few more rights then others, so the normal stat(2) does
not work.
So what's wrong with looking in an Aegis Call reference to lookup anything that
has to do with 'acl'?
I'll tell you: I wasn't able to find anything except for up/down in a protected
subsystem.
To me this is nothing more than a std-call I want to use. I can even do it on
a dirty of the self MS-BARF-IBM box, so why not under Aegis?
Well actually you can, but it's hidden somewhere in my documentation.
And I can't find it :-{. So who's going to help me.
Maybe in return I'll render something usefull for in the COPS package.
Thanx,
Willem Jan.
PS: for those wanting to know more:
try a 'strings -a /com/acl | grep acl'
and you'll see what I mean with an obscured operating system. Lots of
calls nobody has ever heard about.
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlandskrowitz@RICHTER.MIT.EDU (David Krowitz) (12/06/90)
Most of the ACL manager calls are unreleased calls. Use /systest/ssr_util/dmpf (the hex file dumper) to look at /com/edacl. You'll see the names of all of the global subroutine calls near the end of the listing. If you can get DBX or DDE to display the assembly language for /com/edacl, you may be able to figure out the arguments to the calls. Frankly, if HP/Apollo hasn't released the calls, it's because they don't want you to use them. I think it might be easier to use the Unix "system" call or maybe the Aegis "pgm_$invoke" call to run the /com/edacl program from within your own program, feeding it (edacl) the ACL you want to set. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
rees@pisa.ifs.umich.edu (Jim Rees) (12/07/90)
In article <9012061511.AA04340@richter.mit.edu>, krowitz@RICHTER.MIT.EDU (David Krowitz) writes:
Most of the ACL manager calls are unreleased calls. Use /systest/ssr_util/dmpf
(the hex file dumper) to look at /com/edacl. You'll see the names of all of
the global subroutine calls near the end of the listing.
That's a bit clumsy. I prefer "nm," which will give you just the names of
the system calls made by edacl (or any other program).
If you can get DBX or
DDE to display the assembly language for /com/edacl, you may be able to figure
out the arguments to the calls.
I have a little program I sometimes use for hacking unreleased calls. You
can get the address of the call with "esa." Using "nm" on "esa" will tell
you the name of the routine that returns the address of a system call. Using
this call you can write a program that takes the name of a system call and a
list of arguments, and calls it. Since system calls almost always have a
status out-arg as the last argument, and status codes are easy to recognize,
it's not hard to find out how many arguments the call takes. A little guess
work and some experiments and you can usually figure them out.
Frankly, if HP/Apollo hasn't released the calls,
it's because they don't want you to use them.
Yes, but they're not just trying to make your life difficult (even though it
may seem that way sometimes). Every call that gets released has to be
documented and supported, and can never be changed or un-released.
At one time I think there was a book called something like "Programming With
Dangerous Unreleased Calls" (or something like that) that described some,
but not all, of the unreleased calls. It may have only been available to
OEMs, big customers, or Universities.krowitz@RICHTER.MIT.EDU (David Krowitz) (12/07/90)
Thanks! "nm" was something I haven't seen before ... it *IS* handy. So is "esa".You are correct about the manual having existed. It was in the actual Apollo price list for awhile back at SR9.x, but they removed it. I think it was called something like "Programming With Advanced System Calls". Somebody like Dave Funk at U. Iowa ought to have copies of it -- I think I remember seeing some code from him that used the CL_$ calls (the Aegis command-line parser and wild-card handling calls). Anyone have a copy of this manual that they are willing to Xerox for the net? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
brady_p@apollo.HP.COM (Peter Brady) (12/14/90)
In article <9012071413.AA04525@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >....You are correct about the manual having existed. It was >in the actual Apollo price list for awhile back at SR9.x, but they >removed it. I think it was called something like "Programming With >Advanced System Calls"... > > -- David Krowitz The manual was called "Programming with Domain Advanced System Calls". The problem with it is that a lot of the manual is only useful for SR9.X systems; some of the stuff (like the registry and loader calls) are very different in SR10. --pete
wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (12/14/90)
In article <4e93f2ff.1a630@apollo.HP.COM> brady_p@apollo.hp.COM (Pete Brady) writes: >In article <9012071413.AA04525@richter.mit.edu> krowitz@RICHTER.MIT.EDU (David Krowitz) writes: >>....You are correct about the manual having existed. It was > >The manual was called "Programming with Domain Advanced System Calls". >The problem with it is that a lot of the manual is only useful for SR9.X >systems; some of the stuff (like the registry and loader calls) are very >different in SR10. Mind you though, the loader call are documented in the std-manual(some I guess) the registry call are again a nono. Well I talked with my a friend here at HP/Apollo, and he's going to try to get me the SR9 manual. (IF he can still find it) I know that it's of very little use, but it'll give me a clou as to what is going around as typical parameters in those systemcalls. The argument of not having all calls documented because of future changes is very viable too me. But I think that the user should be supplied with a set of calls large enough to get all of his/hers work done. And this would mean that I would be able to set the aegis rights by making *DOCUMENTED* systemcalls. I don't care about the registry(unless my apollo is standalone, I don't want to mess) or the printer-server. The printer-server however is not fully complete and has always required patching.(This is also not a very trivial thing) So my argument here is: Why are some things documented, and hence fixed in their interfaces and are others completely obscured for the sakes of wanting to limit the OS-engineers? Yours, Willem Jan Withagen. Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands