Wow, thanks Mike. That's more dates than a topless woman in a nascar infield
can get!
MA
On Wed, Oct 22, 2008 at 11:56 AM, Mike Walter <[EMAIL PROTECTED]>wrote:
> 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.
>
