5/7/23, 9:27 PM Document 782162.

1
Copyright (c) 2023, Oracle. All rights reserved. Oracle Confidential.

Mobile Web Applications (MWA) Troubleshooting Tips for Release 12 Mobile Web Applications
Server (Doc ID 782162.1)

APPLIES TO:

Oracle Mobile Application Server - Version 12.0 to 12.2.6 [Release 12.0 to 12.2]
Information in this document applies to any platform.

PURPOSE

To assist with the Setup and Troubleshooting of common issues seen in Support for Mobile Web Applications (MWA).

Release 12 has the same version of MWA as 11.5.10 with 1.0.8.4. All of the below principles will apply to R12 except for the
patching. MWA only changed the architecture for R12 of the directories, location of files and scripts, so that MWA can be
managed by AutoConfig.

Prod ID 995 MWA Support is under ATG and handles the Core MWA Server Configuration issues. Functional type issues are
handled by the specific product teams.

For 11i follow Note 269991.1 MWA Tips Troubleshooting Tips for Release 11i

TROUBLESHOOTING STEPS

Section 1 MWA Performance

Section 2 Patches
Section 3 Common Issues
Section 4 The Standard Commands for Stopping and Starting the MWA Server
Section 5 MWA Advanced Configurations
Section 6 MWA GUI and Device Configuration
Section 7 Causes as to why MWA Needs to be bounced
Section 8 How to use MWA in a Shared APPL_TOP environment
Section 9 MWA MULTI-LANGUAGE NLS-MLS Language Support
Section 10 Logging SR's to Support
Section 11 Getting Mobile Debug Log

Section 1 MWA Performance

1. It is not recommended to modify this variable within MWA without Oracle Support consent. However for Diagnostic
purposes, you can allocate more memory to the MWA server or reduce if too high for testing when having issues with MWA
JVM. To do this, modify the mwactl.sh script. Modify the value in the file

$ADMIN_SCRIPTS_HOME/mwactl.sh
VM_CONFIG="-mx512m -ms128m"

Note: "-mx512m -ms128m" is the default setting for R12. If for some reason, this is set to a lesser value, then please
return to default value.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 1/13
5/7/23, 9:27 PM Document 782162.1

2. When experiencing Connection issues while using Wireless Bar Code Scanners, such as “Please Wait,” you may be
experiencing a known JVM Performance Connection Issue. This can occur randomly or intermittently and does not matter what
type of Scanner is being used. Set mwa.JVMAvailableBug=TRUE in the $INST_TOP/admin/install/mwa.cfg

This is for some JVM implementation. This property tells the server that the bug is present in the JVM used, so the server will
perform a workaround for the problem. Please note that the property is CASE sensitive.

This may help in reducing the number of times the MWA has to be bounced.

Note:
This is actually a Bug that can be seen in some Java Versions being used. You can either set this variable in the mwa.cfg or
test other Mobile JVM’s and Server Level JDK’s.

FIX
Change mwa.JVMAvailableBug=FALSE to mwa.JVMAvailableBug=TRUE

If making the change permanent, then ensure you follow the AutoConfiguration Document referenced at the bottom of the
Document for updating the $CONTEXT_FILE.

3. MWA Benchmark testing. It is always recommended to be on the latest version of Java for the MWA. MWA does have a
slight performance increased with each newer version of JDK released.

Customers "must" benchmark your MWA and find a MWA bounce schedule that works best for you and your load. How often
you bounce your MWA depends on multiple factors. For example, the JDK version being used, the type of work your using
MWA for, the number of users using the MWA and the number of MWA Telnet servers being used. For many customers with a
heavy load, they have found that they still have to bounce their MWA servers on a regular basis (weekly or daily) in order to
minimize performance issues. You will have to find a schedule that best fits your company needs due to overall Load and
Activity performed by the users.

To determined the Java being used and path run the following from the sourced environment command line:

$java -version
$which java

Next make sure mwactl.sh is set correctly. In some case the mwactl.sh still calls the old JRE or JDK that was installed
previously. You need to make sure mwactl.sh shows the correct version and path to Java that is being used:

$ADMIN_SCRIPTS_HOME/mwactl.sh

# Max memory to use by Java

