Working with Network Applications

This chapter explains how to install applications in your OS/2 Warp Server domain to be accessed on the WorkSpace On-Demand 2.0 environment by the network users, how to define them as network public applications, and how to grant access to applications for your users.


Application Structure Under WorkSpace On-Demand

An operating system can be regarded as a collection of files that must be loaded into a client workstation's memory and executed. The same can be said for an application; it is simply a set of files that contain the application code and associated configuration information that must be loaded into memory and executed.

The files that comprise an application are similar in nature to those that comprise an operating system. However, an application introduces an additional level of complication since we must not only deal with configuration data that is specific to a client workstation but also that which is specific to an individual user. The table below shows the types of files that comprise an application, along with some examples.

File Types - Application Software

File Type

Read-Only

Read/Write

Generic

95% of application code

Not Applicable

Client-Specific

SNA network configuration

Temporary work files

User-Specific

Lotus Notes ID file

Lotus Notes desktop

It is a simple process to load an application into a client's memory from local storage since each client has its own copy of the application software. In most cases, each user has a unique copy of the configuration files, provided that the client is not shared among multiple users.

When you load an application from a server, however, the process becomes more complicated. A single copy of the application code is now shared between multiple clients and multiple users. Some of the files can be shared, but others are unique to a particular client or user. The server must store multiple copies of such files and allow each client and user to access the correct files. An application's files must therefore be divided into different groups and placed in different locations on the server.

However, most applications' installation programs assume that you are installing the application onto a local drive at the client workstation from which it will be run. They copy files into a single directory structure on a single logical drive. This means that you cannot simply run the installation program on the server and immediately access the application from a client.

When setting up a network application, you must perform a number of steps to ensure that clients and users can correctly access the application's files:

  1. Determine the required file structures for the application on the server.
  2. Copy the application's files into these file structures.
  3. Ensure that file I/O requests are correctly redirected to the server.

In order to successfully carry out these steps, you will need to understand the structure of the OS/2 Warp Server and WorkSpace On-Demand server environment, as well as the behavior of your application itself. There are a number of tools that can help you in analyzing your application's behavior, and these are discussed at the appropriate places in the text.

Application Types

Before starting to set up an application for access by WorkSpace On-Demand clients, you should understand the basic type of application with which you are working. Applications can be split into three basic types:

The type of application you are installing will affect the types of files within the application and the file structures into which they must be placed.

Generating Directory Structures

As illustrated in the table, File Types - Application Software , there are three basic types of files used by an application:

The WorkSpace On-Demand server provides a default set of directory structures in which you can store these different types of files. Application Directory Structures shows the directory structures that are available on the WorkSpace On-Demand server.

 
Application Directory Structures

Shared Files

Generic shared files, to which the client workstation requires only read access, can be located in one of two places on the server:

  • In a subdirectory within the \IBMLAN\RPL\BB20.US directory tree. The application's directory is thus treated as part of the client's boot-drive, and is immediately accessible to the client both at boot-time and after user logon. This is the preferred method of sharing application files and indeed is the only method by which you can easily access application files during the boot sequence.
  • In a shared directory to which the client workstation and/or end user is granted access. This works satisfactorily for applications which do not require device drivers or other modules to be initialized at boot-time, but requires more work to define and grant access to users. All the applications can share the same alias in order to optimize network resources.

We recommend that you create a subdirectory for your application's shared files within the \IBMLAN\RPL\BB20.US directory tree. This directory tree contains the operating system image and is the best location for shared application files that are common to all clients and users. It is available to all clients at boot-time as part of the RPLFILES alias.

Many middleware applications require device drivers or other application code to be loaded during the boot sequence. You may therefore need to add statements to your client's CONFIG.SYS file.

Client-Specific Application Files

With many applications, certain configuration files are specific to the individual client. For example, the Personal Communications/3270 Access Feature includes configuration files containing SNA physical and logical unit IDs that are unique to each client.

The WorkSpace On-Demand server provides two directory structures in which you can place such files:

  • The \IBMLAN\RPL\MACHINES directory tree contains operating system and application files specific to a particular client and to which the client requires only read access. This structure is available to all clients at boot time as part of the RPLFILES alias.
  • The \IBMLAN\RPLUSER directory tree contains operating system and application files to which the client requires read/write access, such as log files. This file structure is available to all clients at boot time as the WRKFILES alias.

Each client has its own unique subdirectory within each directory tree. You can place client-specific files within these subdirectories using the IBMLAN\RPL\MACHINES\client_name subdirectory for read-only files and the \IBMLAN\RPLUSER\ client_name subdirectory for those files that require write access.

When deploying WorkSpace On-Demand in a large-scale production environment, you may wish to automate the creation of these client-specific files using the following technique:

  • Place a default version of each client-specific configuration file in the \IBMLAN\RPLUSER\BB20.US directory structure. WorkSpace On-Demand automatically replicates this directory structure, including subdirectories and files, to the \IBMLAN\RPLUSER\ client_name directory for each client when the client is defined.
  • Use REXX command files to modify the contents of each client-specific configuration file and add the required unique entries for each client at client definition time. The information for these entries must, of course, be gathered as part of the preinstallation planning performed prior to deploying WorkSpace On-Demand.

User-Specific Application Files

Some applications may incorporate files that are specific to an individual user. For example, Lotus Notes includes files, such as a user's ID and DESKTOP.DSK files, that define the working environment for a specific user rather than for the client workstation itself.

In a WorkSpace On-Demand environment, you must place such user-specific files in a location on the server from which they can be accessed after the user logs on. This location will of course be different for each user. We recommend that you place these files in the \IBMLAN\DCDB\USERS directory structure. This directory is created on the domain controller when you define a user ID, and the user has read/write access to the files in the directory.

Note that this directory structure is located on the domain controller for your OS/2 Warp Server domain. In a single-server environment, this is the same physical machine as your WorkSpace On-Demand server. However, if you define your WorkSpace On-Demand server as an additional server in your OS/2 Warp Server domain, the files in this directory structure will reside on a different physical machine than the shared and client-specific files.

