Product Description

Sybase Adaptive Server Enterprise (ASE) is an enterprise-class relational database management system product. ASE is predominantly used on the Unix platform (Solaris, HP-UX, AIX, Linux) but is also available on Microsoft Windows.

ASE was originally called Sybase SQL Server (until version 11.5), but was then renamed to differentiate it from Microsoft SQL Server. Major Sybase ASE Components are the Database Server (Data Server), the Monitor Server, and the Backup Server.

Known Versions

• 10.0.2
• 11.0.x
• 11.5.x
• 11.9.x
• 12.0.x
• 12.5.x
• 15.0.x

Software Pattern Summary

Product Component	OS Type	Versioning	Pattern Depth
Database Server	Unix	Command (Active), Path	Instance-based or Footprint (data dependent)
	Windows	Command (Active), Path, Registry	Instance-based
Backup Server	Unix	Command (Active), Path	Instance-based or Footprint (data dependent)
	Windows	Command (Active), Path, Registry	Instance-based
Monitor Server	Unix	Command (Active), Path	Instance-based or Footprint (data dependent)
	Windows	Command (Active), Path, Registry	Instance-based
Monitor Historical Server	Unix	Command (Active), Path	Instance-based or Footprint (data dependent)
	Windows	Path	Instance-based
XP Server	Unix	Command (Active), Path	Instance-based or Footprint (data dependent)
	Windows	Path	Instance-based
LinkMonitorServerToDataserver	N/A
LinkDataServerToMonitorServer
LinkXPServerToDataserver
LinkDataServerToXPServer

Platforms Supported by the Pattern

The patterns have been created in a manner that allows each of them to support Windows, Linux and Unix platforms from the same module.

Identification

Sybase ASE is composed of 4 major components (with sub-components) which are:

• Database Server (Data Server) - server hosting one or more databases.
• Monitor Server - provides a way to monitor Adaptive Server performance in real time or historical data-gathering mode. Delivers feedback for tuning at several levels - Adaptive Server configuration, Database design, SQL statements in applications and stored procedures
• Monitor Historical Server - provides a way to monitor Adaptive Server performance in historical data-gathering mode.
• Backup Server - dedicated to backing up and restoring Adaptive Server files.
  An optional component may also be running:
• XP Server - allows implementation of Extended Stored Procedures (ESPs). These procedures contain code to carry out functions and tasks external to the server in response to events occurring within the server.

Software Instance Triggers

Component	Trigger Node	Attribute	Condition	Argument
DatabaseServer	DiscoveredProcess	cmd	matches	regex'(?i)\bsqlsrvr\.exe$'
		or
		cmd	matches	regex'\bdataserver$'
		args	matches	regex'-s\s*(?:\S+)'
				or
				regex'-e(?:\S+)'
BackupServer		cmd	matches	regex'\bbackupserver$'
				or
				regex'(?i)\bbcksrvr\.exe$'
MonitorServer		cmd	matches	regex'\bmonserver$'
				or
				regex'(?i)\bmonsrvr\.exe$'
MonitorHistoricalServer		cmd	matches	regex'\bhistserver$'
				or
				regex'(?i)\bhistsrvr\.exe$'
XPServer		cmd	matches	regex'\bxpserver$'
				or
				regex'(?i)\bxpserver\.exe$'
LinkMonitorServerToDataserver	SoftwareInstance	type	=	"Sybase ASE Monitor Server"
LinkDataServerToMonitorServer				"Sybase ASE Database Server"
LinkXPServerToDataserver				"Sybase ASE XP Server"
LinkDataServerToXPServer				"Sybase ASE Database Server"

Simple Identification Mappings

The following components/processes are identified using the combination of pattern definitions and simple identity mappings which map other known (but deemed less important in terms of application modeling) processes.

