Re: AC (authorization code) change

a million paper > pushers ??. > > Jim Thomas > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf > Of Shmuel Metz (Seymour J.) > Sent: Sunday, April 17, 2011 1:30 PM > To: IBM-MAIN@bama.ua.edu > Subject: R

Re: AC (authorization code) change

r J.) Sent: Sunday, April 17, 2011 1:30 PM To: IBM-MAIN@bama.ua.edu Subject: Re: AC (authorization code) change In , on 04/12/2011 at 06:40 PM, john gilmore said: >What you judge prudential seems to me to be bureaucratic complication >that provides the inexperienced with the illusion of

Re: AC (authorization code) change

In , on 04/12/2011 at 06:40 PM, john gilmore said: >What you judge prudential seems to me to be bureaucratic complication >that provides the inexperienced with the illusion of security without >its substance; and you view my suggestion as irresponsible. Refusing to allow a novice to update an

Re: AC (authorization code) change

In , on 04/12/2011 at 01:43 PM, Scott Rowe said: >It is has AC=0 in my environment, and work fine, AFAIK. Your environment may not be the same as for the OP. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see We don't c

Re: AC (authorization code) change

On Mon, Apr 11, 2011 at 9:38 PM, Gibney, Dave wrote: > As to cynical, I only need look at some of the recent neophyte questions on these lists to realize just how far some outfits are out on the limb > asking with completely unprepared people to safeguard systems presumably > important enough

Re: AC (authorization code) change

Over the years many modules with unnnecessary AC=1 attributes have been changed to be AC=0. I thought the original post asserted that there was a problem when this module was not AC=1. Did anyone explain what that problem was? Obviously if it needs to do authorized things *and* if it can be a jo

Re: AC (authorization code) change

John, I do not in any way think that "arcane skills should be kept within the priesthood". What I do think is that one should not propose to a novice that he should just re-link a module with AC=1 when it has not been determined that that is even the problem. I imagine you would teach someone ho

Re: AC (authorization code) change

> What seems to have been missed in this whole discussion is that the module > in question isn't even the job step task program, it does not need AC=1, and > should not have the it's attributes changed. Scott is correct. DSNUTILS does not need to be link edited AC(1). Look elsewhere to solve the

Re: AC (authorization code) change

the generic notion that arcane skills should be kept within the priesthood; and that I suspect is where we differ crucially. John Gilmore Ashland, MA 01721-1817 USA > Date: Tue, 12 Apr 2011 10:39:17 -0400 > From: scott.r...@joann.com > Subject: Re: AC (authorization code) change >

Re: AC (authorization code) change

It is has AC=0 in my environment, and work fine, AFAIK. On Tue, Apr 12, 2011 at 12:20 PM, Shmuel Metz (Seymour J.) < shmuel+ibm-m...@patriot.net> wrote: > In , on 04/12/2011 >at 09:26 AM, Scott Rowe said: > > >What seems to have been missed in this whole discussion is that the > >module in q

Re: AC (authorization code) change

In , on 04/12/2011 at 09:26 AM, Scott Rowe said: >What seems to have been missed in this whole discussion is that the >module in question isn't even the job step task program, it does not >need AC=1, and should not have the it's attributes changed. Perhaps. Is it called with unprivileged link

Re: AC (authorization code) change

On 12 April 2011 11:46, Paul Gilmartin wrote: > On Tue, 12 Apr 2011 11:32:12 -0400, Tony Harminc wrote: >> >>This has been a fundamental ingredient in the preservation of MVS >>System Integrity from the very earliest days, and was a marked >>difference from what came to be called SVS. If every mod

Re: AC (authorization code) change

On Tue, 12 Apr 2011 11:32:12 -0400, Tony Harminc wrote: > >This has been a fundamental ingredient in the preservation of MVS >System Integrity from the very earliest days, and was a marked >difference from what came to be called SVS. If every module expecting >or willing to get control in an author

Re: AC (authorization code) change

On 12 April 2011 08:58, john gilmore wrote: > Peter Relson has had his say, and I am unconvinced by his flag waving: > irresponsible modifications of IBM or ISV modules have, I suppose, occurred > even in this OCO era; but they are about as likely as the impact craters of > that purple call fal

Re: AC (authorization code) change

John, I found your suggestion that one should just re-link the module in question rather irresponsible. It is not clear who you were replying to, so it would appear you are replying to the original poster. Suggesting that an apparent novice re-link a module is fraught with hazard, such actions h

Re: AC (authorization code) change

What seems to have been missed in this whole discussion is that the module in question isn't even the job step task program, it does not need AC=1, and should not have the it's attributes changed. On Tue, Apr 12, 2011 at 8:58 AM, john gilmore wrote: > Peter Relson has had his say, and I am unconv

Re: AC (authorization code) change

Peter Relson has had his say, and I am unconvinced by his flag waving: irresponsible modifications of IBM or ISV modules have, I suppose, occurred even in this OCO era; but they are about as likely as the impact craters of that purple call falling from the skies. John Gilmore Ashland, MA 01721-

Re: AC (authorization code) change

I'm with Dave Gibney. When was the last time you had an AC=1 attribute "lost"? Maybe it arrived incorrect, but more likely someone's actions incorrectly changed it. And if you can't track those actions, your system is at risk. For all I know, the copy of the module that is AC=0 isn't even the

Re: AC (authorization code) change

IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On > Behalf Of john gilmore > Sent: Monday, April 11, 2011 6:20 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: AC (authorization code) change > > Dave Gibney's anxieties about how a module that should be AC(1) came to >

Re: AC (authorization code) change

Dave Gibney's anxieties about how a module that should be AC(1) came to be shipped as something else are entirely understandable; but with more experience he will come to be more cynical. Modules designed only for a reentramt environment can lose that attribute; those that should be AC(1) can

Re: AC (authorization code) change

April 11, 2011 4:40 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: AC (authorization code) change > > On Mon, 11 Apr 2011 20:49:44 +, john gilmore wrote: > > >Why do you think you cannot relink these modules with AC(1)? The binder > accepts its outputs, load modules

Re: AC (authorization code) change

On Mon, 11 Apr 2011 20:49:44 +, john gilmore wrote: >Why do you think you cannot relink these modules with AC(1)? The binder >accepts its outputs, load modules or program objects, as inputs. The >operation is trivial. > ... Unless it was previously linked with the EDIT=NO option. -- gil

Re: AC (authorization code) change

Why do you think you cannot relink these modules with AC(1)? The binder accepts its outputs, load modules or program objects, as inputs. The operation is trivial. John Gilmore Ashland, MA 01721-1817 USA --