prmconf(4) manpage and PRM User’s Guide, section on memory record syntax

The descriptions for the IMPORT and EXPORT fields in memory records are incorrect. There should be one description for both fields, and that description should read as follows:

IMPORT, EXPORT
Allow a PRM group to borrow or lend memory resources.
Leave both fields blank to allow unrestricted borrowing
and lending. Assign both fields a value of 0 to isolate
a memory-critical group to ensure it gets exactly the
memory you give it.

PRM User's Guide, chapter 2, section "How PRM manages shared memory"

The second paragraph in the section incorrectly describes how prm2d handles shared memory. The incorrect text reads as follows:

With the prm2d memory manager, if a group is exceeding its memory shares as system memory utilization approaches 100%, prm2d determines which groups are importing the most memory above their entitlement, as compared with the average overachievement of all groups. If a PRM group is overachieving compared to the average, then the import shares for that group are lowered. This allows other groups to start importing the newly available memory.

The paragraph should read:

With the prm2d memory manager, all shared memory is allocated in the PRM_SYS group.

prmconf(4) manpage and PRM User’s Guide, section on memory record syntax

The descriptions for the IMPORT and EXPORT fields in memory records are incorrect. There should be one description for both fields, and that description should read as follows:

IMPORT, EXPORT
Allow a PRM group to borrow or lend memory resources.
Leave both fields blank to allow unrestricted borrowing
and lending. Assign both fields a value of 0 to isolate
a memory-critical group to ensure it gets exactly the
memory you give it.

PRM User's Guide, chapter 2, section "How PRM manages shared memory"

The second paragraph in the section incorrectly describes how prm2d handles shared memory. The incorrect text reads as follows:

With the prm2d memory manager, if a group is exceeding its memory shares as system memory utilization approaches 100%, prm2d determines which groups are importing the most memory above their entitlement, as compared with the average overachievement of all groups. If a PRM group is overachieving compared to the average, then the import shares for that group are lowered. This allows other groups to start importing the newly available memory.

The paragraph should read:

With the prm2d memory manager, all shared memory is allocated in the PRM_SYS group.

PRM User's Guide, chapter 2, section "Pattern matching for filenames"

Near the end of the section, the following paragraph appears:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application is matched by several records that use pattern matching, the application is assigned to the PRM group specified in the "first" matching record. The "first" matching record is determined by sorting-in ASCII dictionary order- the matching patterns.

The text should read as follows:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application without an explicit record is matched by several records that use pattern matching, the record closest to the beginning of the configuration file is used.

PRM User's Guide, chapter 2, section "How the application manager affects PRM group assignments"

Near the end of the section, the following text appears:

Starting one more program:

% call_home 

The call_home command is matched by the first, second, and fourth records. Because the first record is an exact match, it takes precedence over the other two records, and the call_home process is placed in GroupA.
Lastly, a user starts the following program:

% calendar 

The second and fourth records match the calendar command. Because both these records use wildcards, they are processed in ASCII dictionary order. Consequently, the fourth record is the first to match calendar, which is placed in GroupD.
The text should read as follows:

Starting one more program:

% call_home 

The call_home command is matched by the first and eighth records. (The second and fourth records do not match because PRM expands the regular expressions when the configuration is loaded and finds call_home already has a record.) The eighth record takes precedence because it has an alternate name, and the call_home process is placed in GroupZ. Be careful when constructing regular expressions: As shown with the eighth record above, an expression that is not specific enough can override explicit application records. Lastly, a user starts the following program:

% calendar 

The second and fourth records both seem to match the calendar command. The expressions are expanded in the order they appear in the configuration file. So, the second record is expanded first and is used for the calendar process, placing it in GroupB.

prmconf(4) manpage and PRM User’s Guide, section on memory record syntax

The descriptions for the IMPORT and EXPORT fields in memory records are incorrect. There should be one description for both fields, and that description should read as follows:

IMPORT, EXPORT
Allow a PRM group to borrow or lend memory resources.
Leave both fields blank to allow unrestricted borrowing
and lending. Assign both fields a value of 0 to isolate
a memory-critical group to ensure it gets exactly the
memory you give it.

PRM User's Guide, chapter 2, section "How PRM manages shared memory"

The second paragraph in the section incorrectly describes how prm2d handles shared memory. The incorrect text reads as follows:

With the prm2d memory manager, if a group is exceeding its memory shares as system memory utilization approaches 100%, prm2d determines which groups are importing the most memory above their entitlement, as compared with the average overachievement of all groups. If a PRM group is overachieving compared to the average, then the import shares for that group are lowered. This allows other groups to start importing the newly available memory.

