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: Trapping output right after LOGON
We've seen these additional differences between SECUSER and OBSERVER processing - Secondary user sees message HCP150A when the primary is disconnected and VM or CP read is issued, observer does not. It doesn't appear that an OBSERVER, even with class C SEND, can satisfy a VM read issued by a disconnected user. On our system, the SEND is honored, but everything is processed by CP on the target user, whereas with SECUSER, the input is passed to the guest unless sent with SEND CP. I know that's poorly worded. Example: USERA has USERB as SECUSER, is disconnected, RUN ON, and issues a VM READ. USERB (with or without class C) does SEND USERA Q DISK and sees the normal CMS Q DISK output. USERA has USERB as OBSERVER, is disconnected, RUN ON, and issues a VM READ. USERB (who has class C) does SEND USERA Q DISK and sees HCPCQV003E Invalid Option - DISK. Steve On Tue, 2 Mar 2010, Alan Altmark wrote: Off the top of my head: Secondary user - Can use CP SEND to the primary - Only sees console output of primary when primary is disconnected - Class G secondary can SEND only when primary is disconnected - Class C secondary can SEND at any time - Traffic to primary's *MSG connection is stopped while secondary is logged on Observer - Cannot SEND to the observed virtual machine (observee) - Sees all console traffic without regard to connect/disconnect status of the observee - Does not interfere with observee's *MSG traffic And as you note, the programming characteristics via *MSG are different for the observer and the secondary user. -- Steve Marak -- sama...@gizmoworks.com
Re: VM lockup due to storage typo
I agree with that (the guest cannot be allowed to harm CP) but has that actually been formally - or even informally - accepted by the Powers That Be? I ask because I still remember, as though it were yesterday, opening a security/integrity APAR against VM back in the mid-1980's because any class G user could knock CP down by defining a shared and a nonshared device on the same virtual control unit, and being told that that was NOT a security or integrity issue, and that no fix would be forthcoming. But at least I'm not bitter about it. Steve On Tue, 15 Sep 2009, Schuh, Richard wrote: One of Alan's first precepts of information security and integrity is that the guest cannot be allowed to harm the CP. This clearly violates that. Regards, Richard Schuh -- Steve Marak -- sama...@gizmoworks.com
OT: trivia question (was PIPE SPEC TOD)
On Mon, 3 Aug 2009, Rob van der Heij wrote: PS An answer to my trivia question is 2009-03-28 11:28:37.334892 I shouldn't fry any brain cells on this while at work, but I'll call it a short break from reviewing spreadsheets ... Is there more than one answer, at least in EBCDIC? My intuition may, as usual, be wrong, but with only one hex character (even including lower case) whose hex representation starts with itself it seemed forcing. (There's at least one more if you don't restrict to EBCDIC - 1928-08-17 23:58:45.474099 - but on a z machine I do.) Steve -- Steve Marak -- sama...@gizmoworks.com
Re: Replicating z/VM documentation
On Mon, 13 Jul 2009, Scott Rohling wrote: - The PDF files are named with the manual number, rather than a human readable title. I usually end up renaming them when I download (and am often inconsistent). - I'm never sure I have the 'latest and greatest' - The process is entirely manual So I'm wondering what other people do to keep local copies.. I do the same thing you do, and it's a huge pain. Some of my co-workers use the Library Reader on their Windows laptops, but I find that even worse than having to rename all the PDFs. I'm sure that says something about the Library Reader, or me, or both, but that's just what I want: the PDF format, with a usable name, available offline on my laptop. Doesn't seem like it should be as much effort as it is. Steve -- Steve Marak -- sama...@gizmoworks.com
Re: Impromptu XEDIT Survey
On Wed, 20 Feb 2008, Huegel, Thomas wrote: Where does the prefix field belong? On the left? or On the right? Isn't there enough hatred and intolerance in the world already without bringing this up? Isn't XEDIT big and powerful enough to include all of us with all of our various needs? Can't we all just get along? (The left. The LEFT. THE LEFT ... cough ... sorry, all better now.) Steve -- Steve Marak -- [EMAIL PROTECTED]
Re: Ops privs
On Fri, 24 Aug 2007, Alan Altmark wrote: There are some who believe that the authority to LOGON BY to a user should implicitly allow: - XAUTOLOG - SET SECUSER or OBSERVER - SEND (a la class C) - FORCE - SIGNAL SHUTDOWN Thoughts? And maybe FOR, in 5.3. At my current job, we create LOGONBY profiles out of laziness - small group, development shop, most of us log onto multiple ids every day, so no one has to remember (or change) any password but their own. In this environment, there would be no issue with bundling all of that with LOGONBY. At my last job (security weasel for a RBC), surrogate facilities like LOGONBY were mostly used to solve the problem of how to provide accountable access by multiple people to a shared security principle (userid) for administration or maintenance, with convenience way down the priority list. Frequently, there was an implied serialization of the resource, too. There, we wouldn't have wanted to see something like this because it would have made collisions less likely to be detected before something bad happened, and auditing more complex if it did. The logic of but they could do it anyway if they can log onto the user is hard to argue against. The question is whether there is really any difference that matters, other than maybe the serialization thing, between doing something while logged on as a user and doing more or less the same thing as or to that user while loggged on as a different user. Steve -- Steve Marak -- [EMAIL PROTECTED]
