timezones for enterpriseone 91

Time Zone Support for Oracle

JD Edwards EnterpriseOne

Tools Release 9.1

December 2011

Time Zone Support for Oracle JD Edwards EnterpriseOne

Time Zone Support for Oracle JD Edwards EnterpriseOne Page i

PURPOSE STATEMENT

This document addresses time zone support for the Oracle JD Edwards EnterpriseOne solution. As many

technology concepts and advanced CNC concepts are leveraged in the implementation of a time zone solution

individuals who implement this solution should have the following qualifications:

An understanding of network and operating systems management concepts.

A knowledge of EnterpriseOne Common Foundation and System Administration.

A familiarity with any integrated third-party product interacting with JD Edwards EnterpriseOne to

evaluate whether the mechanisms that are put in place might alter or compromise its use.

Important: The time zone implementation methodology described herein requires as a minimum JD Edwards EnterpriseOne tools release 9.1.

Important: An IDDA (based upon bug 13466311) is required when implementing the time zone solution on little endian platforms, e.g. Microsoft Windows and Linux built on JD Edwards EnterpriseOne tools release

9.1.n.n preceding tools release 9.1.0.2. Tools release 9.1.0.2 contains the little endian platform fix.

Important: The time zone implementation methodology described herein does not apply to database table triggers. JD Edwards EnterpriseOne uses database table triggers for 21 CFR Part 11. Thus, audit records will be

entered to the database based upon the database system's time clock.

Important: The time zone implementation when applied against the IBM i platform requires special package build / deploy considerations described within Appendix C found in this document.

Important: The time zone methodology described herein when applied against a server using a high available 'active-active' or load-balancing cluster solution requires special considerations described within Appendix D

found in this document. An 'active-active' or load-balancing cluster solution is one where two or more active

physical node servers sharing a common logical cluster name are made available via a 'load-balancing' intelligent

network appliance.

This document is intended for information purposes only, and may not be incorporated into any contract. It is

not a commitment to deliver any material, code, or functionality, and should not be relied upon in making

purchasing decisions. The development, release, and timing of any features or functionality described for

Oracles products remains at the sole discretion of Oracle. Updates and enhancements are provided in

accordance with Oracles Technical Support Policies at:

www.oracle.com/support/collateral/oracle-technical-support-policies.pdf


Time Zone Support for Oracle JD Edwards EnterpriseOne Page ii

Table of Contents

Introduction .................................................................................................................................... 1

Time Zone Implementation (Historical Methodology) ................................................................................ 1

OVERVIEW....................................................................................................................................... 2

EnterpriseOne Requirements .................................................................................................................... 3

Configuring EnterpriseOne for Time zones ........................................................................................ 4

Configuring the Enterprise (Logic / Application / Batch) Server .................................................................. 4

Adding a Virtual IP and Virtual Hostname to the Server .................................................................................................. 4

Adding the Time Zone Specific Virtual Host Servers to JD Edwards EnterpriseOne ......................................................... 5

Create New JD Edwards EnterpriseOne System Foundation Instances on the Server ..................................................... 6

Create an Operating System Time Zone Specific User Accounts ...................................................................................... 8

Configuring EnterpriseOne JAS HTML JVMs for Different Time Zones ....................................................... 12

Configure the Application Server JAS HTML JVM to use a Specific Time Zone............................................................... 12

Configuring the IBM WebSphere Application Server ..................................................................................................... 13

Configuring the Oracle WebLogic Server ........................................................................................................................ 15

Configure the JD Edwards EnterpriseOne JAS INI Files ................................................................................................... 19

JD Edwards EnterpriseOne CNC System Administration Considerations .................................................... 20

Time Zone Configuration Code Specific Considerations ................................................................................................. 20

Create Time Zone Specific Environments Logic Directed to Virtual Host ....................................................................... 20

APPENDIX A: REPLICATING YOUR SYSTEM FOUNDATION INSTANCE ............................................... 22

APPENDIX B: ENTERPRISEONE TABLES WITH HOSTNAME REFERENCES ........................................... 26

APPENDIX C: Package build AND Deploy considerations ................................................................. 28 Package Deployment Considerations ............................................................................................................................. 28

Package Deployment for the IBM i Platform .................................................................................................................. 28

APPENDIX D: HIGH AVAILABILITY LOAD BALANCING CONSIDERATIONS .......................................... 30 High Availability Load Balancing Background ................................................................................................................. 30

Time Zone High Availability Load Balancing Considerations .......................................................................................... 31


Time Zone Support for Oracle JD Edwards EnterpriseOne Page 1

INTRODUCTION Many JD Edwards EnterpriseOne customers need transactions to reflect their users local time zones. EnterpriseOne does

not have explicit built-in local time zone support. This document describes a technique that may be used to provide time

zone support for EnterpriseOne users. It allows customers to configure EnterpriseOne to support multiple time zones on

a single operating system image. Thus eliminating the need to purchase and manage a multiple servers for the purpose of

providing multiple time zone support for their end-users.

Time Zone Implementation (Historical Methodology) Historically JD Edwards EnterpriseOne customers needing to support multiple time zones have added two time zone

specific server roles for each desired time zone, e.g. a JD Edwards Enterprise Server and Java Application Server (JAS)

HTML Server. As EntepriseOne Business Functions are executed and data is written to the database, the transaction's

date-time-stamp is based upon the server's time clock. For the Enterprise Server this required a dedicated server in the

form of additional hardware or a virtual server/logical partition. The Enterprise Server's system time clock is set to the

desired time zone. For the HTML Server the desired time zone is set via an HTML instance specific Java argument. Thus,

multiple HTML instances each with a unique time zone could exist on a single server. Each Enterprise Server and HTML

Server combination will be coupled via settings in the JAS.INI file and OCM mappings.

For instance, an EnterpriseOne user is assigned to a particular HTML server. Their EnterpriseOne user role will be

assigned to an environment whose OCM mappings for BSFN logic and UBEs are directed to their time zone specific

EnterpriseOne Server.

Figure 1: Historical Time Zone Support Methodology



The implementation costs for the above listed time zone support methodology can quickly grow when you consider that

each specific time zone Enterprise Server requires dedicated hardware (or virtualized hardware) with redundant shared system

components, e.g. an operating system, database client software, compiler (optional), and potentially other bolt-on products.

Also consider the cost in employee-hours required to maintain each server independently, e.g. patching the operating system.

OVERVIEW The techniques outlined in this document leverage various technology concepts. Although these technology concepts exist

across supported EntepriseOne server platforms, the implementation of any particular technology may differ from one

platform to another. This document is intended to provide guidance and will not address the configuration of each

technology concept by specific platform.

When an EntepriseOne Business Function (BSFN) is executed and data is written to the database, the transaction record's

date-time-stamp is based upon the server's time clock. For BSFNs executed on an HTML server the solution is simple as

one can modify the Java argument by instance (Java Virtual Machine, a.k.a. JVM) so that the HTML specific instance uses

a particular time zone.

Similar logic can be applied to the EnterpriseOne services by assigning a time zone environment variable (or locale setting)

to the operating system user account used to start the JD Edwards EnterpriseOne services. When these services are

started they will inherit the time zone attribute associated with the OS user account. This can be put into practice by

creating multiple operating system user accounts each assigned to a different time zone. These accounts can then be

associated to a time zone specific JD Edwards EnterpriseOne system foundation instance(s) installed on a single server.

For JD Edwards EnterpriseOne a system foundation instance is made up of a JDE.INI file, the file system, and binaries

of a specific tools release used in conjunction with an application foundation, e.g. PD900. Generally when a new

'foundation' is added to a server running another foundation, it requires that the network port be unique as is found in a

multi-foundation implementation. In taking such a tact (where each foundation has a unique port) we eliminate the ability

to leverage and easily manage a common JD Edwards EnterpriseOne server package and diminish the ability to view

reports across the enterprise, etc.

For each JD Edwards EnterpriseOne system foundation instance to share a common network port a few things must

happen. First, the server on which the JDE foundations are installed must have a virtual IP address created for each

