by 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