IMS AUDIT

OBJECTIVE - To ensure that the use of IMS database Management System by

individual application systems is controlled and provides control over the
application.

DATABASE ORGANISATION

1. Determine which databases are accessed by the particular application from

discussion with IS personnel and examination of available documentation.

2. Determine the organisation of each database. If the organisation is HDAM,

ensure that there is no need to process data sequentially as HDAM databases
cannot be processed in this way.

3. Determine why the particular organisation of the database was chosen. Has
account been take of the level of volatility of the database (i.e. number of
segments added and deleted on a regular basis). HSAM databases are better
suited to highly volatile applications.

4. Is use made of GSAM. Normal sequential files can be defined as GSAM

databases. This allows IMS to control rollback and recovery in the event of
failure. Are there any sequential files feeding IMS jobs where this facility
would be useful.

5. Are any databases defined as MSDB (main storage database). These are
resident in memory and have the advantage of fast access times. However, if
the machine goes down, data will be lost resulting in a failure to recover
updates. Some logging does occur, but there is no update on disk. Are these
databases being used for reference purposes only? Are there any reference type
databases which would benefit from being MSDBs and has this option been
considered.

6. Are DEDBs (data entry databases) being used. If they are, determine how
many copies are being maintained (up to 7 are allowed) to allow for restart
and recovery. Is this adequate.

7. For HISAM databases, determine the number of secondary indexes being used.
Determine the reasons for the secondary indexes and ensure that all access
routes are justified. Determine is additional routes are required. Increasing
the number of secondary indexes reduces performance and increases storage
requirement.

8. Is any use made of logical databases. These define the logical relationship
between non-physically related segments (e.g. across different databases).
This definition can be used to maintain structural integrity for a database.

DATABASE DEFINITIONS (DBD)

A DBD is a definition of the physical database.

1. Determine where DBD source macros are held and ensure that they reside
in a
library which is protected by RACF. Review access lists to ensure that they
can only be updated by DBA.

2. Determine which DBD macros apply for the databases used by the application
under review.

3. Determine the IMS access method from the DBD macro. If this is not VSAM,
determine the reasons from DBA and evaluate.
4. Determine the dataset names of each database and ensure that the physical
dataset is adequately protected with RACF. The ddname can be determined from
the DATASET macro in the DBD. It should be noted that IMS databases are
effectively VSAM file which can be accessed via normal methods and utilities
when not under the control of IMS. They must therefore be protected by
RACF to
prevent changes being made outside the control of IMS.

5. Map out the hierarchical structure of the database and review the data
contents of each segment. Do any segments contain data items which should not
be accessed together for any reason (e.g. would impact level of control). IMS
can only control at the segment level. The IBM utility DMAP can be used to
draw the hierarchy automatically. Also ensure that segment contents do not
conflict with business entities or requirements.

6. Determine which fields are search fields. These are defined within the
FIELD macro as NAME=(abc,SEQ,U) where abc is the data field name. Defining
search fields no longer represents a major overhead to the system. Determine
if all defined search fields are valid and if others are required.

7. When key sequence fields are defined as "U" in the FIELD macro, IMS ensures
that they contain unique values. For root segments this means that the field
will be unique across the database. For siblings, the uniqueness is maintained
only within the particular parent. When "M" is specified, multiple occurrences
of a particular value are allowed. This is mainly useful where dates are used
as search fields. Determine whether the specification of search fields as
unique or multiple is based on valid business requirements remembering that
specification of M for data which requires to be unique may lead to unrequired
duplication.

8. IMS stores data in ascending sequence. Where dates form part of the key
sequence, the latest data will be the last read. Where performance is an
issue, it is a valid technique to subtract the date from 999999 in order to
invert the date sequence and ensure that the latest data is first in the
database sequence. Where this type of access is required, ensure that this
technique is used or has been taken into account.

9. The RULES parameter on the SEGM macro defines where to insert a duplicated
segment. This can be inserted FIRST (before other duplicates), LAST (after
other duplicates) or HERE (wherever the application program decides). This
could be manipulated to perpetrate fraud. Evaluate the effect of inserting a
duplicated segment and determine whether the RULES will help prevent
misuse or
error, especially when RULES=HERE is specified.

10. Determine if there are any secondary indexes associated with the database.
This can be determined by the presence of a LCHILD and corresponding XDFLD
macros in the DBD. NB to ensure the use of the secondary index during a search
the XDFLD name must be used not the original field name. Determine that all
applications make use of the secondary indexes where necessary and determine
if additional indexes are required.

11. Determine if any logical relationships have been defined by review of DBD
for LCHILD macro with no associated XDFLD macro. Determine what RULES are set
up for ADD, DELETES and INSERTS. Are these rules realistic. For example, when
a "logical" parent is deleted, should the physical parent be deleted as well.

PSBs and PCBs

A PSB (Program Specification Block) is a definition of the applications view

of the data and terminals. The PSB contains PCBs (Program Communication
Blocks).