supported time zone. Second, a virtual hostname must be created and assigned to each time zone specific virtual IP address.

Third, each installed JDE foundation's JDE.INI file would direct its server network traffic to a time zone specific virtual

hostname and the foundation would be assigned to a time zone specific OS user account. Fourth, a JD Edwards 'Add

Server' plan must be created and executed for each added virtual hostname. Fifth, JD Edwards EnterpriseOne code changes

have been introduced to make it possible for the JD Edwards EnterpriseOne logic to execute and remain scoped to a

particular virtual hostname. Time zone support begins with JD Edwards EnterpriseOne Tools Release 9.1.

Each HTML Server Instance and Enterprise (Logic) Server combination sharing a common time zone will be linked via INI

based configuration settings and OCM mappings. When an EnterpriseOne user is assigned to a particular HTML server,

their EnterpriseOne user role will be assigned to an environment whose OCM mappings for BSFN logic and UBEs are

directed to their time zone specific EnterpriseOne Server.

The aforementioned methodology makes it possible for a single physical server sharing a common operating system image

to support multiple time zone specific JD Edwards EnterpriseOne logic servers. Each logic server will be known by its

virtual hostname, have its own virtual IP address, be tied to an HTML server instance which shares a similar time zone, and use

a time zone specific operating system user account to start its services. Figure 2 shown below depicts a JD Edwards

EnterpriseOne solution logically delineated by three time zones.



Figure 2: Virtual Host Time Zone Support Methodology

EnterpriseOne Requirements This technique is currently limited to JD Edwards EnterpriseOne tools release 9.1 and higher. This technique requires

special considerations for a JD Edwards EnterpriseOne Enterprise/Logic/Batch server using an 'active-active' or load-

balancing cluster solution. An 'active-active' or load-balancing cluster solution is one where two or more active physical node

servers sharing a common logical cluster name are made available via a 'load-balancing' intelligent network appliance; see

Appendix D found in this document for more details.

Important: License program 5761SS1, option 21 "Extended NLS Support" is an IBM i platform requirement.

Single Physical Server with Single Operating System Image - Hostname: JDEENTSRV

Switched Ethernet

User Community

Intelligent Switch *or* Network Deployment / Web Cache Cluster

JAS/HTML

Server

TZ -7 GMT:

HTML01

JAS/HTML

Server

TZ -5 GMT:

HTML01

JAS/HTML

Server

TZ -6 GMT:

HTML01

JDE EnterpriseOne

Database Server

Time Zone Offset (-5 GMT):

E1 Services OS User Account:JDE900TZ5Nexport TZ="/usr/share/zoneinfo/America/New_York"

Virtual IP & Hostname: JDESRVR01

JDE.INI[JDENET]

serviceNameListen=6015

JAS.INI:[PACKAGE BUILD]

PackageDomainServer=JDESRVR01

PackageDomainPort=6015

Serialized Objects Data Source: SerObj_01

JVM Generic Argument:

-Duser.timezone=GMT-5


E1 Services OS User Account:JDE900TZ6Nexport TZ="/usr/share/zoneinfo/America/Chicago"


JDE.INI[JDENET]









E1 Services OS User Account:JDE900TZ7Nexport TZ="/usr/share/zoneinfo/America/Denver"


JDE.INI[JDENET]










CONFIGURING ENTERPRISEONE FOR TIME ZONES This section provides an overview of the steps necessary to configure JD Edwards EnterpriseOne for time zones. Where

applicable it will include steps for configuring the operating system for the IBM i platform. As this document is intended

to provide guidance it will not address the configuration of operating system technology concepts by specific platform.

In essence, the following must be completed to configure an EnterpriseOne time zone instance on an IBM i server (single

operating system image).

Configuring the Enterprise (Logic / Application / Batch) Server For the purpose of clearly defining configuration differences between hostnames, user accounts, library names, etc. the

name suffixes used within this document reflect the time zone difference from Greenwich Mean Time (GMT), e.g.

xxxxxTZ7N for GMT time zone minus (negative) seven hours. For instance the Enterprise Server's virtual name is

JDE900TZ7N for GMT-7 (DENVER time zone). The Enterprise Server's physical name is JDE900SVR.

Note: Use QSECOFR or an equivalent user account (user profile) when configuring the IBM i platform operating system.

Adding a Virtual IP and Virtual Hostname to the Server Add a virtual IP address, one per time zone, and associate this to the system's NIC card. Start the newly added TCP

interface. Then verify the configuration making certain the virtual IP addresses were successfully added and active.

cmd: ADDTCPIFC INTNETADR('10.123.123.51') LIND(ETHERNET) SUBNETMASK('255.255.254.0') cmd: ADDTCPIFC INTNETADR('10.123.123.52') LIND(ETHERNET) SUBNETMASK('255.255.254.0') cmd: ADDTCPIFC INTNETADR('10.123.123.53') LIND(ETHERNET) SUBNETMASK('255.255.254.0')

cmd: STRTCPIFC INTNETADR('10.123.123.51') cmd: STRTCPIFC INTNETADR('10.123.123.52') cmd: STRTCPIFC INTNETADR('10.123.123.53')

cmd: CFGTCP Option 1 | F11 Work with TCP/IP Interfaces System: JDE900SVR Type options, press Enter. 1=Add 2=Change 4=Remove 5=Display 9=Start 10=End

Internet Subnet Interface Alias Opt Address Mask Status Name __ _______________

__ 10.123.123.49 255.255.254.0 Active *NONE __ 10.123.123.51 255.255.254.0 Active *NONE __ 10.123.123.52 255.255.254.0 Active *NONE __ 10.123.123.53 255.255.254.0 Active *NONE __ 127.0.0.1 255.0.0.0 Active LOCALHOST __ 192.168.5.1 255.255.255.0 Active *NONE



Add time zone specific virtual hostnames using the previously created virtual IP addresses. Then verify the hostname

configuration making certain the virtual IP and hostname entries were successfully added. The first command entry below

combines the physical machine's hostname JDE900SVR with the time zone specific virtual hostname JDE900TZ7N .

cmd: CHGTCPHTE INTNETADR('10.123.123.49') HOSTNAME((JDE900SVR.DOMAIN.COM) (JDE900SVR) (JDE900TZ7N.DOMAIN.COM) (JDE900TZ7N)) cmd: ADDTCPHTE INTNETADR('10.123.123.51') HOSTNAME((JDE900TZ6N.DOMAIN.COM) (JDE900TZ6N)) cmd: ADDTCPHTE INTNETADR('10.123.123.52') HOSTNAME((JDE900TZ5N.DOMAIN.COM) (JDE900TZ5N)) cmd: ADDTCPHTE INTNETADR('10.123.123.53') HOSTNAME((JDE900TZ0N.DOMAIN.COM) (JDE900TZ0N))

cmd: CFGTCP Option 10

Work with TCP/IP Host Table Entries System: JDE900SVR Type options, press Enter. 1=Add 2=Change 4=Remove 5=Display 7=Rename

Internet Host

Opt Address Name _ ________________________________

_ ::1 IPV6-LOOPBACK IPV6-LOCALHOST _ 10.123.123.49 JDE900SVR.DOMAIN.COM JDE900SVR JDE900TZ7N.DOMAIN.COM JDE900TZ7N _ 10.123.123.51 JDE900TZ6N.DOMAIN.COM JDE900TZ6N _ 10.123.123.52 JDE900TZ5N.DOMAIN.COM JDE900TZ5N _ 10.123.123.53 JDE900TZ0N.DOMAIN.COM JDE900TZ0N

Important: The local WINS and/or DNS server(s) must be updated to resolve each newly added virtual

hostname to its associated virtual IP address.

Adding the Time Zone Specific Virtual Host Servers to JD Edwards EnterpriseOne Add libraries (schemas), one per time zone, to the DB2/400 database. Label them for ease of reference as shown below.

