Re: RACF Special User Revoked System

Hello Joe, How RVARY INACTIVE command will solve this issue. Can you please explain On Sat, Aug 4, 2018 at 2:37 PM, Joe Monk wrote: > You can try to RVARY INACTIVE. Then, failsoft processing will be in effect. > > Joe > > On Sat, Aug 4, 2018 at 7:19 AM, saurabh khandelwal < >

Re: RACF Special User Revoked System

You can try to RVARY INACTIVE. Then, failsoft processing will be in effect. Joe On Sat, Aug 4, 2018 at 7:19 AM, saurabh khandelwal < venkatkulkarn...@gmail.com> wrote: > Hello Group, > > We are facing issue that someone by mistake used wrong password on special > user and this end up revoking

Re: RACF DATASET protection WHEN(SYSID)

Brian, Do any of the other WHEN options work in lieu of SYSID? For example, WHEN (TERMINAL...) seems like it might be viable, provided of course the test LPAR user is coming in through one of a set of named terminal IDs and that those terminal IDs are only available in/to the test LPAR -- no

Re: RACF DATASET protection WHEN(SYSID) - Compilers

Barbara Nitz wrote: On Mon, 23 Jul 2018 06:05:43 -0400, John Eells wrote: Over the past few years, COBOL and PL/I have added support for Product Registration Services, and can be disabled using IFAPRFxx entries. XL C/C++ is a feature of z/OS and can similarly be enabled or disabled with

Re: RACF DATASET protection WHEN(SYSID) - Compilers

On Mon, 23 Jul 2018 06:05:43 -0400, John Eells wrote: >Over the past few years, COBOL and PL/I have added support for Product >Registration Services, and can be disabled using IFAPRFxx entries. XL >C/C++ is a feature of z/OS and can similarly be enabled or disabled with >IFAPRDxx. > >This does

Re: RACF DATASET protection WHEN(SYSID)

Over the past few years, COBOL and PL/I have added support for Product Registration Services, and can be disabled using IFAPRFxx entries. XL C/C++ is a feature of z/OS and can similarly be enabled or disabled with IFAPRDxx. This does not cover everything, of course, but it's a start.

Re: RACF DATASET protection WHEN(SYSID)

That's right. By add new data to I meant adding new datasets. I wanted to use RACF for the access part (which would have covered the changing and extending data). Apparently that can only be performed with the RACF exit, but that's not very elegant. Brian

Re: RACF DATASET protection WHEN(SYSID)

DISNEW allows you to update and extent current datasets. Just can't create new ones or add another volume that is DISNEW. On Sat, Jul 21, 2018 at 10:48 PM Brian Westerman wrote: > > Well, I found out that the ICHRCX01 exit can be used for this, but I think > that sort of defeats the ease of use

Re: RACF DATASET protection WHEN(SYSID)

Well, I found out that the ICHRCX01 exit can be used for this, but I think that sort of defeats the ease of use in having RACF do the work. I think I can use my original idea of setting up the volume pools as DISALL should do what I want for the pools I want no read or write access to at all,

Re: RACF DATASET protection WHEN(SYSID)

An exit that sees a program name and assign a jobclass that is only open on licensed LPARs or system name to the job? On Fri, Jul 20, 2018 at 11:48 AM Allan Staller wrote: > > My RACF guy says "not possible". > > HTH, > > -Original Message- > From: IBM Mainframe Discussion List On Behalf

Re: RACF DATASET protection WHEN(SYSID)

My RACF guy says "not possible". HTH, -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Westerman Sent: Thursday, July 19, 2018 8:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF DATASET protection WHEN(SYSID) Hi, I was hit with a question that I don't know

Re: RACF DATASET protection WHEN(SYSID)

>So how do people protect the same dataset differently on various LPAR's, or is >it just not possible? We had to make sure that the compilers do not run on a system that doesn't have licence=z/OS. We used when(sysid) in class PROGRAM, for the names of the compilers as the program name to be

Re: RACF DATASET protection WHEN(SYSID)

I've never tried what you're looking to do. We don't share data across sysplex boundaries. It might annoy your users, but you might try giving them a different userid on each system. Each userid would have its own unique access rights even though it represents the same person. Now that I

Re: RACF DATASET protection WHEN(SYSID)

