T.R | Title | User | Personal Name | Date | Lines |
---|
3490.1 | homegrown problems... | CAADC::GALVIN | Mic Galvin, MCI Team | Wed Aug 05 1992 23:23 | 24 |
| Hi there,
Ok, now that the dust has cleared... I have 2 custom AMs and a
custom FM on this system (the stats are: VMS 5.4-3, MCC V1.2.0). It's
a VAXserver 3900 w/ 64mg of Memory, 2 RF71s and an Xterminal 1300/SPX.
When I upgraded I had some problems with MMs not being enrolled,
the typical stuff, so I enrolled them and all the standard products are
fine. However, first I couldn't see my custom icons, after enrolling
them, I could see the icons, but couldn't get past the parents. Kept
getting unrecognized child entities (roughly speaking).
I had a copy of the MCC_FDICTIONARY.DAT/BPT files that I stashed
before the upgrade. I moved those into MCC_SPECIFIC and did a REBUILD
of my dictionary. All is well at this point but I have a question. Is
it ok to use the dictionary in this manner? Is there anything that
gets done in the upgrade that I'm missing? I haven't noticed any
serious problems yet... I noticed when I installed TSAM it did a
rebuild of the dictionary, should I reinstall TSAM? I had it installed
(field test) previously... Thanks in advance.
I've gotten mail from Larry Grossman explaining *most* of my
problems... thanks. I'd be curious to know if there are alot of people
out there doing custom AMs???
/Mic
|
3490.2 | confused in Chicago | CAADC::GALVIN | Mic Galvin, MCI Team | Fri Aug 07 1992 12:33 | 21 |
| Hi there,
Anybody seen any problems with the CIRCUIT AM after upgrading to
V1.2? I keep getting the "verb, entity, partion" blues... I took a
look in my dictionary, $MANAGE/TOOLKIT/DICTIONARY SHOW, and things look
ok. When I look at the class,
DAP> use class CIRCUIT
DAP> show
I don't have any errors, or see any weirdness? To re-iterate. I
upgraded to V1.2, had problems, copied over an old copy of my
MCC_FDICTIONARY files, and did a REBUILD. Things look good with the
custom AMs and most everything else. Oh yeah, from time to time I get
an error message barking at my NOTIFICATION FM not being enrolled. I
enroll it and it says " duplicate entity...etc." Any ideas???
thanks,
/Mic
|
3490.3 | map files gone after V1.2 upgrade | CAADC::GALVIN | Mic Galvin, MCI Team | Mon Aug 10 1992 18:04 | 13 |
| Hi there,
I was able to fix my problems with the CIRCUIT AM and the
NOTIFICATION FM by re-installing MCC V1.2. I didn't move the
MCC_FDICTIONARY files over this time, and still can't see my custom AMs
or custom FM. The problem I am currently facing is that all my MAPs
are gone? I used the US Backdrop as my default map, and there it
is....GONE! What gives?
Is there an easy way to restore previously saved maps? I still
have the files on disk, but I can't quite seem to get the map files to
activate. Thanks in advance.
/Mic
|
3490.4 | Iconic Map crashes after upgrade | EEMELI::VESALAINEN | DECnet Phase V = OSI for the Masses | Wed Aug 12 1992 04:43 | 36 |
| I upgraded from DECmcc T1.2.7 to DECmcc V1.2 SSB.
I also installed ELM AM. Everything seemed to go smoothly, but when I
tried to start Iconic map PM, I'll get first the Iconic map window and
two DECmcc message windows. After that the DECmcc crashes.
I rerun IVP and everything seems to be OK. Any ideas what could be wrong?
$ mana/ent/int=decw
No input bitmaps found for FDDI-Station
%CMA-F-EXCCOP, exception raised; VMS condition code follows
-SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000032, PC
=001F137C, PSL=03C00004
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
0004B8C0 0004B8C0
0007C382 0007C382
000771DC 000771DC
0007A878 0007A878
$ mana/ent
DECmcc (V1.2.0)
MCC> show mcc 0 all attr
MCC 0
AT 12-AUG-1992 10:39:01 All Attributes
Component Name = FNOMCC:.MCC.HSKONE_DIRECTOR
Component Version = V1.2.0
Component Identification = "DECmcc"
Default Namespace Root Directory = ""
Namespace Selection = "DECdns"
|
3490.5 | see note 3236 | TOOK::MINTZ | Erik Mintz, dtn 226-5033 | Wed Aug 12 1992 08:36 | 5 |
| This is the result of a change to the registered code for the FDDI
global entity between the T1.2.7 and SSB versions of the ELM kits.
See note 3236
|
3490.6 | But I have no FDDI stations registered | EEMELI::VESALAINEN | DECnet Phase V = OSI for the Masses | Wed Aug 12 1992 09:51 | 4 |
| Hmm... note 3236 said I should do it before upgrading. However,
I did the upgrade first. :-(
Also I don't have any FDDI stations registered, does it mean
that I have the same problem.
|
3490.7 | Don't see how FDDI AM change could result in ACC-VIO | QUIVER::HAROKOPUS | | Wed Aug 12 1992 11:01 | 23 |
| > No input bitmaps found for FDDI-Station
This error indicates that the IMPM could not find the FDDI-Station icon.
Please post the following:
$show log mcc_icons
$dir mcc_icons:*fddi*.dat
$dir mcc_common:*fddi*.dat
In any event I don't see how this would result in an ACC-VIO. The fact
that you had none of the old "FDDI" entities regiestered means that the
change to FDDI-Station should not effect you.
At any time did you install the T1.2.7 ELM kit on the MCC SSB kit? This has
caused problems for other users.
Regards,
Bob
|
3490.8 | | EEMELI::VESALAINEN | DECnet Phase V = OSI for the Masses | Thu Aug 13 1992 03:05 | 76 |
| It seems that FDDI-stations icons are in mcc_common: directory.
I checked the versions and ELM AM and BMS are SSB versions.
$show log mcc_icons
"MCC_ICONS" = "USER1:[MCC.ICONS]" (LNM$SYSTEM_TABLE)
$ dir mcc_icons:*fddi*.dat
Directory USER1:[MCC.ICONS]
MCC_DOMAIN_FDDI_SEGMENT_ICON.DAT;4 MCC_FDDI_ABA_DAC_ICON.DAT;4
MCC_FDDI_ABA_DAS_ICON.DAT;4 MCC_FDDI_ABB_DAC_ICON.DAT;4
MCC_FDDI_ABB_DAS_ICON.DAT;4 MCC_FDDI_A_DAC_ICON.DAT;4
MCC_FDDI_A_DAS_ICON.DAT;4 MCC_FDDI_B_DAC_ICON.DAT;4
MCC_FDDI_B_DAS_ICON.DAT;4 MCC_FDDI_ICON.DAT;4 MCC_FDDI_NAC_ICON.DAT;4
MCC_FDDI_NULL_DAC_ICON.DAT;4 MCC_FDDI_SAC_ICON.DAT;4
MCC_FDDI_SAS_ICON.DAT;4 MCC_FDDI_TAB_DAC_ICON.DAT;4
MCC_FDDI_TAB_DAS_ICON.DAT;4 MCC_FDDI_TA_DAC_ICON.DAT;4
MCC_FDDI_TA_DAS_ICON.DAT;4 MCC_FDDI_TA_SAC_ICON.DAT;4
MCC_FDDI_TA_SAS_ICON.DAT;4 MCC_FDDI_TB_DAC_ICON.DAT;4
MCC_FDDI_TB_DAS_ICON.DAT;4 MCC_FDDI_TB_SAC_ICON.DAT;4
MCC_FDDI_TB_SAS_ICON.DAT;4 MCC_FDDI_TS_SAC_ICON.DAT;4
MCC_FDDI_UST_ICON.DAT;4 MCC_FDDI_VCONC_ICON.DAT;4
MCC_FDDI_VSLAVES_ICON.DAT;4 MCC_FDDI_WAB_DAC_ICON.DAT;4
MCC_FDDI_WAB_DAS_ICON.DAT;4 MCC_FDDI_WA_DAC_ICON.DAT;4
MCC_FDDI_WA_DAS_ICON.DAT;4 MCC_FDDI_WB_DAC_ICON.DAT;4
MCC_FDDI_WB_DAS_ICON.DAT;4
Total of 34 files.
$dir mcc_common:*fddi*.dat
Directory USER1:[MCC]
MCC_DOMAIN_FDDI_SEGMENT_ICON.DAT;4 MCC_FDDI-STATION_ABA_DAC_ICON.DAT;1
MCC_FDDI-STATION_ABA_DAS_ICON.DAT;1 MCC_FDDI-STATION_ABB_DAC_ICON.DAT;1
MCC_FDDI-STATION_ABB_DAS_ICON.DAT;1 MCC_FDDI-STATION_A_DAC_ICON.DAT;1
MCC_FDDI-STATION_A_DAS_ICON.DAT;1 MCC_FDDI-STATION_B_DAC_ICON.DAT;1
MCC_FDDI-STATION_B_DAS_ICON.DAT;1 MCC_FDDI-STATION_ICON.DAT;1
MCC_FDDI-STATION_NAC_ICON.DAT;1 MCC_FDDI-STATION_NULL_DAC_ICON.DAT;1
MCC_FDDI-STATION_NULL_DAS_ICON.DAT;1 MCC_FDDI-STATION_SAC_ICON.DAT;1
MCC_FDDI-STATION_SAS_ICON.DAT;1 MCC_FDDI-STATION_TAB_DAC_ICON.DAT;1
MCC_FDDI-STATION_TAB_DAS_ICON.DAT;1 MCC_FDDI-STATION_TA_DAC_ICON.DAT;1
MCC_FDDI-STATION_TA_DAS_ICON.DAT;1 MCC_FDDI-STATION_TA_SAC_ICON.DAT;1
MCC_FDDI-STATION_TA_SAS_ICON.DAT;1 MCC_FDDI-STATION_TB_DAC_ICON.DAT;1
MCC_FDDI-STATION_TB_DAS_ICON.DAT;1 MCC_FDDI-STATION_TB_SAC_ICON.DAT;1
MCC_FDDI-STATION_TB_SAS_ICON.DAT;1 MCC_FDDI-STATION_TREE_DAC_ICON.DAT;1
MCC_FDDI-STATION_TREE_DAS_ICON.DAT;1 MCC_FDDI-STATION_T_SAC_ICON.DAT;1
MCC_FDDI-STATION_T_SAS_ICON.DAT;1 MCC_FDDI-STATION_UST_ICON.DAT;1
MCC_FDDI-STATION_VCONC_ICON.DAT;1 MCC_FDDI-STATION_VSLAVES_ICON.DAT;1
MCC_FDDI-STATION_WAB_DAC_ICON.DAT;1 MCC_FDDI-STATION_WAB_DAS_ICON.DAT;1
MCC_FDDI-STATION_WA_DAC_ICON.DAT;1 MCC_FDDI-STATION_WA_DAS_ICON.DAT;1
MCC_FDDI-STATION_WB_DAC_ICON.DAT;1 MCC_FDDI-STATION_WB_DAS_ICON.DAT;1
MCC_FDDI-STATION_W_DAC_ICON.DAT;1 MCC_FDDI-STATION_W_DAS_ICON.DAT;1
MCC_FDDI_ABA_DAC_ICON.DAT;2 MCC_FDDI_ABA_DAS_ICON.DAT;2
MCC_FDDI_ABB_DAC_ICON.DAT;2 MCC_FDDI_ABB_DAS_ICON.DAT;2
MCC_FDDI_A_DAC_ICON.DAT;2 MCC_FDDI_A_DAS_ICON.DAT;2
MCC_FDDI_B_DAC_ICON.DAT;2 MCC_FDDI_B_DAS_ICON.DAT;2
MCC_FDDI_ICON.DAT;2 MCC_FDDI_NAC_ICON.DAT;2 MCC_FDDI_NULL_DAC_ICON.DAT;2
MCC_FDDI_NULL_DAS_ICON.DAT;2 MCC_FDDI_SAC_ICON.DAT;2
MCC_FDDI_SAS_ICON.DAT;2 MCC_FDDI_TAB_DAC_ICON.DAT;2
MCC_FDDI_TAB_DAS_ICON.DAT;2 MCC_FDDI_TA_DAC_ICON.DAT;2
MCC_FDDI_TA_DAS_ICON.DAT;2 MCC_FDDI_TA_SAC_ICON.DAT;2
MCC_FDDI_TA_SAS_ICON.DAT;2 MCC_FDDI_TB_DAC_ICON.DAT;2
MCC_FDDI_TB_DAS_ICON.DAT;2 MCC_FDDI_TB_SAC_ICON.DAT;2
MCC_FDDI_TB_SAS_ICON.DAT;2 MCC_FDDI_TREE_DAC_ICON.DAT;2
MCC_FDDI_TREE_DAS_ICON.DAT;2 MCC_FDDI_T_SAC_ICON.DAT;2
MCC_FDDI_T_SAS_ICON.DAT;2 MCC_FDDI_UST_ICON.DAT;2
MCC_FDDI_VCONC_ICON.DAT;2 MCC_FDDI_VSLAVES_ICON.DAT;2
MCC_FDDI_WAB_DAC_ICON.DAT;2 MCC_FDDI_WAB_DAS_ICON.DAT;2
MCC_FDDI_WA_DAC_ICON.DAT;2 MCC_FDDI_WA_DAS_ICON.DAT;2
MCC_FDDI_WB_DAC_ICON.DAT;2 MCC_FDDI_WB_DAS_ICON.DAT;2
MCC_FDDI_W_DAC_ICON.DAT;2 MCC_FDDI_W_DAS_ICON.DAT;2
Total of 79 files.
|
3490.9 | What's wrong with Circuit defs? | EEMELI::VESALAINEN | DECnet Phase V = OSI for the Masses | Thu Aug 13 1992 06:54 | 52 |
| After doing some more research I found the cause of this problem.
Reading note 3468.* gave me the necessary hint.
If I have Circuit defined in certain domain (created earlier),
this will cause ACCVIO when entering into this domain.
As a workaround I removed the circuit definitions from map file.
What has changed for Circuit between DECmcc T1.2.7. and DECmcc V1.2
SSB?
I have enclosed the output of "manage/ent show domain <dom> member
<circuit> all char" command and the extract from map file.
Domain FNOMCC:.helsinki Member FNOMCC:.niity-inno
AT 13-AUG-1992 12:43:09 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity =
Domain FNOMCC:.helsinki Member FNOMCC:.Niitty-Edu
AT 13-AUG-1992 12:43:10 Characteristics
Examination of attributes shows
Member Type = Static
Member Entity =
object_type 16
var 0
width 0.022500
start_x 1.526715 start_y 0.754989
stop_x 1.699273 stop_y 0.921012
text_x 1.526715 text_y 0.798499
mcc_code 1004
name Niitty-Edu
icon_name Niitty-Edu
ident_dt 0
object_type 16
var 0
width 0.022500
start_x 1.526715 start_y 0.754989
stop_x 1.595323 stop_y 1.018726
text_x 1.398857 text_y 0.884778
mcc_code 1004
name niity-inno
icon_name niity-inno
ident_dt 0
|
3490.10 | class code change. again. | TOOK::MCPHERSON | Life is hard. Play short. | Thu Aug 13 1992 09:22 | 22 |
| >
> What has changed for Circuit between DECmcc T1.2.7. and DECmcc V1.2
> SSB?
>
Answer:
The Circuit entity's Class Code changed to it's 'official' value' of 53 for
the SSB kit. Looking at your map file, it would appear that the class
code for the Circuit object was "1004" as of T1.2.7. If you look in DAP
($ mana/tool/dic) you'll see all the *real* class codes that DECmcc is
expecting (and a lot of other arcana, if you're inclined to peek...)
You see, people tend to send out FT versions of AMs without having
registered *real* class codes; they just make one up and hope it's
unique... Once an AM goes to 'officially distributed' status, it *must*
have a registered class code issued by the DECmcc registry. This process
ensures uniqueness among all the codes that can be used by DECmcc to
identify object classes....
/doug
|
3490.11 | Add mcc_common to mcc_icons definition | QUIVER::HAROKOPUS | | Thu Aug 13 1992 16:22 | 8 |
| > It seems that FDDI-stations icons are in mcc_common: directory.
> I checked the versions and ELM AM and BMS are SSB versions.
The ELM installation procedure always puts the icons into mcc_common (as does
all of the MCC installation processes I believe). If you add mcc_common to
your search path for mcc_icons then it should find the fddi-station icons.
Bob
|