Understanding the Package Build Process

This chapter discusses:

• How the JD Edwards EnterpriseOne system builds packages.

• Server packages.

• Workstation packages.

• Files created by the build process.

• Features.

How the System Builds Packages

This section discusses:

• How the JD Edwards EnterpriseOne system builds a full client package.

• How the JD Edwards EnterpriseOne system builds an update client package.

• How the JD Edwards EnterpriseOne system builds a full mobile package.

• How the JD Edwards EnterpriseOne system builds an update mobile package.

• How the JD Edwards EnterpriseOne system builds a full server package.

• How the JD Edwards EnterpriseOne system builds an update server package.

How the System Builds a Full Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full package. The JD Edwards EnterpriseOne system:

1. Creates the package build directories.

2. Creates the INF file.

3. Copies these directories and files from the check-in location to the package name directory:

   • res

   • source (.c files)

   • include (.h files)

   • work

   • make

   • bin32

   • lib32

   • obj

   • mobileDB

   • pack

   • spec

   • mobilespec

   • pkgspec

   Note. If you select to build business functions with the package build, the system does not copy bin32, lib32, and object (.obj) files because Oracle's JD Edwards EnterpriseOne BusBuild program creates them.

4. Creates an OEE or SSE database with all the central objects tables.

5. Copies all the central objects data into the created database.

6. Runs the JD Edwards EnterpriseOne BusBuild program to compile and link the business functions that create the DLLs in the bin32 directory, the objects in the obj directory, and the libraries in the lib32 directory.

7. Copies the files from the include, source, bin32, lib32, and obj folders of the package to the path code check in location.

8. Compresses the directories.

How the System Builds an Update Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds an update package. The JD Edwards EnterpriseOne system:

1. Creates the package build directories.

2. Creates the INF file.

3. For each object in the Package Build History table (F96225), retrieves the information from the relational database and adds it to the TAM specification files.

4. Copies the associated .c, .h, and .hxx files for the selected objects from the check-in location to the package build area.

5. Runs the JD Edwards EnterpriseOne BusBuild program to update the DLLs in the bin32 directory, the objects in the obj directory, and the libraries in the lib32 directory.

6. Copies the specs and files in the include, source, bin32, lib32, and obj folders of the update to the parent package.

How the System Builds a Full Mobile Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full mobile package. The first five steps are the same as a full client package. The JD Edwards EnterpriseOne system:

1. Creates the package build directories.

2. Creates the INF file.

3. Copies these directories and files from the check-in location to the package name directory:

   • res

   • source (.c files)

   • include (.h files)

   • work

   • make

   • bin32

   • lib32

   • obj

   • mobileDB

   • pack

   • java

   • spec

   • mobile spec

   • pkg spec

   Note. If you select to build business functions with the package build, the system does not copy bin32, lib32, and object (.obj) files because the JD Edwards EnterpriseOne BusBuild program creates them.

4. Builds the local spec repository based on the central objects.

5. Runs the JD Edwards EnterpriseOne BusBuild program to compile and link the business functions that create the DLLs in the bin32 directory, the objects in the obj directory, and the libraries in the lib32 directory.

6. Builds the mobile specs.

7. Builds the mobile DB (databases).

8. Builds the mobile.inf file.

9. Compresses the package.

How the System Builds an Update Mobile Package

The process for creating a mobile update package is similar to creating a regular update package. A mobile update package is created automatically based on the parent package. If the selected parent package was marked as mobile, a mobile update package is automatically built for every update package.

How the System Builds a Full Server Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full server package. The JD Edwards EnterpriseOne system:

1. Creates the package build directories.

2. Creates the INF file.

3. Copies these directories and files from the check-in location to the package name directory:

   • res

   • source (.c files)

   • include (.h files)

   • work

   • make

   • bin32

   • lib32

   • obj

   • mobileDB

   • pack

   • spec

   • mobile spec

   • pkg spec

   Note. If you select to build business functions with the package build, the system does not copy bin32, lib32, and object (.obj) files because the JD Edwards EnterpriseOne BusBuild program creates them.

4. Builds the local spec repository based on the central objects.

5. Generates named event rules (NERs) using the JD Edwards EnterpriseOne BusBuild program.

6. Creates package build directories on the enterprise server.

7. Copies all necessary source and include files from the package location to the enterprise server.

8. Compiles business functions on the server to generate .dll, .so, .sl, or .SRVPGM files.

9. Creates the spec repository in the specified server spec data source.

