Chapter 15

PDS logs and general files

(20071207)

Chapter Goal
The goal of this chapter is to introduce the student to the crontab file, main log
files, configuration files, and tools of the PDS.

Chapter Learning Objectives

After completing this section you will be able to:
• Check the crontab and determine when automated processes will run
• Edit the crontab file
• Determine system variables in master.cfg
• Determine ip addresses of the system in the hosts file

Introduction
This chapter will introduce you to the common files and tools used by PDS
Support. Some are specific to PDS, such as the account log, log_file,
check_errors, and master.cfg. Others are HP-Unix processes and logs, such
as the crontab, syslog.log, passwd, and hosts files.

Section 15_1 Logs

PDS Logs

1. log_file.
When first connecting to a live PDS, you log in as admin. After this will scroll the HP
Unix login information and then the PDS log_file will cat on your screen.
Initially, the log_file contains configuration and option information recorded by
the PDS configuration engineer and installer. It contains a customer service
log file of the PDS history. Every time the system is maintained or upgraded,
the log_file is updated to reflect the changes.
It is a simple text file kept in the /opt/avaya/pds/etc/ directory. The file should include
current information such as how many outbound lines and agent licenses were
purchased, what version and service pack level, and what patches are installed,
and if there are any custom scripts or changes to the system that have been made.
The file is manually updated at the time of install. Thereafter, it can be written to
automatically, such as when an official patch is installed, or written to manually by
an installer or configuration engineer during an upgrade, or a PDS Support
engineer for numerous reasons.

• Log into redts35 as admin

