User Profiles Creation during Operating System installation

When the operating system is installed from IBM-supplied media OR SAVSYS, the user profiles that are created in stage 1 of the operating system installation are determined by a security program that runs and checks for the existence of a specific list of profiles. If the profile does not exist in this list, it is not created. It does not matter which profiles were saved with the SAVSYS. Therefore, a scratch install is performed (for example, a disaster recovery or a migration to a different system) and there are objects in QSYS that are owned by a profile other than the specific set of profiles listed in the security program, they will end up being owned by QDFTOWN.

The profiles that are currently created when the operating system is installed are listed, in order, below:

Obtaining a List of Public Authorities for All Objects in a Library

To obtain a list of *PUBLIC authorities for all objects in a specific library, do the following:

1) On the operating system command line type the following:
WRKOBJ OBJ(LIBXXX/*ALL) OBJTYPE(*ALL)
Press the Enter key. Select Option 5 for all of the objects, as shown below:
Opt Object        Type       Library     Attribute    Text
 5   DTAQ1      *DTAQ   LIBXXX
 5   BATCHRT *FILE      LIBXXX SAVF
 5   CRTMQM *FILE      LIBXXX SAVF
 5   IBM           *FILE      LIBXXX PF
 5   IBM1         *FILE      LIBXXX PF

2) At the command line, type the following:
OUTPUT(*OUTFILE) OUTFILE(XXX/ZZZZ) OUTMBR(*FIRST *ADD)
where XXX is the library where you want the file to reside and ZZZZ is the name of the file to be created.
Then press the Enter key. The system will automatically create the file specified in the OUTFILE if it does not already exist. A record will be added to the file for each object that had a 5 placed in front of it. After the file has been created, you can run a query on the file to create your report.

Delete an object in Integrated File System - Message identifier CPFA0B1

Message CPFA0B1 occurs when one creates a directory in the Integrated File System (CRTDIR) with parameter RSTDRNMUNL set to (*YES). This parameter specifies whether special restrictions apply for rename and unlink operations performed on objects within a directory. This can be set only for a directory in the NFS, QFileSvr.400, "root" (/), QOpenSys, or user-defined file systems. A user cannot unlink an object that has the "restricted rename and unlink" attribute set on unless one or more of the following is true:

o The user is the owner of the object.

o The user is the owner of the directory.

o The user has all object (*ALLOBJ) special authority.

To resolve the problem, do the following:

o Open iSeries Navigator.

o Go into Integrated File Systems.

o Right-click on Integrated File System objects.

o Select Properties.

o Select the Security tab.

o Uncheck Restrict rename and unlink.

Internal security object not available – Message Identifier Message CPF2247 RC6

When a message CPF2247 RC6 is posted, there is no explanation on what a RC6 means. Below is the text that will be seen:

Message ID . . . . . . . . . : CPF2247
Message file . . . . . . . . : QCPFMSG
Library . . . . . . . . . : QSYS
Message . . . . : Internal security object not available. Reason code &1.
Cause . . . . . : An internal security object is not available for one of the following reasons:

1-Object is locked by another process.
2-User profile does not have enough auxiliary storage.
3-Interactive profile is damaged.
4-Damaged object detected, it is not an interactive profile.
5-Unable to access temporary interactive profile.

A RC6 indicates that the Password for user &1 not available. This will occur as a result of system value QRETSVRSEC being set to 0 when the profile was created and the password has not been changed since the system value was changed to 1. The fix is to change the password for the profile on each of the nodes.

Security Information Changes When an Object is Restored

When an object is restored to the system, the system uses the authority information stored with the object. The following applies to security of the restored object:

Object Ownership

o If the profile that owns the object is on the system, ownership is restored to that profile.

o If the owner profile does not exist on the system, ownership of the object is given to the QDFTOWN (default owner) user profile.

o If the object exists on the system and the owner on the system is different than the owner on the save media, the object is not restored unless ALWOBJDIF(*ALL) is specified. In that case, the object is restored, and the owner on the system is used.

o See “Restoring Programs” on page 219 for additional considerations when restoring programs.

Primary Group

For an object that does not exist on the system:

o If the profile that is the primary group for the object is on the system, the primary group value and authority are restored for the object.

o If the profile that is the primary group does not exist on the system:

- The primary group for the object is set to none.

- The primary group authority is set to no authority.

When an existing object is restored, the primary group for the object is not changed by the restore operation.

Public Authority

o If the object being restored does not exist on the system, public authority is set to the public authority of the saved object.

o If the object being restored does exist and is being replaced, public authority is not changed. The public authority from the saved version of the object is not used.

o The CRTAUT for the library is not used when restoring objects to the library.

Authorization List

o If an object other than a document or folder already exists on the system and is linked to an authorization list, the ALWOBJDIF parameter determines the result:

- If ALWOBJDIF(*NONE) is specified, the existing object must have the same authorization list as the saved object. If not, the object is not restored.

- If ALWOBJDIF(*ALL) is specified, the object is restored. The object is linked to the authorization list associated with the existing object.

o If a document or folder that already exists on the system is restored, the authorization list associated with the object on the system is used. The authorization list from the saved document or folder is not used.

o If the authorization list does not exist on the system, the object is restored without being linked to an authorization list and the public authority is changed to *EXCLUDE.

o If the object is being restored on the same system from which it was saved, the object is linked to the authorization list again.

o If the object is being restored on a different system, the ALWOBJDIF parameter on the restore command is used to determine if the object is linked to the authorization list:

- If ALWOBJDIF(*ALL) is specified, the object is linked to the authorization list.

- If ALWOBJDIF(*NONE) is specified, the object is not linked to the authorization list and the public authority of the object is changed to *EXCLUDE.

Private Authorities

o Private authority is saved with user profiles rather than with objects.

o If user profiles have private authority to an object being restored, those private authorities are usually not affected. Restoring certain types of programs may result in private authorities being revoked.
o If an object is deleted from the system and then restored from a saved version, private authority for the object no longer exists on the system. When an object is deleted, all private authority to the object is removed from user profiles.

o If private authorities must be recovered, the Restore Authority (RSTAUT) command must be used. The normal sequence is:

a) Restore user profiles

b) Restore objects

c)  Restore authority

Securing a Library from Some Users but Allowing *PUBLIC Access

There are times when you want a person or group to have less access than *PUBLIC has. To be the most secure possible, you can even make the entire system excluded from the user except what you want that user to be able to see.

For the person or group, do the following:

1. To exclude a person from all libraries on the system and, therefore, all objects in libraries on the system, run the following command:
GRTOBJAUT OBJ(QSYS/*ALL) OBJTYPE(*LIB) USER(xxxx) AUT(*EXCLUDE)
2. Run the following command:
DSPSYSVAL QSYSLIBL
Document every library in the system library list.
3. For each library in the system library list, run the following command:
RVKOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(*ALL)
This allows the user to access the libraries in the system library list. Without this, the user cannot sign on.
4. Do the same thing for each library in the user library list (which is listed in their job description). Then, repeat Step 3 for each library added to the user's library list.
5. For each additional library you want the excluded user to be able to use objects in that library, do one of the following:
To give the user the same authority that public does, run the following command:
RVKOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(*ALL)
To give the user specific authority to the library, run the following command:
GRTOBJAUT OBJ(QSYS/library) OBJTYPE(*LIB) USER(xxxx) AUT(xxxx)
If a user is *EXCLUDE from a library, that user is excluded from all objects in the library. However, if the user can *USE the library, the user can do more than merely *USE the objects within. The authority goes down to the specific object authorities. Therefore, the user might be able to change or even delete objects within the library.
The user must always have access to the following:

o The libraries in their library list.
o Most objects available to *PUBLIC in QSYS.
o The device that they're signing in from, with at least *CHANGE authority.
o Their own user profile, with at least Operator and Management data authorities, and all data authorities.
  
Without these, the user is not able to sign on.

Checking System Authority

When a user attempts to perform an operation on an object, the system verifies that the user has authority for the operation. The system first checks authority to the object library. If the authority to the library is adequate, the system checks authority to the object itself. In the case of database files, authority checking is done at the time the file is opened, not when each individual operation to the file is performed.

During the authority-checking process, when any authority is found (even if it is not adequate for the requested operation) authority checking stops and access is granted or denied. Adopted authority function is the exception to this rule. Adopted authority can override any specific (and inadequate) authority found. See the topic Objects That Adopt the Owner's Authority in the Security Reference manual for more information about adopted authority.

The system verifies a user's authority to an object in the following order:

1. User's *ALLOBJ special authority

2. User's specific authority to the object

3. User's authority on the authorization list securing the object

4. Group's *ALLOBJ special authority

5. Group's authority to the object -- see Note below.

6. Group's authority on the authorization list securing the object

7. Public authority specified for the object or for the authorization list securing the object

8. Program owner's authority, if adopted authority is used

Note: Authority from one or more of the user's groups may be accumulated to find sufficient authority for the object being accessed.

Determining What Objects Were Deleted with User Profile Deletion

If an administrator deletes a profile and also accidentally deletes the owned objects, it is possible to track what objects may have been deleted if security auditing is already being used at that time with QAUDLVL set with type *DELETE.

In the following example, user SMOHAMED deletes user profile COCO04 with the following command:

DLTUSRPRF USRPRF(COCO04) OWNOBJOPT(*DLT)

At the time it was deleted, the user profile owned a number of objects including job queues COCO401 through COCO405.

Using security auditing, it is possible to create an output file containing the deletes using the following commands:

Step 1: Create a file based on the correct field description file for DO journal entries:

CRTDUPOBJ OBJ(QASYDOJ4) FROMLIB(QSYS) OBJTYPE(*FILE) NEWOBJ(COCODELETE)

Step 2: Create an output file from the appropriate journal entries. In this example, I also narrowed down the search with specifics for date and time.

DSPJRN JRN(QAUDJRN) FROMTIME(083106 0730) ENTTYP(DO) OUTPUT(*OUTFILE) +

OUTFILFMT(*TYPE4) OUTFILE(COCODELETE)

Step 3: Look at the resulting file with the following command:

WRKF FILE(COCODELETE)

The following is shown:

 

 

 

 

 

 

 

 

 

Press F20 one time to get to the following screen.

 

 

 

 

 

 

 

 

As you can see, it does not reference the owner of the deleted objects (COCO04) in each entry. However, in the three tests I made, the owned objects were listed immediately above the deletion of the profile. Therefore, the entries are not a definitive answer but at least give a list of everything the administrator deleted immediately before the actual deletion of the profile. Unless the administrator deleted objects right before going on to delete the profile, the list should be fairly accurate.

PM Agent Jobs

A list of PM Agent jobs and their function follows:

Determining Who Started the Performance Collection Job

The performance collection (QYPSPFRCOL) job can be started using one of the following ways:

• Starting a Management Central Monitor
• iSeries Navigator - Under the Configuration and Service container, right-click on Collection Services, and then click on Start Performance Collection
• Performance Monitor (PM/400)
• GO PERFORM, Option 2 or STRPFRCOL command using a character-based interface
• Collection services (QYPSSTRC) API  

Depending on the method used to start the QYPSPFRCOL job, there will be different jobs specified in the CPI1125 message that is logged in the joblog for the job (as shown in example below). The message indicates that the QYPSPFRCOL job was started by PM/400.  

 

Message ID . . . . . . : CPI1125 Severity . . . . . . . : 00

Message type . . . . . : Information

Date sent . . . . . . : 01/04/07 Time sent . . . . . . : 09:38:08

Message . . . . : Job 373713/QSYS/QYPSPFRCOL submitted.

Cause . . . . . : Job 373713/QSYS/QYPSPFRCOL submitted to job queue QSYSNOMAX in QSYS from job 373682/QPM400/Q1PPMSUB.

 

Following is a table which shows the job that is specified in message CPI1125 message, indicating where the QYPSPFRCOL job was started from:

 

Note: To determine if the QZRCSRVS job was started as a result of a Management Central monitor versus iSeries Navigator, check the timestamp for message CPI1125 in the QYPSPFRCOL joblog. Then, check the Management Central server (QYPSJSVR) joblog for message CPIB901 indicating that a monitor was started. If the timestamps for both messages are the same, this means the QYPSPFRCOL job was started using a Management Central monitor.

Performance Tools - Manager and Agent

You can use the Manager and Agent features to efficiently divide required functions of Performance Tools over a distributed environment. Performance Tools are available with two separately installable features. This document explains the differences between the two features to help you decide which feature is more appropriate for your applications.

Manager Feature

The Performance Tools Manager feature is a full-function package that is intended to be used on the central site system in a distributed environment or on a single system. If you require analysis of trace data, viewing data graphically, viewing system activity in real time, or managing and tracking system growth, the Manager feature of the Performance Tools licensed program is more useful.

Agent Feature

The Performance Tools Agent feature, with a subset of the Manager function, is a lower-priced package with the more basic functions. In a distributed environment, the Agent feature works well for managed systems in the network because the data can be sent to the Manager if detailed analysis is required. It is also an effective tool for sites that need a reasonable level of self-sufficiency but have no expert skills available.

The Agent feature of Performance Tools provides functions to simplify the collection, management, online display, data reduction, and analysis of performance data. The Performance explorer reporting function and its associated commands are included in the base option in the IBM® Performance Tools for iSeries™ licensed program and, therefore, are available with either the Manager feature or the Agent feature. The major Performance Tools functions that are not contained in the Agent feature are performance and trace reports, performance utilities (job traces and the select file utilities), system activity monitoring, and performance graphics.

System Value QPFRADJ

During an IPL, CPF1805 messages are sent to the history log (QHST) by the IPL tuner; this indicates machine pool size changes. The IPL tuner runs only if QPFRADJ is set to 1 or 2. The dynamic tuning (automatic adjustment by the performance adjuster) does not log changes to pool sizes, so you will not see a message in QHST for the changes it makes to the machine pool size. Dynamic tuning runs after the IPL tuner when QPFRADJ is set to 2.

So, we are really talking about two separate tuning algorithms. When QPFRADJ is set to 2, the IPL tuner sets the machine pool size based on its own calculation of reserved size and the configuration of the system. It does not look at the minimum machine pool size on WRKSHRPOOL. Those values are only used by the dynamic tuning. The help text on QPFRADJ and WRKSHRPOOL might not be totally clear about these being two separate things; however, it does differentiate adjustment at IPL from automatic adjustment. The help text on WRKSHRPOOL only states that the size percent is used when QPFRADJ is set to 2 or 3. It does not explicitly say automatic adjustment only.

Even if you set the minimum % for the machine pool to a user-defined value, the IPL tuner will still set the machine pool first during the IPL if the QPFRADJ system value is set to 2. The dynamic tuning will recalculate the machine pool size based on the minimum %; however, it will always happen after the IPL tuning. The dynamic tuning runs immediately after the IPL tuning during IPL. However, the point I am trying to make is that there is a window between these two separate adjustments, even though you see only one of them logged in QHST. The IPL tuner does not know what the dynamic tuner minimum % is set to.

Advising that the minimum % be raised to a greater value is good. However, the QPFRADJ system value should also be changed from 2 to 3 to avoid the window where the IPL tuning is setting the machine pool to a low value prior to when the dynamic adjustment changes it to the minimum size set through WRKSHRPOOL.

If the QPFRADJ value is set to 3, the IPL tuner is not invoked; the machine pool is set to the value seen prior to the IPL. As a general recommendation, the QPFRADJ system value should be set to 3.

IBM PM iSeries Installation and Activation Instructions V5R1M0

These instructions provide the steps necessary to activate IBM Performance Management for eServer iSeries. To use this document, find the section pertaining to the operating system release currently in use on the system (for example, V5R3M0).

Operating System Release PM iSeries Availability Options 

• V5R1M0 => Included in operating system
• V5R2M0 => Included in operating system
• V5R3M0 => Included in operating system
• V5R4M0 => Included in operating system

Note: At V5R1M0 and later, PM iSeries is part of the base operating system. However, it must be configured to work properly

Disk Space Requirements

5MB of disk space is required for PM iSeries code at all releases.

Approximately 58MB is required for each day of raw performance data retained on the system. To alter the overall size of the raw performance data retained on the system, on the operating system command line, type the following:

GO PM400,  Press the Enter key. Select Option 3, and change the number of performance data purge days.V5R1M0: Performance Management/400 Activation

1. Sign on as a user with *SECOFR authority.

2. On the operating system command line, type the following:

    WRKSBS

   Press the Enter key.

3. Select Option 8 on the QSYSWRK subsystem, and press the Enter key. Select Option 4 on the QYPSPFRCOL job, and press F4 to prompt. For 'How to end', type *IMMED, and press the Enter key. Press F5 to refresh until the job is gone.

4. Select Option 4 on the Q1PSCH job, and press F4 to prompt. For 'How to end', type *IMMED and press the Enter key. Press F5 to refresh until the job is gone.

5. If upgrading PM iSeries from a prior release in which data was collected, the data in the collection library must be cleared or converted. On the operating system command line, type the following:

GO PM400

Press the Enter key, and select Option 3. Note the data collection library being used (usually QMPGDATA). Press F12 until you return to the main menu.

To clear the library, on the operating system command line, type the following:

CLRLIB xxxxx, where xxxxx is the data collection library. Press the Enter key.

To convert the data, on the operating system command line, type the following:

CVTPFRDTA, Press F4 to prompt. Use the operating system help instructions to complete this task. Consideration should be given to the size of the performance data library and if the system has sufficient space to accommodate another library of that size. For assistance, contact the IBM Support Center in your country.

6. On the operating system command line, type the following:

CFGPM400, Press the Enter key.

Send performance data to IBM? *YES

Receive performance data *NO

Performance data library QMPGDATA(Library from Step 5)

Press the Enter key.

7. A screen listing the PM iSeries communications objects is shown. Change the Do you want to set up PM/400 line control? parameter to *NO. Press F6 to re-create the communications objects regardless of their current status. For information on how to set up PM/400 line control, if necessary, refer to document 21253507 Setting up PMLINMON (V4R5M0 and Higher). To link to document 21253507 immediately, click here .

8. Fill in the customer contact information, paging down as necessary. When complete, press the Enter key.

9. On the operating system command line, type the following:

WRKSBS

Press the Enter key. Select Option 8 on the QSYSWRK subsystem. Verify that the CRTPFRDTA, QYPSPFRCOL, and Q1PSCH jobs are active. If not, contact the IBM Support Center in your country.

10. To configure PM iSeries data to be sent using a point-to-point connection over an internal or dual model modem. If you need assistance, contact the IBM Support Center in your country.

11. To configure PM iSeries data to be sent using a point-to-point connection over an internal or dual model modem. If you need assistance, contact the IBM Support Center in your country.

12. Check the the necessary PM iSeries PTFs by release:

13. GO PM400 option 2, ensure the Q1PCM1, Q1PCM2, Q1PTEST, and Q1PMONTH jobs are inactive. 

Identifying and Resolving Common Performance Problems

When performance problems occur on the IBM System i system, they often affect specific areas of the system first. Refer to the following table for some methods available for researching performance on these system areas. Many of these areas are available as system monitor metrics. However, there are several other ways to access information about them.

Tracking System Performance

Tracking system performance for the IBM® System i™ products server helps you to identify trends that can help you tune your system configuration and make the best choices about when and how to upgrade your system. Moreover, when problems occur it is essential to have performance data from before and after the incident to narrow down the cause of the performance problem and to find an appropriate resolution.

The System i server includes several applications for tracking performance trends and maintaining a historical record of performance data. Most of these applications use the data collected by Collection Services. You can use Collection Services to watch for trends in the following areas:

1. System resource utilization is used to plan and specifically tailor system configuration changes and upgrades.
2. Identify stress on physical components of the configuration.
3. Provide balance between the use of system resources by interactive jobs and batch jobs during peak and normal usage.
4. Collection Services data can be used to accurately predict the effect of configuration changes (for example, adding user groups, increasing interactive jobs) and other changes.
5. Identify jobs that might be causing problems with other activity on the system.
6. Determine utilization level and trends for available communication lines.

 The following tools will help you monitor your system performance over time:

Collection Services

Collection services gathers performance data at user-defined time intervals and then stores this information in collection objects on your system. Many of the other tools (including monitors, Graph history, IBM® PM iSeries™, and many functions in the Performance Tools licensed program) rely on these collection objects for their data.

 

Graph history

Graph history displays performance data that was collected with Collection Services over a specified period of time through a graphical user interface (GUI). The length of time available for display depends on how long you are retaining the collection objects and whether you are using PM iSeries.

 

PM iSeries

PM iSeries automates the collection, archiving, and analysis of system performance data and returns clear reports to help you manage system resources and capacity.