Johannes Michler PROMATIS Horus Oracle


Executive Vice President – Head of Platforms & Development

Every quarter Oracle releases a bunch of Critical Patch Updates that have to be applied to (often many) E-Business Suite instances. While the patch application is highly automated through the adop utility, there are two (little) things that always annoyed me when patching:

  • You have to provide the apps, ebs_system and weblogic password on every adop command
  • You have to re-check your terminal connection to check if a certain step completed

This first part of this blog post series covered how we can easily pass the passwords to adop; in this second part I will show how notifications can be brought to your attention quickly once the patching is completed.

Notifications to PuTTY

It is often inconvenient that after kicking off the adop process (or something similar long-running) you have to re-check the PuTTY terminal over and over again to check if the process completed. Luckily PuTTY has the capability to "flash the task bar" as well as "play a sound" whenever a so call "bell-event" is produced on the remote session. The behavior of putty is controlled through those settings:


Settings for PuTTY to play the standard system alert sound as well as flash the task bar

With those setting in place you should be able to perform a test with the following command:

sleep 3; echo -e "\a"

Then quickly navigate away from the putty window and you should see the Putty Window flashing as well as a "dong" sound ringing:


Flashing Putty Window

Bell with screen

Typically I like to not start adop (or other long running processes) directly but I use a "screen" (https://www.gnu.org/software/screen/) session to start the process. In that way should my internet or VPN connection break down the process continues and I can reattach to the session.

Unfortunately screen does some "special" handling of the "bell" event which in the original configuration I found in my "jump host" from where I connect to the E-Business Suite environments screwed the putty notification of the bell event. To fix this I created a ~/.screenrc file as follows:

[opc@ebscm2 ~]$ cat .screenrc
bell_msg "Bell in window %n ^G"
vbell off

The first command sets the bell_msg to both contain a visual hint in which of potential multiple (background) windows of you screen session a bell event happened. The final ^G makes sure that another "bell" event is raised through that notification. With this setting you make sure that a background bell is actually passed on to PuTTY.

The second setting controls the foreground screen session. By disabling the visual bell (flashing of screen window) a regular bell is passed to the terminal.

The combination of those settings allow bell signals to be propagated to the PuTTY terminal both in foreground and background screen windows. Before continuing, it is a good idea to test both with the above mentioned echo command.

Creating a custom myadop.sh script

Based on this I extended the myadop.sh script from my first blog post by the last line:

[oracle@prod122app01 ~]$ cat /home/oracle/myadop.sh
source /home/oracle/credsEnv.sh
{ echo ${XX_APPS_PWD};echo ${XX_EBS_SYSTEM_PWD};echo ${XX_WEBLOGIC_PWD} ; } | adop "$@"
#now alert the terminal:
echo -e "\a"

Using this simple command I'm then able to run something like:

 ./myadop.sh phase=apply patches=36117775,36117775_D:u36117775.drv

This will result in a bell signal and a flashing putty taskbar logo as soon as the adop process completed.

Summary

Using this procedure I no longer have to check (eventually multiple) screen windows manually every few minutes if my patching completed - either successfully or in error. The procedure can obviously also be used for a lot of more long-running commands.