On Fri, Jun 7, 2019 at 12:15 PM Charles Mills <[email protected]> wrote:
> I am by no means an expert on this stuff. Whenever I have to touch my code > I have the MVS and PoOp manuals open, close at hand, and in some cases, > printed out and highlighted. > > > not fetch protected > > Not fetch protected has fallen way out of fashion! It is generally > considered a security no-no these days. Look at all of the recent MVS APAR > activity in that regard. In "version 1" of my product I buffered SMF > records in non-fetch-protected storage. What's the big deal? The data was > only there for a few seconds at most. It's not like SMF records have credit > card numbers in them or anything. Wrong! But no one ever complained. > Nonetheless, "version 2" moved the buffering to fetch-protected storage. I > don't know what MVSCPCMD does (I can guess!) but I suspect again it is "not > like it contains credit card numbers or anything" but who knows what some > bad guy find useful for a hack, or some customer will find offends their > sense of security? > > I don't have that subpool table in front of me but I assume you have > looked through it and considered every pool. > > Wouldn't running in supervisor state solve the PKM problem? (And I don't > have the PoOp open in front of me, so perhaps I am off base.) > I figure key 8 in private is fairly secure. This is not shared memory. Key 8 in common is stupid, of course. key 8 fetch protected seems silly because most user code runs in key 8, so it's like a locked door where everybody has a key. Yes, supervisor state allows any source key, regardless of PKM. I am trying to avoid running key 0 or supervisor state to the extent possible. In this case, most likely more overkill. If I could run entirely in key 8, problem state, by having the proper APF authorization, I would be happiest. I am really over optimising the code. But, then again, this is for my learning, not for "get something running now". So I am rewriting common instructions [ reg=min(reg,value) ] to use more "recent" instructions. Example: CLI REG,VALUE too high? JL LOWER no LHI REG,VALUE yes, set to max LOWER DS 0H with CLI REG,VALUE too high? LOCHIH REG,VALUE yes, load max > > Charles > > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of John McKown > Sent: Friday, June 7, 2019 9:58 AM > To: [email protected] > Subject: Re: dumb STORAGE OBTAIN question. > > On Fri, Jun 7, 2019 at 11:24 AM Charles Mills <[email protected]> wrote: > > > > Why is FIX=LONG unnecessary? > > > > Because SP 223 is already/always fixed? > > > > Ah, yes. I am going not so slowly crazy (co-worker is bothering me wanting > unnecessary changes to some production backups -- why on Friday I don't > know -- he's bored too.). I am not sure I really want to use 223 because > it is key 0 fetch protected. So I will need to either go key 0 to do some > moves, or use something like MVCK, MVCSK, or MVCOS. All of which would > require me to put key 0 into the PKM. Which I don't see any easy way to do > (No SETPKM function that I can see). Instead, I might just go with a > "weird" subpool like 230 (private high, user key, not fetch protected). Or, > as usual, I am probably over thinking this because the program doesn't > really interface with any other user code. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
