BMC Patrol

Puppet Seeks Wider IT Automation Market - Network Computing

2013-03-26T13:09:00.000-07:00

Puppet Seeks Wider IT Automation Market - Network Computing

The update to Puppet Labs' IT automation software, Puppet Enterprise 2.0, includes cloud provisioning and change monitoring and management orchestration, and is intended to attract a wider audience, says CEO Luke Kanies. He believes the addition of a graphical user interface to replace the more tech-friendly command-line interface should make the software more accessible and attractive to organizations looking to provision new applications and respond to infrastructure changes faster.
Founded in 2005, the company shipped its first open source Puppet Project the same year, and the agent-based client-server solution now manages millions of nodes across thousands of organizations. Customers include Google, Apple, Twitter, Citrix and Oracle/Sun.

BPPM Search

2013-03-26T12:16:00.002-07:00

BPMCLI

2011-10-03T03:51:00.000-07:00

export all of the Portal element names into an HTML or csv file

bpmcli -c getElements -portal portal_web_server -login user_id -lass password

find the number of CPUs on a server using PSL?

/executable|wc -l

Below for solaris

cpucount = "psrinfo|wc -l"
execute("OS",cpucount);

Query the patrol console

collect data from the agent using dump_hist command:

an example:

dump_hist -format %H,%A,%I,%P,%y,%m,%d,%h:%m:%s,%v

This will dump the following columns in csv format, see the Patrol Agent reference manual for more details.

HostName,ApplicationName,InstanceName,ParameterName,year,month,dayOfMonth,hour:minute:second,value

a selection of the output:

PLUM1,AS_AVAILABILITY,PLUM1_3181,HostPingFailures,2010,11,08,09:11:42,0
PLUM1,AS_AVAILABILITY,PLUM1_3181,HostPingFailures,2010,11,08,09:11:13,0
PLUM1,AS_AVAILABILITY,PLUM1_3181,HostPingFailures,2010,11,08,09:11:45,0
PLUM1,AS_AVAILABILITY,PLUM1_3181,HostPingFailures,2010,11,08,09:11:17,0
PLUM1,AS_AVAILABILITY,PLUM1_3181,HostPingFailures,2010,11,08,09:11:49

10 Network Admin Apps for iOS

2011-10-02T06:45:00.000-07:00

10 Network Admin Apps for iOS

This is a client for the Rove Mobile Admin IT management solution and is designed for both the iPhone/iPod Touch and iPad. It helps you manage and track your IT issues, your network and computers, and integrates with a variety of third party systems and services. Though the app is free, you must have separately purchased and installed the Rove Mobile Admin server on your network, for which they offer a 14-day free trial for.

You get real-time alerts from the Rove Monitoring System, Microsoft System Center Operations Manager, BMC Performance Manager Portal, Nagios Monitoring, BMC Remedy Service Desk, CA Service Desk, and Symantec Backup Exec. You get also monitoring capabilities for Microsoft System Center Operations Manager, BMC Performance Manager Portal, and Nagios Monitoring. Additionally, virtualization control supported for VMware Infrastructure and Microsoft Hyper-V.

It offers incident report editing and searching for BMC Remedy Service Desk and CA Service Desk and Change Orders. It features mail system administration support for Microsoft Exchange and Domino. It provides numerous Windows management capabilities, including Command Prompt, Event Viewer, Local Users and Groups, File Explorer, Printers, Restart, Scheduled Tasks, Shared Folders, Services, System Information, Task Manager, Terminal Services, PowerShell, and Dial-up Connections

It supports the Active Directory and Novell Console directories. Database support includes Microsoft SQL Server and Oracle. Also supported is backup system administration of Symantec BackupExec and Symantec NetBackup. Additionally, it features management of the Microsoft IIS web server.

what is a monitoring tool ?

Monitoring tool is a tool which helps enterprise or organization to identify the fault immediately. Thus Mean Time To Repair (MTTR) is reduces. Monitoring tool is a complete automation of and real time status of configured items (any electronic product) which runs business. These electronic devices mapped to the monitoring tool which then monitors the status of devices and alarms when there is a failure or fault.

Monitoring tool can be 3 types

Network monitoring

Server Monitoring

Application Monitoring

Depends on functionality various monitoring tools are available in the market. Those monitor tools are

server monitor

BMC Patrol alias BMC performance Manager

BMC Proactive monitor

HP OpenView Operations Manager

Network Monitor

HP OpenView Network node Manager

Application Monitor

Business Availability Center

If the organization is aligned with ITIL strategy, It might uses Ticketing tool to accomplish this.

It could be of following Tools

BMC Remedy

BMC Remedy portal

HP Service Manager

HP Service Desk

All these applications can be integrated with this monitoring tools. So that an enterprise is accomplished with complete automation. When ever faults occurs in monitoring tools. The Event Management System will open a trouble ticket in this ticketing tool automatically.

BMC patrol also comes in software cloud computing

what is bmc patrol ?

BMC patrol does supports agent based and agent less monitoring of Infrastructure servers in an organization.

BMC patrol have the capability to support windows server. Thus it is a windows monitor tool.
It also support Unix servers. We can use it for all type of unix servers.

AIX
HP-UNIX
REDHAT LINUX
SOLARIS
VMS
Microsoft Windows

Configuring PATROL for Oracle

2010-05-29T12:51:00.000-07:00

1. Load PATROL for Oracle

2. Check instance list after loading PATROL for Oracle : Select Configuration => Advanced => Instance List from the Oracle menu

3. Add instances if instances are not listed

4. Configure instances for monitoring

