In <[EMAIL PROTECTED]>, on 06/27/2007
at 02:19 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>But, as discussed here recently, prohibiting read access doesn't prevent
>the allocation, and it might be more likely that a program that ABENDs on
>OPEN will exit abnormally without doing the FREE.
De
On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote:
>In <[EMAIL PROTECTED]>, on 06/27/2007
>
Time warp?
> at 02:19 PM, Paul Gilmartin said:
>
>>But, as discussed here recently, prohibiting read access doesn't prevent
>>the allocation, and it might be more likely that a program th
On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote:
On Mon, 7 Jan 2008 12:46:34 -0500, Shmuel Metz (Seymour J.) wrote:
In <[EMAIL PROTECTED]>, on 06/27/2007
Time warp?
at 02:19 PM, Paul Gilmartin said:
But, as discussed here recently, prohibiting read access doesn't
prevent
the allocat
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
>
>> //STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep '
>> //STEP2 EXEC PGM=IEFBR14,COND=(0,LE)
>> //SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB
>>
>> ... but RACF won't help you there.
>
>But the initiator might stop you as RMF has
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
>On Jan 7, 2008, at 12:32 PM, Paul Gilmartin wrote:
>> Take my remark as largely rhetorical. IIRC, I was rebutting a prior
>> post expressing a phobic delusion that if PARMLIB had UACC=READ, an
>> incompetently or maliciously crafted job might A
On Jan 8, 2008, at 7:21 AM, Paul Gilmartin wrote:
On Mon, 7 Jan 2008 20:30:53 -0600, Ed Gould wrote:
//STEP1 EXEC PGM=BPXBATCH,PARM='PGM /bin/sleep '
//STEP2 EXEC PGM=IEFBR14,COND=(0,LE)
//SYSUT99 DD DISP=OLD,DSN=SYS1.PARMLIB
... but RACF won't help you there.
But
>ever have "users" cruise your parmlib and then tell you how to tune the
>system? Solution: UACC(NONE).
I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSPROGs.
-
Too busy driving to stop for gas!
---
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL <[EMAIL PROTECTED]> wrote:
:>>ever have "users" cruise your parmlib and then tell you how to tune the
system? Solution: UACC(NONE).
:>I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSPROGs.
How much of PARMLI
>How much of PARMLIB cannot be detected by examining storage in a live system -
>not using APF or anything special?
>Security by obscurity is useless.
I (honestly) do not understand your point.
-
Too busy driving to stop for gas!
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL <[EMAIL PROTECTED]> wrote:
:>>ever have "users" cruise your parmlib and then tell you how to tune the
system? Solution: UACC(NONE).
:>I have yet to see a single member of PARMLIB that is any business of anybody
outside SYSP
On Thu, 21 Jun 2007 18:29:05 + Ted MacNEIL <[EMAIL PROTECTED]> wrote:
:>>How much of PARMLIB cannot be detected by examining storage in a live system
- not using APF or anything special?
:>>Security by obscurity is useless.
:>I (honestly) do not understand your point.
That by "securing" pa
>Binyamin Dissen wrote:
>> On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL <[EMAIL PROTECTED]>
wrote:
>>
>> :>>ever have "users" cruise your parmlib and then tell you how to tune
the system? Solution: >UACC(NONE).
>>
>> :>I have yet to see a single member of PARMLIB that is any business of
anybody o
>Funny how it's ok for SYSPROGs to cruise Applications and "tell" us what needs
>to be changed or how to tune our application
Funny how I haven't worked at a shop (for over 20 years) that allowed me to
"cruise" applications.
Record layouts also need to be protected.
-
Too busy driving to stop f
On Thu, 21 Jun 2007 14:58:28 -0400, Tom Savor wrote:
>Another pet-peave, why do companies buy tools, then SYSPROG decides that
>"only they" get to use it. Example: My customer has purchased
>CICS/Abend-Aid, but has only configured it for CICS dumps.
>None of the applicatioin dumps can access it
"Funny how it's ok for SYSPROGs to cruise Applications and "tell" us what
needs to be changed or how to tune our application (when we didn't ask
for their opinion), but it's not ok for us to cruise your PARMLIB
settings Never heard of a PARMLIB setting getting screwed-up by
looking at it. Un
On Thu, 21 Jun 2007 15:14:00 -0500, Robert Justice <[EMAIL PROTECTED]> wrote:
>"Funny how it's ok for SYSPROGs to cruise Applications and "tell" us what
>needs to be changed or how to tune our application (when we didn't ask
>for their opinion), but it's not ok for us to cruise your PARMLIB
>setti
[EMAIL PROTECTED] wrote:
Binyamin Dissen wrote:
On Thu, 21 Jun 2007 15:54:09 + Ted MacNEIL <[EMAIL PROTECTED]>
wrote:
:>>ever have "users" cruise your parmlib and then tell you how to tune
the system? Solution: >UACC(NONE).
:>I have yet to see a single member of PARMLIB that is any busin
he systems guy cannot
understand the application guy's point, that is
a problem.
From: Ted MacNEIL <[EMAIL PROTECTED]>
Reply-To: IBM Mainframe Discussion List
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: PARMLIB(s) (Was: how to list LE options)
Date: Thu, 21 Jun 2007 18:29:05 +
>How m
-
Funny how it's ok for SYSPROGs to cruise Applications and "tell" us what
needs to be changed or how to tune our application
---
In our shop, it was called "Quality Assurance Review" and we caught some
real how
- Original Message -
From: "Rick Fochtman" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To:
Sent: Friday, June 22, 2007 12:44 PM
Subject: Re: PARMLIB(s) (Was: how to list LE options)
-
Funny how it's ok f
In
<[EMAIL PROTECTED]>,
on 06/21/2007
at 02:58 PM, Tom Savor <[EMAIL PROTECTED]> said:
>Funny how it's ok for SYSPROGs to cruise Applications and "tell" us
>what needs to be changed or how to tune our application (when we
>didn't ask for their opinion), but it's not ok for us to cruise your
>PA
On Wed, 27 Jun 2007 09:13:09 -0300, Shmuel Metz (Seymour J.) wrote:
>
>>If your system security is setup properly, I can see no harm in
>>browsing anything on the system.
>
>One problem, which has been discussed here before, is users who
>allocate systems data sets and don't free them when they're
22 matches
Mail list logo