10. Copies specs from the build machine/deployment server to the spec data source.

11. Compresses the .dll, .so, .sl, and .SRVPGM files.

12. Copies the compressed files from the enterprise server to the deployment server.

How the System Builds an Update Server Package

The steps for a server update package are the same as the first five steps for building a full server package. However, specs for a server update package are merged directly with the live package during package deployment.

Server Packages

This section discusses:

• A description of server packages.

• The server package build process.

• Jde.ini settings for server package builds.

• Spec.ini settings.

• Source code for Sun servers.

A Description of Server Packages

A server package is a group of specification records, source files, header files, and compiled objects that are created on the enterprise servers. A server package is essentially the same as a client workstation package, with these exceptions:

• A server package does not include a Supported Local Database.

• Foundation code is not deployed as part of a server package.

• All specs are built directly into the specified spec data source.

  The specs are copied from the database on the build machine to the spec database data source.

• Some business functions (such as client only business functions) are not built on the server, and therefore are not included in a server package.

All application development takes place on workstations. Object-related files are stored on a single deployment server, and specs are stored in the central objects database on the database server. The application development life cycle is managed by Oracle's JD Edwards EnterpriseOne Object Management Workbench. This configuration enables you to partition business applications to an enterprise server. To ensure that modifications and enhancements that are developed on the workstation are reflected on the server, you must build a server package that contains those modifications and enhancements.

You use Oracle's JD Edwards EnterpriseOne Package Assembly (P9601) and Package Build Director (P9621) applications to assemble, define, build, and deploy server packages. After defining and building a server package, you can deploy it to an enterprise, logic, or application server by using Oracle's JD Edwards EnterpriseOne Deployment Director program (P9631).

The Server Package Build Process

Although creating a server package is identical to creating a client workstation package, you create each for different purposes. Server packages are necessary to transfer specifications and business functions to the enterprise servers.

Oracle's JD Edwards EnterpriseOne Package Build program (P9621) provides these benefits for building server package builds:

• Provides complete integration with client workstation packages.

• Builds a package on multiple servers simultaneously.

• Builds individual package components simultaneously on the server.

• Builds a package on one enterprise server and deploys to another server of the same type.

• Creates history records to enable monitoring and to provide restart capabilities for packages that do not deploy successfully.

• Creates compressed files and loads them onto the deployment server for easier mastering to a CD, or for deploying to another server of the same type.

• Supports both full and update packages.

• Provides the capability to specify a central spec repository for all enterprise and web application (WAS) servers to share.

Because server packages are assembled and defined in the same way as client workstation packages, you can assemble a server package using the JD Edwards EnterpriseOne Package Assembly program (P9601), and build the server package using the JD Edwards EnterpriseOne Package Build program (P9621), at the same time that you assemble and build client workstation packages.

After you assemble the server package and define the package build, these events occur:

1. The system starts a batch application that copies the central objects from the RDBMS to the spec repository on the build machine. The created repository is then copied to the deployment server.

2. On the build machine, the system starts another batch application for the server package.

3. This batch application calls a business function, which in turn calls the server package build engine.

4. The build engine uses the records that the Package Assembly and Package Build Director programs create to:

   • Transfer all business function source and header files to the server.

     At this time, the build engine reads the Object Librarian Master table (F9860) to determine the DLL to which each module belongs. For the JDBTRIG library, a special function is called to direct the trigger library to which the module belongs. In this case, the system does not use the Object Librarian Master table.

   • Start a build master process on the server when the source files for all business functions are transferred.

     This build master starts one or several individual build processes simultaneously. Each DLL has its own build process. The jde.ini file indicates the number of processes that can run simultaneously on a non-iSeries platform. This function is performed by the QBATCH subsystem on an iSeries platform.

   • Move the process to another server if one was specified during the package build process.

     The process transfers and builds all components on that server.

   • Create the spec repository in the spec database data source and copy the spec files from the build machine to the spec repository.

   • Check the status of each build piece on each server after the build process has begun on all servers.

     History records are updated as the statuses change.

   • Compress the package components and transfer the compressed files back to the deployment server when the building is complete.

     This happens only if you specify that the system compress the files when it builds the package. This process is repeated for all servers.

Jde.ini Settings for Server Package Builds

If the server package includes business functions, the Build Settings within Server Manager apply to the package. This table describes various build settings:

Spec.ini Settings