The paragraph should read:

With the prm2d memory manager, all shared memory is allocated in the PRM_SYS group.

PRM User's Guide, chapter 2, section "Pattern matching for filenames"

Near the end of the section, the following paragraph appears:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application is matched by several records that use pattern matching, the application is assigned to the PRM group specified in the "first" matching record. The "first" matching record is determined by sorting-in ASCII dictionary order- the matching patterns.

The text should read as follows:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application without an explicit record is matched by several records that use pattern matching, the record closest to the beginning of the configuration file is used.

PRM User's Guide, chapter 2, section "How the application manager affects PRM group assignments"

Near the end of the section, the following text appears:

Starting one more program:

% call_home 

The call_home command is matched by the first, second, and fourth records. Because the first record is an exact match, it takes precedence over the other two records, and the call_home process is placed in GroupA.
Lastly, a user starts the following program:

% calendar 

The second and fourth records match the calendar command. Because both these records use wildcards, they are processed in ASCII dictionary order. Consequently, the fourth record is the first to match calendar, which is placed in GroupD.

The text should read as follows:

Starting one more program:

% call_home 

The call_home command is matched by the first and eighth records. (The second and fourth records do not match because PRM expands the regular expressions when the configuration is loaded and finds call_home already has a record.) The eighth record takes precedence because it has an alternate name, and the call_home process is placed in GroupZ.

Be careful when constructing regular expressions: As shown with the eighth record above, an expression that is not specific enough can override explicit application records.

Lastly, a user starts the following program:

% calendar 

The second and fourth records both seem to match the calendar command. The expressions are expanded in the order they appear in the configuration file. So, the second record is expanded first and is used for the calendar process, placing it in GroupB.

PRM User's Guide, chapter 5, section "Launching a shell script in a PRM group"

The description of how to launch a shell script in a PRM group is incorrect. It says to use the full pathname of the shell script as an alternate name in the application record.

In fact, you should use just the base name of the script. For example, with a ksh script named foo, the application record should be:

/bin/ksh::::GroupA,foo 

to run the script in the group GroupA. You must also ensure that the full path for the shell or interpreter for your script is listed in the file /etc/shells. NOTE: Because the full pathname is not required for the script, a rogue user can get access to PRM groups he may not otherwise have access to by using the name of the script for his own scripts or wrappers.

prmconf(4) manpage and PRM User’s Guide, section on memory record syntax

The descriptions for the IMPORT and EXPORT fields in memory records are incorrect. There should be one description for both fields, and that description should read as follows:

IMPORT, EXPORT
Allow a PRM group to borrow or lend memory resources.
Leave both fields blank to allow unrestricted borrowing
and lending. Assign both fields a value of 0 to isolate
a memory-critical group to ensure it gets exactly the
memory you give it.

PRM User's Guide, chapter 2, section "How PRM manages shared memory"

The second paragraph in the section incorrectly describes how prm2d handles shared memory. The incorrect text reads as follows:

With the prm2d memory manager, if a group is exceeding its memory shares as system memory utilization approaches 100%, prm2d determines which groups are importing the most memory above their entitlement, as compared with the average overachievement of all groups. If a PRM group is overachieving compared to the average, then the import shares for that group are lowered. This allows other groups to start importing the newly available memory.

The paragraph should read:

With the prm2d memory manager, all shared memory is allocated in the PRM_SYS group.

PRM User's Guide, chapter 2, section "Pattern matching for filenames"

Near the end of the section, the following paragraph appears:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application is matched by several records that use pattern matching, the application is assigned to the PRM group specified in the "first" matching record. The "first" matching record is determined by sorting-in ASCII dictionary order- the matching patterns.

The text should read as follows:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application without an explicit record is matched by several records that use pattern matching, the record closest to the beginning of the configuration file is used.

PRM User's Guide, chapter 2, section "How the application manager affects PRM group assignments"

Near the end of the section, the following text appears:

Starting one more program:

% call_home 

The call_home command is matched by the first, second, and fourth records. Because the first record is an exact match, it takes precedence over the other two records, and the call_home process is placed in GroupA.

astly, a user starts the following program:

% calendar 

The second and fourth records match the calendar command. Because both these records use wildcards, they are processed in ASCII dictionary order. Consequently, the fourth record is the first to match calendar, which is placed in GroupD.

The text should read as follows:

Starting one more program:

% call_home 

