| 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 |
ALL-IN-1 3.0, VMS 5.5-1 Customer has a customized OA application which he would like to send to a machine which has a previous version of this customized OA application already on it. When he tries the restore, it fails for all elements with an error relating to the AS application (!) which they also have, rather than the OA application. An example error report is :- ----------------------------------------------------------------------------- Restore Application Report Application : OA Page : 28 User: MANAGER Date : 22-feb-1993 04:20pm ----------------------------------------------------------------------------- Site Element Details Name : MAIN Type : FRM Area : BRITISH ----------------------------------------------------------------------------- Conflict Summary An element created with the same key exists in the base area Restore site element overwrites current site element No conflicts with elements of another type exist A VMS file with the same name exists in the SITE BRITISH area ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Process Element results Report mode was chosen, no modifications will be made to the live system Failed to save a copy of the site element to ICI_OAA$DISK:[AS.SITE.DEV_REC_BRIT ISH.FRM]MAIN.FRM Error: Form not accesible in OA$SITE_DEV_BRITISH:DEVELOP.FLB ----------------------------------------------------------------------------- Note: Elements of the same name exist in the following area BRITISH (Base Area) --- ----------------------------------------------------------------------------- Restore Application Report Application : OA Page : 28 User: MANAGER Date : 22-feb-1993 04:20pm ----------------------------------------------------------------------------- Site Element Details Name : ICIOAMOVPEND Type : DO Area : BRITISH ----------------------------------------------------------------------------- Conflict Summary No base element exists Restore site element overwrites current site element No conflicts with elements of another type exist A VMS file with the same name exists in the SITE BRITISH area ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Process Element results Report mode was chosen, no modifications will be made to the live system Failed to save a copy of the site element to ICI_OAA$DISK:[AS.SITE.DEV_REC_BRIT ISH.DO]ICIOAMOVPEND.SCP Error: File OA$SITE_DEV_BRITISH:ICIOAMOVPEND.SCP not accessible ----------------------------------------------------------------------------- Note: Elements of the same name exist in the following areas SHARE (Site Area) This apparently happens for new elements as well as elements that already exist from the previous customized OA application. In cm$sitelog the develop and live location are correct. Is there any known problem restoring an application that has previously been restored ? They do not have the patch installed. I'm afraid my restoring of applications is not too good so any ideas ?! Thanks in advance, Clive
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 2342.1 | The logical? | AIMTEC::WICKS_A | I dreamt I found a working printer! | Mon Mar 01 1993 17:00 | 27 |
Clive,
OK let's take wild guesses at them in reverse order!
ICIOAMOVPEND is attempting to restore itself to the BRITISH area
when it already exists in the SHARE area - I wouldn't have thought
this was the intended behaviour
Both elements appear to be having an error accessing
OA$SITE_DEV_BRITISH: is the protection etc ok? what does the logical
look like?
note that the report
had previously said that a file of that name already exists there
(from a previous attempt?)
OK now back To MAIN - note that the first conflict is the MAIN also
exists in the BASE area - well you'd expect that since MAIN is a base
element. You also get that message about the file already existing on
disk but it can't access the OA$SITE_DEV_BRITISH.
I'd have a look to see where the OA$SITE_DEV_BRITISH logical points.
Regards,
Andrew.D.Wicks
| |||||
| 2342.2 | COMICS::BARHAM | Norbert: | Tue Mar 02 1993 12:39 | 27 | |
Thanks Andy,
All looks fine on the logical and protection front. ICIOAMOVPEND was a
red herring actually since they had previously restored it to the
SHARE area and later decided it belonged in the BRITISH area.
The history of the problem is :-
Customer had 19 new customized OA elements restored on the receiving
machine.
At a later date, the application was updated by restoring 23 elements
including the 19 that were previously restored. Only the four new
elements were successfully restored and the other 19 failed to restore
with errors relating to the AS application, similar to .0.
They tried the restore again and this time all 23 elements failed since
they all now existed on the receiving system.
In desperation, they deleted all 23 elements on the receiving machine
and restored again. This time they all restored successfully.
In other words, it always appears to fail for them when the element
already exists from a previous version of the restored application.
Any ideas ?
Thanks,
Clive
| |||||
| 2342.3 | Almost 10 mins to enter just this! | AIMTEC::WICKS_A | I dreamt I found a working printer! | Tue Mar 02 1993 20:38 | 16 |
Clive,
I'll keep it brief since the network appears completely up the spout
today and it takes almost 5 mins to do next unseen.
When they do the second restore what options are they using i.e UPDATE
mode (or FULL) it should be the former and APPLICATION (or RECEIVE)
it should be the former.
On the first RESTORE - the successful one they should have used FULL
and APPLICATION.
Regards,
Andrew.D.Wicks
| |||||
| 2342.4 | Check values in CM$APP and CM$MAF for SITEROOTCODE | UTES09::EIJS | Simon Eijs @Utrecht; 838-2558 | Tue Mar 16 1993 10:52 | 23 |
Hi Norbert,
Maybe a bit late, but maybe you can check the following:
The SITEROOTCODE in CM$APP, does it have the same value as the
SITEROOTCODE in CM$MAF for the Application Areas SHARE and BRITISH?
The procedure CM_RESTORE_PROCESS_ELEMENTS.SCP builds a symbol called
#CM_RESTORE_TOP_DIR_LB which serves as the Siterootcode. The value is
taken from CM$APP in case the application already exists, else you're
asked for it during the restore.
The logicals OA$SITE_DEV_*: are defined according to the values in
CM$MAF, so this might show that CM$MAF contains different values for
the SITEROOTCODE.
The whole issue of Application Areas devided over different devices and
directories has been addressed, but for V3.0 this is a restriction.
HTH,
Simon
| |||||
| 2342.5 | COMICS::BARHAM | Norbert: | Tue Mar 30 1993 11:35 | 5 | |
Not too late at all but not the answer unfortunately.
Soldiering on.
Clive
| |||||