JAVA="/space/oracle/VIS/inst/apps/VIS_aolesc3/admin/scripts/java.sh -Doracle.ap
ps.mwa=${MWA_TOP} -Doracle.apps.inst=${INST_TOP} ${VM_CONFIG}"
export JAVA

The following Documents can be used for upgrading the JDK.

Release 12.0 and 12.1 Java:

Upgrade to latest java 6 update following Note 455492.1
Upgrade to latest java 7 update following Note 1467892.1
Upgrade to latest java 8 update following Note 393931.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 2/13
5/7/23, 9:27 PM Document 782162.1

Release 12.2 Java:

Upgrade to latest java 7 update following Note 1530033.1

How to get Java for Mobile devices? http://www.java.com/en/download/faq/java_mobile.xml

Note: Please understand there are no official Benchmark numbers as each MWA Customer has different variables.
Internally each case the MWA was on the latest Patches as recommended in this Document. Every Customer will vary in
the number of users able to connect, based on overall load on the server, number of users and there work being
performed.

Section 2 Patches

The link below will take you to the My Oracle Support Patches tab with a dynamic up-to-date list of released MWA related
Patches by Code Sets. MWA 12.2 patches have the code set of MWA C, while MWA Release 12.1 will be Code Set MWA B and
Release 12.0 being set to MWA A. Please keep in mind it is very important to also maintain the Product Patches for which you
are using MWA for. For example, if using Warehouse Management Product with the MWA, then you will need to maintain the
WMS Patches as well. Product specific Patches such as WMS and INV(Inventory) will resolve memory leaks along with other
product specific performance issues seen while using the MWA Product.

Please note that you can edit the search results to meet your specific needs (for example to change the platform or language)
by clicking the Edit Search link on the top right of the Patch Search Results frame.

Navigate to the below link for patch list based on your release:

1> Patch Home

2> Under the "Product or Family (Advanced)" Select Mobile Applications Server under product

3> Choose EBS Release

Section 3 Common Issues

The most common issues logged to ATG MWA Core Server Configuration Team(Prod ID 995), are related to the overall
configuration of the MWA Server, Starting MWA and Stopping of the MWA. Most issues can be avoided with proper mwa.cfg
configuration. Making sure the mwa.cfg is configured correctly and having a proper MWA Bounce cycle will clear the majority
of the issues logged to Prod ID 995 ATG MWA Core Server Configuration Team.

1. Check to make sure mwa.cfg file is correct under $INST_TOP/admin/install for R12. In most cases AutoConfiguration may
have changed the MWA Environment without the DBA or System Administrator realizing it. For R12, you can double check the
mwa.cfg file and make sure all is set per the examples given in the mwa.cfg. MWA Telnet Ports require Port+1 and the
Dispatcher requires Port+2. Meaning each Telnet Server will take the port number seen in the mwa.cfg and the next port
number after. Dispatcher will take the port number seen in the mwa,cfg and two more additional ports.

Standard MWA configuration for R12.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 3/13
5/7/23, 9:27 PM Document 782162.1

Note: MWA is broke into two sections with AutoConfig for R12.
$echo $CONTEXT_NAME

$echo $CONTEXT_NAME

$more $CONTEXT_FILE

<oa_mwa_server>
<mwaLogLevel oa_var="s_mwaLogLevel">error</mwaLogLevel>
<mwaLogRotate oa_var="s_mwaLogRotate">Yes</mwaLogRotate>
<mwaLogFileSize oa_var="s_mwaLogFileSize">10000000</mwaLogFileSize>
<mwaDropConnectionTimeout
oa_var="s_mwaDropConnectionTimeout">5</mwaDropConnectionTimeout>
<mwaStaleSessionTimeout oa_var="s_mwaStaleSessionTimeout">60</mwaStaleSessionTimeout>
<mwaDispatcherThreadCount
oa_var="s_mwaDispatcherThreadCount">15</mwaDispatcherThreadCount>
<mwaDispatcherClientsPerWorker oa_var="s_mwaDispatcherClientsPerWorker">10</
mwaDispatcherClientsPerWorker>
<mwaJVMb oa_var="s_mwaJVMb">FALSE</mwaJVMb>
<mwaActivateLOVByEnter oa_var="s_mwaActivateLOVByEnter">FALSE</mwaActivateLOVByEnter>
<mwaSubmenuChangeOrgResp
oa_var="s_mwaSubmenuChangeOrgResp">FALSE</mwaSubmenuChangeOrgResp>
</oa_mwa_server>

