Definitions of Platform-independent File Names

The conversion of a platform-independent file name to a platform-specific one is controlled by definitions that are stored in tables. These definitions refer to the following objects:

  • Operating systems and Syntax groups
    All operating systems are assigned to syntax groups. A syntax group is a group of operating systems that share a common syntax for file names and paths. The definition of a syntax group specifies, for instance, how long file names may be, and whether file name extensions are permitted or not.
  • Logical file name
    A logical file name is a platform-independent descriptive name for a file to be stored in the file system. Its definition applies to all clients of an R/3 system. In addition, it is possible to specify client-specific definitions of a logical file name.
  • Physical file name
    A physical file name is assigned to every logical file name.
  • Logical path
    A logical path is a platform-independent descriptive name for a path where files are to be stored. For the conversion of a logical file name to work for different platforms, it is necessary that a logical path be assigned to that logical filename.
  • Physical path
    One or more physical paths are assigned to a logical path, each one applying to a different syntax group (platform).

The following figure shows the relationships between these objects that determine how a logical file name is converted to a platform-specific file name:

Parameters in physical file names and paths

Physical file names and paths may contain the following keywords enclosed in angle brackets which are replaced at runtime:

Table: Keywords

Keyword

Substitution Value

<OPSYS>

operating system according to function module FILE_GET_NAME

<INSTANCE>

instance of R/3-system

<SYSID>

name of R/3-system according to system field SY-SYSID.

<DBSYS>

database system according to system field SY-DBSYS

<SAPRL>

R/3-Release according to system field SY-SAPRL

<HOST>

host name according to system field SY-HOST

<CLIENT>

client according to system field SY-MANDT

<LANGUAGE>

logon language according to system field SY-LANGU

<DATE>

date according to system field SY-DATUM

<YEAR>

year according to system field SY-DATUM, 4-character

<SYEAR>

year according to system field SY-DATUM, 2-character

<MONTH>

month according to system field SY-DATUM

<DAY>

day according to system field SY-DATUM

<WEEKDAY>

week day according to system field SY-FDAYW

<TIME>

time according to system field SY-UZEIT

<STIME>

hour and minute according to system field SY-UZEIT

<HOUR>

hour according to system field SY-UZEIT

<MINUTE>

minute according to system field SY-UZEIT

<SECOND>

second according to system field SY-UZEIT

<PARAM_1>

value of Parameter 1 in function module FILE_GET_NAME

<PARAM_2>

value of Parameter 2 in function module FILE_GET_NAME

<P=name>

value of profile parameter of current system

<V=name>

value of variable as defined in variable table

<F=name>

value of export parameter OUTPUT of a function module

All physical paths must contain the keyword <FILENAME> as a placeholder for the file name.

Inclusion of these parameters in physical file names and paths helps to both differentiate and standardize the assignment of file names. The keyword <TIME>, for instance, can be useful when a file needs to be stored several times in a row within a short time interval. Apart from the system fields, the following keywords, in particular, give you considerable flexibility in assigning file names:

  • <PARAM_1> and <PARAM_2> are replaced by values that are passed explicitly to the function module FILE_GET_NAME in your program.
  • <P=name> is replaced by values of profile parameters of the current system. To get the list of profile parameters and their values, start report RSPARAM.
  • <V=name> is replaced by values of variables from the customizing tables for platform-independent file names.
  • <F=name> is replaced by values that are returned by function modules. The names of these function modules must have the prefix "FILENAME_EXIT_". Note that in the keyword such a function module is addressed only with the part of its name that follows this prefix. For example, when the function module FILENAME_EXIT_EXAMPLE is used, the appropriate keyword would read <F=EXAMPLE>.
    The function module used must have the export parameter OUTPUT and no reference type must be specified for this parameter. Import parameters must have default values. Table parameters are not supported.