Copyright Information

StarAdmin
StarQuest Ventures, Inc.

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of StarQuest Ventures, Inc.

StarQuest products contain certain trade secrets and confidential and proprietary information of StarQuest Ventures, Inc. StarQuest may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from StarQuest, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Additionally, any public network IDs or addresses referenced in this document are for demonstration/example purposes only. The inclusion of such IDs and addresses in this document does not grant you any express or implied right to test or otherwise use or access any such network ID or address.

StarQuest and StarSQL are trademarks of StarQuest Ventures, Inc.

Microsoft, Windows, Windows XP, and Windows Vista are registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

StarQuest Ventures logo

©Copyright 1994-2007. StarQuest Ventures, Inc. All rights reserved.
October 2007 edition


Welcome to StarAdmin

The StarSQL ODBC driver includes a utility called StarAdmin that allows you to manage and administer three key functions:

  • Binding Packages

  • Creating Catalog Views

  • Granting and Revoking Privileges

Each of these functions has a corresponding tab in the StarAdmin window.

main StarAdmin window prior to connecting to host system

Before you can execute any of the StarAdmin functions you must connect to a database that uses the StarSQL driver. The topic Connecting to a Database provides details about establishing a connection to the desired database.


Connecting to a Database

You must connect to a database before you can execute any of the StarAdmin functions. Perform the following steps to connect to a database.

  1. Select the Open Database Connection command from the File menu, or click on the Connect Database toolbar button button of the toolbar.

  2. In the Select Data Source dialog, select the system data source that connects to the desired database.

  3. In the Connect dialog, enter a valid user ID and password for connecting to the selected database and click the Connect button.

After you connect to a database StarAdmin displays the packages found on that host, and shows the name of the package collection above the list of packages. The bottom of the StarAdmin window shows the database name and the authenticated user ID logged in to the database. If you connect to an OS/400 host, a Custom Indexes group box appears in addition to the Custom Packages group box with an option for binding the default catalog package.

Click the Refresh Packages List toolbar button button on the toolbar to refresh the list of packages.

StarAdmin connected to an OS/400 host

When you are finished working with the database packages, click the Close Database Connection toolbar button button on the toolbar or select Close Database Connection from the File menu.


Binding Package Topics

Binding Packages

StarAdmin automatically binds StarSQL ODBC driver packages on the host database and provides the option of granting EXECUTE or USE authority on the packages created. Users must be able to execute these packages to take advantage of the StarSQL ODBC driver.

For more detail on the Bind Packages function in StarAdmin, click on the links below.

  • StarSQL SQL Packages

  • When to Bind Packages

  • DB2 Authority Requirements for StarAdmin

  • Binding All Packages

  • Bind Default Catalog Package Option

  • Creating and Dropping Indexes

  • Bind DynamicRules Packages Option

  • Names of Packages Created by StarAdmin

  • Deleting a Package


StarSQL SQL Packages

A SQL package is an object that StarSQL uses to store internal control structures as a compiled form of SQL. You must have a SQL package on the host to use dynamic or static SQL on a DRDA connection. StarSQL assumes that required SQL packages already exist on the server. If the package that StarSQL needs is not on the server, StarSQL automatically binds the package dynamically.

StarSQL binds two types of packages:

  • catalog packages
    Catalog packages contain catalog information and are discussed further in the topic Creating Catalog Views. You can create one or more catalog packages in the database.

  • dynamic SQL packages
    Dynamic SQL packages correspond to the cursor options settings (Use Held Cursors and Default ODBC Isolation Level) that are configured for the data source. Depending upon the host database, StarSQL can create up to sixteen dynamic SQL packages on the host. You also can configure the StarSQL data source to bind jumbo packages (UseJumboPackages setting), in which case it allocates up to 1314 statement handles for the dynamic SQL package. See the StarSQL Help for additional information about configuring the cursor and package options.


Binding Packages

It is most efficient to run StarAdmin immediately after installing StarSQL so that packages and proper authorizations are in place before users attempt to connect to the host with an ODBC-enabled application.

Significant changes were made to catalog packages and dynamic SQL packages with the v5.1 release of StarSQL. Unpredictable results may occur if you use StarSQL v5.10 or later with packages created by earlier versions of StarSQL. Rebind packages for use with the StarSQL v5.3 driver.

