Starter Kit- Chapter 14 System iNetwork (formerly iSeries Network)
Home Site Map Contact Us My Profile Log In Join Now!
Info Centers
 Forums

 Tech Center

 News & Analysis

 Solution Center

 UK Centre
Popular Spots
 25th Anniversary

 Article Archive

 ProVIP Center (Club Tech)

 Code

 System i DocFinder

 Essential Guides

 Blogs

 Wikis

 e-Learning

 Webcasts

 Podcasts

 System i Jobs

 Events
Products
 i5 Route Finders

 Learning Center (Store)

 Product Directory
Network Poll
Determining a programmer's desktop requirements is not a black-and-white proposition, but matching equipment to programmer type can help productivity. Which "programmer type" are you?
Vote Now!
Network Memberships
 See Membership Levels

 Free E-Mail Newsletters

 Free RSS Feeds

 Subscribe/Join

 Upgrade Now

 Renew Now
About Us
 About the Network

 Network Publications

 Tech Editor Profiles

 Editorial Calendar

 Contact Us

 Subscribe

 Media Kit (PDF)

 Write For Us


System iNetwork January Sponsor





        System iNetwork January Sponsor


Home » Starter Kit » TOC » Chapter 14
  AS/400-iSeries Starter Kit


Chapter 14 - Keeping Up With the Past

For many of you, AS/400 job processing is new, or at least different. There can be multiple subsystems, job queues, output queues, and messages flying all over the place at once. You can sign on to the system and submit several batch jobs for processing immediately, or you can submit jobs to be run at night. At the same time, the system operator can run jobs and monitor their progress, and users at various remote sites can sign on to the system. With so much going on, you might wonder how you can possibly manage and audit such activity.

One valuable AS/400 tool at your fingertips is the history log, which contains information about the operation of the system and system status. The history log tracks high-level activities such as the start and completion of jobs, device status changes, system operator messages and replies, attempted security violations, and other security-related events. It records this information in the form of messages, which are stored in files created by the system.

You can learn a lot from history -- even your system's history. By maintaining an accurate history log, you can monitor specific system activities and reconstruct events to aid problem determination and debugging efforts. Please note that history logs are different from job logs. Whereas job logs record the sequential events of a job, the history log records certain operational and status messages pertaining to all the jobs on a system. You can review the history log to find a particular point of interest, and then reference a job log to investigate further.

System Message Show and Tell

You can display the contents of the history log on the AS/400 by executing the DSPLOG (Display Log) command

DSPLOG LOG(QHST)

The resulting display resembles the screen in Figure 14.1. The DSPLOG command lets you look at the contents of the history log as you would messages in a message queue. Because system events such as job completions, invalid sign-on attempts, and line failures are listed as messages in file QHST, you can place the cursor on a particular message and press the Help key to display second-level help text for the message.




The DSPLOG command has several parameters that provide flexibility when inquiring into the history log. To prompt for parameters, type in DSPLOG and press F4. The system displays the screen shown in Figure 14.2. The parameters for the DSPLOG command are as follows:

LOG The system refers to the history log as "QHST." QHST provides many of the functions the QSRV and QCHG logs provide on the S/36.

PERIOD You can enter a specific time period or take the defaults for the beginning and ending period. Notice that the default for "Beginning time" is the earliest available time and the default for "Beginning date" is the current date. To look at previous days, you must supply a value. Enter values as six-digit numbers (i.e., time as hhmmss and date as mmddyy).

OUTPUT You are probably familiar with this parameter. The value * results in output to the screen, and *PRINT results in a printed spooled file.

JOB You use the JOB parameter to search for a specific job or set of jobs. You can enter just the job name, in which case the system might find several jobs with the same name that ran during a given period of time. Or you can enter the specific job name, user name, and job number to retrieve the history information for a particular job.

MSGID Like the JOB parameter, this parameter helps narrow your search. You can specify one message or multiple messages. By specifying "00" as the last two digits of the message ID, you can retrieve related sets of messages. For example, if you enter the message ID CPF2200, the system retrieves all messages from CPF2200 to CPF2299 (these are all security-related messages).




History Log Housekeeping

The history log consists of a message queue and system files that store history messages. The files belong to library QSYS and begin with the letters QHST, followed by a number derived as QHSTyydddn. The yyddd stands for the Julian date on which the log was created, and n represents a sequence character appended to the Julian date (0 through 9 or A through Z).

The text description maintained by the system contains the beginning and ending date and time for the messages contained in that file, which is helpful for tracking activities that occurred during a particular time period.

