Sequential File Permissions From Scheduled (cron) Jobs

[kh]

We are currently in the process of trying to "lock down" access to our production environment, but in the meantime there is more than one user who has access to schedule jobs there. I have run into an issue where a re-scheduled job has failed because the job's reject (flat) file was originally created by another user and the permissions are rw-r--r--.

I am pretty familiar with the deal with umask and "umask 002" exists in both the DS startup script and all "dstage" group users' .profile(s). However, here is the behavior I have found. When User X logs into the server via telnet and creates a file, it's permissions are rw-rw-r--. When User X manually runs a job through Director and creates flat files, their permissions are rw-rw-r--. When User X schedules a job for later today (utilizes "at") and creates flat files, their permissions are rw-rw-r--. But when User X schedules a job to occur daily (utilizes "cron") and the creates flat files, their permissions are rw-r--r--.

What is happening? Have I missed a umask statement somewhere or is this just the way it works (and one of the reasons why only one user should run/schedule jobs in production)?

[kduke]

Kevin

All permissions should be the same because these jobs are run as phantoms. Your .profile or /etc/profile are not executed because the cron does not login. cron jobs have no shell associated with them. umask can be set in the dsenv file and DataStage will need to be stopped and started for this to take effect.

umask can be controlled by the parent directory. If the group id is set on the parent dir then anyone in the group can control the files in that dir. All the projects are created this way with all the directories having the group id set so anyone in the group can recompile jobs created by another user. You need to set this on files in data directories or set umask in dsenv in the DataStage engine directory.

The only other way to fix umask is to set it system wide in the UNIX kernel. You have to recompile the kernel afterwards. Not a good solution because if you upgrade your OS then it sometimes goes back to 022 and not 002 which is what you want.

[tonystark622]

I just ran into this problem with DataStage v6.0.1. I contacted Ascential support about it. Eventually we worked out the exact scenario that you mentioned above. The fix was to put the "umask 002" command in the dsenv file, (we only had it in the start up script (the "rc" file)). After that recurring scheduled jobs worked the same as non-recurring scheduled jobs and jobs run manually.

Sounds weird, I know, but the 2nd level support person duplicated it on her own server.

Hope this helps,
Tony