1. Determine which PSBs are used within the application by review of the
//EXEC statement on the relevant program JCL.

2. Determine where PSBs source is maintained and ensure that libraries are
protected with RACF. Ensure that update access is limited to those persons
responsible for maintenance of PSBs. Who is responsible for maintaining PSBs.
Does this provide for division of duties.

3. Determine what type of PCB is contained within the PSB. A terminal will be
defined with a TYPE=TP and a database will be defined with a TYPE=DB.

4. TERMINAL type allows output to be sent to another terminal (for

example, to
send messages to a security terminal). If this type of PCB is used, determine
why and identify the terminal in question. This can also be used to route
error messages to a particular terminal or printer rather than abending. This
enables a controlled abend under IS control to be carried out depending on the
severity of the problem.

5. If the MODIFY=YES parameter is used, the program can determine the

destination. If this is set, determine why and evaluate. If output is
sensitive, ensure that destination is not modifiable.

6. If EXPRESS=YES parameter is specified, output is sent to terminals even if

a program abends. This could cause problems where the output is sensitive
(e.g. cheques) as duplicated output could result when program is restarted or
rerun. Ensure that this is taken into account where this parameter is
specified.
7. DATABASE type allows definition of the segments which can be accessed
by a
program. Ensure that the program can only access those segments which are
appropriate for its processing and that no inappropriate data can be accessed.

8. Ensure that the processing options (PROCOPT) are appropriate for the
program (e.g. enquiry programs should not be allowed to add, delete etc.).
Note that a global PROCOPT can be defined on the PCB macro, but will be
overridden by a PROCOPT entry for an individual segment (on SENSEG macro).

9. Ensure that there is one PSB specified for each program. If multiple
programs use a single PSB there is a danger that if the PSB is changed,
programs may acquire inappropriate privileges over data.

10. Determine the value of the POS= parameter on the PCB macro. This
determines the number of "positions" within the database which can be
maintained by IMS. POS=S means that only the current position can be recorded,
POS=M allows multiple positions to be maintained. This allows a program to
access multiple segments. Is this parameter appropriate for the method of
processing.

11. If the SENFLD macro is used, this defines the only field which can be
accessed within a segment. It can also be used to prevent changes being made
to a particular field by combining it with the REPL=NO parameter. Multiple
SENFLD macros can be specified within a single segment. Do any of the programs
require such a level of security and, if so, is the PCB defined to allow for
it.

APPLICATION CONTROL BLOCKS

An ACB is unique for every on-line program and can be generated for a batch
program. It is a combination of the appropriate DBDs and PSBs for the relevant
program and speeds up processing. IMS will look for an ACB first before
looking at DBDLIB or PSBLIB for batch jobs. The ACB is generated via the
ACBGEN processing.

1. Database definitions can differ between the ACB and the DBD if the DBD is
changed and the ACBGEN is not repeated. If this occurs the program will pick
up the wrong versions which could result in error. Check the ACBLIB definition
to the DBD and PSB to ensure that they are in line.

APPLICATION CONTROL MACRO

The application control macro (APPLCTN) is part of each IMS system Generation
(SYSGEN). There is one macro for each PSB. This defines the PSB name, the
program type (batch, bmp, mpp) etc. There is also one or more associated
transaction control macro (TRANSACT) which defines transaction codes for the
PSB in the APPLCTN.

1. Determine from review of the APPLCTN macro which PSBs are active.
2. Determine from the TRANSACT macro a list of on-line transactions which use
the PSB.

3. Review the parameters specified on the TRANSACT macro. If the MODE=MULTIPLE

parameter is set this specifies that the unit of recovery is set to multiple
transactions. This increases the risk of loss of data and is not recommended
where the data being entered is sensitive. In this case, MODE=SNGL is
recommended.

4. Where RESPONSE is specified in the MSGTYPE parameter the transaction will

respond to the terminal on completion. This is recommended for all sensitive
data entry to accidental prevent duplication of input.

MESSAGE FORMAT SERVICE

This IMS function allows screen formats to be defined independently of the

application programs. It is not mandatory, but can speed up processing.

1. Determine where screen format source code is maintained and ensure that the
datasets are protected with RACF.

2. Determine which screen formats are used for the application under review
and determine which is associated with each program.

3. Certain fields can be defined as "non display" or "protected". This

provides a certain degree of security. Ensure that all use of this protection
is appropriate and that there are no other fields which should be
protected in
this fashion.

4. MFS contains 256 exits where user written code can be inserted to
manipulate data inserted into a field. Use of exit code can be detected by the
existence of the EXIT= parameter on a field definition. Where exits are used,
determine what is being done by the exit code. Also determine where the exit
source code is maintained and how it is protected.

APPLICATION PROGRAMS

1. Review each application program for compliance with the following simple
rules.

2. Ensure that each program has only a single entry point. This can be
determined by scanning the code for the statement ENTRY 'DLITCBL'.