Copying Files to the Directory Structures

When you have created the directory structures necessary to support your application's files on the server, you must copy the files to the correct locations within these directory structures. Determining which files must be placed in which locations, and ensuring that each file resides in the correct location, is a critical element in setting up a network application.

At this point, you will need to understand the behavior of your application and the files that it requires in order to load and run correctly. We have developed a methodology that will help you to investigate your application's behavior and place its files in the correct locations on the server. Installing an Application on the Server describes this methodology in detail.

Redirecting File I/O Requests

The WorkSpace On-Demand client operating system maintains a FIT in memory for use by applications and the operating system itself. When an application running on a client requests access to a file on the server, the client operating system uses the FIT to redirect file I/O requests to the correct location on the server. The table below shows the process by which this redirection occurs.

 
Redirecting Application File I/O Requests

In most cases, the client will regard all application files as residing on its boot drive. The client operating system uses the FIT to resolve the directory and file name requested by the application to an alias, directory and file name on the server, and requests that file from the server over the network.

When you place application files in the directory structures on the WorkSpace On-Demand server, you must ensure that the FIT used by the client includes redirection statements for these files. You can place these statements in either of two areas:

  • For client-specific applications that are launched during the client's boot sequence, place the redirection statements in the machine FIT file.
  • For user-specific applications that are launched by the end user, place the redirection statements in the application FIT file.

For client-specific and user-specific files, you can use the variables allowed in the application FIT file to redirect file I/O requests to a specific client's or user's directory structures.

Access Control Profiles

When placing files on the server, you must ensure that the client and/or the user has the necessary permissions to access the files. Remember that the client workstation itself has a user ID created when you define the client, and this user ID is used to authenticate all file access requests until an end user logs on to the client.

After an end user logs on to the client, the end user's own user ID is used to authenticate access requests for resources that have not already been accessed by the client prior to logon.

Application/File Types - Access Control Profiles

Application Type

File Type

Access Control Profile

Client-Specific

Generic

Client

Client-specific

Client

User-Specific

Generic

User

User-specific

User

Hybrid

Generic

Either

Client-specific

Client

User-specific

User

In many applications, this does not present a problem since all the application's files are accessed either before or after logon. However, some applications exhibit characteristics of both the client-specific and user-specific types; these are the hybrid applications shown in the table, Application/File Types - Access Control Profiles. These applications may access certain files at boot-time, before a user logs on, and other files after a user logs on. Lotus SmartSuite for OS/2 Warp 4 is an example of such an application.

It is important to understand that if a network alias is first accessed prior to user logon, the client's user ID and access control profile will be used for all file I/O requests to that alias, both before and after user logon. If an alias is not accessed until after user logon, the user's user ID and access control profile will be used to authenticate all file I/O requests for that alias. You must therefore ensure that you organize your FIT file entries, and the aliases to which they redirect requests, in such a way that the application can access its files on the server using the correct access control profile.


Installing an Application on the Server

As discussed in Application Structure Under WorkSpace On-Demand , you cannot simply install an application on your WorkSpace On-Demand server and expect it to be immediately accessible to WorkSpace On-Demand clients. You must alter the directory structures and other environment settings created by the application's installation program, to reflect the fact that the application will be loaded from the server but executed on the clients. The following sections show you how to determine the changes that are required and how to apply these changes to your application's environment.

Hardware Requirements

In order to install and test your application in a WorkSpace On-Demand environment, you need to provide a test hardware environment as shown in Creating a Machine Class - Test Hardware Environment .

 
Creating a Machine Class - Test Hardware Environment

First, you will require a WorkSpace On-Demand server. This is required in all cases, regardless of the type of application you wish to install.

For testing, and in some cases for installation too, you will need a client, known as a reference client. Some applications will require you to install the application on the reference client, then transfer the files to the correct locations on the server. For this reason, the reference client should include the following:

  • A BIOS that allows it to boot from the network as well as from local storage devices.
  • A network adapter that is supported by WorkSpace On-Demand 2.0 or for which you have already generated the appropriate definitions.
  • Its own local disk drive, with sufficient disk space to install OS/2 Warp 4.

When creating and testing your application definitions, you will use the reference client as both a WorkSpace On-Demand client and a traditional "fat" client in stand-alone mode.

Create a Temporary Environment

Create a temporary environment on the server using the MKTMPENV utility provided with WorkSpace On-Demand 2.0. Issue the following command:

MKTMPENV client_name environment_name /ADD

where client_name is the name of the client, and environment_name is any name not beginning with BB or OS2.

The MKTMPENV utility creates copies of several directory structures as shown in MKTMPENV Utility Directory Copies . These three directory trees represent the three basic ways in which an application may share its files, as discussed in Generating Directory Structures .

MKTMPENV Utility Directory Copies

Original

Copy

\IBMLAN\RPL\BB20.US

\IBMLAN\RPL\ environment_name

\IBMLAN\MACHINES\ client_name

\IBMLAN\MACHINES\ client_name .BAK

\IBMLAN\RPLUSER\ client_name

\IBMLAN\RPLUSER\ client_name .BAK

This process may take several minutes. After these directories are copied, you can install the application into the copies on the server

Note that certain applications do not install correctly on a server using the backup directory trees created by the MKTMPENV utility. In such cases, you may need to boot your reference client using OS/2 Warp 4, and install the application on the reference client's local hard disk. The reference client allows you to install the application in the standard way and analyze the additions and changes made to the reference client's file structures by the installation process. These detailed differences will allow you to transfer the application's files to the correct locations on the server, and configure the application to be used by users on WorkSpace On-Demand clients.

Install the Application

The means by which you install the application will differ depending on whether your application allows you to use the MKTMPENV utility or whether you are forced to use a reference client. Each method is explained in more detail below.

Using MKTMPENV

Boot the client and logon using an existing user ID. To avoid any problems with access control profiles at this time, we recommend that you use a user ID with administrator authority.