Good point, I'll do that. It should have occurred to me that it was more appropriate there. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO

Re: RACF DATASET protection WHEN(SYSID)

You may get an answer on this listserv, but might also have better luck with the RACF listserv... https://listserv.uga.edu/cgi-bin/wa?A0=RACF-L HTH, Mike -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Brian Westerman Sent:

Re: RACF protection of a volume

Todd Burrell wrote: >Hopefully this is not a stupid question - but >is it possibly via RACF (maybe with DASDVOL) >to allow a particular system to have only read >access to a DASD volume? We have a need to >possibly vary some devices onto a system in one >plex while it is being updated on another

Re: RACF protection of a volume

Nice. On Thu, Jun 7, 2018, 5:33 PM Marna WALLE wrote: > I was thinking of possibly another method that you could look at...how > about making that volume have a READ-ONLY attribute in HCD? Read up on > this, as there are some restrictions. > > Marna WALLE > z/OS System Installation and

Re: RACF protection of a volume

I was thinking of possibly another method that you could look at...how about making that volume have a READ-ONLY attribute in HCD? Read up on this, as there are some restrictions. Marna WALLE z/OS System Installation and Migration IBM Poughkeepsie

Re: RACF protection of a volume

Stupid auto spell error... System. Apparently one more Cindy than I need and certainly one more than I can correct before pressing "send" Rob On Mon, Jun 4, 2018, 11:28 PM Chris Hoelscher wrote: > How many Cindy's do you have? > > Chris Hoelscher > Humana.com > (502) 476-2538 or 407-7266 > >

Re: RACF protection of a volume

How many Cindy's do you have? Chris Hoelscher Humana.com (502) 476-2538 or 407-7266 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Monday, June 4, 2018 10:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN]

Re: RACF protection of a volume

Excellent point. I ran across this ( at the time it was a pesky problem ) which kept me from at least creating datasets on a SMS volume that's part of another Cindy. Rob Schramm On Mon, Jun 4, 2018, 10:37 PM Mike Schwab wrote: > An SMS volume from a system without the volume defined to a

Re: RACF protection of a volume

An SMS volume from a system without the volume defined to a storage group is pretty darn resistant. But they generally don't need this kind of treatment. On Mon, Jun 4, 2018 at 5:27 PM Todd Burrell wrote: > > Hopefully this is not a stupid question - but is it possibly via RACF (maybe > with

Re: RACF protection of a volume

As I said this was probably a stupid question. I suspect that from what I have seen MIM may be a solution, but we will look more. Thanks for the info, Walt. This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for

Re: RACF protection of a volume

On Mon, 4 Jun 2018 17:27:25 -0500, Todd Burrell wrote: >Hopefully this is not a stupid question - but is it possibly via RACF (maybe >with DASDVOL) to allow a particular system to have only read access to a DASD >volume? We have a need to possibly vary some devices onto a system in one >plex

Re: RACF protection of a volume

Are we not smart enough to deal with such things? GRS special processing, hardware reserves, MIM..or for sysprogs.. just being careful? Should some restraint be exercised? Sure.. but let's not act like we are just another server without ways to do just about anything ( some more advisable than

Re: RACF protection of a volume

If you were not aware there is a RACF list that this question might also be posted to To join, if you have not done so RACFhttp://www.listserv.uga.edu/archives/racf-l.html A side comment, I would not allow DASD Sharing between plexes. Within members of a PLEX, yes. Between Plexes, no

Re: RACF on a Sysplex??

-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Friday, May 18, 2018 8:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [EXTERNAL] Re: RACF on a Sysplex

Re: [EXTERNAL] Re: RACF on a Sysplex??

Hi Skip, Any scars from not doing so? – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Saturday 19-May-2018 03:17 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: RACF

Re: RACF on a Sysplex??

⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Zelden Sent: Thursday, May 03, 2018 3:45 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF on a Sysplex?? My client has a mixture of things

Re: RACF on a Sysplex??

My client has a mixture of things, but nothing is ever shared with a sandbox LPAR - not even via RRSF "one way". It really doesn't seem dangerous to do it one way, but I still prefer to isolate things in a sandbox as completely as possible. One business unit with 2 large sysplexes has

Re: RACF on a Sysplex??

