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

Conference clusta::acms

Title:ACMS comments and questions
Notice:This is not an official software support channel. Kits 5.*
Moderator:CLUSTA::HALLAN
Created:Mon Feb 17 1986
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4179
Total number of notes:15091

4132.0. "Perm_cps, shutting down terminals??" by KERNEL::PULLEY (Come! while living waters flow) Fri Mar 21 1997 10:52

    Hi,
    
    I've a customer struggling with shuyying down ACMS.
    Various things sometimes get left.
    I think I saw somewhere a suggestion that, just before shutting it
    down, to help the CP's on their way, you could change the perm_cps
    down to E.g., 0.
    On a system with perm_cps=1, I tryed this:-
    acmsgen> set perm_cps 0
    acmsgen> write active
    
    I didn't know whether to expect after a while, as I had been the only
    ACMS user but then logged out, if the CPs would go from 1 to 0.
    Should that happen?
    
    Thanks,
    Steve.
T.RTitleUserPersonal
Name		DateLines
4132.1OHMARY::HALLBill Hall - ACMS Engineering - ZKO2-2Fri Mar 21 1997 11:3030
    
    PERM_CPS is not the equivalent of setting minimum servers to 0.
    The TSC looks at PERM_CPS when the last user leaves a CP.  If
    PERM_CPS is less than the current number of existing CP's then
    it will delete the CP but I suspect (not confirmed) that it
    starts counting from CP001.  So if CP001 is now empty, and
    there are still other CP's, it won't kill CP001.  It also appears
    that TSC likes to have 1 CP around so even it PERM_CPS is set
    to 0, you'll still have 1 CP.  That's the behaviour we've seen
    when doing some other testing.  It might have something to do
    with MIN_CPIS.
    
    Back to the problem of shutting ACMS down.  The commands to shutdown
    ACMS are sent to various components and OPR waits until they return
    a status indicating success.  If you attempt to shut down an
    application and the EXC cannot cancel an outstanding task, then the
    application will never shut down.  I've seen this first hand when
    a CP was hung with an outstanding task stuck in an exchange step.
    The application refused to shut down. Once I killed the offending
    CP, then the application completed it's shutdown.
    
    I'd tell your customer to first remove the users from the system,
    by attempting to shutdown the terminal subsystem first.  If that
    doesn't work, investigate why one or more CPs does not shutdown,
    then kill the CP.  The applications and the rest of the system
    should then shutdown properly.
    
    Is this my favourite customer in Dublin?
    
    Bill
4132.2KERNEL::PULLEYCome! while living waters flowFri Mar 21 1997 12:277
    Yes, our fave customer too :-)
    I'll try them with users and terminals first.
    I think it's normally the CPs if anything that get left.
    
    Thanks,
    Steve.
4132.3ACMS::HALLBill Hall - ACMS Engineering - ZKO2-2Fri Mar 21 1997 12:3412
    
    There's always the last ditch approach to bringing ACMS down.  I'm
    sure it's documented someplace, but I've known about it for 15 years.
    
    If ACMS will not shut down after an ACMS/STOP SYSTEM/CANCEL, you find
    the ACC process and do a STOP/ID on it.  Then you use the ACMS/STOP
    SYSTEM/CANCEL command again.  ACMSOPR will tell you the system is in
    some unknown state and will then kill every process that begins with
    ACMS01.  Quick and simple!
    
    Bill