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
> >>
> >
>
>