fred glenlake wrote: >We are going from one production lpar and one test lpar to two sysplexs, one >plex for production, one plex for test. Currently the RACF databases are >shared (yeah not ideal) but they will be split (prod and test on their own >databases) once we are sysplexed. >In

Re: RACF on a Sysplex??

I would do the split post sysplex. Make a copy of production to be used by the test sysplex. Get to the two sysplex mode. Then do the cleanup. Remember, you scope of sharing is SYSPLEX. Do not cross sysplex boundaries. You will (most likely) be very sorry if you do. -Original Message-

Re: RACF on a Sysplex??

If you have not joined, there is a RACF List that you might like to also ask this question. To join, if you have not done so, go to this URL RACFhttp://www.listserv.uga.edu/archives/racf-l.html Lizette > -Original Message- > From: IBM Mainframe Discussion List

Re: RACF x CA-TopSecret

My CA TSS resources endorse John's reply below. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John P. Baker Sent: Wednesday, October 11, 2017 5:32 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF x CA-TopSecret Carlos

Re: RACF x CA-TopSecret

ct-17 9:57:36 PM Subject: Re: RACF x CA-TopSecret Or you can post here and see if there are TSS guys willing to help. John beat me to it. Rob Schramm On Wed, Oct 11, 2017, 9:40 PM Charles Mills <charl...@mcn.org> wrote: I've reached out to a TSS resource. We'll see if we get anywhere

Re: RACF x CA-TopSecret

t; -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Wednesday, October 11, 2017 6:17 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF x CA-TopSecret > > So if you were not aware > &g

Re: RACF x CA-TopSecret

I've reached out to a TSS resource. We'll see if we get anywhere that way. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Wednesday, October 11, 2017 6:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re

Re: RACF x CA-TopSecret

CA TSS team does have a command conversion tool and they can help you On 12-Oct-2017 6:47 AM, "Lizette Koehler" wrote: > So if you were not aware > > 1) you can post questions on Communities.CA.COM by joining the Top Secret > community and ask questions there. You need

Re: RACF x CA-TopSecret

So if you were not aware 1) you can post questions on Communities.CA.COM by joining the Top Secret community and ask questions there. You need a valid CA Site number 2) If you are licensed for Top Secret, then you could open a Case to CA-TSS and request assistance., 3) You could try doing an

Re: RACF x CA-TopSecret

Carlos, Please see my answers below. John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Carlos Bodra - Pessoal Sent: Wednesday, October 11, 2017 5:14 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: RACF x CA-TopSecret I need to

Re: RACF Parmlib Support - OA52650

John Eells wrote: >> For what z/OS release is that available? Yes, I see 'Reported Release' which >> is 7B0. Ok, I'm perhaps ignorant, but '7B0' is unfamiliar to me? >Ah, the Dreaded RETAIN Release. [ ... snipped for brevity ... ] Thanks for your very interesting reply. >And, yes. I know.

Re: RACF Parmlib Support - OA52650

Elardus Engelbrecht wrote: Ed Jaffe wrote: Yay! I have wanted this since Old Man Noah cornered the market on gopher wood! ftp://public.dhe.ibm.com/eserver/zseries/zos/racf/pdf/oa52650.pdf That is one very cool enhancement. For what z/OS release is that available? Yes, I see 'Reported

Re: RACF Parmlib Support - OA52650

Love it. Cross posted to RACF-L Dennis Roach, CISSP AIG Identity & Access Management | Technology Services 2929 Allen Parkway, America Building, 3rd Floor | Houston, TX 77019 Phone: 713-831-8799 dennis.ro...@aig.com | www.aig.com -Original Message- From: IBM Mainframe Discussion

Re: RACF Parmlib Support - OA52650

Klaus Stanislawiak wrote: >7B0 (last three characters of the FMID) corresponds to z/OS 2.3. Thanks Klaus. I have also been informed offlist, that z/OS v2.2 is 7A0, z/OS v2.3 is 7B0 and so on. Much appreciated! Groete / Greetings Elardus Engelbrecht

Re: RACF Parmlib Support - OA52650

7B0 (last three characters of the FMID) corresponds to z/OS 2.3. Regards, Klaus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Parmlib Support - OA52650

Ed Jaffe wrote: >Yay! I have wanted this since Old Man Noah cornered the market on gopher wood! >ftp://public.dhe.ibm.com/eserver/zseries/zos/racf/pdf/oa52650.pdf That is one very cool enhancement. For what z/OS release is that available? Yes, I see 'Reported Release' which is 7B0. Ok, I'm

