# 5 Understanding the Package Build Process

This chapter contains the following topics:

## 5.1 How the System Builds Packages (Release 9.1 Update 5)

This section discusses:

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

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

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

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

### 5.1.1 How the System Builds a Full Server and Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full server and client package. The beginning of each step states whether the process occurs on the client machine or on the enterprise server.

1. Client: Server Package UBE (R9621S) initiates the server package build.

2. Client: The system creates the package build directories on the deployment machine.

3. Client: The system initiates the connection with the enterprise server.

4. Enterprise server: The system creates the directories on the Enterprise server and builds the list of objects from the F96225 table.

5. Client: The system copies the business function .c and .h from the deployment server check-in location to the enterprise server directories, source_checkin (.c files) and include_checkin (.h files). This is done to preserve a snapshot of the .c and .h files at the time of the build.

6. Client: The system compresses the res directory from the checkin location of the deployment server. Sends the res.cab to the enterprise server under the res_checkin folder.

7. Enterprise server: The system generates named event rules (NERs) on the enterprise server. The generated files get created in the source_checkin and include_checkin directories on the enterprise server.

8. Enterprise server: The system moves server-only .c and .h files to the source and include folders respectively on the enterprise server. If there is more than one server, then it moves the .c and .h files from the primary server to the other enterprise servers under the source and include folders.

9. Enterprise server: The system compiles business functions on the Primary enterprise server to generate .dll, .so, .sl, or .SRVPGM files. If there are multiple servers, the Primary enterprise server sends a message to the other servers to start the build of business functions.

10. Enterprise server: The system builds specs on the Primary enterprise server from Central Objects, placing the results in the package's spec tables, <table name>_<package name> (for example, F98710_DV910FA) in the database.

11. Enterprise server: If the client package was also selected, the system copies back the files from the source_checkin and include_checkin to the deployment server package directory's include and source directories.

12. Enterprise server: If client package was also selected, the system copies back res.cab from the res_checkin to the package directory. The client then uncompresses it into the <package name>\res directory.

13. The system waits for specs to finish and for dlls to finish building.

14. Enterprise server: When the dll and specs are finished, if the compress feature for server is enabled, then it compresses the .dll, .so, .sl, and .SRVPGM files on the enterprise servers. The Primary enterprise server also sends a message to all other servers to compress.

15. Enterprise server: The system moves the compressed files and the compress.inf file back to the deployment server under the <packagename>/<machine type> directory.

16. Enterprise server: The system moves the server log (svrpkgbuild.log) from each server to the deployment server under <packagename>\serverLogs directory.

17. Enterprise server: The system moves the files located under the text directory on each enterprise server to the deployment server under <packagename>\serverlogs\<server name>\text.

18. Enterprise server: The system moves the files located under the CompileLogs directory on each enterprise server to the deployment server under <packagename>\serverlogs\<servername>\CompileLogs.

19. Enterprise server: The system moves the generation of NER logs on the primary enterprise server to the deployment server under <packagename>\serverlogs\GenerateNER.logs.

20. If this is a server only package, the process is complete. However, if you have selected to build a client, the system also performs the next steps.

21. Client: The Client Package UBE (R9622C) runs to initiate the client package build.

22. Client: The system creates the package inf file.

23. Client: The .c and .h files are compiled using Busbuild.

24. Client: The specs are copied from the Central Objects package spec tables <table name>_<package name> (for example, F98710_DV910FA) into a local Oracle database, Oracle Enterprise Edition (OEE).

25. Client: The system waits for the business functions to compile and the spec build to complete.

26. Client: The system copies the generated NER .c and .h files back to the check in location.

27. Client: The system copies the bin32 and lib32 directories back to the check-in location if the business function build did not have any errors.

28. Client: The system compresses the directories on the deployment server if compression was selected.

### 5.1.2 How the System Builds an Update Server and Client Package

This is an overview of how the JD Edwards EnterpriseOne system builds an update server and client package. The beginning of each step states whether the process occurs on the client from where the build is performed or on the enterprise server.

1. Client: The Server Package UBE (R9621S) initiates the server package build.

2. Client: The system creates the package build directories.

3. Client: The system initiates the connection with the enterprise server.

4. Enterprise server: The system creates the directories on the enterprise server.

5. Enterprise server: The system builds the list of objects in the update package from the F96225 table on the enterprise server. The list of business functions, NER, and Table ER that are needed from the deployment server is built into a file called bsfnfile.txt. The list of bitmaps is found in bitmapfile.txt. Both files are moved back to the <package name>\work directory on the deployment server.

