Conference iosg::all-in-1

    <<<< %A1DUS_GB-E-BADDAT, Data file OA$DATA_SHARE:SM_ACCOUNT_TYPES.DAT
    <<<< -A1DUS_GB-E-BADDAT, record size is incorrect: 1610
    <<<< -A1DUS_GB-E-BADDAT, ALL-IN-1 V3.1 record size for this file should
         be 1558.
    
    Interesting, I wonder what they did - The file should have a record
    size of 1665 after the upgrade, so they haven't got a V3.2 file
    already. The only other possibility is that they have customised the
    forms (SMTEMPLATE*.FRM in OA$LIB:MANAGER.FLB) defining the file.
    
    <<<< I am confused, as my record size is 1558, but the record length is
    <<<< 1610 on the customers other system which completed this part of
    <<<< the upgrade without a problem.
    
    1558 is correct for for V3.1. Are you sure that there isn't more than
    one copy of the file in some other part of the OA$DATA search list? Or
    perhaps they've reapplied a customisation after the upgrade.
    
    <<<< My 3.2 system has a record size of 1665 for this file. (just to
    <<<< different I guess).
    
    No, that's the right size for a V3.2 file.
    
    <<<< Also do we know why the procedure tried to fix it, (and was
    <<<< adamant that it was going to try), and then promptly failed ?
    
    Er, what makes you think that the procedure tried to fix it? Look at
    the messages again:
    
    	%A1DUS_GB-E-BADDAT, Data file OA$DATA_SHARE:SM_ACCOUNT_TYPES.DAT
    	-A1DUS_GB-E-BADDAT, record size is incorrect: 1610
	-A1DUS_GB-E-BADDAT, ALL-IN-1 V3.1 record size for this file should be 1558.
	%A1DUS_GB-E-BADDAT, The reported problems with this data file will
	-A1DUS_GB-E-BADDAT, cause file conversions to fail.  You must return the
	-A1DUS_GB-E-BADDAT, data file to its correct format before continuing.
    
	* Do you want to correct the problems then repeat the checks [YES]?
	* Have you completed your corrections [YES]?
    
    I seem to be asking *YOU* to go and fix it, and then offering to check
    that you did the right thing. There's no way that the installation can
    work out how to fix the problem, since it doesn't know how you've
    changed the file. There's detailed instructions in the Installation
    Guide about how to cope with a customised data file.
    
    Graham
    
    PS <<<< upgrading a Node from version 3.1 to 3.2 of ALLIN1...
    
    I think you must mean ALL-IN-1 :-)

    OK, so it has been a long day.  All points taken on board, graciously.
    
    I will double check a few things with the customer, and bring up the
    question of customization.  Lets see what they have to say.
    
    about ALL-IN-1 that is.
    
    Maybe thats the problem, I am looking at a completely different
    application altogether. :-)
    
    Ivan.

    I have contacted the customer again, and they say that there has been
    no customisation done to this file.  There are no other versions within
    the directory tree and there are no .FDL files around for
    SM_ACCOUNT_TYPES.DAT.
    
    I have asked them to ANAL/RMS/FDL the .DAT file update the RECORD field
    to 1558 and then CONVERT/FDL the .DAT file.  This worked without
    problems.  (They have kept a copyy of the old file).  They will now
    retry the upgrade.
    
    I will post any developments.
    Ivan.

    <<<< I have asked them to ANAL/RMS/FDL the .DAT file update the RECORD
    <<<< field to 1558 and then CONVERT/FDL the .DAT file.  This worked
    <<<< without problems.
    
    Er, when you say there weren't any problems, what did it do to the data
    in the records. Have they gone to SM DTC and read all the templates to
    see if they're OK?
    
    Personally, I'd be inclined to print out all the existing templates,
    trash the file and recreate them. Especially if they don't have many.
    
    I can't see that the field by field conversion into the new record
    format during the upgrade being too successful unless they find out
    what was wrong with the old file first.
    
    Get them to call up the form SMTEMPLATE before the upgrade, and do
    CTRL/N to see what .FLB it's coming from. Then do CTRL/V and carefully
    look for the last field (DEC$TEXT2??) and see what the 'Len' + 'Posn'
    numbers add up to, which should be the same as the record length of the
    file.
    
    <<<< They have kept a copyy of the old file
    
    Wise move.... I'd be keeping the old form library (whichever one is
    mapping this file!) so that I could *read* the old file too.
    
    <<<< They will now retry the upgrade.
    
    Tell them not to bother submitting a bug if it fails :-)