[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference csc32::consolemanager

Title:POLYCENTER Console Manager
Notice:Kits, Scans, Docs on CSC32:: as PCM$KITS:,PCM$DOCS:, PCM$SCANS:
Moderator:CSC32::BUTTERWORTH
Created:Thu Aug 06 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1541
Total number of notes:6564

1299.0. "Archive creates files with 7001010000 as start date" by COMICS::MILLSS (Dr Who : He's Back... And Its About Time !) Tue May 14 1996 11:57

I have seen note 1115 and the reply, quoted below, which queries and explains
this phenomenon.

>       When you say /KEEP=24 and there isn't 24 hours of data the file
>    start time is the Unix epoch time. The files have recent creation dates
>    because when you archive you are pulling data from the active log and
>    placing it in another file. Once the desired data has been archived,
>    the "keeper" data is overlayed onto the existing logfiles and the
>    logfiles is then truncated.

I also have a customer with this problem. I have explained the above to him and
he accepts the explanation. However, he claims that it worked perfectly with
V1.5 (he's running V1.6 ECO 2 since last week) so wants to know what changed and
why !?!?!

He does a CONSOLE ARCHIVE ALL/BEFORE=yesterdays_date/NOCONFIRM every day and
sometimes gets this problem and sometimes doesn't.

The last question is how do we get it to work properly when archiving everyday
as the customer wants to do (and has been doing for some time) ?

Thanks for any help.

Simon R. Mills
South UK CSC
T.RTitleUserPersonal
Name		DateLines
1299.1CSC32::BUTTERWORTHGun Control is a steady hand.Tue May 14 1996 15:505
    I don't see a problem statement here. Whats wrong with the way it
    works? What problem does it cause for your customer?
    
    Regards,
       Dan
1299.2Oops, sorry ! The problem is...COMICS::MILLSSDr Who : He's Back... And Its About Time !Wed May 15 1996 06:1015
Sorry, Dan, I got so carried away with explaining the circumstances I forgot the
little detail of the actual problem statement !

The customer has procedures that automatically copy the files elsewhere for
security reasons and these procedures break if the file name has this odd date
in it.

I accept the reasoning behind why an arbitrary date had to be chosen but why
couldn't it just be the date of the first event that was logged ? I'm not trying
to be awkward I just want to understand. If I don't understand then I can't make
the customer understand. ;-)

Thanks.

Simon.
1299.3CSC32::BUTTERWORTHGun Control is a steady hand.Wed May 15 1996 15:0548
    Simon,
      I really don't know the philosophy behind the decision as I didn't
    design it. At this point that is the way it works and it will more than
    likely change in the not too distant future. What I have proposed is to
    use the best features of the PCM logging methodology with the best
    features of VCS logging methodology. In a nutshell that is:
    
    1. Maintain the 3 files per system, i.e., nodename.TIMES, .LOG and
       .EVENTS
    
    2. Every day at 0 hours military time, close the now previous days
       logfiles and open a new set for the current day.
    
    3. Modify the logfile names to include the date in the filename, i.e.,
       the files would be named 
    
       nodename_yyyy_mmm_dd.LOG, .TIMES, .EVENTS
    
    I feel this would make logfile management much easier. The archive
    process is as simple as copying a file to off-line or even near-line
    storage. This method would also allow archival while users/operators
    are connected and doing their work: No more service disruption or
    com files needed to do DIALOG UNLOCK commands before an archive can be
    performed. There is one other major problem with the current method.
    Since a system must be in a quiescent point before an archive can be
    done this means that PCM *is not* reading data from the system that is
    being archived. Let's say that logfiles are large and it will take
    several minutes to archive them. During this time, the system being
    archive could crash or develop some othjer problem and we wouldn't
    know about it until the archive has completed!!! The biggest objection to 
    this is:
    
    What do you do if the current days logfiles have filled the disk? Quite
    frankly, with current disk technology, storage capcities and low
    pricing this is no longer an issue. It has been *years* since I have ever 
    had a support call for that problem. In the pre-SCSI era of Digital
    when all we had were RD54's it was a problem (unless your customer
    could afford the disk controllers and the RA disks to go with them).
    I also this a minor problem compared to some of the issues mentioned
    previously.
    
    I would suggest to you customer that they not use the file-name of the
    archive file but rather it's creation date-time to make the decision to
    move the files.
    
    
    Regs,
      Dan