IIRC, that is a configuration record that is written when the monitor is
initialized. It was required by MICS. ESAWRITE has the ability to start
each raw data file with one of these records. If you don't have
ESAWRITE, you can find a configuration record in any file, retain a copy
of it and include it in the files processed by the program. 

Regards, 
Richard Schuh 

 

> -----Original Message-----
> From: The IBM z/VM Operating System 
> [mailto:[email protected]] On Behalf Of Leland Lucius
> Sent: Thursday, January 15, 2009 9:44 AM
> To: [email protected]
> Subject: Re: Sorting monitor data?
> 
> Mike Walter wrote:
> > Forewarning: I have no knowledge of LINMON package details.  There 
> > may/must be better ways of doing this, but this may help.
> > 
> > Isn't there a sufficient date/timestamp already on each generated 
> > record that could be used to sort them before CP3KVMXT processing?
> >  
> Yepper, there's a date field and I've tried sorting by that, 
> but CP3KVMXT specifically look for a record beginning with 
> '000087'x as the first record.  Of course, I just had to 
> comment out that check and give it a try, but it causes a 
> specification exception.  :-)
> 
> > If not, would it be possible in your case to modify the 
> LINMON package 
> > or the MSUX EXEC (exit) to write a prefix at the start of 
> each record 
> > before it is written to disk.  That prefix could be the 
> > yyyymmddhhmmssnnnnnnnnnn where yymmddhhmmss is the time that this 
> > process "prefix" began, and the 'nnn's are a sequence 
> number (easily generated with a PIPEs "SPECS"
> > stage).  When you are ready to run them into CP3KVMXT, 
> first sort on 
> > that prefix, and stripping it before re-writing them all as 
> one large 
> > file. But that seems to defeat the purpose of writing the file in 
> > smaller pieces, no?
> Unfortunately, the files in question have already been 
> created.  I can fix the out-of-order issue for future 
> collections, but I was hoping to be able to feed CP3KVMXT a 
> particularly nasty day we had recently.
> 
> Leland
> 

Reply via email to