Conference csc32::consolemanager

Dennis,

  Having connections to the managed systems SHOULD NOT prevent an
  automatic archive happening.

  Having said that, your customer should realize that automatic
  archives are really a failsafe mechanism, he/she should really be 
  doing periodic manual archives.

  Now, as for the files not appearing in the archive directory,
  check the protections on the directories for the archive and log
  files.

  If you think V1.6 will fix this, by all means let your customer
  have a copy, this way if he still has a problem, we can fix it
  before we ship V1.6 to SSB.

Cheers,
Phil

re: .1

Hi Philip,

	Passed your information on to the customer and I will also be sending 
him the T1.6 kit and documentation.  However, he insists that when his 
operators have the consoles locked with a CONNECT that archiving will not 
proceed and posts a message to that affect to the C3's message board.  I 
passed this by John B. here and he seems to think that this is the way things 
work.  Can you add anything to this?

Thanks,

Dennis

Dennis,
       it is correct that if there is a user connected to the particular system
we do not archive. Bear in mind that when we archive we tear the log files into
little pieces. If a user is connected we would be "pulling the Carpet" from
under them, so we check and return if there is a person connected.

Cheers simon....

    Simon,
    
    	I called Dennis's cutomer back....he said that if he operator makes
    a connection (and not doing anything) the archive fails.  He said that
    basically what he wants to see happen is like an operator or accounting
    log file.  That just because you're connected to system, you should
    still be able to archive.  He doesn't (per se) have the log file
    open....
    
    thanks,
    
    Kathi

    >    Simon,
    >I called Dennis's cutomer back....he said that if he operator
    >makes a connection (and not doing anything) the archive fails.  
    
    It doesn't matter if he's doing anything or not. He's still connected
    via CONSOLE CONNECT. If we attempt an ARCHIVE, manual or automatic, the
    ARCHIVE will not take place. Period!
    
    >He said that basically what he wants to see happen is like an operator or
    >accounting log file.  That just because you're connected to system, you 
    >should still be able to archive.  He doesn't (per se) have the log file
    >open....
    
    The problem here is that how do you know what the user is doing? Let's
    say we change the code so that any connected user is locked out while
    doing an archive. Let's say that a user is trying to *boot* the system
    and an automatic archive is kicked off and the logfile for the system
    in question is very large and it will take *several minutes* to archive
    the system - guess what? - the boot will stall as PCM must also stop
    reading from the console line while an archive is in progress. The
    operator may not have even been able to enter the boot command if we
    locked the keyboard at the right moment. What if they logged in and
    tried to run a backup and we locked the keyboard as they were trying to
    issue the command or command file? If the next argument is - okay, so what
    happens if a system crashes and we stall writing the crash dump because an
    archive was in progress?? Indeed we have an issue and so did VCS! If
    the VCS logging disk was full and the only logfile left was for the current
    day, we would eventually hang if the disk went down to 0 free blocks.
    
    With the current design of the logfiles, I believe the code is doing
    the correct thing by blowing off the archive if someone is connected.
    
    Regs,
      Dan

Kathi,
      if he is connected he does have the log file open by the fact
that he has a connection open to the console. When we archive we have
to have exclusive access to the log event and times files as we
actually create new ones in place of the original files. Pointers
in the files are all changed and the effect is to caused the 
connected process to have invalid context ( we know this as we did 
not do this in an early release and the connect and monitor 
interfaces crashed regularly when archiving).

Cheers Simon...

    <<< Note 709.5 by CSC32::BUTTERWORTH "Gun Control is a steady hand." >>>

>    The problem here is that how do you know what the user is doing? Let's
>    say we change the code so that any connected user is locked out while
>    doing an archive. Let's say that a user is trying to *boot* the system
>    and an automatic archive is kicked off and the logfile for the system
>    in question is very large and it will take *several minutes* to archive
>    the system - guess what? - the boot will stall as PCM must also stop
>    reading from the console line while an archive is in progress. The
>    operator may not have even been able to enter the boot command if we
>    locked the keyboard at the right moment. What if they logged in and
>    tried to run a backup and we locked the keyboard as they were trying to
>    issue the command or command file? If the next argument is - okay, so what
>    happens if a system crashes and we stall writing the crash dump because an
>    archive was in progress?? Indeed we have an issue and so did VCS! If
>    the VCS logging disk was full and the only logfile left was for the current
>    day, we would eventually hang if the disk went down to 0 free blocks.
    
Dan,

	Are you stating that if I make a batch job that unlocks the connected
terminal that a system connected via PCM output is lost during archiving???


				Thanks
				Bill

    >Dan,
    
    >        Are you stating that if I make a batch job that unlocks the
    >connected terminal that a system connected via PCM output is lost during
    >archiving???
    
    No, not at all! What happens is we will stop reading from the console
    line so it will be Xoff'd. No data will be lost. 
    
    REgards,
       Dan

Thanks, I was hoping that I misunderstood....

	Bill