Subject: Summary of $, *, MOVE, ServiceChange

From: Madhu Babu <[email-masked]>
Date: Fri, 28 Jan 2000 11:56:17 +0530

I suggest that we should adopt this practice:
1. The special values $, * both for contexts and terminations have defined
meaning that
is not dictated by the command functionality they appear in:
ContextID * means ALL contexts (not ANY context in some cases as SUBTRACT C=*
T=foo*,or T=*, or T=specified)
ContextID $ means ALLOCATE a new one (not FIND a context as in SUBTRACT C=$ T=
... as above...)
TermID * means ALL terminations
TermID $ means ALLOCATE ephemeral (Don't look at media descriptor)
TermID foo* means ALL that START with foo
TermID foo$ means CHOOSE a physical (Don't look at media descriptor)

2. Some commands are termination oriented and the appearance of contextID
doesn't
carry any meaning. No validation of contextID should be done for these commands
These are ServiceChange and Audit (Auditing termination whether in context or
not)
(Subtract ??? For Subtract the only meaning
of context is NULL or non-NULL. specific contextID do not have a meaning because
a
termination belongs to a single context and subtraction is moving to NULL from
that single context.
specific contextID is used by MGC only to help MG easily locate the context or
may be for
more commands for the same context.)

3. ADD and MOVE are related to both termination and context.

(what about other commands ???)

Madhu
Sachin
Hughes Software Systems

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 31 Jan 2000 18:46:06 -0500

Most of point 1 looks like good practice, and we probably follow it at this
point.  I'm not too happy about any suggestion that the MG doesn't have to
look at the media descriptor when allocating ephemerals, and saying that
foo$ always means a provisioned termination is also probably too
restrictive.  Later discussion in the thread "Choosing of ephemeral /
physical Termination" gives examples where that latter convention in
particular is undesirable.

We have also discussed when contextID is significant and when it is not.  We
can spell this out further, but it's definitely in the "clarifications"
category.

> -----Original Message-----
> From: Madhu Babu [SMTP:[email-masked]]
> Sent: Friday, January 28, 2000 1:26 AM
> To:   [email-masked]
> Subject:      Summary of $, *, MOVE, ServiceChange
>