November 14th, 2008, 06:47 PM
1) After a run completes, if you run amstatus <config> it will rename the amdump and log files by adding the timestamp. Once this happens you cannot run amreport because it cannot find the files.
2) The time stamps in amstatus are difficult to decypher for long runs. Here's an example where I snipped just the top piece.
From Wed Nov 12 15:56:21 PST 2008
MCS1:/export/1-B 0 238g finished (1+8:40:57)
MCS1:/export/C-D 0 301g finished (1:00:55)
MCS1:/export/E-H 0 274g finished (1+17:45:39)
MCS1:/export/I-L 0 210g finished (1+15:10:14)
MCS1:/export/M-P 0 280g finished (9:26:16)
MCS1:/export/Q-Z 0 250g finished (1+1:25:31)
DLE C-D finished first at 1am the next morning. DLE M-P finished at 9:26 the next morning, then E-H at 17:45 that day, then Q-Z at 1:25 the second morning, then 1-B at 8am the second morning and last I-L at 15:10 the second day. You can quickly see how confusing these times are. The problem (I think) is that your mixing elapsed time measurement for the days with real time stamps for the hours and minutes. This entire run took 47 hours so you never measured 2 days from the start time. A simple suggestion would be to drop the 1+ notation in favor of "Nov 13 1:24:31" like is used in the message at the top. Simple and crystal clear to everyone when it finished.
At the bottom of the same output is a report on the dumper/taper activity. These are clearly elapsed times (that's whats in the logs where this comes from). The 1+ notation makes sense here (especially if it's not used in the timestamps above) but I might suggest just letting the hours count up producing 47:13:35 for the first entry. This would make it consistent with the body data produced in amreports, an in my personal opinion, more readable.
dumper0 busy : 1+23:13:35 ( 99.99%)
taper busy : 1+23:13:36 ( 99.99%)
0 dumpers busy : 0:00:15 ( 0.01%) runq: 0:00:15 (100.00%)
1 dumper busy : 1+23:13:35 ( 99.99%) runq: 1+23:13:35 (100.00%)
Hope this helps make these reports a little more readable.
November 16th, 2008, 06:15 PM
I stand corrected on item #1. It appears that amstatus has nothing to do with the renaming. When amdump completes it renames the amdump file to amdump.1 and increments the suffix on all amdump.# files in the directory. It also renames log to log.timestamp.0 This creates the problem for amreport.
If you copy the log.timestamp.0 file to log and run amreport it works but most of the other utilities will now fail thinking amdump so you have to delete log.
November 17th, 2008, 03:11 AM
Don't copy the log files, just run: amreport <CONF> -l log.timestamp.0