Name	Command
Sybase Interactive Database client	isql, isql.exe, isqlw.exe, dbisql.exe, dbisqlc.exe or dbisqlg.exe
Sybase Interactive Database client - SQL shell	sqsh
Sybase OpenClient/OpenServer Configuration	ocscfg.exe
Sybase ASE Monitor Server	monserver or monsrvr.exe
Sybase ASE Monitor Historical Server	histserver or histsrvr.exe
Sybase ASE Backup Server	backupserver or bcksrvr.exe
Sybase ASE Backup Server sybmultbuf process	sybmultbuf
Sybase ASE Database Server	sqlsrvr.exe or dataserver
Sybase ASE Database Server engine	dataserver -ONLINE
Sybase ASE Job Scheduler Agent	jsagent or jsagent.exe
Sybase ASE Sybase Central - Java Edition	scjview or scjview.exe
Sybase ASE XP Server	xpserver or xpserver.exe
Sybase ASE Server Configuration	syconfig.exe
Sybase ASE Unified Agent Service	uaservice.exe

Versioning

Version information for the product is currently collected using one of three possible methods.

The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:

Active Versioning

Unix/Linux

The "Active Version Command" method involves either an execution of a single pipeline combining a static command, a dynamic argument from the triggered process command line followed by additional static options/commands, or a more complex command pipeline construction and execution in steps coordinated within the pattern itself.

For Sybase ASE components, the single pipeline approach is used. It uses a combination of a static version command, a dynamic argument from the matched command line followed by additional static options (if applicable).

The command is run once the process has been matched and only if the regular expression used matches the supplied command.

This approach is taken for:

Database Server

Two different variations of the single pipeline approach are used:
1. 'strings' command is executed against a logfile specified by the '-e' argument of the Database Server process command line. The output is parsed for the line containing: 'kernel Adaptive Server Enterprise/' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of strings %logfile_path% | grep "Adaptive Server Enterprise/"' is parsed for:

kernel\s+Adaptive Server Enterprise/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

2. If the version is not obtained using the first approach, a secondary active command version variation is used. In this variation, the actual binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Adaptive Server Enterprise /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/dataserver -v' is parsed for:

Adaptive Server Enterprise/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

NOTE: The first variation of the active version command requires the command-line arguments of 'dataserver' process to contain the path to the logfile (specified by '-e' argument) and that the logfile can be accessed.

The second variation requires that Foundation obtains the absolute path to the 'dataserver' binary and that the user credentials of the Foundation user provide the level of access to allow execution of the binary.

Backup Server

Two different variations of the single pipeline approach are used:
1. 'strings' command is executed against a logfile specified by the '-e' argument of the Backup Server process command line. The output is parsed for the line containing: 'Backup Server/' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of 'strings <logfile> | grep "Backup Server/"' is parsed for:
Backup Server/(\d+\.[d.]*\d)/

If more than one version is returned, the last occurence in the file is taken as the version.

2. If the version is not obtained using the first approach, a secondary active command version variation is used. In this variation, the actual binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Backup Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.
Process: output of '/<absolute_path_to_binary/backupserver -v' is parsed for:
Backup Server/(\d+\.[d.]*\d)/

NOTE: The first variation of the active version command requires the command-line arguments of 'backupserver' process to contain the path to the logfile (specified by '-e' argument) and that the logfile can be accessed.
The second variation requires that Foundation obtains the absolute path to the 'backupserver' binary and that the user credentials of the Foundation user provide the level of access to allow execution of the binary.

Monitor Server

The Monitor Server binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Monitor Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/monserver -v' is parsed for:
Monitor Server/(\d+\.[d.]*\d)/

Monitor Historical Server

The Monitor Server binary is executed with '-v' argument. The resulting output is parsed for the line containing: 'Monitor Historical Server /' and the numeric output following these strings is captured as the 'version' attribute of the Software Instance (SI) node. In addition to this, 'product_version' attribute of the SI node is populated with the version shortened to 'major.minor' level of detail.

Process: output of '/<absolute_path_to_binary/histserver -v' is parsed for:
Monitor Historical Server/(\d+\.[d.]*\d)/