6. Client: The system opens the bsfnfile.txt for the list of .c and .h files to copy from the deployment server check-in location to the enterprise server directories: source_checkin (.c files) and include_checkin (.h files). This is done to preserve a snapshot of the .c and .h files at the time of the build.

7. Client: The system opens the bitmapfile.txt for the list of bitmaps to copy from the res directory check in location on the deployment server to the enterprise server res_checkin directory.

8. Enterprise server: The system generates named event rules (NERs) from the list in the update package. The generated files are created in the source_checkin and include_checkin directories.

9. Enterprise server: The system moves server-only .c and .h files to the source and include folders respectively. If there is more than one server, then it moves the .c and .h files from the primary server to the other enterprise servers under the source and include folders.

10. Enterprise server: The system copies the parent dlls from the parent package to the update package. It then uses this dll to compile the business functions for the update package. If there are multiple servers, the system sends a message to the other servers to start the build of business functions.

11. Enterprise server: The system builds specs from Central Objects, placing the results in the package's spec tables, <table name>_<package name> (for example, F98710_DV910UPD) in the database.

12. Enterprise server: If the client package was also selected, the system copies back the files from the source_checkin and include_checkin to the deployment server package directory's include and source directories.

13. Enterprise server: If client package was selected, the system copies back res bitmaps from the res_checkin to the deployment server in the <package name>\res directory.

14. The system waits for specs to finish and for dlls to finish building.

15. Enterprise server: When the dll and specs are finished, if compression was selected for the server, then the system compresses the .dll, .so, .sl, and .SRVPGM files on the enterprise servers.

16. Enterprise server: The system moves the compressed files and the compress.inf file back to the deployment server under the <packagename>/<machine type> directory.

17. Enterprise server: The system moves the server log (svrpkgbuild.log) from each server to the deployment server under <packagename>\serverLogs directory.

18. Enterprise server: The system moves the files located under the text directory on each enterprise server to the deployment server under <packagename>\serverlogs\<server name>\text.

19. Enterprise server: The system moves the files located under the CompileLogs directory on each enterprise server to the deployment server under <packagename>\serverlogs\<servername>\CompileLogs.

20. Enterprise server: The system moves the generation of NER logs on the primary enterprise server to the deployment server under <packagename>\serverlogs\GenerateNER.logs.

21. If this is a server only package, the process is complete. However, if you have selected to build a client, the system also performs the next steps.

22. Client: R9622C initiates the client package build.

23. Client: The system creates the package inf file.

24. Client: The system compiles the .c and .h files using Busbuild. Busbuild copies the dll from the parent package to build the update business functions into the parent package dll.

25. Client: The system copies the specs from the Central Object package's spec tables <table name>_<package name> (for example, F98710_DV910UPD) into TAM files located under the spec directory.

26. Client: The system waits for the business functions to compile and the spec build to complete.

27. Client: The system copies the generated NER .c and .h files back to the check in location.

28. Client: The system copies the bin32 and lib32 directories back to the check-in location if the business function build did not have any errors.

29. Client (optional): The system compresses the directories on the deployment server. This is only necessary if building an ESU. The client install process does not use the compressed update package files.

### 5.1.3 How the System Builds a Full Client-Only Package

This is an overview of how the JD Edwards EnterpriseOne system builds a full client-only package.

1. R9621S runs first and determines that this is a client-only package so R9622C runs and initiates the client package build.

2. The system creates the package build directories.

3. The system creates the INF file.

4. These directories and files are copied from the check-in location to the package name directory:

• res

• source (.c files)

• include (.h files)

• work

• bin32

• lib32

• obj

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.
5. Creates a local OEE database with all the central objects tables.

6. Copies the 17 central objects tables into the created local OEE database.

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

8. The business services are built.

9. Any features that were included in the package are built.

10. The system copies any changed/new files from the include, source, bin32, lib32, and obj folders of the package to the path code check-in location.

11. The system compresses the directories.

### 5.1.4 How the System Builds an Update Client-Only Package

This is an overview of how the JD Edwards EnterpriseOne system builds an update client-only package.

1. R9621S runs first and determines that this is a client-only package so R9622C runs and initiates the client package build.

2. The system creates the package build directories.

3. The system creates the INF file.

4. For each object in the Package Build History table (F96225), the system retrieves the information from the Central Objects and adds it to the TAM specification files.

5. The system copies the associated .c, .h, and .hxx files for the selected objects from the check-in location on the deployment server to the package's directory on the deployment server.

6. The JD Edwards EnterpriseOne BusBuild program runs. NER is generated from the list of objects. The bin32 and lib32 dll is then copied from the parent package to the update package's bin32 and lib32 directories. The system compiles the business function objects in the package. The updates are then in the bin32 and lib32 directories of the update package.

