IEANTRTR, exactly like IEANTRT, has authorization-related "limitations" and authorization-related opportunities. If you look closely, the non-authorized IEANTRT shows that the level parameter has 4 choices. The authorized IEANTRT shows that the level parameter has 7 choices. The same is true for IEANTRTR (or would be if both authorized and non-authorized were documented). But neither is really true. It's just that an unauthorized IEANTRT would (in practice, not theory) not use one of the other 3 choices. Those other three options are all "match only if the name/token was created by a supervisor state or system key creator". Could an unauthorized user go down that route? I suppose. They wouldn't be retrieving information that they set.
The authorized IEANTRT allows SRB-mode and allows locks to be held; the unauthorized does not allow SRB-mode. It incorrectly talks about locks that could be held. It should not. But realize that these are not enforced requirements/restrictions. Unauthorized code cannot be in SRB mode and cannot have system locks; authorized code is expected to follow the rules, whether they are enforced or not. Unlike IEANTRT for reasons that I do not recall (but should because I wrote it and it was only 10 years ago) but for which I'd hope you'd consider submitting "negative feedback" (such as via thumbs down within "was this topic helpful?" after which you get to enter your comment), IEANTRTR is documented only in the authorized assembler services reference. It should be documented in both, appropriately. It's hard to submit feedback for "this book doesn't have this chapter", with the current scheme available, so I'd suggest doing it from the authorized book's chapter. Peter Relsonz/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
