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

Conference iosg::all-in-1_v30

Title:*OLD* ALL-IN-1 (tm) Support Conference
Notice:Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:IOSG::PYE
Created:Thu Jan 30 1992
Last Modified:Tue Jan 23 1996
Last Successful Update:Fri Jun 06 1997
Number of topics:4343
Total number of notes:18308

1097.0. "Invalid A1CONFIG.DAT - how to recover ??" by JOCKEY::63953::John-Boy (Glad that the Devil is Red !!) Wed Jul 22 1992 11:12

Hi,

A customer is experiencing some very strange behaviour and I am unable to
explain/fix it so can anyone help me with this.

They have upgraded a V2.3 system to V3.0.  ALL-IN-1 seemed to have upgraded OK. 
A change was then made via the A1CONFIG form, for the BRITISH record, so that
the site and file locations pointed to different disks.  No changes were made
to the A1BASE record but I wouldn't have thought this would cause a problem.

After this A1CONFIG change the machine was rebooted and ALL-IN-1 didn't report
any errors on  startup.  However, when a user tries to enter ALL-IN-1, it
thinks about it then reports the following error message before returning to
the DCL prompt;

    Form !AS is not in the library.

I presume that this is because the relevant form libraries have not been opened
so I thought I would go into ALLIN1/NOINIT to manually do this.  However when
you do this, before receiving the CMD> prompt, you receive a `Directory not
found (-E-NODBFORM) error on  OA$SITE_LIB_LLV:SITEMEMRES'.  Checking this
logical shows that it's OK and is in fact pointing to the correct place.  

I ran the A1V30START with SET VERIFY on and lots of errors were reported,
seemingly due to wrongly defined logicals.  I checked every OA$.... logical
and manually reset the ones that  were pointing at incorrect locations. 
However, any attempt to run ALLIN1 still results in the same errors as above
and the error regarding directory not found for SITEMEMRES seems to preclude
any following commands issued from the CMD> prompt from having any affect. 
Where does ALL-IN-1 think it's picking up a value for the translation of this
logical as I can't seem to override it ??

It seems to be a catch 22 position and I think the fix is to modify
A1CONFIG.DAT back to what it was. Unfortunately, I cannot do this via form
A1CONFIG as I cannot get into ALLIN1 and, even if I knew the correct field
names, I don't imagine issuing a

    CMD> WRITE CHANGE A1CONFIG ........

would have any effect due to reasons given above.

So can anyone tell me how you recover from a corrupt A1CONFIG file.

Also, if you can point out where we went wrong, I'll try to avoid doing it in
the future!!

Thanks,
John Marshall

T.RTitleUserPersonal
Name
DateLines
1097.1DOn't press that button again???IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeWed Jul 22 1992 17:2040
    The simple answer to your question is to create another version of
    A1CONFIG on another machine, but I don't imagine you'd consider that to
    be very helpful :-) :-) It is however the best strategy, so if you can
    get to another system do so.
    
    I don't suppose you have an old copy from a backup tape prior to the
    upgrade? The V3.0 upgrade won't have changed much, and the old version
    might be good enough to get the system to start up.
    
    So your only other options would seem to be either to edit A1CONFIG.DAT
    with TPU and then turn it back into an indexed file with a suitable FDL
    or to carry on as you suggest and fix up the logicals. Make sure the
    logicals are defined in the right logical table (SYSTEM or
    OA$BRITISH_TABLE) and that they are all defined /EXEC. You must have
    SYSNAM to do this, and if you don't have it, you don't get an error,
    the logicals just get defined in the wrong mode!!!
    
    Are the logicals (when correctly defined) pointing to real directories,
    and have you moved the files across to the new directories?
    
    Try ALLIN1/NOINIT/NOCUSTOM so it doesn't go to the site areas...
    
    Make sure that all the images have the right owners and protections and
    are installed with the correct privileges. Also, if it's a
    multi-lingual system you have synchronous versions of OA$MAIN.EXE and
    OA$LLV_BRITISH.EXE
    
    How to avoid getting in this mess: Make sure you *ALWAYS* make a copy
    of A1CONFIG before changing it!
    
    Other than that, I can't work out what you did wrong. Perhaps once you
    get going again, you could tell us the exact steps you took and we can
    spot your fatal error :-)
    
    Cheers,
    
    Graham
    
    PS I don't know what you are writing your notes with, but they were all
    overflowing the lines, so I had to edit the note before I could read it!