What Is an Application?



An application is a platform-independent repository for a group of related components, such as procedures, Master and Access Files, data files, HTML files, PDF files, and image files. It provides an area on the server that both confers a unique identity on the application components and facilitates the sharing of components across applications in an organized manner. This construct also simplifies the process of moving a user application from one platform to another and of deploying PC-developed applications.

These components are physically grouped together on an application-by-application basis for run-time execution. This physical grouping can be within an application under a common root or a mapping to an application anywhere in the file system. The physical application or mapped name is referred to as the application name in this document. A comprehensive set of application (APP) commands are provided to control/manipulate the application components, as well as to facilitate applications that can be written and deployed to any platform.

The physical location of an application and its components is determined by a configuration parameter called approot. This parameter is set at installation time and stored in the server configuration file, edaserve.cfg. The default value is dependent on the platform, relative to the install ID home directory, where applicable, as indicated in the following chart.

Application directories can be nested. A nested application directory is an application created within a higher-level application. For more information. see Managing Applications and Paths.

You can also create a home application directory for each user. Providing a user home application gives each user a place where he has full control to create, change, and run his applications. For more information, see Managing Applications and Paths.

The various operating systems on which the product runs have their own behaviors for physical files and how directories or components are referenced. In addition, some are case sensitive and some are not. For example, on Windows, the files abc and ABC refer to the same file, regardless of how it is stored on disk (aBc, for example). However, on UNIX they are all different files. Additionally, z/OS under PDS deployment and OpenVMS ODS2 make file names uppercase when they are actually saved but they can generally also be referenced in lowercase or mixed case after they have been created. Some operating systems also allow spaces in file names and some do not. To co-exist within the various platforms on which the product runs, the product rules are to either always use APP commands or product tools such as the Web Console to create apps for application files (which will create them in the appropriate case), or to use lowercase names with external tools (such as mkdir myapp and vi mytest.fex), as they will save appropriately and work within the APP framework. Additionally, spaces in file names are not allowed. The use of external tools is also discouraged, as they may not act in the same way as internal tools.



Default Value for approot

z/OS PDS Deployment


z/OS HFS Deployment








IBM i (formerly known as i5/OS)




Two applications are provided during installation: a default application called baseapp and an application in which you can generate legacy sample files called ibisamp. In addition, when you connect to the server, a temporary directory called foccache is added as the first directory in the search path. When you want to be able to reuse data within the same browser session, you can store the data in the form of a HOLD, SAVE, or SAVB file in the foccache directory. As long as the browser session remains active, the files stored in the foccache directory can be referenced in requests.

Access to a particular application component can be explicit or implicit. Implicit access is dependent upon the search path in effect at the time of execution. The search path always includes the default application, baseapp. There is no need to explicitly declare this application.

You can change the search path from the Web Console, from the Data Management Console, or from within your application code. You can also change the search path temporarily to add application names to the beginning or end of an existing search path. APP commands are described briefly in Application Commands Overview and in detail later in this chapter.

In addition to explicit APP names under APPROOT or an APP MAP command, which might look like myapp/myproc, there are also special reference names for internal locations that may be useful. They are:

Reference Name



Current directory location. For server use this is the EDACONF edatemp agent directory (that is, ts000001, where 000001 is tscomid of the agent). For PDS Deployment, this is a temporary HFS location. For edastart -t, -x and -f uses, this is the current user directory.


EDAHOME installation location.


EDACONF configuration location.

While the EDAHOME and EDACONF catalog locations are internally already on a server search path, special handles such as these allow you to explicitly reference names of the form _edahome/catalog/sysapps, which is one of a number of internal catalog tables.

Note: For platforms that support the Universal Naming Convention (UNC), you can specify a network drive for approot. The UNC must be:

Generating Samples and Tutorials

You can generate several types of sample files and save them in an application in order to run sample procedures and test features and configurations.

The Web Console Applications page has a button named Tutorials, which you can click to open the Create Tutorial Framework page. You can also right-click an application folder and select New, then Tutorials, from the context menu.

Following is the list of available tutorials.

  • WebFOCUS - Retail Demo (includes Rserve demo if Rserve is configured)
  • WebFOCUS - SSAS Cube Join Demo
  • WebFOCUS - State Population Demo
  • WebFOCUS - Star Schema with Variable Data
  • WebFOCUS - Custom SQL Security Provider
  • DataMigrator - General
  • DataMigrator - Iterator
  • DataMigrator - File Listener
  • DataMigrator - Star Schema
  • Create Legacy Sample Tables and Files

In the past, a static application directory named ibisamp was created and pre-populated with a number of classic sample/demo files from past releases. The ibisamp folder is still created as part of the base installation process, but it is no longer automatically populated.

The current tutorial options have a wider variety of demos, but only load when selected. The classic sample/demo files are still available by choosing Create Legacy Sample Tables and Files from the Tutorial drop-down list.

Because the change is implemented at the folder level, you can choose to continue using ibisamp as the location for creating the legacy files, or you can select any other folder. The drop-down option for Legacy samples creates most, but not all, of the sample files that used to be in ibisamp. Some of the prior files were actually DataMigrator-related, and those have been moved to their own tutorials.

Under z/OS PDS Deployment there are some additional restrictions. The z/OS PDS JSCOM Listener option must have been selected at installation time. The PDS JSCOM option also co-installs some HFS source files that are used by the various create options. If the HFS files for a z/OS PDS Deployment are not present, request to create a tutorial will produce a specific HFS files not found message. Note that not all tutorials are implemented for z/OS, and those will produce a not implemented message, if selected.