| 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 |
Upgrade of 2.4 with SFCP to 3.0 on a stand-alone VMS 5.5-1 system with MR 3.2-1
The upgrade failed 2 times exactly at the same spot when the installation
hung the whole system and rebooting was required.
The installation finished the linking of images such as OA$MAIN, FileCab
server images etc. and as it moved to the next phase of opening the formlibs
to add records into several CM databses when the problem struck. It was then
invoking the script EPROFIL.CA1 for this task when the system hung.
The last upgrade was invoked with debug and trace enabled; and following was
the last portion of logging:
========================================================================
Linking the OA$MAIN image
Linking the Background Formatter
Linking the TM Server
Linking the OA$SUBMIT image
Linking the MAILCOUNT image
Linking the File Cabinet Server images
Linking the RSD housekeeping procedure
Linking the Impersonation Services images
%A1-I-A1LINKED, Finished linking images
%OA-I-LASTLINE, "ALL-IN-1 running -- removing form libraries & TXL"
SYSTEM finished using ALL-IN-1 at 10-Oct-1992 23:25
%DELETE-I-FILDEL, HBA01V$DUA0:[SYS0.SYSUPD.A1030]A1$LIBS.CA1;1 deleted (2 blocks
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$SDC.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$SITELOG.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$FORM$LIBS.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$APP.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$MAF.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$AUTH$LOCATIONS.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$AUTH$USERS.DAT;1 created
%FDL-I-CREATED, HBA01V$DUA0:[SYS0.SYSUPD.A1030]CM$SITEHIST.DAT;1 created
$ ALLIN1/NOINIT/LANGUAGE=BRITISH/OVERRIDE=SHUTDOWN
get oa$dcl="OPEN /APPEND /SHARE DATAFILE DFILE"
display "ALL-IN-1 running -- opening form libraries"
OA$FLO_OPEN_LIB OA$LIB:MEMRES
OA$FLO_OPEN_LIB OA$LIB:OAFORM
OA$FLO_OPEN_LIB OA$LIB:MANAGER
OA$FLO_OPEN_LIB OA$LIB:OACBIFORMS
OA$FLO_OPEN_LIB OA$LIB:ADMIN
OA$FLO_OPEN_LIB OA$LIB:CM
DO oa$lib:CM_POST_FILL_APP
DO oa$lib:CM_POST_FILL_MAF
DO oa$lib:CM_POST_CONVERT_LANGUAGES
DO oa$lib:CM_POST_FILL_AUTH_USERS_V24
DO oa$lib:CM_POST_FILL_AUTH_USERS
DO oa$lib:CM_POST_FILL_AUTH_LOC_LLV
DO oa$lib:CM_POST_FILL_APP_RESERVED
DO oa$lib:CM_POST_FILL_AUTH_LOC_SHARE
DO oa$lib:CM_POST_FILL_SDC_LOC_LLV
DO oa$lib:CM_POST_CONVERT_FORM_LIBS
DO oa$lib:CM_POST_FILL_FORM_LIBS_LLV
DO oa$lib:CM_POST_FILL_FORM_LIBS_SHARE
DO oa$lib:CM_CART_POST_FILL_RUNS
display "ALL-IN-1 running -- updating A1CONFIG data file"
DO OA$LIB:A1CONFIG_BASE_PREPOP
DO OA$LIB:A1CONFIG_LANGUAGE_PREPOP
DO OA$LIB:DATE_FORMAT
GET OA$DCL="CLOSE DATAFILE"
display "ALL-IN-1 running -- data file creation complete"
%A1-I-RNEPROF, Running command procedure EPROFIL.CA1
%OA-I-LASTLINE, "ALL-IN-1 running -- opening form libraries"<CR>
<ESC>[2J<ESC>[10;10H<ESC>[1m<ESC>#3 <ESC>[0m
<ESC>[11;10H<ESC>[1m<ESC>#4 <ESC>[0m
========================================================================
I was told system was hanging within 1-2 minutes of the display msg:
"ALL-IN-1 running -- opening form libraries"
so was it highly likely that opening the above formlibs caused the hanging ?
Once this system went back to 2.4, I checked all the above formlibs and
they're OK: vanilla 2.4 files, no errors from ANALYZE/RMS and the contents of
MEMRES, OAFORM looked OK. This version, 2.4 has been running fine since the
failed upgrade.
I however noticed a couple of 'irrelevant' files in OA$LIB_SHARE:
MEMRES.OBJ;1 34 7-JUN-1988 12:04:00.53
MEMRES_OLD.FLB;1 297 20-FEB-1987 02:24:20.71
MEMRES_OLD.FLC;1 179 26-AUG-1988 13:07:59.54
which seemed to indicate they're 2.3 formlibs (?); also, the customer had no
idea on the origin/nature of the file MEMRES.OBJ. I did ANALYZE/RMS on the
latter but got no error.
Their CART run gave 8 pages of elements with status A and only one element
SFCM had status B and C, from which the customer took no action.
Any ideas on what happened?
Hong
CSC Sydney
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1601.1 | First the easy question, then some guesses! | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Tue Oct 13 1992 11:55 | 30 |
MEMRES.OBJ was an object version of the MEMRES form library that we
used to create (With FMS/OBJ) and link into the image as a performance
improver before we invented .FLCs. MEMRES == MEMory RESident - get it!!
In V2.3, or possibly V2.2, we stopped doing that, and MEMRES just
became another form library like all the others.
So I think you can blow away the MEMRES.OBJ and the MEMRES_OLD files,
although I don't seriously think it will make any difference to this
problem.
You can probably tell by the eay I answered the easy question first
that I don't have any ideas what could be going wrong.
During the installation, the code redefines OA$LIB to be a search list
to find the form libraries in the kit working directory (called
VMI$KWD; the [.A1030] subdirectory under SYS$UPDATE created by VMSINSTAL
during the installation) so it should be finding the new libraries
rather than anything that's already on the system.
I suppose it's possible that one of the form libraries is corrupted on
their kit? You'd need to pull them out of the savesets and do something
like FMS/DIR on them to give you a clue. The .FLBs are in the language
savesets .F and .J.
What I'd try after that is to hack the kit to add an extra line to the
command file generated in KIUPDATE.COM so that TRACE was turned on
before the .FLBs were opened. I don't know if that's an option in this
case...
Graham
| |||||
| 1601.2 | any more suspects ? | GIDDAY::LEH | Tue Oct 13 1992 13:50 | 23 | |
Graham Thanks for a couple of hints. Incidentally, there's some suspicion on the kit this customer was using since 2 weeks ago, their corporate system also failed its upgrade although at different stage, I believe it's before the linking of main images. However, this weekend saw 2 upgrades of their 2 provincial offices and one went through OK, the other was this very problem. Our CSC also used this kit for a fresh installation, not upgrade, and it worked OK. I did have a quick look at some of the savesets in the involved kit and although the creation date of those savesets was later than the SSB kit, BACKUP/LIST showed identical build date and file contents. I recalled checking savesets A1030.A, A1030.B, A1DUS_GB030.A and A1CUS030.A (.B); it seems reasonable from your suggestion to check savesets .F and .J especially in this case there's strong indication on access problems to those formlibs. Will also ask the customer to remove MEMRES.OBJ in the next upgrade. Stay tuned Hong | |||||
| 1601.3 | it may seem a wild guess but... | AIMTEC::WICKS_A | XYLANA: Hound of the Backslashers | Tue Oct 13 1992 16:07 | 7 |
Hong,
which disk controller are you using?
Regards,
Andrew.D.Wicks
| |||||
| 1601.4 | more wild guesses, please | GIDDAY::LEH | Wed Oct 14 1992 09:18 | 20 | |
Andrew
Thanks for your prolific interest...
The customer is using Micro-Tech SCSI disk XSI QTD30 configured as
RA90. They had these types of disks some 18 months ago and no known
problem. In fact, I did do ANALYZE/ERROR on the whole period of upgrade
and found nothing but several system startup events.
Today, I pulled out MEMRES.FLB and OAFORM.FLB from saveset A1LUS030.F
and checked them, which gave identical number of forms when compared
with the SSB kit. Also, looking back to the list of files in VMI$KWD
just prior to the hanging did show all the necessary formlibs,including
the above two.
Any more 'wild' guesses are also welcome
Thanks
Hong
| |||||
| 1601.5 | Paging Iain | AIMTEC::WICKS_A | XYLANA: Hound of the Backslashers | Wed Oct 14 1992 16:50 | 13 |
Hong,
Actually it isn't necessarily a wild guess - we are seeing far too many
ALL-IN-1 v3.0 installs hanging at exactly the point yours does when
using UDA50 disk controllers and some third-party disk controllers.
I have forwarded your original note to my resident guru on everything
(Iain Voller) in the hope that he may explain all there is to explain
in gory detail...
Regards,
Andrew.D.Wicks
| |||||
| 1601.6 | Oz calling Iain, Oz calling Iain... | GIDDAY::LEH | Thu Oct 15 1992 09:33 | 9 | |
Andrew
Are those disk controllers consistently causing the hanging?
Any alternative to their exclusion from instals, if feasible ?
Do you have such a list of controllers ?
Do you or Iain want a trip to Oz ?
Hong
| |||||
| 1601.8 | I agree with Andrew ... | AIMTEC::VOLLER_I | Gordon (T) Gopher for President | Thu Oct 15 1992 15:51 | 15 |
Hong,
Sorry I took so long to reply to this, but ...
I think that you are seeing a problem caused by the attempt by ALL-IN-1
to read information from a controller that doesn't support all possible
transfer requests. I have investigated this problem (or similar) in
detail and have advised the relevant people of a possible solution.
I will mail you with more info and will update this note when a formal
fix is available.
Regards,
Iain.
| |||||