7. If the build machine is not the deployment server, the system copies the parent package's local database from the spec directory to the build machine. The attach and detach of the parent package's local database can only occur on a local machine and not across the network. The specs from the update package are then merged into this parent package's local database and the database is copied back to the deployment server parent package directory. If the build machine is the deployment server, then the merge of the update objects happens to the parent package specs.

8. The system copies the bin32, lib32, obj, source, and include files from the update package to the parent package directory on the deployment server.

9. The system builds any features included in the package.

10. If compression was selected, the system compresses the directories.

## 5.2 Server Packages

This section discusses:

• A description of server packages.

• Primary server

• Jde.ini settings for server package builds.

• Spec.ini settings.

• Source code for Solaris servers.

### 5.2.1 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 Central Objects to the database package tables.

• 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).

### 5.2.2 Primary Server (Release 9.1 Update 5)

For an enterprise server build, there may be more than one enterprise server on which to build the server package. If there are multiple servers, one of these servers must be designated as the primary server.

The primary server controls the builds of the other enterprise servers. All source and include files are moved from the deployment server to the primary enterprise server. The primary server then moves only the server-only business function source and include files to the other enterprise servers.

The primary server generates the NER, and builds the specs from Central Objects into the package database tables. Then it sends a message to the other enterprise servers to compile the business functions. It waits for all the servers to finish and then sends a message to compress, if compression was selected. The primary server is the only server to communicate with the client machine.

### 5.2.3 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:

Setting Value Purpose
Build Area /usr/jdedwards/E900/packages Indicates the location on the server where the package will be built.
Optimization Flags +02 (default for HP-UX)

-02 (default for AIX and Solaris)

Varies, depending on the platform. The system uses these compile flags to build business functions in Release mode. You should not change these flags.
DebugFlags -g -D_DEBUG _DJDEDEBUG (default for HP-UX)

-g -qfulpath -qdbextra -D_DEBUG -DJDEDEBUG (default for AIX)

-g -D_DEBUG -DJDEDEBUG (default for Solaris)

Varies, depending on the platform. The system uses these compile flags to build business functions in Debug mode. You should not change these flags.
InliningFlags blank (default) Indicates whether the IBM i uses inlining. Enter Yes to select inlining on the IBM i. Enter No to turn it off. This flag is blank or ignored for non-IBM i servers.
DefineFlags -DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_HPUX-SOURCE (default for HP-UX)

-DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT (default for AIX)

-DKERNEL -DPRODUCTION_VERSION -DNATURAL_ALIGNMENT -D_SUN-SOURCE (default for Solaris)

Indicates the Kernel Production Version of the source for HP-UX, AIX, and Solaris.
CompilerFlags -Aa +w1 +z -c (default for HP-UX)

-qalign=natural -qflag=I:I -c (default for AIX)

-qspill=1024

-misalign -KPIC (default for Solaris)

Varies, depending on the platform.

The spill flag sets the stack space when business functions are compiled. Typically, 1024 is adequate space to compile the delivered business functions.

OSReleaseLevel +DAportable

-q32 (for AIX)

Indicates the release level for which you are compiling the package. You should not change these flags.
LinkFlags -b -z (default for HP-UX)

-bl:/<your system directory>/bin32/functlist.imp -bM:SRE -bexpall -brtl -lc -bnentry -L. L/usr/<your system directory>/lib -ljdelib -ljdekrnl -ljdenet -bloadmap:loadmap (default for AIX)