Windows

The "Active Version Command" function calls a static version command.

The command is run once the process has been matched and only if the regular expression used matches the supplied command.

This approach is taken for:

Database Server

The version command results in the sqlsrvr.exe command being run with the '-v' argument appended. The output is parsed for the phrase: 'Enterprise/<version>/' and the <version> numeric output is captured as the version.

Command:

Version Command Regex: (?i)(^\w:.+\\sqlsrvr.exe)\s

Options: -v

Version Regex: Enterprise/(?P<version>(\d+(\.\d+)*))/

This active version command works on the Windows platform because Sybase prevents you from installing Sybase ASE into a directory whose name contains one or more space characters.

Path Versioning

The Path Regex functionality allows a regular expression to be applied against the process command line to derive a version number from the command path or arguments.

Currently, versioning of Sybase Adaptive Server Enterprise is performed on Unix/Linux and Windows by reading information within the command-line path using one of the following regular expressions:

Unix/Linux

This approach is taken for:

Database Server

If "active version command" approach does not yield a version (e.g. access to the logfile is not obtained, or path to the logfile cannot be extracted from the command line), path regex parsing approach is taken.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)((?:\.\d)?)((?:\.\d)?)

Versioning is achieved in this case to depth x.x, x.x.x or x.x.x.x depending on the data available on the process command-line.

Examples of paths that would be matched and versions extracted are:

• /opt/sybase/INFR/LN_INFR_P02_DS/ASE-12_5/bin/dataserver - 12.5
• /opt/sybase/12.5.0.3/ASE-12_5/bin/dataserver - 12.5.0.3
• /opt/sybase/12.0.0.8/ASE-12_0/bin/dataserver - 12.0.0.8
• /opt/Sybase/12.5.3/ASE-12_5/bin/dataserver - 12.5.3

Backup Server

If "active version command" approach does not yield a version (e.g. access to the logfile is not obtained, or path to the logfile cannot be extracted from the command line), path regex parsing approach is taken.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

• /opt/sybase/TEST/LN_TEST_D02_DS/ASE-12_5/bin/backupserver - 12.5
• /opt/sybase/12.5.3/ASE-12_5/bin/backupserver - 12.5
• /opt/sybase/12.0.0.8/ASE-12_0/bin/backupserver - 12.0

Monitor Server

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

• /home/pharaoh/u1111/sybase_15.0/ASE-15_0/bin/monserver - 15.0
• /export/apps/sybase/ASE-12_5/bin/monserver - 12.5
• /opt/sybase/ASE-12_5/bin/monserver - 12.5
• /opt/sybase/DREL/LN_DREL_U01_DS/ASE-12_5/bin/monserver - 12.5

XP Server

Path Regex method is currently the only method used for obtaining the product version for Sybase ASE XP Server.

The regular expression used is as follows:

Path Regex: (?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

An example of a path that would be matched and version extracted is:

• /opt/sybase/IMAG/LN_IMAG_D02_DS/ASE-12_5/bin/xpserver - 12.5
• /opt/sybase/DMR/LN_DMR_R01_DS/ASE-12_5/bin/xpserver - 12.5
• /export45/apps/sybase/ASE-12_0/bin/xpserver -SPDSSPX_CHEOLN1_XP -I/export45/apps/sybase -p8 -s77824 -x - 12.0

Monitor Historical Server

The regular expression used is as follows:

(?:ASE-|/sybase/)(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

• /opt/sybase/ASE-12_5/bin/histserver - 12.5
• /opt/sybase/DREL/LN_DREL_U01_DS/ASE-12_5/bin/histserver - 12.5

Windows

This approach is taken for:

Database Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Backup Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

• C:\sybase\ASE-12_5\bin\bcksrvr.exe - 12.5
• D:\sybase\ASE-15_0\bin\bcksrvr.exe - 15.0

Monitor Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Examples of paths that would be matched and versions extracted are:

• C:\sybase\ASE-12_5\bin\monsrvr.exe - 12.5

Monitor Historical Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

XP Server

The regular expression used is as follows:

Path Regex: (?i)ASE-(\d+)[_.](\d+)

Versioning is achieved in this case to depth x.x

Example of path that would be matched and versions extracted is:

• c:\sybase\ase-15_0\bin\xpserver.exe -C -SSTACKXP_XP -IC:\sybase\ini -p8 -s65536 -e1 -lLocalSystem -aSTACKXP - 15.0

Registry Versioning

Windows only

Using registry queries on hosts running Microsoft Windows can at times return the version of the product a process (or processes) belongs to.

This approach is used when it is likely to provide versioning to greater depth than other approaches, or when other approaches (e.g. path regex) are suspected not to provide enough coverage due to the software deployment patterns used.

There are two limitations to the use of Registry Queries and the data returned:

i) If version is obtained using another approach, version will not be obtained using registry query approach even if that data is to lesser depth than the version that would be obtained using registry queries

ii) We cannot always link the process running to a Registry entry. This limitation is similar to the limitations of the versioning using installed packages.

