banned ?

This forum provides the support of Dezhi Mainframe systems. Please post your questions about logon, usage of our mainframe environment.

Moderators: sysprog, prino, sfan, steve-myers, Tim001

banned ?

Postby jkzup » Mon 14 Apr 2014, 18:59

I just tried to logon to TSO and on the password entry screen saw a message that my userid (ZUMZUP) is not authorized to use TSO. My logon attempt with my current password was rejected. Clearly, I have been banned. What I don't understand is why. I would appreciate if someone would clarify what I have done wrong.

Thank you

JK Zup
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

Re: banned ?

Postby steve-myers » Mon 14 Apr 2014, 22:34

You kept looking at a data set that starts with
Code: Select all
*** USERS LOOKING AT THIS DATA SET ARE SUBJECT TO BEING ADDED TO IT ***

In fact, for a while, there was a message in the data set directed at you though it's no longer there, and I know you saw the message. You kept ignoring the messages.
steve-myers
 
Posts: 451
Joined: Tue 04 May 2010, 15:43

Re: banned ?

Postby jkzup » Mon 14 Apr 2014, 23:39

Hello Steve, thanks for your reply.

I don't recall doing anything other than editing my own datasets and running my PL/I compile jobs during my TSO sessions for at least the last several weeks. I'm still not sure what message it was that you say I repeatedly ignored. Further, if the dataset you mention was one I should not have accessed, shouldn't I have received notification of my having caused a RACF violation? If I try to read a dataset to which I have no authorization, I will get a message including "ACCESS INTENT(READ) ACCESS ALLOWED(NONE)" but I know I have received no such messages at all this year. If you can inform me as to when and how often I accessed the dataset, and the text of the message you claim I ignored, it would be very helpful.

Thank you.

JK Zup
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06

Re: banned ?

Postby steve-myers » Tue 15 Apr 2014, 01:28

The data set is accessed once, as part of the logon process. This access is ignored in the access analysis, but it is why there is no RACF violation.

Code: Select all
ZUMZUP   2014/03/20  2:24:17 PM 2  3:09:59 PM
ZUMZUP   2014/03/24 10:50:00 AM 2  2:55:51 PM
ZUMZUP   2014/03/25  5:03:40 PM 3  8:45:39 PM
ZUMZUP   2014/03/25  9:08:08 PM 2  9:15:46 PM
ZUMZUP   2014/03/26  2:35:56 PM 11  6:37:52 PM
ZUMZUP   2014/03/29  3:46:19 PM 2  5:21:44 PM
ZUMZUP   2014/04/01  9:49:32 AM 2 12:02:27 PM
ZUMZUP   2014/04/01  3:41:43 PM 2  4:56:24 PM
ZUMZUP   2014/04/01 11:08:41 PM 2 11:51:34 PM
ZUMZUP   2014/04/04  4:49:40 PM 2  5:39:35 PM
ZUMZUP   2014/04/07  5:48:12 AM 2  6:50:23 AM
ZUMZUP   2014/04/07  8:13:42 AM 2  8:29:49 AM


The first time stamp is the session logon date and time. The second time stamp is the time of the last access to the data set in the session. The number between the time stamps is the total accesses to the data set in the session; the program does not report sessions with one access. The date and times are the system date and time, not your local date and time.

Something like this -

GOOFUSS 2014/03/29 7:10:38 PM 2 7:15:07 PM

is ignored, provided it is not repeated, but, as you can see, you kept repeating your accesses, despite a multitude of warnings.

The admins do not want people reading the data set, for reasons I will not disclose in a public forum.
steve-myers
 
Posts: 451
Joined: Tue 04 May 2010, 15:43

Re: banned ?

Postby jkzup » Tue 15 Apr 2014, 05:57

Hello Steve,

Thank you for your explanation and analysis. I can only assert that I did not explicitly read the dataset, because on all the dates you listed all I did was browse and edit my own datasets and submit jobs to compile and bind my PL/I programs. Since I surely cannot access your dataset by just browsing and editing my own datasets, I must have implicitly read your dataset as a result of running my PL/I compile/bind background jobs.

Indeed, I just recalled that on 3-26 I modified one of my PL/I subroutines that is used by several other PL/I programs I have written. After I recompiled the subroutine, because my JCL creates only a temporary object module that is then binded to create a load module, I had to recompile each program that needed the subroutine, so that they would subsequently be rebinded with the subroutine's new load module included. I had to repeat the series of compiles when I had to correct a mistake I had made in recoding the subroutine and when I wanted to add some more functionality to it. The repeated runs of my complie/bind job likely led to the 11 accesses of your dataset by my userid on 3-26. On the other dates you gave, I did runs of my PL/I compile/bind but not as often as I did on 3-26. For example, I remember that on 3-25 I logged on, made a change to one of my PL/I source modules, then ran my job to recompile/rebind it, after which I soon logged off. I then conceived another change I wanted to make in my source code, hence I got back on, made my change, reran my job to recompile and rebind, then logged off again. That is why you have two lines for 3-25 in your list.

I suspect that even though the JCL I use to compile and bind my PL/I programs simply invokes the PL/I compiler and feeds the resulting object module (which the compiler places in a temporary dataset, since to save space on the disk pack I don't use an object-module library) to the binder to make the load module, somehow my job must be accessing your dataset without my knowing that it is doing so. I can also state that I have been using this same JCL stream for my PL/I compile/bind runs for at least the last year, but alas, only in the last couple of weeks has it somehow begun accessing your dataset. That would explain the access counts you listed. However, given that I haven't changed my JCL stream in at least a year but these phantom accesses have been happening only within the last couple of weeks, I could not have known that my job was doing anything besides the compile/bind it is supposed to do. If a system change resulted in my PL/I compile/bind job implicitly accessing your dataset, I could not have known about it; at very least I surely would never knowingly repeatedly access any dataset to which I lack proper authorization. I have made it my policy to explicitly use and access only my own datasets, so that I don't interfere with anyone or anything else on the system.

Also, after my job finishes, I view its held output under SDSF and then purge the output to avoid having my jobs tie up the spool. I wonder if doing so might also implicitly access your dataset; but again if so it would be because of a system change done within the last two weeks or so, yet I've been using SDSF to view and purge my job output ever since I joined the system in 2009.

Neither the subroutine I modified on 3-26, nor any of my other PL/I programs, explicitly refers to any datasets other than my own.

I hope this clarifies the issue. Again, I can only maintain that I never knowingly repeatedly access any datasets to which I do not have proper authority. If I did read your dataset it could only have been through implicit accesses I had no reason to expect or believe were occurring.

Thank you for your consideration.

JK Zup
jkzup
 
Posts: 37
Joined: Tue 16 Jun 2009, 20:06


Return to Dezhi systems: Mainframe

Who is online

Users browsing this forum: No registered users and 5 guests

cron