Christopher Smith wrote:
I actually believe that in the case of '2' that the implementation should raise a fault and not create the directory. First off, I don't believe that any of the existing low-level batch systems will do this creation for you, and supporting these batch systems is a primary goal of the HPC Profile. Second, I'm not a big supporter of "implied" behaviour. That is, there is a side-effect that a directory is created when this job is run. I'd prefer that a user needs to make sure the directory exists if they are specifying a working directory (using working directory seems to imply that the user knows a fair bit about the execution environment).
As for 3, I agree. It's up to the implementation to document it's behaviour.
According to my perspective, everything's OK as long as what happens is all clearly documented. :-) Maybe could even state that this is part of the profiled set of information a BES publishes about itself? In any case, the real interop case is #1 (specified existing dir). I raised the issue in #2 (specified non-existing dir) because requiring a fault precludes creation, which is behaviour useful for higher-level job managers, as it means that they don't need to take special action to create a shared directory for a group of related activities. Otherwise you end up having to do more workflow-dependency stuff in order to make the directory that the real tasks use. The standards perspective is: each case is distinct and should either have mandated behaviour, or a requirement on implementations to state what they do so that clients can discover prior to activity submission. With that, we can state that any client relying on a particular way of resolving this sort of issue (without first checking for it) is not itself strictly compliant with the profile. :-) Donal.