5. Enable instance monitoring (if not done during configuration)

6. Enable category monitoring (if not done during configuration)

How to Load Knowledge Modules on the PATROL

2009-10-08T17:43:00.000-07:00

1.Just Right Click on the PATROL Main map
2.On the pop up menu press 'L' on key board or choose Load Knowledge Module
3.Now you will prompted to Load Knowledge Module Wizard
4.Now Choose Next to continue.
5.Now it shows list available servers to load
6.Select all the servers if needed then click Next to continue.
7.Now click Select All button to select all the KM's.
8.Use Filter box to filter or select specified KM's.
9.After Selecting all the Required KM's Click Next to continue.
10.Now the wizard successfully completed,Click Finish to close the Wizard.

you can use the same method to unload knowledge modules.

Role of the RTserver

2009-09-26T14:04:00.000-07:00

The Real Time server (RTserver) delivers application-related data between the following PATROL Components:
• PATROL Agent
• PATROL Central – Microsoft Windows Edition
• PATROL Central – Web Edition
• PATROL Console Server
You can install more than one RTserver to form an RTserver cloud.
RTserver clouds provide flexibility and load balancing. If an RTserver fails, another RTserver in the cloud picks up load and the PATROL components continue to communicate.
For additional load balancing, you can divide your PATROL components into groups and have each group talk to their own RTserver cloud.

Role of the PATROL Console Server

2009-09-26T13:57:00.000-07:00

PATROL Agent and PATROL Console communication is changed from two-tiered direct connections to three-tiered connections with an additional application server in the middle tier. In the case of PATROL consoles, this middle tier is PATROL Console Server. It creates a bridge between PATROL Agent’s distributed over the enterprise and
new PATROL 7.x Consoles. The PATROL 7.x consoles supported in this release are:

• PATROL Central Operator - Microsoft Windows Edition
• PATROL Central Operator - Web Edition

All the data related to a user session is collected and saved on the PATROL Console Server in one or more data files associated with a common name (the management profile). By storing management profiles on the PATROL Console Server, users can access their management profile from any 7.x console. The PATROL Console Server performs the following responsibilities:

• Stores frequently-accessed files in a centralized location.
• Caches console-specific agent information for use by the PATROL 7.x consoles.
• Sends requests for executing KM commands from consoles to agents.
• Creates a centralized log on location for all users to access agents.
• Allows centralization of privilege assignments and access control definitions (for both maintenance of tables and checking at runtime). BMC Software, Inc., Confidential and Proprietary Information Introduction 1-3
• Stores console credentials and impersonation data for console accounts in one central location. Centralization allows PATROL administrators to use authentication information through impersonation of user accounts for a given agent. This in turn allows users to authenticate to agents without requiring username and
password entry for each agent access or storage of passwords at every individual console system.
• Executes the same managed system queries across all agents.
• Executes the same event filters and queries across all agents.
• Executes state change actions as defined by users in their management profiles. These actions are executed as PSL or OS commands.
• Creates a persistent data cache for static agent attributes such as PATROL Agent versions, operating system names and versions, and preloaded KM lists, allowing you to access and query the information in the absence of agents.
• Stores privilege information defined through PATROL 7.x Administration Console Modules.
• Stores Access Control List (ACL) definitions as defined through PATROL 7.x Administration Console Modules.
• Stores management profiles for 7.x consoles so that the same information can be accessed from any 7.x console from any computer without any additional configuration that is local to the computer where the PATROL consoles are running. This enables location transparency for the users and allows roaming management profiles.
• Stores KM icons, online Help files, and lists of KM menu and InfoBox commands.
• Stores user preferences for charts, gauges, column order in list views, and view types such as icons, lists, and details. BMC Software, Inc., Confidential and Proprietary Information 1-4 PATROL Console Server and RTserver Getting Started
• Stores which PATROL Agents to connect and which KMs to load.
• Stores user-defined charts, custom views, folder hierarchies.
• Allows centralized access to predefined queries, event filters,
configuration options, and charts.

Patrol for Unix - segment 1 Application List

2009-09-09T01:24:00.000-07:00

PATROL for Unix

The KM for Unix is a set of files that contains knowledge in the form of
command descriptions, applications, parameters, and recovery actions
that analyze and manage PATROL events. The PATROL for Unix
parameters provide a detailed view of all system activity over time so
that you can detect problems, optimize systems, analyze trends, plan
capacity, and manage multiple hosts simultaneously.

PATROL uses the DCMColl Collector, where available, to gather data for
applications on the following platforms. For applications that DCMColl
does not gather data, PATROL uses PSL collection.
• AIX
• Compaq Tru 64 (Digital Unix, OSF/1)
• HP-UX
• Reliant Unix
• Solaris

PATROL uses the PSL collection to gather data for applications on the
following platforms:
• Red Hat Linux
• Sequent DYNIX/ptx
• Suse Linux
• Suse Linux on zSeries (S390), which is available only with the
PATROL for Linux Enterprise Server product

Agent host

Represents a computer instance that corresponds to the host computer that
You are monitoring Opening a computer instance icon displays the application classes that are
Active for that system.

COLLECTORS

Represents the COLLECTOR application, which maintains collector
Parameters for group B platforms. Instead of a prefix, the COLLECTOR
Parameters have the suffix Coll.

COMPOSITES _COLLECTOR

Represents the application that you can use to construct a new composite
Parameter that consists of one or more parameters in a logical relationship
That evaluates to true or false. You can use this application to set a warning
Or alarm condition based on the logical condition and not just on the
Parameter value.

COMPOSITES