<oa_ports>
<mwaPortNo oa_var="s_mwaPortNo" oa_type="PORT" base="10200" step="6" range="6"
label="MSCA
Server Port">%s_mwaTelnetPortNo%</mwaPortNo>
<mwaTelnetPortNo oa_var="s_mwaTelnetPortNo" oa_type="DUP_PORT" base="10200" step="6"
range="6" increment="2" separator="," showall="true" label="MCSA Telnet Server
Port">10200,
10202,10204</mwaTelnetPortNo>
<mwaDispatcherPort oa_var="s_mwaDispatcherPort" oa_type="PORT" base="10800" step="3"
range="-1" label="MSCA Dispatcher Port">10800</mwaDispatcherPort>

2. Make sure entry for dbc folder exists in mwa.cfg under $INST_TOP/admin/install. Also make sure the dbc entry matches
that of the $FND_SECURE or $INST_TOP/appl/fnd/12.0.0/secure directory.

3. Check for the log file location in the mwa.cfg and make sure you can write or create a file in that directory. If not then MWA
will not start until it can write to its logs.

4. Make sure the Patches listed above have been applied.

5. Check for MWA Processes by running the following:

$ps -ef | grep mwa | wc -l

$netstat -alnp | grep <port>

Note: Replace <port> with the port you wish to check.

$lsof -i :<port>
Note: Replace <port> with the port you wish to check.

$ps -ef|grep MWADIS

Note: This is for checking the MWA Dispatcher exe. process.

$ps -efx|grep <applmgr> | grep mwa

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 4/13
5/7/23, 9:27 PM Document 782162.1
Note: Replace <applmgr> with applmgr User.

$ps -ef|grep <applmgr> | grep MWA |wc -l

Note: Replace <applmgr> with applmgr User.

If you want to use v$session to track, you can set the java command in the mwactl.sh by removing the "-DPID" with "-
DCLIENT_PROCESSID". After doing this v$session will show MWA Sessions.

6. Issues with Starting the MWA Services. Make sure you are starting the MWA Services correctly with the proper Commands.
When starting the dispatcher at the LINUX command prompt, the script does not return us back to the command prompt. If
one closes the telnet session, the dispatcher stops. How can one start the dispatcher without having to keep the session open?

This is really an operating system question and the answer may vary depending upon the OS you are using. Basically when
using UNIX/LINUX command line in a terminal window, if you just type mwactl.sh start 10809, that terminal window needs to
remain open and it will not return you to the command line prompt, so the window becomes useless. If the window closes, it
will kill the MWA server.

However, if you append the ampersand to the end of the command:

./mwactl.sh start_dispatcher 10809 &

This returns you to the command prompt and allows you to close the terminal window. One will always have to hit "Return" or
"Enter" as that is a Operating System standard.

7. Stopping the MWA Services. Make sure you are stopping the MWA Services correctly with the proper Commands. Port
numbers maybe to close together. The Dispatcher can take up to the next 3 ports. If your Ports are close and you have
multiple Dispatchers, you will need to change your ports for either the Dispatcher or Telnet Server. Port Numbers to close to
each other will keep the MWA from correctly shutting down.

It is always recommended to set you Dispatcher Port 10 to 20 Ports away from the Telnet Server Ports. This will allow you to
expand the Telnet Servers as you grow or need. If running multiple Dispatcher it is also recommended to keep them 10 to 20
ports away from each other.

The Dispatcher MUST have 3 consecutive ports open. One port for the Dispatcher Connections, one for Dispatcher workers
and One for Server Manager commands. This is in the MWA Installation manuals listed below.

Run the Commands listed above to check for MWA Processes running. Manually kill the MWA processes and see if that helps.
The "lsof -i :<port>" command is the preferred method of checking the MWA Ports.

Section 4 The Standard Commands for Stopping and Starting MWA Server