cmd: CRTLIB LIB(SVM900TZ6N) TEXT(JDE900TZ6N_ENTSRVR_TZ_NEG_6_CHICAGO) cmd: CRTLIB LIB(SVM900TZ5N) TEXT(JDE900TZ5N_ENTSRVR_TZ_NEG_5_NEWYORK) cmd: CRTLIB LIB(SVM900TZ0N) TEXT(JDE900TZ0N_ENTSRVR_TZ_NEG_0_LONDON)

From the Deployment Server login to the JDEPLAN environment run "Add-on Servers Plan" to add the new virtual

server(s) to EnterpriseOne. Create a new 'Add-on Servers' plan, validate the plan, and execute it via the workbench.

Note: Running R9840C prior to executing the plan will copy your current system configuration from the SY900 database to the Deployment

Server local database. This ensures the information pushed from the local database to the server is accurate and date relevant.



Figure 3: Virtual Time Zone Server Information

SERVER PORT

SYSTEM

FOUNDTION LIBRARY SERVER MAP DATA SOURCE TIMEZONE

JDE900TZ7N 6015 SVM900 JDE900TZ7N - 900 Server Map Denver

JDE900TZ6N 6015 SVM900TZ6N JDE900TZ6N - 900 Server Map Chicago

JDE900TZ5N 6015 SVM900TZ5N JDE900TZ5N - 900 Server Map NewYork

JDE900TZ0N 6015 SVM900TZ0N JDE900TZ0N - 900 Server Map London

Note: System Foundation library is equivalent to the Unix install path: /u01/app/JDEdwards/e900_tz0.

Create New JD Edwards EnterpriseOne System Foundation Instances on the Server Replicate an existing system foundation instance by saving and restoring (Unix tar) the system foundation library (including

the IFS directory structure). See Appendix A of this document for instructions on how to replicate the System Foundation

through save and restore commands. Use the Server Manager Console register the instance, e.g. click Create New Managed

Instance & select "Register an Existing Enterprise Server". It is also possible to use the Server Manager Console to install a new System Foundation instance; e.g. click Create New Managed Instance and select "Install New Enterprise Server".

Figure 4: Virtual Time Zone Server Manager Instance Information

SERVER MANAGER INSTANCE

NAME

SYSTEM

FOUNDATION

SERVER

HOST NAME PORT

START

IPC

SERVER MAP

LIBRARY SERVER MAP DATA SOURCE

JDE900TZ7N_EntSrvr_TZn7_De

nver E900SYST7N

JDE900TZ7N 6015 0001 SVM900 JDE900TZ7N - 900 Server Map

JDE900TZ6N_EntSrvr_TZn6_Ch

icago E900SYST6N

JDE900TZ6N 6015 2101

SVM900TZ6N JDE900TZ6N - 900 Server Map

JDE900TZ5N_EntSrvr_TZn5_Ne

wYork E900SYST5N

JDE900TZ5N 6015 4201


JDE900TZ0N_EntSrvr_TZn0_Lo

ndon E900SYST0N

JDE900TZ0N 6015 6301


Each System Foundation instance must have a dedicated set of PATHCODE replicated TAM SPEC objects. On the IBM i

platform this includes IFS TAM SPEC files and binary libraries, e.g. '/PD900' & QSYS/PD900. Because the IBM i

platform's QSYS libraries exist in a flat hierarchical structure it is not possible to have two distinct PD900 libraries. This is

unlike Windows and Unix platforms where these install paths could exist on unique mount points, e.g.

/u01/app/JDEdwards/e900_tz0/PD900. As a result for the IBM i platform it is necessary for the replicated PATHCODE objects to be defined with an addendum that is unique to each supported time zone system foundation

instance. This addendum is defined in the time zone system foundation's JDE.INI file.

The JDE.INI ApplicationPathAddendum addendum (TZnN) is concatenated as a suffix to the replicated objects common name (PD900). The resulting replicated object names will be PD900TZ0N, PD900TZ5N, and PD900TZ6N. Below are instructions for generating unique sets of replicated objects via IBM i platform save and restore commands.

cmd: ADDLIBLE E900SYS cmd: ENDNET cmd: CLRIPC



cmd: CRTLIB TZLIB cmd: CRTSAVF TZLIB/PD900IFS cmd: CRTSAVF TZLIB/PD900

cmd: SBMJOB CMD(SAVLIB LIB(PD900) DEV(*SAVF) SAVF(TZLIB/PD900)) JOB(PD900) cmd: SBMJOB CMD(SAV DEV('/QSYS.LIB/TZLIB.LIB/PD900IFS.FILE') OBJ(('/PD900')) SUBTREE(*ALL)) JOB(PD900IFS)

cmd: CRTLIB PD900TZ0N cmd: CRTLIB PD900TZ5N cmd: CRTLIB PD900TZ6N

cmd: CHGOBJOWN OBJ(PD900TZ0N) OBJTYPE(*LIB) NEWOWN(ONEWORLD) cmd: CHGOBJOWN OBJ(PD900TZ5N) OBJTYPE(*LIB) NEWOWN(ONEWORLD) cmd: CHGOBJOWN OBJ(PD900TZ6N) OBJTYPE(*LIB) NEWOWN(ONEWORLD)

cmd: GRTOBJAUT OBJ(PD900TZ0N) OBJTYPE(*LIB) USER(*PUBLIC) AUT(*CHANGE) cmd: GRTOBJAUT OBJ(PD900TZ5N) OBJTYPE(*LIB) USER(*PUBLIC) AUT(*CHANGE) cmd: GRTOBJAUT OBJ(PD900TZ6N) OBJTYPE(*LIB) USER(*PUBLIC) AUT(*CHANGE)

cmd: MKDIR '/PD900TZ0N' cmd: MKDIR '/PD900TZ5N' cmd: MKDIR '/PD900TZ6N'

cmd: CHGOWN OBJ('/PD900TZ0N') NEWOWN(ONEWORLD) cmd: CHGOWN OBJ('/PD900TZ5N') NEWOWN(ONEWORLD) cmd: CHGOWN OBJ('/PD900TZ6N') NEWOWN(ONEWORLD)

cmd: CHGAUT OBJ('/PD900TZ0N') USER(*PUBLIC) DTAAUT(*RWX) OBJAUT(*ALL) cmd: CHGAUT OBJ('/PD900TZ5N') USER(*PUBLIC) DTAAUT(*RWX) OBJAUT(*ALL) cmd: CHGAUT OBJ('/PD900TZ6N') USER(*PUBLIC) DTAAUT(*RWX) OBJAUT(*ALL)

cmd: SBMJOB CMD(RSTLIB SAVLIB(PD900) DEV(*SAVF) SAVF(TZLIB/PD900) RSTLIB(PD900TZ0N)) JOB(PD900TZ0N) cmd: SBMJOB CMD(RST DEV('/QSYS.LIB/TZLIB.LIB/PD900IFS.FILE') OBJ(('/PD900' *INCLUDE '/PD900TZ0N')) SUBTREE(*ALL)) JOB(PD900ITZ0N)





Edit the new time zone specific System Foundation instance JDE.INI file. Modify the JDE.INI file's [SVR] ApplicationPathAddendum value to be equivalent to the time zone specific addendum, e.g. ApplicationPathAddendum=TZ0N.

Below is an example of the required change for a single System Foundation instance. This process must be repeated for

each time zone specific System Foundation instance.

cmd: EDTF '/E900SYST0N/INI/JDE.INI' cmd: EDTF '/E900SYST5N/INI/JDE.INI' cmd: EDTF '/E900SYST6N/INI/JDE.INI'

Figure 5: Modify the JDE.INI ApplicationPathAddendum

Edit File: /E900SYST0N/INI/JDE.INI Record : 58 of 758 by 10 Control : F ApplicationPathAddendum

CMD ....+....1....+....2....+....3....+....4... ApplicationPathAddendum=TZ0N



Edit each time zone specific source physical file member. Set the tzdiff, tname, and dstname values for each time zone.

tzdiff - The time zone difference to the desired value a positive number represents the difference from GMT

tname - The name of the time zone during standard time

dstname - The name of the time zone during daylight savings time

dststart - The start of daylight savings time

dstend - The end of daylight savings time

