Check out
http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieag400/autqna.htm
for more info on the topic of authorized qnames.
-Joe
Joe Gentile
z/OS GRS Lead
(845)435-2184 (T/L 295-2184)
jwgen...@us.ibm.com
o: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: QNAMEs (was: ENQ rname_addr description)
>
> On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
> >
> >> //STEP EXEC PGM=IEFBR14,COND=(0,LE)
> >> //FILE DDDISP=OLD,DSN=SYS1.LINKLIB (SYS1.**, ad lib.)
> >&
On Wed, 2 Sep 2015 08:30:49 -0500, John McKown wrote:
>
>Until the "mad sysprog" (present!) decides to stuff the person (note
>proper use of non-sexist pronoun) down the elevator shaft. ...
>
For gender inclusiveness, I sometimes use "(fe)malefactor".
On 2015-09-02, at 07:32, Vernooij, CP (ITO
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: 02 September, 2015 15:23
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: QNAMEs (was: ENQ rname_addr description)
On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote
On Wed, Sep 2, 2015 at 8:22 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
> >
> >> //STEP EXEC PGM=IEFBR14,COND=(0,LE)
> >> //FILE DDDISP=OLD,DSN=SYS1.LINKLIB (SYS1.**, ad lib.)
> >>
> >A JOB wit
On Wed, 2 Sep 2015 07:17:47 -0500, John McKown wrote:
>
>> //STEP EXEC PGM=IEFBR14,COND=(0,LE)
>> //FILE DDDISP=OLD,DSN=SYS1.LINKLIB (SYS1.**, ad lib.)
>>
>A JOB with that particular DSN in it with DISP=OLD will never run.
>SYS1.LINKLIB is share enqueued by both LLA and XCFAS on a
On Wed, Sep 2, 2015 at 7:05 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Tue, 1 Sep 2015 10:03:46 -0500, Walt Farrell wrote:
> >>>
> >>I can imagine a DoS attack in which an unauthorized user bogarts a
> QNAME/RNAME
> >>generally used by an authorized facility.
On Tue, 1 Sep 2015 10:03:46 -0500, Walt Farrell wrote:
>>>
>>I can imagine a DoS attack in which an unauthorized user bogarts a QNAME/RNAME
>>generally used by an authorized facility. But such contention could arise
>>entirely
>>among unauthorized users.
>
>Yes, contention could arise strictly be
>I can imagine a DoS attack in which an unauthorized user bogarts a
QNAME/RNAME
>generally used by an authorized facility.
And that is why use of non-authorized QNAMEs by an authorized caller is
poor form.
In some cases existing QNAMEs that are not SYSZ have been made
authorized-only (thus
-Original Message-
From: Walt Farrell
Sent: Tuesday, September 01, 2015 7:51 AM Newsgroups: bit.listserv.ibm-main
Subject: Re: ENQ rname_addr description
I believe it is true that ISGENQ restricts authorized callers to using only
authorized QNAMEs, gil. Use of unauthorized QNAMES by
On 1 September 2015 at 09:30, Joseph W Gentile wrote:
> Would it be better as "ISGENQ introduces new parameter checking to ensure
> that authorized callers use authorized qnames. As with ENQ/DEQ/RESERVE,
> ISGENQ fails requests from unauthorized callers specifying authorized
How about:
"ISGENQ i
On Tue, 1 Sep 2015 09:19:26 -0500, Paul Gilmartin wrote:
>On Tue, 1 Sep 2015 06:51:43 -0500, Walt Farrell wrote:
>>
>>I believe it is true that ISGENQ restricts authorized callers to using only
>>authorized QNAMEs, gil. Use of unauthorized QNAMES by authorized callers can
>>easily end up being
On Tue, 1 Sep 2015 06:51:43 -0500, Walt Farrell wrote:
>
>I believe it is true that ISGENQ restricts authorized callers to using only
>authorized QNAMEs, gil. Use of unauthorized QNAMES by authorized callers can
>easily end up being a system integrity issue, ...
>
I can imagine a DoS attack in wh
On Tue, 1 Sep 2015 05:46:14 -0700, Charles Mills wrote:
>Exactly.
>
>Hexadecimal is a way of describing the content of data, not a type of
>content. The phrase the documentation author was looking for was
>"unprintable character," but Peter's phrasing is superior.
>
Errr... Surely you don't want
Thanks for checking out ISGENQ! "ISGENQ includes parameter checking to
ensure that authorized callers use authorized qnames" is meant to refer to
the feature of ISGENQ which detects when authorized programs use an
unauthorized qname. Perhaps this could use some clearing up... Authorized
callers
mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Peter Hunkeler
Sent: Monday, August 31, 2015 11:18 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: AW: Re: ENQ rname_addr description
> The RNAME must be from 1 to 255 bytes long, and can contain any
> hexadecimal character from X'00' to
X&
On Mon, 31 Aug 2015 17:52:35 -0500, Paul Gilmartin wrote:
>On Mon, 31 Aug 2015 18:14:10 -0400, Joseph W Gentile wrote:
>
>>I think the description of RNAME= in the ISGENQ macro doc is more clear. I
>>could potentially use the wording in the last sentence "The RNAME must be
>>from 1 to 255 bytes
> The RNAME must be from 1 to 255 bytes long, and can contain any hexadecimal
> character from X'00' to
X'FF'.
To me a character is a character, thus a "hexadecimal character" would be one
of {C'a', ..., C'f', C'A', ..., C'F', C'0', ..., C'9' }. Why not "... 255 bytes
long, and can contain by
On Mon, 31 Aug 2015 18:14:10 -0400, Joseph W Gentile wrote:
>I think the description of RNAME= in the ISGENQ macro doc is more clear. I
>could potentially use the wording in the last sentence "The RNAME must be
>from 1 to 255 bytes long, and can contain any hexadecimal character from
>X'00' to
I think the description of RNAME= in the ISGENQ macro doc is more clear. I
could potentially use the wording in the last sentence "The RNAME must be
from 1 to 255 bytes long, and can contain any hexadecimal character from
X'00' to X'FF'" to update the ENQ rname_addr doc. What do you think? Also,
On 2015-08-26 12:31, Abe Kornelis wrote:
>
> I have always interpreted as "qualified by the qname", though I will
> gladly admit this is an inference not directly implied by the text
> itself, and therefore subject to discussion.
> (not intending to start one right now, though).
>
This seems amp
21 matches
Mail list logo