Re: RACF Parmlib Support - OA52650

On Thu, 24 Aug 2017 18:25:09 -0700, Ed Jaffe wrote: >Yay! I have wanted this since Old Man Noah cornered the market on gopher >wood! > >ftp://public.dhe.ibm.com/eserver/zseries/zos/racf/pdf/oa52650.pdf Second that ! - gets rid of two usermods for us Roger

Re: RACF Question

0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Walt Farrell > Sent: Thursday, May 25, 2017 11:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subj

Re: RACF Question

@LISTSERV.UA.EDU Subject: (External):Re: RACF Question On Thu, 25 May 2017 12:14:46 -0400, scott Ford <idfli...@gmail.com> wrote: >In reading through the RACF manual I have a question about STC definitions. >We have a STC that is doing RACF provisioning. The question is if I >change th

Re: RACF Question

On Thu, 25 May 2017 12:14:46 -0400, scott Ford wrote: >In reading through the RACF manual I have a question about STC definitions. >We have a STC that is doing RACF provisioning. The question is if I change >the below RDEFINE from TRUSTED(YES) to TRUSTED(NO) will still be

Re: RACF Question

ITschak: todah rabah I was hoping that was the answer. Regards, Scott On Thu, May 25, 2017 at 12:23 PM, IronSphere by SecuriTeam Software < imugz...@gmail.com> wrote: > Trusted attribute ia a kind of bypass security qhile audited. If turn it > off, the user need to have the proper

Re: RACF Question

Trusted attribute ia a kind of bypass security qhile audited. If turn it off, the user need to have the proper authority to enter racf commands at hia scope or enterprise widw is has a special attribute. Trusted is easier but more risky. ITschak

Re: RACF Database

: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Thursday, May 25, 2017 2:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database Hi Skip, I usually assign a group as the owner of a profile. In the case of datasets, I

Re: RACF Database

www.rshconsulting.com -Original Message- Date:Wed, 24 May 2017 19:22:23 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database A fallout of this thread is that we're looking to assign a new owner to profiles that cover the RACF data sets. I'd like som

Re: RACF Database

@LISTSERV.UA.EDU] On Behalf Of Robert S. Hansel (RSH) Sent: Wednesday, May 24, 2017 3:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database Hi Skip, Point of clarification. IRRDBU00 no longer required UPDATE access with NOLOCKINPUT as of z/OS 2.2. Regards, Bob -Original

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Robert S. Hansel (RSH) wrote: >Restricting access to the RACF database is essential, but it isn't enough to >save you if the database is not allocated as unmovable. DFSMSdss' data >management utility ADRDSSU, when used with the ADMINISTRATOR keyword, ignores >dataset profiles and can perform

Re: RACF Database

-Original Message- Date:Tue, 23 May 2017 21:57:21 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database So it turns out that the number of folks here with ALTER access to RACF data sets is way smaller than I expected. There are however several u

Re: RACF Database

- Date:Tue, 23 May 2017 21:57:21 + From:Jesse 1 Robinson <jesse1.robin...@sce.com> Subject: Re: RACF Database So it turns out that the number of folks here with ALTER access to RACF data sets is way smaller than I expected. There are however several userids with UPDATE

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

:52 + From:"Burrell, Todd" <todd_burr...@csx.com> Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) Wouldn't a simpler solution to protecting the RACF database simply be to give pretty much no one ALTER access to it? I know that at most shops

Re: RACF Database

Of Joel C. Ewing Sent: Tuesday, May 23, 2017 12:36 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database It should go without saying that ALTER (and even READ) access to the RACF database data set should be restricted to those that really need direct access to the database data set

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Radoslaw Skorupka Sent: Tuesday, May 23, 2017 12:04 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP

Re: RACF Database

