The sesion has been closed inmediatly!!!

[jasbaje1]

What is the problem? I can not found the cause why the session with my tso user is closed inmediatly after I make the login!!!
Is It because I need to make a donation? At this moment I have not gotten any money back from my job!!! and if you cobntinue closing my session I can not get any money for may job...because I can not finish if you do not support to make my job,...thankls for your help!!! folks! :D

[prino]

Read this link, which you evidently did not, and think about what you did. Then you will understand.

[mkmiecik]

Firstly, I really appreciate your work and the possibility to log on to your system (which I'm hoping to be able to get back).

I'm having the same problem (user f018rkk), so probably I have unintentionally broken some of the rules mentioned earlier. I only recall copying two files from some of the default ones with a BLKSIZE=32000, so I'm assuming this was it. Apart from that the only thing I've managed to do is launching some HelloWorld JCL, which didn't run, actually. If it's something else I did, I would be very grateful for instructing me what I've done wrong - it's hard to learn from mistakes otherwise.

Regards,
Marcin

[steve-myers]

You attempted to run a RACF CONNECT administration command. The admins do not give users that attempt to run RACF administration command a second chance.

[mkmiecik]

How did I do that? I wouldn't even know where would one issue such a command... And definitely I wasn't trying to break any of the rules and regulations, which, I've really read before using the system. If you could at least explain how this could have happened and give me the chance to not feel being wrongfully accused of doing something, which I didn't.

I thought I can maybe help sort out the misunderstanding by providing the details about my actions that I can remember:
1. I created 2 files with my own HLQ by copying some default files with the same HLQ (F018RKK) using 3.4. I also tried creating files using TSO ALLOC, but failed.
2. Created one or two JCLs (generally HelloWorld-like)
3. Run those JCLs and checked their status in SDSF, applying OWNER F018RKK
4. The jobs did not run, I didn't have time then to sort out the reason, though, but they were some basic JCLs without file access
5. Tried to log in the next day, but was automatically logged-off right away
6. Tought maybe my TSO ID might have been revoked, so went to cgi-bin/mainframe/mainuser?F=RESUME and provided my details
7. Asked the question on this forum to sort out why I couldn't log in

And that's really all (at least of which I can remember). No mean intentions, trying to follow the rules (one which I may have unintentionally broken, but I really don't know when). Any idea which of these actions might have popped out as RACF CONNECT in the logs? As far as I follow, issuing RACF CONNECT (http://publib.boulder.ibm.com/infocente ... onnect.htm) would mean willing to change some users authorization level, which I really did not.

Regards,
Marcin

[steve-myers]

Hello world JCL is only run by beginners, students or a course instructor attempting to construct an example. The use of Fandezhi for this purpose is prohibited, as is clearly explained in the three screens worth of annoying messages you see when you logon.

Clearly you attempted to use the CONNECT command to accomplish something. Just entering the command with no operands simply causes the commend to prompt for input. Personally, I find the command syntax to be very confusing - and in a previous life I did RACF administration. However, you cannot expect me (or the administrators) to believe you did this by accident.

These messages do exist in SYSLOG -

Code: Select all

ICH408I USER(F018RKK ) GROUP(USERG02 ) NAME(MARCIN KMIECIK      )
  FULL VIOLATION ON COMMAND CONNECT

[mkmiecik]

I run the HelloWorld JCL as a refresher, nothing more. I'm not a mainframe expert, I guess - I'm sure there are many here with much more experience than I do. But I've already worked in some mainframe projects, so I'm not a beginner as well. It's just, as in every (bigger) project, you get to implement one things whilst not the others. In my case it's been pretty a lot of Cobol, but not much JCL, hence the HelloWorld, that's all. And yes, I've read all the annoying screens and haven't violated any of the rules listed.

Regarding RACF CONNECT: I didn't execute any RACF commands explicitly nor intentionally. Didn't go to any administration areas in ISPF. I only issued 3.X, SD, tried to open DB2 and DB2Admin (the latter with no success, only after that I've read it's not working), as stated earlier. I really don't know which of what I've done could have produced the output you quoted, but there must be something, even if it didn't happen to anyone before.

Still hoping for someone to try and dig deeper in the logs,
Marcin

[raju576]

So Steve you mean to say that RACF ID will not be re-instated once it is revoked?

[steve-myers]

So Steve you mean to say that RACF ID will not be re-instated once it is revoked?

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]

Steve,

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

[steve-myers]

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

[tsubluh]

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]

How did I do that? ...

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 words

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.

[steve-myers]

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?

TSUBLUH just mentioned the primary flaw of shared userids, and it's why the admins try to bann shared IDs when they detect them.

[prino]

How did I do that? ...

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 words

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.

No, they should not change standard IBM names just because some dimwit assumes that they have another function.