# 5 Understanding the Package Build Process

This chapter contains the following topics:

## 5.1 How the System Builds Packages

This section discusses:

• Understanding Package Build with 64-bit (Release 9.2.3)

• Building 64-bit Packages for Business Function Development (Release 9.2.3)

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

• How the JD Edwards EnterpriseOne system deploys the full server package.

• How the JD Edwards EnterpriseOne system deploys the server update package.

### 5.1.1 Understanding Package Build with 64-bit (Release 9.2.3)

The EnterpriseOne system can be either a 32-bit system or 64-bit system. The package can build with either of these systems, but also depends on what the Enterprise Server system bitness is. The Enterprise Server can only build in the bitness that the system is running. If the Enterprise Server is running a 32-bit system, then the Server Only package will build a 32-bit package. If the Enterprise Server is running a 64-bit system, then the Server Only package will build a 64-bit package.

For a Server/Client package when the Enterprise Server is 32-bit, the client package must either point to a 32-bit system (multi-foundation) or the default system of the deployment server must be 32-bit. For a Server/Client package when the Enterprise Server is 64-bit, the client package must either point to a 64-bit system (multi-foundation) or the default system of the deployment server must be 64-bit.

For a Client only package, the package can point to a 32-bit system or a 64-bit system using multi-foundation. In this case, it does not matter what bitness the Enterprise Server is.

The default system of the Deployment Server can be either a 32-bit or 64-bit system. It does not have to match the Enterprise Server, but the user will have to set up multi-foundation when selecting the foundation during package assembly. If the Enterprise Server is 64-bit and you are building a server/client package, then the foundation selected must be a 64-bit system. You select this in the Package Assembly application.

When building a package for the first time with a 64-bit foundation, the system starts a process to convert the include and source files in the repository, F98780R/F98780H, to 64-bit, include64, and source64. It inserts the include, source, include64, and source64 files into the repository. This is only done once. The F00942T-> emenvfu2 field is now set to 1 to indicate the files have been converted. Once this happens, when a package is built, the package contains both include, source, include64, and source64 files in the package. If the client foundation is 32-bit, then it uses the include and source to build bin32 and lib32 files with the include64 and source64 files existing in the package. If the client foundation is 64-bit, then it uses the include64 and source64 files to build bin64 and lib64 files with the include and source files existing in the package. If the Enterprise Server system is 32-bit, then it uses the checkin\include and checkin\source to build bin32 and lib32 files with the checkin\include64 and checkin\source existing in the package. If the Enterprise Server system is 64-bit, then it uses the checkin\include64 and checkin\source64 to build bin64 and lib64 files with the checkin\include and checkin\source existing in the package. During the client install, the include, source, include64, and source64 are delivered with the client package. During the deploy of the Enterprise Server, only the bin32 or bin64 are deployed. If the files were never converted, meaning a package was never built with a 64-bit foundation, then the package will not contain the 64-bit artifacts.

### 5.1.2 Understanding 64-bit Enablement with the Release Master (Release 9.2.4)

Tools Release 9.2.4 and beyond presents the ability to have a 64-bit only system. The Release Master application is used to indicate a 64-bit only system. When you have all pathcodes, the Enterprise system, and the client foundation converted to 64-bit, and enabled 64-bit in the Release Master, the package will only contain include64 and source64. The package will build the dlls with a 64-bit settings. The client install will have bin64, obj64, lib64, source64 and include64. The server will deploy the bin64 directory. In Busbuild, you will be able to compile, link and build in 64-bit only. Once the 64-bit release is enable, there is no going back 32-bit.

If the you update all pathcodes to 64-bit and have enabled the Release flag for 64-bit the package will only extract and build the 64-bit artifacts, resulting in the following:

• When assembling the package, you can only select 64-bit foundations.

• During the retrieval of the .c and .h file on the Enterprise Server, package build will only extract the 64-bit files, include64 and source64.

• The building of business functions on the Enterprise Server will build the 64-bit artifacts for the 64-bit dlls or .so or pgm files.

• The process to copy the include and source to the Development Client will only transfer the checkin\ include64 and checkin\source64 to the Development Client.

• The client Busbuild will only build and compile the 64-bit artifacts to create the bin64, lib64 and obj64 files.

• Only the 64-bit directories will be compressed, include64, source64, bin64, obj64 and lib64.

### 5.1.3 Building 64-bit Packages for Business Function Development

