General Page
When things go awry, look for logs and joblogs to understand what went wrong and how to solve them. This page seeks to provide that information.
Job Logs
The first place to look is in the joblog of the STRFSFLASH command. The joblog will show errors attempting to connect to the source and target partitions, authentication errors, and messages indicating the jobs started on the remote partitions, etc.
Several joblogs will be placed in the configuration directory /QIBM/Qzrdhasm/fsfc/<CSEData name>/. Joblogs from the controlling, source and target LPAR’s are saved with with CTL_, SRC_, and TGT_ prefixes, respectively. Note that it might take a few minutes after a failure for the joblog to be uploaded from the source or target LPARs.
Toolkit Logs
The FSFC Toolkit has a software log which shows the progress of the operations and has more detailed information. Issue the following command to view this log:
QZRDHASM/VIEWLOG
That is the main log, which is stored in file /QIBM/Qzrdhasm/qzrdhasm.log and exists on controllers, source and target LPARs.
That log contains the information for every command, and may contain information redirected to another log file, for example:
732199 2017-10-06 10:47:34 Start CHKFSFLASH for DUMMY starting from job 732199/TKH/QPADEV001L
Compile Date/time: Sep 29 2017 11:57:25
732199 2017-10-06 10:47:34 Detail records for CHKFSFLASH DUMMY are logged in /QIBM/Qzrdhasm/fsfc/DUMMY/ctl.log (qzrdiaFFMC)
In the example above, the job information and toolkit compile data is shown, and then a message indicating the logging continues in another file. We did this to avoid confusion when multiple STRFSFLASH's are running, i.e. each one will have it's own log.
Note that the VIEWLOG command also contains a parameter to view the logs on remote systems. This uses the QFileSvr.400 file system.
AutoUpdate Mode
If there is a need to monitor the progress of the Full System Flash Copy toolkit, follow these directions to view the log as updates occur:
-
On a command line, issue the command qsh and press enter. This will enter the QSH Command Entry.
You can also use an ssh client (putty, etc) from your desktop to connect to the IBM i -
Type the following command and press enter (substitute the log name if you would like to monitor a different log):
tail –f /QIBM/Qzrdhasm/qzrdhasm.log
-
As entries are placed in the log, the display will be updated.
-
To exit QSH, press F3.
BRMS Logs
If the backups fail, look in the BRMS log for details. Use the command DSPLOGBRM to access this information. F4 on a message will provide information such as user, name and job number which will allow you to access the job log for that backup.
Note: if you are viewing the BRMS Log on the source partition but the backups were performed on the target partition, you’ll need to view the joblog on the target partition.
DSPLOGBRM
This is the quintessential place to view BRMS errors, and is usually a good starting point for determining if there is a problem.
Flight Recorder
BRMS has a software flight recorder located at /tmp/brms/flightrec and /tmp/brms/flightrec.bku. These logs have a wealth of information, but are not very useful without intimate knowledge of BRMS.
When /tmp/brms/flightrec reaches a certain size, it is copied and appended to /tmp/brms/flightrec.bku. Both of these files are occasionally overwritten. In the event of a BRMS error, it is recommended that these two files be copied to prevent them from being overwritten.
The BRMS logging directory /tmp/brms/ is brought back from the target LPAR to the source LPAR and placed into /tmp/brms/fsfc/. Note that this directory is overwritten each time. The intent is to bring back the information about the most recent BRMS activities from the target LPAR.
Was this topic helpful?
Document Information
Modified date:
17 December 2019
UID
ibm11137538