Represents the application that displays instances of the composite
parameters that you construct with the COMPOSITES_COLLECTOR
application

CPU

Represents the CPU application, which monitors CPU usage. The prefix for
CPU parameters is CPU. This application also contains the SMP application
on machines with multiple processors.

DCM

Represents the DCM application, which controls data collection from PATROL
Perform collector to the Data Collection Manager and to associated PATROL
parameters for group A platforms.

DISK

Represents the DISK application, which monitors and provides information
About disks and disk usage. The prefix for DISK parameters is DSK.

FILESYSTEM

Represents the FILESYSTEM application, which monitors and provides
information about file system resources. The prefix for FILESYSTEM
parameters is FS.

HEALTH_AT_A GLANCE

Represents the HEALTH AT A GLANCE application, which monitors the
general health and well-being of the system by providing an overall view of
the system’s CPU, file system, and virtual memory usage.

KERNEL

Represents the KERNEL application, which monitors system kernel
processes and provides kernel resource usage information, including
i-nodes, the file table, and the process table. The prefix for KERNEL
parameters is KER.

LOG

Represents the LOG application, which you can use to monitor log files. This
application has only one parameter, which is used for internal purposes only.
This application contains instances of the LOGMON application class for
each monitored log file. Each LOGMON instance contains parameters and
possibly a LOGTEMP application instance, which specifies a template to use
when monitoring a log file.

Log name

Represents a LOGMON application instance, which you can use to monitor
the size and growth rate of log files that you specify by choosing Edit List of
Monitored Files from the LOG application icon menu. Instances of this
application appear in the LOG application container window. The prefix for
LOGMON parameters is LOG.

Template name

Represents the LOGTEMP application, which you can use to create search
string templates that you can apply to one or more log files. This feature
scans specified log files for specified text strings. LOGTEMP icon instances
appear under LOGMON log file instances to which they have been applied.

MEMORY

Represents the MEMORY application, which monitors memory activity,
including paging, I/O caching, and swapping. The prefix for MEMORY
parameters is MEM.

NETWORK

Represents the NETWORK application, which monitors network activity. The
prefix for NETWORK parameters is NET.

NFS

Represents the NFS application, which monitors RPC (Remote Procedure
Call) and NFS (Network File System) activities. The prefix for NFS
parameters is NFS.

PATROL

Represents the PATROL application, which shows the number of PATROL
Consoles currently running. Currently, the PATROL application has no
parameters.

PATROL AGENT

Represents the PATROLAGENT application, which monitors and manages the
agent. The prefix for PATROL Agent parameters is PA.

PRINTER

Represents the PRINTER application, which monitors the print queue and
printer activity and allows you to perform printer administration activities. The
prefix for PRINTER parameters is PRN.

PROCESS

Represents the PROCESS application, which displays statistics on active and
zombie processes. The prefix for PROCESS parameters is PROC.

PROCESS_PRESENCE

Represents the application that holds PROCCONT instances. You can use
this application to specify which processes you want to monitor.

Name

Represents the PROCPRES application, which monitors specified processes
running on your system. This application is a child application of the
PROCESS and PROCESS_PRESENCE (PROCCONT) applications and
resides in the PROCESS_PRESENCE application’s container window.

SECURITY

Represents the SECURITY application, which provides security-related menu
commands. Currently, the SECURITY application has no parameters.

SMP

Represents the SMP application. This application displays information for
each processor on multiprocessor machines. The prefix for SMP parameters
is SMP. SMP parameters appear under SMP instances in the CPU container
window for machines that have multiple processors.

SNMPHealth

Represents the SNMPHealth application. This application displays information
on the status of the PATROL SNMP subsystem. It also provides the ability to
test various aspects of the system.

SWAP

Represents the SWAP application, which monitors and provides information
about utilization of system swap files. The prefix for SWAP parameters is
SWP. SWAP parameters appear under SWAP instance icons. A Summary instance
appears for all platforms. The group A platforms have only a Summary
instance. The group B platforms have also SWAP instances for discovered
SWAP partitions.

UNIX_OS

Represents the UNIX_OS application class. This application is a container for
all other Unix operating system applications. It does not possess any
parameters. It does provide menu commands to set debugging for various
collectors and to exclude application instances from being monitored.

USERS

Represents the USERS application, which monitors and provides information
about user sessions and processes. The prefix for USERS parameters is
USR.

Parameter Histories

2009-09-03T17:51:00.000-07:00

A red dot in the top left corner of a parameter icon indicates that no history exists.
To view parameter history,
With the mouse over the parameter you want to view, click on the right mouse button to choose View History from the parameter menu. The Time Span dialog box is displayed.
Enter the history span you want to see displayed on the parameter graph using the slide bars, or choose Whole Range to see all the history data collected for that parameter.
The graph for that parameter, with the history span you specified, is displayed.
Alternatively, you can view the history for a parameter by doing the following:
Displaying the parameter graph by double-clicking on the left mouse button.
Choosing Options => View History from the parameter graph window menu bar.
The Time Span dialog box is displayed.
Entering the history span you want to see displayed on the parameter graph using the slide bars or choosing Whole Range to see all the history data collected for that parameter.
The graph for that parameter, with the history span you specified, is displayed.
Related topics

Collecting parameter histories

To collect history data for a parameter using the PATROL Console for UNIX, perform the following steps.
From the List of Parameters window, select the parameter you want to gather history on.
Choose Edit => Modify from the pull-down menu or double-click on the left mouse button. The definition window for that parameter opens.
Find History Level on the definition window.
Using the left mouse button, click on the Inherited button and select Local. The slide bar is activated.
Select the number of days you want to gather history for using the slide bar.
Select OK. That parameter is now gathering history data.

