Conference iosg::all-in-1_v30

2889.0. "Startup looping on housekeeping procedures" by MEOC02::BEESTONL (Liz Beeston) Mon Jun 21 1993 10:42

   Hi... 
   I have a problem at a customer site starting a IOS V3.0 following an 
   SDA.

   The original problem was that following a reboot IOS did not start
   properly because the OA$MTI_QUEUE logical name was set to point to a non
   existing batch queue. When the A1V30START got to starting the Mail batch
   jobs the whole A1V30START process completed unsuccessfully.

   When we were trying to start the FC server process manually we got
   'sharebales images must be installed to run privilege image error' so I
   decided to run the whole A1V30START procedure again. The ADM SDA was
   done.

   We have modified the OA$MTI_QUEUE field in A1CONFIG to point to an
   existing batch queue but now when we are running the startup procedure we
   get to the 'Checking housekeeping procedures to see if they need
   requeing' message and thats as far as we get. The message stays on 
   the screen and the executing process is using as much as 90% of 
   available CPU (4300) and is doing lots of page faults also. 

   The process is running the OA$MAIN.EXE executable and seems to have the
   SM$BATCH$CLEANUP.SCP file open at this time. I have let this run
   on for about 4 minutes of CPU time.

   Does anyone have any ideas on what the problem could be with my startup
   procedure /config file and why we looping.

   Any ideas on how to fix this problem. I don't want to have to go to a
    reboot and at this stage I am not confident that a reboot will actually
    solve the problem

   Regards... Liz

    <<Not so important issue>> The value we had assigned to OA$MTI_QUEUE in
    the original A1CONFIG file was SYS$BATCH. While this is not a physical
    queue on the system there is a SYS$BATCH logical name that points to an
    execution queue for each node of the cluster. Why doesn't ALL-IN-1
    translate the SYS$BATCH the logical name to find execution queue for 
    the Sender and Fetcher?   
    
               

    A quick hack to get round this might be to replace the HK schedule file
    (OA$DATA_SHARE:OA$SM_UTIL_SCHEDULE.DAT) with an empty version, so that
    the tidyup job has nothing to do. Of course you'll have to requeue all
    your HK jobs again afterwards, but it might be worth doing that to
    change the queue name. There's an FDL for the file in OA$LIB.
    
    If it still loops after that, then there must be some problem with
    getting the jobs out of the system queue file. Could JBCSYSQUEU.DAT (or
    it's V5.5 on version) be corrupted? Can you do a SHO ENTRY or SHO QUEU
    from DCL?
    
    Graham

    
    Thanks. I will try making a new schedule file in the morning.
    
    Yes, this is VMS V5.5-2 and the system manager did suggest that over the
    weekend they did create a new queue manager file as there was some
    problem with the old one. Will this cause any problems? (This is the
    problem the startup procedures are attemtping to address I expect)
    
    I'm not on site at the moment but from memory the housekeeping jobs in
    the batch queues all look OK and are scheduled. These jobs are not 
    scheduled in SYS$BATCH, they are in are in a node specific execution 
    queue. It is the mail batch queue that we have modified.
    
    This is a new IOS implementation to provide File Cabinets to TeamLinks
    users so the fact that their IOS mail hasn't been working for the last
    three weeks has escaped attention.
    
    I will let you know the results.... Liz
    

    Yes!! The new schedule file has solved the problem and startup is all
    OK.. Thanks

Someone correct me if I'm wrong but this is documented in the MUPA release 
notes, appendix D, as still a known problem.

Something to do with a logical name being the same as the physical name for a 
queue, causes problem with the QUI$QUEUE DSAB.

/Mario