The log_file scrolls by. You can scroll up and look at the messages in it (or you can
more or cat the /opt/avaya/pds/etc/log_file). This one is pretty much blank since it
is a test system, but toward the end you can see messages about the patches and
service packs:
PDS 12.0.5.k08 - PDS_SVCPK.PDSBASE installed on 2007/01/05 at 15:16:25
PDS 12.0.5.k08 - PDS_SVCPK.SOE installed on 2007/01/05 at 15:16:27
PDS 12.0.5.k08 - PDS_SVCPK.ZIPS installed on 2007/01/05 at 15:16:27
PDS 12.0.5.k08 - PDS_SVCPK.TZONEBASE installed on 2007/01/05 at 15:21:34
PDS 12.0.5.k05 - PDSDB_SVCPK.PDSDB_SVCPK installed on 2007/01/05 at 15:40:05
^-messages indicating service pack 4 was installed (the 4 in 12.0.4.k08 indicated sp4, the k08 is the rev of the
service pack

02000 1144 PDS12_794 installed on Fri Jan 5 19:36:43 PST 2007

^-This line indicates a patch was installed and when, with the sum check of the patch file first (sum check
discussed later)
• Always read the log_file when you log into a PDS, there may be notes
about a particular case that is currently being worked or some special
information about a custom script that may impact what you are there to
troubleshoot.

2. Account log
In /opt/avaya/pds/account are a number of logs that are generated each day and
populated thoughout the day. You saw in the exercise about the tail command
how to use tail –f to watch the account log. This is a very useful way to monitor
a system live. List the files in the account directory. There are
account.<DATE> files, again the date is in the CCYYMMDD format. Most
systems keep 7 days plus the current day’s file, this number of days is
controlled by the clear_all script that was shown briefly in the last chapter.
Since only a few days are kept, it is common to use a command like tail –f
acc*21 to tail the current days running account log (example of *21 is for the
21st day of any month).

• Use more to view today’s account log.

2006/09/07!00.01.00!Z00000!!!0!PID(21864)!script:admin:sh:cron:
2006/09/07!00.01.00!M89600!!!0!PID(21880)!ENVFILE
SCRIPT:admin:/opt/avaya/pds/shell/pds_maintenance::
2006/09/07!00.01.03!ACCTPRTF!!!0!PID(20240)!esSigHandler(11)
2006/09/07!00.01.03!S61002!enserver!DialerEventServerIF_i.cpp!491!PID(20240)!client 'statspmp' number
1 successful logoff from slot 0
2006/09/07!00.01.07!AGENT!!!0!PID(20365)!Agent Signal Error Trap, SIGTERM(15):pid=20365:
2006/09/07!00.01.07!E00500!porter!porter.c!1095!PID(20284)!Porter 1 - Caught signal 15 (SIGTERM)
2006/09/07!00.01.07!E00500!porter!porter.c!1095!PID(20288)!Porter 2 - Caught signal 15 (SIGTERM)
From this you can see the format of the account log. The date and time comes
first, separated by a “!” (referred to as a “bang” in Unix terminology). This ! is
the field deliminator.
The first thing that occurred just after midnight on this PDS system was a
command by “cron” (more on cron later in this chapter) and the next line shows
the script that was run: “pds_maintenance” which stops the PDS Application,
runs clear_all, then starts the PDS Application.
There are messages about each PDS process being shutdown (SIGTERM).
Look at the messages and you will recognize many of the processes from the
last chapter.

Continue looking through the account log file, you will see when the clear_all
runs:
2006/09/07!00.01.15!M89600!!!0!PID(22124)!ENVFILE SCRIPT:admin:/opt/avaya/pds/shell/clear_all::

Then you will see the messages for all the files that clear_all is removing. Here
is the line where it removes all account files older than 7 days
2006/09/07!00.01.17!M89600!!!0!PID(22195)!ENVFILE SCRIPT:admin:/opt/avaya/pds/shell/fclr:-t +6 -d
/opt/avaya/pds/account -n account.*:

Then the PDS Application starts back up, starting with checking for any Admin
Manager changes with install_config –f restart (remember that was discussed
earlier in this course, that AM changes are put in place at PDS Application
restart).
2006/09/07!00.01.25!M89600!!!0!PID(23023)!ENVFILE SCRIPT:admin:/opt/avaya/pds/shell/install_config:-f
restart:

Then starting the conn_mgr binary starts up.

2006/09/07!00.01.27!S28200!conn_mgr!conn_mgr.c!873!PID(23051)!Conn_mgr(23051) - startup complete

Follow the account log until you see a break in time before the next automated
cron process starts up, which is mts_maintenance at 31 minutes after midnight.
2006/09/07!00.02.01!S28200!dccserver!DialerCmdCtrl.cpp!172!PID(23192)!dccserver(23192) - startup
complete
2006/09/07!00.02.14!S61001!enserver!DialerEventServerIF_i.cpp!382!PID(23056)!client 'statspmp' number
1 successful login to slot 0
2006/09/07!00.31.01!Z00000!!!0!PID(23230)!script:admin:sh:cron:
2006/09/07!00.31.01!M89600!!!0!PID(23246)!ENVFILE
SCRIPT:admin:/opt/avaya/pds/shell/mts_maintenance::

You have just looked through a normal pds_maintenance done nightly

2b. Searching for information in the account logs

The account log always shows time in 24 hr format, with periods between the
hours, minutes, and seconds: HH.MM.SS.
The account log is one of the most useful log files on the system for diagnosing
and seeing problems. Things like jobs starting up and shutting down, agents
logging in and out, call selections starting and their results, and much more is
 tracked in this file. Many error messages are also written to the account log,
and over time you will become familiar with reading this file.

Commonly you will want to use grep (and grep –i) to find information out of the
account log. You can grep from a single account log or from all that are on the
system. Use grep callsel acc* to search for any lines in all the account logs
currently on the system when a call selection was run.
account.20060905:2006/09/05!12.15.35!S25000!callsel!callsel.c!1123!PID(6604)!Callsel - Processed 501
records in List redts35-list20, Select file core4_6ms and Strategy file core4_1ms with 85 records selected
and 0 recalls with index #24

Since you are using grep with searching out of a number of files (acc*), the first
part of the output is the filename that the line came from, above it is
account.20060905 followed by a colon and the line from the file (which in itself
may contain a colon, so be aware of that).
If I change my grep command to grep callsel acc*05, the output does not contain
the filename,
2006/09/05!12.15.35!S25000!callsel!callsel.c!1123!PID(6604)!Callsel – Processed 501 records in List
redts35-list20, Select file core4_6ms and Strategy file core4_1ms with 85 records selected and 0 recalls
with index #24
This is because there is only one acc*05 file: account.20060905.

Remember that everything in unix is case sensitive, in this case it does not
matter because the line has both upper and lower case “callsel,” but other
times it is useful to use grep –i.

The callsel output line above shows me when the call selection was run, how
many records were selected and the total records, what list it was on, what
selection and strategy file it used and the index number. This index number will
be useful to use for finding the job that used the selection. Using grep with that
account log again, I can grep for that index number and find the job(s) that
used that index file:
2006/09/05!12.15.35!S25000!callsel!callsel.c!1123!PID(6604)!Callsel – Processed 501 records in List
redts35-list20, Select file core4_6ms and Strategy file core4_1ms with 85 records selected and 0 recalls
with index #24
2006/09/05!12.15.40!S28407!caller!caller.c!670!PID(6608)!Job core6_3ms startup (Pid=6608, Index=24,
Number=21)
(in this case the index number is 24 which is low, so I used the command grep
24 acc*05|grep -i index to filter the other “24”s from the output)

From the line in the account log for when the job started up, I can see quite a bit
of information.
• I can see the time the job was started.
• I can see the index number it used (since a System Operator can run a
record selection many many times in a day, it is important to know which
index of records that was created was used by the job).
 • I can also see the job number (Number=21) which allows me to know that
if I need to run a PCAnalysis extract on just that job, I can use the 21tran
and info.stat files.

So, another good command is grep Job acc*<DATE> |grep startup to see a
line for each job that started up in a day. Since there are many messages in
the account log with “Job” and “startup,” using the pipe and another grep filters
just the output I want. As you use the account log and get a familiarity with it,
you will have an easier time finding the information you need in troubleshooting.

Use more and view with the account log as well to find information. Maybe the
job core6_3ms failed just after startup and you want to look at the account log
just after the startup.

Search the account logs on redts35 with the above command for a job that ran
recently. view that account log and use your vi commands to search for the
jobname. Then using the vi movement commands, look at the messages that
follow the job startup.

2c. Troubleshooting with the account log

While troubleshooting, it is often very useful to have a telnet session window
open to the PDS that is tailing the account log real time while looking at other
things on the PDS on another telnet session.
Use tail –f on today’s account log in one telnet session. Now open another
telnet session to the PDS and log in as “system.” Notice the messages that are
logged, first a message that shows the user’s name:
2006/09/13!08.29.31!Z00000!!!0!/dev/pts/tb!script:system:-sh::
Then when the user has entered the menu, you can see that too:
2006/09/13!08.29.34!!!!0!/dev/pts/tb!!system!Enter Menu – Login

Some logging is also done to see what that user does. This is good to track
telnet “system” users and what they do if there is ever a question about it from
a System Operator (especially some of the Administrative tasks that can cause
a PDS to fail).
In your “system” session, select the Calling lists and users option. Notice that
there is a message logged in the account log showing the user has gone into
the “menu control” menu (more on what that means in the next section).
2006/09/13!08.34.46!!!!0!/dev/pts/tb!!system!Menu - menu control

The other thing to point out is the telnet session that is associated with this user.
Notice in the above messages that each is associated with /dev/pts/tb. This is
the telnet session.
Since there could be many users logged in as “system,” they only way to tell
them apart is by this session designation. For instance, I closed the telnet
session of the above user without exiting from the menus properly and am able
to see that the session was closed improperly by the messages below:
2006/09/13!09.16.10!E39004!menu!menu.c!168!/dev/pts/tb!MENU(9017)Signal Interrupt=1
2006/09/13!09.16.10!E16902!menu!exec_prog.c!152!/dev/pts/tb!EXECPROG:Exit(255) wait(pid=9052)

As you continue this course, you will be required to look at the account log many
times as it is a very useful tool for troubleshooting. Other common messages
will be shown and you will get more familiar with the file.

3. System Checks
check_pds/mts/db/errors
There are a few tools which check the logs and current running processes on the
PDS. You can run these immediately when you log into a system to help
determine if there are obvious problems.
The first tool is the check_pds script, which was introduced in the last chapter.
check_mts and check_db are two more scripts that check for the mid-tier and
database processes (information about the mid-tier and database is in a later
chapter).

• Run all three of these checks on redts35 to see the output.

The mid-tier and database only run on the primary dialer, so if you connect to a
system and check those processes and find them not running, check whether it
is a secondary dialer in a pod (you will see how to do this later in this chapter).

check_errors is a script that scans various logs on the PDS for error messages.
Many error messages are common and normal depending on the system, but
the script output can be helpful. On redts35, just type check_errors at the
command line for the command usage.
• Run check_errors for today and look at the output.
Since this is a test system, most likely there will not be many, but you can see
that the output shows each error and segments them into sections for each log.

Additional logs
There are also a few other logs in /opt/avaya/pds/account that are available,
though used less: switch_log.<DATE>, soe_log (which backs up to
soe_log.old.<DATE>) mid_tier_log.<DATE>, acd_log.<DATE>, and
logger.<DATE>. Knowledge base articles will reference these.

/var/adm/syslog/syslog.log
The syslog.log file is a unix log file (not PDS specific) which displays information
on processes that have logged in and out of the system and other messages.
For example, the syslog.log file will display when an outside computer has
connected to the dialer. The syslog.log is useful for troubleshooting Host
Initiated FTP downloads and uploads. The file is copied to OLDsyslog.log
when the CPU reboots, so the syslog.log and OLDsyslog.log files may keep up
to 7 days of logging each. If you are troubleshooting hardware issues and
need to reboot the CPU, be aware that the OLDsyslog.log will be overwritten by
the syslog.log when it is copied to OLDsyslog.log, make a backup if you think it
will be of use.
Look at the file syslog.log file on redts35. Much of what you will see there will not
be useful, but search the file for “FTP.” Here is an example of an anonymous
ftp login in the syslog.log
Sep 11 10:21:21 redts35 ftpd[4317]: ANONYMOUS FTP LOGIN FROM redts35 [143.243.102.162],
anonymous
Sep 11 10:24:22 redts35 ftpd[4317]: FTP session closed

Quiz 15_1
1) Which file contains logging of starting up the PDS Processes
a. account.<DATE>
b. log_file.<DATE>
c. check_pds.<DATE>
d. check_errors.<DATE>

