Re: WLM : multiple periods not recommended for batch - why?
On May 1, 2012, at 6:39 AM, Andrew Rowley and...@blackhillsoftware.com wrote: I have read a few articles that say that multiple periods are not recommended for batch service classes. Multiple periods seems to be considered a bit old fashioned. I haven't been able to find anything clearly explaining why. I have always felt that they worked well. My best guess is that it is something to do with the behaviour of WLM managed initiators but I'm not sure. Can anyone shed any light, or point me to some Basically it is to do with the fact that WLM works best with a limited number of total service class periods and it is better not to waste them on multi-period classes. That total number seems to vary according to which direction the wind is blowing, but given the sysplex-first nature of the algorithms it makes good sense to keep it small. The second reason is that the algorithms only work well when you have sufficient completions for a statistically valid sample. It is very likely that multi-period classes (other than perhaps TSO) would not have enough and so they might/would not be treated appropriately. The take-away from that is that WLM is a statistical tool and trying to get very fine-grained with it will likely end in tears. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 0C4 pic 4
On Sun, Apr 15, 2012 at 12:29 PM, Micheal Butz michealb...@optonline.netwrote: I am getting S0C4 04 within a wait which leads me to believe that the storage key of the ECB storage key is not the same as the PSW STORAGE KEY 8- 11. Does the following code make sense to resolve this address TESTAUTH FCTN=1 TEST APF AUTORIZATION LTR R15,R5 CHECK R15 BNZ NAPFSYSNDXNOT APF MODESET MODE=SUP,KEY=NZERO TURN ON BIT 15 IN PSW LAR0,REPLY_ECB GET ECB ADDRESS IVSK R1,R0 GET STORAGE KEY MODESET KEYREG=R1,SAVEKEY=OLDKEY SET STORAGE KEY IN PSW WAIT=REPLY_ECB MODESET MODE=PROB,KEY=NZERO back to current TCB key I'm sorry if I seem to be picking on you but there are so many ways that this is wrong. You don't need to be in supervisor state to issue the IVSK instruction, but that's the least of your worries. Overtly changing to key zero just guarantees that the OS is going to vaporize 4 bytes at what ever location you specify - even if it isn't really an ECB at all. In other words, it is another (data) integrity hole. You should never be using an ECB that is in another key than your current PSW key. The system gives you a way to do it, but it assumes you know what you're doing. The only real exception to this is the stop/modify communications ECB for your your address space. The OS has a special case code path that lets you wait on that. There might be other exceptions when you know what you're doing, but this isn't one of them. So to reiterate my earlier advice, you're going in the wrong direction. If you're going to write privileged code that runs entirely within a single APF authorized address space you can do more or less whatever you want. However, if your code might ever get control in a non-APF environment, or you try to share code/data between address spaces, you have a steep hill to climb to avoid compromising integrity. Sorry, them's just the facts. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: System completion code 201
On Wed, Apr 11, 2012 at 1:07 PM, Micheal Butz michealb...@optonline.netwrote: There is a reason I have CSA in KEY 8 Was just wondering If I have to do an explicit modeset to key=8 What you're doing is just stupendously wrong. As a privileged program, you don't NEED to use key 8 storage and it is an integrity exposure to use key 8 CSA. The gymnastics you would have to go through to get what you're doing to appear to work would further increase your exposures. Add to that the fact that an ordinary prob state/key 8 task in another address space cannot do a cross-memory post anyway (sounds like the likely reason for your predicament) and you're just digging yourself a hole. Don't do it. Don't even start doing it. It is a whole lot easier to do it right from the start. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Apr 2, 2012, at 10:46 AM, R.S. r.skoru...@bremultibank.com.pl wrote: The same with unauthorized code - maybe the system is not bulletproof, but we have no documented case of such flaw. Sorry, but you are totally wrong there. Absence of publicized cases does not imply absence of cases. These matters are generally NOT publicized in order to avoid encouraging copycats - particularly in the financial sector. As for evidence; long ago in a previous life, I was *personally* involved in detecting/collecting evidence for prosecution in three separate cases where insiders (one sysprog and two operators) exploited integrity holes. One was proven to be an attempt at theft on a significant scale. One was an attempt at destructive behavior by a soon to be ex employee and the third was just some fool poking around to see what he could do - or that was his story anyway. In all three cases the employees were terminated and one was prosecuted. This is THE reason why I make so much fuss about integrity issues. The community mythology that z/OS and it's ancestors are immune to these things is just a myth. I have seen it happen up close and personal and I don't believe there is anything special about my experience. If I encountered these things in the real world, I am fairly certain it must have been happening in a lot more places around the world. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Is there a way to cause SRB to TCB percolation if an XCF exit fails?
On Mon, Apr 2, 2012 at 4:32 PM, Binyamin Dissen bdis...@dissensoftware.comwrote: The various exits run in SRB mode. As a pants and suspenders guy, I would like to have the task receive a notification from the system if the SRB and its FRR fail. SRB to TCB percolation is a feature that the issuer of the SCHEDULE (or equivalent) gets by specifying the purge TCB address. If you don't do the scheduling (as in this case) I don't believe there's any (officially supported) way to get what you want. It shouldn't be any big problem to schedule an IRB out of the SRB's recovery code to do whatever you want though. (I'm leaving out a lot of details that will be obvious to you) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
While z/OS is probably immune to executables being introduced from outside, how vulnerable is This really isn't a safe assumption, so all of the subsequent questions are kind of irrelevant. Yes, it is possible to configure a z/OS system so that it is extremely difficult to break into, but when you present a harder target, the universe just coughs up a better class of hacker in return. Sort of a yin and yang thing I guess. Anyway, I recommend taking the time to read this wiki post on Stuxnet and then play a few what if? scenarios in your head. Very sobering. Enjoy http://en.wikipedia.org/wiki/Stuxnet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Malicious Software Protection
On Mar 28, 2012, at 4:13 PM, R.S. r.skoru...@bremultibank.com.pl wrote: The problem is we don't believe. :-) W dniu 2012-03-28 22:45, Ray Overby pisze: Yes, I believe I have a way to attack a mainframe system where I don't have access. Then would you believe me? In the days before ubiquitous networking you would have been safe not do believe. Today I think you would be foolish not to believe. The proof is a thought experiment that I could walk you through, but I won't because I don't think it is wise to shout out the location of my neighbor's front door keys, even if he is foolish enough to leave them under the mat. It is the reason why I keep harping on about integrity violations. Suffice to say that more sophisticated malware attacks in the real world like Stuxnet have proven conclusively that patience and a broad based approach can pay dividends even in some of the most supposedly secure sites in the world. And if through that slow patient attack, you manage to get some code running on a z/OS system, THEN... even if that code is utterly non-privileged, it is quite easy to find and exploit integrity violations locally. And the world is your oyster. So it really isn't like on TV where the brainiac agents are always cracking firewall encryption in five minutes. But with the right kind of approach, they don't need to. And if they can do some human insider trading, then it is even easier. Bottom line: if you think your systems are really secure, you're probably nuts. Far more likely it's just that nobody has (yet) paid attention. Sorry. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Sun, Mar 11, 2012 at 8:07 AM, John Gilmore johnwgilmore0...@gmail.comwrote: Since this sort of thing is expected of me, I will note that we find ourselves between Scylla and Charybdis here. Chris Craddock's formulation was open to the exception that Peter Relson took: there is fetch-protected storage the contents of which its owner is entirely free to make available to others. Peter's exception is logically impeccable. It did, however, seem to me to be a very special one; and I observed that it was. I still prefer the ROT that the contents of protected storage should not be made available to the unauthorized (in any but very special circumstances, when they are known procedurally to be innocuous.). To repeat myself now, Peter is nonetheless correct in the abstract. There is a long intellectual tradition which has it that the production of just one black swan is an unanswerable refutation of the proposition that all swans are white. I can't quibble with Peter's exception. I was evidently not sufficiently clear. I had assumed it was self-evident to everyone that a privileged program is free to do what ever it wants with the contents of its own storage - including both disclosing and/or modifying that data - regardless of fetch protection. I was merely pointing out to a prior poster that a privileged program is required to honor key controlled protection in general and meeting that requirement is more rigorous than just not mindlessly storing in areas provided by a caller (regardless of the caller's key). -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Mar 8, 2012, at 1:15 PM, Ray Overby ray.ove...@kr-inc.com wrote: Rob - How about: If your authorized program while executing in PSW Key 0-7 stores into an address provided by an unauthorized caller (as long as the store operation uses the execution PSW KEY) then this is a violation of the IBM statement of integrity. Not necessarily. The integrity statement would only be violated if the privileged program allowed the non-privileged program to circumvent key controlled access. To prevent this, the privileged program must use the non-privileged program's PSW key when passing any results back in areas provider by the caller (e.g. By using MVCDK and the caller's key) - however, the privileged program must also ensure that it does not inadvertently disclose the contents of fetch protected storage, regardless of how it moves the results back to the caller. In the latter case a black hat might cleverly cause a malformed privileged program to copy (say) contents of key zero fetch protected storage into plain old user key storage where the black hat could inspect it to his heart's content. So bottom line: using the caller's key to return results is a necessary, but not sufficient condition to maintain integrity. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Interfacing with the MainFrame
So basically, you're planning to create a product and you want us to describe how to do it? Sent from my iPad On Mar 7, 2012, at 3:51 PM, Ed Mackmahon dropip...@gmail.com wrote: Many thanks for your answers. Let me provide some more information I intend that the interface will logon to the mainframe and issue some operator commands, read some members etc... gather information and send it to the open systems server for further analysis. The user which will be used for logon to the mainframe will have specific RACF/TSS/CA1 display only authorities and the server is on the organization intranet not an out side server. Having that, I am still looking for the preferred way for interfacing in a way that most organization will have no problem to authorize and using most common services available on most organizations (don't want to impose implementing other services as a preq) - that was the reason I was thinking on FTP and Rexx server... Any other comments / Ideas ? Thanks Ed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: ACCESS=PUBLIC on ALESERV macro
On Tue, Feb 21, 2012 at 2:15 PM, Micheal Butz michealb...@optonline.netwrote: If I adding the STOKEN of another address to either my DU-AL PASN-AL can I specify PUBLIC on the ALESERV macro and bypass the authorization) Typically when I get the alet of another address I do a AXSET to give myself authorization to go there Would adding PUBLIC entry for the ALET of another address space via ALESERV bypass the need to do a AXSET No and no. Just don't do it. Adding addressability to another address space this way is not really supported outside of BCP components - even though the macro documentation might seem to suggest otherwise. Consider it a wild hare that escaped. The supported approaches are documented in the extended addressability guide. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Do what to get C strftime %z to work?
On Tue, Feb 21, 2012 at 7:01 PM, Charles Mills charl...@mcn.org wrote: Also remember when perusing the LE publications that the inventors of LE in their wisdom thought it would be too clear to the uninitiated to call the languages dependent on Language Environment languages, choosing instead to further overload the word member. And let's not get started on enclaves and all that... it is made easy, for one C function to call another C function What does that have to do with LE? No other platform that I know of has LE, but on every platform cannot a C function trivially call another C function? Otherwise wouldn't every C program have to consist simply of one humongous main()? All high level languages on all platforms have a runtime that provides the magic behind the curtain. Ours happens to be called LE. However, most others are vastly more transparent and obvious than LE - the main point of which was *NOT* so that C functions could call other C functions, but so that multiple varieties of PL/1 and COBOL programs could call each other. Yes folks, that baby really is ugly. LE is old and crufty for lots of reasons and the doc you need to make sense of it is smeared across multiple publications and as myth and legends in the tribal mind. To quote a former president of ours; I feel your pain. Please count this as the 2012 edition of my now long-standing semi-annual rant about LE. I will now retire from the discussion before mortally offending my IBM friends. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Difference between DREF storage and Page fixed storage
On Tue, Feb 21, 2012 at 3:45 PM, Micheal Butz michealb...@optonline.netwrote: Would any know the difference between (disabled reference storage) DREF e.g. subpool 215 and Page fixed storage e.g. subpool 223 From what I understand DREF means the program is running disable for interrupts and thus no pagIing should occur so the doc say use DREF storage While fixed storage means storage is fixed and the same thing applies no paging should occur the differences are subtle. With FIXED storage allocations, each (virtual) page is allocated to a (real) frame at the time of allocation and will remain so-paired until they are freed. If the storage is actually used then that's a good deal, however if it is one of those cases where let's say maybe something happens and maybe it doesn't.' In that case, the fixed (real) storage would be wasted in the case where it was never referenced. That kind of thing happens often enough in real life to have warranted the creation of DREF. So DREF and FIXED are essentially the same thing (technically a form of xSQA) except for a few important differences. (1) None of the DREF pages is backed by a real frame until the page is referenced. Upon reference the page fault interrupt handler jumps in and tries to obtain a free frame from the AFQ. If it works the instruction is redriven and everyone does the happy dance. However at that point there is always the opportunity to be out of frames so there's even a special abend code to tell you that it happened. And it's transient, so you could try again and find it worked just fine. Overall this strategy means a decent probability of tying up less real storage than you would have done otherwise by using fixed storage. Win! (2) All DREF storage is above the 16MiB line just to coerce a little more modern sanity on the punters who should never be using below the line storage anyway. (3) and this is where it gets tricky... with fixed storage you can could count on the address translation staying fixed forever. However, with DREF it is only true most of the time. It is always true for DREF common storage (technically that is ESQA) however (and this bit is perhaps not widely know) it is NOT necessarily true for private area DREF (technically known as ELSQA). When an address space is logically swapped the system knows nobody is going to be touching the LSQA frames while the address space it toes up, so the system may play a little fast and loose. A backed LSQA page (DREF or not) will always come back in with a fixed frame backing it, but it might not be the one it logically went out with. Still following? Good. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Authorized functions
On Thu, Feb 16, 2012 at 3:33 PM, Scott Ford scott_j_f...@yahoo.com wrote: Tony, I dont want to knock IBM but for us developers this is UGLY ... Maybe the problem is they never intended for it to be called that way ... Yes, exactly right on both counts. Don't forget that TSO is older than dirt and all subsequent efforts to graft on functionality are limited by its original design assumptions. Modern it ain't. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Authorized functions
On Wed, Feb 15, 2012 at 2:55 PM, McKown, John john.mck...@healthmarkets.com wrote: If you really want do this this: run an APF authorized TSO command from a COBOL program, even one which is linked AC=1. Well, you'll need to cheat horribly. One way to cheat is to run your COBOL program under TSO. Do I even need to point out what a bad idea this is? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Doing Some Restructuring?
On Mon, Feb 13, 2012 at 7:00 AM, Veilleux, Jon L veilleu...@aetna.comwrote: I think that this paragraph is interesting: We were previously using configuration management version control, which required a lengthy code check-in process, said Clark Dudek, software developer, IBM Systems and Technology Group. Rational Team Concert has encouraged greater code collaboration and better work item tracking within my team. I guess IBM doesn't think they need version control anymore. Might that be why we are seeing more problems lately? It isn't that they are no longer using configuration management - just different tools with a different world view. In the non-MF world the process involves developers creating their own individual branch from a base in a code repository, then working independently on the branches (coding/unit testing etc.) Then, somewhere down the road, they merge their changes into a new base. This offers greater parallelism than in other (let's say traditional) source management approaches where individual elements are locked while changes are made. It looks terrifying to mainframe folks, but I'm here to tell you it works and there are tools to make it relatively easy. It isn't completely automated - a carbon unit still has to resolve any differences that don't fit, but in most respects there is more freedom and less effort overall. However, as you might imagine, this approach requires great discipline and skill when bringing the pieces back together and that brings us back to the original skills issue that Ed raised. You don't want the B team doing this. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Archaic allocation in JCL (Was: Physical record size query)
On Mon, Feb 13, 2012 at 8:56 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 13 Feb 2012 07:21:11 -0600, McKown, John wrote: Or, as the programmers at our shop would do: SPACE=EAT-EVERYTHING-IN-SIGHT-AND-CAUSE-OTHER-JOBS-TO-ABEND-BECAUSE-MY-STUFF-IS-IMPORTANT-AND-YOUR-STUFF-ISNT. In many other systems, such as Winblows, everybody gets their own personal space. And if it is used up, it doesn't impact others. z/OS shares DASD space. ... The z/OS cultural norm for HFS and zFS is to give each user a dedicated filesystem for HOME. This is similar to the behavior of personal instances of those other systems. I think it is fair to say that JCL and space management are areas where z/OS truly is archaic. The other world manages to get by just fine without having to figure out how much resource to give. There's no reason z/OS couldn't do the same other than slavish adherence to legacy. IMHO it is about time the system itself took care answering its own incessant how big?, how many?, how often? questions. It's 2012 ferpetesakes. I'm all in favor of making sure that existing applications continue to work. I am far less impressed with continuing to impose 1960s thinking on new ones. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: IBM Doing Some Restructuring?
On Feb 12, 2012, at 1:22 AM, Edward Jaffe edja...@phoenixsoftware.com wrote: On 2/11/2012 8:31 AM, Dave Day wrote: The idea of hiring temporary workers, the 'liquid' people referred to in the article, seems to me to be at odds with long term, successful growth. It's hard for me to understand how any serious development projects can be done by temps. Software development is not a math problem. You can't just throw bodies at it to get things done more quickly. You need a smallish group of highly skilled people--the kind that usually have permanent gigs--and time for them to learn the infrastructure and architecture before they can be truly useful. Also, as with any complex subject, the learning curves can be fairly steep. OTOH, perhaps the projects they're envisioning don't involve actual development. Maybe they involve customization of OTS packages. No Ed, customization of OTS packages (generally a bad idea btw) has exactly the same talent requirements you're referring to; a smallish group of highly skilled people. The specific skills may be slightly different, but I know you would not have any trouble relating to them. The (evidently popular) idea that you can pick a random group of (cheap) gunslingers and solve big system or application development problems is as bankrupt today as it ever was. It only ever works on a spreadsheet. Lord spare us from MBAs. CC Sent from my iPad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Lots of *MASTER* CPU during a big sort
On Jan 25, 2012, at 9:08 AM, David Andrews d...@lists.duda.com wrote: But what also caught my eye was unusually large CPU consumption by the *MASTER* address space: 60-75% continuously while his sort was executing. He cancelled it, and *MASTER* went back to its usual docile self. What is a large DFSort with 2M+ real storage doing to consume that much time in *MASTER*? Is this a characteristic I/O interrupt processing in an otherwise lightly loaded system. No biggie. Sent from my iPad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: New code? use ENQ/DEQ or ISGENQ?
On Wed, Jan 18, 2012 at 11:25 AM, Leonard D Woren ibm-ma...@ldworen.netwrote: snip Which reminds me. ENQ/DEQ LINKAGE=SVC cannot be issued by AR mode callers. Guess how I discovered that... That has always been true for all SVCs unless specifically documented otherwise. The exception that springs to mind is SVC 13 and that really doesn't count as an SVC :-) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: 21st Century Migrates Mainframe with Clerity
On Jan 5, 2012, at 5:48 PM, Graham Harris harris...@gmail.com wrote: Intel Core i7 at 177,730 MIPs/sec http://en.wikipedia.org/wiki/Instructions_per_second or almost 180BIPs/sec ... which makes i7 equivalent of more than three z196?? Interesting to read the cited reference against the claimed 180BIPS/sec (/sec ??!!) Synthetic Benchmarks Synthetic benchmarks.are wellsynthetic and do not get your work done for you. These don't necessarily mean anything when it comes to desktop performance in real life, but certainly there is value to be gleaned from these by enthusiasts. These are also the easiest benchmarks to run when it comes to seeing if your system at home is measuring True enough. Nevertheless it would be unwise to conclude that said processors are not actually capable of delivering work in the Real World(tm). There's no telling what the absolute performance will be in any given situation, but those i7 CPUs have more than enough horsepower for most things you would ever want to do - even in a server configuration. We aren't talking about old fashioned PC weenies here. These things rock. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Semiprivileged instructions, part 1 (3)
Steve, Peter is (of course) right. You're struggling with cases where most people generally miss the distinction between the hardware architecture and the software architecture implemented by any given control program. The hardware knows nothing at all about what you would think of as authorization from a z/OS point of view, or any of the internal mechanisms that z/OS uses to make those semi-privileged instructions do something useful. The hardware architecture has three states that control whether or not an instruction can be executed; non-privileged, semi-privileged and privileged. You can assume for all practical purposes that as far as the hardware is concerned, supervisor state and privileged mean the same thing and that you can execute any machine instruction you want any time you want. Whether or not it does something sensible or desirable is irrelevant at this point. In the problem state you can execute any non-privileged machine instruction any time you want *AND* any semi-privileged instruction the control program (in this case z/OS) has enabled. As Peter mentioned earlier, z/OS always allows problem state programs to issue semi-privileged instructions. Additional *SOFTWARE* architectural conditions may have to be satisfied in order for the instruction to complete, or to do something useful. Some of those are done all the time (for all units of work) and others need to go through some software mediation first. For example; From the software point of view the linkage stack is just always there. Under the covers z/OS is manipulating the stack to balance its storage resource utilization, so if you were to look at the stack in a dump it would not necessarily look the way you might expect from reading PoPs. For the most part, the instructions just appear to work and they are useful, or not, depending on what you're trying to accomplish. Other semiprivileged instructions can have more of an in your face nature. For example, SPKA can be issued in problem state any time, but will give a privileged operation exception if there isn't a 1 bit in the PKM for the target key. The PKM (a hardware construct) is setup by z/OS when the unit of work is dispatched but the mechanisms z/OS uses to decide which keys are available at any given time are part of the software architecture. In other cases a given hardware feature might be made available to software in a different way than implied in PoPs, or perhaps not made available to software at all. The often cited example is that the TRAP instructions are not supported by z/OS at all. So in theory, you could write a supervisor state program that would set up the required linkage mechanisms for the TRAP instructions to work, but various z/OS internal components would likely be surprised and disappointed. And that's never a good thing. On Fri, Dec 30, 2011 at 8:01 AM, Steve Comstock st...@trainersfriend.comwrote: On 12/30/2011 5:52 AM, Peter Relson wrote: I have noted a couple of omissions in the PoPs that I will submit a Readers Comment for snip The wording in the PoOp tends to be extremely precise (not 100% correct, but pretty darn close). I caution against assuming that terms mean what they do not say they mean. I understand, and I believe you. But, there are times (perhaps when separate chapters are written or updated by different people) when the consistency is not what I, personally, would like. Consider the Preface description of Chapter 10 says that chapter: contains detailed descriptions of all of the semiprivileged and privileged instructions except for the I/O instructions. that's just a long winded way of saying the I/O instructions aren't described here. Chapter 3 mentions a semiprivileged program - what is that? (Chapter 5 also uses this term without defining it) A literal interpretation of a semiprivileged program is one in which the control program has established the conditions necessary for the program to issue those instructions. Chapter 4 says Another group of instructions, called semiprivileged instructions, are executed by a CPU in the problem state only if specific authority tests are met; otherwise, a privileged-operation exception or a special-operation exception is recognized. Yep. Should all be clear now right? With one or two exceptions, it isn't terribly interesting (at least in z/OS) to be drawing distinctions between non-privileged and semi-privileged. The only meaningful distinction is that you need some assistance from the control program in order to be able to use (some of) the semi-privileged instructions. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message:
Re: Testing g RTM routine
On Oct 27, 2011, at 8:19 PM, Micheal Butz michealb...@optonline.net wrote: Would anyone know how to test the RTM routine of a SRB when I issue a schedule even though SRB activity is asynchronous it takes off automatically Michael, you're really playing with fire. Before you try any of that, please read the topics on SRB's and providing recovery in the authorized assembly language guide. Then read them again about a dozen times. If you don't have a very thorough understanding of system internals you're never going to get this stuff working safely. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
On Tue, Oct 18, 2011 at 10:20 AM, Micheal Butz michealb...@optonline.netwrote: Is all that's required for setting a recovery routine for the SRB is setting a address in SRBFRRA ? http://bama.ua.edu/archives/ibm-main.html At the risk of sending you off on another tangent, yes. But, what would you *DO* with an FRR if you managed to set one? They serve two purposes; 1. Diagnosis: Collect error diagnostic data for subsequent analysis 2. Recovery: Choose to percolate or set up the registers for a retry both of those things are complex and delicate (think of walking on eggshells). If you don't have a very detailed understanding of the recovery environment, you're likely to do more harm than good. If you're going to play with fire, it is best to let your SRB crash and burn, rather than risk doing more harm. Oh and BTW I assume you are aware that (for normal human beings) you CANNOT debug any SRB or FRR under TSO right? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRB routine
ok, ok, I admit it! I know. (sheesh, you guys) Sent from my iPad On Oct 16, 2011, at 11:37 PM, Shane ibm-m...@tpg.com.au wrote: On Sun, 16 Oct 2011 13:07:26 -0700Edward Jaffe wrote: Would anyone know if the SRB routine SRBEPA has to reside in common No. Lol - c'mon Ed, *some-one* must know Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRBEPA
On Sun, Oct 16, 2011 at 4:53 PM, Micheal Butz michealb...@optonline.netwrote: The normal sequence then is common when scheduling to a different address space just think about it for a minute. There is no magic. Put yourself in the SRB's place. In order for it to run, the code has to be addressable in the primary address space where it is initially dispatched. Nothing else matters. From the scheduling application's point of view you just have to make sure the SRB code is in the right place and will remain there until after the SRB completes. If you are going to schedule an SRB into your current primary address space, then it doesn't matter whether the SRB code is in common or in private, it just has to be there when the SRB is dispatched. That is actually an extremely common scenario, e.g. an SRB being scheduled out of disabled code (typically an interrupt handler) to complete processing for whatever was going on. On the other hand; If you are trying to schedule an SRB into -any-other- address space, then (somehow) you have to make sure the code will be addressable when the SRB is dispatched. In general that means loading it into common storage (technically it should be in SQA rather than CSA, but that's a minor nit) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRBEPA
On Mon, Oct 17, 2011 at 11:31 AM, Sam Siegel s...@pscsi.net wrote: On Mon, Oct 17, 2011 at 9:27 AM, Chris Craddock crashlu...@gmail.com wrote: On Sun, Oct 16, 2011 at 4:53 PM, Micheal Butz michealb...@optonline.net wrote: snip On the other hand; If you are trying to schedule an SRB into -any-other- address space, then (somehow) you have to make sure the code will be addressable when the SRB is dispatched. In general that means loading it into common storage (technically it should be in SQA rather than CSA, but that's a minor nit) I'm curious on the technical distinction between putting the SRB code in SQA versus CSA. Can you elaborate? (E)SQA has the correct storage attributes. (E)SQA is key zero and page fixed. You should never load SRB code into anything but key zero and the code should never be paged out, hence my use of the term SQA as a technical nit. You -can- make appropriate choices of subpool and macro options to get equivalent attributes from (E)CSA and if (as usual) there's no SQA available VSM will give you CSA equivalent anyway - known as SQA overflowing to CSA. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SRBEPA
On Mon, Oct 17, 2011 at 5:31 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: In cakxahqwwofk2cmeed1akporkeytzvz-_iq5pk1kmi3bb8fx...@mail.gmail.com, on 10/17/2011 at 11:27 AM, Chris Craddock crashlu...@gmail.com said: On the other hand; If you are trying to schedule an SRB into -any-other- address space, then (somehow) you have to make sure the code will be addressable when the SRB is dispatched. In general that means loading it into common storage (technically it should be in SQA rather than CSA, but that's a minor nit) Why? As long as the address is accessible and the code will be addressable, why can't it be private and pagable? MVS can handle a page fault in an SRB routine. Now, if you're going to schedule SRB's into multiple address spaces for the same routine, then you would want the code in common so that you only need a single copy. If you can arrange ahead of time for the code to be loaded in the foreign address space then of course it can be in private. I said as much. It is also true that SRB's can take page faults, so the SRB code *can* be in pageable storage... However, it is very desirable for the SRB to be able to run through its processing without taking any unnecessary page faults. An ordinary SRB dispatch is an extremely efficient mechanism, but if the SRB subsequently interrupted and has to be suspended (e.g. for a page fault) the system has quite a lot of work to do to save its state (SSRB, FRR stack, linkage stack etc). It is still fast, but why take the hit? Kind of like the old joke about Ferraris. She's a made a to go, not a to stop. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SYSTEM ABEND CODE 0F8 REASON CODE 00000014 under TESTAUTH
No, you werent where you thought you were in the code. The system doesn't lie about what happened. You can't issue any SVC instructions while you have an FRR on the stack, regardless of what kind of FRR you have. And don't forget you may be calling other system services whether you're aware of it or not. Leaving aside the general undesirability of testing SRB code by trial and error, If you did manage to get the SRB scheduled then two interesting things are happening to you. First you have another independent unit of work running (the SRB) which will muddy the waters because any error that befalls the SRB will be reflected back on the TCB you're running under so your debugging information is going to be quite confusing. Frankly you're kind of stumbling around in a coal mine with a flashlight even trying this. I would usually give a little sermon about all the things that can go horribly wrong. I will spare you that but here's the rub -- there's not a lot of chance you're going to suddenly converge on a solution that works. Tell us what problem you're trying to solve and maybe we can help you without trashing your system. Sent from my iPad On Oct 17, 2011, at 10:07 PM, Micheal Butz michealb...@optonline.net wrote: I didn't issue any SVC The code blew up under TESTAUTH at the fifth instruction after the expansion of the SETFRR macro I normally get 0F8 when I am in XMEM mode and issue a SVC I didn't abended on a SVC I abended whitin STM of the SETFRR inst -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Monday, October 17, 2011 10:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: SYSTEM ABEND CODE 0F8 REASON CODE 0014 under TESTAUTH Hi, I am trying to establish a FRR in a TSO command processor program that is not re- entrant this is because Later I schedule a SRB and I want to use the routine I established as a FRR, as input to the SRBFRRA parameter Did you review the abend and code? S0F8 - 14 - THE SVC ISSUER HAD AN ENABLED UNLOCKED TASK MODE FRR. IE. EUT=YES WAS SPECIFIED ON THE SETFRR MACRO. Did it help? Are you a member of the assembler language newsgroup? You might have better response there or better assistance. assembler-l...@listserv.uga.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rename of DDname ?
Changing an allocated DDNAME is a recipe for a train wreck. Just don't. The Allocation component is older than dirt. If you were meant to be able to do such a thing there would be an interface for it. Chris Craddock Sent from my cell phone 281-770-1950 On Oct 7, 2011, at 12:29 PM, John McKown joa...@swbell.net wrote: I don't think you can do a rename of an existing DD name. However, if you have a driver program doing the allocations, perhaps you can change it. Instead of allocating, say, SYSUT1. You allocate some unusual name, perhaps #SYSUT1$ (just to pick one). Then, when you want to refer to that allocation, do a dynamic allocation DYNALLOC using keys DALDDNAM - use the called program's DD name, eg SYSUT1 DALSTATS - use DISP=OLD (or maybe SHR) since you already have it allocated DALDCBDD - with #SYSUT1$ to pick up any DCB= DALREFD - with #SYSUT1$ to refer back for any attributes DALVLSER - with the volumes allocated to SYSUT1, other code will be needed to get this information after the original allocation is done. I have never done anything like this, so I could be totally off-base on the idea. Perhaps others can say more definitively. On Fri, 2011-10-07 at 17:11 +0200, Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Walt Farrell Skickat: den 7 oktober 2011 17:00 Till: IBM-MAIN@bama.ua.edu Ämne: Re: Rename of DDname ? On Fri, 7 Oct 2011 15:45:50 +0200, Thomas Berg thomas.b...@swedbank.se wrote: Are there any way to rename a ddname ? By that I mean leaving the allocation as such untouched but the name of the allocation/DDname is changed. An example of usage is when You have an allocation for application 1 with DDname 'ABC' for dataset AAA.BBB and want to keep that and then want to run application 2 which requires the same DDname (for dataset CCC.DDD). This is just *one* example. Is it a matter of editing the TIOT, or ? No, you can't edit the TIOT. How/where are you running these applications? For the moment the need is in the ISPF/TSO environment. There is programs that requires specific DDnames which is common to other programs, both homegrown and system types, and some of our dialogs need to run several of these at the same time (in sequence) but I want to preserve some allocations because of performance issues (e g big temporary datasets that takes a long time to create or that I need to keep the enques for, etc.). Common system names are such as SYSUT1, SYSUT2 etc. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- John McKown Maranatha! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CA MSM v4 on z/os 1.9
with MSM there was a conscious decision to follow IBM support policies, which makes sense if you think about it. I have no idea whether anyone is running it in an unsupported config. I would point out that if a vendor says release X is required, it usually means just that. You can go off and do your own thing (of course) but you should not expect too much sympathy from the vendor if your way doesn't work. CC Sent from my iPad On Oct 6, 2011, at 11:10 AM, Silvio Camplani sysp...@silvio.fastmail.fm wrote: The release notes for MSM v4 say z/OS 1.10 is required. This seems to be because IBM supports current-2... Is anyone running MSM v4 on a pre z/OS 1.10 lpar? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SETLOCK in IEFU85
It is highly unlikely that you would need a CMS lock. If you are in a properly established cross memory environment then PASN is going to stay put. There are multiple ways of serializing storage modifications w/o resorting to a lock. FWIW to get a CMS lock (there's more than one) you must first hold, or obtain a Local lock. The address space whose Local lock you would need to hold depends on the location of the resources you're trying to serialize. a CML is just the local lock of either PASN or SASN when that is different than HASN - assuming you're in a valid (legally established) cross memory environment. Beware that the hardware will let you do LOTS of things that z/OS doesn't formally support. Chris Craddock Sent from my iphone On Aug 8, 2011, at 7:06 AM, Donald Likens dlik...@infosecinc.com wrote: I need to update common storage from my IEFU85 SMF exit. I am currently using a compare and swap loop to serialize on this update but I think there is a problem with this approach and looking at using SETLOCK. My question is... IEFU85 is in cross memory mode. I need the CMS lock. To get the CMS lock you must have the CML or LOCAL lock first. Since IEFU85 is in cross memory mode must I get the CML lock or can I get the LOCAL lock? Part 2: If I must get the CML lock which address space should I place in R11? Note: I never used locking before so if I have stated anything incorrectly, please correct me. I also have not delted with cross memory before. Part 3: To issue the SETLOCK command, do I have to worry about AR mode before issuing in an SMF exit? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESTAE testing question
On Wed, Jul 20, 2011 at 10:18 AM, Paul Schuster pgs4ibmm...@pacbell.netwrote: Hello: The manual 'z/OS V1R12.0 MVS Assembler Services Guide' has this statement: The case where an SDWA is not provided is rare. Is there a way to force this kind of condition in order to actually test an ESTAE that is tripped with this condition? That's not a good plan. The only time you won't get an SDWA is in cases of storage exhaustion and a likely cause of that is error recursion due to creative recovery efforts. The safest thing to do in that case is to immediately percolate. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Explination of EUT/FRR
On Sun, Jul 17, 2011 at 2:45 PM, michealbutz michealb...@optonline.netwrote: Hi, I have seen these terms EUT Enabled Unlocked Task /FRR and this my understanding I ASSUME Enabled means Enabled for I/O interrupts BIT 6 of Psw the only way I know how to set this is with the LPSW inst No, there's also the external interrupt. Both I/O and external interrupts are masked by the last two bits in the first byte of the PSW. The actual interrupt enablement for the underlying CPU is governed by bits in a control register which get AND-ed with the PSW bits to decide whether the corresponding interrupt will be allowed to occur. There are multiple ways the bits can be turned on or off. You should not try any of them. Unlocked means not holding a Lock Holding a Lock means using some Flavor of the SetLock Yup. Also includes certain special cases such as when running under control of a disabled interrupt exit (e.g timer DIE). There are no locks actually held, but the system acts as if you're holding the CPU lock. Task means running in Task Mode as opposed to a SRB Yep. When the Term FRR is appended it means this unit of work is protected by a FRR Yes. But what makes an EUT FRR an EUT FRR is that you specified EUT=YES on the SETFRR macro. If you had set an FRR in a condition where you would not normally need one, the system will unceremoniously remove it during the next interrupt. EUT=YES tells RTM that you know what you're doing and that the FRR should be left alone. Typical use case is where you're about to get into one of the conditions that would require an FRR and you want to provide the FRR ahead of time, e.g. to perform some post recovery cleanup, release locks etc. All of which is pretty advanced stuff. Not a safe area for tourists. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Obtaining System Information from a COBOL program
On Thu, 23 Jun 2011 11:01:56 -0400, Andy Coburn a...@andycoburn.com wrote: I question Walt's statement above in one case and one case only. The quote below is from the z/OS V1R11 manual Using Data Sets SC26-74410-09: quote ...snipped (by Walt)... Note: VSAM OPEN routines bypass RACF security checking if the program issuing OPEN is in supervisor state or protection key 0. /quote I call your attention to the last paragraph. I have been hoping that IBM will find a way to eliminate this restriction so I won't have to do my own RACROUTE REQUEST=AUTH for every VSAM data set I open when I'm in supervisor state or key zero. I would imagine that not very many COBOL programs run in supervisor state or key zero, but Walt Farrell put on his security hat (his words) so I thought it might be proper to continue his line of thought. http://bama.ua.edu/archives/ibm-main.html You can be fairly certain that *no* COBOL programs run in sup state and/or key zero because LE does not officially support it and not at all without performing unnatural acts. That's not to say you can't conspire to get that to happen, but it would be most unwise to try. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Chacteristics of HOME ASC mode
On Wed, Jun 15, 2011 at 6:50 AM, Micheal Butz michealb...@optonline.netwrote: What if you Have a ss pc rtn and want to access data and inst from the program that issued the ss pc rtn That only takes a little bit of design forethought. Home-space ASC mode is probably the last thing you should be thinking about. On Jun 15, 2011, at 6:07 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Why do you think that you need HOME mode? There may be a better way to do what you want to do. Out of curiosity, are there any supervisor services that work in HOME? No there are not, at least not any publicly documented ones. The major use case is down in the guts of RTM. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RESMGR for terminating Address Space
On Fri, Apr 15, 2011 at 4:17 PM, michealbutz michealb...@optonline.netwrote: Hi, Would anyone know if installing a Address Space Terminating routine via RESMGR works Under all circumstances Meaning normal Termination Yes, Memory Termination resource managers always get control (in *master* btw) at some point after the tasks in the address space have ended. OTOH task level resource managers may or may not get control depending on circumstances. Realistically all resource managers are going to get control in all but the most dire of situations. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best way to multiply doublewords
On Tue, Apr 5, 2011 at 10:50 AM, Tom Marchant m42tom-ibmm...@yahoo.comwrote: It is worth noting that the system provides a 144-byte save area when a program is ATTACHed, as for example when a job step program is given control. true, and somewhat ironic given that it is one of the few interfaces where there truly is no need whatsoever to preserve the caller's state. A mere SVC 3 (or a branch to CVTEXIT, which is itself just an SVC 3) is all that is required. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PSAAOLD question - when is it updated?
On Mon, Mar 14, 2011 at 5:38 PM, Stan Weyman stan.wey...@emc.com wrote: having been down this road on numerous occasions I think Rob has it pretty much nailed IMHO. Please send check payable to Rocket Software, etc, etc... G yeah bright lad is our Rob. The key takeway is if you fetch PSAAOLD and discover it is for ASID 1 then you are running in the*master* address space. But gasp... how could that be gentle readers?!? Well basically a whole load of junk in the way of system exits runs in master simply on the logical basis of where the hell else would it run?. Foremost among those are the EOM RESMGR exits. The ended address space gets put on a queue and its memory termination routines get processed by subsystem router tasks and when they have the temerity to screw up (such as mindlessly and incorrectly referencing private area resources from the dear departed address space) you will see a bunch of wailing and gnashing of teeth from IEFJSRASP. Help? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Am I running in an IMS MPR?
On Tue, Feb 22, 2011 at 11:19 AM, Tony Lubrano tony.lubr...@neon.comwrote: Yes... LRx,PSAAOLD-PSA(,R0) LRx,ASCBASXB-ASCB(,Rx) LRx,ASXBITCB-ASXB(,Rx) LRx,TCBFSA-TCB(,Rx) LRx,SA_R1(,Rx) CLC =CL4'ECP',0(Rx) JEIMS BMP CLC =CL6'DFSRRC',20(Rx) JEIMS MPP If you want, you can do a BLDL on DFSPRPX0. If it is found in the JPA, you are likely to be running in an IMS dependent region. Or, you can follow the CDE chain(s) to locate the module. Just to nitpick slightly; CSVQUERY would be a better choice than BLDL or chasing CDEs. Also, regardless of which path you take to find the job step TCB, it isn't wise to assume either that there is a first save area, or that the contents of the R1 slot point to anything at all. If it is a real job step then there will always be an FSA but below that all bets are off. You need to apply a sniff test before referencing those data areas, or wrap a little recovery around the instruction path above. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: What is address spec terminates in context of LOAD EOM=YES?
On Tue, Feb 8, 2011 at 2:43 PM, Charles Mills charl...@mcn.org wrote: Ah Binyamin, you are a man of few, but cogent, words. Thanks! Looks like the answer to my second question: how do permanent load? Anyone have an answer to my first question (which is mooted if CSVDYLPA lives up to its promise): what is until address space terminates in context of LOAD EOM=YES? Also my apologies for the typo in the subject line. How did I mean to type space and have it come out spec? Not even close. For a garden variety address space (let's face it, that's basically TSO or a STC these days) EOM literally means when the address space termination routines run in the master address space and AFTER all of the tasks in the original address space have ended. Now as you know, a batch address space is different in that many jobs use the same address space one after another. EOM for the batch job's address space typically happens eons after the end of any job that ran there. If you take the definition above it should be fairly obvious that you have to mentally treat the real job step task of each job as the owner for resources that are typically scoped as EOM in other address spaces. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIMEUSED versus TCBTTIME
On Fri, Feb 4, 2011 at 9:38 AM, Rob Scott rsc...@rocketsoftware.com wrote: TCBTTIME is *not* updated when task is actually dispatched and executing on a CPU, only when it gets interrupted by something like WAIT. TCBTTIME will not include any fancy CPU stats either (Enclave SRB, zIIP and zAAP). Also, I do not believe that TCBTTIME is a GUPI field. However, for a quick and dirty sniff at how a normal program is executing, I see little risk for an in-house utility if the limitations are known. http://bama.ua.edu/archives/ibm-main.html All true and good sensible stuff too. For a quick and dirty (and fairly light weight) way to coerce the system into updating it there's always this old trick... WAIT ECB=PHONY (do stuff) DS 0F PHONY DC X'4000' the system sees PHONY as a posted ECB and gets the flock out of there PDQ, updating all of its relevant dispatch counters and accounting fields on the way. :-) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TIMEUSED versus TCBTTIME
On Fri, Feb 4, 2011 at 10:38 AM, Charles Mills charl...@mcn.org wrote: @Chris: Interesting. Do you suppose the technique you describe is cheaper than TIMEUSED with ECT? Hard to tell without benchmarking it and I wouldn't offer a prediction. *HOWEVER* if you are of a mind to sample relevant fields from various control blocks yourself, then this dirty trick gives you a point in time consistency and the cost is essentially a type 1 SVC entry and exit linkage plus a tiny amount of processing in the wait logic until it notices the ecb has already been posted. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Home 1= PRIMARY != SECONDARY
On Thu, Jan 27, 2011 at 12:19 PM, michealbutz michealb...@optonline.netwrote: Would anyone know in what scenario HOME id not = PRIMARY is not = SECONDARY For any given unit of work HASN *never* changes. Initially PASN=SASN=HASN. A space switch PC branches into another address space, so PASNHASN. Depending on how the PC is defined, SASN=new PASN, or old PASN so there's still only two address spaces involved. If the space-switch PC routine calls another space-switch PC then there is now a third address space involved and (again, depending on how the PC is defined and what it does) you can end up with PASNSASNHASN. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Home 1= PRIMARY != SECONDARY
On Thu, Jan 27, 2011 at 3:31 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: On 1/27/2011 2:51 PM, Edward Jaffe wrote: Instructions are always fetched from primary (see PoO). Sorry. It is possible to fetch instructions from home if you switch to home-space ASC mode. http://bama.ua.edu/archives/ibm-main.html True... but nobody outside of Poughkeepsie should ever be running in home-space ASC mode. No doubt some folks will pile on about this but really just don't. Mr Relson is qualified to do it. The list gets very short very quickly after that. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: search for usage
Does anyone have any analysis (which can be shared) related to SuperC's Search-For CPU usage? Its not exactly a gauzy sheer chiffon dress, but who cares? You're only going to use it now and then (when you need it) on moderate sized datasets right? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: X-memory POST question
On Thu, Dec 23, 2010 at 1:06 PM, Robert A. Rosenberg hal9...@panix.comwrote: At 12:31 -0500 on 12/23/2010, Tony Harminc wrote about Re: X-memory POST question: On 23 December 2010 09:43, Binyamin Dissen bdis...@dissensoftware.com wrote: On Thu, 23 Dec 2010 08:30:25 -0500 Peter Relson rel...@us.ibm.com wrote: [...] :This goes to why, in many cases, XM Post is not safe, [...] Are you implying that one should open an APAR against XM POST as an integrity exposure? It's hard to see how a service that is offered only to authorized programs could constitute a violation of the MVS system integrity statement. Tony H. I think the point was that the service has no provision for checking that its use is not going to raise a system integrity exposure. As explained in the checking before issuance procedure, it can mess up the wrong Address Space (or the contents of the correct address space which no longer correspond to the intended location of the ECB). This means that the XM Post caller needs to do their own integrity check as opposed to having the XM Post call doing it and returning a It Failed Return Code. There are several fundamental problems with POST and cross-memory POST just amplifies those. Even for OS/360, an interface consisting of a single word of storage with no eye catcher and no management protocol whatsoever was probably a bit too minimal. Unfortunately WAIT/POST not only survived, but became central to the programming model and operation of the entire system, so any new and improved alternative such as PAUSE/RELEASE (which is very good btw) stands almost no chance of being widely adopted. The biggest flaw is that there is literally no way for the system to know whether the thing you're pointing at is actually an ECB. If you're running in the right key (or worse, in key zero) and the address is valid, the system will blow a nice 4-byte hole at that location, no questions asked. Even when the location actually WAS an ECB at some time, it may not be any more and an asynchronous unit of work that knew about it at some point when it was an ECB may eventually get around to posting it. If you're lucky that will fail, but most of the time it works perfectly and silently corrupts who knows what. Fortunately the cross-memory version is only available to privileged callers so the risk is somewhat reduced. However, if you're doing something brand new, I would very strongly suggest you consider using PAUSE/RELEASE and not bother with WAIT/POST at all - except in the cases where some existing service requires it of course. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Authorized Rexx Assembler Function
My question was that if you have an SVC that does stuff, can it use RACF to check if a user has permissions? Based on your kind replies to my query, the answer is yes. Yes, it isn't just for dataset security. You can ask security questions about any logical resource, even ones you make up yourself. RACF and ACF2 and TopSecret are all called via the same macro (RACROUTE) and they all allow you to ask varieties of essentially the same question: Can user X, do action Y, to resource Z?. So as long as you can correctly formulate the question you want answered in your SVC or PC routine, it doesn't matter which underlying security manager is present. The answer that comes back is one of yes, no, or maybe. How you interpret the answer is up to you. And yes, if you're doing anything non-trivial, using the security manager is a very good idea. As a sidebar comment, if you're tossing up between a PC and an SVC, you're better off with a PC. Either way you have a non-trivial amount of work to get it set up and manage it. You will have lots of questions... -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Sp of load
On Wednesday, December 22, 2010, Micheal Butz michealb...@optonline.net wrote: Would anyone know what subpool load loads into Yes. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Paging Jay Maynard
On Wednesday, December 22, 2010, Mike Schwab mike.a.sch...@gmail.com wrote: Speak of the Devil, and he makes time magazine. http://newsfeed.time.com/2010/12/22/internet-legend-tron-guy-banned-from-seeing-tron-legacy-in-famous-suit/ My wife pointed that out to me and she was utterly shocked when I casually replied oh yeah, I know Jay Somehow she didn't really see it as a brush with celebrity. (sorry Jay) CC -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Frr pramter address question
On Mon, Dec 20, 2010 at 8:36 AM, Micheal Butz michealb...@optonline.netwrote: Hi, The paramd paramter on the SETFRR Macro when adding a FRR you give FRR a address where to return a pointer to a 24 byte area Where would set what info you want passed to your recovery routine in the 24 byte area At the risk of handing you a loaded gun... when you issue SETFRR, the parameter address that is returned to you points to FRRSPARM which is a 24 byte area at the end of the current FRR stack entry. You can store whatever you want in that area (up to 24 bytes, of course) so a typical use case would be to store anchor information so that your FRR recovery routine can find its butt in the dark without a flashlight.What your FRR routine *does* is the hard part. You're in pretty dangerous territory to be stumbling about in the dark. *IF* you do this, I strongly recommend that you do *NOT* attempt to retry out of your recovery routine. Just gather some diagnostics (carefully!) write a message (carefully!) and issue SETRP to percolate with a LOGREC. If you want better diagnostics than that you can request an SVC dump by issuing SDUMP from within your recovery routine, but be careful with that too. You can easily bring a system to its knees by taking excessive dumps. Good luck -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: determine runtime privilege level (prob/supr state, key) without TESTAUTH
On Fri, Dec 17, 2010 at 8:20 AM, Dr. Stephen Fedtke max_mainframe_...@fedtke.com wrote: hi all, if a programcode does not know anything about its environment, and needs to determine its privilege level/status (i.e. problem or supervisor state, key), it could use TESTAUTH. fact is that TESTAUTH has some environmental restrictions, such as TCB mode. on the other hand, most of these PSW-related instructions are privileged, and just using them implies the risk of a 0C2 in case the code runs non-privileged. my questions: * is there any non-privileged instruction to determine the status? * is there any control block field the psw is almost mirrored in (in real-time)? so that this pseudo psw could be checked. OR is the only way: 1) check for being an SRB. 2) use TESTAUTH? if you're only concerned with answering the question am I currently in a privileged condition? then yes, there is a fairly trivial sequence of instructions that you can use that is functionally equivalent to TESTAUTH but about a zillion times faster. If you wanted to determine whether your caller was privileged then there's a slightly different mechanism depending on whether you're running in an SVC or PC routine. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Batch program to update CVTUSER
On Wed, Dec 15, 2010 at 1:22 PM, Lorne Dudley dudl...@queensu.ca wrote: I'm having problems getting the following batch program to run correctly. It's running from an authorized library and abends with 0C4, reason code 4. The book says the key of the storage area that the running program tries to access is different from that of the running program. Data Areas for CVT says Storage Attributes: Subpool: Nucleus Key: 0 Residency: Below 16M line Any ideas appreciated. Ok. Don't do it. It is basically a bad idea. While that field was originally intended for user (i.e. customer) use, in practice it is unusable. If you want to be able to anchor something globally then you should probably use some common storage and create a global name/token pair to point to it. LRR9,R15 .SET UP ADDRESSABILITY USING Y,R9.SET UP ADDRESSABILITY USING CVT,R2 .CVT DSECT * MODESET KEY=ZERO,MODE=SUP * L R2,CVTPTR LOAD UP CVT ADDRESS L R3,CVTUSER LOAD CVTUSER ADDRESS If you wanted to alter the contents of CVTUSER (a bad idea remember) then you should use LA R3,CVTUSER * move 4 characters to CVTUSER MVC R3(4),=C'TEST' RETURN (14,12),RC=0 .RETURN TO CALLER Not to be harsh, but you obviously don't know what you're doing. Unfortunately what you're doing is potentially harmful. As it is you would get the contents of CVTUSER (i.e. zero) in R3 and your subsequent move would fail with a S0C4-4, but only because the hardware provides low address protection. Almost anywhere else you'd clobber whatever happened to be there. What problem (other than just playing around) are you really trying to solve? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Batch program to update CVTUSER
On Wed, Dec 15, 2010 at 4:06 PM, Richard L Peurifoy r-peuri...@neo.tamu.edu wrote: On 12/15/2010 3:23 PM, Chris Craddock wrote: Ok. Don't do it. It is basically a bad idea. While that field was originally intended for user (i.e. customer) use, in practice it is unusable. If you want to be able to anchor something globally then you should probably use some common storage and create a global name/token pair to point to it. I am curious about this. Do some vendors try to use this field? If so, I guess we have been lucky in our choice of vendors. We have used this field to anchor a local CVT for over 40 years and have had no problems. If I were doing it now, I would probably use name/token, but it wasn't available then. back in the day... adventurous folks like Lorne looked at the data areas manuals or fiche and saw USER area and thought of interesting things to do with that anchor (there are several scattered around the place). As a result of that, there are probably dozens of examples of naive old-timey vendor products that attempted to use those data areas over the years and as long a nobody else was trying to use the same user words the products worked. But there isn't any protocol or interface for sharing a single word with others who would also like to use it. Heck back then we didn't even really have the concept of an interface. So it rapidly became obvious to most folks that the user words were in fact useless and their exploiters found another way to do what they wanted. Hence my question to Lorne... what are you actually trying to accomplish? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: VSMLOC documents as using the current address space
On Fri, Dec 10, 2010 at 6:50 AM, Peter Relson rel...@us.ibm.com wrote: IOW, a PC-SS cannot examine the callers addresses via VSMLOC? Correct, at least using documented interfaces (since secondary and home ASC modes are not part of the documented programming interface, and as such might or might not work). VSMLOC does work in cross-memory mode (PASN HASN), *BUT* it is defined to require a primary ASC mode caller, so there's no way to clue the service about the address space you mean. It is going to assume you mean the current primary (PASN). The macro will return the address of the owning TCB for PVT. BTW For services that do accept ALET qualified parameters, most of them don't accept parameters in the secondary address space (ALET=1) That is because those services are implemented via PC instructions. Depending on how the PC is defined, executing the PC instruction will alter the current SASN, even if the PC is not space switching. So after the PC instruction is issued, the SASN that is seen by the service is (typically) the caller's PASN and the caller's SASN is no longer addressable. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Field that contains timestamp of when current jobstep started?
On Thu, Dec 2, 2010 at 3:18 AM, Binyamin Dissen bdis...@dissensoftware.comwrote: On Thu, 2 Dec 2010 13:26:15 +0930 Anthony Thompson anthony.thomp...@nt.gov.au wrote: :ASCBINTS would be job start time, not current step. True. Oops. My bad. I didn't notice you wanted the step time. I don't know off the top of my head which step-level control block would have that (although there must be one somewhere) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bit mode disabled
On Wed, Dec 1, 2010 at 10:25 AM, Tony Harminc t...@harminc.net wrote: On 1 December 2010 10:46, Edward Jaffe edja...@phoenixsoftware.com wrote: You can use an ordinary branch instruction (e.g., BASSM 14,15) to branch to code above the bar. If you're running enabled, you won't execute for long... :-D Just how does it fail? Is the PSW instruction address silently truncated upon return from an interrupt as a result of its having been saved in a legacy control block, leading to continued execution at a presumably incorrect address, or is there some active detection and abend? Something else? What if I install the same code at, say _00123000 and 0070_00123000, and branch to the above-the-bar code? The first level interrupt handlers are responsible for saving the status of the interrupted work. If they detect execution above the bar they call RTM and ruin your day. It is, though, curious that there must be, as Paul Gilmartin points out, quite a bit of infrastructure already there in support of 64-bit addresses. The real PSW is at all times beyond the early stage of IPL a zArch one of 128 bits, and it must be saved and restored properly, as must things like PER addresses in control registers. What remains to be done? http://bama.ua.edu/archives/ibm-main.html there is a technique called PSW scrunching that allows saving an extended PSW in a normal 8 byte PSW field when the instruction address is only 4 bytes. As you can probably imagine, there is literally no way to preserve compatibility with the near infinite number of programs that currently understand and inspect the task management control blocks, so while execution above the bar is a goal, it is a long way off yet. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I would love to know what went wrong at NAB
On Wed, Dec 1, 2010 at 2:11 AM, Ron Hawkins ron.hawkins1...@sbcglobal.netwrote: If I remember rightly it was a bug in IMS 2.2 or 2.3. If I remember correctly NAB (where I worked at the time) had found the bug in stress and regression testing (TPNS for those that remember it) and were waiting for the fix that hit Westpac. Funny how times have changed. Yes it was IMS 2.2 and it did not actually fail in testing. It was in test for quite a while and there was a lot of pressure to put it into production. It crashed mid-morning as the national branch network came online on the monday after it went live. It came up again, went down again, yo-yo'd a few times and then stayed down. The real problem was in the restart and recovery processing which changed in 2.2. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Field that contains timestamp of when current jobstep started?
IIRC there is a field which has the timestamp of when the current step started, but I cannot seem to find it. ASCBINTS -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: I would love to know what went wrong at NAB
On Tue, Nov 30, 2010 at 10:39 PM, Chase, John jch...@ussco.com wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane As if. Can't you just imagine a major Aussie Bank doing that. You were at Bank of NSW when they had the IMS fiasco Steve - how much info on that got out ? (via Bank press releases I mean :-) Yeh It's probably a near-universal trait that dirty laundry is washed discreetly :-) This would be one of those rare cases where the story was big enough that there wasn't a lot of room for discrete laundering. It was actually Westpac by then (btw) and I was there too. That event wasn't a single outage, but rather a series of them wound around failed restart/recovery processing that eventually took several days to fully recover from. There wasn't any news coverage at first, but the scale of the problem had made the press by the second day. Once it had there was plenty of blame storming to go around. I don't recall whether the bank actually issued press releases but their point of view certainly did make it into the press coverage. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bit mode disabled
On Tue, Nov 30, 2010 at 9:43 PM, Gerhard Adam gada...@charter.net wrote: How would you branch to code above the 2GB bar, since none is allowed there? The obvious problem being how you would even get it loaded up there. If I recall, the fundamental problem is that the PSW cannot be saved with an address greater than 31-bit for the next instruction since neither the TCB's or RB's have a large enough area to store it. I have a vague memory of reading, here or on the assembler mailing list, that you would need to run disabled if you wanted to branch to code located above the bar. I also have a vague memory that the Wrath of God would probably fall on you anyway if you tried it, disabled or not. Clearing the air: No, the SAM instructions don't cause you to become disabled. They just switch addressing mode. It is perfectly ok (normal even) for ordinary garden variety programs to switch in and out of 64 bit addressing mode. All z/OS code is loaded below 2GiB, so nothing fancy needs to be done to branch into 64 bit code. However, if you were imagining you would be executing code that was above 4GiB, then forget it. z/OS doesn't support it at all. Even if you could somehow conspire to get some code into storage above the bar, you would not (in general) be able to execute it successfully because none of the major control blocks that manage dispatching work can support saving a full extended PSW, so while you might get away with it for a few instructions, the moment you took an interrupt you'd be toast. Hence the putative requirement to run disabled. For the purposes of this discussion you may assume that's just a bonehead idea. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Potential heresy regarding E and L macros etc. (Was: WTO ABEND D23 help)
On Fri, Nov 19, 2010 at 10:40 AM, Chris Mason chrisma...@belgacom.netwrote: Charles snipIt was because of your earlier posts on automation topics that I bothered to poke my nose in here and it was only when I saw what might be a bit of irritation with the static nature of macro coding, even the E and L - or perhaps especially because of the E and L form - that I feel prompted to suggest a step further than the course proposed by Chris Craddock. This step is, having studied the E and L forms of the macro, ditch the pesky things and just code what is necessary in raw - but superbly documented as always, of course - instructions - with perhaps a comment box surrounding something like the macro text that you would have coded had it been dynamic enough.[1] I think you have missed the point I was making about the WTO interface. I do NOT advocate ditching formal interfaces in general. In fact, the exact opposite is true. I generally advocate for using the official macro interfaces for calling system services. Doing it by hand is error prone and certainly not worth the effort if you have to do it more than once. However there are a few egregious cases where the official interface is (a) so old and crufty that it is unreasonably difficult to use for the general case - the WTO interface we were discussing is a classic example, or (b) is so complicated that it is essentially unusable by mere mortals - many of the XES and LOGR interfaces would fall into that category. I would probably concede your point about the xxxCB macros too, although I've seen the VSAM versions used extensively in products I've been associated with and once you get the gist of them they aren't that onerous. In those too hard for mere mortals cases I provide additional macro infrastructure or kinder-gentler callable service interfaces so that other developers don't have to wrestle with the ugly use cases. But even in those cases I generally use the official macro interface under the covers unless there is a compelling reason not to. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 4:02 PM, Sam Siegel s...@pscsi.net wrote: Hello, What is the most efficient way to coordinate work in a synchronous fashion between a problem state TCB and an enclave SRB? Pause, release? Wait, Post, Latch services? Other? The enclave SRB will be scheduled into the problem state TCB's address space. The enclave SRB will be parsing a buffer and searching for certain tokens. The processing is simple and does not have many lines of code, but could be executed 10s of millions of times per day. The buffer is processed in a read only manner. If both are operating synchronously in the same address space, why bother to introduce the SRB (and communication/synchronization overhead) at all? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Performance questions
On Sun, Nov 14, 2010 at 4:30 PM, Sam Siegel s...@pscsi.net wrote: On Sun, Nov 14, 2010 at 2:22 PM, Chris Craddock crashlu...@gmail.com wrote: If both are operating synchronously in the same address space, why bother to introduce the SRB (and communication/synchronization overhead) at all? Eventually, the SRB will be used to offload work to a zIIP. Otherwise I would not consider this route. Beware of the head long rush to leverage zIIP engines. Using a zIIP is definitely NOT worth the effort unless the work you're offloading to the zIIP is a significant percentage of the total. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Recursive abends on FRR's
On Fri, Nov 5, 2010 at 6:58 AM, Micheal Butz michealb...@optonline.netwrote: I know the field SDWASTAE tests for recursive entry for Esate(s) is there to test for recursive entry for FRR's there's no such thing as a recursive entry to a recovery routine. When an error occurs the FRR stack is processed in LIFO order and then the SCB chain is processed in LIFO order and with ARRs (if any) being interleaved in the right places. Once an individual recovery routine has been entered it is logically disabled and cannot be reentered unless/until a retry occurs. Any (non-FRR) recovery routines that were logically taken out of scope at the retry point will be removed by the system and the linkage stack and RB chain cut back to the point they were at when the recovery routine was set. In effect, the system is trying to put things back the way they were so that it is appropriate to continue. If another error occurs after a retry then the entire process takes place again - which is what many people interpret as recursive abends. That is why in my last post on this topic, I recommended that you issue a diagnostic message and percolate. If you do that you can never get into this situation, regardless of the recovery type. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WTO ABEND D23 help
On Tue, Nov 2, 2010 at 11:24 AM, Robert A. Rosenberg hal9...@panix.comwrote: At 09:32 -0400 on 11/02/2010, Charles Mills wrote about WTO ABEND D23 help: There is a field in the WTO MF=L commented as WPX length. It assembles as 104=x'68' and it's still x'68' in the dump. I don't find WQEBLK or WPL in the listing. I've looked at the MF=E macro expansion and it seems to be storing the CART address and the CONSID in the right place in the MF=L. The text pointer is correct (16 bit length + text). What else should I be looking for? I see that after tweaking you got it working. One tip for the future. If you are going to use parms like CART and CONSID in the MF=E, they should also be used in the MF=L. Some parm lists have flags set in the MF=L indicating what parms are being supplied. If you fill them in via MF=E, there can be problems if those parms (and thus the flags) are not also in the MF=L. I am not saying that that this was your problem but it does not hurt to make sure by having the parm in both macros (if not needed, it will not cause any problems for macros where the MF=L just provides the parm area but no content and the MF=E does ALL the work of building the parms). that's true. It is best to use as close to identical MF=E and MF=L expansions as possible. That can be a bit tricky if you don't know ahead of time how many message lines you're going to need. The limit for a non-privileged caller is 10 btw. I also feel honor bound to point out that the IEZWPL mapping is (to be charitable) extremely misleading. If you're going to build your own expansion you will need to study the actual WTO macro expansion rather than relying on IEZWPL. Try WTO TEXT=(...) with one, then two and then three message lines and you will fairly quickly get the gist of it. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Task Creation and Termination
On Sat, Oct 30, 2010 at 9:07 PM, Micheal Butz michealb...@optonline.netwrote: Sorry by 2 I meant 1 parameter and 1 MVS Service DETACH yes there ARE actually two parameters that you can specify that will result in you having to issue DETACH for yourself. ECB (as already noted) specifies the ECB that will be posted when the task terminates. ETXR specifies the address of an exit routine that will get control as an IRB under the mother task the latter is extremely useful for doing any application-specific cleanup and perhaps providing more forgiving/useful termination notification to your application than you would get from the plain old ECB, which only contains the completion code. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Abending TCB
Mike Butz writes: If a main program uses a Estae rtn then does Multiple Attaches specifying the same ESTAE rtn on the ESTAI parm of the attach can the recovery routine determine the abending TCB If you are getting control in any non-FRR recovery routine (ESTAI, ESTAE(x) or ARR) then the current TCB is always the abending TCB and, except in one interesting case, the error occurred in the current task. The interesting case is where CALLRTM TYPE=ABTERM is issued against your task by another unit of work, e.g. in the case of SRB to task percolation. The SDWA contains information about what was actually going on when the abend occurred and so if you're going to write robust error recovery code, you *REALLY* need to pay attention to that information. With that said, writing good general purpose recovery code is extremely hard. It is better and much easier to tailor your recovery as narrowly as you can to limit the recovery to the section of logic that you're trying to protect/deal with. For that reason alone the idea of using a single ESTAE routine as both an ESTAI and an ESTAE across multiple tasks and RBs within those tasks is just a bad idea unless you go to the trouble of building some underlying recovery infrastructure and leave plenty of footprint information so the recovery code can quickly determine where and why it is being entered and make sensible decisions about providing diagnostics and retry (or not). Most of the time the better path of valor is to request diagnostics, burp up a message about what went wrong and then percolate. You will seldom get in trouble for bailing out, but a surprising percentage of major failures come from ill-advised retry efforts. Another issue that almost always trips people up is the intersection between ESTAE-class recovery routines and the RB and linkage stack level. You need to read the topics on providing recovery very carefully and once you think you understand them, read them again twenty or thirty times. z/OS recovery has great power and flexibility, but it also has more ways of confounding and astonishing you than you can possibly imagine. So let me throw in some personal opinion. ESTAI recovery routines are worthless archaic garbage and should be completely avoided for any new code. They violate the principles outlined above and they build up like dandruff because they apply to every RB on every subtask. On the other hand ESTAE and ESTAEX, while they can be used very narrowly as outlined above, their use is specific to a particular (usually P) RB and linkage stack level so you need to bracket your code with ESTAE creates and deletes with some frequency and that hurts performance. So if you're going to provide task-mode recovery these days, I would strongly recommend using IEAARR to call the code you want to protect. It is almost zero cost and you can tailor it as narrowly as you want. And may the force be with you... -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Fri, Oct 15, 2010 at 10:43 AM, Ricc Harding ricc.hard...@gmail.comwrote: SPFCopy's magic SVC went thru several iterations to make it secure too. It was one of those SVC's that was written to be serially secure but in a multi-tasking environment when two or more tasks could be set up to run concurrently, then a serially secure task, doing what it did in a secure manner (if it was the only thing running) allowed everyone running in the address space to participate in the authorization. STATUS STOP became very much a requirement for those serially secure tasks to remain such. The truth is that there is no such thing as a secure magic SVC (or PC) no matter how creative its authors are. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking?
On Thu, Oct 14, 2010 at 11:13 AM, Bob Shannon bshan...@rocketsoftware.comwrote: I would think it means code that front-ends one of the First Level Interrupt Handlers That's how Amdahl implemented SE and SP assist years ago. I think IBM did it to implement the IEEE floating point instructions so that they would work on processors that lacked the hardware. Of course these were not malicious implementations. (as Bob knows) it is impossible to create/install a malicious FLIH or SVC or PC without already having the keys to the kingdom anyway. That is the foundation of integrity and the reason why the installation has to appropriately protect system datasets and APF libraries. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PAGE FIX
On Thu, Oct 14, 2010 at 4:17 PM, Larry Crilley larry.cril...@dino-software.com wrote: Sure. I just want to determine if a page is fixed. I'm not saying I want to free/unfix it. I just want to know... so far as I know, there is no way to tell in general. There are some obvious corner cases where you can tell, e.g. if the virtual storage address is in a non-pageable subpool, but there is no official interface that will tell you and as Binyamin pointed out, you couldn't rely on it anyway. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CANCEL/FORCE ARM (Was: Really dumb IPL question)
On Tue, Oct 12, 2010 at 8:55 AM, Chris Mason chrisma...@belgacom.netwrote: The archaic IEFSDPPT module is still valid, but for all practical purposes it is unusable. Unusable for all except IBM would be more accurate - although implied by your emphasis on vendors. As far as I can tell from scanning the section in the description of the SCHEDxx member in the Initialization and Tuning Reference manual, IBM routinely specifies its real or imagined requirements in PPT entries in the IEFSDPPT module. That tends to challenge your use of the adjective archaic. IBM does continue to use IEFSDPPT for some things that only take effect at IPL time. However that isn't terribly flexible or useful for anyone else, so I stand by the term archaic. I hope you took the time to appreciate my description of how the Communications Server (CS) IP component developers and authors had got their undergarments in a twist over NOCANCEL in the case of the TN3270E server. I don't know much about Communications Server in particular, but I do know a little bit about z/OS internals and systems management products in general. I can't comment about whether the CS components really need to run with NOCANCEL. I *can* comment on the technical reasons why a server address space might need to run that way. I don't know whether the TN3270E server has those attributes or not. Do you? Or more directly, do you know for sure that they don't? And does it really matter? It is not very common to make address spaces non-cancelable and the reasons for doing so are usually technically deep. ... or maybe the reasons are accidental becausesnip I can't speak for all software developers but I can tell you that those big-gun decisions are never made by accident. At least not by the major software vendors. There are too many folks looking over your shoulder and second guessing everything you do. Not unlike ibm-main in that respect :-) Again we have developer arrogance in not leaving it up to the user as to whether or not to allow the user to advise his/her operators over cancelling the address space by allowing CANCEL or NOCANCEL to be specified by means of the SCHEDxx member with a proper explanation of the advantages and disadvantages, including how they relate to the use of the AUTOLOG facility. We're just going to have to disagree over this. Giving users a choice between things they don't really understand isn't really being helpful to them. Even if the choice is elaborately documented you've added something extra that must be read and understood and actioned and most users don't read everything we give them as it is. If making that choice is of no consequence and it only adds a small amount of work for the user then ok I guess. But if making the wrong choice can lead to a system outage (or worse) why would you want to have the user make that choice? I would prefer that the software should do the right thing for me. You may consider it arrogant and that's fine with me. I have more than enough scars already. Note that the main CS IP address is one thing and, who knows? - well I don't but, of course, the developers do - it may well be that the tricks the main CS IP address space gets up to are the same or similar to those you described in your concrete example. Perhaps so and as you say, you don't know. Nor do I. BTW The tricks I was referring too aren't especially tricky. The garden variety things that server address spaces tend to do are likely to result in dependencies between the server space and its clients. If you blow away the server you're very likely to leave the clients in a damaged state. If it is necessary to allow for restart and recovery for such a server space, then the clean way is for the server to accept a STOP command. Upon receipt of that command the server's internal tasks are all still running normally and they can go on about the business of shutting down gracefully. If you use CANCEL or FORCE that's no longer possible. All of the server's tasks are summarily abended and all subsequent resource cleanup has to be co-ordinated through end of task and/or end of memory routines. Trust me when I tell you that accomplishing that is enormously more complex and risky. An impatient operator with an itchy trigger finger can ruin your whole day. If I'm responsible for providing that functionality then minimizing the risk of disaster seems to me not to be the arrogant thing to do, but rather the prudent thing to do. Why are we even debating this? I can imagine that there are a number of functions the main CS IP address space could perform which imply NOCANCEL is a good idea. However the TN3270E server is just a TCP application with potentially - not necessarily - a mass of definitions to process on starting. It was the time which some customer definition sets needed to get up and running that prompted the separation of the TN3270 sever application - as it should have
Re: CANCEL/FORCE ARM (Was: Really dumb IPL question)
On Sat, Oct 9, 2010 at 12:20 PM, Chris Mason chrisma...@belgacom.netwrote: Chris [1] Your presentation doesn't actually mention a SCHEDxx entry as an alternative to or override for a PPT entry - tut! tut!. Erm... tut me no tuts! PPT entries are defined in SCHEDxx. Erm. How about actually adding some value to the correction rather than merely highlighting an obvious contraction that became inaccurate as a consequence? What I should have said - as, grey beard that I believe you are, you should have seen instantly - is the following: Your presentation doesn't actually mention a SCHEDxx PPT entry as an alternative to or override for a PPT module entry. If you had taken a bit more trouble with your post, you might have offered something like this as the correction instead of just the sort of point-scoring beloved by Dr No - who has recently got himself taken of someone else's Christmas card list as well as confirming his absence from that of another of the usual suspects. I'm sorry. I wasn't trying to score points at all. I was just (unsuccessfully) attempting some humor in pointing out that (nowadays) PPT entries are made in SCHEDxx. The archaic IEFSDPPT module is still valid, but for all practical purposes it is unusable. And as it turns out, software vendors seldom use either one anyway. But you have managed some added value by pointing out that, in addition to being able *statically* to specify at least the CANCEL/NOCANCEL attribute, you can specify attribute(s?) *dynamically*. Unfortunately I can't quite follow whether this is an usual or an unusual step to take and hence how common a problem it might be. I would expect that because of the esoteric nature of the programming involved it would be lie on the *unusual* side. Software vendors in general have an aversion to anything that requires PARMLIB updates in order to install their products. And since there is a very simple brute force alternative in this case, that's what they will typically use. So your idea of having automation examine the PPT would likely yield no useful information for managing individual address spaces. The more fundamental question of what it really means to manage those address spaces is a can of worms I will leave unopened. What this means for automation is that, in preparing to support the management of any particular program's address space, having found no MODIFY,(shutdown) or STOP option, you might well discover the appropriate way to manage shutting the program down is CANCEL or FORCE ARM by checking the IEFSDPPT module and the planned SCHEDxx member. However at the absolutely unavoidable testing stage, you might find that the developer has played the tricky card of setting NOCANCEL dynamically - or, there being no limit to tricky programming or programmers, of resetting to CANCEL! You're probably missing the point of what I meant when I wrote... Note that if an address space is marked non-cancelable, there's usually a good reason. I meant that there is usually a sound technical reason why the address space needs to be that way and you probably ought not assume otherwise. The developer who passed the requirement on to the developers managing the IEFSDPPT module for a particular release of these days z/OS may have ***imagined*** he - or she, the female of the species is equally likely to get it wrong - was asking them to set up the NOCANCEL bit for a good reason. There is no guarantee whatsoever at all in this world that he or she actually understood what he or she was doing. It may be a good idea to set the requirement in stone in the IEFSDPPT module or it may not. It may actually have been better to have the possibility documented in the appropriate manual as a specification in the SCHEDxx PPT entry and actually - shock, horror! - let the user - belonging to the organisation actually *paying* for the product - decide.[3] I am kind of offended at the idea that the developer had no idea what he/she was doing. At least the developer knows what is going on inside the product. The user's OPINION on whether or not an address space should be non-cancelable is irrelevant and is another reason why the vendor is likely to avoid using SCHEDxx or IEFSDPPT. It is not very common to make address spaces non-cancelable and the reasons for doing so are usually technically deep. It is generally done for your own safety, not just because software developers are lazy or have an inflated idea of the importance of their product. For a concrete example, if you have a server address space that owns common storage and cross memory resources and provides services to other address spaces, then abruptly terminating that address space (either via CANCEL or FORCE) could be quite disastrous. You can have an arbitrarily large number of units of work in various states in other address spaces that are suddenly left pointing into the ozone. The process of removing
Re: CANCEL/FORCE ARM (Was: Really dumb IPL question)
On Wed, Oct 6, 2010 at 9:45 PM, Chris Mason chrisma...@belgacom.net wrote: Edward I detect some failure properly to make an effort to understand the point *I* was trying to make! snip [1] Your presentation doesn't actually mention a SCHEDxx entry as an alternative to or override for a PPT entry - tut! tut!. Erm... tut me no tuts! PPT entries are defined in SCHEDxx. In any case I submit for your amusement and reading pleasure the following brute-force alternative that doesn't require a PPT entry at all. It assumes certain things about the environment and current state that I won't bother to enumerate but suffice to say this, or something close to it is far more likely to be used by the ISV cognoscente. So the idea of rattling through the PPT would likely leave non-cancelable ISV products undiscovered. L R1,PSATOLD - Current TCB USING TCB,R1 TCB map ICM R1,7,TCBJSCBB - JSCB USING IEZJSCB,R1 JSCB map L R1,JSCBCSCB - Current CSCB USING CHAIN,R1 Map CSCB NICHACT,255-CHCL Mark this STC non-cancelable (there's another bit elsewhere that makes the address space non-forceable too, but I probably shouldn't elaborate on that) Note that if an address space is marked non-cancelable, there's usually a good reason. Issuing FORCE (with or without ARM) against an address space in that condition should rightly be seen as loading the gun and aiming it at your foot. If you're lucky you'll miss. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TESTAUTH in XMEM PASN |= SASN
Does anyone know if TESTAUTH runs in XMEM mode PASN not equal SASN No it does not. You have to be in primary asc mode and with PASN=SASN=HASN -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where is APF documented?
Tom, Chuck and Ed wrote: On 9/9/2010 4:35 PM, Chris Craddock wrote: yeah I know, I just didn't feel like going off on one of my normal rants about integrity exposures. It seems like nobody listens anyway. and on 9/15/2010 Ed Jaffe wrote: Some of us do... :-) Yep. When Chris speaks I listen. Usually it is entertaining and sometimes even educational. Ha! The posts that Chris makes are usually educational. Sometimes they are also entertaining. http://bama.ua.edu/archives/ibm-main.html aw shucks, educational AND occasionally entertaining! Thanks guys. :-) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where is APF documented?
On Thu, Sep 9, 2010 at 8:39 AM, Charles Mills charl...@mcn.org wrote: Yeah, it's documented bottom-up and in the wrong place. APF is not an authorized assembler service. APF authorization is in the realm of operations and security, not assembler programming. Sure, it impacts assembler programs and programmers, but it also impacts COBOL and Rexx programs. Catalog management affects assembler programs, but it's not documented with the GET macro. what little documentation there is is older than Methuselah's tomcat and you have to be schooled in interpreting the arcane way things are described. Be thankful for what exists. APF is a facility for identifying certain load libraries to z/OS. If an executable program is (1) stored in an APF-authorized library and (2) link-edited with AC(1) then it is said to be APF-authorized. Keep in mind that APF authorization is an attribute of a running job step. A job step becomes APF authorized if and only if the job step program is linked AC(1) *and* is loaded from a dataset in the APF list. If the job step is APF authorized then the job step task and all of its subtasks are considered authorized. Otherwise none of the tasks are authorized. As an untrusted programmer can freely link edit or bind a program with AC(1), an installation can only protect these privileged facilities by using RACF or another security subsystem to control the ability to store programs into APF-authorized libraries, and also the ability to APF-authorize a load library. True. One point to note is that the AC attribute has no effect whatsoever on programs that are not job step programs, but I'd like a dollar for every loadlibrary that has AC(1) sprayed around like confetti. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where is APF documented?
On Thu, Sep 9, 2010 at 3:39 PM, Tony Harminc t...@harminc.net wrote: On 9 September 2010 12:39, Chris Craddock crashlu...@gmail.com wrote: ... I'd like a dollar for every loadlibrary that has AC(1) sprayed around like confetti... snip Every one of those wished-for dollars is a potential exposure. http://bama.ua.edu/archives/ibm-main.html yeah I know, I just didn't feel like going off on one of my normal rants about integrity exposures. It seems like nobody listens anyway. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NO RESPONSE RECEIVED
In response to Charles, Rob Scott said: What SDSF is doing here is using the MGCRE service with the CART parameter (the CART is the command response token) to send the operator command to an EMCS console. The expectation in most cases is that the code that eventually executes in whatever ASID because of the operator command looks at the CIB and sees that there is a CART present and then uses the CART=CIBXCART specification on the WTOs that writes messages containing the operator command response. This allows the EMCS that SDSF has established to wake up and get the message(s). Not all software products use CARTs on their WTOs and there may be architectural reasons why some base z/OS components do not use CARTs either. To cater for this, SDSF must establish a timer so it can give up waiting - hence the setting in the SDSF options. 'es a bright lad is our Rob! Spot on. However, whether or not you see the NO RESPONSE message depends entirely on whether SDSF sees a response before that timeout occurs. So if the system is busy and/or your command takes a while to process, you may get this even when you're doing everything right with respect to the CART. BTDTGTS. As an aside, if you have more than one line of data to return in the command response you'll have to use the multi-line WTO option. Miraculously, it does work and SDSF faithfully horks up the entire multi-line response which makes it a lot easier to see which message parts belong with which responses. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where doc for STORAGE LINKAGE=SYSTEM
On Wed, Sep 1, 2010 at 8:56 AM, Charles Mills charl...@mcn.org wrote: Wow, is this all confusing. (And yes, I imagine maintaining the source -- two sources, assembler and PL/S, right? -- for GETMAIN is even more confusing.) So STORAGE is just GETMAIN in disguise. I knew it provided the same sort of functionality, but with notes here and there seeming to encourage the use of STORAGE instead, I thought it was somehow fundamentally better. well kind of better. It is more accurate to say that STORAGE (the PC version) and GETMAIN (the various SVC and branch-entry versions) end up going to the same place, albeit with different front-end logic along the way. STORAGE is (IMO) better than GETMAIN because it is easier to use and more tolerant of the caller's environmental conditions. But even though the stacking PC is much faster than the SVC FLISH/SLIH, STORAGE is actually slightly slower than GETMAIN because the STORAGE PC front-end does a lot more validation precisely because it IS more tolerant. If you're just writing plain old problem state code there's no advantage unless you are also running in AR mode (supported by STORAGE, but not by any of the forms of GETMAIN) However, if you're writing code that runs in the dark and scary places then STORAGE is a way better deal. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: memory/address sharing in batch mode
On Thu, Jul 29, 2010 at 1:39 AM, Edward Jaffe edja...@phoenixsoftware.comwrote: Amlan Prasad wrote: hi, Has anyone come across or heard of or actually worked on technical design in mainframe where memory/address/data can be passed or shared in parallel by two different jobs? Yes. We do this with shared 64-bit virtual storage obtained via IARV64 REQUEST=GETSHARED and IARV64 REQUEST=SHAREMEMOBJ. You can also share 31-bit storage via IARVSERV, but we don't have any code doing that. There is also the USS implementation of UNIX shared memory (shmget(), shmat() etc) which might be easier to deal with, depending on the OP's programming skills -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Split OMVS file
On Thu, Jul 29, 2010 at 11:03 AM, Mark Steely mark.ste...@wnco.com wrote: I have a ZFS file which is larger than a 3390 mod 2 volume. I would like to split this file to fit on 2 3390 mod 2 volumes. What would the best way to do this. We are z/OS V1R11. Any help would be appreciated. Just make a bigger volume? Seriously, most USB memory sticks are way bigger :-) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another reason to hate PDSE's
PDSEs have only one advantage: snip Well, they do have at least one other advantage: they can store program objects, which allows entry points with long, case-sensitive names, which is sometimes handy. http://bama.ua.edu/archives/ibm-main.html No not really. Longer names may be contained within the program object, e.g. CALL someverylongname and the binder will make sense of it. External entrypoints (those that could be used by ATTACH, LINK etc.) are still only 8 bytes long. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IEFU83, IEFU84 and IEFU85
On Fri, Jul 16, 2010 at 12:10 PM, Rick Fochtman rfocht...@ync.net wrote: Ben, that's very sound advice, but the exit writeing person MUST be aware of any restrictions in the invoking environment. One example: you WILL use the branch entry to WTO if you need to write messages to the operator from IEFU84. Research and careful planning are mandatory, expecially in this particular exit. http://bama.ua.edu/archives/ibm-main.html Actually Rick, that's very sound advice for ALL exits. :-) -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Did a mainframe glitch trigger DBS Bank outage?
On Tue, Jul 13, 2010 at 10:01 AM, Hal Merritt hmerr...@jackhenry.comwrote: For the opening shot in this, I'd argue: yes. While no system can ever be totally idiot proof, human intervention can be counted on as a failure mode. Besides, it should have taken more than one idiot to do the job. :-) just when you think you've created a fool-proof system, the universe will deliver you a superior class of fool human error (both configuration goofs and operational errors) is THE overwhelming cause of system problems these days. Add in application bugs and you've pretty much covered the field. Even the squatty boxes rarely if ever fail these days. People on the other hand... -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is there any kind of system exit taken when an RB ends?
On Mon, Jul 12, 2010 at 4:52 AM, Binyamin Dissen bdis...@dissensoftware.com wrote: Say I would like to get control when a specific PRB ends (while the TCB remains). Are my choices to either poll or modify the return PSW? There is no system service or exit that (directly) does what you want. You can however use a directed SCHEDIRB to plant an IRB between the RB you want to monitor and the one that it was going to return to. Is it worth going to that amount of effort? -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ENQ trap for dynamic allocation
Perhaps I'm missing something here, but couldn't this be nicely done in IEFDB401? Some code would be necessary to rattle through the dynamic allocation parameter list, but on an allocation request, find the DSN (if present) and DISP (if present) and then, do the actual ENQ on SYSDSN (whatever). If you get it, DEQ and proceed, otherwise use the logic you presently have. Testing can I get the resource by obtaining and then releasing it doesn't do anything productive, but it DOES drive up resource contention and overhead. The problem with any such approach is that the state of the resource is quite likely to be different the moment you release it, so a subsequent attempt to obtain it would block anyway. There IS a conditional form of ENQ you can use if you don't want to become trapped in amber while some paleolithic production job runs all day. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ECB parameter on attach
On Mon, Jul 5, 2010 at 10:48 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Mon, 5 Jul 2010 08:48:38 -0600, Robert Raicer wrote: You have it just about right. When the sole remaining RB for the TCB issues SVC-3 (EXIT), End of Task processing begins. This causes RTM Does an RB issue SVC-3, or is it the task the RB dispatches that issues SVC-3? All programs run under the control of an RB (there are several varieties of RB, but their differences are irrelevant as far as this discussion goes). RB's are queued on a TCB so it's a bit of a semantic nit to ask whether it is the task or the RB doing the thing. To be precise, the program that is currently running on the TCB (whether it's actually dispatched or not) is running under the control of the current RB. There may or may not be older (suspended) RBs chained up behind it. Each of those will in turn regain control when the RB ahead of it issues SVC 3. And as a piece of syntactic candy, z/OS and its ancestors always arrange it so that on entry to a new RB R14 contains the address of CVTEXIT, which in turn contains X'0A03' which is (drum roll please) SVC 3. So the program can exit by saving the address in R14 and returning there just like any other program, or it can simply issue SVC 3. Does the RB remain once it has caused the task to be dispatched? I would have exepected it would be removed from the queue; deleted. The RB remains in control until either; it completes its processing and issues SVC 3, or it is suspended and replaced by another RB, e.g. via a LINK macro. In the latter case the RB will remain suspended until all of the RBs ahead of it have terminated via SVC 3. The RB is basically (part of) the place where the system saves state when it needs to run another program, e.g. when the current RB issues a LINK macro. Would it be clearer to say that When a task issues SCV-3 and no undispatched RBs remain on its queue ...? not really. The task terminates when the last remaining RB issues SVC 3. By definition there cannot be any undispatched RBs remaining on the queue. RTM will take care of that behind the scenes for a task that manages to abend itself into oblivion. What happens if a task issues SVC-3 while further RBs remain queued? What SVC 3 really does is terminate the current RB and returns control to the previous RB, so basically nothing special happens, the previous RB resumes execution. It is only when there are NO remaining RBs that the task gets driven through EOT. My uncertainty about the SVC number arose when I was unable to find EXIT in z/OS V1R10.0 MVS Assembler Services Reference ABE-HSP. Is there no actual service with this name? Correct, there is no actual service with the name EXIT. Never has been. Amazing huh? When the ATTACHed module is initially entered, GPR 14 contains the address to which it is to branch upon its completion, i.e., this is the Return Address. While not part of the documented programming interface, this address is generally the address of an SVC 3 instruction contained in the CVT (field CVTEXIT). Are you saying that it is unsupported for a module entered by ATTACH to exit via R14? Or merely that it is not guaranteed that a module can CLC 0(2,14),=x'0A03' to determine that it was entered by ATTACH? http://bama.ua.edu/archives/ibm-main.html No you cannot determine whether you were entered via ATTACH (at least not in that way). R14 will point to CVTEXIT on initial dispatch after an ATTACH, but it will also contain that value on entry for a SYNCH, or a LINK or a XCTL macro and also, in the case where an IRB is scheduled to the task. The interface for SVCs that have RBs (type 2, 3 and 4) is more complicated. The net of it all is, if you needed to know the circumstances in which you were exiting, you could usually determine it programmatically but not by making the above mentioned comparison. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is Commuication ECB valid for subtask
:In other words Can the communication ECB be posted in the subtasks as well I wouldn't think so a it is in key0 storage, but as there is bypass code for wait perhaps there is also bypass code for post. The communications ECB is indeed in key 0 storage, but the system recognizes attempts to wait on that specific ECB and treats it as a special case. It allows any task in the address space to wait on the stop/modify ECB. The stop/modify function would not be terribly useful otherwise. Only one task can wait on it. True. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linklst; 6 of 1/half dozen of the other?
On Mon, Jun 14, 2010 at 4:04 PM, McKown, John john.mck...@healthmarkets.com wrote: I don't like versions in LNKLST datasets. I have no problem with them in maintenance or steplibs. But, regardless of the HLQ, they should not have versioning in the production environment, IMO. I agree with you about versions. My manager, OTOH, totally disagrees. So we do it his way. And we put the OEM products in the LNKLST so that the version numbers are hidden from the users. It is mostly a religious issue, but for some products there are practical considerations. If you have (for example) something that starts really early during IPL processing you have a fairly limited set of choices. Now in fairness, there aren't too many such products, but it always pays to read the fine print. Every once in a while when the vendor says they need it to be a particular way they're right and a one size fits all approach will lead to tears. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Vendor Watch: zNext or z11? Either Way, It's Coming Soon!
On Tue, May 25, 2010 at 12:31 PM, McKown, John john.mck...@healthmarkets.com wrote: Depends. What are they running? How do they measure up time? We are still stuck in the 1970s for all intents and purposes. We run CICS with VSAM. No RDMS. No Websphere. 100% COBOL. We do run some 3270 screen scraping and even have a few CICS web like transactions via HTTP. But we have a lot of night down-time for running batch reports and updates against the CICS VSAM files. This is on CICS/TS 3.2, z/OS 1.10, and a z9BC. Our legacy applications are old, old, old. http://bama.ua.edu/archives/ibm-main.html I laughingly refer to this as running in 1985 compatibility mode and pretty much all but the top tier of customers still run that way. There's a huge gulf between what the platform is capable of and what people actually do with it. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LINK Question (SRB Mode?)
On Thu, May 20, 2010 at 2:15 PM, Art Celestini spamb...@celestini.comwrote: A colleague has written me about a set of circumstances he is observing: Program “A” is authorized, running in Key 7, TCB mode, and issues a LINK for Program “B”. When Program “B” gets control, it finds PSATOLD=0 and PSASRBM=04. Program “A’s” state was verified with a S0C1 just before the LINK, and Program “B’s” state verified with a S0C1 at entry. How could LINK possibly give the target program control in SRB Mode? Offhand, I don’t know the z/OS release he is running on but I expect it would be at least 1.8. First, let's be clear there is no possible connection whatsoever between issuing a LINK macro and finding yourself running under an SRB. LINK is a task-mode-only function and does not result in the transfer of control to another unit of work. So just abandon that idea altogether. It isn't an APAR-able IBM bug, or some alien conspiracy. I don't care what z/OS release it is, I would guarantee sight unseen that it has NOTHING to do with a bug in the dispatcher. The world as we know it would end if that were ever true. One of two things is true. First, assuming the SRB-mode condition is accurately reported, then the only explanation is that some other unit of work (directly or indirectly) scheduled Program B as an SRB. Any temporal relationship to the LINK macro also being issued for Program B is coincidental. The second (and I believe more likely) case is that the environmental conditions are just not accurately being reported. Program B is getting control under a new PRB in the same task that issued the LINK just like it has since the beginning of time. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: *MASTER* ... again
On Wed, May 12, 2010 at 8:31 AM, Shane Ginnane ibm-m...@tpg.com.au wrote: mounts hobbyhorse As has been discussed here before, seems every half-baked software developer (and more than a few fully baked ones) seem to think ASID 1 is the perfect place to drop a long lived RB rather than make it obvious to the customer what is happening. Couldn't possibly cause a problem ... as has been re-iterated here incessantly. /mounts hobbyhorse Shane ... On Wed, May 12th, 2010 at 11:16 PM, Mark Zelden wrote: Do you have any tso app running under master? (perhaps an automation product or TSSO)? Ok, while you're dismounted... let's all take a nice deep breath and relax. For those who don't know; Running UNDER the master subsystem (i.e. START YOURSTCNAME,SUB=MSTR) has nothing whatsoever to do with running IN the master address space. There are perfectly sound reasons why a product (especially an automation or monitoring product) would NEED to run that way - usually because the product needs to run during the IPL/startup phase before the JES is up and fully functional, or it needs to run during/after JES termination during system shutdown. It ought to be pretty obvious that running under the default (SUB=JES) isn't even viable for things like that. And while you're pondering that one, consider for a moment that every single SSI and RESMGR end-of-memory exit actually DOES run in the master address space. The great grubby and unwashed masses of systems software products use those capabilities utterly routinely and yet the world does not tilt off its axis. And there are other things that run there too. I'm not advocating that people become cavalier about running in master, but seriously that's how the system has worked, literally forever. So chill already. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Accessing Cross Memory Storage in REXX
On Wed, May 12, 2010 at 12:28 PM, Rick Fochtman rfocht...@ync.net wrote: -snip- Notice that I said Legal. Nothing else is supported by the z/OS software architecture - regardless of whether something else is possible under the hardware architecture. Any grinning idiot with an APF library can study PoPs and contrive ways of gaining addressability to some other address space, but since z/OS doesn't know (or allow!) what you would be doing, the results are most kindly described as unpredictable. unsnip- Chris, I don't think the various z/OS routines invoked by PC are scheduling SRB's just to fetch their parameter lists. I'm sure there are other mechanisms, perhaps using MVCS/MVCP, that are more efficient than just scheduling a Global SRB. Perhaps some of our friends at IBM can provide some enlightenment. I notice that in some areas, PC is replacing SVC to invoke a service; about time!. SVC's are incredibly slow, because of the interrupt processing overhead, both software and hardware. I've even seen systems that use a BAL to a specific low storage address that ran MUCH faster than equivalent SVC functions. While I agree that coding technique have MUCH to do with efficiency, in this particular instance, hardware functions much also play a significant role. Space-switching PC routines don't need to invoke SRBs to access parameter data in their caller's address space because addressability to the primary (PC-server) address space is established by the PC instruction and addressability to SASN and HASN are automatically available. The mechanisms needed to manage that cross-memory environment are formally established and managed by z/OS cross-memory services, so it is all legal. What ISN'T legal is any variation of the common techniques for bypassing formal xmem interfaces and snooping into another address space by doing SSAR or ALESERV ADD,CHECKEAX=NO. (Aside: the fact that the CHECKEAX option is documented does not mean you're supposed to use it. It was intended for internal use and it escaped.) As I said already, the only legal way to poke around in another address space (without going to cross memory services) is to schedule an SRB into the desired address space. It is true that people have exploited the hardware architecture to avoid doing the right thing, but that isn't supported by z/OS and the results of doing that are (believe it or not) very likely to be dangerous. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Accessing Cross Memory Storage in REXX
On Tue, May 11, 2010 at 9:52 AM, Ray Overby rayove...@comcast.net wrote: My understanding is if the target address space is non-swappable then you can safely use non-srb code to obtain access to the other address space's private area. I believe the unpredictability comes when the target address spaces are swappable. Depending upon your application requirements non-srb code may in fact work. For example, address spaces with a system LX that support space switch pc routines will always be non-swappable. If your application required data from these address spaces you should be ok. There are other address spaces that normally run non-swappable. However, you could not access all address spaces with this technique. For swappable address spaces you should use SRB code. As usual, it depends upon your application. Non-swappability is necessary but not sufficient. For example, the application running in address space with ASID=26 could terminate while you're looking at it and be replaced by another application running in the same ASID because z/OS likes to reuse ASIDs. There is anti-aliasing support on z10 systems and (I think) some z9s, but that's yet another detail where you'd be shooting in the dark. If you were playing by the rules and the target address space was a cross-memory resource owner, the system would not reuse the ASID - which is why you have to follow the rules. You might get away with it for a long time, but sooner or later you'll get bitten and the results might be ugly. The fact is, the z/OS cross-memory architecture was never designed to support establishing addressability between address spaces where the target address space is not officially designated as a cross-memory resource owner - all of which is done under the covers by the PCAUTH address space when you set up your linkage indexes and PC entry tables. As many people have discovered, the hardware has no such restriction on cross-memory addressability because it is designed to support a variety of software architectures, not all of which may be supported by a given operating system. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Accessing Cross Memory Storage in REXX
On Mon, May 10, 2010 at 4:37 PM, Rick Fochtman rfocht...@ync.net wrote: -snip Highly unlikely unless I'm missing something obvious. The only LEGAL way to access memory in some other address space is via an SRB. You need to be in sup state and key zero to schedule an SRB and REXX runs key 8 and problem state. But if we're allowed to cheat then I'll play :-) PS I didn't know there were any mainframe people at Queens... ---unsnip--- Not strictly true, but the mechanisms are NOT for the meek! I've found other ways but in the interests of safety, I'll not share them. Notice that I said Legal. Nothing else is supported by the z/OS software architecture - regardless of whether something else is possible under the hardware architecture. Any grinning idiot with an APF library can study PoPs and contrive ways of gaining addressability to some other address space, but since z/OS doesn't know (or allow!) what you would be doing, the results are most kindly described as unpredictable. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Accessing Cross Memory Storage in REXX
On Sun, May 9, 2010 at 9:16 PM, Lorne Dudley dudl...@queensu.ca wrote: The October 2001 issue of the Xephon MVS Update 181 contained REXX Cross Memory assembler subroutine code allowing access to information in other memory spaces by ASID. I was never able to get this to operate properly. Has anyone had any success with this or do you have some equivalent code that you can share ??? Highly unlikely unless I'm missing something obvious. The only LEGAL way to access memory in some other address space is via an SRB. You need to be in sup state and key zero to schedule an SRB and REXX runs key 8 and problem state. But if we're allowed to cheat then I'll play :-) PS I didn't know there were any mainframe people at Queens... -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Pause Elements
On Fri, May 7, 2010 at 2:13 PM, Blaicher, Chris chris_blaic...@bmc.comwrote: I have a TCB and a SRB process and want to suspend one and let the other proceed and then reverse it and do that over and over. The following pseudo code assumes knowledge of IEAVAPE/IEAVPSE/IEAVXFR/IEAVRLS/IEAVDPE: TCB: Allocate a PE for the TCB Start a SRB Wait for SRB to init SRB: Allocate a PE for SRB POST TCB's WAIT PAUSE the SRB TAG1- Do some work XFER to the SRB Do some work XFER to TCB If more to do Loop to TAG1 ELSE Release the SRB indicate stop WAIT for SRB to post Free SRB PE POST TCB's WAIT Return Free TCB PE Return Another way to do this is just schedule an SRB for each time I want to do some work, but using IEAVXFR is supposed to be a lot less expensive. I can get it to do it once, but after that it gets all balled up. The manual does not cover this in their examples. http://bama.ua.edu/archives/ibm-main.html Been there done that and you have the source code in-house to go peer at. Take a look at the RTCS source code. Most of what you need to know is inside OSZTASK and OSZNOTFY (which both work in SRB mode btw). I'm guessing you're missing the point that you get a new pause token when you come out the other side of PAUSE and that new token has to be conveyed (somehow) to the other UOWs that will subsequently attempt to call RELEASE. And if there's any possibility of a race condition between posters (callers of RELEASE) you have to make allowance for that. Call me if you get stuck. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how big is big?
On Wed, Apr 28, 2010 at 12:58 PM, Kirk Talman rkueb...@tsys.com wrote: what is the size (in mips?) are the datacenters or companies that it takes to make the 1st, 2nd ... quintile? Is that published? well if you figure on a single z10-EC engine being O(1K) old fashioned meaningless thingies and then do the math you come up with a number that is O(bloody big). -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Calling unauthorized code from an authorized address space
On Sat, Apr 24, 2010 at 2:17 PM, Binyamin Dissen bdis...@dissensoftware.com wrote: : There is no way to dance around it or pretend :otherwise. The only way you could avoid the exposure would be to guarantee :that no authorized code code could ever run within the address space after :you have allowed the unauthorized code to run. There is no way to guarantee :that in general and in any case, it would effectively eliminate the value of :that address space as a server for hosting this function. Why this requirement? It is fairly clear that it is a requirement for the OP's proposed application - else why bother with the elaborate schemes to temporarily remove authorization? He wants to run his authorized code and his client's unauthorized exit code within the same address space, presumably without restarting his server address space each time he gets a new client request. And since that can't be done safely, there's no point. The only case that leaves open is a garden variety key 8 APF authorized :address space. If you turn off JSCBAUTH before invoking the unauthorized :code, then it is true that code would NOT be able to MODESET to a system key :or get into supervisor state while it is running, however that isn't the :only exposure. While they are running, they can easily diddle with the data :belonging to the other tasks providing the privileged application :functionality in that space. Most of the system owned data areas will be key :0, 1 or 5 (and thus whey would be safe) but most of the areas owned by the :worker tasks will be in key 8. All of those areas would be susceptible to :modification by your unauthorized code when it runs. If such a modification :occurred and ANY privileged code continued to run, their data would :potentially be invalid and that is an integrity violation in and of itself. :Beyond that, a little creativity would get your unauthorized code back in :control in a privileged condition - thus violating integrity. Why must the authorized work areas be in key 8? It isn't that they MUST be. Merely that the (initially APF-authorized) application running within the address space WILL get key 8 storage for every task or step-owned low private subpool allocation UNLESS it goes out of its way to run in a system key and use only key-selectable subpools (kind of an odd exercise given they chose not to have a system key assigned via PPT, but I'll play along). However, even if it did attempt to avoid using task-key storage there would still potentially be an unknowable number of task or step owned data areas laying around in key 8. That's the deal breaker. If you let unauthorized code run within that same address space, you cannot guarantee that the unauthorized code won't be able inspect or modify the authorized application's data. In fact, it is guaranteed that the unauthorized code could do exactly that, which is by definition an integrity exposure just on its own merit. But even worse, if any of the APF application's tasks had already switched to supervisor state and continued to run during or after when the unauthorized code had been allowed to run, then there's a very high likelihood that the unauthorized code could fool that supervisor state code into violating integrity. You could do it. I could do it. There just isn't any safe way to avoid that in general. There are too many moving parts in a typical address space and not all of those parts (e.g. home grown exits and/or ISV code) are going to be in on the secret of what's supposed to be going on. Disagree if you like but you would be flying in the face of literally decades of integrity studies. While we're at it, let's not forget that (again, unless the authorized application goes out of its way) the unauthorized code is going to get control with the security identity of the server where it is running (usually some sort of production ID) Of course, that can be handled too, but the number of things that have to go just right in order for the OP's idea to work out is enormous and it only takes one slip for the whole house of cards to fall down. :Removing authorization must therefore be a complete one-way trip :because other tasks in the address space may have already switched into :supervisor state and be running independently of your unauthorized code. I :am deadly serious about this. If you (knew enough to) do the thought :experiment you would soon realize that there is literally no way to prevent :these exposures. Abandon hope. False. : Abandon hope. It won't be easy. : Now a question about TCB creation. After control is returned from the : problem state program to the caller, it should be possible to see if it : ATTACHed any new TCBs. If new TCBs were created, I could abend the entire : process instead of flipping the JSCBAUTH bit back on. This would ensure : that when the user exit returned to the caller, none of the