If you are building a package to use in developing 64-bit business functions, you will need to select the Generate NER Headers for Opposite bitness check box in the Package Definition application. When you compile a 64-bit business function in OMW with Busbuild on a 32-bit development client the NER headers (n*.h) for 64-bit will have to be present on the client machine for the compile to be successful. This is done during the client package build prior to building the business functions.

When you define a package in the Package Definition application for building business functions, you must select the 'Generate NER headers for Opposite bitness' check box. This creates the NER headers ( n*.h) for the opposite bitness under include64 or include.

If the package is a 32-bit package and the box is checked, then the headers for NER are generated into the include64 directory of the package.

If the package is a 64-bit package and the box is checked, then the headers for NER are generated into the include directory of the package.

The Generation of these NER headers are displayed under in the buildlog.txt, <deployment server>\<pathcode>\<package name>\work\buildlog.txt.

If you do not select the option to Generate NER headers for Opposite bitness during the package build, the NER headers for the opposite bitness are not present in the include or include64 directory. You will see these errors when compiling the opposite bitness in OMW with Busbuild.

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

This is an overview of how the JD Edwards Enterprise One 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.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.
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 checks the F00942T->emdbsrcflg value for 1. If value is 0 or blank, the objects have not been inserted into the F98780R table. If value is 1, then the objects have been inserted.

4. Client: The system checks the F00942T-emenvfu2 value for 1. If the value is 0 or blank, then the include and source files in the F98780R/R98780H have not been converted to 64-bit. If the value is 1, then the include and source files have been converted to include64 and source64 and uploaded into the F98780R/R98780H tables

5. Client: This is only done once. If F00942T -> emdbsrcflg value is 0 or blank and the F00942T-> emenvfu2 value is 0 or blank, then the system sets F00942T -> emdbsrcflg=2 for processing. It does a fetch from F9860 for all objects that are not system code 88. It checks if there is a file associated with the object on the deployment server pathcode. If there are files then it creates a par file for the object and insert the record with the par file into the F98780R/F98780H. If the foundation selected for the package was 32-bit, then for business functions and tables, the par file will only include source and include files. It sets the object record in the F9860->sigtffu =1 to indicate there are files for this object. When the process is complete, it sets the F00942T->embdsrcflg=1 for completion. It leaves the F00942T-> emenvfu2 as 0 or blank since this indicates that the conversion of the include and source into 64-bit files was not done.

6. Client: This is only done once. If F00942T -> emdbsrcflg value is 0 or blank and the F00942T-> emenvfu2 value is 0 or blank, then the system sets F00942T -> emdbsrcflg=2 for processing. It does a fetch from F9860 for all objects that are not system code 88. It checks if there is a file associated with the object on the deployment server pathcode. If there are files then it creates a par file for the object and inserts the record with the par file into the F98780R/F98780H. If the foundation selected for the package was 64-bit, then for business functions and tables, it converts the include and source into 64-bit files into a temporary include64 and source64 directory. It creates the par file with all four directories and inserts the record into the F98780R/F98780H . It sets the object record in the F9860->sigtffu =1 to indicate there are files for this object. When the process is complete, it sets the F00942T->embdsrcflg=1 for completion. It also sets the F00942T-> emenvfu2 =1, which indicates the conversion of the include and source into 64-bit files was done.

7. Client: This is only done once. If F00942T -> emdbsrcflg value is 1, the F00942T-> emenvfu2 value is 0 or blank, and the foundation selected for the package was 64-bit, then it sets F00942T -> emenvfu2 =2 for processing. It does a fetch from F9860 for all objects that have F9860-> sigtffu=1 and that are not APPL, GT or DSTR, and not system code 88. For each fetch, it retrieves the par file from the F98780R, expands the par file, converts the include and source files to 64-bit and places them in temporary include64 and source64 directories. It creates the par file with all four directories and inserts it into the repository. When complete, it sets the F00942T-> emenvfu2 =1 to indicate the files have been converted to 64-bit.

8. Client: The system initiates the connection with the Primary Enterprise Server.

9. Enterprise Server: Creates the directories on the Primary Enterprise Server and builds the list of objects from the F96225 table.

10. Enterprise Server: If client populated the F98780R/F98780H, then check the 'Live' specs F98710 <package name> for the object name F98780R. If these specs are not there, then it get the specs from the Central Objects path code and insert them into the 'Live' specs tables, F98710, F98711, F98712 and F98713.