All JD Edwards EnterpriseOne servers and WIN32 clients require a spec.ini file to retrieve the package and spec data source information. This file is created by the Package Build process. It resides in the spec directory.

This table describes the settings within the SPEC LOCATIONS section of the spec.ini file:

Source Code for Sun Servers

The Sun Solaris compiler expects a newline character at the end of every source code file that it compiles. If the compiler does not find this newline character, it rejects the line and displays a warning message. In some cases, this line rejection and message might cause the package build to fail.

If you develop custom modifications on Sun servers that use the Solaris operating system, you must ensure that this newline character is present in the compiled source code before you assemble, define, and build packages that contain the modifications. This step helps ensure that the package build process finishes successfully.

In some cases, the system automatically adds the newline character, and you do not need to add it manually. If you edit source code in the UNIX environment using an editor such as VI or emacs, these editors automatically add the newline character. Also, all of the source code files for business functions include the newline character.

However, editors that are included with PC workstations typically do not add the newline character. Therefore, if you edit source code on a PC workstation and then transfer the file to the server for compiling, verify that the newline character exists in the source code.

See Also

JD Edwards EnterpriseOne Tools Release 8.98 Server Manager Guideon the Update Center.

Workstation Packages

This section discusses:

• Workstation installation.

• Building specifications and business functions.

• Defining the compiler level.

• Verifying UNICODE settings.

• Package INF files.

Workstation Installation

A typical full workstation installation takes more than 1.4 GB of disk space and can take 10 to 30 minutes to install, depending on network traffic. A workstation configuration contains the full suite of applications, including those that the user rarely or never uses, but all applications are available immediately.

Building Specifications and Business Functions

If you build a full client package that includes both business functions and specifications, add the following setting to the [INSTALL] section of the workstation jde.ini file on the computer that you use to build the packages:

WaitForBusbuild=Y/N

A Y means that business functions are built after all the specs are complete. The system builds the specifications and business functions sequentially instead of simultaneously.

An N means that specs and business functions are built simultaneously, which can speed up the build process.

Defining the Compiler Level

If you have more than one version of Microsoft Visual C++ on your machine, add one of the following settings to the [JDE_CG] section of the workstation jde.ini file on the computer that you use to build the packages:

VisualStudioVersion=6
VisualStudioVersion=7
VisualStudioVersion=8

Use the first setting if you are using the Microsoft Visual C++ v6.0 compiler, the second setting if you are using the Microsoft Visual C++ 2003 v7.1 compiler, and the third setting if you are using the Microsoft Visual C++ 2005 v8.0 compiler. If more than one supported compilers have been installed on the computer that you use to build packages and the VisualStudioVersion is not defined in the jde.ini, the highest level compiler will be used to perform the build.

Verifying UNICODE Settings

If you are upgrading from Xe and you have modified any interactive or batch applications that contain NERs and that are language-enabled, you must ensure that the following setting is in the [INSTALL] section of the workstation jde.ini on the computer that you use to build the packages:

Unicode Conversion Codepage=<code_page_value>

In this setting, code_page_value is a valid value for the code page of the language-enabled application that contains NERs. For example, for Korean language the value would be:

Unicode Conversion Codepage=ksc-5601

Note. If you are a language customer but have never added NERs to your applications, then you are not required to have this setting. Also note that LocalCodeSet=<value> is no longer used in releases subsequent to Xe.

Package INF Files

The Package INF file is essentially the interface between the package build and Oracle's JD Edwards EnterpriseOne Workstation Installation program. The INF file defines the components that are included in the package, the source and destination paths for those components, and the attributes that are needed to install the package.

The INF file is created during the package build process and is stored in its own package_inf directory, based on the release master directory. JD Edwards EnterpriseOne Workstation Installation reads the INF file for the package that it is installing to determine which components are loaded to a workstation, as well as their locations.

Here is a typical INF file for package DV900FA, which is full package A for the DV900 path code. This INF file includes these sections:

• [SrcDirs]

• [DestDirs]

• [FileSets]

• [FileSetsDescription]

• [Components]

• [Typical]

• [Compact]

• [Attributes]

• [Oracle Databases]

• [Start]

• [Desktop]

• [Environment]

• [Fonts]

• [Feature]

[SrcDirs]

The JD Edwards EnterpriseOne Workstation Installation program uses these settings to determine the source path from which information is copied. JD Edwards EnterpriseOne Package Build compresses these directories. JD Edwards EnterpriseOne Workstation Installation copies the compressed directories to workstations.