Packages that are rebound using the new version of StarSQL can be shared with clients that are running previous versions of StarSQL, except if you use any functions related to stored procedures for DB2 UDB for Windows and UNIX or if you need to work with LOB data types (BLOB or CLOB). Users also may get different results from ODBC catalog functions when using a version of StarSQL prior to v5.1 with packages bound with v5.3. In these cases, upgrade all clients to the new StarSQL version, or use different package collections if you must maintain clients that are running previous versions of StarSQL.

Users must make sure that the Catalog Schema and Package Collection named in their data source match those specified when the packages are bound using StarAdmin. If the host is using a mixed-byte character set and you need to enable the CustomizePrdid setting of the StarSQL data source, the CustomizePrdid setting must be enabled when you bind packages and in the DSN that is used to connect to the host from the StarSQL client.

For most ODBC-enabled applications, StarSQL automatically creates packages as they are needed. If you experience a problem with automatic package binding when using an ODBC-enabled application, use StarAdmin to bind the packages.

Following are examples of situations in which you may need to use StarAdmin to rebind SQL packages:

  • To take advantage of StarSQL for Windows support for LOB data types.

  • To use jumbo packages (see UseJumboPackages parameter of the StarSQL help). If you initially bind packages with the UseJumboPackages option of the StarSQL data source set to No (the default) and later find that you need more statement handles per connection, rebind the packages with the UseJumboPackages option of the StarSQL data source enabled.

  • To access DB2 for z/OS when the host is configured to use a multi-byte character set and you need to enable the CustomizePrdid parameter of the StarSQL data source.


DB2 Authority Required for StarAdmin

For StarAdmin to successfully bind SQL packages, the StarAdmin user must have BINDADD authority to create packages on the host database. For StarAdmin to successfully grant EXECUTE or USE authority, the StarAdmin user must have GRANT authority on the database.

Important Note

If the host is SQL/DS and you intend to GRANT authority for StarSQL driver packages to other users, you must use SQLDBA as the Package Collection. Using any value other than SQLDBA for the Package Collection will restrict the ability to GRANT EXECUTE to other AUTHIDs.

Additional privileges, which vary according to the host type, are required to delete a package. Refer to the DB2 documentation for your host system for more information about the specific authority privileges that are required.


Bind All Packages Command

During the initial connection to the database, StarAdmin creates one package if it does not already exist on the host. If the package already exists, StarAdmin verifies that the UserID is authorized to use the package. StarAdmin does not overwrite existing packages on the initial connection.

After a StarAdmin user successfully connects to a database, StarAdmin displays a list of all SQL packages that are stored in the specified Package Collection for the data source. The default package collection is STARSQL.

Click the Refresh Packages List toolbar button button on the toolbar to refresh the list of packages.

When you bind the packages, StarAdmin checks for existing packages and deletes them before it attempts to create new packages. There are several ways that you can execute the bind packages function:

  • Click the Bind Packages toolbar button button on the toolbar.

  • Click the Bind All button on Bind Packages tab button on the Bind Packages tab of the StarAdmin window.

  • Select the Bind All Packages command from the Command menu.

If any delete or bind operations fail, StarAdmin displays an error message and aborts the procedure. If all packages are bound successfully, StarAdmin asks if you want to grant EXECUTE or USE authority to PUBLIC.


Bind Default Catalog Option

Bind Default Catalog Package Option

The catalog package that the StarSQL driver uses depends on the value of the Catalog Schema setting for the StarSQL data source (DSN). For each host system, there is a corresponding default catalog package which matches the system catalog name. If the proper Catalog Schema name is set in the DSN, StarSQL creates the necessary catalog packages automatically. If you enable the Bind Default Catalog Package on the Bind pane of StarAdmin and bind packages, StarAdmin binds the default catalog package specified by the host system regardless of the value of the Catalog Schema setting in the DSN.

The following pane of the StarSQL Data Source Wizard shows where you set the Catalog Schema in the DSN.

Catalog Schema setting of StarSQL DSN

The following table describes the default catalog package that corresponds to the Catalog Schema for different host systems.

Host | Catalog Schema | Default Catalog Package
DB2 for OS/390 and z/OS | SYSIBM | SYSIBM
DB2 UDB for iSeries (DB2/400) with OS/400 v3r2 and later | QSYS2 | QSYS2
DB2 UDB v6.x and later for UNIX and Windows | SYSCAT (or the Bind Default Catalog Package option is enabled) | SYSCAT
DB2 for VM and VSE (SQL/DS) v3.3 and later | SYSTEM or SYSTEM.AUTHID | SYSTEM