11. Enterprise Server: If F00942T -> emdbsrcflg= 1, open the F9860 and get all objects where a F9860->sigtffu1=1 and F9860->sy != 88 and not a Named Event Rule (NER) or a Business Service (SBF) object. Open the F98780R and retrieve each object which will put the files into Primary Enterprise Server directories, checkin\source (.c files), checkin\source64 (.c files), checkin\include(.h files) , checkin\include64(.h files) and the bitmaps into the checkin\res directory

12. Client: If F00942T -> emdbsrcflg= 0 or blank, transfers the business function .c and .h files from the deployment server check-in location to the Primary Enterprise Server directories, checkin\source (.c files) and checkin\include_(.h files). This is done to preserve a snapshot of the .c and .h files at the time of the build.

13. Client: It compresses the res directory from the check-in location of the deployment server. Transfers the res.cab to the Primary Enterprise Server under the checkin\res folder.

14. Enterprise Server: If there are other servers, the Primary Enterprise Server will contact each Enterprise Server to start the build process.

15. Enterprise Server: On the Primary Enterprise Server, the package build checks if there is a difference between data dictionary items in the database compared to what is in ddict/ddtext. The difference fields are the type and length. If there are any differences, then it locks all processes to prevent any UBE to run and waits for all UBEs to finish. It does not affect users on the Web. When the locks are obtained, ddict/ddtext/glbtb are deleted in the path code spec directory.

16. Enterprise Server: The Named event rules (NERs) are generated into the checkin\source and checkin\include directories if the system on the Enterprise Server is 32-bit. If the system on the Enterprise Server is 64-bit then it will generated the files into the checkin\source64 and checkin\include64 on the Primary Enterprise Server

17. Enterprise Server: Moves server-only .c and .h files (if 32-bit system moves the checkin include and source, if 64-bit system moves the include64 and source64) to the source and include directories respectively on the Primary Enterprise Server. If there is more than one server, then the Primary Enterprise Server moves the .c and .h files from the source and include directories to the other Enterprise Servers under the source and include directories.

18. Enterprise Server: 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.

19. Enterprise Server: 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_DV920FA) in the database. There are 17 tables that are copied from one location to the other. Also the manifest table is created which holds the name of the package.

20. Enterprise Server: If the client package was also selected, the Primary Enterprise Server transfers the files from the checkin\source, checkin\source64, checkin\include, checkin\include64 and checkin\res to the deployment server package include, source, include64, source64 and res directories.

21. Enterprise Server: If client package was selected, it transfers the res.cab from the checkin\res to the package directory. The client then uncompresses it into the <package name>\res directory.

22. Client: Send message to Primary Server to get status.

23. Enterprise Server: Checks the status of the other servers to see if BSFNs are complete. Checks its own status to see if BSFNs are complete.

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

25. Enterprise Server: Transfers the compressed files and the compress.inf file back to the deployment server under the <packagename>/<machine type> directory.

26. Enterprise Server: Check the jde.ini for entry

[PACKAGE MANIFEST]                        CreateJAR=Y


If this entry is there then create a E1_APP_xxxx.jar file under the package name. This contains the bin32 and the spec.ini populated with the package name. This is used by Server Manager.

27. Enterprise Server: Transfers the server log (svrpkgbuild.log) from each server to the deployment server under <packagename>\serverLogs directory.

28. Enterprise Server: Transfers the files located under the text directory on the each Enterprise Server to the Deployment Server under <packagename>\serverlogs\<server name>\text.

29. Enterprise Server: Transfers the files located under the CompileLogs directory on the each Enterprise Server to the deployment server under <packagename>\serverlogs\<server name>\CompileLog.

30. Enterprise Server: Transfers the files located under the GenerateNER_logs directory on the Primary Enterprise Server to the deployment server under <packagename>\serverlogs\GenerateNER_logs.

31. If this is a server only package, the process is complete. However, if client was selected, the system performs the next steps.

32. Client: Runs Client Package UBE R9622C to initiate the client package build.

33. Client: Creates the package inf file.

34. Client: Compiles the .c and .h files using Busbuild.

35. Client: Builds the specs from the package's spec tables <table name>_<package name> (for example, F98710_DV920FA) in the database and puts them into the package's local spec database.

36. Client: If F00942T-> emdbsrcflg= 1 or 3 then get all the SBF files from the F98780R repository table. If the field was blank or 0 then copy the files from <pathcode>\sbf directory. Build the BSSV - Business Services.

37. Client: Waits for the compile of the business functions, building of the specs, and the building of the BSSV to complete.

