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)

-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/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
DumpFileDestDir=$DDV920\Spec\SPEC_DV920FA.dmp

5.3.6.10 [START]

This section contains startup information:

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

Or for 64-bit (Release 9.2.3):

ProgramGroupName=JDEdwards
Item1=System\Bin64\activConsole.exe, JDEdwards Solution Explorer, appl_pgf\res\One⇒
World.ico

5.3.6.11 [Desktop]

This section contains desktop information:

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

Or for 64-bit (Release 9.2.3):

Item1=System\Bin64\activConsole.exe, JDEdwards Solution Explorer, appl_pgf, res⇒⇒
\OneWorld.ico

5.3.6.12 [Environment]

This section contains environment information:

PathDV920=%INSTALL\DV920\bin32;
PathSys=%INSTALL\system\bin32;

Or for 64-bit (Release 9.2.3):

PathDV920=%INSTALL\DV920\bin64;
PathSys=%INSTALL\system\bin64;

5.3.6.13 [Fonts]

This section contains font information:

[Fonts]
Arial=Font\arial.ttf

5.3.6.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 shows some features that might be included:

[Feature]
WEBDEVELF=\\DENMLSAN246\E920\Package_inf\Feature_inf\WEBDEVELF_1.INF
VS2010RT=\\DENMLSAN246\E920\Package_inf\Feature_inf\VS2010RT_1.INF

5.3.6.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 PD920/bin32 directory contains the DLLs that are created on the workstation. All of the business function source files are in the PD920/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 stored in the F98780R repository table 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 or Windows Server Build

This topic describes the files that the system creates when it builds business functions on a UNIX or Windows 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) for UNIX or .dll for Windows

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 or Windows 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 in the jde.ini which can be accessed through Server Manager.

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

The checkin location holds all the include, source, and res files that were retrieved from the F98780R during the build. The process then copies only the server-only or server/client business functions to the PD920FA source and include directories to prepare it to build the business functions.

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

PD920FA\source\CAEC

PD920FA\source\CALLBSFN

PD920FA\source\CCORE

PD920FA\source\CDESIGN

PD920FA\source\CDIST

PD920FA\source\CFIN

PD920FA\source\CHRM

PD920FA\source\CMFG

PD920FA\source\JDBTRIG

checkin\include and/or include64

checkin\source and/or source64

checkin\res

Each subdirectory contains the business function source files that belong to the shared library. All shared libraries are installed in the PD920/bin32 directory.

The naming convention for UNIX for the shared libraries is as follows: 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.

For Windows, all DLLs are installed in the PD920\bin32 directory. They have the same name as the DLL subdirectories, except that they have the .dll suffix.

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 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.4.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.4.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 in the jde.ini which can be accessed through Server Manager.

Subordinate to the package directory (PD920FA) 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:

PD920FA

include

source

CAEC

CALLBSFN

CCORE

CDESIGN

CDIST

CFIN

CHRM

CMFG

JDBTRIG

spec

text

checkin\include and/or include64

checkin\source and/or source64

checkin\res

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.4.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.5 Descriptions of Directory Files

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

Directory Description
PD920\include This is the location where .h and .hxx source files are located. These objects are taken from the server and built on.
Checkin\include and/or include64 This is the location where all the .h include files retrieved from the F98780R repository are stored.
Checkin\source and/or source64 This is the location where all the .c source files retrieved from the F98780R repository is stored.
Checkin\res This is the location where all the bitmaps used by the applications are stored.
PD920\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.
PD920\spec This folder is no longer used but is created for backwards compatibility.
PD920\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.

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

5.5.2.2 [Registry]

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

The settings for this section are displayed in this order:

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

The following table contains a description of each variable:

Item Purpose
Root Describes the root in the registry with these values:
  • 0 means root

  • 1 means current user

  • 2 means local machine location

  • 3 means users

Key Indicates the key for the registry value.
Name The registry value name. Name prefixes are:
  • + means that the name is created (if it does not already exist) when the feature is installed

  • – means that the name is deleted with all subkeys when the feature is uninstalled

  • * means that the name is created (if it does not already exist) when the feature is installed, and it is removed with all subkeys when the feature is uninstalled

Value The name of the registry value. Value prefixes are:
  • #x means that the value is stored as a hexadecimal value

  • #% means that the value is stored as an expandable string

  • # means that the value is stored as an integer

  • #$ means that the value is stored as a string


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.