Clearing parameter histories

You can clear parameter history for an application instance, application class, computer instance, or computer class. Clearing the history at the class level does not affect the history status at the local (that is, instance) level.
Note: If a parameter value exceeds its retention period, it is deleted automatically. Refer to the PATROL Console Help or the PATROL User Guide for more information on defining a history retention period.
All Computer Classes
Display the Computer Classes List window and select ALL_COMPUTERS.
Choose Attributes => Parameters to display a list of parameters defined for all computer classes.
Select the parameters for which you want to clear the history.
Choose Options => Clear History.
An Application or Computer Class
Display the relevant Classes List window and select the class for which you want to clear the parameter history.
Choose Attributes => Parameters to display the List of Parameters window.
Select one or more parameters.
Choose Options => Clear History.
An Application or Computer Instance
Display the pop-up menu for the object.
Choose Customize => Parameters to display the List of Parameters defined for the object.
Select one or more parameters for which you want to clear the parameter history.
Choose Options => Clear History.

Loading the Knowledge Module for UNIX

2009-09-03T17:48:00.000-07:00

Perform the following steps to load the PATROL KM for UNIX:
Access the Knowledge Module dialog box as described in Loading a KM The dialog box displays a list of available Knowledge Modules installed at your site.
Select the UNIX3.km file or the application class KM file from the list by highlighting it.
Note: You can load BASE3.km instead of UNIX3.km, which contains only the PATROL and PATROL Agent applications As a database administrator, you may find the BASE#.km file useful if you do not want to monitor UNIX parameters
Click on OK.
When the KM has loaded, PATROL enters into a discovery phase
Note: If you want to monitor log files or AIX system micropartitions, you must load the LOG.kml or VIRTUALIZATION.km file respectively.
Application discovery rules

Application discovery rules are defined using either
simple discovery
PSL discovery
Simple discovery uses simple pattern matching to find instances of the application running on the monitored computer.
PSL discovery uses complex scripts written in PATROL Script Language to find the application instances.

Triggering application discovery

Depending on the value of the application check cycle for a computer, PATROL may take a few moments to discover all the applications on a given computer.
To force the agent to discover all the applications on a given computer,
Access the PATROL Agent application menu as described in Accessing the KM menu commands.
Choose Trigger Agent Activities => Perform Application Discovery from the PATROL Agent application menu. PATROL displays the discovered applications in the icon window.

Parameters

2009-09-03T17:46:00.000-07:00

Parameters
Parameters give PATROL the ability to probe, monitor, and respond to any application or computer variable value. Parameters can monitor the rate at which file systems are filling up or the number of processes started that are still executing. They can provide a detailed statement of all system activity through time so that you can clearly identify peaks, troughs, and trends in the performance of system resources.
A parameter contains commands that are stored and used to collect data from a system resource. The data is made available for
Creating graphic formulas
Providing detailed information about the current status of the application
Performing analysis to determine if automatic recovery actions should be started to avoid a possible problem
Parameters function the same way for computers as they do for applications.
Refer to your console documentation or console Online Help for more information about defining and customizing parameters.

recovery actions

Recovery actions are commands defined as part of the parameter and executed by the PATROL Agent when the parameter value falls within a defined alarm range. A parameter can store a list of recovery actions associated with different alarm ranges for the same problem. If a parameter detects an alarm state, the PATROL Agent tries to repair the problem by issuing the first recovery action defined for the parameter.
If the alarm level is still critical the next time the PATROL Agent runs the parameter, the next recovery action on the list is run and so on until no more recovery actions are left.
The PATROL Agent can send a message to the Console to activate a state change action such as a flashing icon, which lets you know that you need to investigate the problem. Refer to Initiating State Change Actions for more information on the types of alerts PATROL can initiate.
You can modify parameter recovery actions or define your own. Refer to the PATROL Console for UNIX User Guide, the PATROL for Microsoft Windows User Guide volumes 1 through 3, and the PATROL Console online help for more information.
Related topics

KM for Unix

2009-09-03T17:38:00.000-07:00

The Knowledge Module for UNIX (KM) contains the knowledge that PATROL uses during system monitoring, analysis, and management activities. This knowledge can include command descriptions, applications, parameters, recovery actions, and other information useful in administering UNIX systems.
The KM parameters allow you to perform system performance analysis quickly and easily because they can provide a detailed statement of all system activity through time. You can clearly identify peaks, troughs, and trends in the performance of system resources.
By enabling you to detect problems, optimize systems, analyze trends, plan for capacity, and manage simultaneous, multiple host, the KM helps you ensure that your UNIX systems run efficiently 24 hours a day.
The following topics provide an overview of the KM for UNIX.
Application hierarchy
The PATROL products are organized hierarchically. At the top level of the hierarchy is the computer instance. Beneath it is the UNIX operating system object. All the UNIX product application classes are subordinate to the UNIX object. Many of the application classes contain instances, but not all application classes have instances or parameters.
The following figure illustrates the basic hierarchy. It does not necessarily display all the application classes in the product.

Collection Methods
Two collection methods are available to the PATROL Knowledge Module for UNIX. The two methods use separate collector parameters.The collectors are
DCM Collector â€“ employs the Perform Collector and DCM binary to gather information for application classes and uses collector parameters with â€“Ctrl suffix to control the poll time and status; DCMColl monitors this collection process
PSL Collectors â€“ employs PSL collector parameters with the â€“Coll suffix, except for the DCMColl, to gather information for application classes
Unavailable Parameters by Collection Method
Neither collection method gathers data for every parameter available in the KM. For a list of parameters that are deactivated for a specific collection method, see
DCM Collection Exceptions
PSL Collection Exceptions

