RTC zOS Personal Dependency Builds - why are USS files/folders owned by build engine user ID when authentication override has been provided?
A personal build provides for building (compile, link, etc.) source changes after checking the changesets in and prior to delivery of the changesets to a stream. A developer can verify a "clean" compile and do initial testing of the changes before committing the changesets to a stream where they become available to other developers.
Typically you would use Authentication Override when running a personal build and "direct" the outputs to a "Dataset Prefix (HLQ) that you have access to as well as an OMVS "Load Directory" that you also have appropriate access to since the "default" build engine user would not have access to your "personal space". In the past I have noticed and still notice that some of the "Load Directory" files/folders created during a personal build are actually owned by the "default" build engine user and not by my ID which I provide by authentication override and I am not able to delete those files/folders. Why are they not owned by my ID? |
4 answers
Are you seeing the files in question being created in the directory specified for the default build definition user or are they being created in the personal USS directory specified but the files are owned by the builder used id? Aso, what files specifically are you seeing this happening to?
|
|
The folder/files in question are being created in the personal USS space. All files are owned by the default build engine user even though authentication override was used. Many files are set with permissions where the personal USS owner could delete them but the "personal build load directory" has permissions where only the owner can delete it and when created by the bfagent the owner is the build engine user instead of the authentication override user. I am sending you (Guy) screen shots via a separate note.
|
|
We had an initial go at recreating this and could not. Could you please supply the build log and the version of RTC that you are using.
|
|
We have tried recreating this in a 3.x environment and still do not see it happening. I think you need to open a PMR for this. For the PMR I would strongly suggest that you start with a set of completely empty directories and record some step by step instructions. For example, there is no mention in this thread about using buildable subsets and yet the log implies that you are. Also, in the email threads I have seen I caught sight of...
"Ok - let me see what kind of response I get from support. Based on the ls -l list it does appear that you could actually delete most files under testbuild1 except perhaps the ISPF log file. "
....which is a little confusing and implies that perhaps this is working ok
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.