Dezhi Systems support site

Hello. I get logoff immediatly after I logon and no reson is giving, please help wglez01

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

Now I am kind of confused. For instance, what if I need to browse a SYS1.MODGEN macro ? Does that action result in a 913 ? If so does that 913 result in a RACF revocation? Is it that y'all would prefer that I FTP the members from the IBM web site to my HLQ based PDS / PDSE macrolib? I would think that ACCESS=READ be the proper designation. Damn, if I should edit a SYS1.MODGEN member (merely because I want statement / line number [ I know I could use "View"] ) am I gonna be whacked by RACF ?

This is a rather ambiguous - can you clarify?

"...accessing data sets of others, this includes trying to allocate data sets with an HLQ that is not your userid"
Allocate with what DISP=?

Bruce

tsubluh wrote:... What if I need to browse a SYS1.MODGEN macro ? Does that action result in a 913 ? ...

No. Everyone has read access to most system data sets. In this context a system data set is a data set with high level qualifier that is not a user id, though how you can easily determine this I don't know.

There are a few exceptions to this rule. For example, SYSFAN.xxx data sets are system data sets, but SYSFAN.MAINUSER.xxx data sets are off limits. They appear to be used by the userid management process.

tsubluh wrote:... "...accessing data sets of others, this includes trying to allocate data sets with an HLQ that is not your userid"
Allocate with what DISP=? ...

"Allocate" in this context is attempting to allocate a new data set, not allocate an existing data set for ordinary use, even if that use will later cause a S913 ABEND. In other words, DISP=(MOD,...) will cause problems if allocation determines MOD really means NEW.

Hi Steve,
I believe I too may have got a 913 while "snooping" through the SYSFAN.MAIN... data sets. Sorry.

As the INTENT was only read, is this really a violation?

Thanks.
Dan

RSI01DD wrote:Hi Steve,
I believe I too may have got a 913 while "snooping" through the SYSFAN.MAIN... data sets. Sorry.

As the INTENT was only read, is this really a violation?

Thanks.
Dan

Yes.

However, it does not appear the admins took any action since you stopped after one attempt. I believe the SYSFAN.MAINUSER data sets are part of the automated user ID management process and the admins regard them as extremely off limits.

steve-myers wrote:I believe the SYSFAN.MAINUSER data sets are part of the automated user ID management process and the admins regard them as extremely off limits.

Then how about changing the HLQ of these sensitive data sets? Would it be a good idea? Say they start with SYSADM and the rules say clearly to stay away from them. Although I may see the whole picture here

Yours truly,

Rene FERLAND, Montreal

I said this before and I will say it again. SYSADM is a user. Users may not use another user's data sets. Period. End of story. Your data is essentially your property; it is the duty of the admins to protect your property.

The outage at the end of April and extending into May was caused by a user using another user's data to attempt to hide his malfeasance; it fooled the admins for about 5 minutes. Fortunately one of the admins was logged on when this started, otherwise it would not have been possible to assign a root cause to this outage. It did cause the admins to more strictly protect user data. Other than network issues, there have been no z/OS outages since early May.

steve-myers wrote:I said this before and I will say it again. SYSADM is a user.

You will never have to say it again to me (and I apologize). The particular HLQ SYSADM was accessory to my remark; I just thought that having some SYSFAN data sets "you can read me" and some SYSFAN datasets "don't touch me" makes thing slightly difficult. By moving the latter to a new HLQ, rule of usage no 1 would indeed apply (which I now realize would make it unnecessary to warn users about them).

steve-myers wrote:The outage at the end of April and extending into May was caused by a user using another user's data to attempt to hide his malfeasance; it fooled the admins for about 5 minutes. Fortunately one of the admins was logged on when this started, otherwise it would not have been possible to assign a root cause to this outage. It did cause the admins to more strictly protect user data. Other than network issues, there have been no z/OS outages since early May.

When "JES2 got hosed"? I remember. And I understand, believe me.

Yours truly,

Rene FERLAND, Montreal