Moderators: sysprog, prino, sfan, steve-myers, Tim001
ICH408I USER(F018RKK ) GROUP(USERG02 ) NAME(MARCIN KMIECIK )
FULL VIOLATION ON COMMAND CONNECT
That's up to the admins. All too often, when they do restore an ID, the user returns to his old ways, usually with 48 hours.raju576 wrote:So Steve you mean to say that RACF ID will not be re-instated once it is revoked?
I do not think the admins will look favorably on this request. On November 20, someone using vsraju attempted to access 9 data sets for several other users. Attempting to use other user's data sets is expressly prohibited. At least one of these users has also been banned. The admins may reinstate f018rkk (I think I remembered the ID correctly) since there was just the one violation even though his story about not remembering attempting to use a RACF administration command is essentially unbelievable, but repeating the same thing 9 different times is too much.raju576 wrote:... My RACF ID (vsraju) has been revoked and some 3 days back (it has been more than 48 hrs ). I want my id back please.......
I'm just guessing here, but an alternate name for the RACF CONNECT command is CO. It's possible you tried CO as an abbreviation for COPY. The first operand of CONNECT is a userid and it has several keywords that could be taken to be positional parameters substututing for a data set name; in other wordsmkmiecik wrote:How did I do that? ...
TSUBLUH just mentioned the primary flaw of shared userids, and it's why the admins try to bann shared IDs when they detect them.tsubluh wrote:It would seem to me that if these users are not directly responsible for the S913's then perhaps the person(s) they are sharing their logon credentials with might be responsible. In any event a RACF violation is a violation and hence the revocation. Who knows?
steve-myers wrote:I'm just guessing here, but an alternate name for the RACF CONNECT command is CO. It's possible you tried CO as an abbreviation for COPY. The first operand of CONNECT is a userid and it has several keywords that could be taken to be positional parameters substututing for a data set name; in other wordsmkmiecik wrote:How did I do that? ...
CO xyz xxx (where xxx might be considered a data set name)
I tried CO xxx yyy
where xxx is a valid user ID and yyy is one of the valid CONNECT command keywords. The command was rejected and it produced an ICH408I message in SYSLOG, in spite of the fact I don't think the command could ultimately do anything even run from a userid that can use the command. I hope the admins won't kill my ID for an innocent experiment!
Certainly CO was a poor choice for an alternate name for CONNECT, but we can't do anything about it. Perhaps a sysprog could delete the CO alias from SYS1.LINKLIB.
Return to Dezhi systems: Mainframe
Users browsing this forum: No registered users and 0 guests