Document ID : KB000028279
Last Modified Date : 14/01/2019
Show Technical Document Details

Why don't REPLACE, APPEND AND CREATES honor the UMASK parameter for a remotely initiated transfer?

If you initiate a receive on your UNIX system, the UMASK parameter will force the file being created to have the access permissions indicated by the octal number assigned to the parameter. But what if you want this same type of control for a remotely initiated transfer? How do you dictate what UMASK will be used for the file created on the UNIX box?

Used to set the permissions assigned to a file when the file is being created and received on a UNIX system for the first time. The value is expressed as an octal number (base 8). The octal number has the same meaning as in the standard UNIX umask command. This is used only for locally initiated transfers.
Note: Not used for IBM 4680/4690 systems.
Range 000 - 777
Default 022

One solution is to force XCOM to create all incoming files with a fixed, user defined UMASK on remotely initiated transfers. How is this possible? When a file is received by XCOM, it is received into a temporary file. Only when the filetransfer is complete, is that file closed and then renamed to the target filename specified in the transfer request. We can force XCOM to open this temporary file with a particular UMASK. When the temporary file rename occurs, the UMASK is retained for the specified filename. The mechanics for setting this up are as follows:

How to set appropriate permissions for incoming file transfers

Code the xcompp post processing script (found in /usr/lib/xcom) to perform a chmod against the temporary file created by XCOM when receiving the file. At the very end of the xcompp script (where it says "POSTPROCESS HERE") code:
   chmod xxx $tmp_file
   where 'xxx' is the numeric file permissions, e.g., '644'.
Also, change the following two lines in the xcompp script:
   'tmp_file==$1' should be changed to 'tmp_file=$1' and
   'file==$1' should be changed to ' file=$1'
This will change the permissions of every incoming file being transferred to XCOM/UNIX.

An important note: Response time and timing issues differ from UNIX system to UNIX system. On some systems it is possible that the transfer will proceed so quickly that the post processing script will not have the opportunity to modify the UMASK prior to the opening of the temporary file when it begins to accept the transferred data. If such is the case on your system, use the variable $file in the script, and not $tmp_file. So for this scenario, code the xcompp post processing script (found in /usr/lib/xcom) to perform the chmod as:   chmod xxx $tmp_file
   where 'xxx' is the numeric file permissions, e.g., '644'."
at the very end of the xcompp script (where it says "POSTPROCESS HERE").

Lastly, we should mention that prior to XCOM for UNIX version 3.00.0104d,transfers that created a file where either FILE_OPTION=REPLACE or FILE_OPTION=APPEND was specified, XCOM for UNIX would create the file with a UMASK of 666 instead of the value specified by the CA XCOM UMASK parameter. In versions 3.00.0104d or later, the CA-XCOM UMASK parameter is honored for locally initiated transfers.