Install the application on the boot drive (usually Z:) following the application installation instructions. If possible, do not configure any client-specific or user-specific features.

When you have installed the application, run the DIFFTREE utility (provided with WorkSpace On-Demand 2.0) from an OS/2 command line on the server, using the following command:

DIFFTREE source_tree target_tree

You will need to run the DIFFTREE utility three times (once against each of the directory trees copied by the MKTMPENV utility):

The DIFFTREE report shows the files that were added or changed when you installed the application. With sufficient knowledge of the application, you should be able to place the read-only files and read/write files in the correct locations. At this stage, most files will be read-only. You should copy these files to the proper areas within the \IBMLAN\RPL\BB20.US directory tree.

 

Configure the application to include your required settings for both client-specific and user-specific information and generate a new DIFFTREE report. This report should now reflect the changes made during the configuration process.

Most files changed at this point will be client- or user-specific. You must decide whether you wish these files to be stored in a read-only form, thereby preventing the user from changing them, or in a read/write area, where the user may change them as required. You should place read-only files in the \IBMLAN\MACHINES\ client_name directory and read/write files in the \IBMLAN\RPLUSER\ client_name directory.

Using a Reference Client

If you are using a reference client, you must capture the client's system state, both before and after installing the application. This will allow you to determine which files and directories have been added or changed during installation.

Before starting the installation, turn off the archive attribute bit for all files on the reference client using the following command from the root directory of the client's boot drive:

ATTRIB *.* -A /S

This allows you to later determine which files are accessed during the application installation process, by querying the archive attribute.

Make copies of existing system configuration files, including:

CONFIG.SYS
OS2.INI
OS2SYS.INI
WIN.INI
SYSTEM.INI

The installation process may modify these files, and keeping copies allows you to determine where changes have been made.

Install and configure the application on the reference client according to the application's installation instructions.

When the installation is complete, search for all added or modified files on the client by issuing the following command:

DIR *.* /A:A /S >ATTRIB.TXT

This command scans the client's hard drive for all files that have the archive attribute set--that is, all files that have been opened or modified during the installation process--and writes the resulting directory listing to a file named ATTRIB.TXT.

Identify Client- and User-Specific Files

It is very important that you understand the application's behavior in order to determine which files and subdirectories require only read access and which require read/write access. Typically, application code can be made read-only and shared by all clients and users, but client- and user-specific files must be separated into client- and user-specific subdirectories and accessed in read/write mode.

At this point, you will require some knowledge of the way in which your application operates since you must now determine which application files can be shared by all client workstations and/or users and which files are specific to a particular client or user. Generic files can be located within the WorkSpace On-Demand boot image and shared by all clients and users, but client- or user-specific files require separate copies to be made and placed in different directories. Generic application files that can be shared by all users are normally located within the client's boot image on the server--that is, within the \IBMLAN\RPL\BB20.US directory tree.

For the files that are specific to a client or user, you must identify those files that are specific to a client and determine whether each file can be accessed in read-only mode or whether it requires write access during application execution. Client-specific, read-only files can be placed in the \IBMLAN\RPL\MACHINES\ client_name directory, but client-specific, read/write files should be placed in the \IBMLAN\RPLUSER\ client_name directory, where client_name corresponds to the name of the client.

For the user-specific files, you must perform a similar task to determine which files can be accessed in read-only mode and which files require write access. You must create your own directories to contain user-specific, read-only files since WorkSpace On-Demand does not provide a directory for such files. You can place user-specific read/write files in the \IBMLAN\DCDB\USERS\ user_id directory on the domain controller. In most cases, however, you can simply place all user-specific files in the \IBMLAN\DCDB\USERS\user_id directory on the domain controller.

Copy Application Code to the Server

Next you must translate the application's directories on the server or the reference client to your current WorkSpace On-Demand client boot image. The steps you must follow will differ depending on whether your application allowed you to use the MKTMPENV utility or whether you were forced to use a reference client.

Using MKTMPENV

If you are installing from a temporary environment that you created on the server using the MKTMPENV utility, XCOPY the contents of the \IBMLAN\RPL\ environment_name \ appl_name directory to a new directory named \IBMLAN\RPL\BB20.US\ appl_name \, where appl_name is the base directory for the application (for example, NOTES for Lotus Notes or NETSCAPE for Netscape Navigator). You should ensure that the subdirectories are also copied.

Using a Reference Client

If you installed the application on a reference client, you should create a directory tree within the \IBMLAN\RPL\BB20.US directory corresponding to the application's directory tree on the reference client. You can use a compression tool such as Infozip's PKZIP.EXE to create a single file containing the application's entire directory structure. You can then move this file to the server and unzip it into the \IBMLAN\RPL\BB20.US directory.

Copy Client- and User-Specific Files to the Server

You must now copy any client- and user-specific files to the appropriate locations on the server.

The exact directory structures you use on your server will depend upon your own preferences and the requirements of the application, since some applications require a specific directory structure for their files.

Modify Operating System Configuration Files

Some applications, particularly middleware applications, will modify operating system configuration files such as CONFIG.SYS and possibly even OS2.INI or OS2SYS.INI. Windows applications commonly make changes to the WIN.INI and SYSTEM.INI files. You must ensure that these changes are reflected in the corresponding files within the client's boot image.

Note the changes made to the system configuration files by the application installation process, and make the necessary additions or modifications to the corresponding files in the client's boot image. While each client has its own unique set of system configuration files, which are located in the \IBMLAN\RPL\MACHINES\ client_name directory, it is more efficient to make the changes to the template files for a client's machine class, which are located in the \IBMLAN\RPL\MACHINES\BB20.US\ machine_class .MC directory. Any changes that you make to this file are automatically incorporated into each new client's configuration files when you define the client.

