IFS, creating files in user-defined IFS-directory - *PUBLIC authority

[christoph_ostrop]

as i have learned, that a systemcopy on IBM-i is not a systemcopy

http://scn.sap.com/thread/3511183

in the target system of that kind of system copy (creating new sap system with restored data from a source-system) maybe there happened some (default) changes in creating files from a sap system to IBM-i IFS directory, especially the *PUBLIC authority ???

all higher directorys have authority *PUBLIC *RWX and all data authority, but new created files in user-defined IFS-directory did not have *public options set (by default) ?

is this behaviour new to new sap systems (because of higher security thinking by sap?)

and

how to change this (default) setting for new created files in IFS ?

[Former Member · Accepted solution]

Hi Christoph,

when you refer to a UDFS, are you just referring to the default ROOT (/) file system or to anyother FS created with CRTUDFS? What specific file are your referring to?

If the UDFS was created explicitly, there are options to specify public access for any created file. Could thi maybe be the case?

Best regards,

Luis

[christoph_ostrop · Accepted solution]

Luis B Gonzalez-Suarez wrote:

Hi Christoph,

when you refer to a UDFS, are you just referring to the default ROOT (/) file system or to anyother FS created with CRTUDFS? What specific file are your referring to?

If the UDFS was created explicitly, there are options to specify public access for any created file. Could thi maybe be the case?

Best regards,
Luis

it is the default ROOT (/) file system on the same host as the sap database is located.

[Former Member · Accepted solution]

What specific file your are referring to? Any file created by the installation or the SAP system should at least have r3group as a primary, which your file doesn't appear to.

[christoph_ostrop · Accepted solution]

it is an file export from ERT100 (ECC sap system)

which should be read by an PI-System with file-adapter .............

the owner of the directory is R3OWNER and *PUBLIC (of directory) has all authority.

but files, created within this directory,  have not all *Public authority.

[thomas_obermeier · Accepted solution]

Hi Christoph,

Assuming that a freshly installed system has neither rdisp/umask nor install/umask set explicitly I am not surprised of what you describe. rdisp/umask is empty by default. If it is not set OPEN DATASET falls back on install/umask, which defaults to '007', which again implies that public has no data access to the resulting file.

So my suggestion is to look up the two parameters in your original system and set them accordingly in the copied one. Refer to note 68718 for a little background.

Hope that helps

Thomas

[christoph_ostrop · Accepted solution]

Thomas Obermeier wrote:

Hi Christoph,

Assuming that a freshly installed system has neither rdisp/umask nor install/umask set explicitly I am not surprised of what you describe. rdisp/umask is empty by default. If it is not set OPEN DATASET falls back on install/umask, which defaults to '007', which again implies that public has no data access to the resulting file.

So my suggestion is to look up the two parameters in your original system and set them accordingly in the copied one. Refer to note 68718 for a little background.

Hope that helps
Thomas
 

Hi, Thomas,

yes, that is the correct answer. Thank you !

in the source-system:

in the target system (new system as result of system copy)

is there a list of all changed default-values of such profile parameter available ??

??? http://scn.sap.com/thread/3515029

it is not funny, to search for that changes by running in such error situations !  

the fact is, that the target system (of system copies) shows a different behaviour as the original system, that is not good.