38. Client: Copies the generated NER .c and .h files back to the check in location.

39. Client: Compresses the directories on the Deployment Server if compression was selected.

40. Client and Server package is complete. The User can deploy the Server package.

### 5.1.5 How the System Builds an Update Server/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.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.
1. Client: Server Package (R9621S) initiates the server package build.

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

3. Client: The system initiates the connection with the Primary Enterprise Server.

4. Enterprise Server: Creates the Directories on the Primary Enterprise Server.

5. Enterprise Server: The system builds a link list of objects in the update package from the F96225 table. If F00942T-> emdbsrcflg = 0 or blank, then it builds the list of business functions, NER, and Table ER in a file called "bsfnfile.txt". A list of bitmaps are listed in a file called "bitmapfile.txt". Both files are transferred from the <package name>\work directory to the Deployment Server.

6. Client: If F00942T-> emdbsrcflg = blank or 0 then the system opens the "bsfnfile.txt" for the list of .c and .h files to transfer from the deployment server check-in location to the Primary Enterprise Server directories, checkin\source (.c files) and checkin\include (.h files). This is done to preserve a snapshot of the .c and .h files at the time of the build.

7. Client: If F00942T-> emdbsrcflg=blank or 0, then system opens the "bitmapfile.txt".for the list of bitmaps to transfer from the res directory check in location on the deployment server to the Primary Enterprise Server checkin\res directory.

8. Enterprise Server: If F00942T->emdbsrcflg=1, then the system opens the link list of Objects and if the F9860->sigtffu1, it retrieves the par file from the F98780R and puts them in the checkin\include, checkin\include64, checkin\source, checkin\source64 and checkin\res directories.

9. Enterprise Server: On the Primary Enterprise Server, if the objects in the update package contain NER, on the Primary Enterprise Server, the package build checks if there is a difference between data dict items in the database compared to what is in ddict/ddtext. The difference fields are the type and length. If there are any differences, then it locks the package build locks all processes to prevent any UBE to run and waits for all UBEs to finish. It does not affect users on the Web. When the locks are obtained, ddict/ddtext/glbtb are deleted in the path code spec directory. The locks are then released.

10. Enterprise Server: The system generates named event rules (NERs) on the Primary Enterprise Server. The generated files are created either in the checkin\source and checkin\include directories or checkin\source64 and checkin\include64 directories depending on the bitness.

11. Enterprise Server: The Primary Enterprise Server copies server only .c and .h files to the source and include directories respectively. If there are more than one server, then the Primary Enterprise Server transfers the .c and .h files to the other Enterprise Servers under the source and include directories.

If 64-bit is enabled in Release Master, only the include64 and source64 artifacts are copied into the checkin location (Release 9.2.4).

12. Enterprise Server: Copies the parent dlls from the parent package to the update package. This dll is used in the compile of the business functions for the update package. If there are multiple servers, the Primary Enterprise Server sends a message to the other servers to start the build of business functions.

13. Enterprise Server: The Primary Enterprise Server builds specs from Central Objects, placing the results in the package's spec tables, <table name>_<package name> (for example, F98710_DV920FA) in the database. The 17 tables are created and the records for the objects are inserted into the new tables. The Manifest table is created with the name of the package and all the objects in the update package.

14. Enterprise Server: If the client package was also selected, the Primary Enterprise Server transfers the files from the checkin\source, checkin\include, checkin\source64 and checkin\include64 to the deployment server package include, source, include64 and source64 directories.

15. Enterprise Server: If client package was selected, the Primary Enterprise Server transfers back res bitmaps from the checkin\res to the Deployment Server in the <package name>\res directory.

16. Enterprise Server: The system waits for specs to finish and for dlls to finish building. If there were other servers, it will wait for them to complete.

17. Enterprise Server: When the dlls and specs are finished building, if the compression was selected for the server, then the system compresses the .dll, .so, .sl, and .SRVPGM files on the Enterprise Servers.

18. Enterprise Server: The Primary Enterprise Server transfers the compressed files and the compress.inf file back to the Deployment Server under the <packagename>/<machine type> directory.

19. Enterprise Server: The Primary Enterprise Server transfers the server log (svrpkgbuild.log) from each server to the Deployment Server under <packagename>\serverLogs directory.

20. Enterprise Server: Transfers the files located under the text directory on each Enterprise Server to the Deployment Server under <packagename>\serverlogs\<server name>\text.

