I realize that this was not asked for, but I keep a "DATETIPS EXEC" on my
disk with the following for quick, tested cut/pastes into new execs.
Maybe it will help someone else in the future:
---<snip>---
/* DATETIPS EXEC*/ address command
trace ?i
retpd=7
tmp=date('B')+retpd
exdte=left(date('O',tmp,'B'),2)||right(date('D',tmp,'B'),3,0)
isodate='2005-01-21'
wday=date('W',isodate,'S',,'-')
when=date('B')-1 /* Yesterday */
prevjdate=left(date('O',when,'B'),2)||right(date('D',when,'B'),3,0)
when=date('B')+1 /* Tommorrow */
nextjdate=left(date('O',when,'B'),2)||right(date('D',when,'B'),3,0)
isodate =date('S', date('U'),'U','-','/')
isodateplus =date('S', date('U',date('B')+5,'B') ,'U','-','/')
isodateminus=date('S', date('U',date('B')-5,'B') ,'U','-','/')
Sdateplus =date('S', date('B')+5,'B')
Sdateminus =date('S', date('B')-5,'B')
Signal ON Syntax Name Bad_Date
bdate=date('B',date,iformat)
Signal Off Syntax
daynum=date('B', sdate, 'S')//7
/*This will give you a number in the range of 0 (=Monday) and 6 (=Sunday)
An added bonus is that this number also infers how far away you are
from Sunday, */
/* Let rexx test for a valid date... */
yyyymmdd=195005bd
SIGNAL ON SYNTAX NAME BadDate
returnlabel='SOMELABEL' /* Must be upper case if used */
emsg=date('S',yyyymmdd,'S') /* Let REXX validate */
SomeLabel:
SIGNAL OFF SYNTAX
BadDate:
say '+++'xfn'; invalid date: "'yyyymmdd'".'
Exit
/* You cannot "Return" from a SIGNAL, but you can: */
/* SIGNAL value returnlabel */
ValiDate:
SIGNAL ON SYNTAX NAME InvalidDate
Call Date arg(2),arg(1),arg(2)
Return (1==1)
InvalidDate:
Return (0==1)
---<snip>---
"Scott Rohling" <[EMAIL PROTECTED]>
Sent by: "The IBM z/VM Operating System" <[email protected]>
10/22/2008 10:34 AM
Please respond to
"The IBM z/VM Operating System" <[email protected]>
To
[email protected]
cc
Subject
Re: RACF inactivity REVOKE
Oops -- REXX DATE doesn't allow 'Julian' to be converted .. although you
can convert 'from' Julian.. New code:
Daybase = date('B')
D30ago = date('S',Daybase-30,'B')
.
.
.
xlastacc = date('S',xyr||xday,'J')
If xlastacc < D30ago then do
.
.
.
Scott Rohling
On Wed, Oct 22, 2008 at 8:09 AM, Scott Rohling <[EMAIL PROTECTED]>
wrote:
I think you're going to have some issues during January using Julian ;-)
2009001-30 = 2008971 ... so you'll likely end up revoking everybody...
I would use date('B') -- and then convert to date('J') after:
Daybase = DATE('B')
D30ago = Date('J',Daybase-30,'B')
Scott Rohling
On Wed, Oct 22, 2008 at 6:41 AM, Mary Anne Matyaz <[EMAIL PROTECTED]>
wrote:
So here's the quick and dirty version for those interested.
/* Rexx */
erase racf data a
GLOBALV SELECT $RACGRP SET $RAC_APN Y
GLOBALV SELECT $RACGRP SET $RAC_ISPF Y
'RAC LU MATYAZ'
GLOBALV SELECT $RACGRP SET $RAC_APN N
GLOBALV SELECT $RACGRP SET $RAC_ISPF N
Daybase = date('Julian')
D30ago = Daybase - 30
'PIPE < RACF DATA | STRIP | LOCATE /LAST-ACCESS/ | STEM xracf.'
If rc <> 0 then exit rc
Do i = 1 to xracf.0
parse var xracf.i xlast '-' xaccess '=' xyr '.' xday '/' xrest
xlastacc = xyr || xday
If xlastacc < D30ago then do
'rac alu MATYAZ revoke'
say 'Revoking userid MATYAZ due to last access ' xlastacc
end
End
On Wed, Oct 22, 2008 at 6:56 AM, Mary Anne Matyaz <[EMAIL PROTECTED]>
wrote:
> Colin,
> Inactivity timeout is a system wide setting. The only workaround I
> could come up with is this:
> If your system is like mine, it is a lot of linux guests, a few
> batchlike system userids, and a few system programmers. See if they
> will allow you to change the interval to the maximum, 254, and NOT
> revoke. Then, you can do the revoke manually. By that I mean, write
> and run a nightly exec that checks those three or four system
> programmers, see when their 'last-access' is from a RAC LU, and if
> it's beyond 30 days, issue a RAC ALU userid REVOKE.
> I think it's a nice idea, so I'm going to write one. I'll email it to
> you if you want it.
> MA
>
> On Tue, Oct 21, 2008 at 4:00 AM, Colin Allinson <[EMAIL PROTECTED]>
wrote:
>>
>> I know this has been the subject of recent discussion & I said that we
have
>> a process to override this for defined virtual machines. However, for a
>> number of reasons, (mainly keeping up with identifying them), this is
giving
>> us some difficulty.
>>
>> Our VM systems are now very different beasts to when the original rules
were
>> defined so I am talking to our internal security about lengthening the
>> period of inactivity before automatic revoke. They are sympathetic but
asked
>> me to investigate if the inactivity time-out can be different dependant
on
>> RACF group or if it is a system wide limit.
>>
>> As far as I know, it is a system wide limit but I would be pleased if
>> someone can confirm or deny this.
>>
>>
>> Colin Allinson
>>
>> Amadeus Data Processing GmbH
>>
>
The information contained in this e-mail and any accompanying documents may
contain information that is confidential or otherwise protected from
disclosure. If you are not the intended recipient of this message, or if this
message has been addressed to you in error, please immediately alert the sender
by reply e-mail and then delete this message, including any attachments. Any
dissemination, distribution or other use of the contents of this message by
anyone other than the intended recipient is strictly prohibited. All messages
sent to and from this e-mail address may be monitored as permitted by
applicable law and regulations to ensure compliance with our internal policies
and to protect our business. E-mails are not secure and cannot be guaranteed to
be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate
with us by e-mail.