Some applications may modify binary files such as OS2.INI. In these cases, you must use a utility, such as INIDIFF.CMD, to determine the changes made to the INI files, and then use the INIMERGE.CMD utility and possibly an INI file editor, such as FM/2, to apply these changes to the INI files in the client's boot image. These utilities are included on the CD-ROM that accompanies this redbook.

In WorkSpace On-Demand 2.0, you can define certain INI file entries dynamically using the Parameters page in the Application Definition notebook when you define create a network application definition. See Customizing INI Files , for more information on how to do this.

The method described above incorporates the changes into the configuration files for every new client that you define using a particular machine class. If you wish to run an application only on certain clients, and therefore want the necessary modifications to be included only for those clients, you may wish to create a new machine class and make the modifications to the templates for that machine class only.

Note that the more application code you include in your client's boot image to be loaded at boot-time, the larger the working set of your client becomes. Since this can affect the boot performance of your clients, you need to find the right balance between loading code at boot-time or alternatively, waiting until an application is needed before loading its modules. This balance will depend heavily on the types of applications that you use in your particular installation.

Redirect Required Files

You must ensure that all application files are addressed by entries in the client's file index table (FIT). You can place the required entries in the machine, user or application FIT files, depending on the time at which the file will be accessed.

Any files used by middleware applications that will be accessed at boot time should be placed in the machine FIT file, irrespective of whether they are generic, client- or user-specific files, since the machine FIT file is loaded into the client's memory during the boot process. Note that you must place these files in a location on the server to which the client has the appropriate access using the client's own access control profile.

Application files that are accessed by applications launched from the desktop by the end user should be placed in the application FIT file. You can use the variables available under WorkSpace On-Demand 2.0 to tailor a single application FIT file to support multiple clients and users. These variables are:

Note that the user FIT file is not widely used under WorkSpace On-Demand 2.0 since the application FIT file performs many of the same functions and allows you to load and discard FIT entries when starting and stopping an application, thereby saving memory space in the in-memory FIT.

You may wish to use a user FIT file, however, if you have a hybrid application that is loaded at boot-time and therefore has entries in the machine FIT, but also requires access to user-specific files. Since entries in the user FIT override similar entries in the machine FIT, you can use the user FIT to redirect certain files to the correct, user-specific locations.

Test the Application Definition

Test the network application by running it from a different client workstation. Ensure that the application runs correctly and that all configuration files can be accessed and, where necessary, modified. For user-specific applications, you should also log on using several different user IDs, and ensure that the user-specific settings are loaded correctly by the application.

Clean Up the Installation Environment

Delete the NetBIOS sessions between the server and the client by issuing the following command from the server's command line with administrator privilege:

NET SESS \\ client_name /DEL

If you used the MKTMPENV utility to create a temporary environment on the server, delete the temporary environment by issuing the command:

MKTMPENV client_name /DELETE


Defining the Application Using the GUI Interface

Defining an application for use by a WorkSpace On-Demand client is much the same as setting up a network public application with OS/2 Warp Server. However, WorkSpace On-Demand adds a number of enhancements to the public application facility. These enhancements allow more environment information to be saved with the application, thus allowing for application roaming (see Application Roaming ).

The example we use here is an OS/2 application named PMCAMERA. This application consists of the following files:

PMCAM200.DLL
PMCAM200.EXE
PMCAM200.HLP
PMCAM200.INI

This is a very simple application, but it illustrates the principles of application definition quite well since it contains several different file types.

You must first decide where to install your application on the server. We recommend installing your applications within the \IBMLAN\RPL\BB20.US directory tree. For this example, we will create a subdirectory named PMCAMERA within the \IBMLAN\RPL\BB20.US directory. We will then create another directory named PMCAMERA\DLL for the DLL files, and a third directory named PMCAMERA\HLP for help files.

Installing PMCAMERA is very easy; you must simply XCOPY the application files to their locations:

XCOPY PMCAM200.DLL C:\PMCAMERA\DLL
XCOPY PMCAM200.EXE C:\PMCAMERA
XCOPY PMCAM200.HLP C:\PMCAMERA\HLP
XCOPY PMCAM200.INI C:\PMCAMERA

Begin by opening the Public Application Definitions folder for your OS/2 Warp Server domain.

 
Public Application Definitions Folder

Identify the Application

In the Public Applications Definitions folder, drag and drop a WorkSpace On-Demand Template to a free area of the folder. The OS/2 Warp Server GUI displays the Identity page of the Application Definition notebook, as shown in the picture below.

 
Application Definition - Create Settings Notebook

On this page, enter a name for the application in the Application name field, and enter a description in the Description field.

Specify the Program Name

On the Invocation page, specify the command used to launch the application. In our PMCAMERA example, the command is PMCAM200.EXE. You can also specify additional parameters on this page, or instruct the client to prompt the user for additional parameters when starting the application.

Specify the Program Location

On the Program Location page, you need to specify the Alias directory that you had defined earlier for the application. The path to the application's main executable also needs to be specified, as shown in the picture below. .

 
Application Definition - Program Location Page

You can see from the example Application Definition - Program Location Page that we have selected the On requester radio button. This is because, even though the application physically resides on the server, we will access it from the client workstation's viewpoint as though it resides on the client's boot drive (Z:). This is the preferred method of accessing network applications since it reduces the number of network aliases, which are potential drive letter assignments, required on the server.

If you wish, however, you can select the On server radio button. The OS/2 Warp Server GUI then replaces the Drive field with an Alias field into which you can enter the name of the network alias on which the application resides.

Most applications do not require a drive letter assignment to the directory alias where the program resides. The default is not to assign a drive on the Program Location page. However, some application programs require a drive assignment and will not start correctly unless one is assigned. To avoid this situation, you can assign a drive letter to the directory alias as a current assignment and specify this drive.

Assign a Work Directory

Some programs require a work directory to store temporary files and other working data. You can assign a working directory using the Work Directory page, as shown in the picture below.

 
Application Definition - Work Directory Page

Here we have specified the work directory to be the user's home directory, which is accessed as drive H: from the client's viewpoint. This example assumes that you have defined a home directory for each user who will run PMCAMERA and that this directory is accessed as drive H: by the user.