Systems Administrator > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: Tuesday, May 23, 2017 2:28 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF Database (was: Sample JCL for

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

RACF A/S can be easily stopped using STOP command (not an MVS STOP, it is @STOP). It also can be started again as well. The only cost is "address space unavailable" issue. Of course *properly protected* RACF db cannot be moved or deleted, due to lack of authorities. No one should have even

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

@LISTSERV.UA.EDU Subject: Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) I have not tried this, but IBM supplies a RACF started task whose purpose is to issue RACF commands via a console. As supplied, the RACF STC has no DDs, but I suppose you could add one for the primary and maybe

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Tuesday, May 23, 2017 11:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, May 22, 2017 4:58 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote: >RECFM PSU

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On 22 May 2017 at 12:57, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > > ... In any case, a SAF product has to be available extremely early in > IPL, ... > > > How does ACF2, based on VSAM, meet this requirement of early availability? > The same way it would if ACF2

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Tue, 23 May 2017 07:30:02 -0500, John McKown wrote: >On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson >wrote: > >> Brief war story. Long before "z/OS", someone accidentally deleted (!!!) >> the primary RACF data base. It was not

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

John McKown wrote: >>Long before "z/OS", someone accidentally deleted (!!!) the primary RACF data >>base. >> Could not have done that with VSAM. ;-) >​Been there. Done that. Beat up the programmer. I hope he survived your cruel beating, because if he did the same error on the BACKUP RACF DB,

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

> -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jesse 1 Robinson > Sent: 23 May, 2017 0:18 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF Database (was: Sample JCL for file transfer using > NJE/TCPIP)

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, May 22, 2017 at 5:17 PM, Jesse 1 Robinson wrote: > Brief war story. Long before "z/OS", someone accidentally deleted (!!!) > the primary RACF data base. It was not enqueued on as previously noted. > Data was intact and the system hummed along, but there was no

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, 22 May 2017 17:44:16 -0500, Joel C. Ewing wrote: >RECFM PSU may prevent moving the database, but it doesn't block >deletion. After realizing this somewhat-essential data set wasn't >protected by an enqueue, we picked an installation started task that was >normally running all the time

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, 22 May 2017 09:21:48 -0400, Robert S. Hansel (RSH) wrote: > >... then immediately closes them. > Why? Does it also FREE then? Why? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Kown > Sent: Monday, May 22, 2017 8:03 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: RACF Database (was: Sample JCL for file transfer > using NJE/TCPIP) > > On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < > r.han...@rshconsulting.com> wrote: &

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

ay, May 22, 2017 7:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin <paulgboul...@aim.com> wrote: >On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wro

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David W Noon Sent: Monday, May 22, 2017 10:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in <507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>): On 2017-05-22, at 10:01, Jesse

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: > ... Nonetheless ACF2, based on VSAM, was well established ... > > ... In any case, a SAF product has to be available extremely early in IPL, > ... > How does ACF2, based on VSAM, meet this requirement of early availability? -- gil

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Monday, May 22, 2017 8:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP) On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < r.han...@rshconsulting.

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Mon, May 22, 2017 at 8:21 AM, Robert S. Hansel (RSH) < r.han...@rshconsulting.com> wrote: > Gil, > > The RACF database is BDAM (Basic Direct Access Method) and has, to my > knowledge, always been so since it was first released in 1976. The index > records are stored in the database with the

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

On Sun, 21 May 2017 14:19:39 -0500, Paul Gilmartin wrote: >On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote: >> >>>RACF (I'm less sure) is VSAM. >> >>No, it is PSU (PS and Unmovable). Other attributes are mandated by IBM. >> >"Unmovable" would seem to imply

Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)

Gil, The RACF database is BDAM (Basic Direct Access Method) and has, to my knowledge, always been so since it was first released in 1976. The index records are stored in the database with the profile (data) records, so it is completely self-contained. I know of no other product using this

Re: RACF TEMPDSN improvement with the zOS 1.13

>You have gotten excellent replies from Robert and Dan. You can sure use these >resources as proof of that change. Also see http://www.rshconsulting.com/racftips/RSH_Consulting__RACF_Tips__April_2012.pdf Happy reading! Groete / Greetings Elardus Engelbrecht

Re: RACF TEMPDSN improvement with the zOS 1.13

Rogério Camargo wrote: >Thanks for your reply. You're most welcome. >... but again, I could not identified any piece of information about the >TEMPDSN improvements came with the zOS V1R13. You have gotten excellent replies from Robert and Dan. You can sure use these resources as proof of

Re: RACF TEMPDSN improvement with the zOS 1.13

ay, April 19, 2017 9:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF TEMPDSN improvement with the zOS 1.13 It's not really described as an improvement anywhere for z/OS 1.13 but the documentation at https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha700/tempdsn.ht

