I agree, even though we have code which is similar. If I wrote it today, I'd use IRRXUTIL to get that data using a REXX program. On Aug 7, 2013 11:32 PM, "Ed Gould" <[email protected]> wrote:
> That is only one issue of screen scraping which we have talked on here > before. > Its like trying to take an IDCAMS listing and parse it out to be more user > friendly. > It works great until IBM changes it. IOW its not a programmed interface > that IBM is willing to advertise. > > Ed > > On Aug 7, 2013, at 3:41 PM, Greg Shirey wrote: > > On 7 August 2013, 13:34 Tony Harminc wrote: >> >> We produce a daily listing of RACF commands from our SMF type 80s (using >>>> RACFRW) and we list ADDUSER >>ADDGROUP ALTUSER ALTGROUP CONNECT DELUSER >>>> DELGROUP PASSWORD PERMIT RALTER RDEFINE REMOVE. >>>> >>>> We also produce a daily listing of our CICS user IDs and their RACF >>>> status. On July 8 we had a user ID on >our report that was listed as >>>> REVOKED and a LAST-ACCESS date and time of 07/17/07 17:01:28. >>>> >>> >> What produces this second listing? >>> >> >> Is it possible that the REVOKED status reported the first time was >>> actually an indication of some other reason the user would not be able >>> to logon, e.g. being revoked at the group level or having a revoke >>> date that has been reached? Do your SMF records show CONNECT command >>> activity that affects the user? There are doubtless other reasons that >>> a report might claim a userid to be revoked when the magic "FLAG4" is >>> not set. >>> >> >> It is a COBOL program that parses the output of an LU * command. I >> didn't write it, but it appears that the program examines the 4th line of >> output for each User to see if "ATTRIBUTES=REVOKED" begins in column 3. It >> writes the information to a VSAM file and then creates the report from the >> data in the VSAM file. I just checked the User IDs listed as revoked on >> today's report, and indeed they are revoked in RACF, but I take your point >> - this report is probably where I need to look. >> >> Thanks, >> Greg >> >> >> >> >> >> ------------------------------**------------------------------** >> ---------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