DBA's and System Administrators often are confused as to what scripts should be used for the starting and stopping of the
MWA Telnet Servers and Dispatcher. Part of the confusion is due to having the ability to start and stop MWA though the AD
Start all and Stop all scripts which run mwactlwrpr.sh. Please understand this is a script that is managed by AutoConfig and
should only be used by TXK AutoConfiguration. Many of the MWA functionality such as maintaining Multiple Dispatchers or
having to point MWA Telnet Server to use specific configurations will not be maintained with mwactlwrpr.sh.

If for some reason you do need to use the AD adstrtal.sh and adstpall.sh for the mwactlwrpr.sh, can be started using the Apps
Username and Password and needs to be shutdown using the Sysadmin Username and Password. There are a number of
issues with the mwactlwrpr.sh that require Patching for 12.0.x and 12.1.x.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 5/13
5/7/23, 9:27 PM Document 782162.1

For 12.0.x MWA A for mwactlwrpr.sh, the current version is 120.5.12000000.5 at the time of writing this document.
For 12.1.x MWA B for mwactlwrpr.sh, the current version is 120.6.12010000.4 at the time of writing this document.
For 12.2.x MWA B for mwactlwrpr.sh, the current version is 120.9.12020000.5 at the time of writing this document. Note if
using AMP, there is a Internal Version 120.9.12020000.6 with Bug 26051712 that requires Support to release the patch as
needed.

Keep in mind using mwactlwrpr.sh or the adstrtal.sh and adstpall.sh is not recommended for the maintaining of the MWA
Servers. MWA requires a regular bounce cycle and is best to use the standard mwactl.sh script.

Basic Start and Stop Example:

nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 2310 &

nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mfg/welcome stop 2310 &

Start Script Example :

start_mwa.sh
export PATH=$PATH:$ADMIN_SCRIPTS_HOME/mwactl.sh
export DISPLAY="<set to the value of the display in the jserv.properties>"
echo "Starting MWA Telnet server on port 10200-10216 and Dispatcher"
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10202 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10204 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10206 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10208 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10210 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10212 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10214 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start 10216 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh start_dispatcher &

One More Example that can be used. This can be used to point to a particular JDK.

start_mwa.sh
export
PATH=$PATH:/u01/applmgr/vis/inst/apps/vis_host/admin/scripts/mwactl.sh:/u01/applmgr/common/util/java/1.5/j2sdk1.5.0_06
export DISPLAY=host.domain:1.0
nohup /u01/applmgr/vis/inst/apps/vis_host/admin/scripts/mwactl.sh start 10202 &
nohup /u01/applmgr/vis/inst/apps/vis_host/admin/scripts/mwactl.sh start 10204 &
nohup /u01/applmgr/vis/inst/apps/vis_host/admin/scripts/mwactl.sh start 10206 &
nohup /u01/applmgr/vis/inst/apps/vis_host/admin/scripts/mwactl.sh start_dispatcher &

Stop Script Example :

stop_mwa.sh:
export PATH=$PATH:$ADMIN_SCRIPTS_HOME/mwactl.sh
export DISPLAY="<set to the value of the display in the jserv.properties>"
echo "Stopping MWA Telnet server on port 10200-10216 and Dispatcher"
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxx stop_force 10202 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxx stop_force 10204 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxx stop_force 10206 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxx stop_force 10208 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxx stop_force 10210 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxxx stop_force 10212 &
nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxxx stop_force 10214 &

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 6/13
5/7/23, 9:27 PM Document 782162.1

nohup $ADMIN_SCRIPTS_HOME/mwactl.sh -login mobileadm/xxxxxxxxx stop_force 10216 &

nohup $ADMIN_SCRIPTS_HOME/mwactl.sh stop_dispatcher &

Note: In order to stop the MWA, you must use a User that has the System Administrator Responsibility. In the example above
the <xxxxxxxxx> represents the password of the mobileadm user. Also stop_force is used as, this will terminate all users still
connected. If you use the regular stop, the telnet server will NOT bounce until all users on that port have signed off.
MWA is designed to allow 24x7 shops to bounce on a regular basis, without the users even noticing a loss in production. The
bounce is seem-less and users will not even realized had taken place.

Note 198543.1 How To Rebounce the Mobile Application Server for Industrial Applications v1.0.8, explains in more detail how
this is done and provides a sample script for doing this.

Section 5 MWA Advanced Configurations

