| Attached is a discussion we had re: the Data COllector code change, etc
cross-posted from the DECMCC developers conference....
Note that Rob whipped up a DCL procedure (knowing Rob, what else!) that would
fix up the map files for the data collector. You could hack it up to fix the
Circuit icons in map files, if you wanted...
Of course, this is all predicated on the assumption that the problem *is*
invalid class codes for the circuit entity....
/doug
================================================================================
Note 114.0 BL18 breaks use of Collector 9 replies
TOOK::R_SPENCE "Nets don't fail me now..." 13 lines 23-MAR-1992 17:27
--------------------------------------------------------------------------------
WARNING!! The Collector entity class changed for BL18!!!
We must be sure to include appropriate warnings and procedures
with the FT Update in case people have collectors in domains.
Once you do the upgrade to 18 you can't access existing collectors
so you can't delete them and put them back.
An attempt to put in a replacement gives an obscure error.
You also cannot update domains that contain the collector.
s/rob
================================================================================
Note 114.1 BL18 breaks use of Collector 1 of 9
TOOK::MCPHERSON "Save a tree: kill an ISO working g" 13 lines 23-MAR-1992 23:29
-< Bit me, too. >-
--------------------------------------------------------------------------------
Yeah. This one bit me last Friday. Really rained on my parade for a while...
This *definitely* needs a 'pre-emptive strike' of warning documentation with the
EFT Update kit.
Although... if the MIR files will be incompatible between EFT and EFT
Update, then this shouln't be a problem, right? At least it'll be a _small_
problem compared the task of rebuilding all of the repositories... :^/
At any rate, I plan on jotting down some notes on this & putting them in the
MCC conf when I can pull togther a few attention units...
/doug
================================================================================
Note 114.2 BL18 breaks use of Collector 2 of 9
TOOK::MINTZ "Erik Mintz, DECmcc Development, dtn 226" 9 lines 24-MAR-1992 08:28
--------------------------------------------------------------------------------
>Although... if the MIR files will be incompatible between EFT and EFT
>Update, then this shouln't be a problem, right? At least it'll be a _small_
>problem compared the task of rebuilding all of the repositories... :^/
On ULTRIX only. The class code problem will happen on both VMS and ULTRIX.
I believe the Circuit AM is going to change codes once they complete
registration as well.
================================================================================
Note 114.3 BL18 breaks use of Collector 3 of 9
TOOK::R_SPENCE "Nets don't fail me now..." 5 lines 24-MAR-1992 09:29
-< VMS is actually more of a problem >-
--------------------------------------------------------------------------------
Yes, and MIR files is a much too imprecise description.
On VMS the Instance repositories have NOT changed and there is
no reason to trash things.
s/rob
================================================================================
Note 114.4 BL18 breaks use of Collector 4 of 9
MCDOUG::MCPHERSON "Save a tree: kill an ISO working" 48 lines 24-MAR-1992 09:59
-< more precision... >-
--------------------------------------------------------------------------------
> Yes, and MIR files is a much too imprecise description.
> On VMS the Instance repositories have NOT changed and there is
> no reason to trash things.
Pardon my imprecision. I should learn not to send mail or reply to
notes when it's past my bedtime... ;^)
You're right Erik. I forgot that VMS doesn't have the same probs as the
ULTRIX dictionary file underpinnings... Silly me.
Whether or not the instance repositories (at least on ULTRIX)
have changed is not the issue at hand. Although wholesale
replacement of the dictionary and instance repository with post-BL17
will solve the Data Collector class code change problem. (Not unlike
blowing up your house will solve a termite problem... :^)
The fundamental problem (VMS or ULTRIX) is that the CLASS CODE for the
Collector has changed and that *will* affect anything that has ever
stored any information about the class of a (previously registered)
Collector.
This is my 'punch list' off the top of my head. Please reply with
corrections/additions/etc, since this will likely form the
"DangerDangerDanger" warning for the Data Collector with the EFTUpdate
kit....
BEFORE upgrading to EFTupdate (or any post BL17 kit) the user will have
to
- get a listing of all registered collectors (ideally also any
reference data about them)
- create a script (using this data) that will re-register the
collectors
- DEregister all data collectors from the system
- Upgrade
- RE-register all Data collectors to the system (using the script)
- Update all PRE-upgrade MCC_MAP files with the appropriate class
codes (e.g. mcc_code 307 --> mcc_code 25) for Collectors where
appropriate...
I haven't thought about it much (and would welcome comment) but would
it also be necessary to remove (and subsequently re-add) Data
Collectors from any domains they are members of?
/doug
================================================================================
Note 114.5 BL18 breaks use of Collector 5 of 9
TOOK::CALLANDER "MCC = My Constant Companion" 3 lines 24-MAR-1992 10:02
-< other MIRs effected >-
--------------------------------------------------------------------------------
be warned that MIR files containing collector info will also
be effected by this change (ex: alarms and notification MIRs)
================================================================================
Note 114.6 BL18 breaks use of Collector 6 of 9
TOOK::R_SPENCE "Nets don't fail me now..." 9 lines 24-MAR-1992 10:38
-< One step... >-
--------------------------------------------------------------------------------
Well, as one step, I have a DCL procedure that will update all the
MAP files for the new class.
I wil post a location as soon as I test it some more (that is, I
get back to BL17 and do the rest of the procedures).
If anyone needs it sooner, send me mail.
s/rob
================================================================================
Note 114.7 BL18 breaks use of Collector 7 of 9
MCDOUG::MCPHERSON "Save a tree: kill an ISO working" 25 lines 24-MAR-1992 10:52
-< ?more info on Notif. FM MIR? >-
--------------------------------------------------------------------------------
>
> be warned that MIR files containing collector info will also
> be effected by this change (ex: alarms and notification MIRs)
>
Jill,
Isn't the notfication FM's MIR kinda 'transitory' in that it doesn't store any
data beyond the current DECmcc session (other than storing the notify requests
as script files) ? Or am I oversimplifying?
If that's so, then wouldn't NOTIFY requests be OK as long as the class code for
the object in the domain is consistent with what's in the dictionary? (I.e. as
long as the user followed the steps I outlined a couple of replies back). If
not, then what else do we need to watch out for?
Since alarm rules can be created and "saved" across a system upgrade, then they
are probably more dangerous... When alarm rules are created, do they store the
class code of the entity internally? If yes, then that'll be another gotcha
for alarms rules on Collectors (or circuits). Fortunately (for the COllector
AM) they're pretty much 'event oriented' so there's not too much interesting
about Collectors that you can alarm on (except maybe an "OCCURS N TIMES" rule).
Circuits are probably more of a concern.
/doug
================================================================================
Note 114.8 BL18 breaks use of Collector 8 of 9
TOOK::R_SPENCE "Nets don't fail me now..." 12 lines 24-MAR-1992 18:10
-< More progress >-
--------------------------------------------------------------------------------
I downgraded my system this morning from BL18 to BL17 and encoundered
only one minor (now that I know the answer it seems minor - you shoulda
seem me this morning) problem.
Before you downgrade from BL18 to BL17 so you can deal with existing
collectors, be SURE to delete all of the MCC_class_STACK logicals.
The one for the registration_fm will cause an ACCVIO in the IVP
if you don't deassign it.
so far so good...
s/rob
================================================================================
Note 114.9 BL18 breaks use of Collector 9 of 9
TOOK::CALLANDER "MCC = My Constant Companion" 7 lines 27-APR-1992 08:40
-< targeting data stored in notif MIR >-
--------------------------------------------------------------------------------
the notification MIR is not transitory, it is just as permeanent
as the alarms MIR. BUT... it only stores the targeting database
information, it does not store the notify requests. Notify requests
are just that, mcc_call_function requests and nothing more. They live
and die like all other transient commands.
|