MEMO XMASGIFT (was Missing the nonames option on SFS commands)
I knew I would enjoy to quote Sir Kris: There's a package on the VM Download Pages I did it a few weeks ago and forgot all about. But it is there now. Enjoy, Rob http://www.vm.ibm.com/download/packages/descript.cgi?NONAMES SFS commands feature a lookup from the user's NAMES file that can not be disabled by an option on the command. When SFS commands are issued by a program, such a lookup is normally unwanted. The NONAMES program runs a CMS command with the NAMEFIND nickname resolution disarmed, allowing the careful programmer to write robust code (like the address command in REXX to avoid unintended execution of a REXX program instead of the command). In addition to the assembler source, a complete MODULE is provided for those who don't have the High Level Assembler to build it.
Missing the nonames option on SFS commands
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)
Re: Missing the nonames option on SFS commands
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)
BRR14
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
Re: Missing the nonames option on SFS commands
On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens [EMAIL PROTECTED] wrote: REGEQU USING *,R15 L R15,=A(32) BRR14 Just to help folks advance their assembler programming, this program would these days consist of REGEQU LHI R15,32 BR R14 In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit second operand to 32 bits. Note also the lack of the USING. I know it's off-topic, but it IS Friday! :-) Alan Altmark z/VM Development IBM Endicott
Re: Missing the nonames option on SFS commands
On Fri, Aug 1, 2008 at 4:14 PM, Alan Altmark [EMAIL PROTECTED] wrote: In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit second operand to 32 bits. Note also the lack of the USING. And the lack of an END statement... ;-) So if the suggestion is to mess with the NAMEFIND, then I think I would rather make the assembler program a bit larger and have it process the argument string as a CMS command. 'NONAMES GRANT AUTH' path 'TO' user '( READ NEWREAD' without risking to pick up a nickname. Considering that SFS has options at the wrong place of the command anyway, this is probably pretty good. Rob
Re: Missing the nonames option on SFS commands
That would be fine as a circumvention if you were the only one affected and were in a hurry, but it does not fix the problem. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Kris Buelens Sent: Friday, August 01, 2008 6:45 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands 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
Re: Missing the nonames option on SFS commands
I would have thought that LA R15,32 would have been a better instruction to use than L R15, =A(32). I know that in olden days it burned less carbon. I don't know what the comparison with the LHI would be, but imagine that the two would be pretty close since both actually load the operands when the instruction is fetched, with no memory access needed. I was asked once to write a small program on OS/MFT that would burn cycles. I named it IEFBR15. It was even shorter and did the job. For such a trivial program, I didn't bother with the REGEQU. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 01, 2008 7:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens [EMAIL PROTECTED] wrote: REGEQU USING *,R15 L R15,=A(32) BRR14 Just to help folks advance their assembler programming, this program would these days consist of REGEQU LHI R15,32 BR R14 In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit second operand to 32 bits. Note also the lack of the USING. I know it's off-topic, but it IS Friday! :-) Alan Altmark z/VM Development IBM Endicott
Re: Missing the nonames option on SFS commands
On Friday, 08/01/2008 at 11:43 EDT, Schuh, Richard [EMAIL PROTECTED] wrote: I would have thought that LA R15,32 would have been a better instruction to use than L R15, =A(32). I know that in olden days it burned less carbon. I don't know what the comparison with the LHI would be, but imagine that the two would be pretty close since both actually load the operands when the instruction is fetched, with no memory access needed. Using LOAD ADDRESS requires that you learn all the little rules - The operand has to be 0-4095 (it's a displacement) - The maximum value of the register isn't what you think it is - That maximum value is different in AMODE 24 than it is in AMODE 31 - There's no overflow protection with LA R1,10(,R1) since it isn't an arithmetic operation - Don't forget the comma in (,R1) If you could live with it, no problem, but it wasn't for the uninitiated. That's the nice thing about LHI, it was designed to load a number into a register, not an address. Now if you want to increment a register by 10: AHI R1,10 Just hoping folks learned something new today. I'll be the first to admit that these new (NOT!) instructions don't come naturally to my fingertips. Alan Altmark z/VM Development IBM Endicott
Re: Missing the nonames option on SFS commands
You didn't mention the rule about using 0 (or R0) as a base register value, either explicitly or by default in your list of rules for LA ;-) That was the form I used. Only the increment value is loaded in that case, so you are restricted to loading a value of 0-4095. When I was writing a lot of assembler programs there weren't as many rules, i.e. no 64-bit considerations, and they were second nature to me. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 01, 2008 9:06 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands Using LOAD ADDRESS requires that you learn all the little rules - The operand has to be 0-4095 (it's a displacement) - The maximum value of the register isn't what you think it is - That maximum value is different in AMODE 24 than it is in AMODE 31 - There's no overflow protection with LA R1,10(,R1) since it isn't an arithmetic operation - Don't forget the comma in (,R1) If you could live with it, no problem, but it wasn't for the uninitiated. That's the nice thing about LHI, it was designed to load a number into a register, not an address. Now if you want to increment a register by 10: AHI R1,10 Just hoping folks learned something new today. I'll be the first to admit that these new (NOT!) instructions don't come naturally to my fingertips. Alan Altmark z/VM Development IBM Endicott
Re: Missing the nonames option on SFS commands
Where did you learn about the LHI instruction. I that a Load Halfword immediate? I looked at the hlasm books and they deal mostly with macros. I also looked at principle of operations manuals, but seem to have all the old assembler instructions and not any new ones. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 01, 2008 9:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens [EMAIL PROTECTED] wrote: REGEQU USING *,R15 L R15,=A(32) BRR14 Just to help folks advance their assembler programming, this program would these days consist of REGEQU LHI R15,32 BR R14 In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit second operand to 32 bits. Note also the lack of the USING. I know it's off-topic, but it IS Friday! :-) Alan Altmark z/VM Development IBM Endicott == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
Re: Missing the nonames option on SFS commands
Look at the Load halfword. Both LH and LHI are described there in the ESA POP. Regards, Richard Schuh -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ward, Mike S Sent: Friday, August 01, 2008 10:47 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands Where did you learn about the LHI instruction. I that a Load Halfword immediate? I looked at the hlasm books and they deal mostly with macros. I also looked at principle of operations manuals, but seem to have all the old assembler instructions and not any new ones. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark Sent: Friday, August 01, 2008 9:15 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Missing the nonames option on SFS commands On Friday, 08/01/2008 at 09:44 EDT, Kris Buelens [EMAIL PROTECTED] wrote: REGEQU USING *,R15 L R15,=A(32) BRR14 Just to help folks advance their assembler programming, this program would these days consist of REGEQU LHI R15,32 BR R14 In S/390 architecture, Load Halfword Immediate sign-extends the 16-bit second operand to 32 bits. Note also the lack of the USING. I know it's off-topic, but it IS Friday! :-) Alan Altmark z/VM Development IBM Endicott == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
