TECHNOTE: Best Practices for
Implementing Self-maintenance on Radia
Management Clients, Version 4.0
Document ID: KB01376
Date Created: 11/19/2004
Last Revised: 12/07/2004
Introduction
This document describes the best practices for implementing and using self-maintenance
on version 4.0 Radia Management Clients (herein, Radia Clients). Client selfmaintenance is the updating of the binary files (.EXE, .DLL, .SYS) that are used by the
Radia Clients. These updates are periodically provided by Hewlett-Packard either as part
of routine maintenance, or in response to a critical customer-reported problem. The Radia
Clients are:





Radia Application Manager (RAM)
Radia Inventory Manager (RIM)
Radia OS Manager (ROM)
Radia Patch Manager (RPM)
Radia Software Manager (RSM)
Version 4.0 introduced significant changes in the way self-maintenance is performed.
The information in this document applies only to version 4.0 Radia Clients connecting to
a version 4.0 Radia Database.
Note
Information about performing self-maintenance on Radia Clients, version 3.x can
be found in KB01210, MAINTENANCE: Radia Client Self-Maintenance –
version 3.0.
Requirements & Prerequisites
Product Versions
Radia Application Manager, Radia Inventory Manager, Radia OS Manager, Radia Patch
Manager, Radia Software Manager, 4.0 and greater
Platforms
AIX, HP-UX, Macintosh, Linux, Solaris, and Windows
Components & Processes
Components
Radia Application Manager, Radia Inventory Manager, Radia OS Manager, Radia Patch
Manager, Radia Software Manager
Processes
Self-maintenance, deployment, reporting
New Self-maintenance Features in Version 4.0
A number of features have been added in version 4.0 to improve self-maintenance. The
following list provides a high-level overview:




PRDMAINT Domain
The Radia Database includes a new Domain, PRDMAINT, for use with version
4.x client maintenance. Version 3.x clients will continue to still use the
NOVADIGM domain. Both domains can co-exist in a Radia Database, thereby
allowing existing 3.x clients and new 4.x clients to use the same database.
Resource Arbitration
All maintenance files in a package will first be compared to the files in IDMSYS
(C:\Program Files\Novadigm on Windows platforms) to determine if they should
be downloaded, as opposed to previous versions of Radia Clients which
unconditionally downloaded all of the files to a staging directory and then did a
comparison. This new method will eliminate unnecessary file transfers and reduce
bandwidth usage.
Resource Verification
Resources that are downloaded to the staging folder will verify the internal release
information against additional release attributes in the metadata. Only the files
that fall under the same release category (such as 4.0) will be eligible for
activation into IDMSYS. In addition, the normal resource-verification flag
(ZRSCVRFY) is now honored. The default is U, update only if newer. These
changes prevent files from being back-leveled in the event maintenance packages
are incorrectly configured.
Support for Multiple Services
Client self-maintenance is no longer limited to one ZSERVICE Instance for all
clients and platforms. Maintenance services are now included in the catalog
(ASERVICE), so it is possible to use more than one service instance.





Piloting
Support for multiple service instances in the catalog (ASERVICE) allows for
piloting. Piloting new maintenance packages to a small group was not possible
with previous versions because new maintenance packages had to be connected to
a single client self-maintenance service, which meant that all production clients
would simultaneously receive any updates made to this service.
Another technique for piloting is the use of a stop expression on the maintenance
package. All maintenance packages are shipped in a disabled state—setting the
stop expression, ZSTOP000, to 1—in order to prevent immediate deployment.
This stop expression can be updated to check resolution- and policy-object
variables in order to facilitate deployment to a specific user community
(WORKGRP and POLICY are recommended).
Immediate or Deferred Activation
Maintenance packages can now be staged on the target machines and activated
immediately, or deferred. Immediate activation places the maintenance files in the
live location prior to processing the normal application catalog, making them
available before normal application-processing occurs. During the deployment,
activation can be optionally deferred and initiated another time by either a timer
instance, notification from the Radia Management Portal (RMP), or changing the
activation parameter using Client Operations Profiles (COP). This gives the
administrator the flexibility to deploy maintenance packages ahead of time and,
before committing the changes, verify that all clients received them.
Backup and Restore Capabilities
Installation of the version 4.0 client creates a backup directory with a copy of the
core files that are necessary to perform a client connect. In the event that the client
files in IDMSYS get corrupted, the core files located in the backup directory can
be restored using upgrdmaint (upgrdmaint /restore). This repairs the client so it
can then perform the verification and repair any missing or corrupted files.
Administrators also have the ability to update this backup directory with later
versions of the client.
Reporting via the APPEVENT Object
When maintenance files are activated into IDMSYS, an APPEVENT object is
created and sent to the Radia Configuration Server (RCS) for reporting. The
ZSVCNAME is set to UPGRDMAINT, and the ZUSERID is equal to the
machine name.
Maintenance is not Linked to First Refresh-Catalog Operation
A new RADSKMAN parameter-and-value pair, MNT=Y, must be passed in order
to start the self-maintenance process. This allows administrators to perform
maintenance on a schedule other than the normal application processing. By
default, MNT=N.
Radia Client Fix Types
Radia Client fixes are classified as one of the following:



Hot Fixes
Hot fixes are usually provided in response to a high-severity production problem
or security issue for which a work-around is not possible. Hot fixes are provided
for specific problems only, and are sometimes later superseded by code changes
that are included in a fix pack or service pack. Hot fixes tend to be customerspecific and are not, therefore, included in later releases of the product. For these
reasons, hot fixes are provided by Technical Support only; they are not available
for customers to download via the patch download site.
Fix Packs
Fix packs are smaller, intermediate, regression-tested releases of hot fixes that are
created to resolve specific customer-reported problems. Fix packs are released
every 6–8 weeks, or as required, and generally contain 5–6 components.
Service Packs
Service packs are a cumulative collection of the previously released fix packs and
hot fixes and, as such, they supersede those fix packs and hot fixes for a minor
release of a product (such as, 4.0, 4.1, and 4.5). New releases of the product are
considered an upgrade and therefore are not performed using self-maintenance.
The fixes that are contained in a service pack are regression tested. Service packs
are generally released every 4–6 months depending on the operating-system
platform and number of fixes available.
For example: Hewlett-Packard might offer several service packs for the version4.0 release. These service packs would be 4.0.1, 4.0.2, 4.0.3, etc., and selfmaintenance would be used to deploy them. The next release (considered an
upgrade) would be version 4.1, which would not be deployed via selfmaintenance; rather, specific instructions for performing the upgrade would be
provided.
Implementing Radia Client Self-maintenance
This section explains each of the six tasks (shown in Figure 1) that Hewlett-Packard
recommends for performing Radia Client self-maintenance.
Figure 1 ~ Importing Maintenance Packages
Importing Maintenance Packages
The first step to configure self-maintenance is to import the packages. In version 4.0 there
is a new database Domain, PRDMAINT (shown in Figure 2), for Radia Client selfmaintenance.
Note
This Domain is for Radia Clients, version 4.0 and later.
Prior versions of Radia Clients must continue to use the NOVADIGM Domain
for self-maintenance.
Previous releases are protected in several ways from receiving version-4.0 maintenance.