-G -L$(ORACLE_HOME)/lib (default for Solaris) shared -z muldefs -melf_i386 -L/JDEdwards/e900/system/lib -ljdesaw (Linix-64 bit) Varies, depending on the platform. The system uses these flags to link business functions. You should not change these flags. LinkLibraries blank (default) Indicates the libraries to which business functions are linked. (Applies to Windows and IBM i servers only.) SimultaneousBuilds 0 (unlimited) (default) any integer (number of simultaneous builds) Indicates the number of DLLs that can be built at a time. Zero means that all will be built simultaneously. Qname queue name Applies to IBM i only. Specify a queue name if you want the jobs for building dlls to go to a queue other than the default queue. <compiler values> Any compilers installed on the system will be retrieved from the registry and shown in a pull-down list. (Microsoft Windows platform) Indicates the compiler level to use for builds. For more information on the supported versions of Visual Studio, see the Visual Studio Requirements for Microsoft Windows-based Enterprise Servers section in the JD Edwards EnterpriseOne Tools Server Manager Guide. DeployWaitInMinutes any integer (number of minutes) Indicates the number of minutes to wait for an update or full package to deploy. ### 5.2.4 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: Setting Value path code_Package Indicates the name of the package. path code_DataSource Indicates the database data source that is used to retrieve the spec information. ### 5.2.5 Source Code for Solaris Servers The 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 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. ## 5.3 Workstation Packages This section discusses: • Workstation installation. • Building specifications and business functions. • Defining the compiler level. • Verifying UNICODE settings. • Package INF files. ### 5.3.1 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. ### 5.3.2 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. ### 5.3.3 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=10  VisualStudioVersion=9  Use the first setting if you are using the Microsoft Visual C++ 2010 compiler and the second setting if you are using the Microsoft Visual C++ 2008 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. For more information on how to update this setting using Server Manager, as well as the supported versions of Visual Studio, please see the Visual Studio Requirements for Microsoft Windows-based Enterprise Servers ### 5.3.4 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 primary enterprise server and 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. ### 5.3.5 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] • [Language] #### 5.3.5.1 [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. Item Purpose SPathcode=\\MachineName\E900\PACKAGE\ DV900FA Indicates the location of the package that the package builds for workstation installation. The default value for this path is the path code directory over which you built the package. You can change this setting if you want to use a different package. SSYS=\\MachineName\E900\SYSTEM Indicates the location of the system directory that the package builds for workstation installation. The default value for this path is the system directory that is associated with the path code over which you built the package. Normally, this directory is subordinate to the release share name (E900). This item appears only when included in the package. SPathcodeDATA=\\MachineName\E900\ DV900\PACKAGE\DATA Indicates the location of the Supported Local Database that the package builds for workstation installation. The default value for this path is the data directory that is subordinate to the path code over which you built the package. This item appears only when included in the package. #### 5.3.5.2 [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). Item Purpose DPathcode=%INSTALL\path code Indicates the destination directory for the package. DSYS=%INSTALL\system Indicates the destination directory for system files. This item appears only when included in the package. DPathcodeDATA=%INSTALL\path code\data Indicates the destination directory for the database. This item appears only when included in the package. #### 5.3.5.3 [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. Item Purpose Pathcode1=Y,$Spathcode\bin32, $Dpathcode\bin32 Indicates the bin32 directory that is subordinate to the path code. Pathcode2=Y,$Spathcode\spec, $Dpathcode\spec Indicates the spec directory that is subordinate to the path code. Pathcode3=Y,$Spathcode\include, $Dpathcode\include Indicates the include directory that is subordinate to the path code. Pathcode4=Y,$Spathcode\lib32, $Dpathcode\lib32 Indicates the lib directory that is subordinate to the path code. Pathcode5=Y,$Spathcode\obj, $Dpathcode\obj Indicates the obj directory that is subordinate to the path code. Pathcode6=Y,$Spathcode\source, $Dpathcode\source Indicates the source directory that is subordinate to the path code. Pathcode7=Y,$Spathcode\work, $Dpathcode\work Indicates the work directory that is subordinate to the path code. Pathcode8=Y,$Spathcode\make, $Dpathcode\make Indicates the make directory that is subordinate to the path code. Pathcode9=Y,$Spathcode\res, $Dpathcode\res Indicates the res directory that is subordinate to the path code. Pathcode10=Y,$Spathcode\sbf.cab, $Dpathcode\java Indicates the java directory that is subordinate to the path code. SYS=Y,$SSYS\System.cab, $DSYS Indicates the compressed system database that the package build generates. PathcodeDATA=Y,$SpathcodeDATA\data.CAB, $DpathcodeDATA Indicates the compressed data database that the package build generates. #### 5.3.5.4 [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  #### 5.3.5.5 [Components] These settings indicate the location of the foundation, production, and development objects, as well as the database files. Item Purpose Production Objects=APPL_PKG1, APPL_PKG2, APPL_PKG3 Indicates the location of production objects. Development Objects=APPL_PKG4, APPL_PKG5, APPL_PKG6, APPL_PKG7, APPL_PKG8, APPL_PKG9 Indicates the location of development objects. Foundation=SYS Indicates the foundation location. Data=pathcode DATA Indicates the database location. #### 5.3.5.6 [Typical] This section describes the setting for a typical development user. Item Purpose Name=Development Indicates that the package is for a development user. Description=Install the development objects Indicates the package description. Components=ProdObj, DevObj, Foundation, Data Indicates that the package should contain both production and development objects, as well as the database and foundation. #### 5.3.5.7 [Compact] This section describes settings for a typical production user. Item Purpose Name=Production Indicates that the package is for a production user. Description=Install the production objects only Indicates the package description. Components=Production Objects, Foundation, Data Indicates that the package should contain only production objects, as well as the database and foundation. #### 5.3.5.8 [Attributes] This section contains information about the current release, global tables, specification and help files, and the jde.ini file. Item Purpose PackageName=DV900FA Indicates the name of the package. PathCode=DV900 Indicates the path code for which the package is being built. Built=Build Completed Successfully Indicates the package status. A status of 50 or 70 means that the package is ready for installation. PackageType=Full Indicates the package type: full or update. SPEC_FORMAT=XML Indicates the format for the specifications. Release=E900 Indicates the current release, which determines the setup.inf file to use in building the jde.ini for the workstation. The release is also used to determine paths for system and helps. BaseRelease=B9 Indicates the current base release. SystemBuildType=RELEASE Indicates the type of build: DEBUG or RELEASE. This option is retrieved from owver.dll. MFCVersion=6 Indicates the version of the MFC compiler. SpecFilesAvailable=Y Indicates that specification files are available to merge or copy. This option is always set to Y for full and update packages. DelGlbTbl=Y Indicates whether to delete global tables when installing. This option is set to Y for full packages. For update packages, this option is set to Y only if the objects include a table object. ReplaceIni=Y Indicates whether to delete the existing jde.ini file when installing, and then create a new one. This option is set to Y for full packages. For update packages, the user must specify during package build definition whether to replace the jde.ini file. AppBuildDate=Mon Jul 20 11:22:22 2008 Indicates the date and time when the package was built. Full packages always have this date. This option is blank when no objects are included in the package. FoundationBuildDate=Wed Jun 03 15:08:34 2008 Indicates the date and time when the foundation was built.The date is retrieved from owver.dll. Full packages always have this date. This option is blank when no foundation location is specified in the package. DataBuildDate=Wed Jun 03 15:08:34 2008 Indicates the date and time when the database file was built. Full packages always have this date. This option is blank when no database location is specified in the package. DeploymentServerName=DENMLSAN222 Indicates the name of the deployment server. Location=DENVER Indicates the location of the deployment server. DeploymentStatus=Approved Indicates the package deployment status. PackageDescription=Development full package A Indicates the package description. Icon Description=JDEdwards Describes the desktop icon. Default Environment=DV900 Indicates the default environment. AllPathCodes=Y Indicates that a package for *ALL path codes exists when set to Y. Spec= Indicates the format of the specifications with these values: • XML_RDBMS Use this setting when XML specs are in an RDBMS (full package). • XML_TAM Use this setting when XML specs are in TAM format (update package). Language Lists the languages in the package using language codes and separated by commas. #### 5.3.5.9 [Oracle Databases] This section contains information about the Oracle databases. Item Purpose JDELocal_DV900=ORACLE Indicates the local Oracle database. SPEC_DV900FA=ORACLE Indicates the Oracle database. 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

