|
GSMonitor/400
The Application for
Monitoring the AS/400 Server
|
|
|
|
|
|
The
presented GSMonitor/400 application is intended for administrators of the
OS/400 operating system in manufacture, trade and service companies. The
construction of the application allows to obtain information about current
problems in the OS/400 system, both to any mobile phone (most often the
system administrator’s one) and to any e-mail box. The GSMonitor/400
application can operate on any type of IBM AS/400 minicomputer. Because of a
high calculating capacity of this type of device and capabilities of the
operating system, the application is intended for average and big companies. Besides the
main function of the GSMonitor/400 application, which is to detect current
messages occurring in the system and to send them to a defined address – a
mobile phone or an e-mail box, the presented program to a high extend
facilitates the AS/400 administrator’s work by means of a built-in database.
This database allows to define an automatic reaction of the program to a
possible problem, which may occur in the OS/400 system. The GSMonitor/400
application enables to define any number of addressees of messages from the
internal database. The project
assumption of the presented application was that the program should enable
the user to define in the application database possible reactions to any
event which occurs in the system (registered in the system logs). The best
example is a situation when there is a low critical value of the free disc
space. The system informs administrator about that sending an SMS to his
mobile phone and can also inform any number of recipients. Besides that the
application performs by itself an operation which is defined in the internal
database, e.g. restarting of the OS/400 system, copying of specific libraries
to another system, or switching off the server. Basic
interface of the internal database and defined prompts for each field allow
to limit the work consumption and to minimize the risk of mistakes during the
data entering. An addition
to the program is the CGI interface, which enables to access the internal
database from an Internet browser. The HTTP server must be run. This solution
eliminates a need to use the IBM Client Access 400 application. A next part
of the application, which enables to send controls to the AS/400 server from
a mobile phone as an SMS, is under construction. The task that is now
considered is – how to enter the system in a safe way when controlling it by
an SMS. One of possible solutions, when coding of an SMS is not allowed, is a
“one-off password system”.
2. Servicing the „GSMonitor/400” application. 2.1. Configuration. The GSMonitor/400
application must be configured before the first running in order to work
properly. For that purpose the CONFIGFILE configuration file is used. This
file is managed by the CONFIG program, which is run from the level of the
DATA FILE UTILITY tool delivered with the OS/400 system. The configuration consists in
filling in each field in the CONFIGFILE, namely: an IP address of the mail
server in a company, a name of the domain in which the mail server is
located, a name of the physical file which includes the database of messages
and reactions to them, a default value of the priority (only messages with a
higher priority than the default one will be sent to the recipients), and a
default address of the system administrator (mobile phone or e-mail box)
where messages will be sent. If the
configuration file is not filled in correctly, then during running the
GSMonitor/400 application the following message appears: „Please fill in the
fields of the configuration file”. The tool
for managing of DFU files is run by means of the following command: > STRDFU .
2.2. Running. GSMonitor/400
may be run in a few ways: a) in the QINTER subsystem (as an interactive
job) by means of the command: > CALL
GSMONITOR Remarks: under an assumption,
that the GSMMONITOR library is placed on a so-called “liblist” (*LIBL) or at
a given moment we are inside the GSMONITOR library. Otherwise, during running
the program we must also enter a library where the program is placed, as one
of parameters of the CALL command. b) in the QBATCH subsystem (as a
batch job) by means of the command: >
SBMJOB(CALL PGM(GSMONITOR)), Remarks: as
in the a) subpoint. c)
as a new
entry in the Job Scheduler, which can be called e.g. by means of the command WRKJOBSCDE,
next by means of option No. 1 - ADD a new entry and in the command
line enter the command: >
SBMJOB(CALL PGM(GSMONITOR)), next in the remaining parameters
define the time in which the program must be run, e.g. every day in the
morning from Monday to Friday at 6 o’clock. As a result
of running the application in an interactive mode, after completing the work
with a session/job (in the QINTER subsystem) in which the GSMonitor/400 job
was started, the work of the GSMonitor/400 application is also completed. Running the
program as a batch job (in the QBATCH subsystem) is free of the above
deficiency, but after restarting the system, e.g. at night, the program must
be run again. The last
way is free of both deficiencies. It is the best method of constant
monitoring of the AS/400 server work by means of GSMonitor/400.
2.3.
Working with the GSMonitor/400 application. Both before
and after running the program it is possible to access to the internal
database (reading and changing) and to change the value of the main priority.
The main priority is used to establish the threshold from which the messages
will be sent to the administrators. 2.3.1.
Changing a value of the main priority. The main
priority may assume values of integer from (0,9). The lowest priority equals
0 and then GSMonitor/400 sends all messages to the recipients. The highest
priority equals 9 and then only critical messages are sent to the recipients.
In order to change this parameter the DATAAREA object was used, the name of
which is PRIOR, and the value of which is changed by means of the command: > CHGDTAARA DTAARA(PRIOR) VALUE(here_new_value) After
calling the command above and pressing the ENTER key, the program sends to
the recipients only these messages defined in its database the priority of
which is higher than or equal to the value of the PRIOR parameter. Example: GSMonitor/400
was run automatically at 6:00a.m., with the default value of the main
priority equal to 5. An administrator came to work as usual at 8:00a.m., and
he immediately found out that in 1 hour’s time he would have to participate
in an important meeting. In order both to have constant control over the work
of the AS/400 server and to be able to participate in the meeting, he decided
to have messages sent only in case of critical situations. So, by means of
the command entered from the command line:
> CHGDTAARA DTAARA(PRIOR) VALUE(9) He changed the value of the main
priority to 9. Next after leaving the meeting room, he went for lunch, and
finally after 2 hours he decided that he wanted to have the situation
monitored with the message priority equal to 3 and higher, so in order to
achieve he entered the command: > CHGDTAARA DTAARA(PRIOR) VALUE(2) End of example.
2.3.2.
Working with the internal database. The
database was designed in such a way as to enable a user simple and fast
modification of its records or clear view of resources. Data from database
are placed in a file, the name of which was indicated in a CONFIGFILE before
running GSMonitor/400 (default name – MSGDATA). Each record has 5 fields that
enable to input the proper values. Presented below is an exemplary record
from the database. ID CPI7E48 PRIORITY 8 WEIGHT 4 COMMENT Ethernet resource failed. COMMAND *DFT The first field called ID (message
identifier) enables to input the so-called MSGID, which describes a given
message in the OS/400. The field is of a character type with length 7. The second
field is used to
give a priority value to a given message, so here the decision about its
importance for the administrators is made. The field is of a character type
with length 1 and for proper work of the program may assume values of integer
from (0,9). The third
field called
WEIGHT (of a command) enables to set a weight of a given record in the
database with the same message identifier – the same value of the ID field.
The order of performing the commands in the database for the same message may
be changed by rearranging records just by changing values of the WEIGHT
field. The field is of a character type with length 1 and for proper work of
the program may assume integer values from (0,9) and character values from
(A,Z). The value of this field is unique, that is in the database there can
be only one record with a given value of this field. The fourth
field called
COMMENT is used to input in the database a comment or a description to which
situation in the system a given record is related. This filed is useful
during review of the records in the database. The field is of a character
type with length 62. The fifth
field in the
record called COMMAND is used to enter a reaction which should occur after
the appearance of a given message in the OS/400 system – the record with
proper values of the ID and WEIGHT fields. In this field commands of the CL
for OS/400 may be entered. The field is of character type with length 375.
The field has the *DFT default value, thanks to which the content of the
message is sent to an administrator whose address was given in the
CONFIGFILE. For review
and modification of records in the database the program called BAZA is used.
It is delivered together with the GSMonitor/400 application and it is run
from the level of the Data File Utility (DFU). Example: An
administrator has decided that if in the OS/400 system the message CPI7E48
occurs, the GSMonitor/400 application will react in the following way: 1) switching
the Ethernet line into the VARY OFF state, 2) waiting 60
seconds, 3) switching
the Ethernet line into the VARY ON state, 4) an attempt
to send a message to an administrator (user MARCIN) whose address was defined
in the CONFIGFILE (SMS or e-mail), 5) an attempt
to send a message to the user ANIA to her mobile phone – ANIA works on a
network project, and this information may be useful to her, 6) checking
the status of the Ethernet line – if switched on, an attempt is made to send
the message „Failure of the Ethernet line has been repaired ” to the
user MARCIN to his e-mail box. So for one message the administrator
has decided to execute 6 steps (6 records in the database with the same value
of the ID field), in strictly defined order (the value of the WEIGHT field).
On the previous page there were given the values of fields of the record in
the database which is responsible for the execution of the 4th
command from the example above. End of example.
2.4.
Limitations. Internet.
GSMonitor/400 enables to send messages from the OS/400 system to any e-mail
box on the Internet, so at the moment it requires constant access to the
Internet. The author is working on a solution in the form of a device
connected directly to the AS/400 server, e.g. PCI card, which will make the
GSMonitor/400 application independent of cable networks. GSM
Operator. The
program enables to send messages as an SMS to mobile phones only through the
PLUS GSM gate. The author is working on a capability of using any GSM
operator’s gate, e.g. due to a different range area of every GSM network. Disc space.
The number of
records in the internal database is limited by a disc capacity of the
server. One record consists of 446
text signs, and occupies ... bytes of disc space. Automatic
operations. Each message may have assigned 36 commands
(automatic operations) in the database – the WAGA field assumes values from 0
to 9 (10) and from A to Z (36). The author assumed that it is enough for
program users and for the AS/400 server. 3. Author and license. The author
of the GSMonitor/400 application is Artur Pacut. It is prohibited to
propagate the application without the author’s permission. After
ordering the product, GSMonitor/400 is delivered to the customer with the
license for a specific server. The product is protected – running on a
different server is not possible.
|
|
|
