The SAP System OS Collector (SAPOSCOL) is a platform-independent program that runs in the background of the operating system and collects system information using a shared memory segment for multiple applications and all SAP instances on a host. These information details can be viewed through the transaction code ST06/OS06 in the SAPGUI interface. It is a very useful tool for NetWeaver/Basis administrators and consultants to monitor server performance. SAPOSCOL pulls real-time data from the system, although it is not updated automatically, you need to click the ‘Refresh’ button to get the updated data. SAPOSCOL collects data from the system every 10 seconds and logs it, and also logs the hourly averages for the last 24 hours. Exactly one process per host runs autonomously from SAP instances and collects data from various operating system resources. The user can monitor all the servers under the SAP landscape with this tool. But for the remote server (livecache server) the transaction code is OS07. You can check CPU utilization, physical and virtual memory usage, pool data/swap size, disk response time, utilization of physical disks and file systems, resource load for running processes and even LAN data from the monitoring list.

You can navigate to this tool from SAP Menu->Tools->CCMS->Control/Monitoring->Performance->Operating System->Local->Activity.

If you can’t see any data, that means OS Collector (SAPOSCOL) is not running (error code: shared memory not available). In this situation, your main task is to fix the saposcol so that it works correctly. This usually happens after a fresh SAP installation or Kernel upgrades. If you are new to SAP systems, the following guide will be helpful in overcoming the saposcol issue.

Unix/Linux/AIX/Sun/Solaris system:

First, check the permission of the saposcol.exe file, it should be 777 (owner is root in the sapsys group) and the sticky bit should be set to 4750. If you want to know which user is running saposcol, use “ps -ef | grep saposcol “. Now, to change the saposcol file to owner root, sapsys group, 4750 mode, log in as root to your Unix system and run the commands as shown below.

cd /usr/sap//SYS/exe/run

chown root toad

chgrp sapsys saposcol

chmod 4750 sapocol

You can also run “saproot.sh” in the exe directory to set the permissions. Then run saposcol -l as the same owner (root). Check the status of the collector using saposcol -s. After setting the file permissions, you can also use ST06 -> OS Collector -> Click ‘Start’ to run SAPOSCOL.

To stop the OS collector, use saposcol -k. If this command failed to kill the process, you can run “cleanipc 99 remove” (see SAP Note 548699). If this attempt also fails, you should delete the saposcol shared memory key. Run the command “ipcs -ma” and note the shared memory ID on the line containing the saposcol key. Then run the command “ipcrm -m ID”. The shared memory key will be created again the next time you run saposcol.

Sometimes using “saposcol -l” gives a message that it is already running, but when I grep the process using “ps -ef|grep -i saposcol”, it might not show the process. In this situation, you can use an undocumented parameter “saposcol -f”, where “f” means to forcefully start the process. When it starts, stop the process in the throttling method using “saposcol -k” and then start it normally using “saposcol -l”.

If saposcol is still not running, you should start it in dialog mode. Login with use adm and follow the steps below,

toadcol -d

collector > clean

collector > exit

saposcol -k to stop the collector.

Before reboot

toadcol -d

Collector > exit (you should get a message – Shared memory removed)

collector > exit

cd /usr/sap/tmp

mv coll.put coll.put.sav

CD

toadscol

“coll.put”, if this file contains the old shared memory and needs to be removed to start from scratch (See SAP Note 548699, point 7). If you are unable to clear shared memory, try the following commands to clear shared memory:

$ toadcol -kc

$ toadcol -f

If this also fails, you have to reboot from the OS level and it looks like you need a new version of saposcol as well (see SAP note 19227).

IBM iSeries i5/OS (OS/400, OS/390):

– Check the permissions of the ‘/usr/sap/tmp’ directory and the ‘saposcol.exe’ file, it must be 4755 and the owner must be root in the sapsys group. See SAP Note 790639. After assigning permissions, you can run from the operating system command line using ‘SAPOSCOL -l’. To display the status use ‘SAPOSCOL -s’ and to stop the process use ‘SAPOSCOL -k’. You can also run the process by submitting a job at the operating system level using

CALL PGM(SAPOSCOL) PARM(-l)

Submits the job on the QBATCH job queue in the QGPL library.

– On iSeries, you might experience strange data when analyzing CPU utilization with tcode ST06/OS06. Even if you are using multiple CPUs, SAPOSCOL can only report CPU usage for the first CPU. Also, you will sometimes find reported CPU usage above 100% at some intervals, if you are running an SAP instance on an unlimited partition where multiple logical partitions are using a shared processor group. In this situation, make sure that the CPU usage reported for CPU #0 is the average usage of all CPUs that are used in the system. If you want to see the shared CPU partition information, apply support packages as per SAP note 994025, including the following patch levels

6.40 disp+work package (DW): 182 SAPOSCOL: 69

7.00 availability+work package (DW): 109 SAPOSCOL: 34

When applying these patches and support bundles to your system, new transactions OS06N, ST06N, and OS07N are available for viewing additional information in two sections titled “Host System” and “Virtual System.” These include information about the type of partition and the CPU available and consumed in the current partition, as well as in the shared processor group. Therefore, if you are an iSeries user and your SAPOSCOL is not running, most likely you need to install the latest kernel and saposcol patch. (SAP Note 708136 and 753917)