Creating and Dropping Indexes

Creating and Dropping Catalog Indexes

If you connect to an OS/400 host system, an additional Custom Indexes grouping appears on the Bind Packages tab of StarAdmin, with a Create Catalog Indexes option and a Drop Indexes button.

Creating catalog indexes may provide a performance advantage for some applications that execute static SQL statements in the catalog package. Advanced applications, such as SQDR Plus, that obtain the system table schema already leverage the logical views of the system catalog tables and are unlikely to benefit by creating custom catalog indexes.

If you enable the Create Catalog Indexes option and click the Bind All button, StarAdmin indexes the system tables of the catalog schema that is defined in the StarSQL DSN (see Bind Default Catalog Option for an example of where the catalog schema is defined). The indexes are created in the QSYS library with a name of SQCATIXn, where n is a number from 1 through 7.

Clicking the Drop Indexes button deletes the custom catalog indexes. After you click the button you can use a program such as the IBM Navigator to confirm that the SQCATIXn file(s) were deleted from the QSYS library.

Note that creating or deleting catalog indexes is a global operation. Deleting the StarSQL index files that were created for the host system tables will affect any StarSQL DSN that is using them.


Bind DynamicRules Package Option

If you enable the Bind DynamicRules Package option, StarAdmin binds the packages required to support the DYNAMICRULES option. The DYNAMICRULES option is available only on DB2 for OS/390 hosts.

If the DYNAMICRULES option is set to BIND in the data source, the user executes the dynamic SQL in the ODBC application with the permissions of the package owner instead of the their own user permissions. However, when this option is set, users cannot execute the following SQL statements, regardless of the permissions set for the package owner:

  • SET CURRENT SQLID

  • GRANT

  • REVOKE

  • ALTER

  • CREATE

  • DROP

  • Any SQL statement that cannot be prepared as a dynamic SQL statement.

When you enable the Bind DynamicRules Package option, a dialog appears to confirm that you want to bind these packages to support DYNAMICRULES.


Names of Packages Created by StarSQL

Catalog packages can have pre-determined names (e.g., SWCATPKG, SYSIBM, QSYS2) as discussed in Bind Default Catalog Package Option, or arbitrary names the StarAdmin user gives to a catalog view (e.g., MYVIEW) as discussed in the topics listed in Creating Catalog Views.

Dynamic SQL packages have predetermined names. The names of these packages depends on how the Default ODBC Isolation Level and the Use Held Cursors options for the data source are set. Note that there is no Held Cursors option for SQL/DS.

The following tables list the names of the dynamic SQL packages that are created based on the isolation level and cursors settings for data sources to the various host environments.

DB2 for OS/390 Catalog Package Names

Catolog Schema | Catalog Package Name
SYSIBM or SYSIBM.AUTHID | SYSIBM

For a catalog view, the package name is user-specified.

DB2 for OS/390 Dynamic SQL Package Names

Isolation Level | Held Cursors=No | Held Cursors=Yes
Read Committed | SWRC0000 | SWRC1000
Repeatable Read | SWRR0000 | SWRR1000
Read Uncommitted | SWRU0000 | SWRU1000
Serializable | SWTS0000 | SWTS1000

DB2 for OS/390 v5 and above
Dynamic SQL with DYNAMICRULES=BIND
Package Names

Isolation Level | Held Cursors=No | Held Cursors=Yes
Read Committed | SWRC2000 | SWRC3000
Repeatable Read | SWRR2000 | SWRR3000
Read Uncommitted | SWRU2000 | SWRU3000
Serializable | SWTS2000 | SWTS3000

DB2 for OS/390 v5 and above
Dynamic SQL with KEEPDYNAMIC=Yes
Package Names

Isolation Level | Held Cursors=No | Held Cursors=Yes
Read Committed | SWRC4000 | SWRC5000
Repeatable Read | SWRR4000 | SWRR5000
Read Uncommitted | SWRU4000 | SWRU5000
Serializable | SWTS4000 | SWTS5000

DB2 for OS/390 v5 and above
Dynamic SQL with DYNAMICRULES=BIND and KEEPDYNAMIC=Yes
Package Names