dstshift - The daylight savings shift

In the example below for the United States Eastern Time Zone, the value (tzdiff) should be set to 300. This represents 300

minutes (5 hours) after Greenwich Mean Time. The name of the time zone during Standard time (tname) is EST. The

name of the time zone during Daylight savings time (dstname) is EDT. Daylight saving time (dststart) starts the third

month of the year, the beginning of the second week, the first day of the week, and 7200 seconds (120 minutes) after

midnight local standard time. Daylight saving time ends (dstend) the tenth month of the year, the beginning of the third

week, the sixth day of the week, and 0 seconds after midnight local standard time. The daylight savings change (dstshift) is

3600 seconds or 1 hour.

cmd: WRKMBRPDM QGPL/MYLOCALES EN_US_ET

Figure 6: Modify the Locale Time Zone Specific File (EN_US_ET)

Columns . . . : 1 100 Edit SEU==>

FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 0005.57 END LC_MESSAGES 0005.58 0005.59 LC_TOD 0005.60 0005.61 tzdiff 300 0005.62 tname "EST" 0005.63 dstname "EDT" 0005.64 dststart 3,2,1,7200 0005.65 dstend 10,3,6,0 0005.66 dstshift 3600 0005.67 0005.68 END LC_TOD ****************** End of data **************************************

As each time zone specific locale member is edited, the locale specific object must be generated. The commands below

will create the locale specific objects.

cmd: CRTLOCALE LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN5.LOCALE') SRCFILE('/QSYS.LIB/QGPL.LIB/MYLOCALES.FILE/EN_US_ET.MBR') CCSID(37) TEXT('US - Eastern Time : New York GMT Negative 5')

cmd: CRTLOCALE LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN6.LOCALE') SRCFILE('/QSYS.LIB/QGPL.LIB/MYLOCALES.FILE/EN_US_CT.MBR') CCSID(37) TEXT('US - Central Time : Chicago GMT Negative 6')



cmd: CRTLOCALE LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN7.LOCALE') SRCFILE('/QSYS.LIB/QGPL.LIB/MYLOCALES.FILE/EN_US_MT.MBR') CCSID(37) TEXT('US - Mountain Time : Denver GMT Negative 7')

cmd: CRTLOCALE LOCALE('/QSYS.LIB/QGPL.LIB/ENGB_GMT.LOCALE') SRCFILE('/QSYS.LIB/QGPL.LIB/MYLOCALES.FILE/EN_GB_GMT.MBR') CCSID(37) TEXT('GB - Greenwich Mean Time : London')

When the locale specific objects are generated, user profiles (user accounts) can be created and associated to their

appropriate time zone locale object. This is described immediately below. Notice below that each user has been assigned

'JDE' as its group profile and 'ONEWORLD' as its supplemental group profile. These new users will inherit the authorities of

and have access to all objects owned by users 'JDE' and 'ONEWORLD'.

cmd: CRTUSRPRF USRPRF(NEWYORK) USRCLS(*PGMR) INLPGM(JDEOW/BV3C) TEXT('ONEWORLD - GMT_Minus_5') SPCAUT(*JOBCTL) JOBD(QGPL/ONEWORLD) GRPPRF(JDE) OWNER(*GRPPRF) SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN5.LOCALE')

cmd: CRTUSRPRF USRPRF(CHICAGO) USRCLS(*PGMR) INLPGM(JDEOW/BV3C) TEXT('ONEWORLD - GMT_Minus_6') SPCAUT(*JOBCTL) GRPPRF(JDE) JOBD(QGPL/ONEWORLD) OWNER(*GRPPRF) SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN6.LOCALE')

cmd: CRTUSRPRF USRPRF(DENVER) USRCLS(*PGMR) INLPGM(JDEOW/BV3C) TEXT('ONEWORLD - GMT_Minus_7') SPCAUT(*JOBCTL) GRPPRF(JDE) JOBD(QGPL/ONEWORLD) OWNER(*GRPPRF) SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN7.LOCALE')

cmd: CRTUSRPRF USRPRF(LONDON) USRCLS(*PGMR) INLPGM(JDEOW/BV3C) TEXT('ONEWORLD - GMT') SPCAUT(*JOBCTL) GRPPRF(JDE) JOBD(QGPL/ONEWORLD) OWNER(*GRPPRF)SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENGB_GMT.LOCALE')

With the time zone specific user profile created, each time zone specific System Foundation instance can be modified to

use the time zone specific user as shown below. This change will start the EnterpriseOne services with specified user.

cmd: CHGJOBD JOBD(E900SYST0N/NETJOBD) USER(LONDON) cmd: CHGJOBD JOBD(E900SYST5N/NETJOBD) USER(NEWYORK) cmd: CHGJOBD JOBD(E900SYST6N/NETJOBD) USER(CHICAGO) cmd: CHGJOBD JOBD(E900SYS/NETJOBD) USER(DENVER)

Third party products connecting to the EnterpriseOne database but bypassing EnterpriseOne services can leverage

platform operating system user accounts whose LOCALE specific setting matches the desired time zone. The command

below creates users with 'JDE' assigned as their group profile and 'ONEWORLD' as their supplemental group profile.

These new users will inherit the authorities of and have access to all objects owned by users 'JDE' and 'ONEWORLD'. Further by

setting OWNER to *GRPPRF this ensures that any objects created by these users will be owned by user 'JDE'.

Note: The EnterpriseOne proxy (system) users must also be updated to use the user profile

LOCALE('/QSYS.LIB/QGPL.LIB/xxxx.LOCALE') attribute. This will ensure that all UBE database table updates and the UBE Submitted Job table's run time properly represent the user's associated time zone.

cmd: CRTUSRPRF USRPRF(OWJDEGMT) USRCLS(*PGMR) TEXT('E1 DB USER - GMT') SPCAUT(*JOBCTL) GRPPRF(JDE) OWNER(*GRPPRF) SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENGB_GMT.LOCALE')



cmd: CRTUSRPRF USRPRF(OWJDETZ5N) USRCLS(*PGMR) TEXT('E1 DB USER - GMT_Minus_5') SPCAUT(*JOBCTL) GRPPRF(JDE) OWNER(*GRPPRF) SUPGRPPRF(ONEWORLD) LOCALE('/QSYS.LIB/QGPL.LIB/ENUS_GMTN5.LOCALE')



Figure 7: Work with Active Jobs (Subsystems by Time Zone)

Work with Active Jobs JDE900SVR 07/27/11 23:05:22 CPU %: .0 Elapsed time: 00:00:00 Active jobs: 395 Current

Opt Subsystem/Job User Type CPU % Function Status __ JDEE900 QSYS SBS .0 DEQW __ JDENET_K DENVER BCI .0 PGM-JDENET_K DEQW __ JDENET_K DENVER BCI .0 PGM-jvmStartPa DEQW ...

__ NETWORK DENVER BCH .0 PGM-JDENET_N SELW __ JDE900TZ0N QSYS SBS .0 DEQW __ JDENET_K LONDON BCI .0 PGM-JDENET_K DEQW __ JDENET_K LONDON BCI .0 PGM-jvmStartPa DEQW ...

__ NETWORK LONDON BCH .0 PGM-JDENET_N SELW __ JDE900TZ5N QSYS SBS .0 DEQW __ JDENET_K NEWYORK BCI .0 PGM-JDENET_K DEQW __ JDENET_K NEWYORK BCI .0 PGM-jvmStartPa DEQW ...

__ NETWORK NEWYORK BCH .0 PGM-JDENET_N SELW __ JDE900TZ6N QSYS SBS .0 DEQW __ JDENET_K CHICAGO BCI .0 PGM-JDENET_K DEQW __ JDENET_K CHICAGO BCI .0 PGM-jvmStartPa DEQW ...

__ NETWORK CHICAGO BCH .0 PGM-JDENET_N SELW __ QBATCH QSYS SBS .0 DEQW



Configuring EnterpriseOne JAS HTML JVMs for Different Time Zones This section provides an overview of the steps necessary to configure EnterpriseOne JAS HTML JVMs and JAS INI files

