HPE NonStop SQL WebDBS - Introduction

Introduction to HPE NonStop
WebDBS 1.1
Frans Jongma,
Hewlett Packard Enterprise
Advanced Technology Center
NonStop Enterprise Division
Date: February 2021

Contents
Introduction............................................................................................................................................ 3
Using ServiceNow.............................................................................................................................. 3
References......................................................................................................................................... 3
New features in release 1.1 ................................................................................................................... 3
The login page....................................................................................................................................... 5
Administrator login ............................................................................................................................. 5
Tenant login ....................................................................................................................................... 6
The Database View for an Administrator................................................................................................ 7
The Actions menu .............................................................................................................................. 8
User actions.................................................................................................................................. 10
Additional administrator views.............................................................................................................. 11
Datasource information .................................................................................................................... 11
DBS System Info.............................................................................................................................. 14
The Account menu for Administrator ................................................................................................ 15
Creating databases.............................................................................................................................. 16
The Database View for a Tenant ......................................................................................................... 19
The Actions menu ............................................................................................................................ 20
The Account menu for a Tenant ....................................................................................................... 24
Additional Tenant views....................................................................................................................... 25
Datasource Attributes....................................................................................................................... 25
Control Query Defaults..................................................................................................................... 27
Database compatibility controls........................................................................................................ 28
Common views for all users................................................................................................................. 28
Downloads View............................................................................................................................... 28
Remote mxci (rmxci) with the JDBC drivers.................................................................................. 29
ODBC Drivers............................................................................................................................... 29
Hibernate dialects and Liquibase dialects ..................................................................................... 29
NonStop SQL/MX example database ........................................................................................... 29
References View.............................................................................................................................. 29

NonStop Advanced Technology Center
Introduction to HPE NonStop WebDBS 1.1 -3-
Introduction
In this document we will introduce WebDBS, the user interface to the specific part of HPE Database
Platform Automation (DBPA) that is used to manage NonStop SQL/MX databases. HPE DBPA for HPE
NonStop SQL/MX is based on HPE NonStop SQL/MX Database Services (DBS).
SQL/MX DBS is a solution that provides a multi-tenant database environment where the databases are
isolated from each other while still sharing common resources such as compute power, storage, and
network capacity. However, while the databases share the storage, each database uses dedicated,
unshared, devices which prevents them from encountering database bottlenecks such as database
cache and lock-space. Cache and lock space are part of the NonStop SQL Data Access Managers
which are dedicated to only one database and not shared with others.
Databases can be used by anyone who has permission to use the resources. Initial permissions are
granted by a system administrator who, upon a request from an end-user, will create the environment
on behalf of this user. The end-user will then be one of the tenants of the multi-tenant SQL/MX DBS
environment that hosts multiple databases, be the owner of the database and will be able to add other
users to this database and give them permissions as needed, without further involvement of the system
administrator. In a SQL/MX DBS environment, the tenants will only access the database using the
JDBC and ODBC SQL interfaces or perform actions from the WebDBS user interface. These users do
not have access to the NonStop system using a command prompt.
Using ServiceNow
Database creation by the system administrator is fully automated when ServiceNow1
is used.
ServiceNow uses workflows that ultimately execute a job that creates a SQL/MX DBS database using a
system administrator role. In the context of ServiceNow, the system administrator is just the account
that acts as an approver in the workflow.
In this document, we describe the functions that are available in WebDBS, where the system
administrator, as well as the tenants, can perform NonStop system-related tasks, some of which are
also possible from the ServiceNow interface.
References
The SQL/MX Database Services Manual provides a good overview of the architecture of DBS, the
database in a DBS environment and database isolation. The manual is in the HPE support Center at
https://support.hpe.com/hpesc/public/docDisplay?docLocale=en_US&docId=a00090077en_us
This and other references are found in the References View of WebDBS as described in the section
REFERENCES VIEW.
New features in release 1.1
In the 1.0 release of WebDBS, system management functions, such as deployment and removal of
databases were only possible through ServiceNow (SNOW) workflows. WebDBS release 1.1 provides
1 ServiceNow (www.servicenow.com), a company that provides a cloud computing platform that helps companies
manage digital workflows.