If 64-bit is enabled in Release Master, only the include64 and source64 artifacts are copied to the client and the res files to the Deployment Server (Release 9.2.4).

21. Enterprise Server: Transfers the files located under the CompileLogs directory on each Enterprise Server to the Deployment Server under <packagename>\serverlogs\<server name>\CompileLogs.

22. Enterprise Server: Transfers the files located under the GenerateNER_logs directory on the Primary Enterprise Server to the Deployment Server under <packagename>\serverlogs\GenerateNER_logs.

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

24. Client: The Client Package UBE R9622C initiates the client package build.

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

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

27. Client: The system builds the specs from the package's spec tables <table name>_<package name> (for example, F98710_DV920FA) into TAM files located under the spec directory.

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

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

30. 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.6 How the System Builds a Full Client Package

The following sections provide an overview of how the JD Edwards EnterpriseOne system builds a full client-only package. All activity is done on the client/build machine.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.
1. Server Package UBE (R9621S) runs first and initiates the server package build. The process determines this is a Client Only package and will continue to the R9622C UBE.

2. Client Package UBE (R9622C) runs and initiates the client package build.

3. Creates the package build directories.

4. The system checks the F00942T->emdbsrcflg value for 1. If value is 0 or blank, the objects have not been inserted into the F98780R table. If value is 1, then the objects have been inserted.Client: This is only done once. If F00942T -> emdbsrcflg value is 0 or blank and the F00942T-> emenvfu2 value is 0 or blank, then the system sets F00942T -> emdbsrcflg=2 for processing. It does a fetch from F9860 for all objects that are not system code 88. It checks if there is a file associated with the object on the deployment server pathcode. If there are files, then it creates a par file for the object and inserts the record with the par file into the F98780R/F98780H. If the foundation selected for the package was 32-bit, then for business functions and tables, the par file only includes source and include files. It sets the object record in the F9860->sigtffu =1 to indicate that there are files for this object. When the process is complete, it sets the F00942T->embdsrcflg=1 for completion. It leaves the F00942T-> emenvfu2 as 0 or blank, as this indicates that the conversion of the include and source into 64-bit files was not done

5. This is only done once. If F00942T -> emdbsrcflg value is 0 or blank and the F00942T-> emenvfu2 value is 0 or blank, then the system sets F00942T -> emdbsrcflg=2 for processing. It does a fetch from F9860 for all objects that are not system code 88. It checks if there is a file associated with the object on the deployment server pathcode. If there are files, then it creates a par file for the object and inserts the record with the par file into the F98780R/F98780H. If the foundation selected for the package was 64-bit, then for business functions and tables, it converts the include and source into 64-bit files in temporary include64 and source64 directories. It creates the par file with all four directories and inserts the record into the F98780R/F98780H. It sets the object record in the F9860->sigtffu =1 to indicate there are files for this object. When the process is complete, it sets the F00942T->embdsrcflg=1 for completion. It sets the F00942T-> emenvfu2 =1, which indicates that the conversion of the include and source into 64-bit files was done.

6. This is only done once. If F00942T -> emdbsrcflg value is 1, the F00942T-> emenvfu2 value is 0 or blank, and the foundation selected for the package was 64-bit, then it sets F00942T -> emenvfu2 =2 for processing. It does a fetch from F9860 for all object that have F9860-> sigtffu=1 and that are not APPL, GT, or DSTR, and not system code 88. For each fetch, it retrieves the par file from the F98780R, expands the par file, converts the include and source files to 64-bit and places them in temporary include64 and source64 directories. It creates the par file with all four directories and inserts it in the repository. When complete, it sets the F00942T-> emenvfu2 =1 to indicate the files have been converted to 64-bit.

7. Creates the INF file.

8. If F00942T-> emdbsrcflg= 0 or blank, then it copies the files from the check-in location to the package name directory. These files are located under the directories res, source (.c files), include (.h files) and work.

If 64-bit is enabled in Release Master, only the include64 and source64 artifacts are copied into the check-in location (Release 9.2.4).

9. If F00942T->1, then it queries the F9860 for all objects with a F9860->sigtffu=1 and F9860->sy != 88. It retrieves each object from the F98780R and put them into the directories res, source (.c files), include (.h files), If the package is pointing to a 64-bit foundation, then it will put files into the source64 (.c files) and include64 (.h files) directories. It then copies the work directory from the checkin location to the package name.