[DestDirs]

The JD Edwards EnterpriseOne Workstation Installation program uses these settings to determine the destination paths on the workstation. The process replaces %INSTALL with the user's computer configuration, which is set up in the User Display Preferences table (F00921) and the User Defined Codes Language Status table (F00051).

[Filesets]

These settings list the various source and destination directories that are subordinate to the path code for the package. Y equals compressed, and N equals not compressed. The source and destination directory names are preceded by an S and D, respectively.

[FileSetsDescription]

This section provides a text description for each fileset as shown in this example:

[FileSetsDescription]
DV9001=Business Function DLL Files
DV9002=Specification Files
DV9003=Include Files
DV9004=Library Files
DV9005=Object Files
DV9006=Source Files
DV9007=Work Files
DV9008=Make Files
DV9009=Resource Files
DV90010=SBF Source Files
SYS=Foundation Files
DV900DATA=Data Files

[Components]

These settings indicate the location of the foundation, production, and development objects, as well as the database files.

[Typical]

This section describes the setting for a typical development user.

[Compact]

This section describes settings for a typical production user.

[Attributes]

This section contains information about the current release, global tables, specification and help files, and the jde.ini file.

[Oracle Databases]

This section contains information about the Oracle databases.

Each of the databases listed, has its own section in the INF file as shown in this example:

[JDELocal_DV900]
SourceTableSpace=JDELocal
Server=127.0.0.1
UserID=SYSTEM
DataFileDestDir=$DDV900DATA\JDELocal_DV900.dbf
DumpFileDestDir=$DDV900DATA\JDELocal_DV900.dmp

[SPEC_DV900FA]
SourceTableSpace=MASTER
Server=127.0.0.1
DataFileDestDir=$DDV900\Spec\SPEC_DV900FA.dbf
DumpFileDestDir=$DDV900\Spec\SPEC_DV900FA.dmp

[START]

This section contains startup information:

[START]
ProgramGroupName=JDEdwards
Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_pgf\res\OneWorld.ico

[Desktop]

This section contains desktop information:

[Desktop]
Item1=System\Bin32\activConsole.exe, JDEdwards Solution Explorer, appl_pgf, res⇒\OneWorld.ico

[Environment]

This section contains environment information:

PathDV900=%INSTALL\DV900\bin32;
PathSys=%INSTALL\system\bin32;

[Fonts]

This section contains font information:

[Fonts]
Arial=Font\arial.ttf

[Feature]

This section describes information for any features that are included in the package. A feature is a set of files or configuration options that is included in a package for deployment to a workstation or server. This example provides an example of some features that might be included:

[Feature]
WEBDEVELF=\\DENMLSAN246\E900\Package_inf\Feature_inf\WEBDEVELF_1.INF
WEBDEVOC4J=\\DENMLSAN246\E900\Package_inf\Feature_inf\WEBDEVOC4J_1.INF
WORKFLOWF=\\DENMLSAN246\E900\Package_inf\Feature_inf\WORKFLOWF_1.INF

Files Created by the Build Process

This section discusses:

• Workstation package build

• Server package build

• UNIX server build

• Windows server build

• iSeries server build

Workstation Package Build

Business function dynamic linked libraries (DLLs) on workstations are grouped by related business functions. This grouping limits the size and number of procedures that are contained in each DLL. Grouping prevents memory allocation errors and avoids the platform limitations that can occur when you export too many procedures from the same DLL.

The production environment PD900/bin32 directory contains the DLLs that are created on the workstation. All of the business function source files are in the PD900/source directory.

Files Created by a Business Function Build

When you build a single business function through Oracle's JD Edwards EnterpriseOne Object Librarian, the Business Function Builder program uses the make (*.mak) file that is generated at runtime, and creates or copies these files and builds the business functions into their respective DLLs:

• Source file (*.c)

• Header file (*.h)

• Object file (*.obj)

You must use the jdecallobject API to call a business function from a business function.

These files are created for NER business functions:

• OBJNAME.c

• OBJNAME.h

• OBJNAME.obj

These files are created for table event rules:

• OBJNAME.c

• OBJNAME.hxx

• OBJNAME.obj

Server Package Build

Server package builds are used to move path code objects from the deployment server to enterprise server platforms. Server package builds are initiated when you create either full or update packages during package assembly. After you have assembled the package, you must select the server option during package definition, and select the relevant servers from the list of available servers in the screen that follows. When package definition is complete and the package has been activated, highlight the package and select Submit Build from the Row menu to start the server package build. When the server package build has finished successfully, you can deploy the server package.

