I would expect that most ISVs (as well as IBM) have ways to do this themselves.
There are various issues to make this "shared area" customer friendly, which include format, integrity, serialization and persistence (possibly other considerations). The end user can currently taken care of that with a dataset, a DB2 table, CICS named counters, etc. Direct memory may be an optimization, and one can press IBM for an enhancement to allow problem state programs to do this, but I don't think the business case would get that many votes over other priorities. At any rate, assembler-list is the wrong forum for this discussion. On Tue, 7 Dec 2021 05:20:33 +0000 "Farley, Peter x23353" <[email protected]> wrote: :></rant> :>I don't know about anyone else, but I am really getting tired of these continuous calls from supposedly knowledgeable people to "invent your own PC or SVC to protect your global shared storage application solution and dont trust anyone or anything and if you do this your integrity is your own problem not ours". :> :>Why hasn't IBM or even some clever ISV supplied a pre-packaged, integral-part-of-the-operating-system solution to safely share and update global storage any way an application designer can imagine and easily usable from normal HLL application programs? Protected by standardized SAF security calls and all that is needed for real integrity. Why do we have to "roll our own" and "own the loss of integrity if you screw it up"? Why can't those who know more than we do provide the solution? :> :>This isn't rocket science, it's just programming, and IBM + ISV's have more programmers more intimately familiar with how to safely secure memory sharing than anyone else, so why aren't they doing it instead of foisting it onto us? :> :>DB2 does it for disk-resident data, why can't something like that (maybe not QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be provided for global memory? There are exabytes to be exploited!! Help us use them!! :><rant/> :> :>Peter :> :>-----Original Message----- :>From: IBM Mainframe Assembler List <[email protected]> On Behalf Of Gary Weinhold :>Sent: Monday, December 6, 2021 9:27 PM :>To: [email protected] :>Subject: Re: Is it possible to update CSA from an unauthorized user-key program? :> :>Assuming you could accomplish your objective, which appears to be :>user-key (8 or 9) storage updatable by any process running on the lpar, :>it would appear that not only is the information stored there not :>confidential, but its integrity is not important. You have no :>protection from any user-key program overlaying the storage with any :>value it wishes, whether purposely or accidentally. Even if you have a :>plan to restrict access to obtaining the address of this shared storage, :>accidental overlays could still occur, like buffer overruns. :> :>a) In general, key 0 memory that is not fetch protected can be read by :>any key 8 user :>b) By definition, key 8 users cannot update key 0 memory. :>c) Considering the restrictions, any value of key 0 to key 7 works for :>the macro :>d) That would break integrity rules. :> :>One method for updating the storage is to encapsulate the update routine :>in a PC or SVC, which includes a security check for whether the caller :>is authorized to update the value and determines the location of the :>memory itself (not trusting the caller to supply it). :> :> :> :>On 2021-12-06 7:13 p.m., Wendell Lovewell wrote: :>> Hello Listers, :>> :>> I'd like to be able to update a common storage area across all CICS and batch regions. I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it requires supervisor state and/or key 0-7. :>> :>> It seems that something like issuing a STORAGE macro similar to: :>> :>> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM :>> :>> ...from an authorized program would allocate the storage needed. But I don't know the rules for accessing it from "user-mode" (unauthorized, key 8) programs like a CICS application. :>> :>> a) Given the address of the storage obtained like that, can any user-mode program read that storage? :>> b) Could a user-mode program update that storage? :>> c) Should the KEY parameter be specified, and if so, what value should I use. Afaik it has to be 0-7 since User-key CSA was outlawed. :>> d) Am I correct that there isn't an IRAV64 option that will allow a user-mode program to update the storage? :>> :>> Thanks for your help! :>> :>> Wendell :>> :>> (Cross-posted to the CICS list.) -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