If 64-bit is enabled in Release Master, only the include64 and source64 artifacts are copied to the package location (Release 9.2.4).

10. Creates an OEE Local database with the Central Object tables.

11. Copies the 17 Central Objects tables into the created database.

12. Runs the JD Edwards Enterprise One BusBuild program to generate the NER, compile and link the business functions, which create the DLLs in the bin32/bin64 directory, the objects in the obj directory, and the libraries in the lib32/lib64 directory.

13. Build Business Services if selected.

14. Build any Features that were included in the package.

15. Compress the directories.

### 5.1.7 How the System Builds Client Only Update Package

The following section describes how the JD Edwards EnterpriseOne system builds a client only update package.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.
1. Server Package UBE (R9621S) runs first and initiates the server package build. The process determines this is a Client Only package and will continue to the R9622C UBE.

2. Client Package UBE (R9622C) runs and initiates the client package build.

3. Creates the package build directories.

4. Creates the INF file.

5. For each object in the Package Build History table (F96225), retrieves the information from the Central Objects and adds it to the TAM specification files and builds the individual .par file for the object under the <package name>\spec\packagename> directory.

6. If F00942T-> emdbsrcflg= 0 or blank, 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.

7. If F00942T->emdbsrcflg=1, then it retrieves each par file from the F98780R and puts the files in the package's directory on the Deployment Server.

8. Runs the JD Edwards EnterpriseOne BusBuild program. Generates the NER from the list of objects. It copies from the parent package, the bin32/bin64 and lib32/lib64 files to the update package bin32/bin64 and lib32/lib64 directory. It compiles the business functions objects in the package. The updates are now in the bin32/bin64 and lib32/lib64 files of the update package.

9. Updates the Parent Package: If the build machine is not the deployment server, it will copy the parent package local database from the spec directory to the build machine. The attach and detach of the parent local database can only occur on a local machine and not across the network. The specs from the update package are than merged into this parent package local database. The parent package local database is then copied back to the deployment server parent package directory. If the build machine is the deployment server, than the merge of the update objects happens to the parent package specs located under the parent package spec directory.

10. Copies from the update package bin32/bin64, lib32/lib64, obj, source/source64 and include/include64 files to the parent package directory on the Deployment Server.

11. Builds any features included in the package.

12. If compression was selected, then compresses the directories.

### 5.1.8 How the System Deploys the Full Server Package

This is an overview of how the JD Edwards EnterpriseOne system deploys a full server package and the affect it has on the JAS Server.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.

Full Package - Normal Package Deployment:

1. Set the F9651 field mdmchrcdnm=50 to prepare the server for Deploy.

2. Process sleeps for 1 minute which allows the JAS server polling to see there is a package to deploy. The JAS server will put a lock on the web applications to wait for the deploy to finish. The JAS server will poll every 5 seconds checking the F9651 table to see if it is done with the deploy. It looks for mdmchrcdnm=30. There are no effects to user already in the application only if the users try to bring up a new application will they have to wait.

3. Sets the F9651 field mdmchrcdnm=10 to indicate deployment is happening.

4. Enterprise Server sends message to all kernels to lock. This will prevent any UBE from being submitted.

5. Process waits for all running UBEs to complete. It will only wait as long as the setting in the jde.ini indicated - "DeployWaitInMinutes=x" or default to 30 minutes. If time has expired, it will release the locks without deploying the package.

6. Once UBEs are finished running:

1. Opens the <pathcode>/spec.ini file and changes the <pathcode>_Package setting to the new package name:

DV920_Package=DV920FA

2. Copies the .dll/.so/sl/SVRPGM from the package directory to the "Live Area" which is <pathcode>\bin32/bin64" or the SVRPGM library.

3. Deletes the ddict, ddtext and glbtbl specs from the <pathcode>/spec directory.

4. Deletes the Runtime cache from the <pathcode>/runtimeCache directory.

5. Releases the kernel locks.

6. Sets the F9651 field mdmchrcdnm=30 to indicate deployment is finished.

Action Taken on the JAS Server

When the first person signs onto a web application after the deployment, the process checks the manifest table, F98770, discovers that a package was deployed, and follows these steps:

1. Deletes the XML files from the F989999 and F989998 tables.

2. Updates the manifest table to the new full package.

3. Releases the locks on the web users.

4. Users will be able to sign on to the applications.

### 5.1.9 How the System Deploys the Server Update Package

This is an overview of how the JD Edwards EnterpriseOne system deploys different types of update server packages.