Isolation Level | Held Cursors=No | Held Cursors=Yes
Read Committed | SWRC6000 | SWRC7000
Repeatable Read | SWRR6000 | SWRR7000
Read Uncommitted | SWRU6000 | SWRU7000
Serializable | SWTS6000 | SWTS7000

SQL/DS Catalog Package Names

Catolog Schema | Catalog Package Name
SYSTEM or SYSTEM.AUTHID | SYSTEM

For a catalog view, the package name is user-specified.

SQL/DS Dynamic SQL Package Names

SQL/DS hosts provide no Use Held Cursors option, so the package name varies only according to the isolation level.

Isolation Level | Package Name
Read Committed | SWRC0000
Repeatable Read | SWRR0000
Read Uncommitted | SWRU0000
Serializable | SWTS0000

DB2/400 Catalog Package Names

Catolog Schema | Catalog Package Name
QSYS2 or QSYS2.LIBRARY | QSYS2

For a catalog view, the package name is user-specified.

DB2/400 Dynamic SQL Package Names

Isolation Level | Held Cursors=Off | Held Cursors=On
None | SWNC0000 | SQNC1000
Read Committed | SWRC0000 | SWRC1000
Repeatable Read | SWRR0000 | SWRR1000
Read Uncommitted | SWRU0000 | SWRU1000
Serializable | SWTS0000 | SWTS1000

DB2 Universal Database Catalog Package Name

For DB2 UDB for Linux, UNIX, and Windows, StarAdmin creates the catalog package SYSCAT if the Bind Default Catalog Package check box is selected. For a catalog view, the package name is user-specified.

DB2 Universal Database Dynamic SQL Package Names

Isolation Level | Held Cursors=Off | Held Cursors=On
Read Committed | SWRC0000 | SWRC1000
Repeatable Read | SWRR0000 | SWRR1000
Read Uncommitted | SWRU0000 | SWRU1000
Serializable | SWTS0000 | SWTS1000


Deleting a Package

If you have performed an upgrade of the StarSQL or DB2 software, you may need to explicitly drop and re-create packages. Typically it is better practice to drop the packages directly on the host and then run StarAdmin to create and bind new packages, as StarAdmin has a package in use when it is connected to DB2 (the particular package that is in use depends on how the data source is configured).

Dropping a package requires special privileges, which vary according to the host type. Refer to the DB2 documentation for your host system for more information about the specific authority privileges that are required.

Perform the following steps to delete one or more packages using StarAdmin.

  1. Connect to the desired database if you are not already connected to it.

  2. Click the Bind Packages tab of the StarAdmin window.

  3. Highlight the package(s) you want to delete. You can use the Shift-Click selection technique to select consecutive packages or the Shift-Control technique to select non-consecutive entries.

  4. Click the Delete Selected button.


Catalog Views Topics

Creating Catalog Views

StarAdmin creates restricted views of the system catalog. This function is used to create a subset of system catalog tables to reduce the number of tables that are returned to applications. With StarAdmin, an administrator can create views based on OWNERs (or Library Names for DB2/400) and/or individual tables.

For MVS environments, the Include Current SQLID option lets you create restricted views based on the CURRENT SQLID. When users access a restricted view, only the tables that the SYSIBM.SYSTABAUTH table authorizes for the particular SQLID and for PUBLIC will be returned to the application.

For more detail on the Creating Catalog Views function in StarAdmin, click on the links below.

  • When to Create Catalog Views

  • StarAdmin Catalog Views

  • How to Create a Catalog View

  • Using a Catalog View with StarSQL


When to Create Catalog Views

Creating Catalog Views

By creating catalog views you can limit the tables that are returned to end-user applications that use ODBC catalog functions. Many applications, such as Microsoft Access and Microsoft Query, use these ODBC functions to return table information.

An administrator can control which tables are visible to end users by creating a Catalog View that includes a subset of the tables. The administrator can control who uses the catalog through package authorization, as described in the topic Granting and Revoking Host Privileges.

Some applications display an error or truncate the list of tables returned to the application if there are many tables in the database. Create one or more catalog views to limit the number of tables returned to applications.


StarAdmin Catalog Views

The following paragraphs describe catalog view settings and operations in various host environments.