Specify the Program Mode

On the Program Mode page, you need to specify what type of application you are defining. In our PMCAMERA example, the application is an OS/2 Presentation Manager (OS/2 PM) application.

Allocate Network Resources

The picture below shows the Network Resources page. Using this page, you can dynamically assign network resources, such as printers, shared serial ports or additional directory aliases, when the application is started by the user. Note that the user must have the appropriate level of access to the resource.

 
Application Definition - Network Resources

In our PMCAMERA example, we do not require any additional network resources; so the Network Resources page is left blank.

Define Required Environment Variables

The Parameters page allows you to define the application's execution environment dynamically when the application is started. This page is shown below.

 
Application Definition - Parameters

The Parameters page displays the environment variables including their names, the location where the value is appended to the variable, the value, and whether the parameter is user-specific. From here, you can add, change or delete parameters. You can also read a set of parameters from a file instead of manually entering them each time.

Adding Parameters

To add an application parameter:

  1. Select the Add push button. The Add Application Parameters pop-up is displayed, as shown in the picture below.
 
Application Definition - Adding Configuration Parameters
  1. Choose either the Configuration radio button to display a drop-down list of known environment variables from which to select an item, or choose the Application specific radio button and enter an application-specific environment variable name.
  2. Choose the position for appending the environment parameters. Select Begin to place the parameter value at the beginning of a currently existing environment variable of the same name. Select End to place the parameter value at the end of a currently existing environment variable of the same name. Select Replace to replace an existing environment variable with the value you specify.

You can specify a parameter name more than once if it is defined with a different append value. Parameters specified more than once that have different append values are processed in the following order:

REPLACE value
  1. BEGIN value
  2. END value

If you repeat a parameter name with the same append value, an error message is displayed that instructs you to correct the problem before adding that parameter.

You can specify most environment variables as application parameters; however, LIBPATH is an exception. LIBPATH cannot be changed or replaced. LIBPATH can only be specified with the BEGIN or END append flag to allow adding to the front or back of the existing LIBPATH . Additionally, BEGINLIBPATH produces the same results as specifying LIBPATH with the BEGIN append flag, and ENDLIBPATH produces the same results as specifying LIBPATH with the END append flag. See the IBM OS/2 Command Referenc e for more information on using LIBPATH .

 
  1. Enter the value of the parameter in the Value field.
  2. In our PMCAMERA example, the following parameters must be added:
  3. LIBPATH, Begin, \\WSODSRV1\OS2APPS\DLL
  4. HELP,?, \\WSODSRV1\OS2APPS\HLP
 
  1. Select the User specific checkbox if you wish this parameter to be overridden for each user. In such cases, the value that you specify here becomes the default. See Section See User-Specific Application Parameters , for information on how to override the default value.
  2. Select OK to add the parameter.

The Add Application Parameters pop-up will disappear, and the new parameter you have added will appear in the list on the Parameters page in the Application Definition notebook.

If you wish to add another parameter, select the Add button again. Similarly, you can modify or delete an existing parameter by selecting the Change... or Delete buttons, respectively.

Parameter Types

There are two basic types of parameters that you can select using the Add Application Parameters pop-up:

  • Configuration parameters are the environment variables PATH , LIBPATH , DPATH , and HELP .
  • Application-specific parameters are special parameters that apply only to a specific application. If your application sets its own environment variables, you can define them here. There are also a number of parameters that are defined by WorkSpace On-Demand itself, but you can specify to customize the behavior of your application on the client. A number of these are described in the following sections.

Launch Parameters

WorkSpace On-Demand supports several special parameters that define the way an application is launched. You can specify these parameters on the Parameters page of the Application Definition notebook, just as you can any other application-specific parameter.

WSOD_LAUNCH_MINIMIZED

When you specify this parameter with a value of 1, the application is launched minimized. The table below shows the Add Application Parameters pop-up when adding the WSOD_LAUNCH_MINIMIZED parameter.

 
Application Definition - Adding Application-Specific Parameters
WSOD_LAUNCH_SESSION

This parameter gives the administrator full control over the type of session in which WorkSpace On-Demand will launch the application. Use this with care because the application may not work at all if you choose the wrong type of session. WSOD_LAUNCH_SESSION Values shows the values that WSOD_LAUNCH_SESSION can take and the session types that it will launch.

WSOD_LAUNCH_SESSION Values

Value

Session Type

1

Full-screen OS/2 session

2

Windowed OS/2 session

3

OS/2 Presentation Manager application

4

Full-screen DOS session

7

Windowed DOS session

10

WIN-OS/2 real mode session

12

WIN-OS/2 auto mode selection

15

WIN-OS/2 standard mode, seamless, separate VDM

16

WIN-OS/2 standard mode, seamless, common VDM

17

WIN-OS/2 enhanced mode, seamless, separate VDM

18

WIN-OS/2 enhanced mode, seamless, common VDM

19

WIN-OS/2 enhanced mode, full-screen session

20

WIN-OS/2 standard mode, full-screen session

WSOD_LAUNCH_NODROP

When you specify this parameter with a value of 1, the client operating system leaves network resources, such as application FIT entries, attached when the application's primary executable terminates. This parameter is useful when you wish to launch an application containing a number of executables that must be run in sequence.

If you specify the NODROP parameter with a value of 1, the application launcher will keep the application FIT file entries in the in-memory FIT when the application's initial executable terminates. If you do specify the WSOD_LAUNCH_NODROP parameter, the application launcher removes the application FIT entries from the in-memory FIT.

WSOD_LAUNCH_NOCLOSE

When specified with a value of 1, this parameter causes a DOS or OS/2 VIO window not to close when the application terminates. This may prove useful in determining the cause of a problem with the application definition because you will be able to see any error messages the program generates. It is usually best removed once the program is working correctly.

Create the Application Definition