complete administrator functionality. This allows customers to manage the database lifecycle without
requiring ServiceNow.
The software will adjust the actions allowed in WebDBS depending on the presence of ServiceNow: if
active, WebDBS will not provide actions that are managed via SNOW workflows, since these actions
would interfere with those managed by these workflows.
The features of WebdDBS are described in the subsequent sections.

The login page
A single login page is used to log into the HPE NonStop WebDBS interface by administrators as well as
tenants.
The URL of the page depends on the specific site; the format is:
https://<host>:<port>/webdbs
Since there are two types of users, Administrators and Tenants, the type of user needs to be specified
from the pull-down selection on the login page as shown in Figure 1.
Alternatively, the type of user can be included in the URL as a parameter.
https://<host>:<port>/webdbs/?admin
https://<host>:<port>/webdbs/?tenant
Figure 1: Login screen
Administrator login
Administrators are users that have a higher authorization to the system than regular tenants.
Administrators can create databases, can reset a tenant password, and have access to the system
using a NonStop system command prompt such as the bash shell or the Guardian TACL command
interpreter. Administrators also provide the first-line support for tenants, who are expected to have SQL
database knowledge, but a NonStop system background is not required.
Currently, there is only one administrator user: the user that has been assigned as the SQL/MX DBS
administrator, for example TENANT.ADMIN.

Tenant login
Tenants are the users of the databases. Tenant database owners have a higher authorization level
than other tenant users. Users with CREATE access are all considered database owners. A tenant
database owner can execute tasks for that database that otherwise would be done by a system
administrator or Database Administrator. For example, shutdown database services and restart them,
running backup and restore functions, perform user management and even dropping the database and
freeing all resources.
Once the user has successfully logged in, a list of databases and users is presented in a view that is
called the Database View. This information will be different for administrators and tenants, and the
actions that can be performed on these databases will also be different. The next sections describe the
Database view as presented to administrators and tenants.

The Database View for an Administrator
When the administrator has logged in, the Database View for the administrator is displayed. This view
shows all databases configured on the system and consists of two parts. The top part shows the
databases with summary information. This summary information shows the status of the database, if it
is started or stopped, and a summary of connection activity and storage information.
The bottom part shows detailed information of the selected database, which upon login, is the first
database in the list.
To select a database, click its name from the list of databases (or anywhere in the row) and this will
highlight the line as selected. In the example, the database DBS_TEST has been selected.
Figure 2: Administrator Database View
The radio buttons on the left side are used to select which type of details are to be displayed:
Schemas lists the schemas that have been defined for the selected database. The
INFORMATION_SCHEMA is a schema that is created automatically when the database is created. The
date and time in the Created column reflect the time that the database was created. The subvolume is
the name of a logical storage group on the storage devices and is like a subdirectory. The version
refers to the storage features that are supported in the database objects version of the schema.
Schema version is not the same but related to the database software version that is shown in the upper
half of the screen. The feature version can be lower than that of the software. It means that while the
software can support data types or certain objects, the database metadata need to be upgraded for
applications to use these features.
Users lists the users for the database along with their privileges, create, write, and so on.
Connections lists active and available connection information. Active connections show the user,
application name, address information of the client system as well as server-information such as the
assigned port, the server-side process information, (the MXCS Server) and TCPIP provider. Each

connection is represented on the server as a dedicated process, Connections that are in the Available
state refer to processes that have been pre-started and are ready to receive new connections.
Figure 3: Database connections overview
Storage provides information about the storage that has been assigned and used. There are two types
of storage: SQL/MX storage is the database storage and refers to the amount of space that was
requested by the user and how much has been used. Every volume assigned to the database appears
on a separate line. The amount of storage that is assigned to a database may be larger than was
requested. This is because storage is assigned based on logical storage volumes that are exclusively
assigned to one database.
The OSS file-system storage is used for non-database data, for example, schema backup data.
Figure 4: Storage overview
The Actions menu
The Actions menu at the right-hand top of the screen is a context-sensitive menu that lists the actions
that the administrator can perform with the selected database and the database-object selected using
the radio button. The Actions listed in Figure 5 are based on the Schemas button selected and are
database oriented, such as start and stop, create, and remove database as well as database storage
expansion.
Figure 5: Administrator action pull-down menu