for specific time zones.

Configure the Application Server JAS HTML JVM to use a Specific Time Zone The JVMs can be configured with a time zone offset and should be configured to execute business logic in an

EnterpriseOne instance where the time zone matches that of the JVM. Changes to the JVM must be applied to the Java

arguments associated with the Application Server's instance, e.g. via the IBM WebSphere Administrative Console.

Figure 8: Java Generic Arguments for Time Zone Offset by JAS HTML Instance

VIRTUALSERVER JAS HTML Java Generic Argument TIMEZONE

JDE900TZ7N I507WAS792 -Duser.timezone=GMT+7 Denver

JDE900TZ6N I507WAS798 -Duser.timezone=GMT+6 Chicago

JDE900TZ5N I507WAS797 -Duser.timezone=GMT+5 NewYork

JDE900TZ0N I507WAS796 -Duser.timezone=GMT London

Important: Different distributions of java and even varying java release levels derive time zones differently. When adding a java argument (-Duser.timezone=GMT+7) to offset the Java Virtual Machine's (JVM) time one may find that time is derived as a factor of system time compensated by the added java offset. In other cases time is a factor of Greenwich Mean Time (GMT) coupled with the java argument offset, where GMT is calculated as the system's time compensated by the system's defined time zone. Thus, it is important to check the JVM's specific job logs to ensure they represent the intended time zone.

Note: The JVM log messages shown below are from an Oracle WebLogic server; it includes the GMT offset notation as part of the date-timestamp. This GMT offset notation does not appear in an IBM Websphere Server log date-timestamps. Figure 9: Java Virtual Machine Logging Messages



Configuring the IBM WebSphere Application Server

a. Login to the IBM WebSphere Administrative Console. From the left-hand entry menu expand the Servers node, Server Types, and click on WebSphere application servers. Select the web container associated with the JVM that will use the MT time zone.

Figure 10: Modify the Application Server Configuration(s)

b. Scroll down and expand the Java and Process Management node found under the Server Infrastructure heading; click Process Definition.

Figure 11: Navigate to the Java and Process Management | Server Infrastructure | Process Definition



c. Click the Java Virtual Machine hyperlink found under Additional Properties. Scroll downward to the bottom of the

web page and locate the Generic JVM arguments field. Add the time zone value offset to the value(s) already found in this field. For instance: , -Duser.timezone=GMT+7 would be added to the existing value making the value string: -Djava.awt.headless=true, -Duser.timezone=GMT+7. Note that the , (comma or semicolon) delimiter may vary depending upon the operating system platform on which the WebSphere Application

Server is running.

Figure 12: Modify the Java Virtual Machine | Generic JVM arguments to use a specific Time Zone

d. Click the Apply button (shown in the figure above). Then click the Save button two more times from different Save forms (shown below). Stop and restart the web server, then check the server's logs to ensure the timestamp value represents the intended time.

Figure 13: Save and Apply the Change Made to the Application Server


15

Configuring the Oracle WebLogic Server

a. Login to the Oracle WebLogic Administrative Console. From the left-hand menu control Domain Structure expand the Environment node and click the Servers hyperlink.

Figure 14: Navigate to the Configured Domain Servers

b. Select the server (web container) associated with the JVM that will use the MT time zone, e.g. dendell06_html_7003.

Figure 15: Select the Web Container for Modification


16

c. Navigate to the upper left-hand corner of the Oracle WebLogic Administrative Console page and click the Lock & Edit button.

Figure 16: Select Server Start Tab

d. Click the Server Start tab to change the server's configuration focus. Scroll downward to the bottom of the web page and locate the Arguments field. Add the time zone value offset to the value(s) already found in this field. For instance: , -Duser.timezone=GMT+7 would be added to the existing value making the value string: -XX:MaxPermSize=128m -Xms32m -Xmx768m -Duser.timezone=GMT+7. Note: Take care not to introduce a carriage return. The arguments must be read as a contiguous string without any edit controls.

Figure 17: Modify the Java Arguments Found in the Server Start Tab


17

e. Scroll down and click the Save button found at the bottom portion of the Server Start screen.

Figure 18: Click the Save Button Found at the Bottom of the Server Start Tab

f. Click the Activate Changes button.

Figure 19: Click the Activate Changes Button

g. Click the Summary of Servers hyperlink.

Figure 20: Navigate to Summary of Servers


18

h. Click the Control tab. Click the check-box that precedes the server entry that was changed in the previous steps. Click the Shutdown button (a forced shutdown may be necessary). The server will be shutdown. As before click the check-box that precedes the web container server entry and click the Start button to restart the server. Check the server's logs to ensure the timestamp value represents the intended time.

Figure 21: Shutdown & Restart the Server


19

Configure the JD Edwards EnterpriseOne JAS INI Files Each JD Edwards EnterpriseOne JAS server should be linked to a JD Edwards EnterpriseOne Enterprise Server with a

similar time zone setting. Ensure that the JAS.INI & JDBJ.INI file's are set to the time zone specific values as shown

directly below. These values should match the targeted Enterprise Server.

JAS.INI

[SECURITY] NumServers=1 SecurityServer=JDE900TZ0N


20

JD Edwards EnterpriseOne CNC System Administration Considerations This section provides an overview of the CNC considerations to configuring EnterpriseOne for use with delineated

System Foundation time zone instances.

Time Zone Configuration Code Specific Considerations JD Edwards EnterpriseOne tools release 9.1 introduced code changes making it possible for the JD Edwards

EnterpriseOne Services to bind its listening port to a time zone specific virtual IP address and virtual hostname. A new

JDE.INI file setting has been introduced, e.g. stanza and statement [JDENET] listenOnSpecificIP. When the

listenOnSpecificIP statement is enabled the EnterpriseOne JDENET Services will bind only to the virtual hostname's IP address named as the JDE.INI [CLUSTER] PrimaryNode value. If the JDE.INI file's [JDENET]

listenOnSpecificIP is disabled, the JDENET port (6015) binding occurs at the global IP address level 0.0.0.0; this global IP binding affects all physical and virtual IP addresses found on the local machine.

JDE.INI

[JDENET] listenOnSpecificIP=1


21

JPD900LON DEFAULT JDE900TZ0N - Logic *PUBLIC BSFN AV JPD900NYC DEFAULT JDE900TZ5N *PUBLIC UBE AV JPD900NYC DEFAULT JDE900TZ5N - Logic *PUBLIC BSFN AV PD900CHI DEFAULT JDE900TZ6N *PUBLIC UBE AV PD900CHI DEFAULT JDE900TZ6N - Logic *PUBLIC BSFN AV PD900DEN DEFAULT JDE900TZ7N *PUBLIC UBE AV PD900DEN DEFAULT JDE900TZ7N - Logic *PUBLIC BSFN AV PD900LON DEFAULT JDE900TZ0N *PUBLIC UBE AV PD900LON DEFAULT JDE900TZ0N - Logic *PUBLIC BSFN AV PD900NYC DEFAULT JDE900TZ5N *PUBLIC UBE AV PD900NYC DEFAULT JDE900TZ5N - Logic *PUBLIC BSFN AV

3. Create EnterpriseOne time zone specific roles. Associate the time zone specific environment to the time zone specific

role. Each EnterpriseOne user (role) is associated only with those environments that are linked to the user's respective

time zone.

4. Associate the EnterpriseOne user to the time zone specific role.

Figure 22: Time Zone Specific Environments / Roles / Users Assignments

VIRTUAL

SERVER TIMEZONE

E1

TIMEZONE

ENVIRON

E1 USER

TIMEZONE

ROLE

E1 USER ACCT ASSOCIATED

WITH TIMEZONE ROLE

SERVER MAP


JDE900TZ7N Denver JPD900DEN JDETZ7N

MANISH, KELLI, SEAMUS,

CHARUNEE, SOLANGE, SVM900

JDE900TZ7N - 900 Server

Map

JDE900TZ6N Chicago JPD900CHI JDETZ6N

KATE, TIM, CRYSTAL,