This approach is taken for:

Database Server

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\SQLServer\CurrentVersion

Versioning is achieved in this case to depth x.x.x or x.x.x.x

Backup Server

The approach will execute if versioning using Regex Path hasn't succeeded and also requires the command-line arguments for Backup Server containing the server name (-S argument followed by a server name).

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server\<server name>\Version

If executed, versioning that can be achieved is to depth x.x.x or x.x.x.x

Monitor Server

The approach will execute if versioning using Regex Path hasn't succeeded and also requires the command-line arguments for Monitor Server containing the server name (-M argument followed by a server name).

The key used to determine the version is:

HKEY_LOCAL_MACHINE\SOFTWARE\SYBASE\Server\<server name>\Version

If executed, versioning that can be achieved is to depth x.x.x or x.x.x.x

Alternative Versioning Approach

We are currently aware of one other potential method to obtain version information for the Database Server and Backup Server on Unix/Linux using Active Version command approach. This method is an extension of the current approach.

Detailed Logfile Parsing

The current version command approach that parses the Database Server or Backup Server logfiles assumes that the logfile has been generated by the version of the server that is currently running. It is possible however, that the server has been upgraded to a later version without re-setting the logs. In this case, the version returned may no longer be correct.

An approach to rectify this could be to parse the whole file for lines containing:

'kernel Adaptive Server Enterprise/' or 'Backup Server/' respectively, and use output obtained from the last line.

This would ensure accuracy, but could have serious performance implications every time a large logfile is encountered. Due to the high probability of performance impact this approach is unlikely to be implemented.

Future Considerations

Application Model Produced by Software Pattern

Product Architecture

An ASE installation typically comprises one "dataserver" which hosts several databases. Some of these are "system" databases which store only meta-data used to keep the system operational. The others are "user" databases which store application data in the form of tables and stored procedures.

Backup Server can either be resident on the same host as the Database Server, or be located in a remote location.

Monitor Server, Monitor Historical Server and XP Server all need to be located on the same host as the Database Server.

Software Pattern Model

An ASE installation typically comprises one "dataserver" which hosts several databases. Some of these are "system" databases which store only meta-data used to keep the system operational. The others are "user" databases which store application data in the form of tables and stored procedures.

Database Server

The Database Server pattern is triggered by the Database Server process (dataserver or sqlsrvr.exe). The name of the database server running is extracted from the command-line arguments using the following regular expression, '-s\s*(\S+)' on Unix/Linux and '(?i)-s\s*(\S+)' on Windows. This name is used to create a unique SI.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name contributes to a unique key for the instance-based SI that is generated. Where this name is not available, a grouped SI is created which groups database servers based on their version.

Relationship Creation

Associate inference relationship is created between the triggered prime process and children processes launched by this process.

Backup Server