Add a title on the General page of the Application Definition notebook (for example, PMCAMERA); then select the Create button at the bottom left-hand corner of the Application Definition notebook to create the application definition.


Defining the Application Using the Command Line Interface

How you administer your applications and users depends on your administrative structure and the knowledge of the people in your remote locations. Many users may need to use the same set of public applications; so it may make sense to define applications and grant access to users through an automated process. Alternatively, the administrators (if any) in your remote locations may not be familiar with such tasks.

Another advantage in using the command line interface is the standardization of your application definitions. By using default scripts to define your applications, you avoid having different application definitions across your different locations. In large enterprise environments where you may have many locations and many users, the use of standardized batch processes or REXX scripts helps to provide a consistent end-user environment.

You can define applications using the NET APP command from a command line or a REXX script. The NET APP command has the same capabilities as the Application Definition notebook, but has the advantage that you can run it remotely in a full screen session, or you can run it unattended using response files. The command line interface therefore allows you to support remote administrators or to perform all administration from a central site.

WorkSpace On-Demand 2.0 enhances the command line interface to support the new WorkSpace On-Demand application parameters as well as the standard OS/2 and DOS public applications using the NET APPPARM command. You can use the NET APP and NET APPPARM commands to create WorkSpace On-Demand public applications, to modify the application-specific parameters, to assign applications to users, or to make application parameters user-specific.

OS/2 Presentation Manager Application

You can use the NET APP command to create an application definition for an OS/2 PM application. For example, the following creates an application definition for PMCAMERA:

NET APP PMCAMERA /APPDIR:Z:\PMCAMERA /COMMAND:PMCAM200.EXE
/REMARK:"PMCamera" /TYPE:WSOD /INTERFACE:PM /ADD

OS/2 Command Line Application

You can use the NET APP command to create an application definition for an OS/2 command line (VIO) application that will run in a windowed or full screen OS/2 session. For example, the following command creates a windowed OS/2 command line session:

NET APP OS2WCOMD /APPDIR:Z:\OS2 /COMMAND:CMD.EXE /REMARK:"Windowed OS/2
Command Prompt" /TYPE:WSOD /INTERFACE:PM /ADD

You can create a definition that directly launches an application program by including the name of the application's EXE file in the /COMMAND : parameter. To create a full screen OS/2 session, use the same command with the /INTERFACE:FS parameter.

WINOS2 Application

To create an application definition for a general WIN OS/2 session, use PROGMAN.EXE as the invocation command. Do not use WIN.COM or WINOS2.COM. When you create an application definition for any application that resides in the WINOS2 directory of the client boot image, the program location (on the Invocation page) must be specified as being on the requester, with the drive and path of the program being the boot drive and \OS2\MDOS\WINOS2.

To create an application definition for a WINOS/2 windowed session (Win3.1 Enhanced Mode), type the following command from an OS/2 command line:

NET APP WINOS2W /APPDIR:Z:\OS2\MDOS\WINOS2
/COMMAND:PROGMAN.EXE /REMARK:"Windowed WINOS/2 Command
Prompt" /TYPE:WSOD /INTERFACE:PM /ADD
NET APPARM WINOS2W /ADD WSOD_LAUNCH_SESSION=17 /PLACEMENT:R

When using WINOS/2 full-screen sessions, if the session appears to be unresponsive to the mouse or keyboard input, or both, enter the following command from an OS/2 command line:

NET APPARM WINOS2FS /ADD VIDEO_SWITCH_NOTIFICATION=1
/PLACEMENT:R

To create an application definition for a WINOS/2 full-screen session, use the same command with the /INTERFACE:FS parameter; then use the NET APPARM command with the WSOD_LAUNCH_SESSION=19 parameter (for Windows 3.1 Enhanced Mode).

DOS Application

You can use the NET APP command to create an application definition for a DOS application, as shown in the following example:

NET APP DOSWIND /APPDIR:Z:\OS2\MDOS /COMMAND:COMMAND.COM
/REMARK:"Windowed DOS Command Prompt" /TYPE:WSOD /INTERFACE:PM /ADD

You can then use the NET APPARM command to specify DOS settings for the application. For example, the following example configures a DOS application to use 4 MB of EMS memory and 8 MB of XMS memory:

NET APPARM DOSWIND /ADD MOUSE_EXCLUSIVE_ACCESS=1 /PLACEMENT:R
NET APPARM DOSWIND /ADD XMS_MEMORY_LIMIT=4096 /PLACEMENT:R
NET APPARM DOSWIND /ADD EMS_MEMORY_LIMIT=8192 /PLACEMENT:R

Using Response Files

You can use response files to create applications, set the application parameters to the default values, and assign applications to your users. Response files provide a powerful way to automate your WorkSpace On-Demand administration and apply necessary standards across a number of servers.

You can use the response file to create WorkSpace On-Demand applications and assign these applications to users.

The applications are

The application parameters are not provided; so some applications, such as PM Camera, will need more application parameters. The response file is included to show the basic capabilities of the command line interface in conjunction with response files.


DOS and WIN-OS/2 Applications

The same general principles apply to setting up a DOS or Windows application under WorkSpace On-Demand as to any other. There are a few special considerations, however.

You must pay particular attention to the way your application handles the Windows INI files. In many cases, you must make a policy decision on whether to allow your users unrestricted access to their own copies of the INI files by means of FIT file extensions or to allow only read access to a common set of standard INI files. Once again, there is no substitute for knowing your application!

There is no need to use OS/2 Warp Server's DOS and Windows Template to create an application definition. Although this will work, it is better to use the WorkSpace On-Demand 2.0 Template, which gives you the option to specify parameters for the application.

DOS and WIN-OS/2 Settings

WorkSpace On-Demand supports the use of DOS and WIN-OS/2 settings although it has no equivalent to OS/2's Add Programs facility to define them automatically. You can define any setting as an application-specific entry on the Parameters page of the Application Definition notebook simply by entering the name of the setting and the required value.

