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.

(Release 9.2.7.3) During the retrieval of files from the F98780R table, if a record is missing for an object or the files are missing from the par file, package build attempts to repair this record. Business functions and tables should always have a record in F98780R with a .h and/or a .c file. Business Service will also always have a record with a .java file. UBE and business views only have a record if they have a .h file. Application will only have a record if it has a bitmap file.