With Customer's running their EBS Applications in complex configurations that have complex advanced network topology,
Support see's many different attempts to run MWA in these configurations. MWA does not efficiently work with complex
advanced configurations. Development does not officially certify MWA in these advanced configurations. The standard
supported configuration for MWA is to run on a single middle tier with a single or multiple MWA Dispatchers and the MWA
Telnet Servers on the same middle tier node. MWA does not support failover functionality. MWA can not be run under multiple
middle tiers unless used in a shared Oracle Applications $APPL_TOP. With a shared Oracle Applications $APPL_TOP, you can
run MWA on multiple middle tiers as long as there is a Primary MWA middle tier for which the MWA Telnet servers can be
pointed to when using the MWA Shared Oracle Applications $APPL_TOP commands. If running MWA outside the standard
given configurations, you do so at your own risk as Support will not be able to assist in trouble shooting those complex
advanced configurations. For further information for running MWA with a Oracle Shared $APPL_TOP, see Section 8 How to use
MWA in a Shared APPL_TOP environment in this document.

A number of the issue we see when MWA is used in an Advanced Configuration include forms of network related issues with
the MWA Ports in use, such as CLOSE_WAIT's and TIMED_WAIT's. These will tend to be related Advanced Network
Architecture.

When using Hardware Load Balancers, MWA Connections tend to ramp up and cause MWA to crash or be bounced more
frequently then needed. This is caused by Hardware Load Balancers tracking the MWA ports for being 'Alive' or 'Heartbeats.'
Each time Hardware LBR checks the MWA ports, an added unauthenticated connection is added to the MWA. Hardware LBR's
will also cause the Logs to fill with "Broken Pipe" type errors. You can expect Random User Disconnections and can experience
unexpected Login and Logout issue with settings and configurations of the Hardware Load Balancer. You will also see added
Inactive MWAJDBC Connections due to the unauthenticated connections. See Section 7 on how to kill the inactive MWAJDBC
Connections.

When running MWA on multiple middle tiers when not using the MWA Shared $APPL_TOP commands and configuration, you
can have data corruption, Users seeing 'Already signed on' and/or User Connection related issues.

Note: The setup of the Load Balancer and setting of the Routing Rules are supported though the Vendor of the LBR. MWA
Support is NOT familiar enough with Load Balancer to advise on LBR Configurations required.

Section 6 MWA GUI and Device Configuration

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 7/13
5/7/23, 9:27 PM Document 782162.1

The common issue with MWA GUI is due to not having the startgui.cmd set correctly.
The Java command path must be all on one line:

The following is a Script Example of MWA GUI on Client PC running Applications 12.1.X:

set MWA_GUI_TOP=C:\mwagui
set JAVA_TOP=C:\jdk1.6.0_18
%JAVA_TOP%\bin\java -classpath
%MWA_GUI_TOP%\lib\j9969932_3p.zip; %MWA_GUI_TOP%\lib\j9969932_fnd.zip;
%MWA_GUI_TOP%\lib\j9969932_mwa.zip
oracle.apps.mwa.awt.client.StartGUI

Note: The following still applies for R12.0.X and 11.5.10.2. Patch 12780257 has replaced Patch 4941477 and contains the
latest classes.

To run GUI for a R12 Instance, the "SAME" two patches listed for 11i are still used for R12.0.X.
You can use the Patch 12780257 for R12.0.X as well.

Manual: Mobile Application GUI Client

Note 294670.1 Oracle Mobile Applications Graphical User Interface

There have been SR's logged to Support regarding Handheld Mobile Devices hanging after setting up GUI on a Mobile Device.
Normally the issue is related to the Device configuration or the network configuration. Some cases have been seen where a
incorrect file extension is used to start the MWA GUI Session. In this case the Software Vendor would need to be engaged.
ATG MWA Support will make sure the Device is setup per the Oracle Mobile Applications Graphical User Interface Client. If all
has been confirmed to be setup and configured correctly from Oracle, then customers will need to request Support from the
vendor of the Device or that of the Software Vendor for the Device.

Example of Mobile Hand Held Devices with Client GUI Patch 4941477 for the command script with R12.0.X:

MWA_GUI_TOP=\Windows\mwagui\
\Windows\CrEme\bin\CrEme.exe -Of -tiny -classpath
\Windows\CrEme\lib\AWTclasses.zip;%MWA_GUI_TOP%\lib\j4941477_3p.zip;%MWA_GUI_TOP%\lib\j494
oracle.apps.mwa.awt.client.StartGUI mwahost.domain 10300

Example of Mobile Hand Held Devices with Client GUI Patch 4205328 with R12.0.X:

\Windows\CrEme\bin\CrEme.exe -Of -tiny -classpath

\Windows\CrEme\lib\AWTclasses.zip;\Windows\mwagui\lib\j4205328.zip
oracle.apps.mwa.awt.client.StartGUI mwahost.domain 10300

Note: Notice the various command examples given above. The top example I set a Environment Variable of
%MWA_GUI_TOP%. The Second example I provided full Path to the MWA.

Setting up a Device:

We can start out by just verifying if the Devices are starting there connection with the a Command File?

Take the deviceIP_template.ini under $INST_TOP/admin/install and copy it to deviceIP.ini, IF NOT ALREADY DONE SO
AUTOMATICALLY!

Now do the following in the deviceIP.ini:

Under the [map]

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 8/13
5/7/23, 9:27 PM Document 782162.1

Set the IP address based on your network architecture for the Devices:

[device]
DEFAULT=default_key.ini
SYMBOL=symbol.ini
INTERMEC=internec.ini
GUI=gui_key.ini

// Wildcard at the end of IP address is supported.

[map]
127.0.0.1=default_key.ini
<IP octet>.<IP octet>.<IP octet>.* = symbol.ini

Note: Do you notice the above devices listed under [device]? This is what the user is prompted with to select before Log
In, but now any IP address connecting with <IP octet>.<IP octet>.<IP octet>.* should go right to the symbol.ini file.

Now create a symbol.ini if Symbol Devices did not provide a default ini.

Because you are using GUI Devices, we can try and see which .ini BEST FITS/FUNCTIONS for your devices.

Make a copy of your gui_key.ini file and rename it to symbol.ini

With in this files(your new symbol.ini) you can play with the contents during testing.

IF FOR SOME REASON the gui_key.ini did not work out for you after modifing and customizing the parameters, you can copy
and and rename the default_key.ini to symbol.ini.

Please understand MWA does need to be bounced for the new .ini files to take affect. So before testing the .ini files, MWA
must be bounced.

Need to follow up with the Vendor for the devices, to make sure we have the best configuration for your device.

Section 7 Causes as to why MWA Needs to be bounced

The majority of the MWA Performance Problems are fixed by being on the latest Product specific Patches and Code used by
MWA or by upgrading the JDK.

Please understand that, bouncing the dispatcher/servers can be done without stopping the operations. It can be done
sequentially without any production outages. Refer to Bug 6600421.
The number one cause of why the MWA has to be bounced when using a Dispatcher is due to running out of Dispatcher
Thread Connections. Then once the MWA is bounced it clears the Threads. You can also add multiple Dispatchers as well. See
Section 3 above.

Currently for dispatcher configuration following is the limit set

mwa.DispatcherWorkerThreadCount=10
mwa.DispatcherClientsPerWorker=15
(10x15 = 150 maximum Dispatcher user connections)

But this can be offset by running multiple dispatchers or dedicated Telnet Servers with latest JDK. mwacfg.lc is hard coded to
accept nothing higher then 20 for the Thread Count. This can also happen if just using MWA Telnet Servers without a

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 9/13
5/7/23, 9:27 PM Document 782162.1

Dispatcher. You can increase the number of Telnet Servers used when this is seen when only using MWA Telnet Servers. If
using the Dispatcher, then the issue is normally just related to the Dispatcher.

The next biggest cause of why MWA has to be bounced depends on Device Configuration or your advanced configuration. If
the Device has a Heartbeat or NO Timeout Configured on the Devices used, this can cause the connections to creep up. Each
time a heartbeat is sent to the MWA Server it makes a Connection without signing on. (MWA WILL NOT CLEAN UP THIS
CONNECTION) You can create custom scripts to clean up the connections not signed on. The Heartbeat will count as a
connection every time it is sent and takes away connections that can be used by a User attempting to sign in. It would be
recommend to remove any such heartbeats or extend them out. If using a Hardware Load Balancer, each time the session
persistence or session stickiness is checked or any heartbeat type connections made by the LBR to make sure the MWA Ports
are still up, will also cause the connections to fill up. By removing or extending the time checked, for the session persistence or
session stickiness on the LBR, the MWA availability will extended. When these connections fill up, MWA Has to be bounced.