You can use the DSPOBJD (Display Object Description) command to display a list of history files. The command

DSPOBJD OBJ(QSYS/QHST*) OBJTYPE(*FILE)

results in a display similar to the one shown in Figure 14.3. The system creates a new file each time the existing file reaches its maximum size limit, which the system value QHSTLOGSIZ controls. Because the system itself does not automatically delete files, it is important to develop a strategy for deleting the log files (to save disk space) and for using the data before you delete the files.




You should maintain enough recent history on disk to be able to easily inquire into the log to resolve problems. The best way to manage history logs on your system is to take advantage of the automatic cleanup capabilities of Operational Assistant (OA). The OA category "System Journals and System Logs" lets you specify the number of days of information to keep in the history log. OA then deletes log files older than the specified number of days. (For more information about Operational Assistant, see IBM's AS/400 System Operations: Operational Assistant Administrator's Guide (SC41-8082).)

Keep in mind that OA does not provide a strategy for archiving the history logs to a media that you can easily retrieve. If you activate OA cleanup procedures, make sure that once each month you make a save copy of the QHST files. If you are remiss in performing this save, OA will still delete the log files.

If you elect not to use this automatic cleanup the OA offers, you can do the following:

  • On the first day of each month, save all QHST files in library QSYS to tape. It's probably wise to use the same set of tapes and save to the next sequence number. For quick reference, record on the tape label the names of the beginning and ending log files. You can use the DLTQHST utility (from the QUSRTOOL library) to delete old history files.

  • View the existing log files on the system and delete any that are more than 30 days old. (Hint: Remember that the text description contains the beginning and ending date and time to help you determine the age of the file.)

To determine how much history log information to keep, you should consider the disk space required to store the information and schedule your file saves accordingly. In most cases, it is a good idea to keep 30 days of on-line history, although large installations with heavy history log activity may need to save and delete objects every 15 days.

Inside Information

Careful review of history logs can alert you to unusual system activity. If, for example, the message "Password from device DSP23 not correct for user QSECOFR" appears frequently in the log, you might be prompted to find out who uses DSP23 and why (s)he is trying to sign on with the system security officer profile. Or you might notice the message "Receiver ACG0239 in JRNLIB never fully saved (I C)." The second-level help text would tell you which program was attempting to delete the journal receiver. If these events are brought to your attention, you might be able to prevent the loss of important information.

Maintaining a history log lets you reconstruct events that have taken place on the system. In reviewing its history log, one company discovered that a programmer had planted a system virus. A history log can also alert you to less serious occurrences (e.g., a specific sequence of jobs was not performed exactly as planned). Or you can use it to review all completion messages to find out how many jobs are executed on your system each day or which job ended abnormally. As you monitor the history log (preferably every day), you will soon start to recognize the messages that are most beneficial to you.

The history log is a management tool that lets you quickly analyze system activities. It provides a certain amount of security auditing and lets you determine whether and when specific jobs were executed and how they terminated. Using and maintaining a history log is not difficult and could prove to be time well spent.

Note: The security journaling capabilities that OS/400 offers using the audit journal QAUDJRN provide additional event-monitoring capabilities specifically related to security. This new journal is capable of monitoring for the security-related events recorded in the QHST as well as additional events that QHST does not record. For more information concerning QAUDJRN, see the AS/400 Security Reference (SC41-8083).


Starter Kit for the AS/400, 2nd Edition
Copyright 1994 by Duke Press
DUKE COMMUNICATIONS INTERNATIONAL
Loveland, Colorado

All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher.

It is the reader's responsibility to ensure procedures and techniques used from this book are accurate and appropriate for the user's installation. No warranty is implied or expressed.

This book was printed and bound in the United States of America.
Second Edition: April 1994

ISBN 10882419-09-X



  Sponsored Links   Featured Links


Penton Technology Media
Connected Home | SQL Server Magazine | Windows IT Pro
Report Bugs | Contact Us | Comments/Suggestions | Terms & Conditions | Privacy Policy | Trademarks
See Membership Levels | Subscribe | Free E-mail Newsletters | Free RSS Feeds | My Profile | Upgrade Now | Renew Now

Copyright © 2009 - Penton Technology Media
Penton Media
System i is a trademark of International Business Machines Corporation and is used by Penton Media, Inc., under license. SystemiNetwork.com is published independently of International Business Machines Corporation, which is not responsible in any way for the content. Penton Media, Inc., is solely responsible for the editorial content and control of the System iNetwork.