To assemble a server package, use the foundation, database, and object information in package assembly to generate build information, specification files, and business function source for .c, .h, and .hxx files. After the server package build has generated these objects and placed them in the staging area, the system transfers the objects to each of the servers that is specified in the package definition. The system then directs the servers to compile the business function source code and generate the corresponding business function DLLs.

UNIX Server Build

This topic describes the files that the system creates when it builds business functions on a UNIX server.

Files Created by a Business Function Build

When you are building business functions, these groups of source files are actually compiled:

• NER business functions.

• Table event rules.

• C business function event rules.

When you are building business functions, these file types are supplied to the build process:

• Source files (.c)

• Header files (.h, .hxx)

When building business functions, the build process creates these file types:

• Object files (.o)

• Make files (.mak)

• Shared libraries (.sl, .so)

Shared libraries for business functions, which are equivalent to a DLL for a Windows workstation, are consolidated. Therefore, one shared library is created for each parent DLL in the Object Librarian - Status Detail table (F9861). If you are creating custom business functions, use a custom parent DLL instead of one of the parent DLLs that JD Edwards EnterpriseOne software provides.

Where Business Functions Are Stored

On a UNIX platform, related business functions are grouped into shared libraries. This grouping limits the size and number of procedures that are contained in each shared library. Grouping prevents memory allocation errors and avoids platform-specific limitations in the number of procedures that you can export per shared library.

The exact location of the package is determined by the Build Settings within Server Manager.

Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each shared library that is created on the enterprise server.

The directory structure looks like this example where the top directory represents the package name:

PD900FA

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

Each subdirectory contains the business function source files that belong to the shared library. All shared libraries are installed in the PD900/bin32 directory. The naming convention for the shared libraries is lib, followed by the name of the shared library subdirectory, followed by .sl (for HPUX) or .so (for AIX). An example is libccore.sl.

Specification Files

JD Edwards EnterpriseOne specifications are stored in an RDBMS. The database data source for this database is specified in the spec.ini file or is selected by the package build administrator during the server package build definition process. Package Build copies the specs directly from the build machine to the specified spec database. However, local cache (GLBLTBL, DDDICT, and DDTEXT) specification files are still created in TAM format. The contents in these files are destroyed when a new package is deployed.

Windows Server Build

This topic describes the files that the system creates when it builds business functions on a Windows server.

Files Created by a Business Function Build

When you are building business functions, these groups of source files are actually compiled:

• Business function event rules.

• Table event rules.

• C business function event rules.

When you are building business functions, these file types are supplied to the build process:

• Source files (.c)

• Header files (.h, .hxx)

When building business functions, the build process creates these file types:

• Object files (.o)

• Make files (.mak)

• DLLs (.dll)

Business function DLLs are consolidated, just as they are on the UNIX platform or workstation. Therefore, one shared library is created for each parent DLL in the Object Librarian - Status Detail table (F9861). If you are creating custom business functions, use a custom parent DLL instead of one of the parent DLLs that JD Edwards EnterpriseOne software provides.

Where Business Functions Are Stored

On Windows platforms, business functions are grouped into parent DLLs for related business functions. This grouping limits the size and number of procedures that are contained in each DLL. Grouping also prevents memory allocation errors and avoids platform-specific limits of exported procedures per DLL.

The exact location of the package is determined by the Build Settings within Server Manager.

Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each DLL that is created on the enterprise server.

The directory structure looks like this example where the top directory is the package name:

PD900

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

Each subdirectory contains all of the business function source files that belong to the DLL. All DLLs are installed in the PD900\bin32 directory. They have the same name as the DLL subdirectories, except that they have the .dll suffix.

Specification Files

JD Edwards EnterpriseOne specifications are stored in an RDBMS. The database data source for this database is specified in the spec.ini file or is selected by the package build administrator during the server package build definition process. Package Build copies the specs directly from the build machine to the specified spec database. However, local cache (GLBLTBL, DDDICT, and DDTEXT) specification files are still created in TAM format. The contents in these files are destroyed when a new package is deployed.

iSeries Server Build

This topic describes the files that the system creates when it builds business functions on an iSeries server.

Files Created by a Business Function Build

When building business functions, the server package build creates these file types in a library with the package name in the QSYS file system:

• *MODULES - Object files.