Overview of inactive MWAJDBC connection :

In R12 development has changed the functionality in the ApplicationsObjectLibrary.class file, so that now the V$SESSION
contains module name as 'MWAJDBC' when the mwa.loglevel=error. With this change customers can monitor their production
env with mwa.loglevel=error and kill the inactive sessions without having to run mwa.loglevel=trace in prod. You can also
track MWAJDBC connection though V$SESSION changing the following Java command in the mwactl.sh by removing the "-
DPID" with "-DCLIENT_PROCESSID." After doing this V$SESSION will show MWA Sessions.

As part of this change, MWA will not write the inactive MWAJDBC sessions to the $SESSION when the mwa.loglevel=trace. The
'MWAJDBC' not showing up in the $SESSION when the mwa.loglevel=trace is intended functionality.

MWA application only takes JDBC connection from Connection Pool, Connection Pool is shared by the entire EBS Applications.
For one MWA telnet session, only one JDBC connection is taken, and updated with module=MWAJDBC for trace purpose. The
connection will be returned to Connection Pool after the MWA telnet session (mwa.StaleSessionTimeout is setup for telnet
session) is closed. You can find inactive sessions live forever unless shutdown the server,
i.e. the JDBC connection will not be removed after telnet session is closed. This is why you can still search out JDBC session
with module "MWAJDBC" after closing telnet sessions.

There are inactive sessions with module='MWAJDBC', because MWA has code in place to update this for trace purpose.

For the Connection Pool mechanism, MWA application invokes the downstream FND application to get JDBC connection from
Connection Pool, MWA application can not close JDBC connection directly.

To view MWAJDBC Connections:

SQL statement to identify the detail information of JDBC connection :

select vse.username, vse.sid, vse.serial#, vse.process, vse.module, vse.action, vse.program, vp.pid, vp.spid, vsq.sql_text
from v$session vse, v$sqltext vsq, v$process vp
where vse.sql_address=vsq.address
and vse.sql_hash_value=vsq.hash_value
and vp.addr = vse.paddr
and vse.module like '%JDBC%'
order by vse.sid , vse.serial# , vsq.piece;

select program, module from v$session where module = 'MWAJDBC';

To view Inactive MWAJDBC Connections:

select program, module from v$session where status='INACTIVE' and module='MWAJDBC';

You can terminate all inactive jdbc sessions from MSCA/MWA Apps Servers using following sql:

select distinct 'alter system kill session '||''''||sid||','||serial#||''''||' ;' from v$session
where process is NULL and program like '%JDBC%' and module = 'MWAJDBC' and status = 'INACTIVE' and last_call_et &gt;
3600*12 and machine like 'host%';

Note: Change the <host> to your correct 'host%' value

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 10/13
5/7/23, 9:27 PM Document 782162.1

Section 8 How to use MWA in a Shared APPL_TOP environment

Do the following for starting a MWA Telnet Server :

$mwactl.sh -java_config "-Dmwa.cfg=[path to config file]" -mwatop [path to mwatop] start

[port number]

It must be the Full Path to the Primary for '-Dmwa.cfg' then the '-mwatop' for either Primary or Shared $APPL_TOP's

When you specify option mwa_top , the configuration file mwa.cfg will be picked from specified
$INST_TOP/admin/install/mwa.cfg. If you want to specify mwa.cfg file to be picked up from Primary host(where you run the
server/dispatcher) then you can use option java_config.

You would typically run this on your primary host and point to the $INST_TOP/admin/install/mwa.cfg on Shared host through
option -mwatop. But if you want to start another MWA server on your shared host as well then you can do the same.

NOTE: One cannot use the ad scripts in a shared APPL_TOP for MWA. One must use the MWA Shared APPL_TOP scripts in
the MWA Tips Document.

Section 9 MWA MULTI-LANGUAGE NLS-MLS Language Support