To restrict the libraries that are searched for catalog functions, enter the number in the Catalog Filters option of the StarSQL Data Source Setup Wizard. The maximum value is 10.

DB2 for OS/390

When an application retrieves catalog information and the Catalog Schema is set to SYSIBM, StarSQL returns a list of all tables in the database. It is recommended that SYSIBM be used as the Catalog Schema for all users.

Use catalog views to create a subset of the SYSIBM tables based on OWNER, individual tables, or CURRENT SQLID.

SQL/DS

When an application retrieves catalog information and the Catalog Schema is set to SYSTEM, StarSQL returns a list of all tables in the database. It is recommended that SYSTEM or SYSTEM.AUTHID be used as the Catalog Schema for all users.

Use catalog views to create a subset of the SYSTEM tables based on OWNER and/or individual tables.

DB2/400

When an application retrieves catalog information and the Catalog Schema is set to QSYS2, StarSQL returns a list of all tables in the database. It is recommended that QSYS2 or QSYS2.LIBRARY be used as the Catalog Schema for all users.

Use catalog views to create a subset of the QSYS2 tables based on one or more LIBRARIES and/or individual tables.

DB2 Universal Database

Use catalog views to create a subset of the SYSCAT tables based on OWNER and/or individual tables. It is recommended that <DEFAULT> or SYSCAT be used as the Catalog Schema for all users.


Creating a Catalog View

To create a catalog view with StarAdmin, follow the steps below.

  1. If you have not already done so, start StarAdmin and connect to the desired database.

  2. Click the Catalog Views tab of the StarAdmin window.

  3. If you want all the tables of a given OWNER (or LIBRARY, for DB2/400) to be included in the view you are creating, click the Owners radio button, double-click the database name in the Database/Owners list, highlight the OWNER or LIBRARY in the Owners/Tables list, and click the Add button. The OWNER or LIBRARY name should now be displayed in the Selected Owners/Tables list.

    If you want to include an individual table in the view you are creating, click the Owners radio button, double-click the OWNER name (or LIBRARY name, for DB2/400) in the Database/Owners list, highlight the table name in the Owners/Tables list, and click the Add button. The table name should now be displayed in the Selected Owners/Tables list.

  4. For DB2 for OS/390 hosts, if you want to create a catalog that will be dynamically updated when the user logs on, click the Include Current SQLID check box. With this option, each individual AUTHID will see only the tables that it (or PUBLIC) is authorized to via the SYSIBM.SYSTABAUTH table.

  5. Click the Create View button or select the Create View command from the Command menu to display the View Name dialog box.

  6. Enter a view name and click OK to display the View SQL dialog box. If you would like to modify the SQL statement that will be used to create the view, you can do so in this dialog.

    SQL statement for creating a view

  7. Click the Create button to create the view.


Using Catalog Views with StarSQL

Use the name of the catalog view that you have created as the Catalog Schema in the StarSQL data source (see Bind Default Catalog Option for an illustration of where the Catalog Schema is set). Use the library or location on the host where you bound the Catalog Package as the Package Collection in the StarSQL data source.


Grant and Revoke Priv Topics

Granting and Revoking Privileges

You can use StarAdmin to grant or revoke the following privileges for one or more AUTHIDs:

  • EXECUTE or USE privileges on packages

  • SELECT privileges for restricted views.

The topics When to Use Grant_Revoke Privileges and How to Use Grant_Revoke Privileges provide more detail about the Grant and Revoke Privileges function in StarAdmin.


Granting and Revoking Privileges

You can use the StarAdmin Grant/Revoke functionality to make the following changes to host privileges:

  • Grant or revoke EXECUTE or USE authority on StarSQL packages to one or more AUTHIDs. You must grant EXECUTE on StarSQL packages to users who want to use the StarSQL driver.

  • Grant SELECT privileges on one or more catalog views to one or more AUTHIDs. You must grant SELECT privileges on catalog views to users who want to use those catalog views.


Assigning Grant and Revoke Privileges

