5 Understanding the Package Build Process

This chapter contains the following topics:

Section 5.1, "How the System Builds Packages (Release 9.1 Update 5)"
Section 5.2, "Server Packages"
Section 5.3, "Workstation Packages"
Section 5.4, "Files Created by the Build Process"
Section 5.5, "Features"

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.

Client: Server Package UBE (R9621S) initiates the server package build.
Client: The system creates the package build directories on the deployment machine.
Client: The system initiates the connection with the enterprise server.
Enterprise server: The system creates the directories on the Enterprise server and builds the list of objects from the F96225 table.
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.
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.
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.
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.
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.
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.
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.
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.
The system waits for specs to finish and for dlls to finish building.
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.
Enterprise server: The system moves the compressed files and the compress.inf file back to the deployment server under the <packagename>/<machine type> directory.
Enterprise server: The system moves the server log (svrpkgbuild.log) from each server to the deployment server under <packagename>\serverLogs directory.
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.
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.
Enterprise server: The system moves the generation of NER logs on the primary enterprise server to the deployment server under <packagename>\serverlogs\GenerateNER.logs.
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.
Client: The Client Package UBE (R9622C) runs to initiate the client package build.
Client: The system creates the package inf file.
Client: The .c and .h files are compiled using Busbuild.
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).
Client: The system waits for the business functions to compile and the spec build to complete.
Client: The system copies the generated NER .c and .h files back to the check in location.
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.
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.

Client: The Server Package UBE (R9621S) initiates the server package build.
Client: The system creates the package build directories.
Client: The system initiates the connection with the enterprise server.
Enterprise server: The system creates the directories on the enterprise server.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The system waits for specs to finish and for dlls to finish building.
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.
Enterprise server: The system moves the compressed files and the compress.inf file back to the deployment server under the <packagename>/<machine type> directory.
Enterprise server: The system moves the server log (svrpkgbuild.log) from each server to the deployment server under <packagename>\serverLogs directory.
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.
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.
Enterprise server: The system moves the generation of NER logs on the primary enterprise server to the deployment server under <packagename>\serverlogs\GenerateNER.logs.
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.
Client: R9622C initiates the client package build.
Client: The system creates the package inf file.
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.
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.
Client: The system waits for the business functions to compile and the spec build to complete.
Client: The system copies the generated NER .c and .h files back to the check in location.
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.
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.

R9621S runs first and determines that this is a client-only package so R9622C runs and initiates the client package build.
The system creates the package build directories.
The system creates the INF file.
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.
Creates a local OEE database with all the central objects tables.
Copies the 17 central objects tables into the created local OEE database.
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.
The business services are built.
Any features that were included in the package are built.
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.
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.

R9621S runs first and determines that this is a client-only package so R9622C runs and initiates the client package build.
The system creates the package build directories.
The system creates the INF file.
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.
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.
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.
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.
The system copies the bin32, lib32, obj, source, and include files from the update package to the parent package directory on the deployment server.
The system builds any features included in the package.
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
DumpFileDestDir=$DDV900\Spec\SPEC_DV900FA.dmp

5.3.5.10 [START]

This section contains startup information:

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

5.3.5.11 [Desktop]

This section contains desktop information:

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

5.3.5.12 [Environment]

This section contains environment information:

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

5.3.5.13 [Fonts]

This section contains font information:

[Fonts]
Arial=Font\arial.ttf

5.3.5.14 [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\E910\Package_inf\Feature_inf\WEBDEVELF_1.INF
WEBDEVOC4J=\\DENMLSAN246\E910\Package_inf\Feature_inf\WEBDEVOC4J_1.INF
VS2010RT=\\DENMLSAN246\E910\Package_inf\Feature_inf\VS2010RT_1.INF

5.3.5.15 [Language]

This section describes information for all of the languages that were included in the package. This example includes simplified Chinese and German:

[Language]
LANGUAGE=CS,G

If there are no languages, then the value is blank:

[Language]
LANGUAGE=

5.4 Files Created by the Build Process

This section discusses:

Workstation package build
Server package build
UNIX server build
Windows server build
IBM i server build

5.4.1 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.

5.4.1.1 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

5.4.2 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.

5.4.3 UNIX Server Build

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

5.4.3.1 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.

5.4.3.2 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

PD900FA\source\CALLBSFN

PD900FA\source\CCORE

PD900FA\source\CDESIGN

PD900FA\source\CDIST

PD900FA\source\CFIN

PD900FA\source\CHRM

PD900FA\source\CMFG

PD900FA\source\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 HP-UX) or .so (for AIX). An example is libccore.sl.

5.4.3.3 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.

5.4.4 Windows Server Build

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

5.4.4.1 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.

5.4.4.2 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:

PD900FA\source\CAEC

PD900FA\source\CALLBSFN

PD900FA\source\CCORE

PD900FA\source\CDESIGN

PD900FA\source\CDIST

PD900FA\source\CFIN

PD900FA\source\CHRM

PD900FA\source\CMFG

PD900FA\source\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.

5.4.4.3 Specification Files

5.4.5 IBM i Server Build

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

5.4.5.1 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 IBM i.
*FILE - Contains only logs about compiled business functions.

5.4.5.2 Where Business Function Source Members Are Stored

IBM i 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 IBM i.

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:

Directory	Description
`PD900\include`	This is the location where .h and .hxx source files are located. These objects are taken from the server and built on.
`PD900\pack`	This folder is no longer used but is created for backwards compatibility.
`PD900\source`	This directory contains subdirectories that include the business function DLL names. Each subdirectory contains .c source for the business functions that are compiled and linked into the DLL.
`PD900\spec`	This folder is no longer used but is created for backwards compatibility.
`PD900\text`	This directory contains build text, status files and log files (.txt, .sts, .log) for business function DLLs and specification files. The text files contain information that is needed for the server package build. The text files also contain build directives for creating business function DLLs. The status files for specification files indicate whether a server package build was successful in converting pack files into spec files. The status files for business function DLLs indicate which .c source files were successfully compiled and linked. The log files created exclusively for business function DLLs contain the compiler commands used to build and link business functions. For the Microsoft Windows platform, the beginning of this file identifies the compiler used to perform the build.

Note:

After an upgrade, existing IBM i 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.

5.4.5.3 Specification Files

5.5 Features

This section discusses:

Defining features
Feature INF files

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

5.5.2 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.

5.5.2.1 [Header]

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

Item	Purpose
Feature=	Name of the feature.
FeatureType=	Type of feature.
Description=	Text description of the feature.
Required=	A setting that indicates whether installation of the feature is required.
InitialChoice=	A setting that specifies the default selections for features that the user can install.

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.

Feature Installation Option	Required	InitialChoice
Required	Y	Both
Selected	N	Both
Deselected	N	Custom