Subject: Digitmap definition override

From: Sachin Mittal <[email-masked]>
Date: Thu, 12 Oct 2000 15:12:43 +0530

The text says that a digitmap once defined can be overriden with a new
definition.
But if the digitmap is defined by management action outside the scope of MGC,
can MGC override that with a definition of it's own.

Also say there are terminations:
1. aaab
2. aaac
3. aabd
4. aabe

And the same digitmap name is used to define digitmaps on aaa* and aab* with
different
definitions. Is it allowed ? What if some terminations belong to both the
wildcarded names
used in such definitions.

Sachin

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 12:12:35 -0500

> -----Original Message-----
> From: Sachin Mittal [mailto:[email-masked]]
> Sent: Thursday, October 12, 2000 5:43 AM
> To: [email-masked]
> Subject: Digitmap definition override
>
>

[PTT] I'd say this is permissible -- there may be circumstances where it is
desirable to use this capability.

> used in such definitions.

[PTT] Digitmaps can be defined on individual terminations.  The current
value for a digitmap is that set by the most recent command affecting that
termination.  A wildcarded command is interpreted as a series of individual
commands, each affecting one termination.  Thus the answer to your question
is that digitmap values are independent of naming conventions except as
these affect command execution.

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Oct 2000 16:04:35 -0400

In considering your questions, note that when terminations are moved back to
the NULL context, their properties take on default values, which may be
provisioned (section 6.2.4).  Hence any MGC overriding of digit map values
other than those defined on ROOT is temporary.  I would assume by definition
that a cold start reestablishes default values on ROOT and on all persistent
terminations.

As for your second question: does provisioning change default values only,
or can it change current property values for a termination as well?
Opinions?

> From: Dave Sclarsky [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 3:33 PM
> Subject: Re: Digitmap definition override
>
>
> I agree that the MGC should be able to override a
> provisioned digitmap, but it does raise some questions:
>
> 1. If an MGC overrides a management-provisioned Digitmap,
> which value should the MG be expected to use after a
> subsequent cold start (i.e. how long does the MGC
> definition persist)?
>
> 2. Also, what if a management action changes the value of
> a Digitmap after it was overridden by the MGC?
>
> What do you think?
>
> Dave Sclarsky, S-Link Corporation
> [email-masked]
>
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Monday, October 23, 2000 1:13 PM
> Subject: Re: Digitmap definition override
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 23 Oct 2000 16:09:52 -0400

> subsequent cold start (i.e. how long does the MGC
The provisioned value

> a Digitmap after it was overridden by the MGC?
The provisioned value, the NEXT time the digitmap is used, i.e.
it behaves like the text describes for a new value of an
existing, in-use digitmap.

If the management system does this, it does so under peril that
the MGC may not understand what has happened.

Brian