For example, you can enter the IDLE_SECONDS setting with a value of 60 , the IDLE_SENSITIVITY setting with a value of 100 , a FOLDER setting with a value of <WP_APPSFOLDER> , and so on with all the DOS or WINOS2 settings.

To change these values, you must use the SET command, followed by keyname=value in the value field on the Parameters page in the Application Definition notebook. For example:

SET DOS_FILES=45;SET DOS_HIGH=1;

Note that when defining DOS settings on an OS/2 Warp 4 client, you would typically select On or Off radio buttons for some settings. When specifying these settings on the Parameters page in the Application Definition notebook, you must use the Boolean values 1 for On and 0 for Off. For example:

SET COM_HOLD=1;

will set the COM_HOLD setting to On.

Some settings, such as DOS_VERSION , may already have default values. You must be careful when specifying these settings since any value that you supply is treated as a replacement (even if you are using the UPDATEIFEXIST flag). Therefore, if you wish to add one item to the list of items in the DOS_VERSION setting, you should also include all of the existing values.

Note that some settings may not apply to particular clients due to their hardware configuration. For example, the VIDEO_8514A_XGA_IOTRAP setting is only available on certain client hardware.

You can find a list of standard settings for many applications in the \IBMLAN\RPL\BB20.US\OS2\INSTALL\DATABASE.TXT file on your WorkSpace On-Demand server.

Remember that even though a DOS-specific template appears in the Public Application Definitions folder, you should use the Workspace On-Demand template since this is the only template that allows you to define application parameters in this way.


Java Applications

You can run both Java applets and Java applications on your WorkSpace On-Demand 2.0 clients without using a Web browser. Applets and applications are run by the Java Virtual Machine (JVM) built into the WorkSpace On-Demand client operating system. At the time of writing, the current version of the JVM is Version 1.1.6.

The Java 1.1.6 specification requires 256-color mode (or greater). However, Java applications and applets using the Abstract Window Toolkit (AWT) on WorkSpace On-Demand clients can run in 16-color mode, but may be difficult to read. Using 256-color mode (or higher) is recommended for this version and for future versions of Java for OS/2.

Java Applets

WorkSpace On-Demand clients run Java applets on the desktop using the applet viewer APPLET.EXE. By making APPLET.EXE available as a public application, you can make Java applications available to WorkSpace On-Demand users.

You will need to configure a separate invocation of APPLET.EXE for each Java application you intend to make available this way. In each case, you must pass the name of the HTML file defining the application as a parameter on the Invocation page of the Application Definition notebook, as shown in the picture below.

 
Defining the Java Configuration Applet

You will probably not need to give your users write access to any files in order to run Java applets. Instead, by running the CNFGAPPL utility applet once on the server, you can create a single, central copy of the PROPERTY file, located on the \JAVAxx\HOTJAVA subdirectory, from which all the users can then read their Java configuration values.

However, you must redirect the file access for the PROPERTY file using a FIT entry in order for the client workstation to search the correct directory. The default FIT entry in the machine FIT file redirects all access to the \JAVAxx\HOTJAVA subdirectory to the client-specific read-write area on the server. If you wish to redirect access to this subdirectory to the generic read-only area on the server, you should override the default entry with the following:

Z:\JAVA11\HOTJAVA BB20.US\JAVA11\HOTJAVA

You can do this by editing the machine FIT file or by adding the above entry to the default user FIT file DD20USDU.FIT.

Java Applications

Setting up a Java application is very similar to setting up a Java applet, with only one or two differences:

Apart from the above, defining a Java application is similar to defining any other application.


Granting Access to Users

After you have installed and defined a network application on your server, you must grant access to end users so that they can use the application. OS/2 Warp Server's access control policies ensure that, by default, no user has access to any network resource, including applications, unless that access is granted by the system administrator.

 

Using the GUI

All those tasks can be performed through the OS/2 Warp Server GUI. To assign an application to an end-user:

  1. Open LAN Services from the OS/2 Warp Server desktop.
  2. Open LAN Server Administration.
  3. Open the appropriate domain object.
  4. Open User Accounts.
  5. Open the object for an existing user ID.
  6. Select the Applications page, as shown in the picture, Granting Access to an Application.
 
Granting Access to an Application

To assign or add a public application for this end-user, select the Add button. The Add Public Applications pop-up is displayed, as shown in the picture below.

 
Add Public Applications Pop-Up

Select the application you require from the list and click on the Add button to add it to the list of applications on the Applications page.

You can define application access for many users at one time by dragging and dropping the application's icon on a user group icon within the Groups folder. This assigns access to the application for all users within that group. However, you must be careful when adding new users to the group after you have granted access to the application since these new users will not automatically be granted access.

Using the Command Line Interface

You can also grant access to an application for an end user through the command line interface using the following command:

NET USE user /ASSIGN PUBLIC: application_name

where user is the user ID to which you wish to assign the application, and application_name is the name of the application as defined on the Identity page of the Application Definition notebook.

You can easily use a REXX program to extend such definitions to a large number of users; so the command line interface provides an ideal method of granting access to applications in organizations with many end users.

User-Specific Application Parameters

After you have defined a network application, you can also define certain application parameters on a per-user basis. In order to do this, you must specify the parameter as user-specific when you define the application.

To set user-specific application parameters:

  1. Open User Accounts.
  2. Open the object for an existing user ID.
  3. Select the Applications page.
  4. Select the desired application from the public application list. If the application has user-specific parameters within its definition, the User Parameters button will be selectable.
  5. Select the User Parameters button. The User-Specific Application Parameters pop-up appears as shown in Adding a User-Specific Application Parameter Value , with the parameter name, where it is appended, and the value.
 
Adding a User-Specific Application Parameter Value

To add a user-specific application parameter setting:

  1. Select an application parameter from the User default parameters list.
  2. Select the Add button.
  3. This adds the entry to the User-specific parameters list and displays the Set User-Specific Value pop-up.
 
Set User-Specific Value Pop-Up
  1. Enter the desired value for the application parameter.
  2. Select OK.

