[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Weird error with class DATASET
From:       Jack Zukt <jzukt59 () GMAIL ! COM>
Date:       2024-05-02 14:59:30
Message-ID: CAMVc2uKyD4jKfjgos8-mp3fVdx69PgLQNjDXNGKtih_-EatkDQ () mail ! gmail ! com
[Download RAW message or body]

Hi Juan,
Thank you for your input.
That seems to be the way that we are running ours as well.
Regards
Jack


On Thu, 2 May 2024 at 14:35, Mautalen Juan Guillermo <jmautalen@anses.gov.ar>
wrote:

> Hi!
>
> For the record, in our case we use DFSMSrmm as TMS, and at RACF level we
> have TAPEVOL INACTIVE and NOTAPEDSN in effect. Protection on tape datasets
> is achieved using PARMLIB DEVSUPxx options (TAPEAUTHDSN and TAPEAUTHF1).
> This seems to be IBM suggestion, and everything is working fine.
>
> Juan G. Mautalen
>
> -----Mensaje original-----
> De: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> En nombre de Jack Zukt
> Enviado el: jueves, 2 de mayo de 2024 9:59
> Para: RACF-L@LISTSERV.UGA.EDU
> Asunto: Re: [RACF-L] Weird error with class DATASET
>
> CUIDADO: Este correo electrónico se originó fuera de la ANSES. No haga
> clic en enlaces / links, ni abra los adjuntos salvo que sepa que el
> contenido es seguro.
>
>
>
> Hi Bob,
> Thank you again for your help.
> I went back to the z/OS Security Server RACF Security Administrator's
> Guide manual.
> On Chapter 7. Protecting data sets on DASD and tape, it states:
>
> *Guideline:* When you use a tape management system, such as DFSMSrmm, do
> not enable the TAPEVOL class or the SETROPTS TAPEDSN function.
>
> The manual also states that the DEVSUPxx statement TAPEAUTHDSN=YES Enables
> RACF authorization checking in the DATASET class for tape data.
>
> As the SETROPTS CLASSACT(TAPEDSN) is used for tape datasets to be checked
> against profiles in the dataset class, it seems using the TAPEAUTHDSN=YES
> DEVSUPxx statement is akin to the same thing.
>
> English not being my natural language I may be interpreting this wrong.
> What do you think?
>
> Regards
> Jack
>
>
> On Thu, 2 May 2024 at 12:03, Jack Zukt <jzukt59@gmail.com> wrote:
>
> > Hi Bob,
> > Thank you for your input.
> > This job has ran been successfully running for quite some time now.
> > There were no changes to the environment nor to RACF. The only
> > difference (we think, as it is hard to check) is that this time a second
> tape was needed.
> > You are right, it is weird not having TAPEDSN active. I had not
> > noticed it myself until this problem came along. We are evaluating its
> activation.
> > Regards
> > Jack
> >
> >
> > On Wed, 1 May 2024 at 11:22, Robert S. Hansel
> > <R.Hansel@rshconsulting.com>
> > wrote:
> >
> >> Hi Jack,
> >>
> >> I've copied Radoslaw's and your posts to IBM-MAIN below to share it
> >> with the RACF-L community and as it may be relevant to this issue.
> >>
> >> It is unusual that this installation has activated tape protection
> >> using DEVSUPxx options instead of SETROPTS TAPEDSN. (See my survey of
> >> January
> >> 2016.) It is even more unusual to use tape for temporary datasets.
> >>
> >> Has this job previously used multiple tapes for its temporary dataset
> >> and did it run successfully in the past? Has anything changed since
> >> its last successful execution, such as activation of TEMPDSN?
> >>
> >> Regards, Bob
> >>
> >> Robert S. Hansel                       2024 IBM Champion
> >> Lead RACF Specialist
> >> RSH Consulting, Inc.
> >> 617-969-8211
> >> www.linkedin.com/in/roberthansel
> >> www.rshconsulting.com
> >> ---------------------------------------------------------------------
> >> -----
> >> Upcoming RSH RACF Training - WebEx
> >> - RACF Level I Administration - OCT 7-11, 2024
> >> - RACF Level II Administration - NOV 4-8, 2024
> >> - RACF Level III Admin, Audit, & Compliance - DEC 9-13, 2024
> >> - RACF - Securing z/OS UNIX  - SEPT 23-27, 2024
> >> - zSecure Admin - Basic Administration - May 7-10, 2024
> >>
> >> ---------------------------------------------------------------------
> >> ------
> >>
> >> -----Original Message-----
> >> Date:    Tue, 30 Apr 2024 14:55:45 +0100
> >> From:    Jack Zukt <jzukt59@GMAIL.COM>
> >> Subject: Re: Weird error with class DATASET
> >>
> >> Hi Radoslaw,
> >> Thank you for your answer.
> >> I was equally amazed at a tape being used for sortwork. The reason
> >> being, I was told, the input being so large that there was not enough
> >> temporary DASD workspace to accommodate the sortwork file. I told
> >> them to use DASD with SPACE=(CYL,(1500,1500),RLSE),VOL=(,,,55), which
> >> did the trick. There are space constraints but there was enough
> >> space. However that does not explain why RACF interferes at the
> >> second volume mount.
> >> This environment uses DFSMSRMM for tape management. TAPEDSN is
> >> inactive; TAPEVOL is inactive; TEMPDSN is active without profiles (I
> >> may be wrong but I was under the impression that TEMPDSN works just
> >> by being active).
> >> DEVSUPxx settings are
> >>
> >> TAPEAUTHDSN=YES,
> >> TAPEAUTHF1=YES,
> >> TAPEAUTHRC4=FAIL,
> >> TAPEAUTHRC8=FAIL,
> >> TAPE_MULTI_VOLUME_ANOMALY=FAIL,
> >> NON_VSAM_XTIOT=YES
> >>
> >> Regards
> >> Jack
> >>
> >>
> >> On Tue, 30 Apr 2024 at 14:08, Radoslaw Skorupka <
> >> 00000471ebeac275-dmarc-request@listserv.ua.edu> wrote:
> >>
> >> > W dniu 30.04.2024 o 12:45, Jack Zukt pisze:
> >> > >   Hi all,
> >> > >
> >> > > I am cross-posting this to IBM-Main and RACF-L A strange
> >> > > situation was related to me yesterday.
> >> > > An ICETOOL job was executing using a tape file for work space as
> >> > > the
> >> > input
> >> > > files are quite large. As one tape was not enough, a mount for a
> >> second
> >> > one
> >> > > was issued. When that happened, RACF prevented the use of that
> >> > > second
> >> > tape:
> >> > >
> >> > > IEC501A M 2667,SCRTCH,SL,COMP,PCXDS105,ICCL105A
> >> > > ICH408I USER(BATUSR  ) GROUP(GRPBAT ) NAME(USERID FOR BATCH JOBS)
> >> > >    SYS24120.T041826.RA000.PCXDS105.TEMP1.H01 CL(DATASET )
> VOL(LH6140)
> >> > >    INSUFFICIENT ACCESS AUTHORITY
> >> > >    ACCESS INTENT(UPDATE )  ACCESS ALLOWED(NONE   )
> >> > > IEC518I SOFTWARE ERRSTAT: RACFPROT
> >> > > 2667,LH6140,SL,PCXDS105,ICCL105A
> >> > >
> >> > > Any idea why this might be happening?
> >> > > The TAPEVOL classe is inactive. The TEMPDSN class is active.
> >> >
> >> > Well... This is very first time I see temporary dataset on tape. I
> >> > feel like an archaeologist :-) However it seems like the dataset is
> >> > considered as regular, not temporary. Which is wrong.
> >> > BTW: what is your SETR TAPEDSN setting?
> >> >
> >> > Few remarks:
> >> > - tape protection depends on RACF and SMS and tape management
> >> > system (DFSMSrmm, CA-1, Control-T, etc.). There are many knobs and
> buttons.
> >> >
> >> > - you can try to use regular (named) dataset on the tape. That
> >> > gives you better control over DSN.
> >> >
> >> > - (obvious) why not DASD?
> >> >
> >> >
> >> > --
> >> > Radoslaw Skorupka
> >> > Lodz, Poland
> >> >
> >>
> >
>
> El contenido del presente mensaje y sus anexos es privado, confidencial y
> de exclusivo uso para el destinatario referenciado. Puede contener
> informacion privilegiada o amparada por el secreto profesional o por
> disposiciones legales y/o reglamentarias vigentes. Cualquier modificacion,
> retransmision, diseminacion o divulgacion de su informacion se encuentra
> expresamente prohibida y su uso inadecuado puede derivar en responsabilidad
> civil para el usuario o configurar los delitos previstos en los articulos
> 153 a 157 del Codigo Penal. Si no fuere uno de los destinatarios
> consignados o lo hubiere recibido por error, Ud. NO ESTA AUTORIZADO a
> utilizar total o parcialmente, copiar, enviar, revelar, imprimir, divulgar
> de manera alguna el contenido del presente mensaje o el de sus adjuntos. En
> consecuencia, tenga a bien comunicarselo inmediatamente al emisor y
> ELIMINARLO. ANSES no garantiza la seguridad, integridad, exactitud u
> oportunidad de lo transmitido por este medio ni se responsabiliza de
> posibles perjuicios derivados de la captura, incorporaciones de virus o
> cualquier otra manipulación efectuada por terceros. Asimismo, las opiniones
> expresadas en este mensaje y en los archivos adjuntos son propias del
> remitente y no representan la opinion o politicas de ANSES, salvo que se
> diga expresamente y el remitente se encuentre  autorizado para ello. Por
> ende, ANSES no asumira -en ningun caso- responsabilidad alguna frente al
> destinatario y/o terceros en virtud de dichas comunicaciones y ademas, no
> sera responsable frente a los usuarios por la correspondencia o los
> mensajes de correo electronico enviados por terceros u otras personas
> distintas a ANSES, ya sea que estos hubieren o no solicitado el envio de
> tales mensajes. ANSES se reserva el derecho de bloquear el acceso o remover
> en forma parcial o total todo mensaje y sus adjuntos que a su criterio
> pudiere resultar abusivo, difamatorio, obsceno, fraudulento, artificioso,
> engañoso, ofensivo o violatorio a los terminos de la presente.  PD: Tildes
> omitidas intencionalmente.
[prev in list] [next in list] [prev in thread] [next in thread]