Profile parameters accompany the SAP Basis administrators their entire lives. Still, in many SAP systems one can find sub-optimal handling of those and when it comes to monitoring or compliance checking one may be curious how to determine the currently effective values. This may be from a special interest if one considers to implement a tool for compliance checking.

In this blogpost I like to give a brief overview about profile parameters, maybe some handling tips and evaluate how the effective profile parameter values can be determined.

Updates:

2021-06-01: Added section for checking profile parameters on ABAP on HANA using a sql script
2021-05-23: Refined the details in all check methods.

Effective Parameters

At first we must know that many profile parameters have a so called „kernel default value“. This value is compiled into the kernel and will take effect if it is not overwritten by other means – we will come to that in a few.

We can display the kernel default values of all parameters recognized by the actual SAP kernel for example by running the command sappfpar all on OS-level as user <sid>adm.

Please note: Looking at the output we may find some profile parameters which have no kernel default value and some parameters are entirely unknown to the kernel and therefore are not listed in the output at all. Values for these profile parameters must then be set explicitly in a profile file. An example would be the parameters ccl/* to setup the CommonCryptoLib.

The kernel default values might change with newer releases or patch levels of the SAP kernel. New sub-parameters might be added to existing profile parameters. Furthermore, completely new parameters may be added and in rare cases parameters get removed.

To make profile parameter values configurable and persistent they can be defined and stored in profile files. At system startup the profile parameters’ values are read from the profile files residing on the filesystem. This happens in the following order:

With this, we must keep in mind: A value from the instance profile might oversteer a value from the DEFAULT.PFL. In some cases this may be used by intention, in others not.

Determine the correct profile for a parameter and use variables to define its value

As a rule of thumb instance profiles should contain only parameters which are specific for the particular instance.
And in addition – if you like – only if there is no variable available which can be used to make values instance specific while defining them in the DEFAULT.PFL.

To make this concept more clear I like to give an example for that based on the profile parameter icm/HTTP/logging_<xx>:

We should prefer to set
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=$(DIR_LOGGING)$(DIR_SEP)↵
icm_http_server_$(SAPSYSTEMNAME)_$(INSTANCE_NAME)_$(SAPLOCALHOST)-%y-%m-%d.log
in the default profile over setting
icm/HTTP/logging_0 = PREFIX=/,LOGFILE=/usr/sap/NPL/D00/log/↵
icm_http_server_NPL_D00_vhcalnplci-%y-%m-%d.log
in the instance profile.

In this example we also made the value independent from the operating system by specifying the path by the variable $(DIR_LOGGING) and the delimiter using $(DIR_SEP). So no matter how many instances our system has, even if heterogenous, we can rely on the desired value will take effect on each instance.

Having a closer look at the kernel default value of the profile parameter DIR_LOGGING we will see that it is specified as $(DIR_INSTANCE)$(DIR_SEP)log. And DIR_INSTANCE is specified as $(DIR_SEP)usr$(DIR_SEP)sap$(DIR_SEP)$(SAPSYSTEMNAME)$(DIR_SEP)$(INSTANCE_NAME). For DIR_SEP the kernel default value is hard coded in the OS-specific SAP Kernel, for Linux it is /. So we can note: Even nested usage of variables is possible.

Precisely, there are only very few profileparameters which must be set in the instance profile. Some parameters are for example flagged as system-wide when being displayed in transaction RZ11 and therefore should never be set in the instance profile.

Please note: The only deviation I came across are the rdisp/wp_no_* profile parameters which need to be set explicitly in the instance profile to be recognized correctly by the  “Operation Modes and Instances” editor of transaction RZ04. A warning will be displayed if these profile parameters are not present in the instance profile. Even though, the values for these profile parameters would be correctly determined and used if they would be defined in the default profile only.

Maintaining profile parameter values

For maintaining profile parameter values we have basically two possibilities.

1. Maintain the profile files on the OS-level using your preferred text editor.
2. Logon to the system and use transaction RZ10.

Please note: In RZ10 the instance profile of the ASCS instance (/usr/sap/<SAPSID>/SYS/profile/<SAPSID>_ASCS<nn>_<hostname>) could be included after implementing SAP Note 2789094.

Profile parameter values become effective during the system startup. Some time this is also referred as ‘they become “activated”‘.

Change profile parameter values at runtime

For some profile parameters it is possible to change their value at runtime. These changes are withdrawn after a system restart.

We can change profile parameters via web methods offered by the SAP Instance Agent (aka SAP Start Service):
sapcontrol -nr <Inst-No> -function [SetProcessParameter|SetProcessParameter2]

On AS ABAP changes during runtime can be performed for example using transaction RZ11 or Func TH_CHANGE_PARAMETER. Some components like the ICM will recognize changes and will perform a soft-restart, others will just use the new value for their next task execution.

Please note: There are a few profile parameters which allow a change at runtime depending on their current value. This is for security reasons.

Checking profile parameter values

Since the effective profile parameter values are calculated as described above, it is not that easy to determine them. Depending on the method used to check the values the relevant origin of the effective value might not be considered and therefore the result may not reflect the correct value. Let’s have a look at some common methods for checking profile parameter values.

SAP Instance Agent

We can display all profile parameters known to the current SAP kernel and their values via three different web methods offered by the SAP Instance Agent (aka SAP Start Service):

sapcontrol -nr <Inst-No> -function ParameterValue

• The displayed values are the values which have been effective at the last system startup.
• Parameter values changed at runtime are not recognized.
• Only substituted values are displayed.
• Profile parameter values added or modified in any profile file at runtime typically are not recognized. After a restart of the sapstartsrv they are recognized even if a restart is required for them to take effect.
• Values for profile parameters unknown to SAP kernel are only displayed if they are defined in any profile file.

sapcontrol -nr <Inst-No> -function GetProcessParameter <ICM|"Web Dispatcher"|MessageServer|Gateway|EnqueueServer|Dispatcher>(displays also description and all available sub-parameters)

• The displayed values are the values which will be effective after the next system startup. Profile parameter values added or modified in any profile file at runtime are not recognized.
• Parameter values changed at runtime are not recognized.
• Only substituted values are displayed.
• Values for profile parameters unknown to SAP kernel are not displayed. (Maybe because they are not assigned to one of the groups)

sapcontrol -nr <Inst-No> -function CheckParameter

• The displayed values are the values which will become effective after the next system startup. Profile parameter values added or modified in any profile file at runtime are recognized immediately even if a restart is required for them to take effect.
• Parameter values changed at runtime are not recognized.
• Substituted values as well as unsubstituted values (listed as “definition”) are displayed.
• Values for profile parameters unknown to SAP kernel are only displayed if they are defined in any profile file. A warning for the unknown parameter will be displayed.

For all of these web methods:

• The check must be performed for every instance to get the full picture. Sapcontrol supports you on that: It can query the web methods on remote hosts using the -host and -port options.

Please note: Some parameters are only relevant for a certain type of instance. So, we may decide to determine the parameter value only for a particular instance. We can find the instances of a system and the “features” each one provides by running sapcontrol –nr <Instance-no> -function GetSystemInstanceList.

sappfpar

We can also use the kernel tool sappfpar to display all profile parameters known to the current SAP kernel and read the values directly from the specified profile on filesystem:

sappfpar pf=<profile> (interactive mode)
sappfpar all pf=<profile>

• The displayed values are the values which will become effective after the next system startup. Profile parameter values added or modified in any profile file at runtime are listed in the output immediately even if a restart is required form them to take effect.
• If executed for the default profile, the unsubstituted values from the default profile are displayed (the instance profile is not recognized). The values displayed in column “SAP:” are the kernel default values.
• If executed for an instance profile, the unsubstituted values for the instance related to that instance are displayed (the default profile is also recognized). The values displayed in column “SAP:” are the values from the default profile or the kernel default values.
• Parameter values changed at runtime are not recognized.
• Values for profile parameters unknown to SAP kernel are displayed.
• It must be performed for every instance profile to get the full picture.
• There is also an interactive mode which displays the origin of an profile parameter value which will become effective after the next system startup sappfpar pf=/sapmnt/$SAPSYSTEMNAME/profile/DEFAULT.PFL get_origin

sapparar

We can also use the kernel tool sapparar to display all profile parameters known to the current SAP kernel and read the values directly from the specified profile on filesystem:

sapparar all pf=<profile>

sapparar <parameter> pf=<profile>

• The displayed values are the values which will become effective after the next system startup. Profile parameter values added or modified in any profile file at runtime are listed in the output immediately even if a restart is required form them to take effect.
• If executed for the default profile, the substituted values from the default profile are displayed (the instance profile is not recognized). The values displayed in column “SAP:” are the kernel default values. The values displayed in column “User:” are the effective values for any instance without an instance profile holding values tailored specific to the same instance.
• If executed for an instance profile, the substituted values for the instance related to that profile are displayed (the default profile is also recognized). The values displayed in column “SAP:” are the values from the default profile or the kernel default values.
• Parameter values changed at runtime are not recognized.
• Values for profile parameters unknown to SAP kernel are displayed.
• It must be performed for every instance profile to get the full picture.

cat & grep

Last we can simply cat and grep through all profile files on the OS-level (DEFAULT.PFL, instance profiles) as all profiles of all instances of the same system reside in the same directory (/sapmnt):

cat DEFAULT.PFL $SAPSYSTEMNAME_<instance_name>_<hostname> $SAPSYSTEMNAME_<instance_name>_<hostname> | grep ^<parameter>

• The displayed values are the values which will be effective at the next system startup. Profile parameter values added or modified in any profile file at runtime are listed in the output immediately even if a restart is required form them to take effect.
• This method does not recognize the kernel default values.
• It does not recognize parameter values changed at runtime.
• It does not consider substitution of variables or arithmetic formulas.
• It does not recognize the effective profile parameter values per instance.
• Values for profile parameters unknown to SAP kernel are displayed.
• For the SAP Host Agent this is the only available method to display profile parameter values. There is nothing how to determine for which profile parameters which kernel default values are used.

Checking profile parameters when logged on to SAP NW AS ABAP

Besides the methods to query the profile parameter values from the outside at least for AS ABAP we have some possibilities to get the values when logged on.

Transaction RZ10

We can display the profiles using transaction RZ10.

• This displays the profile parameter values as they are stored in the table TPFET (see below how the entries to this table are populated).
• The displayed values are the values which will become effective after next system startup. Profile parameter values added or modified in any profile file at runtime are listed in the output immediately even if a restart is required form them to take effect.
• Values for profile parameters unknown to SAP kernel are displayed.
• After SAP note 2789094 was implemented, the instance profile of the ASCS instance can be displayed.

Transaction RZ11

We can display the profiles parameter values using transaction RZ11. It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values to determine the values.

• Profile parameter values added or modified in any profile file at runtime are not recognized in the output.
• It displays unsubstituted values for the kernel default value.
• It displays also the profile parameter values changed at runtime.
• Values for profile parameters unknown to SAP kernel are not displayed.
• Profile parameter values efficient at the ASCS instance can‘t be listed, even after SAP note 2789094 (at least at time of writing).
• The check must be done for every instance.

Table TPFET

We can display the profile parameter values stored in the table TPFET.

• The entries are populated when profiles are maintained and saved in transaction RZ10 or after importing the profile files via the related functionality in transaction RZ10, when maintained on OS-level.
• The displayed values are the values which will be effective at the next system startup. Profile parameter values added or modified in any profile file at runtime are listed in the output immediately even if a restart is required form them to take effect.
• This table holds the profile parameter values of the profile files, it does not contain the kernel default values.
• It contains only substituted values.
• Values for profile parameters unknown to SAP kernel are displayed.
• After SAP note 2789094 was implemented, profile parameter values stored in the instance profile of the ASCS instance are also in there.

Table PAHI

We can display the profile parameter values stored in the table PAHI.

• The entries are populated hourly by the background job SAP_PERFMON_RSSTATPH (triggered by job SAP_COLLECTOR_FOR_PERFMONITOR) which runs the report RSORA110. This uses the (legacy) Kernel call “CALL ‘C_SAPGPARAM’” (like FuBa RSPO_R_SAPGPARAM does).
• Until population it holds only the history, not the current state!
• The displayed values are the values which will be effective at the next system startup. Profile parameter values added or modified in any profile file at runtime are not recognized.
• After population it holds also the profile parameter values changed at runtime.
• It contains only substituted values.
• Values for profile parameters unknown to SAP kernel are contained only if they have been activated during the last system startup.
• Profile parameter values defined in the instance profile of ASCS aren’t listed, even after SAP note 2789094 (at least at time of writing).
• When changing the same parameter multiple times only the value active at runtime of the report RSORA110 is populated to the table.
• Only one parameter change per day is recognized because the field PARDATE holds only the date and not a timestamp of the last parameter change.

Report RSPFPAR

We can use the report RSPFPAR (which is also called by RSPARAM). It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values (by utilizing the class CL_SPFL_PROFILE_PARAMETER).

• The displayed values are the values which have been activated during the last system startup.
• It displays also the profile parameter values changed at runtime.
• It contains unsubstituted values at least for the kernel default value (here listed as “System Default Value”).
• Profile parameter values added or modified in any profile file at runtime are not recognized.
• Values for profile parameters unknown to SAP kernel are listed in the output only if they have been activated during the last system startup.
• Profile parameter values defined in the instance profile of ASCS aren’t listed, even after SAP note 2789094 (at least at time of writing).
• The check must be done for every instance.

Function module TH_GET_PARAMETER

We can use the function module  TH_GET_PARAMETER. It uses the ABAP Kernel modules sapparam_km_get_all_parameter and sapparam_km_get_all_values

• It displays also the profile parameter values changed at runtime.
• It displays only substituted values.
• Profile parameter values added or modified in any profile file at runtime are not recognized.
• Values for profile parameters unknown to SAP kernel are displayed.
• Profile parameter values defined in the instance profile of ASCS aren’t listed, even after SAP note 2789094 (at least at time of writing).
• The check must be done for every instance.

Checking profile parameters for ABAP on HANA

SQL script HANA_ABAP_Parameters

SAP provides a lot of useful sql scripts published in SAP note 1969700. In this package also the script HANA_ABAP_Parameters is included which can be used to query the table PAHI.

Please note: Due to the limitations mentioned for table PAHI, parameters of the ASCS instance can not be checked using this script.

Checking profile parameters using SAP Solution Manager / SAP Focused Run (FRUN)

“Configuration Validation” or “Configuration and Security Analytics“ (CSA)

In SAP Solution Managers’ “Configuration Validation” or in FRUNs’ “Configuration and Security Analytics“ (CSA) validation the profile parameter values can be checked for compliance. In order to do so,

• for AS ABAP the ABAP_INSTANCE_PAHI ConfigStore in the CCDB is filled daily by the extractor framework with the data from the managed systems.

Please note: As its name indicates, it is filled with entries from the table PAHI. Due to the limitations mentioned for table PAHI, parameters of the ASCS instance can not be checked using this store. A similar workaround as described below for SAP Web Dispatcher might be used.

In addition to that the ConfigStores ABAP_DEFAULT_PROFILE, ABAP_INSTANCE_PROFILE and ABAP_ASCS_PROFILE (Store type: TEXT) are available,

Please note: The limitations of these ConfigStores are described in the blogpost linked below.

• for AS Java the „Parameters“ ConfigStore is available,
• for SAP Web Dispatcher the ConfigStore INSTANCE_PROFILE (Store type: TEXT) is available.
  How to use this for compliance checks is described in the detailed blogpost How to monitor standalone (non-ABAP) Web Dispatcher Security in Solution Manager written by Kai Bauer (which inspired me to write all this),
• for SAP HANA no ConfigStore for profile parameters is available and therefore no checks can be performed,

Please note: The parameters for SAP HANA itself are stored in the .ini files, while the profile files hold the profile parameters for SAPStartSrv, CommonCryptoLib, etc.

• for SAP Host Agent the “host_profile” ConfigStore (Store type: TEXT) is there.

Checking profile parameters using other tools/workflows

Combining AWS services to carry out a parameter check

The blogpost Compliance Check of SAP Systems Using AWS by Jaskirat Singh describes very detailed how to combine AWS services to a custom compliance checker which utilizes the web method ParameterValue of SAP Instance Agent.

Conclusion on how to check profile parameter values

Sadly we can not rely on the central monitoring tools provided by SAP to get this job in general comprehensively done. There are some drawbacks for example when it comes to checking profile parameter values related to the ASCS instance or to check whether profile parameter values are defined by using variables.

Also if we like to implement a custom compliance check we must consider what capabilities the utilized check method provides and what exactly we can expect from them.

For (near-)real-time checking of the effective profile parameter values, whether the parameters are known by the SAP kernel or not, on a SAP NW AS ABAP system the method of choice seems to be the function module TH_GET_PARAMETER.