https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.icha200/nut.htm#nut
Joe
On Sat, Aug 4, 2018 at 7:46 AM, saurabh khandelwal <
venkatkulkarn...@gmail.com> wrote:
> Hello Joe,
>
> How RVARY INACTIVE command will solve this issue. Can you please explain
>
>
> On Sat, Au
Is there any way to resume that special user from console or get the WTOR
message on console for this user and let this user be in revoked status
and other users should be able to login to system
On Sat, Aug 4, 2018 at 2:46 PM, saurabh khandelwal <
venkatkulkarn...@gmail.com> wrote:
> Hello Joe,
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 <
> venkatkulkarn...
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 an
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
leapf
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
IFAPR
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 n
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.
Barbara
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
---
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
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,
a
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
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 the
>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 prot
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 write
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
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: Thursd
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 p
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 Migrat
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
--
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
>
>
>
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]
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 st
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 DAS
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 t
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
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 o
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
E
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 Sankaranarayanan, Vignesh
Sent: Friday, May 18, 2018 8:44 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: [EXTERNAL] Re: RA
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 on
⇐=== 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, but
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 separa
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 prepa
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-
F
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 On Behalf Of
> fred
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
C
Try the Top Secret Cookbook. Should have what you need.
Doug Fuerst
Principal Consultant
BK Associates
718.921.2620 (O)
917.572.7364 (C)
d...@bkassociates.net
-- Original Message --
From: "Rob Schramm"
To: IBM-MAIN@listserv.ua.edu
Sent: 11-Oct-17 9:57:36 PM
Subject: Re:
nal 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
>
> 1) you can post qu
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
S
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 a valid CA Site number
>
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 In
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 c
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.
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 Rele
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 Lis
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
---
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
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 per
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
-
e
> 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
> Subject: (External):Re:
AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):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 RDEF
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 able to
>issue RACF com
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 authorit
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
---
al Message-
From: 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
m/RSH_RACF
www.rshconsulting.com
-Original Message-
Date:Wed, 24 May 2017 19:22:23 +
From:Jesse 1 Robinson
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 something truly
o:IBM-MAIN@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
---
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 fu
ulting.com
-Original Message-
Date:Tue, 23 May 2017 21:57:21 +
From:Jesse 1 Robinson
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 access; th
-
Date:Tue, 23 May 2017 21:57:21 +
From:Jesse 1 Robinson
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 access; they seem to be mostly in the
2017 18:36:52 +
From:"Burrell, Todd"
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 only one o
Behalf
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 databas
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
Mainframe 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: Samp
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 READ
-MAIN@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
-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 Jesse 1 Robinson
Sent: Tuesday, May 23, 2017 11:03 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: RACF Database (was: S
ssage-
From: IBM Mainframe 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
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
):
On 22 May 2017 at 12:57, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
[snip]
How doe
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 us
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 enqueued on as previously noted.
>>
>
>Been there. Done that.
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,
> -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)
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 'SYS1.RACF'
> in the catalog
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 (bu
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
M-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) <
Sent: Monday, 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 wrote:
>On Sun, 21 May 2017 05:12:00 -0500, Elardus Engelbrecht wrote:
>>
&g
ssage-
From: IBM 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 -
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
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
-
From: IBM Mainframe Discussion List [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
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 pro
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 uncopyable; the copy wou
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 struc
>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
--
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 tha
bject: 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.htm
Protecting DFP-managed temporary data
Bob,
Thanks so much I noticed now such difference.
Have a great day!
From: IBM Mainframe Discussion List on behalf of
Robert S. Hansel (RSH)
Sent: Wednesday, April 19, 2017 6:56 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF TEMPDSN improvement with
half
> of Elardus Engelbrecht
> 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:
>
> >Hello!
> >I've heard about improvements with the zOS 1.13 (some yea
o find that
info in such documentations ?
Again, tks a lot for your time :-)
From: IBM Mainframe Discussion List on behalf of
Elardus Engelbrecht
Sent: Wednesday, April 19, 2017 2:43 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF TEMPDSN improvement with the zOS 1.
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 d
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 sim
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 IB
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 need
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)? Ditt
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 don
@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
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
http://events.share.org/Winter2017/Public/SessionDe
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 t
201 - 300 of 485 matches
Mail list logo