Note:

Any references to 64-bit apply to Tools Release 9.2.3 and higher.

Deployment of Update Package that Includes All Types of Objects:

1. Set sthe F9651 field mdmchrcdnm=50 to prepare the server for deployment.

2. Process sleeps for 1 minute which allows the JAS server polling to see there is a package to deploy. The JAS server puts a lock on the web application to wait for the deployment to finish. The JAS server polls every 5 seconds, checking the F9651 table to see if it is done with the deployment. It looks for mdmchrcdnm=30. There are no effects to users already in the application, only if the users try to bring up a new application.

3. Sets the F9651 field mdmchrcdnm=10 to indicate deployment is happening.

4. Enterprise Server sends message to all kernels to lock. This will prevent any UBEs from being submitted.

5. Process waits for all running UBEs to complete. It will only wait as long as the setting in the jde.ini indicates - "DeployWaitInMinutes=x" or default to 30 minutes. If time has expired, it will release the locks without deploying the package.

6. Once UBEs are finished running:

1. Merges the update package tables with the current database tables to which the spec.ini points.

2. Copies the .dll/.so/sl/SVRPGM from the update package directory to the "Live Area": <pathcode>\bin32/bin64" or the SVRPGM library.

3. Deletes the ddict, ddtext, and glbtbl specs from the <pathcode>/spec directory.

4. Deletes only the directories of the UBEs that are in the package from the runtime cache directory, <pathcode>/runtimeCache.

7. Released the kernel locks.

8. Sets the F9651 field mdmchrcdnm= 30 to indicate deployment is finished.

Deployment of an Update Package that Contains Only UBE Objects:

1. Sets the F9651 field mdmchrcdnm=50 to prepare the server for deployment.

2. Sets the F9651 field mdmchrcdnm=10 to indicate deployment is happening.

3. Places a lock on only the UBEs in the package. If there is a submit to run a UBE in the package, it is inserted into the F988259 table and held until the package is complete.

4. Merges the update package tables with the current database to which the spec.ini points.

5. Deletes only the directories of the UBEs that are in the package from the Runtime cache directory, <pathcode>/runtimeCache.

6. Sets the F9651 field mdmchrcdnm= 30 to indicate deployment is finished.

7. Submits the list of UBEs in the F988259 to run.

Note:

Only the UBEs in the package are not allowed to run. All other UBEs will be processed during deployment.

Deployment of an Update Package that Contains Only Application Objects:

1. Sets the F9651 field mdmchrcdnm=50 to prepare the server for deployment.

2. The process sleeps for one minute, which allows the JAS Server polling to see there is a package to deploy. The JAS Server will put a lock on applications to wait for deployment to finish. It will start polling every 5 seconds checking the F9651 table to see if it is done with deployment. It looks for mdmchrcdnm=30. There is no effect to users already in the application. If starting an application, there will be a wait until deployment is finished.

3. Sets the F9651 field mdmchrcdnm=10 to indicate deployment is happening.

4. Merges the update package tables with the current database tables to which the spec.ini points.

5. Sets the F9651 field mdmchrcdnm=30 to indicate deployment is finished.

Deployment of an Update Package that Contains Only UBE and Application Objects:

1. Set sthe F9651 field mdmchrcdnm=50 to prepare the server for deployment.

2. The process sleeps for one minute, which allows the JAS Server polling to see that there is a package to deploy. The JAS Server puts a lock on applications to wait for deployment to finish. It starts polling every 5 seconds checking the F9651 table to see if it is done with deployment. It looks for mdmchrcdnm=30. There is no effect to users already in the application. If starting an application, there will be a wait until deployment finishes.

3. Sets the F9651 field mdmchrcdnm=10 to indicate deployment is happening.

4. Places a lock on only the UBEs in the package. If there is a submit to run a UBE in the package, it is inserted into the F988259 table and held until the package is complete.

5. Merges the update package tables with the current database tables to which the spec.ini points.

6. Sets the F9651 field mdmchrcdnm=30 to indicate deployment is finished.

7. Submits the list of UBEs in the F988259 to run.

Note:

Only the UBEs in the package are not allowed to run. All other UBEs are processed during deployment.

## 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 in the F98780R repository table, 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

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 retrieved from the F98780R repository table on 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/E920/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)