Re: RACF TEMPDSN improvement with the zOS 1.13

To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF TEMPDSN improvement with the zOS 1.13 HI Roger, Beginning with z/OS 1.13, the activation of TEMPDSN no longer interferes with currently running processes, and it is safe to activate TEMPDSN without waiting for an IPL. If you compare the descriptio

Re: RACF TEMPDSN improvement with the zOS 1.13

ussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf > of Elardus Engelbrecht <elardus.engelbre...@sita.co.za> > Sent: Wednesday, April 19, 2017 2:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: RACF TEMPDSN improvement with the zOS 1.13 > > Rogério Camargo wrote: > > >

Re: RACF TEMPDSN improvement with the zOS 1.13

that info in such documentations ? Again, tks a lot for your time :-) From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Elardus Engelbrecht <elardus.engelbre...@sita.co.za> Sent: Wednesday, April 19, 2017 2:43 AM To: IBM-MAIN@LISTSERV.UA

Re: RACF TEMPDSN improvement with the zOS 1.13

HI Roger, Beginning with z/OS 1.13, the activation of TEMPDSN no longer interferes with currently running processes, and it is safe to activate TEMPDSN without waiting for an IPL. If you compare the description of TEMPDSN in the 1.12 version of the RACF Security Administrator's Guide with its

Re: RACF TEMPDSN improvement with the zOS 1.13

Rogério Camargo wrote: >Hello! >I've heard about improvements with the zOS 1.13 (some year ago) related to the >RACF TEMPDSN, however it is being just impossible to me to find that >information in any 1.13 manual/migration guide... I've just read and searched >several of these manual, but I

Re: RACF Non-expiring passwords

Thanks all! It was including the NOEXPIRED keyword that fixed our problem. We were getting no error messages and the id is not used for TSO When we changed it with TSO the batch FTPs still failed. Thanks again. Elaine -- For

Re: RACF Non-expiring passwords

Hi Elaine, When you reset the password, be sure to use the NOEXPIRED operand on your ALU command like so: ALU userid PASSWORD(password) NOEXPIRE This will require the password to conform to your current password syntax rules. If the former password no longer conforms to your rules, you'll

Re: RACF Non-expiring passwords

Are you saying that attempting to change the password with the RACF panels fails but using ALU with the same password and options succeeds? Do you have a password validation exit? Can you show us your password rules and the panel data (use X, x, 1, and $ as appropriate for the password)?

Re: RACF Non-expiring passwords

Elaine Beal wrote: >We have a non-expiring password that we've used for years and somehow failed >the other night. I reset with an alu line command but the new password doesn't >work. When I go through the panels it says the current password isn't valid. >We have changed password rules but I

Re: RACF and public keys

@LISTSERV.UA.EDU Subject: Re: RACF and public keys FYI, we will be presenting a SHARE session next week on this subject: *Finding the Needle in a Haystack - Diagnosing Common OpenSSH Problems* - Room: Blossom Hill I,II - Session Number: 20125 Thursday, March 09, 2017: 10:00 AM - 11:00 AM

Re: RACF and public keys

FYI, we will be presenting a SHARE session next week on this subject: *Finding the Needle in a Haystack - Diagnosing Common OpenSSH Problems* - Room: Blossom Hill I,II - Session Number: 20125 Thursday, March 09, 2017: 10:00 AM - 11:00 AM

Re: RACF and public keys

On Wed, 1 Mar 2017 13:00:08 -0700, Jack J. Woehr wrote: >Mark Post wrote: >> If you don't mind them accessing your system in this way (I have severe >> doubts about that), just put the key as-is into the target userid's >> .ssh/authorized_keys file and have them give it a try. > >And make sure

Re: RACF and public keys

Mark Post wrote: If you don't mind them accessing your system in this way (I have severe doubts about that), just put the key as-is into the target userid's .ssh/authorized_keys file and have them give it a try. And make sure the dir .ssh is chmod 700 and the authorized_keys file is chmod

Re: RACF and public keys

Thanks Mark and Allan! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Post Sent: Wednesday, March 01, 2017 2:41 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: RACF and public keys >>> On 3/1/2017 at 02:04 PM, Tracy A

<    1   2   3   4   5   >