The Backup Server pattern is triggered by the Database Server process (backupserver or bcksrvr.exe). The name of the Backup server running is extracted from the command-line arguments using the following regular expression, '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows. This name is used to create a unique SI.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name contributes to a unique key for the instance-based SI that is generated. Where this name is not available, a footprint SI is created which groups Backup servers based on their version.

Relationship Creation

Associate inference relationship is created between the triggered prime process and children processes launched by this process.

Monitor Server

The Monitor Server pattern is triggered by the Monitor Server process (monserver or monsrvr.exe). The name of the Monitor server running is extracted from the command-line arguments using the following regular expression, '-M(\S+)' on Unix/Linux platform and '(?i)-M(\S+)' on Windows. This name is used to create a unique SI.

In addition to this, where available on the command-line, the name of the Database Server being monitored is extracted using the following regular expression ('-S(\S+)') and stored as 'db_server_monitored' attribute on the SI node generated. This attribute is later used to model communication between the Database Server and the Monitor Server.

On Unix hosts, the trigger process is combined with a set of its parent processes as well as any child processes to the trigger process.

SI Depth

The server name contributes to a unique key for the instance-based SI that is generated. Where this name is not available, a footprint SI is created which groups Backup servers based on their version.

Monitor Historical Server

The Monitor Historical Server pattern is triggered by the Monitor Historical Server process (histserver). The name of the Monitor Historical server running is extracted from the command-line arguments using the following regular expression, '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows.

SI Depth

The server name contributes to a unique key for the instance-based SI that is generated. Where this name is not available, a footprint SI is created which groups Backup servers based on their version.

XP Server

The XP Server pattern is triggered by the XP Server process (xpserver). The name of the XP server running is extracted from the command-line arguments using the following regular expression '-S(\S+)' on Unix/Linux and '(?i)-S(\S+)' on Windows.

In addition to this, where available on the command-line, the name of the Database Server that launched the XP server is extracted using the following regular expression '-S(\S+)_XP' and stored as 'db_server_related' attribute on the SI node generated. This attribute is later used to model communication between the Database Server and the XP Server.

SI Depth

The server name contributes to a unique key for the instance-based SI that is generated. Where this name is not available, a footprint SI is created which groups Backup servers based on their version.

Communication between Database Server and Monitor Server

Two patterns have been developed to model the communication between the Database Server and Monitor Server. This communication is via shared memory hence isn't detectable via monitoring of open ports, but the Monitor Server command-line usually provides the information about the monitored Database Server via the '-S' attribute. This information is captured in the 'db_server_monitored' attribute of the Monitor Server SI node.

As patterns can trigger in any order, and this relationship can only be created once both Database Server and Monitor Server SIs exist, two patterns are required to ensure that this relationship is created. One pattern triggers when a Database Server SI has been generated, while the other when the Monitor Server SI has been generated.

Only one of these patterns will be successful at any one time.

In either case, once triggered, the pattern searches for either the Database Servers or the Monitor Servers (depending on the pattern) where the 'db_server_monitored' attribute of the Monitor Server SI node matches the name of the Database Server on the same host.

For each match that occurs, a communication relationship of type 'Peer to Peer' is created.

Communication between Database Server and XP Server

Two patterns have been developed to model the communication between the Database Server and XP Server. This communication is established when the Database Server needs to launch the XP server in order for external stored procedures to be executed. The XP Server command-line usually provides the information about the Database Server via the '-S' attribute. By default, the name of the XP server is the same as that of the Database Server with '_XP' string appended. This information is captured in the 'db_server_related' attribute of the XP Server SI node.

As patterns can trigger in any order, and this relationship can only be modeled once both Database Server and XP Server SIs exist, two patterns are required to ensure that this relationship is modeled. One pattern triggers when a Database Server SI has been generated, while the other when the XP Server SI has been generated.

Only one of these patterns will be successful at any one time.

In either case, once triggered, the pattern searches for either the Database Servers or the XP Servers (depending on the pattern) where the 'db_server_related' attribute of the XP Server SI node matches the name of the Database Server on the same host.