Refresh refreshes the database view.
Create Database allows the administrator to deploy a new database using a data-entry screen. See
the section Creating databases.
Remove Database will remove the selected database and all its resources from the system after a
confirmation.
Figure 6: Removal of database
Add Storage presents a new screen where the administrator enters the amount of additional storage to
be added to the database configuration. Storage requirements are entered in units of one GB.
Figure 7: Requesting additional storage
Note: To ensure isolation between tenants and to minimize resource contention, NonStop SQL/MX
DBS reserves storage space based on system volumes, dedicated to only a single tenant. When a
tenant request, for example, 10 GB of storage and the system uses volumes of 100 GB each, a
database will have 100 GB assigned. In the example above, 100 GB extra would assign a second
storage volume, thus reserving 200 GB for 110 GB requested. Should the additional storage request be
less than 90 GB however, only a single volume would be needed to satisfy the requirement.
A database will be able to exceed the amount of requested storage. Only if it exceeds the assigned
storage, additional storage adding more volumes, will be required.

Start and Stop Database enable and disable access to the database by starting and stopping the
database server processes, respectively.
Start and Stop all Databases are administrator convenience actions whereby with a single action, all
databases will be started or stopped.
Note: Stopping databases need a confirmation by the administrator. Any active connections will be
disconnected, and active transactions will be aborted and backed out automatically. When databases
are started while they are already in the started state, active connections are not affected.
User actions
An administrator can remove a user or reset a password for a user. Both actions require a user ID, and
the actions appear in the Actions menu only if a user has been selected as shown in Figure 8.
Figure 8: Action menu for user context
Remove User removes the selected user from the selected database in the Database View if the user
does not own any schemas. There must be at least one user with CREATE access in every database.
A delete of the last user with this access will be rejected.
Note that removal of users from databases is a task that also a tenant database owner can perform.
Reset User Password allows the Administrator to enter a new password for a tenant. The tenant is
then again able to log in and alter the password that was created by the administrator.

Figure 9: Reset a user password
A password reset by an administrator sets a new password for the user, so they can get access to their
databases. Users that have their password reset must change this password as soon as possible.
Additional administrator views
Apart from the database view, which is probably the most important view, there are a few other views
which are described in the next sections.
Figure 10: Administrator views
Datasource information
Datasource information is the information that is used to manage database connections to a database
and includes the number of connections that are configured, the execution priority and controls (called
Control Query Defaults) that influence the runtime behavior of queries and certain DDL operations.
The name of the Datasource and the Database is the same. An administrator can select which
(database) information to view by selecting the database name from the Datasource drop-down list as
shown in Figure 11.

Figure 11: Administrator Datasource Overview
The attributes at the top of the screen show the connection information. An administrator can make
changes and these changes will take effect for new connections only.

Figure 12: Altering Datasource Attributes
The fields are largely self-explaining. Detailed information about the input fields and on-off buttons can
be found in the SQL/MX Connectivity Service Administrative Command Reference manual.
The Control Query Defaults (CQD) section displays the tenant-modifiable controls. The set of controls
that is shown below, includes parameters that are used when tables are created. The two EXT (extent)
sizes define the space that is allocated on disk when a table receives data. In the example, the first
extent of a table or a partition of a table is 100 MB and will increase by 50 MB as the table grows. Once
the partition reaches 2.5 GB, a ‘table/partition full’ error will be returned. A database owner can then
increase the number of extents from 49 to a higher number.
An administrator can manage the user-modifiable set using the appropriate buttons.
An overview of all controls is provided in the NonStop SQL/MX 3.8 User Guide (called Reference
Manual in earlier releases). Refer to the SYSTEM_DEFAULTS Table in the Metadata Tables section.
Managing the user-modifiable controls is done via a selection as shown in Figure 13. To add a new
control, select one from the drop-down list of available default controls and provide the value. To modify
or delete one, select the control from CQD list and use modify or delete.
The controls all have a system default. Adding a CQD means that the CQD is added to the set of user-
modifiable controls, to be set as defaults for every database connection. Note however, that CQDs can
be modified by an application when needed for particular purpose.
When a CQD is added, the current value will be displayed as shown in the example.

Figure 13: Managing user controls
DBS System Info
The DBS System Information can be selected from the Views pull-down menu as shown in Figure 14.
Figure 14: DBS System Info
DBS Status provides system information about the DBS environment, such as the number of
databases in use, the total number of storage volumes assigned to DBS databases and the number of
free (unassigned) volumes.