MWA is limited on what Languages that it can handle. Normal Telnet is fine with Multiple Language, but GUI with jdk 1.1.8 can
not handle the translations.This is due to the limitation in the JDK 1.1.8 and the Languages it can handle. The character-set or
Charset as called by Java Code is defined as the combination of a coded character set and a character-encoding scheme. You
can find this scheme listed on the Sun Jave Support site:

For JRE6 http://download.oracle.com/javase/6/docs/technotes/guides/intl/encoding.doc.html

From here you can figure out if your Charset is one of the supported scheme's for the JDK 1.1.8. You may realize that the URL
Call and the Page mention 1.3. When looking at the Encoding for JDK 1.1 on the Sun site, you are redirected to this page.
From our understanding the Encodings are the same between 1.1 and 1.3 versions JDK.

Further information in regards to the Encoding Schemes can be reviewed under the Document:

Note 167557.1 Known Issues With Multi-Lingual Support for Mobile Applications Framework

MWA Development is currently working to certify the current versions of JDK to be used for Devices and GUI.

Section 10 Logging SR's to Support

1.What is your current MWA Bounce

Cycle?

2. How many Middle Tiers are you running your MWA Telnet Servers and Dispatcher on?
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 11/13
5/7/23, 9:27 PM Document 782162.1

Please provide a small Network Topology of your MWA Configuration to include any Load Balancers, firewalls, Middle Tiers
Database, etc.

3. Provide the JDK Version being used?

4. What actions are the User doing in the Product Functionality on a daily basis and for what Product? Example would be 'Pick
Loads' WMS
5. How many Users do you have using the MWA at a given time? Please see Section 3 above to get User Load Counts for the
MWA.
6. Are Devices being used and if so, what type of devices?
7. What is the MWA Topology being used? Basically how many nodes are you running MWA on? Are you using any Dispatchers
or Load Balancer?
8. What are the versions of the following files?
ident $MWA_TOP/bin/MWADIS mwacfg.lc mwadis.oc
$JAVA_TOP/oracle/apps/mwa/presentation/telnet/ProtocolHandler.class
$JAVA_TOP/oracle/apps/mwa/presentation/telnet/PresentationManager.class
$JAVA_TOP/oracle/apps/mwa/container/ApplicationsObjectLibrary.class
9. Upload the $ADMIN_SCRIPTS_HOME/mwactl.sh and the $INST_TOP/admin/install/mwa.cfg. If the issue for the SR has to
do with the Mobile Bar Code Scanner Devices being used, then also upload the device.cfg and deviceIP.ini as well. If the issue
has to do with using the GUI MWA, then upload the gui_key.ini and the .cmd used to start the MWA GUI along with the
mwa.cfg file.
10. Upload the MWA Debug Logs using the steps below in Section 11.

Section 11 Getting Mobile Debug Log

Set mwa.LogLevel=trace in the mwa.cfg file located in $INST_TOP/admin/install

Every time there is some kind of Performance issue it will begin to trace it. The Logs will be in the path described in the
mwa.cfg file and may or may not have the port number listed with the log.

Rename the following files located in the "mwa.logdir" parameter of the mwa.cfg file:
[port].INV.log
[port]WMS.log
[port].system.log

Bounce MWA Services for the trace to take place.

Upload the new Log files.

REFERENCES

NOTE:198543.1 - How To Rebounce Mobile Application Server For Industrial Applications v1.0.8

NOTE:380490.1 - Oracle E-Business Suite R12 Configuration in a DMZ

BUG:3025394 - MWA SERVER UNABLE TO MAKE NEW CONNECTIONS HANGS
NOTE:380489.1 - Using Load-Balancers with Oracle E-Business Suite Release 12.0 and 12.1
BUG:6600421 - MOBILE SERVER DROPS CONNECTION EVERY 24HRS
NOTE:294670.1 - Oracle Mobile Applications (MSCA/WMS) Graphical User Interface
BUG:4252132 - MWA-SERVER DOES NOT ACCEPT GREEK CHARACTERS
NOTE:455492.1 - Using Latest Java 6.0 Update With Oracle E-Business Suite Release 12

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 12/13
5/7/23, 9:27 PM Document 782162.1

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=5tz89uban_598&id=782162.1 13/13