Note that if you define a parameter as user-specific when you define the application but do not specify a value using the Set User-Specific Value pop-up, WorkSpace On-Demand uses the default value that you specified when defining the application.


Customizing INI Files

Certain applications may require their own entries in the client's OS2.INI or OS2SYS.INI files. When you install such applications on a traditional "fat" client, the installation program makes the necessary modifications to the INI files. In a WorkSpace On-Demand environment, however, you may need to manually add the necessary entries to these files.

When you compare the file structures on your server or reference client before and after installing an application, you may notice that one or more INI files have been changed. If this is so, the following sections will show you how to determine the specific differences between the files and how to add the necessary entries to the INI files in your WorkSpace On-Demand client's boot image.

INI File Structure

An INI file is a binary file that consists of a set of application-type groups. Within each application type is one or more entries consisting of a keyname and a value.

Comparing INI Files

You can use the INIDIFF utility included on the CD-ROM that accompanies this redbook to compare two INI files and produce a third file that contains only the differences between the two. The syntax of the INIDIFF command is as follows:

INIDIFF <source.INI> <new.INI> <delta.INI>

The INICREATE.CMD utility will extract any new application types, keynames and/or values that exist in new.INI, but not in source.INI, and write them to delta.INI. You can then use delta.INI to incorporate these changes into the appropriate INI file in your client's boot image.

Modifying INI File Entries

You cannot edit an INI file using a normal text editor, but you can use an INI editor, such as UNIMAINT or FM/2, to edit the application types, keynames and values within an INI file. This is often necessary when you are creating or modifying machine classes, particularly when adding support for new video adapters. It is also necessary when you are setting up a network application that requires entries in one or more INI files.

Using an INI Editor

You can use an INI editor to check the delta.INI file created by the INIDIFF utility, and then modify the appropriate INI file in the client's boot image in one of two ways:

  • Manually by using the INI editor to add the necessary application types, keynames and values
  • Automatically by using the INIMERGE utility included on the CD-ROM that accompanies this redbook. The syntax of the INIMERGE command is:

INIMERGE target.INI delta.INI

Either method will result in a new INI file with the necessary entries to support your machine class or application.

Using the NET APPPARM Command

WorkSpace On-Demand 2.0 allows you to add or modify INI file entries dynamically when you launch an application. You can specify the entries to be added or changed from the command line by using the NET APPPARM command with the appropriate parameters as shown in NET APPPARM Command - INI File Parameters .

NET APPPARM Command - INI File Parameters

NET APPPARM Parameter

Meaning

/FIELDTYPE:I

Indicates that the APPPARM command is an INI file update.

/INIFILE:ini_file_name

Indicates the INI file to be updated.

/INIAPP:ini_app_name

Indicates the application type within the ini_file_name to be created or modified.

/INIKEY:ini_key_name

Indicates the keyname associated with the application type to be created or modified. Note that ini_key_name is case sensitive.

/INIVALUE:ini_value

Indicates the value associated with ini_key_name . This parameter is not required to create an INI file entry. If not provided, the value is assumed to be an empty string.

/Uuser

Optional; if specified, the INI file is specific to a user.

The following rules apply to the use of these parameters:

  • If the /INIK parameter specifies a keyname that already exists within the INI file, the NET APPPARM command replaces the existing value for that keyname with the value specified by the /INIV parameter.
  • If the /INIA or /INIK parameters specify an application type or keyname that does not already exist, the NET APPPARM command adds that application type or keyname to the file.
  • If you do not include an /INIV parameter, the NET APPPARM command simply displays the current value associated with the application type and keyname specified by the /INIA and /INIK parameters.

For example:

NET APPPARM application_name /AD /F:I /INIF:\app_dir\app.ini /INIA:tags
/INIK:heading /INIV:bold /UO

You can also use the NET APPPARM command to delete an application type or keyname from an INI file. To do this, you must omit the /INIV parameter from the command and include the /DELETE parameter as shown below:

NET APPPARM application_name /AD /F:I /INIF:\app_dir\app.ini /INIA:tags
/INIK:heading /DELETE


Application Roaming

WorkSpace On-Demand introduces the concept of application roaming , which is the ability for users to logon to any client workstation and immediately access their own applications and data files. to locate and successfully execute personal user files and user-unique, network-public applications from any client workstation at which the user is logged on.

Application roaming provides the user access to his/her application from any WorkSpace On-Demand workstation of the same machine class. Previously, although the application was installed on the server, environment information needed to be added to the client workstation's own files. This meant that users had access to certain applications only from particular clients. The enhancements made to the public applications allow for enhanced flexibility, allowing a user to run an application from any client workstation with compatible hardware.

It is important to understand the issue of hardware compatibility. Although a user may be able to logon and start an application on any client workstation in the network, the client workstation must have the correct hardware to support the application. For example, suppose that a graphics application requires an SVGA graphics adapter in order to run correctly. A user may run this application on different clients, provided that each client has an SVGA graphics adapter. However, if the user logs on to a client with a VGA graphics adapter and attempts to run the application, the application will fail.

Application roaming is accomplished through a two-stage process.

  1. The first stage provides a hardware affinity by using the WorkSpace On-Demand client's network hardware address to associate a hardware image with a specific client. This software is loaded across the network from the WorkSpace On-Demand server to the WorkSpace On-Demand client.
  2. The second stage provides a user affinity by employing the user ID to specify a user's unique applications and the environment required to support them. This environment includes the PATH , LIBPATH and DPATH statements as well as the environment variables required to execute those network-public applications to which the end-user has access. This information is dynamically loaded from the WorkSpace On-Demand server to any WorkSpace On-Demand client from which the user logs on.

Note that the correct use of FIT files to redirect application file access at the user and application level is key to successfully implementing application roaming. Correct redirection of file access through FITs can provide both client- and user-specific configuration data for applications, thereby overcoming some of the issues of hardware compatibility and allowing users to run an application from different clients while maintaining their own personalized application configuration.