SERGIO, BECKY, SVM900TZ6N


Map

JDE900TZ5N NewYork JPD900NYC JDETZ5N

SRINI, DONNA, SYDNEY,

ROBERTA, CAROLINE, SVM900TZ5N


Map

JDE900TZ0N London JPD900LON JDEGMT

PREETI, BRENDON, KARA,

SUZANNE, COLIN, SVM900TZ0N


Map


22

APPENDIX A: REPLICATING YOUR SYSTEM FOUNDATION INSTANCE Use the instructions directly below if you wish to replicate your current System Foundation instance to another. Substitute

the target System Foundation instance name and values as needed.

cmd: CRTLIB JDETEMP

cmd: ADDLIBLE E900SYS

cmd: ENDNET

cmd: CLRIPC

cmd: CRTSAVF JDETEMP/E900SYS

cmd: CRTSAVF JDETEMP/E900SYSIFS

cmd: SBMJOB CMD(SAVLIB LIB(E900SYS) DEV(*SAVF) SAVF(JDETEMP/E900SYS) OMITOBJ((*ALL *SQLPKG))) JOB(E900SYS)

cmd: SBMJOB CMD(SAV DEV('/QSYS.LIB/JDETEMP.LIB/E900SYSIFS.FILE') OBJ(('/E900SYS')) PATTERN(('*.PDF' *OMIT)) SUBTREE(*ALL))JOB(E900SYSIFS)

cmd: MKDIR '/E900SYST0N'

cmd: MKDIR '/E900SYST0N/LOGS'

cmd: CHGOWN OBJ('/E900SYST0N') NEWOWN(ONEWORLD) SUBTREE(*ALL)

cmd: CRTLIB E900SYST0N

cmd: CHGOBJOWN OBJ(E900SYST0N) OBJTYPE(*LIB) NEWOWN(ONEWORLD)

Wait for the above listed jobs to end successfully.

cmd: SBMJOB CMD(RSTLIB SAVLIB(E900SYS) DEV(*SAVF) SAVF(JDETEMP/E900SYS) RSTLIB(E900SYST0N)) JOB(R900SYS)

cmd: SBMJOB CMD(RST DEV('/QSYS.LIB/JDETEMP.LIB/E900SYSIFS.FILE') OBJ(('/E900SYS' *INCLUDE '/E900SYST0N') (PATTERN)) PATTERN(('*.PDF' *OMIT)) SUBTREE(*ALL)) JOB(R900SYSIFS)

Edit the System Foundation instance JDE.INI file. Change references to the System Foundation instance specific values, e.g. E900SYST0N, addendum TZ0N, start IPC 6301, bootstrap data source JDE900TZ0N - 900 Server Map, DatabaseName2 SVM900TZ0N, instanceName JDE900TZ0N_EntSrvr_TZ_neg_0_London, etc.

Figure 23: Virtual Time Zone Server Manager Instance Information

SERVER MANAGER INSTANCE

NAME

SYSTEM

FOUNDATION

SERVER

HOST NAME PORT

START

IPC

SERVER MAP


JDE900TZ7N_EntSrvr_TZn7_De

nver E900SYST7N

JDE900TZ7N 6015 0001 SVM900 JDE900TZ7N - 900 Server Map

JDE900TZ6N_EntSrvr_TZn6_Ch

icago E900SYST6N

JDE900TZ6N 6015 2101


JDE900TZ5N_EntSrvr_TZn5_Ne

wYork E900SYST5N

JDE900TZ5N 6015 4201


JDE900TZ0N_EntSrvr_TZn0_Lo

ndon E900SYST0N

JDE900TZ0N 6015 6301



23

cmd: EDTF '/E900SYST0N/INI/JDE.INI'

Figure 24: Edit the JDE.INI Replacing the System Foundation Library Name

Edit File: /E900SYST0N/INI/JDE.INI Record : 1 of 758 by 10 Column : 1 Control : c /E900SYS/ /E900SYST0N/ all

CMD ....+....1....+....2....+....3....+....4....+....5....+....6....+....7. ************Beginning of data************** ; JD Edwards initialization file INI(JDE) ; AS/400 specific version - E900

[JDE_CG] CLASSPATH=/E900SYS/classes/xalan.jar:/E900SYS/classes/xerces.jar:/E900S ServerPackageSleep=60

[DEBUG] Output=FILE

Repeat the change all (search / replace).

Figure 25: Edit the JDE.INI Replacing the Logging Directory Path

Edit File: /E900SYST0N/INI/JDE.INI Record : 9 of 758 by 10 Col Control : c /JDE900/ /E900SYST0N/LOGS/ all

CMD ....+....1....+....2....+....3....+....4....+....5....+... [DEBUG] Output=NONE Trace=FALSE DebugFile=/JDE900/JDEDEBUG JobFile=/JDE900/JDE.LOG JDETSFile=/JDE900/JDETS.LOG LogErrors=1 ClientLog=0 KeepLogs=1

Find CLUSTER and set the value to the Virtual Hostname.

Figure 26: Edit the JDE.INI to Modify the PrimaryNode Value

Edit File: /E900SYST0N/INI/JDE.INI Record : 670 of 689 by 10 Control : F CLUSTER

CMD ....+....1....+....2....+....3....+....4.... [CLUSTER] PrimaryNode=JDE900TZ0N


24

Go to the top of the file; type a 'T' in the 'Control: _' field and press ENTER. Find [JDENET] listenOnSpecificIP and replace the value.

Figure 27: Edit the JDE.INI to Modify the [JDENET] listenOnSpecificIP Value to '1'

Edit File: /E900SYST0N/INI/JDE.INI Record : 99 of 690 by 10 Colum Control : F JDENET]

CMD ....+....1....+....2....+....3....+....4....+....5....+....6 internalQueueTimeOut=30 FilePacketBufferSize=32768 netTemporaryDir=/JD Edwards/JDE_HOME/targets/JDE900TZ0N_EntSr listenOnSpecificIP=1


25

Go to the top of the file; type a 'T' in the 'Control: _' field and press ENTER. Find ApplicationPathAddendum and replace the value.

Figure 30: Modify the JDE.INI ApplicationPathAddendum

Edit File: /E900SYST0N/INI/JDE.INI Record : 58 of 758 by 10 Control : F ApplicationPathAddendum

CMD ....+....1....+....2....+....3....+....4... ApplicationPathAddendum=TZ0N


26

APPENDIX B: ENTERPRISEONE TABLES WITH HOSTNAME REFERENCES The tables below are core to EnterpriseOne and must be properly configured to identify each added virtual hostname.

Tables not named here are those related to UBE scheduling, real time events, etc.

Data Source Master Table (F98611) found in SY900 & SVM900:

SELECT SUBSTR(OMDATP, 1, 27) OMDATP, SUBSTR(OMSRVR, 1, 12) OMSRVR, SUBSTR(OMDATB, 1, 27),

OMOCM1 FROM SY900.F98611;