• *USRSPC - User spaces hold information about which .c files each business function DLL contains.

• *SRVPGM - Server programs are the DLLs on the iSeries.

• *FILE - Contains only logs about compiled business functions.

Where Business Function Source Members Are Stored

iSeries business function source and headers are now transferred to the Integrated File System (IFS). Server package build transfers objects to these subdirectories under the server package directory in the IFS for the iSeries.

The exact location of the package is determined by the Build Settings within Server Manager.

Subordinate to the package directory (PD900FA) is a source directory. This source directory contains subdirectories for each DLL that is created on the enterprise server.

The directory structure looks like this example where the top directory is the package name:

PD900FA

include

pack

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

spec

text

This table describes the files that are found in the directories:

Note. After an upgrade, existing iSeries server path codes must be rebuilt with the server package build to avoid problems building server package updates and manually re-linking business functions using the LINKBSFN program.

Specification Files

JD Edwards EnterpriseOne specifications are stored in an RDBMS. The database data source for this database is specified in the spec.ini file or is selected by the package build administrator during the server package build definition process. Package Build copies the specs directly from the build machine to the specified spec database. However, local cache (GLBLTBL, DDDICT, and DDTEXT) specification files are still created in TAM format. The contents in these files are destroyed when a new package is deployed.

Features

This section discusses:

• Defining features

• Feature INF files

Defining Features

In addition to objects, you can also add a feature to a package. A feature is a set of files or configuration options that must be copied to a workstation or server to support an application or another function. Like objects, features are included in a package and deployed to the workstations and servers that require the feature components.

For example, you might need to add these items to a package: ActiveX controls, a Supported Local Database for the Sales Force Automation feature, ODBC data sources for use with Open Data Access, or Microsoft Windows registry settings.

You define a feature by using the JD Edwards EnterpriseOne Package Assembly program (P9601). You can then add the feature to a package by using the JD Edwards EnterpriseOne Package Assembly program (P9601) and Package Build Director program (P9621).

Feature INF Files

When a package contains features, a section called [Features] in the Package INF file includes both the feature name and a pointer to the Feature INF file that is created for each feature in the package. These Feature INF files provide specifications that tell the installation program the actions to perform during the installation.

The Feature INF file can include these sections:

• [Header]

• [Registry]

• [INI]

• [FileSets]

• [Shortcut]

• [ThirdPartyApps]

• [ODBCDataSources]

This is a typical Feature INF file for which the sections contain specifications for each feature component.

[Header]

The header section contains general information about the feature and specifies the installation options for the feature.

The Required and InitialChoice entries are set using the three Feature Installation option settings (Required, Selected, Deselected) on the Feature Information form. When you select one of these three options, the system writes these values into the Required and InitialChoice entries in the feature INF file.

[Registry]

This section contains information about how the feature affects the Windows registry.

The settings for this section are displayed in this order:

Registry_no.=Root[value], Key, [prefix]Name, [prefix]Value

The following table contains a description of each variable:

[INI]

This section contains information about how the feature affects the jde.ini file.

The settings for this section are displayed in this order:

Ini_no.=FileName, Directory, Section, Key, Value, Action

The following table contains a description of each variable:

[FileSets]

This section contains information about additional files that must be installed for the feature to function correctly.

The settings for this section are displayed in this order:

Fileset_no.=Compression, SourceDirectory, FileName, TargetDirectory

The following table contains a description of each variable:

[Shortcut]

This section contains information about shortcuts that appear on the Windows desktop as part of the feature installation.

The settings for this section are displayed in this order:

Shortcut_no.=Directory, Name, Target, Arguments, Description, HotKey, Icon, IconIndex, ShowCmd, WKDir

The following table contains a description of each variable:

[ThirdPartyApps]

This section contains information about third-party products that are installed with the feature.

The settings for this section are displayed in this order:

ThirdPartyApp_no.=Source Directory, Description, Synchronous/Asynchronous, Execute Before/After, FileName

The following table contains a description of each variable:

[ODBCDataSources]

This section contains information about ODBC data sources that are installed with the feature.

ODBC data sources have two sections in the feature.inf. One section contains header information and the other contains the detail information. The feature.inf contains one header section listing all data source components that are included in the feature. For each data source that is listed in the header, a corresponding detail section exists. Only the header section is described in this table. For information about the detail section, see the documentation for the selected ODBC Driver.

The settings for this section are displayed in this order: DataSourceName=DataSourceDriver