The call_home command is matched by the first and eighth records. (The second and fourth records do not match because PRM expands the regular expressions when the configuration is loaded and finds call_home already has a record.) The eighth record takes precedence because it has an alternate name, and the call_home process is placed in GroupZ. Be careful when constructing regular expressions: As shown with the eighth record above, an expression that is not specific enough can override explicit application records.

Lastly, a user starts the following program:

% calendar 

The second and fourth records both seem to match the calendar command. The expressions are expanded in the order they appear in the configuration file. So, the second record is expanded first and is used for the calendar process, placing it in GroupB.

PRM User's Guide, chapter 5, section "Launching a shell script in a PRM group"

The description of how to launch a shell script in a PRM group is incorrect. It says to use the full pathname of the shell script as an alternate name in the application record.

In fact, you should use just the base name of the script. For example, with a ksh script named foo, the application record should be:

/bin/ksh::::GroupA,foo 

to run the script in the group GroupA.

You must also ensure that the full path for the shell or interpreter for your script is listed in the file /etc/shells.

NOTE: Because the full pathname is not required for the script, a rogue user can get access to PRM groups he may not otherwise have access to by using the name of the script for his own scripts or wrappers.

prmconf(4) manpage and PRM User’s Guide, section on memory record syntax

The descriptions for the IMPORT and EXPORT fields in memory records are incorrect. There should be one description for both fields, and that description should read as follows:

IMPORT, EXPORT
Allow a PRM group to borrow or lend memory resources.
Leave both fields blank to allow unrestricted borrowing
and lending. Assign both fields a value of 0 to isolate
a memory-critical group to ensure it gets exactly the
memory you give it.

PRM User's Guide, chapter 2, section "How PRM manages shared memory"

The second paragraph in the section incorrectly describes how prm2d handles shared memory. The incorrect text reads as follows:

With the prm2d memory manager, if a group is exceeding its memory shares as system memory utilization approaches 100%, prm2d determines which groups are importing the most memory above their entitlement, as compared with the average overachievement of all groups. If a PRM group is overachieving compared to the average, then the import shares for that group are lowered. This allows other groups to start importing the newly available memory.

The paragraph should read:

With the prm2d memory manager, all shared memory is allocated in the PRM_SYS group.

PRM User's Guide, chapter 2, section "Pattern matching for filenames"

Near the end of the section, the following paragraph appears:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application is matched by several records that use pattern matching, the application is assigned to the PRM group specified in the "first" matching record. The "first" matching record is determined by sorting-in ASCII dictionary order- the matching patterns.

The text should read as follows:

Filenames are expanded to their complete names when a PRM configuration is loaded. Explicit application records take precedence over application records that use wildcards. If an application without an explicit record is matched by several records that use pattern matching, the record closest to the beginning of the configuration file is used.

PRM User's Guide, chapter 2, section "How the application manager affects PRM group assignments"

Near the end of the section, the following text appears:

Starting one more program:

% call_home 

The call_home command is matched by the first, second, and fourth records. Because the first record is an exact match, it takes precedence over the other two records, and the call_home process is placed in GroupA.

Lastly, a user starts the following program:

% calendar 

The second and fourth records match the calendar command. Because both these records use wildcards, they are processed in ASCII dictionary order. Consequently, the fourth record is the first to match calendar, which is placed in GroupD.

The text should read as follows:

Starting one more program:

% call_home 

The call_home command is matched by the first and eighth records. (The second and fourth records do not match because PRM expands the regular expressions when the configuration is loaded and finds call_home already has a record.) The eighth record takes precedence because it has an alternate name, and the call_home process is placed in GroupZ.

Be careful when constructing regular expressions: As shown with the eighth record above, an expression that is not specific enough can override explicit application records.

Lastly, a user starts the following program:

% calendar 

The second and fourth records both seem to match the calendar command. The expressions are expanded in the order they appear in the configuration file. So, the second record is expanded first and is used for the calendar process, placing it in GroupB.

PRM User's Guide, chapter 5, section "Launching a shell script in a PRM group"

The description of how to launch a shell script in a PRM group is incorrect. It says to use the full pathname of the shell script as an alternate name in the application record.

In fact, you should use just the base name of the script. For example, with a ksh script named foo, the application record should be:

/bin/ksh::::GroupA,foo 

to run the script in the group GroupA.

You must also ensure that the full path for the shell or interpreter for your script is listed in the file /etc/shells.

NOTE: Because the full pathname is not required for the script, a rogue user can get access to PRM groups he may not otherwise have access to by using the name of the script for his own scripts or wrappers.