Perform the following steps to grant or revoke privileges to StarSQL packages or views.

  1. If you have not already done so, start StarAdmin and connect to the desired database.

  2. Click the Grant/Revoke tab of the StarAdmin window.

  3. In the Packages/Catalog Views list, select one or more packages or catalog views for which you want change privileges.

    Each package is listed with an envelope icon Package icon, and each catalog view is listed with an icon depicting a database table and a camera View icon.

  4. Click the Add button to display your selected items in the Selected Packages/Catalog Views list.

  5. Click the GRANT radio button if you want to grant privileges, or the REVOKE radio button if you want to revoke privileges.

    Grant/Revoke radio buttons

  6. Inspect the Grant To or Revoke From frame in the upper left area of the StarAdmin Grant/Revoke display. If the list box on the right side of the frame does not contain the AUTHIDs for which you want to grant or revoke privileges, enter each AUTHID in the data entry field on the left side of the Grant To or Revoke From frame, and click the Add button. The AUTHID should appear in the list to the right. Repeat for each AUTHID you want to affect. If no restrictions are required, you can enter PUBLIC rather than individual AUTHIDs.

    adding an AuthID

  7. If the Grant To or Revoke From list contains an AUTHID for which you do not want to grant or revoke privileges, click that AUTHID in the list. The Add button within the Grant To/Revoke From box changes to a Remove button, which you can click to delete the selected AUTHIDs from the list.

    removing an AuthID

  8. Click the Execute button when you are ready to grant or revoke the specified privileges. Click Yes to confirm that you want to perform the grant or revoke operation for the selected AUTHIDs.


Contacting StarQuest

Please use the following methods to contact StarQuest Ventures if you need to obtain a license key, or have suggestions or need information about StarQuest products.

Support

If you do not want to use the online licensing feature of the License Configuration utility, you can obtain a license key for your product by sending an email to contact@starquest.com with the following information:

  • TCP/IP address or Host ID of the computer on which the license will be installed

  • Number of connections purchased

  • Company Name

  • Contact Name

  • Phone Number

  • Email Address

StarQuest Support will send a reply email that provides the license key for your organization's use of the product. Since the license is unique to the computer on which it will be installed, you must contact StarQuest should you need to move the license from one computer to another.

Additional technical support may be available subject to the prices, terms, and conditions specified in your organization's maintenance contract with StarQuest Ventures, Inc.

Sales and Service

If you have ideas for product enhancements or need more information about how StarQuest products can provide solutions for connecting Windows and UNIX applications to IBM host resources, please contact us via any of the following methods.

Address | StarQuest Ventures, Inc. P.O. Box 1076 Point Reyes Station, CA 94956
Telephone | 415-669-9619
Fax | 415-669-9629
Email | contact@starquest.com
World Wide Web | www.starquest.com


Obtaining Licensing Information

The license key for using StarQuest products is based on which product you are licensing, the number of connections you need, and the particular computer on which the license will be installed. The easiest method for obtaining a license key is to use the online licensing feature of the License Configuration utility. (For details about online licensing, start the License Configuration utility and click the Help button.)

If you prefer to obtain a license key from StarQuest via an email request, you need to provide a static IP address or the Host ID of the computer on which you will install the product. If the computer is in a network that uses the Dynamic Host Configuration Protocol (DHCP), provide the Host ID instead of an IP address to StarQuest when you request the license. IP addresses that are assigned by the DHCP service are dynamic and can invalidate the license key when the computer is assigned a different unique IP address.

Displaying the IP Address

Each node in an IP network must be assigned a unique address, such as 172.19.36.72. The IP address can be static (permanently assigned to the computer) or dynamic (assigned by the DHCP service). If the computer is assigned an IP address by the DHCP service, the IP address can change and you should provide the Host ID instead of the IP address when you request the license from StarQuest.

  1. To display the IP Address of a computer, enter the command ipconfig at a Command Prompt.

A display similar to the following shows the IP address that is currently assigned to the computer.

Connection-specific DNS Suffix: company.com
IP Address....................: 172.19.36.72
Subnet Mask...................: 255.255.255.0
Default Gateway...............: 172.19.24.1

Refer to the documentation for your version of the operating system for more information about displaying a command prompt or using the ipconfig command.

Displaying the Host ID

The Host ID, or Disk ID, of a Windows computer identifies the physical disk in a particular computer. You can display the Host ID from the License Configuration utility by clicking Add from the Licenses tab. Or you can display the Host ID by opening a command window and entering the command label at the command prompt.

The label command displays information similar to the following, from which you provide the Volume Serial Number to StarQuest when you request the license key.

Volume in drive C: has no label
Volume Serial Number is C854-CE05
Volume label <ENTER for none>?