2) What is the command for running check_errors to look for any errors
yesterday between 2pm and 6pm? ______________

3) T/F The log_file is only written to by the PDS system

4) What is the message that is logged when a “system” user logs out of
the CPU? ______________________

5) Are any messages logged when a user logs into campaign editor?
YES/NO
Section 15_2
PDS Configuration Files
Configuration files were introduced in the last chapter. The resource guide has
information about all configuration files on the PDS. A few major ones will be
highlighted in this section.

Configuration files contain variables that are read by scripts and binaries. For
instance, each job that is configured has a file that holds the settings of that job.
There are many configuration files in the /opt/avaya/pds/config directory, but by no
means all of them.

Look at the timezone.cfg file in the config directory. There are many comments and
then each setting, such as:
J:Mountain Daylight:7:MST7MDT:0-6:08.00:20.45
K:Mountain No Daylight:7:MST7:0-6:08.00:20.45
L:Pacific Daylight:8:PST8PDT:0-6:08.00:20.45
M:Pacific No Daylight:8:PST8:0-6:08.00:20.45
So, each line is one configuration, and each line is separated into however many
fields needed by colons. Each field is read by a binary or script and that way
changes can be made just to the configuration file easily without modifying the
script or binary.
The main configuration file for most of the PDS configuration is master.cfg, below.