– Another scenario on iSeries, when your saposcol is not running and you cannot start it from ST06/OS06. The problem could be because the R3ADMAUTL authorization list was not accurate. You can solve it this way,

1) Remove QSECOFR *ALL X

2) Change *PUBLIC from *USE to *EXCLUDE

3) Add R3OWNER *ALL X

You can now start saposcol using the ST06/OS06 tcode. And you can also start the process from the command line,

CALL PGM(/SAPOSCOL PARM(‘-l’)

If this does not solve the problem, check if both programs QPMLPFRD and QPMWKCOL in library QSYS have *USE authority assigned to the user R3OWNER (SAP Note: 175852). If not, you need to run the following commands:

GRTOBJAUT OBJ(QSYS/QPMLPFRD) OBJTYPE(*PGM) USER(R3OWNER) AUT(*USE)

GRTOBJAUT OBJ(QSYS/QPMWKCOL) OBJTYPE(*PGM) USER(R3OWNER) AUT(*USE)

You then need to check if the R3OWNER user is part of the R3ADMAUTL authority list (SAP Note: 637174). After this, if you get the error “SAPOSCOL is not running? (Shared memory not available), then follow the steps below,

1) Delete the shared memory (coll.put) as per SAP note: 189072. The location of ‘coll.put’ is: ‘/usr/sap/tmp’.

2) End jobs QPMASERV, QPMACLCT, QYPSPFRCOL, and CRTPFRDTA in QSYSWRK if they are running.

3) Delete the temporary userspace, WRKOBJ OBJ(R3400/PERFMISC*) OBJTYPE(*USRSPC)

4) ENDTCPSVR*MGTC

5) CALL QYPSENDC PARM(‘*PFR ‘ ‘ ‘) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]

6) ENDJOB JOB (xxxxxx/QSYS/QYPSPFRCOL) OPTION (*IMMED) SPLFILE (*YES) [This command must be run for all QYPSPFRCOL jobs found on the system even if they show with *OUTQ as their status]

7) ENDJOB JOB(xxxxxx/QSYS/CRTPFRDTA) OPTION(*IMMED) SPLFILE(*YES) [This command must be run for all CRTPFRDTA jobs even if they show with *OUTQ as their status]

8) RNMOBJ OBJ(QUSRSYS/QPFRCOLDTA) OBJTYPE(*USRSPC) NEWOBJ(QPFRCOLDTX)

9) RNMOBJ OBJ(QUSRSYS/QPFRCOLDTA) OBJTYPE(*DTAQ) NEWOBJ(QPFRCOLDTX) [This object may or may not exist at this time]

10) CALL QYPSCOLDTA *note This program will create a new *USRSPC. After the collection services start, there should be a new *DTAQ.

11) Initiate collection services using GO PERFORM, opt 2, and opt 1; OR CALL QYPSSTRC PARM(‘*PFR ‘ ‘*STANDARDP’ ‘ ‘) [There are 6 blanks after *PFR and there are 6 blanks making up the second parameter]. Or, start the collection services from Operations Navigator.

12) STRTCPSVR*MGTC

13) End and restart Operations Navigator if it is running. See IBM Authorized Program Analysis Report (APAR) SE12188 for more information.

14) Now start SAPOSCOL from ST06/OS06.

Windows system:

– Go to the Kernel folder on the command line where you will find saposcol.exe. Set full owner permission

for the file and the folder. Then run saposcol -l (saposcol -d in dialog mode)

– You can also try Start/Stop SAPOSCOL service from Control Panel -> Administrative Tools -> Services (services.msc).

If all other attempts fail, make sure you have the correct version of SAPOSCOL. Get the latest SAPOSCOL from the SAP Service Marketplace for your operating system. Download the SAPOSCOL.SAR file for your Kernel and save it to a directory. Then STOP SAP & SAPOSCOL. Check for kernel library crashes and don’t forget to make a backup of the library. Then run APYR3FIX and then APYSAP. See OSS note 19466.

SAPOSCOL may also terminate due to a small amount of internal memory allocation. When this memory gradually fills up during SAPOSCOL runtime, the system writes data out of the buffer. As a result, the next buffer is cleared and SAPOSCOL ends with a dump. Apply the following patches with at least the patch levels specified below:

SAP Release 640: SAPOSCOL patch level 100 and DW patch level 293

SAP Release 700: SAPOSCOL patch level 75 and DW patch level 151

SAP Release 701: SAPOSCOL Patch Level 18 and ILE Patch Level 53

SAP Release 710: SAPOSCOL patch level 36 and ILE patch level 161

SAP Release 711: SAPOSCOL patch level 12 and ILE patch level 48

Therefore, it is obvious that if we use different SAP systems on a server with incompatible combination of Kernel versions, SAPOSCOL will face a crisis and will not provide data for all systems, although SAP system functions will run smoothly. This is happening because we are using the new IBM technology with EXT Kernels, so it will not allow SAPOSCOL to reside in a Single Tier Store (SLS), instead placing it in Teraspace. In this situation, it is obvious that if you run an EXT system with other non-EXT systems, saposcol will run on only one system. To overcome this issue, you must upgrade to EXT Kernel for all SAP systems with the latest patches. Then set the proper authorization for the SAPOSCOL file and directory as indicated, which will resolve any issues related to SAP OS Collector.