SQL/MX DBS assigns storage volumes exclusively to databases and therefore, the number of free
volumes (in the example, one volume is free) is an indication how much room is left for additional
databases, or for storage expansion of existing databases.
DBS Users shows all users that have access to databases on the server that is managed by WebDBS.
There will be an entry for every user-database combination, and therefore one user can appear multiple
times in the list. The list can be ordered by the columns to provide easier grouping.
The Account menu for Administrator
The Account menu shows the role of the user and further options for the account.
Figure 15: Account menu for Administrator
An administrator can only logout to log back in as administrator or as a tenant user. Tenant usernames
and Administrator usernames use different NonStop OS IDs, and therefore an administrator account
cannot also be a tenant account.

Creating databases
In a multi-tenant environment, there must be some authority that is responsible for managing the
systems and -if applicable- for making sure that some user control is in place. Often, tenants are
charged for their usage in some form, and therefore SQL/MX DBS delegates the provisioning or create
of the environment to a system administrator function. There are two ways how an end-user can
request and obtain a NonStop database environment.
When ServiceNow is used, an end-user will typically start the workflow by entering a service request or
ticket into the system which contains the necessary information to deploy a database. This request then
initiates a workflow that puts the request into the queue of an administrator. This administrator needs to
review the request and decides if all requirements are met and confirms the request. This will then
continue the create workflow and launch the deployment tasks that run on the NonStop server. Upon
completion, the request will appear in the requestor’s list of subscriptions along with the information the
user needs to connect to the database or to execute database-owner functions with WebDBS. For
example, the URL, to connect as a tenant to WebDBS will be displayed in ServiceNow. The
administrator in ServiceNow does not require any access to the NonStop system, as the process is fully
automated.
When WebDBS is used to run without a framework such as ServiceNow, an Administrator can initiate
the deployment of behalf of the end user. An end-user will notify the administrator in some form, this
can be by phone, app, email, or even using ticketing system that is not integrated with NonStop
SQL/MX DBS. When the administrator decides to honor the request, he or she will login to WebDBS as
administrator and select the Create Database action and enter the data that the requestor has provided
as shown in Figure 16.
! Note: Create database involves quite a bit of setup on the system and can take some time. Typically,
the operation can take about 1.5 minutes to complete.
Only a few attributers are required to setup an environment:
Database name uniquely defines a database on the system. Depending on the customer, this name
can be provided by the end-user or it can be defined by the system administrator. Database
connections require a database name as well as the IP address information of the server that hosts the
database. The database name is converted to uppercase, and when used in a connection string, must
be specified in uppercase.
Schema name defines a logical group of database objects within a database. Multiple schemas exist
within a database; the one that is entered on this screen will be used to be set as the default when
application connect to the database. If the application does not rely on any schema, enter
DEFAULT_SCHEMA. The schema name is also converted to uppercase. However, when used in
applications, it can be specified in uppercase or lowercase.

Figure 16: Create database
User Name is the name of the user that will act as the database owner. This user will be granted
CREATE access, which is required to create and maintain database objects. This user, along with the
password that is entered are used to connect to the database and perform WebDBS tenant functions.
Usernames can be in the form of email IDs (user@organization.com) or Windows IDs (HOST.USER)
or simple names as shown. Usernames that are or can be used as NonStop OS usernames will be
rejected as “not allowed as External Username2
”.
New Password needs to adhere to the Safeguard standards, such as password quality, that are
defined for the NonStop server. Note: In case a user has already access to another database as owner
or as a regular user, a password must be entered to pass validation, however, the existing password
will not be altered. The password must be re-entered to make sure it was entered correctly.
Optional parameters are:
Initial Number of Servers the number of server processes to handle connections that are started
when the database is started. Each connection is represented by a dedicated server process.
Maximum Number of Servers the maximum number of connections allowed for this database. As
more clients connect to the database, new processes are started to satisfy the needs. When
connections are closed, idle server processes may remain in the available state until it reaches its
defined time with idle timeout.
2 SQL/MX DBS uses user IDs that cannot be used to access the NonStop system. They are called “External User
IDs”. When a user connects, the ID is translated into a NonStop OS Username, which is managed by the
Safeguard software. To prevent conflicts, NonStop User IDs cannot be used as external user IDs. The use of a
name that is used as a Safeguard alias for a NonStop OS user is possible, however unlike the alias, it is
considered a different user.