The staging directory is different on the version 3.x and version 4.0 Radia Clients;
and the self-maintenance method, UPGRDMAINT, is version-specific.
The version-4.0 maintenance services have a special ZSTOP expression that
prevents pre-version 4.0 Radia Clients from receiving the service.
UPGRDMAINT checks the internal version information in the maintenance files
in order to ensure that the fixes match the client version.
Figure 2 ~ PRDMAINT domain
In order to prevent package-configuration problems, Hewlett-Packard provides version
4.0 self-maintenance packages as export decks. These export decks eliminate the need for
customers to publish fixes, which alleviates problems that were caused by using an
incorrect drive or directory when publishing the fix.
HP-Supplied Product Maintenance
The following examples show the contents of a typical hot fix, fix pack, and service pack.
Hot Fix
File name: R3207014.zip
Contents: RAM_WIN32_NT_4_0_HF_R3207014.xpi,
RAM_WIN32_NT_4_0_HF_R3207014.xpr, and RADCONCT.EXE.
Fix Pack
File name: FPCORE01.zip
Contents: RAM_WIN32_NT_4_0_FPCORE01.xpi,
RAM_WIN32_NT_4_0_FPCORE01.xpr
Service Pack
File name: SP401.zip
Contents: Service packs contain various export decks, depending on the client platform.
Appropriate documentation is provided with each service pack.
Import Steps
1. Download the hot fix, fix pack, or service pack files.
2. Extract the contents into the Radia Configuration Server's exe directory. (UNIX)
Extract the contents into the Radia Configuration Server's bin directory. (Windows)
3. Stop the Radia Configuration Server service.
4. Import the files using the ZEDMAMS utility, IMPORT_INSTANCE. (For detailed
information this utility, see the Radia Configuration Server Guide.)
IMPORT_INSTANCE command-line example (Windows):
ZEDMAMS
VERB=IMPORT_INSTANCE,FILE=RAM_WIN32_NT_4_0_CORE01.XPI,
XPR=RAM_WIN32_NT_4_0_CORE01.XPR,DUPLICATES=MANAGE,COMMIT_C
HANGES=YES,REPLACE=YES,
CONTINUE=YES,PREVIEW=NO
5. Verify that the ZEDMAMS.LOG (or other log file defined by the parameter
log=<filename.log>) ends with a return code less than or equal to 4.
6. Restart the Radia Configuration Server service.
Customer-Specific Maintenance
Using self-maintenance, customer-specific scripts or methods can be deployed to, and
updated on, the Radia Clients. Examples of customer-specific scripts are:
INITMETH.REX, PRESETUP.REX, ARGS.XML, and any other customer-specific
script, batch file, or executable that needs to be deployed to the IDMSYS folder. Standard
Radia Client fixes should not be published using this method; HP-supplied export decks
must be used (refer to the previous section, HP-Supplied Product Maintenance).
Note
The Radia Packager that is included as part the version 4.0 Radia Administrator
Workstation suite does not support custom-maintenance publishing. Customers who
need to publish custom maintenance must contact Technical Support for a Radia
Packager update.
Custom maintenance can be published using the Radia Packager for Radia, version 4.0
(formerly the Radia Publisher) as follows:
1. Copy the custom-maintenance files into the IDMSYS folder of the machine on which
the Radia Packager is installed.
2. Launch the Radia Packager and log in.
3. In the Session Type box select Component Selection Mode.
4. Enter a Session ID and Description.
Click Next.
5. Enter a Package Name, select PRDMAINT for the Domain, and complete the
Description and Release information.
Click Next.
6. At the System Configuration and Availability panels, change nothing.
Click Next.
7. Expand the IDMSYS folder and select the custom-maintenance files that are to be
published.
Click Next.
8. Expand the folders that are displayed under the Files tab.
Right-click and from the context menu select Set Properties|Directory and Files.
9. The Properties and Locations panel will have the Maintenance Radia button
selected on the Data Options tab, do not change this.
Select the Verification options and Delivery Options setting on the Client
Management tab.
Click OK to save the changes and Next to continue.
10. Click Promote to complete the packaging session.
Preparing Maintenance Service
Figure 3 ~ Preparing Maintenance Service
After the maintenance package has been imported, it will be connected to the Maint 40
sample Application Service (ZSERVICE) instance that is provided in the default
database. Launch Radia System Explorer and expand the PRDMAINT domain.
The Application Service Class in the PRDMAINT Domain has an instance named Maint
40 in the default database. This instance has five _ALWAYS_ connections to instances in
the PRDMAINT Class, one connection for every Radia Client type. Notice that the value
for each connection uses symbolic substitution to attributes in ZMASTER and
IDENTITY, as in:
PRDMAINT.RAM_&(ZMASTER.ZOSTYPE)_&(IDENTITY.RAMREL)


