Maintenance outage for upgrade on Sunday, September 22

This site, docs.bmc.com, will be inaccessible for two hours starting at 8 AM CDT, Sunday, September 22, for a platform upgrade.

    Page tree
    Skip to end of metadata
    Go to start of metadata
    Discover with BMC Discovery
    download

    This product can be discovered by any edition of BMC Discovery. Download our free Community Edition to try it out, or [see what else it can discover] !

    What is this?
    This is a product information page, containing details of the information that BMC Discovery gathers about a product and how it is obtained.
    Product Name
    Adaptive Server Enterprise
    Publisher Page
    Sybase
    Category
    Relational Database Management Systems
    Release
    TKU 2019-Aug-1
    Change History
    Sybase Adaptive Server Enterprise - Change History
    Reports & Attributes
    Sybase Adaptive Server Enterprise - Reports & Attributes
    Publisher Link
    Sybase

    Product Description

     

    Extended Discovery pattern which allows to model Database Detail Nodes being managed by the Sybase Database Server  is available for this product.

     

    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
    • 11.0
    • 11.5
    • 11.9
    • 12.0
    • 12.5
    • 15.0
    • 15.1
    • 15.5
    • 15.7
    • 16.0

    Software Pattern Summary

    Product ComponentOS TypeVersioningPattern Depth
    Database ServerUnixCommand (Active), Path, SQL queryInstance-based or Footprint (data dependent)
    WindowsCommand (Active), Path, RegistryInstance-based
    Backup ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
    WindowsCommand (Active), Path, RegistryInstance-based
    Monitor ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
    WindowsCommand (Active), Path, RegistryInstance-based
    Monitor Historical ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
    WindowsPathInstance-based
    XP ServerUnixCommand (Active), PathInstance-based or Footprint (data dependent)
    WindowsPathInstance-based
    LinkMonitorServerToDataserverN/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

    ComponentTrigger NodeAttributeConditionArgument
    DatabaseServerDiscoveredProcesscmdmatchesregex'(?i)\bsqlsrvr\.exe$'
    or
    cmdmatchesregex'\bdataserver$'
    argsmatches

    regex '(?:^|\s)-\w\s*(?:\S+)'

     
     
    BackupServercmdmatchesregex'\bbackupserver$'
    or
    regex'(?i)\bbcksrvr\.exe$'
    MonitorServercmdmatchesregex'\bmonserver$'
    or
    regex'(?i)\bmonsrvr\.exe$'
    MonitorHistoricalServercmdmatchesregex'\bhistserver$'
    or
    regex'(?i)\bhistsrvr\.exe$'
    XPServercmdmatchesregex'\bxpserver$'
    or
    regex'(?i)\bxpserver\.exe$'
    LinkMonitorServerToDataserverSoftwareInstancetype="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.

    NameCommand
    Sybase Interactive Database clientisql, isql.exe, isqlw.exe, dbisql.exe, dbisqlc.exe or dbisqlg.exe
    Sybase Interactive Database client - SQL shellsqsh
    Sybase OpenClient/OpenServer Configurationocscfg.exe
    Sybase ASE Monitor Servermonserver or monsrvr.exe
    Sybase ASE Monitor Historical Serverhistserver or histsrvr.exe
    Sybase ASE Backup Serverbackupserver or bcksrvr.exe
    Sybase ASE Backup Server sybmultbuf processsybmultbuf
    Sybase ASE Database Serversqlsrvr.exe or dataserver
    Sybase ASE Database Server enginedataserver -ONLINE
    Sybase ASE Job Scheduler Agentjsagent or jsagent.exe
    Sybase ASE Sybase Central - Java Editionscjview or scjview.exe
    Sybase ASE XP Serverxpserver or xpserver.exe
    Sybase ASE Server Configurationsyconfig.exe
    Sybase ASE Unified Agent Serviceuaservice.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:

    SQL Query

    Database Server

    Pattern executes sql query := "select @@version";

    From the target output retrieves full version using regex :

    • (?i)Adaptive\sServer\sEnterprise/(\d+(?:\.\d+)*)

    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 occurrence 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.

    3. One more approach uses <strings "process.cmd"> command . From the command output product version is being extracted by means of regex:

    •  '^Adaptive Server Enterprise\/(\d+(?:\.\d+)*(?:\sSP\d+)?)'

    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 ing 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 expressions used are as follows:

    Path Regex: /sybase/SYB(\d{2})(\d)/

    Path Regex: (?:/[sS]ybase/(?:ase/)?|ASE-)(\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/<Server_name>/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 expressions used are as follows:

    Path Regex: /sybase/SYB(\d{2})(\d)/

    Path Regex: (?:/[sS]ybase/(?:ase/)?|ASE-)(\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/<Server_name>/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 expressions used are as follows:

    Path Regex: /sybase/SYB(\d{2})(\d)/

    Path Regex: (?:/[sS]ybase/(?:ase/)?|ASE-)(\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/<Server_name>/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 expressions used are as follows:

    Path Regex: /sybase/SYB(\d{2})(\d)/

    Path Regex: (?:/[sS]ybase/(?:ase/)?|ASE-)(\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/<Server_name>/ASE-12_5/bin/xpserver - 12.5
    • /opt/sybase/DMR/<Server_name>/ASE-12_5/bin/xpserver - 12.5
    • /export45/apps/sybase/ASE-12_0/bin/<Server_name>/export45/apps/sybase -p8 -s77824 -x - 12.0

    Monitor Historical Server

    The regular expressions used are as follows:

    /sybase/SYB(\d{2})(\d)/

    (?:/[sS]ybase/(?:ase/)?|ASE-)(\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/<Server_name>/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.

    Additional Attributes

    Instance Information

    Instance information is obtained by parsing the trigger process arguments

    ComponentArgument usedNotes
    Database Server-s argument We use the default SYBASE if we can't find it

    Backup Server

    Historical Server

    XP Server

    -S argument
    Monitor Server-M argument


    Installation Root

    The pattern tries to get the install_root from the trigger process command (e.g. /opt/Sybase/bin/dataserver means an install_root of /opt/Sybase)

    If this fails the pattern checks two parameters in the trigger process arguments:

    • -c. The path to the configuration file. -c/app/sybanz/foo/cfg/foo.cfg means an install_root of /app/sybanz/foo
    • -e. The path to the logs. -e /app/sybanz/bar/logs/bar.log means an install_root of /app/sybanz/bar

    The publisher's documentation provided background


    Bind Address

    UNIX platform only

    The DatabaseServer pattern attempts to get the bind address for a given Sybase database server. Such information is retrieved from the 'interfaces' file which is relative to the product's installation path using the following regular expression:


    • regex '\((\d+(?:\.\d+)+)\)'

    The bind address may also be set to one of the host's alternative IP addresses as mentioned in the comment header for a particular Sybase database server section within the contents of the interfaces file itself.

    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.

    Background

    The sql.ini or interfaces file is a programmatically generated block for each server. Although several formats exist, each block normally consists of one of the following formats:

    TEAPOT
     query tcp ether london-north 5008
     master tcp ether london-north 5008

    or

    ## 
    TEAPOT - dev backup 
    ##
    on london-north (192.168.100.101) port 5013

    The lines in the former method together constitute the "main server section". The lines in the latter method together constitute the "server section header"

    Parsing the Interfaces file

    The pattern searches in two overlapping sections of the interfaces file for the port information: the main server section and server section header

    The server section header

    • Starts with regular expression (?i)^\#\#\s+[\w\-]+\s+\-\-

    • Ends with regular expression ^\s*$

    The main server section

    • Starts with regular expression (?i)^\[?%srv_name%\]?(?:\s+\d+\s+\d+)?$

    • Ends with regular expression ^(?:\S+|\s*)$

    On Windows the port information is obtained by parsing the main server section with the following regular expression:


    • (?i)\bmaster=[^,]+,%hostname%,(\d+)

    On UNIX, port information is obtained by parsing the interfaces file with one of the following regular expressions (tried in this order):

    • Parse the main server section with: (?i)\bmaster tcp ether (?:%hostname%|%host_local_fqdn%)\s(\d+)

    • Parse the main server section with: \bmaster tcp ether %host_ip_addr%\s(\d+)

    • Parse the server section header with: (?i)^\#\#\s+on\s%hostname%\s\(\d+(?:\.\d+)+\)\sport\s(\d+)

    • Parse the main server section with: \bmaster tcp ether [\w\-\.]+\s(\d+)

    Application Model Produced by Software Pattern

    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.

    The Database Server key is based on instance, path to the configuration file, type and host key. The key for all other components is based on instance, type and host key

    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 'Client-Server' 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.

    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.

    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 external Subject Matter Experts.

    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 external Subject Matter Experts. 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).


    Created by: Rebecca Shalfield 19 Oct 2007
    Updated by: Alex Kashkevich 18 Apr 2014
    Reviewed by: Chris Blake 8 August 2013