OMDATP OMSRVR OMDATB OMOCM1 Business Data - PROD JDE900SVR Business Data - PROD DB Business Data - TEST JDE900SVR Business Data - TEST DB Central Objects - DV900 JDE900SVR Central Objects - DV900 DB Central Objects - PD900 JDE900SVR Central Objects - PD900 DB Control Tables - Prod JDE900SVR Control Tables - Prod DB Control Tables - Test JDE900SVR Control Tables - Test DB JDE900TZ7N JDE900TZ7N JDE900TZ7N - 900 Server Map SVR JDE900TZ7N - 900 Server Map JDE900SVR JDE900SVR - 900 Server Map DB JDE900TZ7N - Logic JDE900TZ7N JDE900SVR - 900 Server Map SVR JDE900TZ7N - RTE JDE900TZ7N JDE900SVR - 900 Server Map SVR JDE900TZ7N - XAPI JDE900TZ7N JDE900SVR - 900 Server Map SVR Data Dictionary - 900 JDE900SVR Data Dictionary - 900 DB JDBTSTLIB JDE900SVR JDBTSTLIB DB JDE900TZ0N JDE900TZ0N JDE900TZ0N - 900 Server Map SVR JDE900TZ0N - 900 Server Map JDE900SVR JDE900TZ0N - 900 Server Map DB JDE900TZ0N - Logic JDE900TZ0N JDE900TZ0N - 900 Server Map SVR JDE900TZ0N - RTE JDE900TZ0N JDE900TZ0N - 900 Server Map SVR JDE900TZ0N - XAPI JDE900TZ0N JDE900TZ0N - 900 Server Map SVR JDE900TZ5N JDE900TZ5N JDE900TZ5N - 900 Server Map SVR JDE900TZ5N - 900 Server Map JDE900SVR JDE900TZ5N - 900 Server Map DB JDE900TZ5N - Logic JDE900TZ5N JDE900TZ5N - 900 Server Map SVR JDE900TZ5N - RTE JDE900TZ5N JDE900TZ5N - 900 Server Map SVR JDE900TZ5N - XAPI JDE900TZ5N JDE900TZ5N - 900 Server Map SVR JDE900TZ6N JDE900TZ6N JDE900TZ6N - 900 Server Map SVR JDE900TZ6N - 900 Server Map JDE900SVR JDE900TZ6N - 900 Server Map DB JDE900TZ6N - Logic JDE900TZ6N JDE900TZ6N - 900 Server Map SVR JDE900TZ6N - RTE JDE900TZ6N JDE900TZ6N - 900 Server Map SVR JDE900TZ6N - XAPI JDE900TZ6N JDE900TZ6N - 900 Server Map SVR LOCAL LOCAL Planner - 900 SVR Local - DV900 (local) EnterpriseOne SSELocal DB Local - DV900 Specs (local) EnterpriseOne SSELocal DB Local - PD900 (local) EnterpriseOne SSELocal DB Local - PD900 Specs (local) EnterpriseOne SSELocal DB OWJRNL JDE900SVR OWJRNL DB Object Librarian - 900 JDE900SVR Object Librarian - 900 DB System - 900 JDE900SVR System - 900 DB System - 900NJ JDE900SVR System - 900NJ DB Versions - DV900 JDE900SVR Versions - DV900 DB


27

Versions - PD900 JDE900SVR Versions - PD900 DB WAS7PDTZ0N JDE900SVR WAS7PDTZ0N DB WAS7PDTZ5N JDE900SVR WAS7PDTZ5N DB WAS7PDTZ6N JDE900SVR WAS7PDTZ6N DB WAS7PDTZ7N JDE900SVR WAS7PDTZ7N DB

Job Queue Control Status Master Table (F986130):

SELECT SUBSTR(QCEXEHOST,1,12) QCEXEHOST, QCPORTNM, QCJOBQUE FROM SY900.F986130 ORDER BY 1, 3

QCEXEHOST QCPORTNM QCJOBQUE JDE900SVR 6015 QBATCH JDE900TZ0N 6015 QBATCH JDE900TZ5N 6015 QBATCH JDE900TZ6N 6015 QBATCH JDE900TZ7N 6015 QBATCH

Active Deployed Pathcode Package Server Detail (F96511):

SELECT SUBSTR(SKMKEY, 1, 12) SKMKEY, SKPORTNUM, SKPATHCD, SKMCHDETTYP, SKSERSHP FROM SY900.F96511

SKMKEY SKPORTNUM SKPATHCD SKMCHDETTYP SKSERSHP

JDE900SVR 6015 PD900 31 PD900FC

JDE900SVR 6015 PD900 33 Central Objects - PD900 JDE900TZ0N 6015 PD900 31 PD900FC

JDE900TZ0N 6015 PD900 33 Central Objects - PD900 JDE900TZ5N 6015 PD900 31 PD900FC



JDE900TZ7N 6015 PD900 33 Central Objects - PD900

Other Enterprise Server tables with specific references to the virtual host name(s).

Table Description: SQL Statement:

Software Package Build Header: SELECT * FROM SY900.F96021

Software Package Build Header - History: SELECT * FROM SY900.F96215

Software Package Build Detail: SELECT * FROM SY900.F9622

Software Package Build Detail - History: SELECT * FROM SY900.F96225

Machine Master: SELECT * FROM SY900.F9650

Machine Detail: SELECT * FROM SY900.F9651

Table and Data Source Sizing Table: SELECT * FROM SY900.F986115

Default Printer Table: SELECT * FROM SY900.F986167

Package Deployment on Servers Information: SELECT * FROM SY900.F98826


28

APPENDIX C: PACKAGE BUILD AND DEPLOY CONSIDERATIONS When building a package use the JDE.INI [BSFN BUILD] DoCompression=1 option to compress the 'server' package. This setting is defined on the client/deployment workstation. See the "Package Management Guide" for more

information related to compressing server packages. Once a server package has been built, deployed, and certified for use

it can be deployed to other time zone specific virtual server(s).

Note: Use of the Server Package Compression feature for the time zone solution is recommended for all JD Edwards EnterpriseOne server

platforms with the exception of the IBM i platform. See "Package Deployment for the IBM i Platform" further below.

Package Deployment Considerations

Each time zone instance should have an EnterpriseOne JDE CNC user whose OCM mappings point to the correct time

zone specific server. The Deployment Server's local database should also have a record of each JDE CNC time zone

instance user(s). When deploying a package, login to the Deployment Server with the appropriate user, e.g. JDENYC. This user should be used to deploy a package against its associated time zone specific server.

Note: Failure to use a time zone specific JDE CNC user to deploy a package could lead to unpredictable mutex wait

locking. For example, a user logs in as JDE to deploy a package to virtual host JDE900TZ6N. Following a successful deploy the same user deploys a package against virtual host JDE900TZ0N. Because JDENET communication is now active between the workstation and two servers, e.g. JDE900TZ6N, JDE900TZ0N potentially both servers will throw a mutex wait to suspend all activity so that the package can be successfully deployed. To mitigate this JDENET cross-

communication opportunity, login with the appropriate JDE CNC user to deploy a package on each virtual server.

Package Deployment for the IBM i Platform

Since the IBM i platform has a flat QSYS library and IFS structure there can only be 'one' package location, e.g.

QSYS/PD900FE and /OneWorld/Packages/PD900FE. If one were to use the compressed package option on the IBM i

platform where more than one host or virtual host EnterpriseOne foundation instance share a common package, the

deploy process will step over itself. This occurs as the deploy process attempts to replace the pre-existing package library

and IFS folder objects.

On the IBM i platform build a single package without the compression option, choosing either the primary host or a

virtual host. For example package PD900FE is built against the primary time zone server's hostname. Three other virtual

host EnterpriseOne instances are active on the same IBM i platform server. Each have their own application foundation

runtime SPECs (via the INI addendum). To deploy a common package to each virtual server we must first manually

create a 'build' record for each of these virtual host servers. The instructions that follow create the server package records

necessary for package deployment. This process mimics the record creation process that would occur were a successful

package build were performed against each additional virtual host server(s).

Package PD900FE is built against the primary server, e.g. JDEENTSVR.

10.123.123.51 JDE900TZ6N.DOMAIN.COM JDE900TZ6N



10.123.123.54 JDEENTSVR.DOMAIN.COM JDEENTSVR JDE900TZ7N.DOMAIN.COM JDE900TZ7N


29

1. Manually create a record(s) in the F96021 table for each time zone specific virtual host server. The yellow highlighted

font represents the target virtual host names, while the blue highlighted font identifies the package name and build server

name.

INSERT INTO SY900/F96021 (SELECT T3.BHPKGNAME, T3.BHPATHCD, 'JDE900TZ0N' BHDATP, T3.BHBLDSTS, T3.BHPKG1, T3.BHBLDDTE, T3.BHBLDPCK, T3.BHBLDFUNC, T3.BHBLDTYPE, T3.BHCLRDST, T3.BHACCUMLOG, T3.BHSTOPBUSBLD, T3.BHSTOPBLD, T3.BHBLDDOC, T3.BHCMPPKG, T3.BHALLCOMP, T3.BHALLSPEC, T3.BHTRNNOBLD, T3.BHPKGBULFUT1, T3.BHPKGBULFUT2, T3.BHPKGBULFUT3, T3.BHPKGBULFUT4, T3.BHPID, T3.BHJOBN, T3.BHUPMJ, T3.BHUPMT, T3.BHUSER FROM SY900/F96021 T3 WHERE T3.BHPKGNAME = 'PD900FE' AND T3.BHDATP = 'JDEENTSVR' AND BHBLDSTS = 50)



