User ID not authorized

[sankha]

Hi,

I had created the user ID SANKHA in the morning and was using it to understand the available features. I was planning to use it for testing some of my applications/ideas.

I logged off once and tried to reconnect but I am getting the following message:
IKJ56420I Userid SANKHA not authorized to use TSO

Please note that I am using this ID for personal growth and this is not for corporate use or training purpose.

Could you please let me know why my ID was deleted.

Regards,
Sankha

[steve-myers]

I think the admins deleted your ID for these reasons -

• You attempted some sort of unauthorized operation on a user catalog. Your ID almost certainly had normal update access to this catalog through normal IDCAMS commands like LISTCAT, but it certainly did not have ALTER access.
• You attempted to read other people's data.

This list is just from today. Other things you did other days got the admins nose twitching, but today was probably too much.

[steve-myers]

Personal growth!? Seems unlikely. Sabotage seems more likely.

Code: Select all

 ICH408I USER(SANKHA  ) GROUP(USERG02 ) NAME(SANKHADEEP          ) 296
   CATALOG.USERS8.UCAT CL(DATASET ) VOL(FAN003)
   INSUFFICIENT ACCESS AUTHORITY
   FROM CATALOG.** (G)
   ACCESS INTENT(ALTER  )  ACCESS ALLOWED(UPDATE )
 IEC161I 040(056,006,IGG0CLFT)-002,SANKHA,SYSUSER SYSUSER,SYS00029,,, 297
 IEC161I CATALOG.USERS8.UCAT


If I read these message correctly, you attempted to open a user catalog as a VSAM dataset, for output. In other words, you might have destroyed the ability of the users with datasets cataloged in CATALOG.USERS8.UCAT to access their data. For someone interested in sabotage this might be considered "personal growth," though I doubt very many others would agree.

In my opinion, the administrators not only have the right, but it is their duty to protect the system from people like you.

The only statement you made that seems to be absolutely true is you just created the SANKHA ID.

[monitor]

Wouldn´t it be better to give users only read ( or no ) access to other users data. I´m surprised this hasn´t been done before.

[nclouston]

I think it is up to the individual user to protect their own datasets but some, if not most, may never have had to do this. It is a long time since I did any RACF work and as all my stuff is just 'play' i.e. trying out bits'n'bobs of various languages/utilities I have no objection to people looking at my stuff. Indeed, due to the lack of a sticky to easily find information you sometimes have to take a peek to find out how to do something (thanks Prino!). To be honest I have no idea what protection my data has - probably UACC(all or whatever) and I probably should change it to UACC(READ). I would also suggest that a lot of the 'no-go' areas be made UACC(READ) and then maybe this constant failure in CICS and DB2 could be minimised and the culprits identified. This may already be in place but CICS has gone again recently so perhaps a bit more work needs to be done on that. Yes, there may be a workload associated with immplementing that but over the coming years that is going to be less than restoring CICS/DB2 evry other week or so.

[prino]

Wouldn´t it be better to give users only read ( or no ) access to other users data. I´m surprised this hasn´t been done before.

In an ideal world. FanDeZhi should use RACF in a "deny all, unless permitted" rather than the current "deny none, unless forbidden" mode, but... who is going to do all this?

FanDeZhi is run entirely by volunteers and very few of them have the expertise or (RACF) authority to implement the changes. A recent addition to the team has started on a lot of changes and this may well be on his list, but there is only so much time he can spend on the system, and yours truly, although on-line for very long periods, does not have the authority.

As for the

I think it is up to the individual user to protect their own datasets but some, if not most, may never have had to do this.

We don't really want people playing around with RACF, as this will cause all kinds of problems with system management jobs.

[prino]

... Indeed, due to the lack of a sticky to easily find information you sometimes have to take a peek to find out how to do something (thanks Prino!). ...

FanDeZhi is a fairly bog-standard z/OS system, i.e. all information can be found on-line in IBM manuals, i.e. at the IBM Library Server Library...