Applications

An application in PATROL is any resource utilized or running on a computer. The Knowledge Module for UNIX has a basic set of applications that monitor events such as CPU, file system, and memory usage. Each running copy of an application discovered by PATROL is called an instance of the particular application class. Each application instanceis represented by an icon in the COMPUTER window.
The following topics provide details about the KM applications.

Basic Application Concepts

About application discovery
About InfoBoxes
About application parameters
About application reports

Using Applications

The Knowledge Module for UNIX applications
Triggering application discovery

acos()

2009-09-03T17:32:00.000-07:00

acos()
Return the arccosine of the argument
Format
acos(cosine)
Parameter
Description
The acos() function returns the arccosine of cosine; that is, the length in
radians of the arc whose cosine is cosine.
The output range for the acos() function is 0 £ acos() £ p. The acos()
function return value is accurate to six decimal places.
Example: Testing for Roundoff Error
The following PSL statements test the roundoff error in the cosine and
arccosine functions by comparing argument with acos(cos(argument)) for 0 £
argument £ 3.1 (»p) radians in increments of 0.1 radian.
arg = 0.0;
printf ("radians\t\tcos()\t\tacos(cos())\troundoff error\n");
printf ("-------\t\t-----\t\t-----------\t--------------\n");
while (arg <= 3.1) {
cosine = cos(arg);
argument = acos(cosine);
error = argument - arg;
printf ("%+1.1f\t\t%+1.6f\t%+1.6f\t%+1.6f\n",arg,cosine,argument,error);
arg = arg + 0.1;
}

Parameter Definition
cosine Cosine argument.
Valid Range: –1 £ cosine £ 1

Common PSL Coding Errors

2009-09-03T17:26:00.000-07:00

Character Strings Interpreted as Numbers

Problem: Errors can occur when numeric operations are applied to character strings
whose first character is a digit or minus sign because PSL will evaluate
these character strings as numbers.
Reason: Before PSL performs an operation, it must determine whether the
operands are numeric or character. To make the determination, PSL
performs one of the following tests:
• For relational operators, PSL tests that both operands consist entirely
of digits, a period, and/or a minus sign. Otherwise, both operands are
character type.
• For arithmetic operators, PSL tests only that the first character of
each operand is a digit or minus sign. Otherwise, both operands are
character type that generates a run-time warning.
The run-time warnings perform the same check as the as arithmetic
operators.

These features remain for compatibility with previous releases of
PATROL.
Arithmetic operators identify the character string “10th May” as the
number 10 while relational operators correctly identify it as a character
string. Its use as an arithmetic operand will not generate a run-time
warning.
Solution: Be aware that character strings whose first character is a valid numeric
representation can cause unexpected results in numeric operations that
will not be detected by PSL diagnostics. Avoid the use of such strings.

Floating Point Numbers Interpreted as Character Strings

Problem: PSL interprets floating point numbers with a leading decimal point as
character strings.
Reason: Before performing a numeric operation, PSL evaluates both operands to
verify that they are numbers. PSL tests only that the first character of
each operand is a digit or minus sign. Upon detecting that the first
character is a decimal point, PSL identifies the operator as a character
string and returns a warning.
PSL identifies the operand 0.33 as a number and the operand .33 as a
character string.
Solution: Begin each floating point number with a digit or a minus sign.

Character Strings Interpreted as Variable Names

Problem: PSL interprets character strings that are not enclosed in double quotation
marks as variable names.
Reason: The PSL language requires that all character strings appearing in
statements and function calls be enclosed in double quotation marks to
identify them as character strings.
Improperly identified character strings will not generate compiler errors
but may generate warnings about uninitialized variables if the string is
not equivalent to a variable name initialized elsewhere in the program.
PSL interprets the statements get(Dev); and get(RDB/Dev); as requests
for the values of the user variables Dev and RDB/Dev. PSL interprets the
statements get("Dev") and get("RDB/Dev") as requests for the PSL
object variables Dev and RDB/Dev.
Solution: Enclose all strings in double quotation marks. Enable PslDebug flag 16
to catch variable names that were not explicitly initialized within the PSL
program.
Problem: PSL interprets character strings that are not enclosed in double quotation
marks as variable names.
Reason: The PSL language requires that all character strings appearing in
statements and function calls be enclosed in double quotation marks to
identify them as character strings.
Improperly identified character strings will not generate compiler errors
but may generate warnings about uninitialized variables if the string is
not equivalent to a variable name initialized elsewhere in the program.
PSL interprets the statements get(Dev); and get(RDB/Dev); as requests
for the values of the user variables Dev and RDB/Dev. PSL interprets the
statements get("Dev") and get("RDB/Dev") as requests for the PSL
object variables Dev and RDB/Dev.
Solution: Enclose all strings in double quotation marks. Enable PslDebug flag 16
to catch variable names that were not explicitly initialized within the PSL
program.

PSL Functions That Do Not Modify Their Arguments

Problem: Some PSL functions do not modify their arguments and their return
values are lost if not explicitly saved in the PSL program.
Reason: Some PSL functions return modified copies of their arguments as return
values, preserving the integrity of the original arguments.
For example, the PSL function call trim(text,"\t"); returns a copy of
the character string variable text with all tab characters removed. Without
an explicit destination and because the trim function cannot modify its
test argument, the return value is discarded before executing the next PSL
statement. Alternately, the PSL function call text=trim(text,”\t”);
returns the modified copy of string variable text and stores it back into
text.
PSL functions that do modify their arguments are those that perform
command execution and PSL object manipulation, including the
following:
• create()
• destroy()
• system()
• execute()
• set()
• log()
• close()
• print()
• popen()
• write()
The return values for these functions generally indicate the completion
status of the operation and may not need to be retained.
Solution: Become familiar with the descriptions of the PSL built-in functions.
Those that return more than a completion status value probably do not
modify their arguments and thus require that you explicitly save the
return value if it is to be available to other statements within the program.