2. Create an INF file for each 'virtual host' server based upon the original INF file.

cp \\\E900\PD900\package\PD900FE\AS400V7R1M0\JDEENTSVR.INF \\\E900\PD900\package\PD900FE\AS400V7R1M0\JDE900TZ0N.INF


30

APPENDIX D: HIGH AVAILABILITY LOAD BALANCING CONSIDERATIONS An 'active-active' or load-balancing cluster solution is one where two or more active physical node servers sharing a common

logical cluster name are made available via a 'load-balancing' intelligent network appliance. This type of solution is generally used

by businesses which run in a 24/7 (twenty four hours a day, by seven days a week) around the clock environment. Time zone support for

servers using an 'active-active' or load-balancing cluster solution require the configuration of additional virtual node servers.

Note: Oracle JD Edwards does not explicitly support high availability active-active load balancing cluster solutions for the JD Edwards

Enterprise Server (application/logic/batch server). These types of solutions rely heavily on the use of specially architected third-party hardware

and software products. That said, there are many Oracle customers who run both JD Edwards EnterpriseOne JAS/HTML and application

servers in a high availability cluster arrangement.

High Availability Load Balancing Background

The figure below depicts a high availability 'active-active' load balancing cluster solution. In this example there are two server

groups shown in delineated node group sets. Associated with each node group is a JDEdwards EnterpriseOne Enterprise

(Logic) Server and JAS HTML Server. Each Enterprise Server is known by its physical node name (JDESRVA) and its logical cluster name (JDEENTSRV). The importance of pairing a logical server and JAS HTML server into a set will soon be made clear.

Figure 32: Standard High Availability 'Active-Active' Load Balancing Cluster


31

Referring to figure above, consider the following standard Package Deployment scenario for a high availability server running JDEdwards EnterpriseOne E812 and higher. During a package maintenance cycle we must perform the following after successfully building a full or update package that is error free:

1) A server set (Server Group B) will be made ineligible to new users via an intelligent network appliance/switch. 2) Optional to pre-generate serialized objects: The new full/update client package is deployed to the web generation

machine. The web generation machines JDBJ.INI file must be updated pointing to a serialized objects database location that is not currently in use. The web generation process commences.

3) When activity within Server Group B is quiesced (free of users and all batch activity), the JAS HTML server(s) are shutdown. The Package Deployment process is submitted to the Logic Server.

4) Optional to pre-generate serialized objects: Update the HTML Server JDBJ.INI files setting the serialized objects location to that used in step 2 above.

5) Review the logs to validate a successful package deployment and web generation process. 6) Start the JDEdwards EnterpriseOne Enterprise Server and JAS/HTML servers.

a. At application releases 8.12 and higher when packages are deployed which include SPEC updates there exists a spec auto-discovery process. This auto-discovery process compares the manifest information found in the serialized object tables to that associated with the server via table F96511.

b. If the serialized object's manifest and F96511 table record for the server are in sync nothing changes. c. If the serialized object's manifest and F96511 table record differ: (1) in the case of an update package(s) the

specific package item records are deleted from the serialized object tables (2) in the case of a full package the serialized object tables are truncated.

d. For servers that use a 'logical cluster name' it is recommended that the auto-discovery process be overridden by updating the HTML server's INI files. The value defined as the PackageDomainServer will be used in lieu of the 'logical cluster name'. By overriding the auto-discovery process it is possible to update a node server without impacting the opposing node server. Additionally it is recommended to use a unique set of serialized objects for each node server.

JAS.INI: [PACKAGE BUILD] ;PackageDomainServer=DEFAULT ;PackageDomainPort=0 PackageDomainServer=JDESRVB PackageDomainPort=6015

JDBJ.INI: [JDBj-SPEC DATA SOURCE] ...

name=SerObj_B2 database= server=JDEE1DB physicalDatabase=SEROBJB2 ...

Important: Failure to override the auto-discovery process may cause the serialized objects of an 'active' server to be unexpectedly truncated due to a perceived SPEC mismatch.

7) Test the server set by connecting to the HTML servers by physical IP address (as opposed to the logical IP address) so as to bypass the load-balancing mechanism.

8) Once the server set is certified, make the server set eligible for use within the cluster. 9) Repeat this process for each server set until all sets have been updated with the new deployed package.

Time Zone High Availability Load Balancing Considerations

The figure further below depicts a time zone specific high availability 'active-active' load balancing cluster solution. In this

case the logical server name is based upon the time zone that is represents, e.g. LONDON. Consider too that additional multiple virtual host servers will exist on each physical server, e.g. CHICAGO, TORONTO, DENVER. For purposes of

discussion we will focus on a single time zone server named LONDON. As before the two server groups are shown in delineated sets. All aspects of the time zone high availability 'active-active' load balancing cluster solution's layout are

identical to those in a standard load balancing configuration with one significant exception, the ability to address a specific

virtual node server.

To explain this difference consider that when updating one server node without impacting another one must deploy a

package to the server's physical host name rather than its logical cluster name. Since each server may have multiple virtual

servers we cannot use the server's true physical server name to deploy a package. Rather we must use a host name alias to


32

distinguish one time zone server node from another, e.g. LONDONA and LONDONB. In the figure below notice that

the common logical server name is LONDON, while the server's physical names are JDESRVA & JDESRVB, and the node server names are LONDONA & LONDONB, respectively.

Figure 33: Time Zone High Availability 'Active-Active' Load Balancing Cluster

To accomplish this server package deployment segmentation we must do the following:

1) Ensure that each physical host server defines within its own hosts table the common logical time zone server name and

specific time zone node alias, e.g. LONDON and LONDONA as shown directly below.

Host Table - Server Node A:

10.123.123.51 CHICAGO.DOMAIN.COM CHICAGO CHICAGOA.DOMAIN.COM CHICAGOA

10.123.123.52 TORONTO.DOMAIN.COM TORONTO TORONTOA.DOMAIN.COM TORONTOA

10.123.123.53 LONDON.DOMAIN.COM LONDON LONDONA.DOMAIN.COM LONDONA

10.123.123.54 DENVER.DOMAIN.COM DENVER DENVERA.DOMAIN.COM DENVERA


33

Host Table - Server Node B:

10.123.123.91 CHICAGO.DOMAIN.COM CHICAGO CHICAGOB.DOMAIN.COM CHICAGOB

10.123.123.92 TORONTO.DOMAIN.COM TORONTO TORONTOB.DOMAIN.COM TORONTOB

10.123.123.93 LONDON.DOMAIN.COM LONDON LONDONB.DOMAIN.COM LONDONB

10.123.123.94 DENVER.DOMAIN.COM DENVER DENVERB.DOMAIN.COM DENVERB

2) The WINS and/or DNS server must distinguish between the node specific host names, while the common logical

server name uses a logical IP address. From the perspective of all client servers, the time zone servers are accessible via

their logical IP addresses. Traffic to this logical IP address is routed by the intelligent network appliance to the appropriate backend

node server. The logical IP address is then transformed to the physical IP address via network address translation (NAT). 'Sticky IP' is

used to create an affinity between the client and backend node server so that communication persists between these

two servers.

WINS DNS Perspective:

10.123.123.11 CHICAGO.DOMAIN.COM CHICAGO


34

Time Zone Support for Oracle JD Edwards EnterpriseOne December 2011

Author: Michael Guerra, Oracle JD Edwards Contributing Author: Steve Fillipi, Oracle JD Edwards

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A.

Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com

Copyright 2011, Oracle. All rights reserved. This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

timezones for enterpriseone 91

Documents