-G -L$(ORACLE_HOME)/lib (default for Solaris) shared -z muldefs -melf_i386 -L/JDEdwards/e920/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 supported 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=2017  VisualStudioVersion=2013  VisualStudioVersion=10  VisualStudioVersion=9  Use the first setting if you are using the Microsoft Visual C++ 2017 compiler, the second setting if you are using the Microsoft Visual C++ 2013 compiler, the third setting if you are using the Microsoft Visual C++ 2010 compiler, and the fourth 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 Improving Client Package Build Performance If you find that client package builds take an inordinately long time when using Visual Studio 2013 or 2010, you can add and adjust the following setting in the [JDE_CG] section of the jde.ini on the build machine for the client package. The setting is passed to the Microsoft Visual C++ compiler as the /MP flag and specifies how many simultaneous compilations of business functions are allowed. SimultaneousBuilds=X  In this example, the value of "X" is shown in the table: Value of "X" Description 0 This is the default value if the setting is missing. Visual Studio will attempt to start as many compilers as there are virtual threads on the build machine. 1 Only one compiler at a time will be run. An integer less than or equal to the number of virtual threads on the build machine. Visual Studio will attempt to start as many compilers as possible up to and including this number. You can start with a value of zero (0), build a package, and, by looking at the build logs, determine how long the compilation takes. In some cases, you may not want to use all available virtual threads on the build machine. In that case, retry the build with various values until you get satisfactory build times. ### 5.3.5 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.6 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 DV920FA, which is full package A for the DV920 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.6.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\E920\PACKAGE\ DV920FA 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\E920\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 (E920). This item appears only when included in the package. SPathcodeDATA=\\MachineName\E920\ DV920\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.6.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.6.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. Pathcode1=Y,$Spathcode\bin64,$Dpathcode\bin64 Indicates the bin64 directory that is subordinate to the path code (Release 9.2.3) 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. Pathcode3=Y,$Spathcode\include64, $Dpathcode\include64 Indicates the include64 directory that is subordinate to the path code. Pathcode4=Y,$Spathcode\lib32, $Dpathcode\lib32 Indicates the lib32 directory that is subordinate to the path code. Pathcode4=Y,$Spathcode\lib64, $Dpathcode\lib64 Indicates the lib64 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. Pathcode5=Y,$Spathcode\obj64, $Dpathcode\obj64 Indicates the obj64 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. Pathcode6=Y,$Spathcode\source64, $Dpathcode\source Indicates the source64 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.6.4 [FileSetsDescription] This section provides a text description for each fileset as shown in this example: [FileSetsDescription] DV9201=Business Function DLL Files DV9202=Specification Files DV9203=Include Files DV9204=Library Files DV9205=Object Files DV9206=Source Files DV9207=Work Files DV9208=Make Files DV9209=Resource Files DV92010=SBF Source Files SYS=Foundation Files DV920DATA=Data Files  Or for 64-bit packages (Release 9.2.3): [FileSetsDescription] DV9201=Business Function 64-bit DLL Files DV9202=Specification Files DV9203=Include 64-bit Files DV9204=Library 64-bit Files DV9205=Object 64-bit Files DV9206=Source 64-bit Files DV9207=Work Files DV9208=Resource Files DV92010=Include Files DV92011=Source Files SYS=Foundation Files DV920DATA=Data Files  #### 5.3.6.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.6.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.6.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.6.8 [Attributes] This section contains information about the current release, global tables, specification and help files, and the jde.ini file. Item Purpose PackageName=DV920FA Indicates the name of the package. PathCode=DV920 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=E920 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. ServicePack=01-15-2018_08_43 - Release64 Indicates the date that the Tools Release was built, the mode (debug or release), and the bitness. (Release 9.2.3) ToolsBitness=32 orToolsBitness=64 Indicates the bitness of the package (Release 9.2.3) 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 2020 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 2020 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 2020 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=DV920 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.6.9 [Oracle Databases] This section contains information about the Oracle databases. Item Purpose JDELocal_DV920=ORACLE Indicates the local Oracle database. SPEC_DV920FA=ORACLE Indicates the Oracle database. Each of the databases listed, has its own section in the INF file as shown in this example: [JDELocal_DV920] SourceTableSpace=JDELocal Server=127.0.0.1 UserID=SYSTEM DataFileDestDir=$DDV920DATA\JDELocal_DV920.dbf
DumpFileDestDir=$DDV920DATA\JDELocal_DV920.dmp [SPEC_DV920FA] SourceTableSpace=MASTER Server=127.0.0.1 DataFileDestDir=$DDV920\Spec\SPEC_DV920FA.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.