Working with Network Applications

---

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.

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:

• Client-specific applications are typically "middleware" applications that are launched during the client workstation's boot sequence. They are composed of generic application code, with certain configuration data that is unique to each client workstation, such as network addresses, SNA PU IDs and so on. An example of such an application is IBM Personal Communications/3270 Access Feature.
• User-specific applications are typically launched by the end user from the client's desktop. They are composed of generic application code with certain configuration data that is unique to each end user. An example of such an application is Lotus Notes.
• Hybrid applications exhibit characteristics of both the client- and user-specific categories. These applications include certain code that is launched during the client's boot sequence as well as individual application components that are launched by the end user. An example of such an application is Lotus SmartSuite for OS/2 Warp 4.

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:

• Generic code includes programs, dynamic link libraries or basic configuration files that are shared by all users of an application, and all clients on which the application is run. These files are always accessed in read-only mode by an application running on a client.
• Client-specific files are configuration files that define a client's SNA address and so on. These files are unique to a client workstation, but are still shared by those end users who use that client. In most cases, these files will be accessed in read-only mode, but in some circumstances, a client-specific file may require write access by the application.
• User-specific files are configuration files that define an individual user's working environment, mail preferences and so on. These files are unique to each end user. In most cases, these files will be accessed in read/write mode to enable users to customize their working environment

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

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.

---

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 .

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.

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.

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.

• Copy any client-specific or user-specific read-only files to the \IBMLAN\RPL\MACHINES\ client_name directory. In cases where these files contain unique settings for each client, you will need to devise a method of generating each file with the unique settings and placing it in the correct directory for the client to which it belongs.
• Within the IBMLAN\RPLUSER\ client_name directory tree, create an empty directory for the application and also for any subdirectories of that application directory that will be mapped using FIT entries. These directories will contain client-specific files that are updated by the application during execution. In some cases, these files may not be created until the application is run; so the directories must be created even though they are left empty. This is another instance where knowledge of the application's behavior becomes very important.
• Within the \IBMLAN\DCDB\USERS\ user_name directory, create an empty directory for the application. You should then copy any required configuration files to this directory. For example, you might copy the user's initial Lotus Notes ID and DESKTOP.DSK files here so that these files can be accessed by redirection through the FIT and modified as required by the user.

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:

• ? is resolved as the client's boot drive (typically Z:).
• <DCSERVER> is resolved as the OS/2 Warp Server domain controller.
• <USER> is resolved as the user name.
• <RPLBOOTSERVER> is resolved as boot server.
• <OS2VERSION> is resolved as the current OS/2 version being booted on the client workstation. This enables for different OS/2 versions to be managed on different clients by the same boot server.
• <MACHINE> is resolved as the client workstation name.

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.

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

• An application definition that simply invokes a command line
• An application definition for PM Camera

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:

• On the Invocation page in the Application Definition notebook, specify JAVA.EXE in the Command field.
• Type the name of the Java program you wish to run in the Parameters field.

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

 

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

---

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.