#### 5.5.2.3 [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:

Item Purpose
FileName The name of the destination INI file.
Directory The location of the destination INI file.
Section The name of the section in the destination file.
Key The name of the key within the section of the destination file.
Value The value to be written to the key of the destination file.
Action The action to take regarding the INI entry:
• 0 means create the INI entry.

• 1 means create the INI entry only if it does not already exist.

• 3 means create the INI entry or append to the existing entry.

#### 5.5.2.4 [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:

Item Purpose
Compression An option that indicates whether the fileset is compressed.
Source Directory The source location of the fileset.
FileName The name of the CAB file for the fileset.
Target Directory The target location into which the fileset will be placed.

#### 5.5.2.5 [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:

Item Purpose
Directory The directory where the shortcut is created.
Name The name of the link file for the shortcut.
Target The name of the executable file for the shortcut.
Arguments Any command line arguments for the shortcut.
Description A description of the shortcut.
HotKey A hot key that launches the shortcut.
Icon The shortcut icon and location.
IconIndex An index of the icon if the icon is inside an image list.
ShowCmd A command for the application window, with these value options:
• 0 means show the window normal-sized.

• 3 means show the window maximized.

• 7 means show the window minimized; not active.

WkDir The working directory for the shortcut.

#### 5.5.2.6 [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:

Item Purpose
Source Directory Source location of the executable for running the third-party application.
Description Description of the third-party application.
Synchronous/Asynchronous An option that indicates whether the third-party application can be installed in parallel (synchronous) or must be installed serially (asynchronous).
Execute Before/After An option that indicates whether the third-party application installation is run before or after JD Edwards EnterpriseOne is installed.
FileName The name of the file that launches the third-party application.

#### 5.5.2.7 [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

Item Purpose
DataSource Name The name of the ODBC data source.
DataSource Driver The driver that is used for the data source.