|
|
Home » Starter Kit » TOC » Chapter 14
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 TellYou 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 HousekeepingThe 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:
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 InformationCareful 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 © 2008 - Penton Technology 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. |