Conference iosg::all-in-1_v30

    Mario,
                                       
    Not that I understand German or even English! but it appears to be
    falling over when trying to delete the housekeeping jobbies
    
    Does the release note section 1.2 help at all I know it isn't exactly
    the same but it does appear to relate to second language update
    installations.
    
    If this is during post-install then can't you just rerun
    A1$POSTINSTALL with verify on to get more clues.
    
    Regards,
    
    Andrew.D.Wicks

Couldn't find the A1$POSTINSTAL.COM anywhere in the [ALLIN1...] tree.

Re: release notes 1.2,

I already has him check to see if there were any housekeeping procedures
off the MHP option.  There were none.  I didn't get him to check the
batch queues themselves.

Mario

    Hi Mario,
    
    from your log file excerpt I can't see what's wrong. The installation
    seemed to fail very early, too early to have reached the post
    installation phase. That's why you can't see the A1$POSTINSTALL
    procedure, because it is written (=created) by another procedure later
    during the installation.
    
    Could you send me the complete kog file? Maybe it tells a bit more.
    Did you update the German language from an earlier V3.0 level?
    
    	Stefan

Stefan,

The customer was able to get around the problem by commenting out a .COM
procedure in KITINSTAL.COM which stops housekeeping batch jobs.

They tried to run he command file manually and it ran successfully.

Who knows why it was failing while running out of VMSINSTAL.

Do you still want the log file?

Thanks,

Mario

    Mario,
    
    So it was the HK thingies? I like when I am almost right because it
    happens so infrequently... Which .COM? Any strange VMS version?
    
    Regards,
    
    Andrew.D.Wicks

The KITINSTAL.COM in the save-set A1LDE030.A.  You can also check the A1LUS030.A
which has the same piece of code in it.

In there you will find the line:

	$! STOP_HOUSE_KEEPING_BATCH_JOBS

The last piece of code in that section before the EXIT calls 
OA$LIB:SM_DELETE_FROM_QUEUE which displays the message:

"Checking housekeeping schedule to see if any procedures need deleting"

This message is the last successful message before the ACCVIO.

They commented it out since there were no housekeeping jobs in the batch
queues, and everything worked.  Who knows what will happen at the next
update?


BTW, what's an HK?

Mario

    Mario,
    
    if it's not too much trouble for you, I would still like to see the log.
    I want to be sure that it's not a generic problem in the product, which
    is shipping since last week.  8-0
    
    	Stefan

    Hello Mario,
    
    the only obvious mismatch I can see is that
    
    - in .0 you say the customer wants to update from an earlier V3 BL
    
    - in the log the customer selected option (4), which is 
    	"Upgrade of an additional existing ALL-IN-1 V2.4 language"
    
    
    	Stefan

    
    Hi,
    
    Re .0)
    
    Could the following assumption be correct:
    
    Situation:
    
    	ALL-IN-1/English V2.4	Primary language
    	ALL-IN-1/German V2.4	Secondary language
    
    After first upgrade (of English) you have:
    
    	OA$LIB_SHARE:OA$MAIN.EXE 	(V3.0)
    	SYS$SHARE:OA$LLVENGLISH.EXE	(V3.0)
    	SYS$SHARE:OA$LLVGERMAN.EXE	(V2.4)
    
    That means that OA$MAIN.EXE, when started with:
    
    	$ ALLIN1/REENTER/USER=MANAGER/LANG=GERMAN
    
    would have a mismatch between the V3.0 message symbol addresses
    (OA$MAIN) and the message text addresses (OA$LLVGERMAN). They are
    correct for English as both images are V3.0 images. That explains the
    'wrong' messages.
    
    The mix between English and German messages is because CM wasn't
    translated in V2.4. 
    
    The ACCVIO? Hard to say. To me it looks like an repeated call to a data
    file with a mismatch between actual length and form/DSAB length but
    then more messages should appear. Maybe one of the data set used wasn't
    in OA$DATA_SHARE:
    
    	OA$SM_UTIL_SCHEDULE.DAT
    	OA$SM_UTILITY_MASTER.DAT
    	PROFILE.DAT
    
    or appeared in the OA$DATA_GERMAN: directory, in which case a V3.0
    entry form could map a V2.4 data file to write info to
    (SM_GEN_UTI_SCH).
    But that's only a SWAG.
    
    Ciao,
    
    	Simon

    Hi,
    
    During a test installation I had the same problem. I restored the
    backup, upgraded a 2nd time and had the same problem again... Late in
    the evening I solved the problem.
    
    On my system there was still an old V2.4 OA$LLVGERMAN.EXE in
    SYS$SYSROOT:[SYSLIB]. The new one was in SYS$COMMON and therefore not
    used. This happens if someone links ALL-IN-1 and copies the german
    image to SYS$SHARE as it is wronly documented in the management
    guide...
    
    Stefan
    
    Is it your problem too?
    
    Stefan