Idle Servers are waiting to accept new connections. This allows a quick connect response to new
connections. After a period of high activity, servers will stop after their idle timeout has expired until the
number of idle servers is reached.
Idle Timeout is the time a server waits for new connections before it stops.
Connect timeout is the time that an application can keep a connection open without sending data. This
means that after a time of non-activity the connection will be closed automatically.
The buttons Create Metadata Views and Log User Sessions are useful for users and administrators.
Metadata views allow SQL queries to be executed on SQL/MX metadata which is highly normalized
and therefore, queries can become quite complex.
User Sessions logging includes records for start and end sessions to be logged in the system (EMS)
log file.

The Database View for a Tenant
When a tenant has logged in, the Database View for this user is displayed. The view is like that of an
administrator, however, only the databases that the tenant has access to will be displayed.
The database view consists of two parts. The top part shows the databases that the current user has
access to along with the access rights. The bottom part shows more detailed information of the
selected database, which by default, is the first database in the list.
To select a database, click its name from the list of databases (or anywhere in the row) and this will
highlight line as selected. In the example, the database DBS_TEST has been selected.
Figure 17: Tenant Database View
The top part of the screen includes status information, such as the number of connections, storage
information, the IP address for database connections and the default database schema when
applications connect to the database. The bottom part shows detailed information of the selected
database, which by default, is the first database in the list.
The radio buttons on the left side are used to select which type of details are to be displayed:
Schemas lists the schemas that have been defined for the selected database. The
INFORMATION_SCHEMA is created automatically when the database is created. The creation time of
this schema is therefore also the creation time of the database.
Users lists the users for the database along with their privileges, create, write, and so on.
Connections lists active and available connection information. Active connections show the user,
application name, address information of the client system as well as server-information such as the
assigned port, the server-side process information, (the MXCS Server) and TCP/IP provider. Each
connection is represented on the server as a dedicated process. Connections that are in the Available
state refer to processes that have been pre-started and are ready to receive new connections.

Figure 18: Tenant database connections
Storage provides information about the storage that has been assigned and used.
Figure 19: Tenant database storage overview
The data about the SQL/MX file system includes the storage that is used by database data such as
tables, indexes, other SQL objects and metadata. If a database spans more than one volume, there will
be a line for every database volume. The path name for SQL/MX filesystem refers to the storage
volume, the logical disk as seen by the OS, including the $ sign. The amount of storage that is assigned
to a database may be larger than was requested. This is because storage is assigned based on logical
storage volumes that are exclusively assigned to one database.
Every database will also use some regular filesystem storage, for example, schema backups, which is
presented as OSS in the overview.
The Actions menu
The Actions menu at the right-hand top of the screen is a context-sensitive menu that lists the actions
that the tenant user can perform with the current selection of database and the database-object
selected by the radio button. For example, to remove a user’s access to a database, a database and a
user must be selected in the Database View.

Figure 20: Tenant Database Action menu
Refresh refreshes the database view.
Remove Database allows the database owner to remove the selected database. Removal of a
database includes the following:
- All database connections are stopped immediately
- The database server processes terminate, and the configuration will be removed
- The database users are removed
- The database data as well as backups are removed
- The database storage is returned to the storage pool
Note: Database removal is not reversible, and before the removal starts, the user needs to confirm this
action.
Start and Stop Database enable and disable access to the database by starting and stopping the
database server processes, respectively. Before taking a dedicated database disk backup the database
must be stopped to prevent any application from keeping files open. Regular backups for database
recovery purposes are executed automatically and allow full database access.
Note: Stopping databases need a confirmation by the user. Any active connections will be
disconnected, and active transactions will be aborted and backed out automatically. When databases
are started while they are already in the started state, active connections are not affected.
Create Schema allows a user to create an empty schema in the selected database along with
metadata views set up for that schema. The metadata views provide easy SQL access to the SQL/MX
metadata of the schema objects.
Backup Schema creates a disk backup of all the objects in the currently selected schema. A backup
will be incomplete if some objects are not backed up, for example because an application has still
tables or indexes open. The backup process will skip such objects. To avoid this, the database services
must be stopped first using the Stop Database action.

