The SAP System OS Collector – SAPOSCOL in a Nutshell

The SAP System OS collector (SAPOSCOL) is a platform independent stand-alone program that runs in OS background and collects the system information using a segment of the shared memory for various applications and all SAP instances on a host. These information details can be viewed through transaction code ST06/OS06 in frontend SAPGUI. It is a very useful tool for NetWeaver/Basis Administrators & consultants to monitor server performance. SAPOSCOL extracts real-time data from system, although it does not refreshes automatically, you need to click the ‘Refresh’ button to get the updated data. SAPOSCOL collects system data every 10 seconds and records it, and also records the hourly averages for the last 24 hours. It runs autonomously from SAP instances exactly one process per host and collects data from various operating system resources. User can monitor all the servers under SAP landscape with this tool. But for remote server (livecache server) the transaction code is OS07. You can check CPU utilization, Physical & 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 the OS Collector (SAPOSCOL) is not running (error code: Shared memory not available). In this situation your main task is to fix the saposcol to run properly. This usually happens after a new SAP installation or Kernel upgrades. If you are new with the SAP Systems the following guideline will be helpful to overcome the saposcol issue.

Unix/Linux/AIX/Sun/Solaris System:

First, Check the permission of saposcol.exe file, it should be 777 (owner is root in group sapsys) and 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, group sapsys, mode 4750, log in as root to your unix system and execute the commands as below,

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

chown root saposcol

chgrp sapsys saposcol

chmod 4750 saposcol

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

To stop the OS collector use saposcol -k. If this command failed to kill the process, you can execute “cleanipc 99 remove” (Check SAP Note 548699). If this attempt also fails, then you need to remove the shared memory key of saposcol. Execute command “ipcs -ma” and note down Shared Memory ID in the line that contains saposcol key. Then execute the command “ipcrm -m ID”. Shared memory key will be created again next time when you run saposcol.

Sometimes using “saposcol -l” gives a message that it’s already running, but when you grep the process using “ps -ef|grep -i saposcol” it may not show the process. In this situation, you can use a undocumented parameter “saposcol -f”, where “f” stands for starting the process forcefully. When it starts, then stop the process in regulation methon using “saposcol -k” and then start it normally using “saposcol -l”.

If saposcol still doesn’t run, then you need to start it in dialog mode. Login with use adm and follow the steps below,

saposcol -d

Collector > clean

Collector > quit

saposcol -k to stop the collector.

Before restarting

saposcol -d

Collector > leave (You should get a message- Shared memory deleted)

Collector > quit

cd /usr/sap/tmp

mv coll.put coll.put.sav

cd

saposcol

“coll.put”,if this file contains the old shared memory and should be deleted in order to get a clean start (Check SAP Note 548699, point 7). If you are unsuccessful in clearing shared memory, please try the following commands to clear the shared memory:

$ saposcol -kc

$ saposcol -f

If this also fails, then you need to restart the system from OS level and seems like also need a new version of saposcol (Check SAP Note 19227).

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

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

CALL PGM(SAPOSCOL) PARM(-l)

It submits the job in job queue QBATCH in library QGPL.

– In iSeries, you might experience strange data when analyzing CPU utilization using tcode ST06/OS06. Even you are using multiple CPU’s, SAPOSCOL might only report CPU usage for the first CPU. Also sometimes you will find CPU utilizations reported above 100% in some intervals, if you are running SAP instance in an uncapped partition where multiple logical partitions are using a shared processor pool. In this situation, be sure that CPU usage reported for CPU number 0 is the average usage for all CPU’s being used in the system. If you want to view shared CPU partition information, apply support packages as per SAP Note 994025 including following patch levels

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

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

By applying these patches and support packages into the system, new transactions, OS06N, ST06N, and OS07N are available to view additional information in two sections titled “Host system” and “Virtual system”. These include information about the partition type and the available and consumed CPU in the current partition as well as in the shared processor pool. So, if you are a iSeries user and your SAPOSCOL is not running, highest probability is that you need to put the latest kernel & saposcol patch. (SAP Note 708136 & 753917)

– Another scenario in iSeries, when your saposcol is not running, and you cannot start it from ST06/OS06. Problem might be with the authorization list R3ADMAUTL was not accurate. You can solve it by this way,

1) Remove QSECOFR *ALL X

2) Change *PUBLIC from *– USE to *EXCLUDE

3) Add R3OWNER *ALL X

Now you can start saposcol using the tcode ST06/OS06. And also you can start the process from 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 for user R3OWNER (SAP Note: 175852). If not then you have 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)

Then you should verify if the user R3OWNER is part of authority list R3ADMAUTL (SAP Note: 637174). After this if you receive the error “SAPOSCOL not running? (Shared memory not available), then follow the steps below,

1) Remove the shared memory (coll.put) as per SAP Note: 189072. ‘coll.put’ location is: ‘/usr/sap/tmp’.

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

3) Delete the temporary user space, 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 collection services is started there should be a new *DTAQ.

11) Start 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 collection services from Operations Navigator.

12) STRTCPSVR *MGTC

13) End and restart Operations Navigator if 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 in command line where you will find saposcol.exe. Set full owner permission

for the file & 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, then make sure you have the correct version of SAPOSCOL. Get latest SAPOSCOL from SAP Service Marketplace for your OS. Download the SAPOSCOL.SAR file for your Kernel and save in a directory. Then STOP SAP & SAPOSCOL. Check for any Kernel library locks and don’t forget to take library backup. Then run APYR3FIX and then APYSAP. Check OSS Note 19466.

SAPOSCOL also can be terminated due to small amount of internal memory allocation. When this memory filled gradually during the runtime of SAPOSCOL, system writes data outside the buffer. As a result the following buffer is cleared and SAPOSCOL terminates 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

So, it’s obvious that if we use different SAP Systems in one server with incompatible mixture of Kernel versions, SAPOSCOL will face crisis and will not provide data for all systems, though SAP system functions will run without any trouble. This happens because we are using new IBM technology with EXT Kernels, so it will not allow SAPOSCOL to reside in single level store (SLS), rather than put it to Teraspace. In this situation it’s obvious that if you run an EXT system with some other non-EXT systems, saposcol will run only in one system. To overcome this issue you need to upgrade to EXT Kernel for all SAP systems with latest patches. Then set proper authorization for SAPOSCOL file & directory as guided which will solve any problem related to SAP OS Collector.