Re: ICH13005I

2017-08-24 Thread Smith III, Phil (HPE Data Security (Voltage))
John Eells wrote: >Whether it's a bug or a doc error vs. a feature depends on exactly what >weirdness you saw and whether it's expectedly or unexpectedly weird. That's a >question for Level 2 or RACF-L. But as I understand it, some of the weird >things derive from commands against a class that

Re: ICH13005I

2017-08-23 Thread Smith III, Phil (HPE Data Security (Voltage))
John Eells wrote: >OK, not related to the problem for which we took the APARs. >Was the POSIT shared with another class? Weird Things Happen when you do that. That was my guess, and what led me to suggest they change it. But I don't know. Still seems like a bug, or at least a doc error, no?

Re: GSKSRVR trace

2017-08-22 Thread Smith III, Phil (HPE Data Security (Voltage))
Lester, Bob wrote: > Try GSK.SGSKSAMP? That's it! GSKWTR was already there-this is an IBM system, so who knows what was where and why. I copied it and it started! When I get off this call I'll tinker with the trace. Thanks 10**6!

Re: ICH13005I

2017-08-22 Thread Smith III, Phil (HPE Data Security (Voltage))
John Eells wrote: >Phil, there are plenty of people left on the RACF team in POK to read whatever >you send in. Good. >But may I ask what the POSIT was? There could be a relevant APAR or two. 019. P.S. Lizette, thanks - I meant to post to RACF-L as well originally, forgot! Have done so now.

ICH13005I

2017-08-22 Thread Smith III, Phil (HPE Data Security (Voltage))
A customer was getting: ICH13005I RESGROUP DOES NOT APPLY TO CDT CLASS ENTITIES; OPERAND IGNORED on an RDEFINE command. Some tinkering and a SWAG led me to ask him to change the POSIT, and the problem went away. Googling ICH13005I gets a grand total of 13 hits, none of them very helpful. The

Re: GSKSRVR trace

2017-08-22 Thread Smith III, Phil (HPE Data Security (Voltage))
Well, color me stumped yet again. I have no GSKSRVR member in any PROCLIB! What am I missing? (Yes, I know, "a GSKSRVR member"...) From: Smith III, Phil (HPE Data Security (Voltage)) Sent: Saturday, August 19, 2017 5:17 PM To: ibm-m...@bama.ua.edu Subject: RE: GSKSRVR trace Mike Schmu

Re: GSKSRVR trace

2017-08-19 Thread Smith III, Phil (HPE Data Security (Voltage))
Mike Schmutzok wrote: >I think you have to start the GSKSRVR first before starting the GSK writer. We >had to do an SSL trace per IBM's request and the following was the process >they gave to us. Note, this was for a CICS trace so your reply may be >different. Well, that would certainly make

GSKSRVR trace

2017-08-18 Thread Smith III, Phil (HPE Data Security (Voltage))
Ok, I'm hopelessly ignorant about z/OS tracing, so please don't laugh (too hard). I'm trying to follow the instructions on https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.gska100/sssl2dia1023728.htm to learn about SSL tracing. Yes, this is a test system. I copied

Re: Curse you, L-Soft!

2017-08-09 Thread Smith III, Phil (HPE Data Security (Voltage))
Gil, Contact me off-list if you haven't heard from me already (I have an email address for you but it may be old). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with

Re: "break" (was: Someone just too smart ...?)

2017-08-05 Thread Smith III, Phil (HPE Data Security (Voltage))
Paul Gilmartin said, in part: >A lot of that I'd do with SELECT and CALL. But partly I'm being compulsive >about >avoiding SIGNAL. And sometimes I force a terminal condition (such as NOVALUE) >to get the procedure call trace. (Continuing this Socratically, not really trying to convince anyone,

Re: "break" (was: Someone just too smart ...?)

2017-08-04 Thread Smith III, Phil (HPE Data Security (Voltage))
Paul Gilmartin wrote: >Rexx has no GOTO. "break" is LEAVE [control-variable] (and "continue is >ITERATE [control-variable]). I never use Rexx SIGNAL other than to force >an error; its side effects are dreadful. By "to force an error", do you mean "to say that something bad happened and end the

Re: Can I cause another user to refresh their ACEE?

2017-07-27 Thread Smith III, Phil (HPE Data Security (Voltage))
Bob Bridges wrote: >It's been a while, but I'm quite sure that at one installation at least I had >authority to issue a command that "refreshed" a user's ACEE so that the >changes I'd just made to his access would take place immediately without his >having to log off and on again. I had the

Re: IBM z14 Multilayered Encryption

2017-07-18 Thread Smith III, Phil (HPE Data Security (Voltage))
Greg Boyd wrote: >It depends on the application. If you are using IEBGENER to copy DSNA (clear >text) to DSNB, and DSNB is flagged as requiring encryption and key label KEYB >is associated with DSNB, then you must have write access to DSNB and read >access to KEYB. IEBGENER will complete

Re: IBM z14 Multilayered Encryption

2017-07-17 Thread Smith III, Phil (HPE Data Security (Voltage))
Timothy Sipples wrote: >Phil, I don't know anybody arguing against application-based encryption and >hashing. Certainly IBM is all in favor of that (also). Encryption facilities >have been available since the early 1970s, arguably -- certainly for a long >time. Application programmers have

Re: IBM z14 High-lights

2017-07-17 Thread Smith III, Phil (HPE Data Security (Voltage))
So virtual flash is essentially disk cache, using regular memory? (As a long-time VMer, I almost wrote "minidisk cache", but then realized that would be wrong :)) And it's managed at the HMC, not by the OS, so it differs from MDC that way, too. But the same basic concept. Makes TONS of sense!

Re: IBM z14

2017-07-17 Thread Smith III, Phil (HPE Data Security (Voltage))
When I specifically asked about this, I was told that if you did not have rights to both SAF profiles, you could not read the data set at all. Are you reading things that suggest this is not the case? Sure, access to two profiles is a bit more security than one—that is, it’s more likely that

Re: Sorting email addresses

2017-07-17 Thread Smith III, Phil (HPE Data Security (Voltage))
R.S. wrote: >Theoretically yes, but practically I have never met case-sensitive email >address, even the part before @ character. >Of course this is very subjective, limited, 22-years old observation, not a >rule. YMMV ;-) Seconded, except for the YMMV part. I'd submit that any domain that had