Figure 21: Backup action of selected schema
A backup of all the objects in the database schema will be executed as a background job. For this
reason, a popup window will appear explaining that a backup can take a relatively long time as shown
in Figure 22. When the Close button is pressed, the GUI can be used to perform other tasks. When the
backup is completed, a popup notification will be displayed as is shown in Figure 23.
Figure 22: Long-running jobs are executed in the background
Figure 23: Upon completion user is notified
! Note: in the current version of the software only a single copy of a schema backup can exist. Running
a backup action will overwrite a previous backup file on the system.
Note: Only one backup or restore schema operation per login session can be running in the
background at a time. You will get an error if you attempt to back up a schema while another
schema is being backed up in the same login session.

Restore Schema will restore the schema that is selected from its backup. If there is no backup present,
the restore fails.
! Note: The restore starts with dropping all objects in the schema. The schema objects, tables, indexes,
but also views and constraints from the backup will then be restored into an empty schema.
! Note: Due to the restore of a backup, the database statistics will be reset. For optimal SQL execution
plans, new database statistics need to be generated using the UPDATE STATISTICS SQL command.
Figure 24: Enter the name of the schema to be restored
Note: Only one backup or restore schema operation per login session can be running in the
background at a time. You will get an error if you attempt to restore a schema while another
schema is being restored in the same login session.
Figure 25: Successful restore of schema
Add User adds a new user to the selected database. A new popup window will be displayed. The
required information includes the name and password of the user and the access level for the
database. The user can already exist as a user for another SQL/MX database. If so, the password that
exists for this user will not be changed as part of this action. The password details on this window are
ignored.
Note: Due to the isolation of databases and their users, a database owner may not know if the new
user already is known to the system and has a valid password. If users already exist for another
database, they can use the password they already know. If not, they must use the password
that was created by the database owner when they log in the first time.

Figure 26: Adding a new user to a database
The database access types are one of the following.
CREATE - allows creation as well as removal of database objects such as database tables and
indexes. In the current release of WebDBS, a user with CREATE access will be able to perform
database operation tasks such as adding new users.
WRITE - allows the user to read and modify data in the database. This privilege is valid for all current
and future tables in the database.
READ – allows only read access to the database to current and future tables.
NONE – allows none of the above access to all tables. These users need access granted per table
using the ANSI GRANT/REVOKE SQL syntax executed from a SQL database access tool.
Note that users with CREATE access are treated as database owners. CREATE privilege includes
WRITE and READ privileges. WRITE privilege includes READ.
The Account menu for a Tenant
The account pull-down menu shows the current user and the role: tenant or administrator. Some
functions are specific to tenants, and some are specific to administrators.
Figure 27: The Account menu
Tenants have the option to change their password from the account menu.

Figure 28: Change tenant password
To change the tenant password, both the old password and the new one must be entered.
In case the tenant does not know the password, a system administrator can reset the password by
setting a new password which the tenant is able to change after a successful login. To switch role from
a tenant to a system administrator requires a logout and a new login.
Additional Tenant views
The tenant database owner can change the database operating environment using the Datasources
view. This view contains much of what an administrator sees and can modify a subset of what an
administrator can change. In case a tenant needs changes made that cannot (yet) be made by a
tenant, the system administrator can make this change on behalf of the tenant. As a rule, a tenant will
not be able to make changes that can have a negative impact on other tenants, such as altering the
execution priority and the maximum number of connections that can be made to a database.
Datasource information is the information that is used to manage database connections to a database
and includes the number of connections that are configured, the execution priority and controls (called
Control Query Defaults) that influence the runtime behavior of queries and certain DDL operations.
The name of the Datasource and the Database is the same. An administrator can select which
(database) information to view by selecting the database name from the Datasource drop-down list as
shown in Figure 30.
Datasource Attributes
The attributes at the top of the screen show the connection information. A tenant or an administrator
can make changes, however, a tenant cannot change the priority or maximum number of servers that
can access the database. These changes must be made by an administrator.

Figure 29: Tenant altering Datasource Attributes
Every database connection is managed by a server process on the database server. The connection
processes do not have to be always active. They will be started as needed; the “number of servers”
attributes control how this is done.
Initial number of servers will be started when the database is activated. The system will start
additional processes as needed until maximum number of servers is reached. After a connection
closes, the process will wait until idle timeout has passed. Also, when no activity occurs on a
connection, the server process will close the connection after the connect timeout has passed.
The number of idle servers will remain active to be able to quickly serve new connection requests.