Functions That Do Not Write to the System Console Window

Problem: PSL built-in functions such as grep(), cat(), or get_var() do not
display their return values in the system console window.
Reason: PSL built-in functions return their values to the PSL program. To display
those values outside the program, they must be printed.
For example, grep(), cat(), and get_var() produce no output to the
system console window but print(grep()), print(cat()), and
print(get_var()) will print the specified function return values.
Solution: To display function return values in the system console window, make
those functions arguments of the print() function.

exit_status — System Return Code Variable

2009-09-03T17:23:00.000-07:00

The PSL exit_status variable stores the exit status of a process
invoked from a system(), popen("OS",) or execute("OS",) function.
The user cannot write the exit_status variable.
Tip
The popen() function with an OS command type can set the
exit_status variable asynchronously whenever its operating system
child process dies. It is possible (although unlikely) that the popen()
function could set exit_status after a system() or execute()
function concludes but before exit_status is read for the system() or
execute() call.

Incompatibilities with the C Programming Language
There are features found in the C programming language that are not
supported by and not compatible with PSL. This section lists known
incompatibilities.
Operators && and
Difference: PSL does not perform short-circuit processing of the && and operators.
C Action: The && and functions short-circuit in standard C meaning that
evaluation stops with the first condition that establishes an outcome for
the statement. Some programmers use this feature to construct statements
that depend on the left-to-right sequential evaluation of the conditions.
PSL Action: PSL always evaluate all conditions in a statement using && and
operators. Evaluation of all conditions may cause unexpected results in
statements that depend on a left-to-right sequential evaluation and
short-circuit.
Prefix and Postfix Operators ++ and --
Difference: PSL does not distinguish between prefix and postfix operators.
C Action: Appending ++ or –– as a prefix instructs the program increment or
decrement the variable then test the condition, while appending ++ or ––
as a postfix instructs the program to test the condition before
incrementing or decrementing the variable.
PSL Action: PSL treats both prefix and postfix operators as prefix operators. Treating
postfix operators as if they were prefix operators may cause unexpected
results in statements that depend on postfix operators.
BMC Software, Inc., Confidential and Proprietary Information
Diagnosing PSL Program Errors 6-9
Break and Continue Statements
Difference: PSL supports the function but not the syntax of the break and
continue statements. PSL replaces the break statement with the last
statement, and the continue statement with the next statement.
PSL Action: PSL treats the C break and continue statements as statements that
evaluate the variable name break or continue and produce no output or
effect within the PSL program.

errno — Error Return Code Variable

2009-09-03T17:22:00.000-07:00

The PSL errno variable is set by various PSL built-in functions to
indicate the reason for a failure. All functions that can potentially set
errno are also required to reset the errno variable to zero and have it
remain zero if the function is successfull. Functions that don’t set the
errno variable do not reset it to zero either. This requirement validates
usage styles such as the following:
x = cat("file");
if (errno != 0)
{
# Error occurred in cat function
# examine errno value for specific error code
}
The user can also write values to the errno variable. However, there
should be little cause to set errno since it is reset by all function that set
it.
Tip
The errno variable is reset to zero by many built-in functions at the start
of their processing; and in some functions, clearing can occur before
arguments are processed, leading to errno being cleared before being
processed as an argument. Hence, when passing errno as an argument
to a built-in function, BMC Software recommends that you make a copy
in a temporary variable and pass the copy.

PslDebug — Run-Time Error Checking Variable

2009-09-03T17:17:00.000-07:00

The PslDebug built-in local variable provides a run-time error checking
and trace facility that detects a variety of common PSL coding errors.
You can enable or disable run-time checking and/or tracing by equating
PslDebug to a numeric value representing 1 or more of 16
error-checking flag bits.
The trace data produced by the PslDebug trace flags is useful in
debugging PSL programs during the initial stages of programming or as a
“pre-debug” before calling the more powerful (and hence more time
consuming) PSL debugger.
The general arrangement of the flags is as follows:
• error checking: 0-128
• tracing: 256-16384
The format of PslDebug within a PSL script is identical to that of any
other PSL variable:
PslDebug = n;
Value Definition
PslDebug Enable All Error Checking and Tracing:
–1 Enable all PSL run-time error checking and tracing functions. Setting
PslDebug = -1 is equivalent to setting all error checking and tracing flag
bits, or setting PslDebug = 257 (1 + 256 enables all error checking and all
tracing flag bits).
PslDebug Enable/Disable All Error Checking:
0 Disable all run-time error checking.
1 Enable all PSL run-time error checking. Setting PslDebug = 1 is equivalent
to setting all error checking flag bits.