ZMASTER_ZOSTYPE is a new attribute that the Radia Client populates with a
value (such as ‘WIN32_NT’ for NT-class Windows operating systems).
IDENTITY.RAMREL is a new attribute that contains a release value, such as
4_0, 4_1, and 4_2.
The combination of these symbolic values allows for simplified connections that can
handle a wide variety of operating-system platforms. These five connection values should
not be altered. If additional service instances are added in order to support piloting, these
five connection values should be copied into the new service instance.
The Maint 40 service also includes the ZSTOP expression
(EDMGETV('IDENTITY','RAMREL')=''). This expression eliminates unnecessary
resolution and metadata downloading by preventing the service from being included in
the catalog for previous client releases. This expression should also be used for any
additional service instances that are created.
Figure 4 ~ Default Maintenance Application Service Instance
By default, all self-maintenance packages (hot fixes, fix packs, and service packs) will be
provided with a value of 1 for the ZSTOP000 expression (as seen in Figure 5). This
prevents the new package from being accidentally deployed and activated by stopping the
resolution process. Administrators will have to remove this value as the last step before
attempting to deploy the new package.
Figure 5 ~ Maintenance Package Instance with ZSTOP000 set to 1
In the PRDMAINT Domain there is a PRDMAINT Class that contains twenty Requires
Connection-type attributes (see Figure 6). Instances in this Class are the anchor point for
all self-maintenance packages in the PACKAGE Class.
Figure 6 ~ PRDMAINT Class
There are five PRDMAINT Class Instances in the default Radia Database, one for each
Radia Client. See the Database Tree View in Figure 6. Each time a fix pack or service
pack is released, HP will supply export decks for the entire PRDMAINT Class.
Therefore, these instances should not be changed because they will be overwritten when
the new instances are imported.
Figure 7 ~ RAM_WIN32_NT_4_0 Instance
The first two Requires Connection slots in each instance are already populated; these
values must not be changed. These two connections refer to PACKAGE Instances in the
default database (see Figure 7). If these types of packages are needed, the hot fix or
custom fix package must be connected to one of these two default packages using a
Requires Connection. By using this connection scheme, all of the PRDMAINT
Instances can be replaced and their referential integrity to the PACKAGE Class is
maintained.
Hot Fix Example
Figure 8 shows an example of a hot fix package
(RAM_WIN32_NT_4_0_HOTFIX_R3207017) that might be supplied by HP. The
instance that represents this hot fix is connected to the default package
RAM_WIN32_NT_4_0 using a REQUIRES connection. This is the proper way to
connect a hot fix package.
Eventually, this hot fix might be included in a fix pack or service pack, in which case it
would then be made available as part of the appropriate export deck. In the export deck,
the PRDMAINT Instances will be pre-configured with the required package connections.
The Radia administrator can remove the values in the REQUIRES slots that refer to any
previous hot fixes after verifying that the hot fix is part of the fix pack or service pack by
referring to the fix number appended to the instance name. This information is included
in the Release Notes for the fix pack or service pack.
Note
Using the example in Figure 8, the Radia administrator should, prior to removing this
Requires Connection, read the Release Notes for the fix pack or service pack in order
verify that fix R3207017 was included.
Figure 8 ~ RAM_WIN32_NT_4_0_HOTFIX Instance
Fix Pack Example
Figure 9 shows an example of a fix pack package (RAM_WIN32_NT_4_0_ FPCORE01)
that might be supplied by HP. The PRDMAINT Class and
RAM_WIN32_NT_4_0_FPCORE01 package are provided as export decks so there is no
need for a Radia administrator to make any connections after importing the package. By
design, the fix pack is connected to the last Requires Connection slot. Subsequent fix
pack packages would be added in the preceding vacant slots until a service pack is
released. When a service pack is released, the new PRDMAINT Instances that are
provided will remove all of the existing fix-pack connections and only one connection to
the service pack will remain.
Note
Always backup the Radia Database before importing maintenance decks.
Figure 9 ~ RAM_WIN32_NT_4_0 Instance with a Fix Pack configured
Custom-Maintenance Example
Figure 10 shows how to configure a custom-maintenance package. The example shows a
package, RAM_WIN32_INITMETH_01, connected to
RAM_WIN32_NT_4_0_CUSTOM via a REQUIRES connection.
RAM_WIN32_NT_4_0_CUSTOM is provided in the default database and must be used
as the anchor point for any custom-maintenance packages.
Figure 10 ~ RAM_WIN32_NT_4_0_CUSTOM Instance with a custom maintenance
package configured
Configuring Client Operations Profiles (optional)
Figure 11 ~ Preparing COP
By default, self-maintenance resources are automatically activated or installed when
delivered to the desktop. The Radia administrator can, however, use the Radia Client
Operations Profiles (COP) component to specify when self-maintenance will be
activated. Although COP is not required in order to perform self-maintenance, it is
required in order to change the default activation values. The attribute that controls this
feature, ACTMAINT, is in the CLIENT.SETTINGS Class.
The values of ACTMAINT are listed and described in Table 3.
Table 1  ACTMAINT Values
Attribute Value
I (or blank)
Description
This is the default behavior—resources will be immediately activated or copied into the IDMSYS folder
from the staging folder when the maintenance service is downloaded.
Immediate
P
Prompt
For RSM clients, the user interface will display a dialog stating that the Radia Client needs to be
updated, and that the session will restart after the activation is complete. The dialog contains an OK
button only.
For RAM clients, the behavior is the same as I (Immediate).
For RSM clients, this will instruct the user interface that maintenance needs to be applied. The user
interface will display a dialog stating that the Radia Client needs to be updated, and that the session will
restart after activation.
Table 1  ACTMAINT Values
Attribute Value
D
Deferred
Description
This will populate the staging folder but will not activate maintenance during normal processing. The
client method, UPGRDMAINT.EXE, must be invoked on an independent schedule in order to activate
staged resources using a timer or notification from the Radia Management Portal.
The SETTINGS Class Instance is part of the CLIENT Domain that is used during COP
resolution. Complete instructions for implementing COP can be found in the guide, HP
OpenView Application Manager Using Radia.
Implementing Entitlement Policy
Figure 12 ~ Implementing Entitlement Policy
Entitlement policy can be defined using either an internal or external policy model.
Internal Policy Model
The Maint 40 instance is connected to the _BASE_INSTANCE_ of the POLICY.USER
class. This connection will cause all new USER Instances to inherit this value and be
entitled to this service.
Note
This connection can be removed from USER._BASE_INSTANCE_ and instead be
connected to a Workgroups (WORKGRP) or Departments (DEPT) instance. The
same users will be entitled to the service, but as a result of belonging to a department
or workgroup, rather than each having to be defined in the USER Class.
Figure 13 ~ Self-maintenance service connection using internal Radia policy model
External Policy Model
Policy can also be defined using a directory service such as LDAP or NDS. The Radia
Policy Server can be used to assign the self-maintenance service to either users or
computers in the directory tree.
Note
For more information, refer to the guide, HP OpenView Policy Server Using Radia.
Deploying the Self-maintenance Service
Figure 14 ~ Deploy Service.
Deployment of the self-maintenance service can be performed as part of a standard client
connect, or as part of a connection process that is created specifically for delivering
maintenance. In order to initiate self-maintenance during a standard RAM client connect,
a new RADSKMAN parameter (MNT=Y) is required on the command line with the other
RADSKMAN parameters. When the client connect is started, the self-maintenance
service will be processed and the maintenance files will be installed immediately—not
after the client connect has ended. This differs from previous releases of the Radia
Clients.
Note
Remember, in order to change the default behavior of the service being automatically
installed, the ACTMAINT attribute must be changed from its default value of I.
And, in order to change the default of the ACTMAINT attribute, the Radia COP
component is required.
In the following example, the self-maintenance files will be immediately activated
because cop=y is not specified.
Radskman cat=prompt,ip=192.168.1.10,mnt=y
Note
For a complete list of the RADSKMAN parameters, refer to the TechNote/Engineering
Note, RADSKMAN: Parameters and Examples for Version 4.x.
Activating a Deferred Self-maintenance Service
If the deployment of a self-maintenance service was deferred (ACTMAINT=D), the
service needs to be activated. This can be accomplished by Notifying the client via the
Radia Management Portal or using a timer to run UPGRDMAINT.
Activation using the Radia Management Portal
1. Select the Notify operation.
2. From the Notify Type drop-down list, select Custom Notify.
3. In the Command box in the Notify Information section, enter UPGRDMAINT.
4. Complete the information in the remaining panels and click Submit.
Now, running UPGRDMAINT will activate any deferred self-maintenance files that are
on the client.
Activation using a Timer to run UPGRDMAINT
A timer can be deployed to activate self-maintenance immediately and in the future.
Using this method, maintenance files and the timer instance can be deployed as part of a
normal daily Radia client connection. Once this timer and deferred maintenance are in
place, the timer will activate the files based on the schedule determined by the
administrator.
1. In the PRDMAINT.TIMER Class select one of the Sample Timer instances, such as
Daily Apply Self Maintenance.
2. Specify the following values:



ZSCHFREQ=ONCE
ZRSCCMDL=upgrdmaint
ZSCHDEF=MONTHLY(20041201,01:00)
3. Connect this TIMER instance to the self-maintenance service instance prior to
deployment with the deferred setting.
When the “timer” (established by ZSCHDEF) expires, the (deferred) self-maintenance
service will be activated.
Note
For complete details on configuring a TIMER instance, refer to the section, Scheduled
Deployment Strategy in the in the guide, HP OpenView Application Manager Using
Radia.
Performing a Self-maintenance only Connection
Self-maintenance packages can also be deployed during a dedicated maintenance only
client connection. This type of connection does not process the applications in the
software catalog. This method can be used to:


Provide greater control when self-maintenance files are deployed
Allow self-maintenance updates to occur on a schedule separate from other
updates, and with less frequency (such as weekly or monthly, instead of daily)
Self-maintenance only Connection using the Radia Management Portal
1. Select the Notify operation.
2. From the Notify Type drop-down list, select Custom Notify.
3. Specify:
Radskman Req=“Self Maintenance”, ip=<RCS_IP_address>
Self-maintenance only Connection using a Timer
To perform maintenance only, specify:
Radskman Req=“Self Maintenance”, ip=<RCS_IP_address>
Note
When this syntax is used MNT=Y is automatically set.
The PRDMAINT Domain has a TIMER Class that contains three sample TIMER
Instances. The first, Daily Apply Self Maintenance, has ZRSCCMDL=UPGRDMAINT
specified. This instance can be used to activate maintenance that was previously
deployed, but with the activation deferred, ACTMAINT=D. The ZSCHDEF parameter
needs to be configured with the desired schedule. The sample uses DAILY, but this can
be changed to WEEKLY and MONTHLY.
The two remaining samples are configured to deploy and activate maintenance using the
parameter, Radskman Req=“Self Maintenance”. The ZSCHDEF parameter needs to be
configured with the desired schedule.
Restoring and Updating the Backup Folder
By default, the client installation creates a backup folder that contains the minimum
components required to perform a connection to the RCS. This backup folder, which
resides in the IDMROOT folder, enables the restoration of the Radia Client in the event
the IDMSYS directory becomes corrupted or files are deleted. Its contents can be restored
into the IDMSYS folder by running UPGRDMAINT, and can be updated if code is
subsequently deployed to the client.
Restoring a Damaged Radia Client using the Radia Management Portal
1. Select either the Notify by Device or Notify by Subscription operation.
2. From the Notify Type drop-down list, select Custom Notify.
3. Specify:
upgrdmaint /restore
This will copy the contents of the backup folder to the IDMSYS folder. The Radia Client
will now be functional so a notification can be sent to perform a full connect or a
maintenance-only connect in order to repair the client files.
Upgrading the Backup Folder using the Radia Management Portal
1. Select the Notify operation.
2. From the Notify Type drop-down list, select Custom Notify.
3. Specify:
upgrdmaint /backup
This will copy the core files from the IDMSYS folder into the backup folder. This
command is useful after a service pack or fix pack has been deployed to the client so that
the backup folder is synchronized with the latest maintenance.
Deployment Recommendations



