Re: help with DMSCGR DMSCSR esoterica
Uppercase or not: I guess that these CSL routines also work with EXEC2, and there One is another variable than ONE. Substitution or not: One often sees execs containing code like this: info.street='xxx' info.name='' and the coder of the exec didn't define 'street', nor 'name' as variables. So INFO.STREET and INFO.NAME are the variables here. When accessing them from CSL (or PIPE), one needs direct access, no substitution. In PIPE speak this is VAR INFO.STREET DIRECT This technique makes it possible to code for example ToEat='STREET NAME' do while toEat'' parse var toEat t toEat say left(t,10) '=' info.t end But, this is not always what exec programmers want. So the reason for substitution or not. Notes: - I consider the above (coding info.name='xxx' and supposing 'name' is a constant) as bad practice. One can get the same simple code by using info.0name='xxx' as 0name can never be a variable. - With CMS Pipelines, VAR xxx.yyy DIRECT has better performance then SYMBOLIC. One must know what one wants to achieve. Given that t='NAME' - 'PIPE VAR INFO.T SYMBOLIC ...' - 'PIPE VAR INFO.'t 'DIRECT ...' both produce exactly the same result, but the second example is considerably faster. 2011/2/19 Steve Marak sama...@gizmoworks.com I have one of those is there ever any situation when ... would not be a good default questions, and I need the help of VM-savvy minds capable of perverse and twisted logic. I can't imagine a better place to find them than this list. (Yes, that was intended as a compliment.) As you all know, DMSCGR and DMSCSR are CSL routines which retrieve and set, respectively, the values of REXX variables. The default behavior is that the variable name passed is searched for directly in REXX's list of variables, exactly as passed. Optionally, the caller can ask that the name be both translated to upper case and that REXX perform variable name substitution on it before looking for it. (Since REXX doesn't care about case in variable names and some quick experiments confirm that passing mixed- or lower-case names without this option isn't productive [except of non-zero return codes], one could reasonably ask why the name is not always translated to upper-case. I think it's a very valid question, but more or less irrelevant to my problem.) In situations where everyone involved knows which behavior is desired, the choice between substitution or not isn't an issue. But if there's a situation where an end user will create REXX execs which pass a variable name to a program which will then retrieve or set it via these routines, it's more problematic ... or maybe not, if one or the other behavior is obviously preferable. Can anyone think of a situation in which you would *not* want substitution performed on the variable name passed? Typically, the whole reason you use compound REXX variables is to get that. But the writers of these routines didn't make that the default, so I want to know if there's some obvious situation we're missing where you wouldn't want it. (We've come up with one exotic case involving REXXVARS, but it's not one that seems likely to occur. In fact, it seems like the writer of the exec would almost have to be out to get you to code it that way.) Thanks, Steve -- Steve Marak -- sama...@gizmoworks.com -- Kris Buelens, IBM Belgium, VM customer support
help with DMSCGR DMSCSR esoterica
I have one of those is there ever any situation when ... would not be a good default questions, and I need the help of VM-savvy minds capable of perverse and twisted logic. I can't imagine a better place to find them than this list. (Yes, that was intended as a compliment.) As you all know, DMSCGR and DMSCSR are CSL routines which retrieve and set, respectively, the values of REXX variables. The default behavior is that the variable name passed is searched for directly in REXX's list of variables, exactly as passed. Optionally, the caller can ask that the name be both translated to upper case and that REXX perform variable name substitution on it before looking for it. (Since REXX doesn't care about case in variable names and some quick experiments confirm that passing mixed- or lower-case names without this option isn't productive [except of non-zero return codes], one could reasonably ask why the name is not always translated to upper-case. I think it's a very valid question, but more or less irrelevant to my problem.) In situations where everyone involved knows which behavior is desired, the choice between substitution or not isn't an issue. But if there's a situation where an end user will create REXX execs which pass a variable name to a program which will then retrieve or set it via these routines, it's more problematic ... or maybe not, if one or the other behavior is obviously preferable. Can anyone think of a situation in which you would *not* want substitution performed on the variable name passed? Typically, the whole reason you use compound REXX variables is to get that. But the writers of these routines didn't make that the default, so I want to know if there's some obvious situation we're missing where you wouldn't want it. (We've come up with one exotic case involving REXXVARS, but it's not one that seems likely to occur. In fact, it seems like the writer of the exec would almost have to be out to get you to code it that way.) Thanks, Steve -- Steve Marak -- sama...@gizmoworks.com
Re: help with DMSCGR DMSCSR esoterica
Oops! The last statement should be: say city.who Sorry! blush Les Les Koehler wrote: Rexx vars are always upper-cased *except* for 'content addressable arrays' (stemmed variables). For example: name='Les Koehler' city.name='Tampa' say 'Enter the name of the person and I''ll give you the city' parse pull who say city.name The concept is simple yet very powerful. I used it once to improve the elapsed time of matching a vendors individual transaction accounting records against his end of month accounting records from hours to a couple of minutes. The individual records and the monthly records did *not* have the same layout, but with this technique it was a snap to match them. Les Steve Marak wrote: I have one of those is there ever any situation when ... would not be a good default questions, and I need the help of VM-savvy minds capable of perverse and twisted logic. I can't imagine a better place to find them than this list. (Yes, that was intended as a compliment.) As you all know, DMSCGR and DMSCSR are CSL routines which retrieve and set, respectively, the values of REXX variables. The default behavior is that the variable name passed is searched for directly in REXX's list of variables, exactly as passed. Optionally, the caller can ask that the name be both translated to upper case and that REXX perform variable name substitution on it before looking for it. (Since REXX doesn't care about case in variable names and some quick experiments confirm that passing mixed- or lower-case names without this option isn't productive [except of non-zero return codes], one could reasonably ask why the name is not always translated to upper-case. I think it's a very valid question, but more or less irrelevant to my problem.) In situations where everyone involved knows which behavior is desired, the choice between substitution or not isn't an issue. But if there's a situation where an end user will create REXX execs which pass a variable name to a program which will then retrieve or set it via these routines, it's more problematic ... or maybe not, if one or the other behavior is obviously preferable. Can anyone think of a situation in which you would *not* want substitution performed on the variable name passed? Typically, the whole reason you use compound REXX variables is to get that. But the writers of these routines didn't make that the default, so I want to know if there's some obvious situation we're missing where you wouldn't want it. (We've come up with one exotic case involving REXXVARS, but it's not one that seems likely to occur. In fact, it seems like the writer of the exec would almost have to be out to get you to code it that way.) Thanks, Steve -- Steve Marak -- sama...@gizmoworks.com