For each match that occurs, a communication relationship of type 'Peer to Peer' is created.

Installation Root

The product's installation root is extracted by parsing the command line arguments against the following regular expression:

UNIX

• -e(\S+/ASE-\d+_\d+)

Windows

• ^(\S+\\ASE-\d+_\d+)

Port Information

The DatabaseServer, BackupServer and MonitorServer patterns attempt to get port information for the product. On UNIX, such information is retrieved from the 'interfaces' file which is relative to the product's installation path. On Windows, such information is retrieved from the 'sql.ini' file in the 'ini' directory relative to the product's installation path.

First of all, the patterns attempt to get the installation path (base path) for the product from the command line arguments using one of the following regular expressions:

• Unix: -e(\S+)/ASE-\d+_\d
• Windows: ^(\S+)\\ASE-\d+_\d

Once the installation path is known, the 'interfaces' or 'sql.ini' file is read line by line to locate the required server's section and then the required attribute within that section.

The following regular expression is applied to each line until the start of the section for the required server is located:

• ^\[?%srv_name%\]?\s*$

where %srv_name% is replaced by either the DB server name, the Backup Server name or the Monitor Server name.

Once the required section has been located, a further regular expression is applied to each subsequent line within the section to extract the port:

• \bmaster tcp ether %hostleafname%\s(\d+)

where %hostleafname% is replaced by the leafname of the host name.

Listing Sybase Database Installed Options and Obtaining Edition Information

A separate pattern is used to identify and model a selection of Installed Options in the Sybase ASE Database. Additionally, this pattern also attempts to determine the edition of the Sybase ASE installation. For more information on this approach, please refer to the relevant page.

Obtaining detailed Sybase ASE Database and table information

A separate pattern has been created to query the Sybase ASE Database Server in order to obtain database list and (optionally) database table details. For more information about this pattern, please refer to the relevant page

Subject Matter Expertise

The set of fingerprints for Database Server and Backup Server running on Unix/Linux hosts, including approaches used to version the product have been developed with input from JPMC.

Subject Matter Expert input will be welcome on any other potential approaches not discussed to improving product versioning coverage and depth of Sybase ASE components.

Sybase ASE Database Server process identification on Unix/Linux has been updated based on feedback from Sybase SMEs at DrKW and JPMC (via David Futter). Identification changed from 'dataserver .-e' to 'dataserver .-s\S' as '-s' command-line argument is more likely to be present on the process command line, whereas '-e' is more likely to be an optional argument and not always be present.

Testing

Unix/Linux

Testing to ensure the processes related to Sybase ASE components have been correctly identified has been performed using Foundation record data from hosts running Solaris, AIX and Linux operating systems.

Record data also contained enough information to extract the version information for all three major components (Database Server, Backup Server, Monitor Server) using the Regex Path versioning approach.

In addition to this, active version command approach was developed and initially evaluated both on in-house Sybase ASE installations and on customer sites. The approach taken was shown to work well provided the environment conditions this approach requires were met.

Windows

Testing to ensure the processes related to Sybase ASE components have been correctly identified has been performed using in-house Sybase ASE installations.

Path regex and Registry versioning approaches were also tested against in-house Sybase ASE installations and were deemed to work well unless constrained by the data returned from the hosts (e.g. Foundation discovery typically cannot obtain process command-line on hosts running Windows NT or Windows 2000 Server. This limitation no longer exists on hosts running Windows XP or Windows 2003 server).

Information Sources

Open Issues

N/A

TOP

Created by: Rebecca 08:07, 19 October 2007 (PDT)
Reviewed by: Nikola Vukovljak 20 October 2007
Updated by: Rebecca Shalfield 12:39, 30 January 2009 (GMT)
Updated by: Rebecca Shalfield 14:42, 07 February 2012 (GMT)
Updated by: Rebecca Shalfield 15:25, 19 March 2012 (GMT)
Reviewed by: Chris Blake 09:56, 20 March 2012 (GMT)