• /opt/avaya/pds/etc/master.cfg
The master.cfg file defines critical variables for PDS processes, which reference
the file for values during operation and startup. Values set in this file govern
both hardware and software processes. Some changes require a system
reboot to take effect. Where variables are defined in another configuration file
and in master.cfg, entries in master.cfg prevail. Do not change any
parameter in master.cfg unless instructed by a knowledge base article or
experienced PDS Support Engineer.
Parameters can be found in the master.cfg file by using the getvar command in
combination with a keyword, such as ACCOUNTING. On redts35, type “getvar
ACCOUNTING”, it will return the value set for that parameter in the master.cfg file.
This is a simple way for both PDS Support and any shell scripts to get parameters out
of the master.cfg file.
Open the the reference guide for information about each setting in the master.cfg
file and look at the master.cfg file on redts35 at the same time..
The first setting is ACCOUNTING, which you already saw the value of above. This
setting designates the path for writing PDS logs. So, to give an example of how
this parameter is used is that when the script archive_mgr runs, it sets a variable
“LOG” in it’s script by finding the parameter in the master.cfg file with the following
log
LOG="`getvar ACCOUNTING`/Backuplog" ## Backup log file name.
This sets the parameter LOG to whatever is in ACCOUNTING in master.cfg
appended by “/Backuplog”, which is /opt/avaya/pds/account/Backuplog. This is
similar to how most scripts find settings from master.cfg.
The BACKONBADALT parameter was discussed early in this course when talking
about Phone Strategies, find it in the master.cfg file and look at it’s description in
the reference guide.
Look up the information about the following parameters from the reference guide and
enter the current values on redts35
CALL_BLENDING
CYCLE_LIM
EXPERTCALLING
INBNDSYS
MAXRECSIZE
MAXSELECT
MAXSORT
MAXSTRATEGY
OPERATORS
OPLIMIT
OPTIMEOUT
PORTS
SWITCHTESTMODE
SYSOPS
TZ

