T.R | Title | User | Personal Name | Date | Lines |
---|
1405.1 | FORMAT_UPGRADE.SCP | IOSG::NEWLAND | Richard Newland, IOSG, REO1-D/4A | Mon Sep 14 1992 14:50 | 11 |
| The FORMAT master file is converted by the OA$LIB:FORMAT_UPGRADE.SCP
script. It does not use OA$CNV_CONVERT because the creation of a new
FORMAT master plus conversion of the entries in the old file is more
complicated than what OA$CNV_CONVERT can do.
As FORMAT_UPGRADE references the contents of the V2.3/.4 FORMAT master file
using field names I can't see that the different field order on a /Dansk
V2.3 system will cause problems.
Richard
|
1405.2 | Yes, but what is V2FORMAT really? | COPCLU::COPSPD::GLARGAARD | Allan Glargaard, DS @DMO | Wed Sep 16 1992 10:26 | 17 |
| Re .1, Richard,
>As FORMAT_UPGRADE references the contents of the V2.3/.4 FORMAT master file
>using field names I can't see that the different field order on a /Dansk
>V2.3 system will cause problems.
>
FORMAT_UPGRADE.SCP uses FOR v2format do ... etc to copy the old data from
the file in #v2fmt = "OA$DATA_LLV:V2X_FORMAT.DAT"
So, the interesting question is:
Is the V2FORMAT form a modified version of the customers old FORMAT.FRM,
or is it supplied with the V3.0 kit?
Best regards,
Allan
|
1405.3 | Yes - Special action required! | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Wed Sep 16 1992 11:40 | 15 |
| V2FORMAT is a form in the V3.0 OAFORM library. Created 12-Mar-92.
Hence, the customer needs to take some special action to get their
Format file back to the same format (if you'll excuse the pun :-) ) as
the original one before the upgrade, or more simply save theirs and
create an empty one using the FDL.
Then after the upgrade, modify the V2FORMAT form to match theirs, or
change the FORMAT_UPGRADE.SCP to use their form instead. Reapply their
customisations to the new FORMAT form (which is a mandatory change in
the CART data file for just this reason!)
Finally rerun the FORMAT_UPGRADE script to convert their file.
Graham
|
1405.4 | V2FORMAT is supplied in kit | IOSG::NEWLAND | Richard Newland, IOSG, REO1-D/4A | Wed Sep 16 1992 11:42 | 33 |
| The V2FORMAT form is supplied in V3.0 kit. Therefore what I said in my
earlier reply is wrong. The V2FORMAT form will have to be modified to make
it agree with the incorrect ALL-IN-1/Dansk V2.3 FORMAT form.
Do you know why the ALL-IN-1/Dansk v2.3 FORMAT form was changed?
The two ways of dealing this that I can think of are:
1. Correct the FORMAT master before upgrading to V3.0. This will require
writing a conversion script which reads a Dansk V2.3 FORMAT master file
and creates a V2.3/.4 FORMAT master file with the correct format.
2. Re-convert the FORMAT master file after upgrading to V3.0.
The FORMAT master is upgraded as one of the Post Installation tasks.
This may result in the V3.0 file containing incorrect entries. After
installation the following will have to be done.
1. Update the V2FORMAT form to be equivalent to the Dansk v2.3 FORMAT
form
2. Delete the new OA$LIB_LLV:FORMAT.DAT file
3. Rename the OA$LIB_LLV:V2X_FORMAT.DAT file to be FORMAT.DAT
4. Re-run OA$LIB:FORMAT_UPGRADE.SCP
Richard
|
1405.5 | Thanks, and a little background | COPCLU::COPSPD::GLARGAARD | Allan Glargaard, DS @DMO | Wed Sep 16 1992 13:34 | 28 |
| Re. .3, Tony - you confirmed that I have some work to do before
we start upgrading - or some cleanup to do afterwards :-)
Re. .4, Richard - I'm glad you agree with Tony about how it's done, I
believe both of you now :-)
>
>Do you know why the ALL-IN-1/Dansk v2.3 FORMAT form was changed?
>
Yup, it was changed by yours truly, so I should know. In V2.3 and maybe
earlier we had a FORMAT.FRM where the Standard Formatting field was put
last in the FMS field ordering, which made TAB'ing down the screen somewhat
strange, and led to someone changing the Compile Command field by accident.
I bet someone changed the FMS attributes of the field and forgot to reset
the field orders - possibly myself.
During translation of V2.4 I decided to "fix" this, and did a reset of the
field orders - and all was well I thought. Since then we have had -
of course you may say - some trouble in getting the V2.4 FORMAT.FRM to point
to the data created with the V2.3 FORMAT.FRM. One result was that nobody could
print after an upgrade. Smiling is allowed here ;-)
Now I'm going to do something to make the same happen again, er, sorry -
I'll write some guidelines to be followed before upgrading to make sure
the customers FORMAT.DAT matches the V2FORMAT in V3.0
Thanks both for your contributions,
best regards,
Allan
|
1405.6 | | FROIS1::HOFMANN | Stefan Hofmann, LC Frankfurt, ISE | Thu Sep 17 1992 08:54 | 8 |
| Hello Allan,
when you write something about the FORMAT.DAT for upgrades, please
include paragraph 1.7 from the Danish Release Notes, because it's about
the same issue.
thanks,
Stefan
|
1405.7 | Rel.not. 1.7 not quite enough, sorry | COPCLU::COPSPD::GLARGAARD | Allan Glargaard, DS @DMO | Mon Sep 21 1992 14:47 | 32 |
| Re. .6:
> include paragraph 1.7 from the Danish Release Notes, because it's about
> the same issue.
>
Stefan, I didn't know if anything about FORMAT.DAT made it to the
release notes, but now I have a copy of the ones that made it to
production.
There is nothing wrong with paragraph 1.7, but it only covers one of
the formats - all formats have to be corrected, since they will
contain a stray "N" og "Y" in the middle of the Compile command
field, and have an empty Standard formatting field.
I'll make up something so that all the data are converted to a known
state before upgrading, along the following lines:
1) Fetch OAFORM.FLB from the A1V30 kit
2) From this library, fetch FORMAT.FRM
3) FMS/LIB/CREATE cnvformat.flb FORMAT.FRM
4) Fetch FORMAT.FRM from running system
5) Edit form name to be V24FORMAT.FRM
6) FMS/LIB/INSERT cnvformat.flb V24FORMAT.FRM
7) ALLIN1/NOINIT
8) Cmd> OA$FLO_OPEN cnvformat
9) Cmd> OA$CNV_CONVERT V24FORMAT FORMAT
I haven't checked any of this yet, but that's my basic idea.
Comments are welcome, as I'm getting rusty on this anyway.
Best regards,
Allan
|