| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 141.1 | fyi | SHALOT::CLARK | | Fri Feb 28 1992 20:30 | 5 |
|
FYI, this note was cross-posted in DIAMONDFT, note 379.
|
| 141.2 | Starting the investigation | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Feb 28 1992 20:51 | 10 |
| Terry,
Are there any errors in the scripts in the ESC areas? Do they execute
correctly when called interactively in an uncompiled state?
I haven't seen this problem before and I have compiled in lots of
scripts (the Lotus 1-2-3 for ALL-IN-1 integration) from non-OA
application areas with DIAMOND.
Tony
|
| 141.3 | Now seen twice | AIMTEC::WICKS_A | Vote Bill'n'Opus for a weirder USA | Fri Feb 28 1992 21:10 | 15 |
| Terry,
This error has now been reported from another Field Test Site running
BL122D.
It's different numbers of bytes and different addresses but all the
same other stuff "ASCIC string alternate ..", "RMS directory list.."
Do I remember that this particular system is running VMS v5.5? just
looking for a pattern in common with the other site.
Regards,
Andrew.D.Wicks
|
| 141.4 | More to check | SIOG::T_REDMOND | Thoughts of an Idle Mind | Fri Feb 28 1992 22:40 | 10 |
| Another thing to check...
TXL source areas are determined by records in CM$AUTH$LOCATIONS with
the TXL flag set to OA$Y. Can you check all of the records in the data
set with the flag set and see if the logical names point to valid disk
areas. Also check that the right TXL compiler is being used for the
files in those areas. For example, make sure you don't have a record
for a location storing DO mode scripts which actually stores BLPs.
Tony
|
| 141.5 | re .2, .3, .4 | SHALOT::CLARK | | Mon Mar 02 1992 14:51 | 98 |
|
re .3
Hi Andrew,
Yes, both system here in Charlotte with this error are running
VMS 5.5.
re .2, .4
Hi Tony,
I haven't tried executing each file interactively. I've watched the
txl compilation and see no error on the files being included. Also
I believe the entries in CM$AUTH$LOCATIONS are correct. The logicals
point to valid directories and those directories contain the correct
filetypes. I've listed the entries with the TXL flag set below. If
you see something wrong please let me know.
Terry
----------------------------------------------------------------------
Application Area: ESC_ENGLISH
Type: BLP
Site Location: OAX$SITE_BLP_ESC_ENGLISH:
Base Location: OAX$BLP_ESC_ENGLISH:
Description: ESC Site ENGLISH area for BLP element type
Open: Y
Txl Location: Y Txl Type: BLP
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.BLP_ENGLISH]
Base Translation: ESC$DISK:[ESC.BLP_ENGLISH]
----------------------------------------------------------------------
Application Area: ESC_ENGLISH
Type: DO
Site Location: OAX$SITE_DO_ESC_ENGLISH:
Base Location: OAX$DO_ESC_ENGLISH:
Description: ESC Site ENGLISH area for DO element type
Open: Y
Txl Location: Y Txl Type: DO
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.DO_ENGLISH]
Base Translation: ESC$DISK:[ESC.DO_ENGLISH]
----------------------------------------------------------------------
Application Area: ESC_ENGLISH
Type: SCP
Site Location: OAX$SITE_SCP_ESC_ENGLISH:
Base Location: OAX$SCP_ESC_ENGLISH:
Description: ESC Site ENGLISH area for SCP element type
Open: Y
Txl Location: Y Txl Type: SCP
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.SCP_ENGLISH]
Base Translation: ESC$DISK:[ESC.SCP_ENGLISH]
----------------------------------------------------------------------
Application Area: ESC_SHARE
Type: BLP
Site Location: OAX$SITE_BLP_ESC_SHARE:
Base Location: OAX$BLP_ESC_SHARE:
Description: ESC Site SHARE area for BLP element type
Open: Y
Txl Location: Y Txl Type: BLP
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.BLP_SHARE]
Base Translation: ESC$DISK:[ESC.BLP_SHARE]
----------------------------------------------------------------------
Application Area: ESC_SHARE
Type: DO
Site Location: OAX$SITE_DO_ESC_SHARE:
Base Location: OAX$DO_ESC_SHARE:
Description: ESC Site SHARE area for DO element type
Open: Y
Txl Location: Y Txl Type: DO
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.DO_SHARE]
Base Translation: ESC$DISK:[ESC.DO_SHARE]
----------------------------------------------------------------------
Application Area: ESC_SHARE
Type: SCP
Site Location: OAX$SITE_SCP_ESC_SHARE:
Base Location: OAX$SCP_ESC_SHARE:
Description: ESC Site SHARE area for SCP element type
Open: Y
Txl Location: Y Txl Type: SCP
Languages:
Protection:
Site Translation: ESC$DISK:[ESC.SITE.SCP_SHARE]
Base Translation: ESC$DISK:[ESC.SCP_SHARE]
----------------------------------------------------------------------
|
| 141.6 | Entries are correct. | CESARE::EIJS | All in 1 Piece | Mon Mar 02 1992 15:43 | 17 |
|
Hi Terry,
The CM$AUTH$LOCATIONS entries are correct.
Apart from the error messages, the question will arise: Are duplicate
entries errors?
The TXL compilation code ignores the duplicates and creates a final
TXL. Currently when duplicates are flagged, the TXL won't be installed.
That's the reason for the last message. However, under the assumption
that a TXL without the duplicates is still a correct TXL then this is
not the expected behaviour. I'll check this.
Ciao,
Simon
|
| 141.7 | Remove duplicates for a sanity check | FAILTE::LAAHS | Two Cute Celts are better than one | Tue Mar 03 1992 10:13 | 9 |
| Terry,
To eliminate the duplicates problem can you try recompiling after
temporarily renaming the duplicates from the OA$BLP_ENGLISH area?
By the way, I don't think that the presence of duplicates should stop
the TXL being installed.
Kevin
|
| 141.8 | It works when duplicates are renamed | SHALOT::CLARK | | Tue Mar 03 1992 15:31 | 16 |
|
Hi Kevin,
Renaming the duplicates in the OA area is how I temporarily got
around the problem. Just as a sanity check I renamed them back
to their original names and recompiled A1TXL again. As expected
I got the duplicate warning messages, the LIB$FREE_VM errors, and
A1TXL was not installed. I then renamed the OA duplicates to be
unique and again recompiled A1TXL. No warnings or errors were
displayed and A1TXL was installed.
One of the developers here looked at the code and has reported a IPR.
Cheers'
Terry
|
| 141.9 | Still need to resolve the problem | SHALOT::NICODEM | Who told you I'm paranoid??? | Mon Apr 06 1992 22:22 | 57 |
|
[The following is posted for Terry Clark...]
Hi,
It appears that a problem still exists in the TXL Compile code.
The environment is ALL-IN-1 V3.0 PBL123A with the ESC appl areas
included during txl compiles.
It seems that when duplicate files are encountered during the
A1TXL compilation, the txl will compile but not install.
To verify this I removed the ESC application from CM and compiled
A1TXL. It completed successfully with no errors and then installed
the txl.
Next, I installed the ESC appl and then renamed all the files that
would be included in A1TXL to be unique. I started the A1TXL
compile again. It completed successfully with no errors and then
installed the txl.
Next I renamed the ESC files back to their original names (which
would create duplicates) and started the A1TXL compile. This time,
when all the files were included, I got the following
TXL> SCRIPT SM_GENERAL_QM_ERROR
TXL> SCRIPT TMEDIT
TXL> SCRIPT TM_RESTORE_CAL
TXL> total bytes in elements = 709541
Text Library OA$LIB_LLV:A1TXL compiled with 32 duplicate elements
Text Library OA$LIB_LLV:A1TXL successfully compiled
Press RETURN to continue
After pressing return to continue as instructed, I got the following
message.
Error compiling ALL-IN-1 TXL
I examined the message screen saw the following.
%OA-I-TXL_TRACE_ELE, TXL> SCRIPT SM_GENERAL_QM_ERROR
%OA-I-TXL_TRACE_ELE, TXL> SCRIPT TMEDIT
%OA-I-TXL_TRACE_ELE, TXL> SCRIPT TM_RESTORE_CAL
%OA-I-TXL_TOTALBYTES, TXL> total bytes in elements = 709541
%OA-I-TXL_COMPILED_DU, Text Library OA$LIB_LLV:A1TXL compiled with 32 dupli
cate elements
%OA-I-TXL_COMPILED, Text Library OA$LIB_LLV:A1TXL successfully compiled
%OA-I-LASTLINE, Error compiling ALL-IN-1 TXL
Press RETURN to continue
I looked in OA$LIB and saw a new txl file but it was not installed.
Any suggestions?
Terry
|
| 141.10 | Duplicates still regarded as 'error situation' | CESARE::EIJS | All in 1 Piece | Tue Apr 07 1992 11:20 | 50 |
|
Terry,
The VM problems were fixed for BL123*, however the check for the
duplicate entries resulting in the message that the compilation failed
still exist. The scripts CM_CDS.SCP and CM_CTX.SCP both check if
duplicate entries were found and then jump to a certain label. It's been
mentioned before in this note that duplicates shouldn't actually be
regarded as errors but no changes were made for BL123.
A workaround is to replace the following lines in CM_CDS.SCP:
.IF NOT #CM_STATUS OR OA$TXL_DUPL_ELEMENTS NE 0 OR -
OA$TXL_COMPILER_ERRS NE 0 THEN .GOTO ERROR_COMPILING_TXL
OA$TXL_REMOVE CMTXL \OA$MSG_PURGE\-
by:
.IF NOT #CM_STATUS OR OA$TXL_COMPILER_ERRS NE 0 THEN -
.GOTO ERROR_COMPILING_TXL
OA$TXL_REMOVE CMTXL
.IF OA$TXL_DUPL_ELEMENTS EQ 0 THEN OA$MSG_PURGE
and replace the following lines in CM_CTX.SCP:
.IF NOT #CM_STATUS OR OA$TXL_DUPL_ELEMENTS NE 0 OR -
OA$TXL_COMPILER_ERRS NE 0 THEN .GOTO ERROR_COMPILING_TXL
OA$TXL_REMOVE A1TXL \OA$MSG_PURGE\-
by:
.IF NOT #CM_STATUS OR OA$TXL_COMPILER_ERRS NE 0 THEN -
.GOTO ERROR_COMPILING_TXL
OA$TXL_REMOVE A1TXL
.IF OA$TXL_DUPL_ELEMENTS EQ 0 THEN OA$MSG_PURGE
In that case duplicate elements are not regarded as errors and the
message buffer isn't cleared so that you can review the buffer after
completion.
HTH,
Simon
PS The workaround doesn't mean the problem is forgotten!
|
| 141.11 | Duplicate element message is *informational* | IOSG::HULIN | Ian Hulin, IOSG: REO, DTN 830-6141 | Tue Apr 07 1992 15:18 | 46 |
|
Gentlemen,
The bug in the base note has been fixed. The only bug in the base note
was the VM memory corruption.
The messages you see regarding duplicate elements are informational
only. The code merely tells you that the second element with the same
name is not being compiled into the TXL and carries on to create the
section file as noted in .9.
It is entirely under your control as to which version of a duplicate
element gets put into the TXL.
If you want them both, change one of the duplicate element names.
If you want only one of the two, ensure that the directory containing
the desired TXL element gets compiled first, you can do this via CM
so that it gets compiled into the CDS TXL.
If you're trying to supersede base elements in the base TXL without
going through CM, firstly you deserve all the problems you get, but in
a more charitable mode you can still ensure that the directory order is
observed by calling OA$TXL_COMPILE(A1TXL="hackers_data_file_spec.dat").
However you're technically unsupported if you do this.
Why not keep things simple and use the supplied technology? If what's
provided is inadequate for what you want to do:
1 Ask whether you should be doing what you want to do.
2 If there's a genuine gap in the functionality provided, tell us
precisely as possible what you're trying to do and if there's a
genuine oversight/bug, report it.
Looks to me like the base software's behaving itself here and doing
what it says it does, or am I missing something?
The only sticky area I can potentially think of is customising base
elements in A1TXl; can anyone in Turin say whether a superseded source
gets moved out of its directory into the CDS TXL source directory when
the customised element is made live by the Application Maintainer?
Cheers,
Ian
|
| 141.12 | Maybe it's not that big a problem? | SHALOT::NICODEM | Who told you I'm paranoid??? | Tue Apr 07 1992 15:34 | 27 |
| Ian,
I'd like to emphasize that we, in no way, wish to "circumvent" what is
intended by CM, nor are we trying to "hack" anything. Let me see if I can
simplify the problem, in standard CM terms.
We have an application which is being developed in its own CM area.
There are occasional elements which are part of this application which have the
same name as base ALL-IN-1 elements. (I understand the concept of naming
conventions; it's simply not always possible to avoid this situation -- like
when an application must customize something like WPPRINT.SCP, for example.)
Using the priorities that CM supplies, we wish to compile these appli-
cation elements into the A1TXL, along with the base elements. The standard
menu option allows this, and compilation begins. When the duplicate name is
encountered, an error message is displayed to that effect. That is fine; it's
no different than encountering the same situation during a DCL link procedure.
However, the newly-compiled TXL does *not* get installed. Furthermore,
it is unclear whether it *should* be, since we're not certain what "errors"
may have been generated during the compilation.
Given that the VM problem is fixed, all we're asking is that duplicate
names be allowed across areas, and we'll be responsible for the "precedence" of
which gets picked. However, the newly-compiled TXL still must be installed.
F
|
| 141.13 | See 160.* | CESARE::EIJS | All in 1 Piece | Tue Apr 07 1992 17:01 | 9 |
|
Ian,
If I think I know what you asked form then please have a look at 160.*,
where this same question was asked by Frank.
Ciao,
Simon
|
| 141.14 | | SHALOT::CLARK | | Tue Apr 07 1992 18:58 | 55 |
|
Ian,
I agree with you on your comments about the errors recorded in the
base note. The VM errors listed have indeed been fixed and I would
like to say "Thank You" to everyone who took part in fixing those
errors.
However the problem listed in .9 (my note post for me by Frank)
concerns with why the txl was not installed. That is the concern
I now have. I think Simon is right. You might want to take a look
at note 160. FWIW, we are not hacking code or trying to do anything
strange. We simply have an application area that supports SDC and
SITE areas. We place our files in the application SDC area and
expect/support user customizations in the application SITE area.
We also expect the files in the BLP, DO, SCP areas to be included
in the appropriate txls. All this is clearly supported by CM. As
you can see there is nothing out of the ordinary with what we are
doing.
Simon,
Thanks for the code changes. At this time I kind of don't want to
have to customize a users system just to have the txls installed.
But if thats the way to go then our development team will need to
consider this option. FYI, I tried issuing the command
<OA$TXL_REMOVE followed by <OA$TXL_INSTALL. The recompiled A1TXL
was installed and the software appears to behave as expected. This
also might the option was have to take.
The main question(s) I have is this.
o When duplicates are found on a system, what is the correct
action ALL-IN-1 should take? Should it report the duplicates
as errors and not install the newly compiled txl (as it currently
does)? Or should it ask the installer if they want to install
the newly compiled txl (my personal choice)?
o Where does the development team stand on this? Is this
something they feel might need to be changed?
o What does the development team recommend as the offical action
to be taken by the application teams when we encounter this
situation?
I know I can be long-winded so I'll stop for now. I will be on
vacation starting tomorrow, April 8 and will not be back in the
office until Monday, April 20.
Thanks again to everyone for their input.
Terry
|