Some may not have descriptions in the reference guide, and some may have no
value on redts35

• /opt/avaya/pds/config/compcode.cfg
This file contains the completion codes set on the PDS. Explore this file on
redts35 and in the reference guide. Notice in the reference guide that there is a
section for the syntax. Each line is the configuration for one completion code
and thus, there is more than one field in each line because each completion
code has many settings. What each field is for is shown in the guide. When
investigating settings, it is important to know what each field does and the
reference guide is often very good at indicating these.

• /opt/avaya/pds/menus/*.menu and *.cmd

When you log into the PDS as “system” or “sysadm” it opens a character based
menu. The menus are usually the same between different PDS’s, but
occasionally a system will have some custom CUI menu option either put there
during install, an upgrade, or possibly by PDS Support.
When the character based menu is accessed, this runs the menu binary, which
reads information from a configuration file. There are two ways to access this,
either logging in as “system” as a System Operator would, or running the menu
binary yourself from command line. Type “menu system” and you will open the
CUI “system” menu. By doing this, you have invoked the menu binary using
the system.menu config file. On a separate session look at the system.menu
 file. This config file provides the formatting and options for the “system” menu.
You can see a line in the .menu file for each of the options you see in the
Supervisor Main Menu.
From looking at the file, you can see that the numbered options in the menu
relate to a line in the .menu file and clearly the first two fields in the .menu file
are displayed
system.menu file shows
Control:Calling lists and users::::1:0:menu:control
Supervisor Main menu shows
2. Control Calling lists and users
When you choose that option, the menu binary calls the next menu which is
signified by the last two fields: control.menu. Select that option in the menus
and look at the control.menu file. Again you can see the same formatting.
The first option (ignoring the exit and help options which are in all menus) in this
control.menu is Count calling list records. Instead of calling another menu, this
runs a PDS binary vfiles. The percent sign (%) before the binary is legacy
which designated that this is a PDS binary to be run. It does not appear to be
needed any longer, but is still there in most baseline menus.
The next line is AppendLIst, which calls a script, create_append, since this is a
script, it is not preceeded by the %. Then there is another binary, %createop
and then another script, extract_records. Each one of these runs immediately
when called.
The next option is Edit, which does not call another menu, or a binary or script,
but calls another type of menu, the *.cmd. In this case the menu binary will
use configuration in the edit.cmd file for displaying the options. Notice the
formatting is very different from what is in the .menu file and display is different
from the menu screens. In the menus you have two colums, one for the
commands and one for items (in this case the items is blank, others are not and
you will see those later). In the .cmd file you see the WELCOME line is for the
title of the screen, the helpname (which relates to option 2, Display help, which
calls the edit help file). ITEMDIR is for when directory items need to be listed
on the second column and EXTEN is for what files types to show.
The options that you have in the menu start with the F2 line. Binaries and scripts
can be called from the .cmd file as well, but here they are in the second field of
the line.
The next three fields are YES or blank values. The first one is for holding the
output of the command (making the user “press any key to continue” when the
command finishes instead of going right back to the menu). The second is for
a verification of your choice (since things like shutdown the PDS are options
from a .cmd menu, it is good to ask the user “are you sure?” before just
shutting down). The third is for whether a selection from the items column
needs to be made or additional entries need to be entered..
The next fields allow arguments to be added to whatever binary or script is being
called. Try the first option to Edit a record. First it asks if you are sure, then it
will ask for additional entries based on the next field, and what you enter will be
used as the argument (s). For this option, just type Screen map “list1” and
 Search Field name “ACCTNUM”. This initiates the record_ed binary with
arguments “list1” and “ACCTNUM.”
You cannot call another menu or another cmd from one of these .cmd screens.

All CUI menu options call other functions that can be done from the command
line instead of through the menus. In the next two chapters you will be using
the menus to edit and run call selections, start jobs, and download calling lists.
Throughout this course, menus options are used sometimes and the actual
commands will be used other times.
Most PDS Support engineers use the menus when they start out until they learn
the actual functions behind the menu options. There is no expectation that you
should know each binary and script’s function, you may need to refer to menu
options to figure out what is being called by an option like “download host
records to PDS.” As you get more familiar with the actual scripts and binaries,
you will find yourself relying on the menus less and less. If you want to learn
the command line versions of each option, look though the menus and then
grep that line from the .menu and .cmd file.
For example, the menu option discussed above - Count calling list records runs
the vfiles binary. You do not need to memorize the binary vfiles today, if you
cannot remember it, you can use grep -i to search all files in the menus
directory for “count”:
REDTS35(admin)@/opt/avaya/pds [19]
$ grep -i count /opt/avaya/pds/menus/*
control.menu:Count:Count calling list records:YES:::1:0:%vfiles
control.menu:Users:Manage user accounts::::1:0:%createop
inbnd.cmd:F4:%vfiles:YES:::Count calling list records
transfer.cmd:F5:%vfiles:YES:::Count calling list records
From this you can see that vfiles is the binary that is called from three different
files (a .menu file and two different .cmd files) to “Count calling list records.”
And this also gives you a distinct comparison of how a binary is called from
each type of menu.

There is more information about the *.menu and *.cmd files in the reference
guide. Use this information and complete exercise 15_1 at the end of this
chapter.

• /opt/avaya/pds/config/locale.cfg, timezone.cfg, and stdday.cfg

There was an administrative task you did earlier in the course that involved
modifying the area codes and viewing time zones of the PDS. The menu
option was under the Administrative tasks from “sysadm.”
Now that you are familiar with the menu structure, you can look in the
sysadm.cmd file and see that when you used that menu option, it ran a shell
script called locale_ed.
This script edits the area code table, the locale.cfg and displays information from
the timezone.cfg file (does not allow edits to that file).
Prior to version 11x, PDS Support would have to update the locale.cfg file
(named vllocale.cfg in 9x and 11x).
Though System Operators/Administrators are now responsible for updating the
area code table themselves, it is important to know how to read the locale.cfg
file.
• Read through the comments in the locale.cfg file for information
Focus on the REJECT, ZONE, and AREA_NUMBER fields, which is where the
majority of PDS Support work is done.
If you don’t remember how the area code editor displayed information when you
ran it earlier, use locale_ed (or run it from the menus) to refresh your memory.
This script is reading the information out of this file.
Also, look through the timezone.cfg and how the information is displayed in
locale_ed. Typically, the timezone.cfg file should not be altered, but it is not
uncommon for System Operators to ask that the guard times be adjusted (they
are baseline set to stop calling at times like 20:45, some may wish that to be
changed to 20:55.
The business is responsible for guard time regulations, not Avaya, so if they
request to turn off the guard times, it is up to them, you should just warn them
of the danger of doing so, which is legal calling times.
The last config file that is in the same category is stdday.cfg. This file sets the
date when daylight savings time changes. It is very seldomly altered, but has
an impact, so should be mentioned. If any questions come up about the
system automatically adjusting for daylight savings time in various areas of the
world, it does, and when the changes are made is based on this file.

• /etc/hosts
The hosts file associates an IP address with a host name and alias for any
network resource or computer system the PDS will connect to. Look at the
hosts file on redts35.
The hosts file is useful to telnet to different PDS or to telnet to or ping other
components that are connected to the dialer. Often a business will have a
number of PDS, either in a pod or not. Commonly, the other systems will be
noted in this file with an alias and an ip address so PDS Support can easily
move between each dialer. Also, an alias for mosupport is often in the hosts
files which makes it easier to ftp to the Redmond platform when having to move
files around.
Also, if the serial connection to the switch is not functioning (sdsc1), a telnet
session can still be created from the command line: telnet switch1.
Additionally, information from the hosts file is useful in determining which IP
address to ping when there are network issues. There may be an IP for
something else in the network.
Quiz 15_2
1. Log into redts35 and find the values for the following settings.
a. CALL_BLENDING
b. BUSYONSTART
c. CYCLE_LIM
d. SYSOPS
e. TZ

2. Look up the syslog and log_file on redts35. Note 3 useful pieces of

information from each.

3. Give the IP address on redts35 for the following components:

a. switch _________
b. router _________
c. localhost __________

4. When configuring menu options

a. You can call a submenu (.menu and .cmd) from any other .menu or
.cmd file
b. You can run a binary and shell script only from a .cmd menu
c. You can run a binary and shell script from either a .menu or .cmd file
d. a. and c.
Section 15_3
Crontab
Expectations
Upon Completion of section 15_3, you should be able to do the following:
1. Interpret the crontab file and determine when commands will execute.
2. Write a new line in the crontab file and make it active.
3. Define /dev/null and describe its’ use in the crontab file.
4. Define a “full path” for a file.

Terms and Commands

cron Unix process that executes commands at specified dates and times

crontab Unix command used to edit or execute the active crontab file

1>, stdout standard output, defaults to tty of person executing command

2>, stderr standard error, defaults to tty of person executing command

/dev/null Unix device file used to send unwanted output, in effect, a trash bin

path location of a Unix file in the logical structure, a full path begins at the
root (/)
tty terminal session associated with a logon

# in the crontab file, everything on the line after the mark is a comment
and will not be executed
About Crontab
Unix has a built-in facility called cron that schedules commands or programs to
be executed at a specific time. Cron runs all the time and executes commands
that are listed in its crontab (literally cron table). A crontab file is a list of
commands with the desired times of execution in a particular format. A PDS
will typically execute several commands from the crontab file, including the
nightly restart of the PDS processes, and most downloads.
The crontab can be displayed by typing crontab –l

• Run crontab –l on redts35.

Below is an example of a line from this crontab file which is a reboot of the CPU
done Sunday morning at 01:01 am.
# Weekly reboot on Sunday
02 01 * * 0 . /opt/avaya/envdir/envfile cron; $SHELLDIR/pds_shutdown
1>/dev/null 2>&1

First, comments in the crontab file are indicated with a # symbol. Anything that
appears on a line after the # will not be executed by cron. Comments are often
used to help group a series of commands that are of a similar nature, for example,
put all the downloads together under the heading “ #File Transfer”. Try to maintain
groupings so that PDS Support can find each entry easily.
Other than groupings, comments are usually used to explain the reason a line is in
the crontab, or give other useful information such as saying who made a temporary
change and when it should be removed.

In the actual line that is executed, the first set of 5 values is the time/date to run
what follows. The 5 fields of numbers listed before the command are defined in
this order:
Minute 0-59
Hour 0-23
Day of month 1-31
Month 1-12
Day of week 0-6 (0 is Sunday)

Use a comma between multiple values (like running a command at 08:30 and 08:40
would need to look like “30,40 08” , a hyphen (-) for a range (run each hour 05-09
at 30 past “30 05-09”) and an asterisk (*) to indicate all possible values.
For example, the above line for the Sunday reboot shows 02 for the minute, 01 for
the hour, * for both day of month and month, and 0 for Sunday. So that means that
every Sunday at 1:02 this is excecuted (no matter the month and day of the
month). This number of fields allows for whatever is being exceduted to only run
once a year, or even less (for example, setting up the command to run on a
Sunday which is also the 4th of July, this will only happen about every 7 years
(depending on leap year).
It is important to think about the hour and minute being switched when you read
a crontab file, because we are accustomed to reading time in the larger to
smaller order, whereas the cron program reads it from smaller to larger, with
day of week on the end.

The next entry is “. /opt/avaya/envdir/envfile cron;”, this runs the cron file and
sets up the environment for it. This should be in all entries in the crontab file,
and if not, the command will likely not run.

The next entry is the command. The $SHELLDIR can be used because it is
defined in the cron environment to know this is the shell directory.
pds_shutdown is the command run. If any variables need to be set for the
script, they can also be entered (see other entries in the crontab file for
examples.

Redirecting output.
Now, look at the segment “2> /dev/null 1> &2”, which redirects output to the
/dev/null file, a Unix equivalent of the Recycle Bin. Be careful, when you send
something to /dev/null, you cannot get it back. 2> is a Unix variable used to
redirect the standard error (stderr) of a command to something other than the
default. 1> is the Unix variable used to redirect the standard output (stdout) to
something other than the default.
The default for output in both cases is the tty or terminal session associated with
the logon executing the command. In the case of the crontab, there is no tty
associated with it, therefore the command has no place to send the screen
output that it normally generates. This can cause the program to fail, partially
or completely, so we redirect the output and errors to /dev/null. The &2 for the
output of 1> works as a shortcut, /dev/null would work there as well.

To change the crontab, you need to edit the crontab file just like any other file.
Initiate the edit by typing crontab –e. vi commands work for editing.
As with all other configuration files, be sure to make a backup before making any
change to the existing file. You can do this by redirecting the output of crontab –l
to a file just in case you delete something you did not mean to: crontab –l >
/tmp/crontab.<yourinitials>
Quiz 15_3.

1) When will this command run?

01 00 * * 1-6 . /opt/avaya/envdir/envfile cron; $SHELLDIR/pds_maintenance 1>/dev/null 2>&1

2) What would the command(s) to do the following look like?

a) Run db_mgr (see crontab on redts35 for an example) at 3 A.M. every
day
b) Reboot the system (pds_shutdown) at 2 AM, Monday through Friday
and at 1 AM Saturday and Sunday
c) Run a custom script called htovl_cust at 7:05 AM, on the 1st day of every
month, except January. Run the script on the 2nd of January.
Remember that all custom scripts are located in /opt/avaya/pds/customs
Exercise 15_1: Add a menu option to check disk space.
It is not uncommon for PDS Support to add a menu option for allowing the
System Operator/Administrator to check the hard drive space on the CPU. The
Unix command bdf outputs the disk usage. Try this at the command line to see
the output. What you will do in this exercise is add a menu option to allow the
PDS Administrator to run this. You will add this to both a .menu and a .cmd
file. We want to add it to the Administrator main menu and the Administrative
tasks sub menu.
First, add it to the Administrator main menu (the name of the menu). To find
which menu file this is, you can grep –i administrator * in the menus directory.
Look for the .menu file with the title in the WELCOME line and that is the file
you want to modify. You can see that it is the sysadm.menu. So, to look at
how that menu currently looks, type menu sysadm. Decide where you want
the check disk space option to go in the menu so you know where to insert the
new line. Back the sysadm.menu file up and then use vi on the original file to
add a line which will call the binary bdf. You can use any other .menu line
which calls a binary as an example of the format (such as the Count Calling list
records discussed earlier in the chapter). Since this is not a PDS binary, do not
use the % in front. You can use any short description and text you want.
Once saved, go into the menu and make sure it works. Now, go back into the
.menu file and remove the YES from the <anykey> field and save it. Now try
the menu option again. Notice that it does not appear to work, the screen just
flickers and you are still in the menu. What is actually happening is that the
binary is run in the background, but the output is not held on screen and waiting
on the user to “press any key to continue.” From the command line, run bdf
again, notice that your cursor goes back to the command line immediately.
So, when the YES is not in that field, the command runs, the output is
displayed, but it goes right back to the menu. Put the YES back in the .menu
and also add a YES in the <sure> field. Now when you choose the menu
option, it prompts if you are sure before running the binary. Again, this is a
good option to add, asking for verification, if the menu option could cause
problems on the system. If you want to specify a directory of the command to
run, notice the <dir> field.
Note your final line in the .menu file here
_______________________________________

Now, add the bdf to the .cmd that is called when you choose Administrative tasks
from the Administrator main menu. You can see from the .menu file which
.cmd it is. Back that file up and using the reference guide and other lines in
.cmd files as reference, add a line for the bdf option. Again there are two fields
that you can populate with YES for verification and for keeping the output of the
command on the screen after it is run.
Note your final line in the .cmd here ____________________
Move the original .cmd and .menu files in place over your modified version (do
not leave a version that has the answer so that the next student to go through
the exercise will not have references.