Numeric Operation Warnings:
2 Enable warnings when arithmetic operations involve NULL string operands.
This check is a stylistic one used to verify that numeric variables are explicitly
initialized to zero rather than defaulting to NULL strings, which are treated as
zero in arithmetic operations.
Example: The expression x+10 will generate this warning when x is the NULL
string.
4 Enable warnings for arithmetic operations involving nonnumeric operands.
Example: The expression “mary” + “john” attempting to numerically add two
character strings will generate this warning.
8 Enable warnings for illegal or undefined arithmetic operations.
Example: Divide by zero.
Variable Initialization Warnings:
16 Enable warnings for variables that were not explicitly initialized.
This checks for variables that are used before being explicitly equated to a
value. Variables are initialized to the NULL string by default. BMC Software
recommends that you explicitly initialize all variables to a value (even the NULL
string) as a matter of good programming style.
Built-in Function Warnings:
32 Enable warnings for PSL Version 2.0 built-in functions.
This check allows you to suppress warning messages that were not
suppressible in PSL Version 2.0.
Example: A “file not found” for the cat() function will generate this warning.
PslDebug = 32 is the default if PslDebug is not specified to provide the
same default behavior as PSL Version 2.0.
64 Enable warnings for PSL Version 3.0 built-in functions.
This is a new error check of built-in functions that were not in PATROL®
Version 2.0. The errors detected include passing non-numeric arguments
when a numeric value is required, passing a bad argument, or passing the
wrong number of arguments to a printf() function.
128 (not used)
PslDebug Enable All Tracing:
256 Enable all PSL run-time tracing. Setting PslDebug = 256 is equivalent to
setting all tracing flag bits.

512 Enable function call tracing.
Function call tracing reports which functions are called but does not return
information about the arguments. Function call tracing traces both user-defined
and built-in functions.
1024 Enable function argument tracing.
Function argument tracing reports the arguments passed to all user-defined or
built-in functions. Function argument tracing requires that function call tracing
(PslDebug = 512) also be enabled; that is, PslDebug = 1536 for function
argument tracing.
2048 Enable function return value tracing.
Function return value tracing reports the value returned by calls to all
user-defined or built-in functions.
Variable Tracing:
4096 Enable variable assignment tracing.
Assignment tracing reports the variable name (if available) and the value
assigned to it.
8192 Enable errno tracing.
errno tracing reports any nonzero values stored in the PSL errno variable.
Lock Tracing:
16384 Enable PSL lock tracing
Lock tracing reports the interprocess actions that occur during lock() and
unlock() function processing, including the granting, denying, and releasing
of locks.
32768 (not used)
Table 6-1 PslDebug Error Checking Flag Bits (Part 3 of 3)

You set multiple flag bits by equating PslDebug to the sum of their
values. For example, PslDebug = 44 would enable the following flags:
• arithmetic operations involving nonnumeric operands (4)
• illegal or undefined arithmetic operations (8)
• PSL Version 2.0 built-in functions (32)
whose sum 4 + 8 + 32 is 44.

PSL External Commands

2009-08-30T06:43:00.000-07:00

%DUMP — List Specific Information

Return a list of specific information
Format
%DUMP option
Description
The %DUMP command returns a list of information that is specified
by the parameter option.
Field Definition
option One of the following:
• ALLReturn info about PATROL® Agent data structures
• APP_INSTSReturn info about each application
instance
• APPSReturn a list of applications
• CHANNELSReturn a list of open PSL global file and
process channels
• CONSOLESReturn a list of connected consoles
• ERRORSReturn a list of PSL errors that have
occurred
• GLOBALSReturn a list of global channels
• KM_LISTReturn a list of loaded KMs
• LIBRARIESReturn a list of loaded libraries
• PARAMSReturn a list of PATROL Agent parameters
• RTLISTReturn info about processes in the Agent
run-time queue
• RUNQReturn a list of items scheduled in the run
queue
• TASKSReturn a list of current tasks

%DUMP CHANNELS — List PSL Global Channels

List open PSL global process and file channels
Format
%DUMP CHANNELS
Description
The %DUMP CHANNELS command returns a list of global file and process
channels opened using either the fopen() or popen() functions. The
output from the %DUMP CHANNELS command contains the same
information as that provided by the get_chan_info() function within
a PSL program. The PSL interpreter returns the list of global channel
information to the console window from which the %DUMP CHANNELS
command was executed.
Note
The %DUMP CHANNELS command is one of a series of dump commands
available from the command line. Use the %DUMP command

%DUMP LIBRARIES — List Loaded PSL Libraries

Format
%DUMP LIBRARIES

Description
Each line of output from the %DUMP LIBRARIES command is a string
with the format:
- ,
Example
When typed into the computer window, the command
OS>%DUMP LIBRARIES outputs the following:
================ Currently Loaded Libraries =========================
response_def_lib.lib - unmodified, Wed Nov 6 15:34:42 1996
unix_misc_lib.lib - unmodified, Wed Dec 11 13:11:16 1996
set_share_lib.lib - unmodified, Tue Nov 26 16:56:38 1996
=====================================================================

%PSL — Execute a PSL Statement

Execute a one-line PSL statement
Format
%PSL statement
Parameter
Description
The %PSL command submits statement to the PSL interpreter for
immediate interpretation.

%PSLPS — List Current PSL Processes

List all scheduled or active PSL processes on the computer system
Format
%PSLPS
Description
The %PSLPS command returns a list of currently scheduled or active PSL
processes on the computer system to the console window. The
information displayed by the %PSLPS command includes the process
identifier (PID) and the name of the PSL process or command.

psl — PSL Compiler Command

Call the PSL interpreter and compiler for the specified PSL source file
Format
psl inputfile -o outfile -n -r -w -l -P -O -q -b -R -e functionname -s
librarynames -S

