For some commands, there are CSL routines, and most of those don't do
nickname resolution, for others you are right.
I discussed this with Alan quite some years ago. He suggested to
NUCXLOAD a module as NAMEFIND
Here's my -NONICK ASSEMBLE program, part of SFSULIST
* This program tries to solve the problem that many SFS QUERY commands
* always try to perform nickname resolution
* E.G Q LIMITS FOR USER1
* Will fail is USER1 is a nick in "userid NAMES" and this
* nickname has no :localID. tag
* For programs like SFSULIST, nickname resolution should even never
* take place, SFSULIST works from the list of users enrolled in an SFS
* hence each userid it specifies should be take literally, independent
* of what exists in the end-user's userid NAMES file.
*
* As suggested by ALAN ALTMARK, we create a module to NUCXLAOD
* as NAMEFIND and the module exits with rc=32: ie no nick found.
REGEQU
USING *,R15
L R15,=A(32)
BR R14
END
The REXX code then basically uses:
/* For DELETE, QUERY & MODIFY, we avoid Nickname xlation by */
/* NUCXloading a module as NALMFIND that exists with rc=32 */
NoNick=(abbrev('QUERY',cmdW1,1) | abbrev('DELETE',cmdW1,3) |,
abbrev('MODIFY',cmdW1,3) )
if NoNick then do
address command 'NUCEXT NAMEFIND'
if rc=0 then address command 'NUCXDROP NAMEFIND'
address command 'NUCXLOAD NAMEFIND -NICKSFS'
end
address cms cmd
CmdRc=rc
if NoNick then address command 'NUCXDROP NAMEFIND'
2008/8/1 Rob van der Heij <[EMAIL PROTECTED]>:
> I had done some programming to help system administration. Part of
> that obtains a list of users to check in SFS. Which users I get listed
> is basically outside my control, and I want the program to be robust
> enough to handle that.
> Trying to understand the strange results, I realized that one of the
> users just happened to match a nickname in my personal NAMES file, and
> the QUERY (in this case) nicely iterated the command for the list of
> users in that nickname. Not nice when you don't want that.
> I felt pretty stupid that I did not disable the (apparent) default to
> search your NAMES file, but found that there is no such option.
>
> I think this is broken. When you want to write robust code, it should
> not casually pick up a NAMES file that happens to be there. In my case
> it just made the output look strange and it made me lookup the syntax
> for Q LIMITS ALL to avoid iterating over all users. This just smells
> like a Trojan Horse attack around the corner.
>
> VMLINK has a NONAMES option to avoid literals to be taken as
> nicknames. SENDFILE and friends would enjoy that too, but I can code
> AT to force no NAMES resolution.
>
> So what's the right way to make this robust? Do I have to save the
> NAMES file and put an empty one there? Or NUCXLOAD some dummy thing as
> NAMEFIND ?
>
> Rob (friday is my security weasel day)
>
--
Kris Buelens,
IBM Belgium, VM customer support