If Radia is configured to perform machine and user connections, configure the
self-maintenance service to be a Machine-only service. Do this by setting the
ZSERVICE.ZSVCMODE attribute to M. When the user connection is performed
(context=u), the maintenance service will be skipped. This will prevent
unnecessary data transfer and verification of the maintenance service when the
user initiated connection runs.
Customers who are using RAM and RSM Clients on the same machine should
perform maintenance during the RAM connect only. This will prevent prompts
informing the user that Radia updates need to be applied.
Customers who are using only RSM will need to add the MNT embed tag to the
ARGS.XML file so that the RSM client performs maintenance. The correct
syntax is shown in the following example.
<?xml version="1.0" ?>
<RADIA_ARGUMENTS>
<ARGUMENTS>
<PROVIDERNAME>RADIA</PROVIDERNAME>
<RESOLUTIONMANAGER>192.168.1.10</RESOLUTIONMANAGER>
<STARTDIR>SYSTEM</STARTDIR>
<IDENTIFICATION>$machine</IDENTIFICATION>
<CHANNELNAME>SOFTWARE</CHANNELNAME>
<RESOLUTIONPORT>3464</RESOLUTIONPORT>
<MNT>Y</MNT>
</ARGUMENTS>
</RADIA_ARGUMENTS>
Reporting
Figure 15 ~ Examine Reporting results
Reporting for the self-maintenance service is now identical to the reporting that is
available for other Radia-managed services. The _BASE_INSTANCE_ in the
PRDMAINT.ZSERVICE Class has the standard Radia EVENTS attribute for defining
application events on which to report. By default, all reporting events are set to B (Both).
Figure 16 ~ Self-maintenance service Event Reporting
Use the Radia Reporting Server to review the event information for the maintenance
service. See the HP OpenView Reporting Server Guide.
Further Reading
HP OpenView using Radia System Explorer Guide
Legal Notices
Warranty
Hewlett-Packard makes no warranty of any kind with regard to this document, including,
but not limited to, the implied warranties of merchantability and fitness for a particular
purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct,
indirect, special, incidental or consequential damages in connection with the furnishing,
performance, or use of this material.
A copy of the specific warranty terms applicable to your Hewlett-Packard product can be
obtained from your local Sales and Service Office.
Restricted Rights Legend
Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set
forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software
clause in DFARS 252.227-7013.
Hewlett-Packard Company
United States of America
Rights for non-DOD U.S. Government Departments and Agencies are as set forth in FAR
52.227-19(c)(1,2).
Copyright Notices
© Copyright 2005 Hewlett-Packard Development Company, L.P.
No part of this document may be copied, reproduced, or translated into another language
without the prior written consent of Hewlett-Packard Company. The information
contained in this material is subject to change without notice.
This product includes software developed by third parties, including:
PREBOOT EXECUTION ENVIRONMENT (PXE) SERVER, Copyright © 1996-1999
Intel Corporation.
TFTP SERVER, Copyright © 1983, 1993 The Regents of the University of California.
OpenLDAP, Copyright 1999-2001 The OpenLDAP Foundation, Redwood City,
California, USA.
Portions Copyright © 1992-1996 Regents of the University of Michigan.
OpenSSL License, Copyright © 1998-2001 The OpenSSLProject.
Original SSLeay License, Copyright © 1995-1998 Eric Young (eay@cryptsoft.com)
Trademark Notices
Linux is a registered trademark of Linus Torvalds.
OpenLDAP is a registered trademark of the OpenLDAP Foundation.
Acknowledgements
PREBOOT EXECUTION ENVIRONMENT (PXE) SERVER
Copyright © 1996-1999 Intel Corporation.
TFTP SERVER
Copyright © 1983, 1993
The Regents of the University of California.
OpenLDAP
Copyright 1999-2001 The OpenLDAP Foundation, Redwood City, California, USA.
Portions Copyright © 1992-1996 Regents of the University of Michigan.
OpenSSL License
Copyright © 1998-2001 The OpenSSLProject.
Original SSLeay License
Copyright © 1995-1998 Eric Young (eay@cryptsoft.com)
DHTML Calendar
Copyright Mihai Bazon, 2002, 2003
©1997-2005 HP/Novadigm, Inc. All rights reserved. Terms of use. Legal notices.
E-Mail: support.mail@hp.com Disclaimer.
These materials contain the confidential, proprietary information of HP.