Parameters
Parameter Definition
inputfile Name of the PSL source file
-o outfile Write the compiled binary output as the file outfile. This
option implicitly includes the -n option; that is, the -o
option does not schedule outfile for execution after
compilation.
The PSL compiler may add a .lib or .bin extension
to outfile if you selected the -l or -b option
respectively.
-n Do not schedule outfile for execution after compilation.
-r Suppress runtime error messages. This option is
equivalent to including the statement PslDebug = 0;
in the PSL script.
-w Suppress compilation warning messages produced by
the PSL compiler.
-l Write the compiled output in library mode as the file
outfile.lib. This option implicitly includes the -n
option; that is, the -l option does not schedule
outfile.lib for execution after compilation.
-b Write the compiled output in binary mode as the file
outfile.bin.This option implicitly includes the -n option;
that is, the -b option does not execute the binary after
compilation.
-P Activate the PSL Profiler

Parameter Definition
-O Specify the optimizer level. (For more information about
optimizer levels, see “Optimization Levels” on page
C-11.)
-q Print the PSL bytecode to the screen
-R Inform the PSL compiler that statically or dynamically
loaded libraries are required for the compilation
Default if not specified: No statically or dynamically
loaded libraries required for the compilation
-e functionname Specify the user-defined function functionname within
the PSL source file as the execution entry point for the
compiled program
Default if not specified: Execution begins with the first
statement within inputfile that is not part of a
user-defined function definition.
-s Instruct the PSL compiler to statically load all user
libraries required for compilation.
Default if not specified: Load library names with the
.lib extension statically and all other library names
dynamically
librarynames List of user library names that should be statically
loaded for compilation. Library names should have the
format library_name.lib. The PSL compiler loads any
library name without the .lib extension dynamically
unless the -l flag is specified.
Default if not specified: No user libraries are included.
-S Display the PSL symbol table

Description
The psl command creates an executable binary file from inputfile and
specified librarynames. The stand-alone interpreter will immediately
execute the compiled binary if options -o outfile, -l, and -b are omitted.
Use this command to create PSL libraries and PSL binaries that can be
used in the PATROL Agent. Doing so allows for a significant
performance gain.
-O Specify the optimizer level. (For more information about
optimizer levels, see “Optimization Levels” on page
C-11.)
-q Print the PSL bytecode to the screen
-R Inform the PSL compiler that statically or dynamically
loaded libraries are required for the compilation
Default if not specified: No statically or dynamically
loaded libraries required for the compilation
-e functionname Specify the user-defined function functionname within
the PSL source file as the execution entry point for the
compiled program
Default if not specified: Execution begins with the first
statement within inputfile that is not part of a
user-defined function definition.
-s Instruct the PSL compiler to statically load all user
libraries required for compilation.
Default if not specified: Load library names with the
.lib extension statically and all other library names
dynamically
librarynames List of user library names that should be statically
loaded for compilation. Library names should have the
format library_name.lib. The PSL compiler loads any
library name without the .lib extension dynamically
unless the -l flag is specified.
Default if not specified: No user libraries are included.
-S Display the PSL symbol table
Parameter Definition
BMC Software, Inc., Confidential and Proprietary Information
5-10 PATROL Script Language Reference Manual
The following PSL features cannot be fully simulated with the PSL
interpreter:
• complex built-in functions such as create() and destroy() that
rely on the full object hierarchy of the agent
• multiple PSL process issues such as timeouts or waiting for a lock
• security issues with functions such as fopen() and cat(), which rely
on the user name operating the agent’s command

Locking Functions for Concurrency Control

2009-08-30T06:41:00.000-07:00

PSL includes two built-in functions for enforcing concurrency control:
lock() and unlock(). These functions are typically used to linearize
accesses by different PSL parameters, commands, and processes to
shared data structures. These shared data structures include the object
hierarchy accessed by the PSL set() and get() functions and external
resources such as files.
All PSL processes attempting to linearize accesses to a resource must
cooperate by requesting locks of a given lock name. All resource
accesses, including the set() and get() functions, are denied shared
resource access without a lock. It is the responsibility of each PSL
process to access a resource only when it holds the required lock.

PSL Built-in Functions

2009-08-29T06:47:00.001-07:00

PSL includes a number of built-in functions that provide
PATROL-specific actions such as creating and manipulating PATROL
objects and general-purpose functions such as mathematical, logical, and
I/O functions. Following is a summary of the PSL built-in functions. The
functions are individually described in Chapter 4, “PSL Built-in
Functions.”

Diagnostics

2009-08-29T06:46:00.000-07:00

If any compilation errors are encountered when a PSL script is compiled,
error messages tell you the line number of the error and briefly describe
the cause of the error. See Chapter 6, “Diagnosing PSL Program Errors,”
for further information.

Optimization

2009-08-29T06:45:00.002-07:00

Like C, PSL does a certain amount of expression evaluation at compile
time, whenever it determines that all of the arguments to an operator are
static and have no side effects.
In particular, string concatenation is done at compile time between string
literals. Backslash interpretation is also done at compile time. You can
say
“Now is the time for all” .“\n” .
“good men to come to.”
and this expression is reduced to one string internally.
PSL is also highly efficient. The language is not immediately interpreted,
but instead is compiled into an internal form, which is then executed by a
high-speed interpreter.

Compiled PSL Binary Files

2009-08-29T06:45:00.001-07:00

PSL includes a standalone compiler to compile PSL scripts and create
executable PSL binaries outside the PATROL Agent. There is also an
external interpreter that simulates all aspects of PSL execution except
those areas specific to the PATROL Agent.

Interpreted PSL Scripts

2009-08-29T06:44:00.002-07:00

Upon receiving a script, PSL compiles the whole script into an internal
form. If the script is syntactically correct, the internal form is then
interpreted. Upon reexecution, the script is not recompiled.