Stan Sieler <[log in to unmask]> wrote: >Here are my comments. If I thought all 20 questions were good, >I'd give the Sylvan (?) people a score of 20. But...that's not >the case. I marked the ones they missed with a "-" in the >left column. (Some that I didn't mark that way I still have >complaints about.) > <snip> I agree with pretty much everything Stan wrote and have a few additional comments. >MPE/iX Fundamentals > > 1. ok. > > 2. ok...but should allow for open book, like real life No question. *Nobody* knows everything off the top of their head. And when you are only 90% certain of the answer you use :HELP or a manual. Someone once said "It's a lot easier to answer a question than clean up after a guess." > >- 3. BAD: TWO answers are correct! (C and D) I can't stand buzzwords. "Implicit dereferencing" I want to know if you can read and write a command file that does something a bit more useful than ST for SHOWTIME and SJ for SHOWJOB. I don't care whether you call it "implicit/explicit dereferencing," "variable substitution," or just plain "insert value here." > > 4. ok > >- 5. WRONG! The correct answer is, well, there isn't one out of the four choices. > The ostensible correct answer presupposes too many things. > Additionally, it's a completely inappropriate question for an MPE test! > A better question would be about hierarchical databases. I admit, I got caught up looking for the best definition of an Image Database and overlooked the "object database model" I bet you won't find a question about hierarchical databases on a non-MPE cert. test! > > 6. ok > > 7. ok (a little odd on the terminology with "... is attached to the root") > > 8. ok > > 9. ok > > 10. ok (except the "DATE <=" isn't valid syntax as shown!) > > >MPE/iX System Management > > 1. ok <snip> > 7. obscure > Heck, I didn't even *know* about the RESETACCT command. And, they > biased the question by omitting part of the description. "HELP RESETACCT" > say "Zeros the running counts of CPU time or connect time accumulated by > an account and by all groups within that account." They omitted the > "by an account", which led me to analyze it with "hmm, seems to only > affects group in my account, therefore AM ought to suffice". > > (Yeah, I missed that one :) > I'd read "Any user with AM capability", and thought to myself > "well, they're being sloppy...they probably meant any user *in the same > account* ... which, of course, wasn't the case. I was thinking the same thing. I can't remember the last time I used RESETACCT. Plus, usually an AM user can do most anything within his/her own account. There are plenty of other commands that have more value like SHOWQ and SHOWPROC that would make for a better question. > >- 8. WRONG! ("Where is device class information for disks stored?") > > There are ostensibly two correct answers: VCT and DCT. The first of > those is the Volume Class Table ... which has *NO* device class > information. It has *VOLUME* class information, not *DEVICE* class! Does the name of the MPE internal tables really matter for this type of test? Isn't it more important to understand how they are used and manipulated? > >- 9. BAD! Both C and D can be correct. There are arguments in favor of > each one. (For D, you'd typically use ";KEEP") > (Argument in favor of D over C: C could potentially restore > week old passwords, possibly opening a security hole; additionally, > there's a hope that the restore utility's "KEEP" option might be > quicker at skipping files, thus saving restore time instead of > doubly restoring some files) > Buzzwords again. I want to know that I can ask an admin. to develop a backup strategy to back up the entire system on Sunday and on each weekday everthing that has changed since Sunday. I don't care whether or not you call it incremental, partial, or cumulative, (the definition of which has been blurred over the years by misuse) I just want to know if you can develop the backup strategy, and understand how to recover from it. > 10. ok > > > >Score: 15 out of 20. (Less if you're a stricter grader) > 14 of 20. Good thing this was only the practice test. ;-) Doug. Doug Werth Beechglen Development Inc. [log in to unmask] Cincinnati, Ohio The opinions expressed do not necessarily represent the views or opinions of Beechglen Development. They might, but not necessarily. They represent solely the opinions of the author.