Figure 30: Tenant Datasource overview
Control Query Defaults
This section includes controls that are in effect when a connection is established. They can affect DDL
operations; for example, the set of controls that is shown, includes parameters that are used when
tables are created. The two EXT (extent) sizes define the space that is allocated on disk when a table
receives data. In the example, the first extent of a table or a partition of a table is 100 MB and will
increase by 50 MB as the table grows. Once the partition reaches 2.5 GB, a ‘table/partition full’ error will
be returned. A database owner can then increase the number of extents from 49 to a higher number.

Database compatibility controls
The DC controls (DC_MODE, DC_DATE and DC_SELECT_FOR_UPDATE) are used for database
compatibility mode.
When DC_DATE is set to ‘1’, the datatype DATE includes the time as is the case in Oracle databases,
even though the contents will be displayed year-month-day. When DC_DATE is set to 0, the SQL/MX
default and the ANSI default, the field contains only the date part.
DC_SELECT_FOR_UPDATE influences how locks are placed when rows are selected for update
within a transaction. Normally, this statement is used to declare a cursor that can be updated in an
embedded SQL program. However, other DBMS use this statement to lock rows for update later in the
transaction. With this mode set to ‘1’, SQL/MX places an exclusive lock on the rows that match the
WHERE clause but releases any locks for rows that do not match. This improves concurrency
compared to the standard ANSI SQL method, where the statement needs to be executed in
EXCLUSIVE MODE and places exclusive locks on all rows for the duration of the transaction.
DC_MODE is one CQD that can be used to set all compatibility controls for an application instead of
setting them individually.
Other values may appear in the list, such as timeout (for lock waits) and the list of volumes that are
assigned to this database. An administrator can add more user-modifiable controls to the list, but a
tenant can only modify the values from the list. To modify a CQD, select it first and press MODIFY. The
new value can be entered in a popup window.
!Note: Modifications take effect for new connections.
Common views for all users
There are two views that show the similar information for Administrators and Tenants.
Downloads View
The downloads view contains the information about downloadable files such as ODBC and JDBC
drivers that are required to connect to the NonStop SQL/MX database. The contents of the page may
vary from installation to installation because its contents can be managed by the system administrators.
The ODBC and JDBC drivers will be available for download in any case.

Figure 31: Example download page
The contents of the download page are customizable by the system manager. The file names listed on
this page are the names of the files as they appear in the downloads directory
/usr/tandem/sqlmx/dbs/webdbs/dbs_manage/downloads. Figure 31 shows an example that
contains drivers and the rmxci command example, but also a copy of this document.
Remote mxci (rmxci) with the JDBC drivers
Rmxci is a command interpreter written in Java3
and uses the JDBC Type-4 driver. The download page
includes two archives, t4sqlmx.jar and rmxci.jar that are required to run rmxci. An example command
script for Windows, called rmxci.cmd.sh, is also provided. Before executing the script on the
workstation, the .sh suffix, must be removed from the file name.
ODBC Drivers
ODBC drivers for Windows, Linux and HPUX are provided. These drivers are provided as install files.
Depending on the target OS, they are downloaded as executable files or tar files.
Hibernate dialects and Liquibase dialects
Hibernate and Liquibase are common development tools and HPE provides dialects for use with
SQL/MX. If necessary, the system administrator can include these dialects on the download page.
NonStop SQL/MX example database
A simple HR database definition including data is available.
References View
The References View is a place holder for reference materials and is also customizable by a system
administrator. The contents of this page are managed using a simple JSON configuration file. Its
contents will be presented as depicted in Figure 32. The JSON configuration file is called
references.json and is in /usr/tandem/sqlmx/dbs/webdbs/dbs_manage/references.
3 Java is a registered trademark of Oracle and/or its affiliates.

Figure 32: References View

HPE NonStop SQL WebDBS - Introduction

More Related Content

What's hot (20)

Similar to HPE NonStop SQL WebDBS - Introduction (20)

More from Frans Jongma (11)

Recently uploaded (20)

HPE NonStop SQL WebDBS - Introduction