Version 1.6 of ai05s/ai05-0092-1.txt

Unformatted version of ai05s/ai05-0092-1.txt version 1.6
Other versions for file ai05s/ai05-0092-1.txt

!standard 3.3.1(20.4/2)          09-04-27 AI05-0092-1/05
!standard 3.9(25.1/2)
!standard 6.3.1(21.1/2)
!standard 9.6(22)
!standard 13.3(75/1)
!standard 13.13.2(55/2)
!standard 13.13.2(56/2)
!standard A.11(4/2)
!standard A.11(5/2)
!standard A.16(68/2)
!standard G.2.2(11)
!class presentation 08-03-05
!status work item 06-03-05
!status received 06-02-13
!priority Low
!difficulty Easy
!qualifier Omission
!subject More presentation issues in the Standard
!summary
This AI corrects minor errors in the Standard.
1) Drop "must" from 3.3.1(20.4/2) (two places).
2) Replace "must be" with "is" in 6.3.1(21.1/2).
3) Drop "must" from 13.3(8.1/2).
4) Replace "must" by "shall" in 13.13.2(55-56/2).
5) Replace "Safe_last" by "Safe_Last" in G.2.2(11).
6) Drop the "3.9.2" reference from 13.3(75/1).
7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and "Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String".
8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).
9) The routines Wide_Expanded_Name and Wide_Wide_Expanded_Name should be listed in 3.9(25.1/2).
10) Replace "_statement" with "statement".
11) Add a default of "" to the Form parameter.
!question
1) Generally, "must" shall not be used in normative rules of the standard. However, 3.3.1(20.4/2) uses "must precede" twice. Should this be fixed? (Yes.)
2) "Must" also occurs in 6.3.1(8.1/2). Fix that, too? (Yes.)
3) "Must" also occurs in 13.3(8.1/2). Should that also be fixed? (Yes.)
4) "Must" also occurs in 13.13.2(55-56/2). Sigh. More text to fix? (Yes.)
5) "Safe_last" should be written as "Safe_Last" in G.2.2(11). Fix it? (Yes.)
6) 13.3(75/1) says "See 3.9.2 and 13.13.2". There doesn't appear to be anything relevant in 3.9.2. What is the intent? (Delete it.)
7) A.11(4-5/2) use the wrong names for the Wide and Wide_Wide versions of bounded strings. Fix these? (Yes.)
8) 3.9(25.1/2) mentions "Interface_Ancestor_Tag", but there is no such thing. Change to "Interface_Ancestor_Tags"? (Yes.)
9) 3.9(25.1/2) mentioned "Expanded_Name", but it doesn't mention "Wide_Expanded_Name" and "Wide_Wide_Expanded_Name". Should it? (Yes.)
10) 9.6(22) includes "_statement"; this fragment is unseemly. Should this be replaced by "statement"? (Yes.)
11) A.16(13/2) includes a default of "" for the Form parameter, but A.16(68/2) does not. Should A.16(68/2) have a default for the Form parameter? (Yes.)
[Other questions here.]
!recommendation
(See summary.)
!wording
1) Drop "must" from 3.3.1(20.4/2); it occurs in two places.
2) Replace "must be" with "is" in 6.3.1(21.1/2).
3) Drop "must" from 13.3(8.1/2).
4) Replace "must" by "shall" in 13.13.2(55-56/2).
5) Replace "Safe_last" by "Safe_Last" in G.2.2(11).
6) Remove "3.9.2 and" from 13.3(75/1).
7) In A.11(4-5/2), replace "Wide_Bounded_String" with "Bounded_Wide_String" and "Wide_Wide_Bounded_String" with "Bounded_Wide_Wide_String".
8) Replace "Interface_Ancestor_Tag" with "Interface_Ancestor_Tags" in 3.9(25.1/2).
9) Replace "or Parent_Tag" with "Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name" in 3.9(25.1/2).
10) Replace "_statement" with "statement" in 9.6(22).
11) Replace "Form : in String);" with "Form : in String := "");" in A.16(68/2).
!discussion
1) 3.3.1(20.4/2) uses "must precede", while 3.3.1(20.1-3/2) use "is preceded by". "Must" doesn't add anything here, as this is a rule after all -- following it is not optional and we don't need to re-enforce that.
2) 6.3.1(21.1/2) is a definition, and should use "is", not "shall" (or "must").
3) 13.3(8.1/2) is also a definition, and "must" is just emphasis.
4) 13.13.2(55/2) is an Implementation Requirement, and must use "shall". 13.13.2(56/2) is an Implementation Permission, so "shall" is optional, but just dropping "must" doesn't make much sense (the emphasis is needed).
5) All other references to Safe_Last use a capital 'L', this one should, too. Note that this error dates all the way back to the original Ada 95 Standard.
6) It's possible the author meant 3.9, but that wouldn't be useful, as 3.9(11) just references 13.3. We surely don't want a circular definition, so we just drop the reference.
7) The names of the types ought be consistent between A.4.7, A.4.8, and A.11.
8) An obvious missing 's'.
9) The Wide and Wide_Wide versions of Expanded_Name surely should raise the same exceptions as the base version. Anything else would be madness. Note that the routines are listed in alphabetical order.
10) This is one of a number of similar fragments in the Ada 95 RM. As they interfere with automated linking and indexing (and look like a mistake), we've been eliminating them when possible. We could have used the entire "delay_statement" here, but that would seem redundant (there are two other occurrences of delay_statement in the paragraph).
11) Clearly the specifications given in A.16(13/2) and A.16(68/2) should match. Since Form parameters generally default to "", we believe that A.16(13/2) is correct and change A.16(68/2) to match.
!corrigendum 3.3.1(20.4/2)
Replace the paragraph:
by:
!corrigendum 3.9(25.1/2)
Replace the paragraph:
Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tag, Is_Descendant_At_Same_Level, or Parent_Tag if any tag passed is No_Tag.
by:
Tag_Error is raised by a call of Descendant_Tag, Expanded_Name, External_Tag, Interface_Ancestor_Tags, Is_Descendant_At_Same_Level, Parent_Tag, Wide_Expanded_Name, or Wide_Wide_Expanded_Name if any tag passed is No_Tag.
!corrigendum 6.3.1(21.1/2)
Replace the paragraph:
by:
!corrigendum 9.6(22)
Replace the paragraph:
If an attempt is made to cancel the delay_statement (as part of an asynchronous_select or abort — see 9.7.4 and 9.8), the _statement is cancelled if the expiration time has not yet passed, thereby completing the delay_statement.
by:
If an attempt is made to cancel the delay_statement (as part of an asynchronous_select or abort — see 9.7.4 and 9.8), the statement is cancelled if the expiration time has not yet passed, thereby completing the delay_statement.
!corrigendum 13.3(8.1/2)
Replace the paragraph:
A machine scalar is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but must include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies.
by:
A machine scalar is an amount of storage that can be conveniently and efficiently loaded, stored, or operated upon by the hardware. Machine scalars consist of an integral number of storage elements. The set of machine scalars is implementation defined, but include at least the storage element and the word. Machine scalars are used to interpret component_clauses when the nondefault bit ordering applies.
!corrigendum 13.3(75/1)
Replace the paragraph:
S'External_Tag denotes an external string representation for S'Tag; it is of the predefined type String. External_Tag may be specified for a specific tagged type via an attribute_definition_clause; the expression of such a clause shall be static. The default external tag representation is implementation defined. See 3.9.2 and 13.13.2. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type.
by:
S'External_Tag denotes an external string representation for S'Tag; it is of the predefined type String. External_Tag may be specified for a specific tagged type via an attribute_definition_clause; the expression of such a clause shall be static. The default external tag representation is implementation defined. See 13.13.2. The value of External_Tag is never inherited; the default value is always used unless a new value is directly specified for a type.
!corrigendum 13.13.2(55/2)
Replace the paragraph:
If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation must ensure that the discriminants of the actual parameter of Read are not modified.
by:
If Constraint_Error is raised during a call to Read because of failure of one the above checks, the implementation shall ensure that the discriminants of the actual parameter of Read are not modified.
!corrigendum 13.13.2(56/2)
Replace the paragraph:
The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute must take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3).
by:
The number of calls performed by the predefined implementation of the stream-oriented attributes on the Read and Write operations of the stream type is unspecified. An implementation may take advantage of this permission to perform internal buffering. However, all the calls on the Read and Write operations of the stream type needed to implement an explicit invocation of a stream-oriented attribute shall take place before this invocation returns. An explicit invocation is one appearing explicitly in the program text, possibly through a generic instantiation (see 12.3).
!corrigendum A.11(4/2)
Replace the paragraph:
The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Wide_Wide_Bounded_String, and any occurrence of package Bounded is replaced by Wide_Wide_Bounded.
by:
The specification of package Wide_Text_IO.Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Bounded_Wide_String, and any occurrence of package Bounded is replaced by Wide_Bounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for Text_IO.Bounded_IO, except that any occurrence of Bounded_String is replaced by Bounded_Wide_Wide_String, and any occurrence of package Bounded is replaced by Wide_Wide_Bounded.
!corrigendum A.11(5/2)
The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Wide_Unbounded_String, and any occurrence of package Unbounded is replaced by Wide_Unbounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Wide_Wide_Unbounded_String, and any occurrence of package Unbounded is replaced by Wide_Wide_Unbounded.
by:
The specification of package Wide_Text_IO.Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Unbounded_Wide_String, and any occurrence of package Unbounded is replaced by Wide_Unbounded. The specification of package Wide_Wide_Text_IO.Wide_Wide_Unbounded_IO is the same as that for Text_IO.Unbounded_IO, except that any occurrence of Unbounded_String is replaced by Unbounded_Wide_Wide_String, and any occurrence of package Unbounded is replaced by Wide_Wide_Unbounded.
!corrigendum A.16(68/2)
Replace the paragraph:
procedure Copy_File (Source_Name, Target_Name : in String; Form : in String);
by:
procedure Copy_File (Source_Name, Target_Name : in String; Form : in String := "");
!corrigendum G.2.2(11)
Replace the paragraph:
Finally, S'Safe_First and S'Safe_last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin.
by:
Finally, S'Safe_First and S'Safe_Last are set (in either order) to the smallest and largest values, respectively, for which the implementation satisfies the strict-mode requirements of G.2.1 in terms of the model numbers and safe range induced by these attributes and the previously determined values of S'Model_Mantissa and S'Model_Emin.
!ACATS test
None needed.
!appendix

From: Tucker Taft
Sent: Wednesday, February 13, 2008  10:04 PM

A document by Derek Jones indicated that the Ada 2005
standard had 22 occurrences of "must."  Needless
to say that surprised me.  So I did a search.
I found the following 14 "musts":

   3.3.1(20.4)
   3.9.4(26/2), 3.9.4(33/2) (both from an Example)
   6.3.1(21.1)
   7.5(9/2) (a Note)
   12.6(16.1)(a Note)
   13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2)
   C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way)
   M(1/2), M.1(1/2), M.2(1/2), M.3(1/2)

I'm not sure where the other 8 could be hiding.
Only 9 of the above 14 are actually clear places
where "shall" should have been used instead.
The others are informal uses of "must."  We might
still want to purge them all, however, just to avoid
any confusion about what are the real requirements.

****************************************************************

From: Robert A. Duff
Sent: Thursday, February 14, 2008  8:40 AM

What document by Derek Jones are you talking about?

I object to blindly changing "must" to "shall".  Eschew obfuscation.  Certainly
the ones in "Language Summary" and "Examples" and other informal places can
remain as is.

The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede",
which matches the style used in the immediately preceding paragraphs, and
I think matches the general style of "Dynamic Semantics", which says what
happens, not what "shall happen".

In 6.3.1(21.1), "must be" should be "is"; it's a definition.

In 13.3(8.1/2), I could tolerate changing "must include" to "shall include",
but "includes" would be just as good.

In 13.13.2(55/2), "must" should be "shall".

In 13.13.2(56/2), "must" should probably be "shall".

Annex M is informative, so should not use "shall".

None of this has the slightest effect on implementers or users; as usual in
such cases, I'm happy to take "!No Action".

I get 22 occurrences, by the way:

@ grep -i must rm.txt 
parts: a specification, containing the information that must be visible to
must name the library units it requires.
specifies a Boolean expression (an entry barrier) that must be True before the
capabilities of class-wide operations and type extension must be tagged, so
objects of a given type must be represented with a given number of bits, or
      requiring late initialization must precede the initial value evaluations
      occurring earlier in the order of the component declarations must
Queue must provide implementations for at least its four dispatching
Queue, the implementation of the four inherited routines must be provided.
21.1/1 each attribute_designator in one must be the same as the corresponding
      assignment operation must be an aggregate or function_call, and such
      aggregates and function_calls must be built directly in the target
      formal_abstract_subprogram_declaration must be dispatching calls. See
is implementation defined, but must include at least the storage element and
of one the above checks, the implementation must ensure that the discriminants
stream-oriented attribute must take place before this invocation returns. An
time must be completely deterministic. For such implementations, it is
      programmer must make sure that the task whose attribute is being
controlled manner. Each Ada implementation must document many characteristics
implementation must document various properties of the implementation:
manner. Each Ada implementation must document all implementation-defined
certain target machine dependences. Each Ada implementation must document
@ grep -i must rm.txt |wc
     22     224    1637
@ grep -i must aarm.txt |wc
    122    1271    8910
@ 

I'll bet most of these come from Ada 83 or Ada 95 wording.

****************************************************************

From: Randy Brukardt
Sent: Thursday, February 14, 2008  9:55 PM

> > A document by Derek Jones indicated that the Ada 2005
> > standard had 22 occurrences of "must."  Needless
> > to say that surprised me.  So I did a search.

I see the new presentation AI will get started with a bang (for those of you
who missed the recent meeting, we approved and closed the existing
presentation AI as it was getting too long).

I'm surprised, too, that despite some care we managed to forget that basic
rule that many times.

> > I found the following 14 "musts":
> >
> >    3.3.1(20.4)
> >    3.9.4(26/2), 3.9.4(33/2) (both from an Example)
> >    6.3.1(21.1)
> >    7.5(9/2) (a Note)
> >    12.6(16.1)(a Note)
> >    13.3(8.1/2), 13.13.2(55/2), 13.13.2(56/2)
> >    C.7.2(30/2), C.7.2(32) ("must" is used in non-technical way)
> >    M(1/2), M.1(1/2), M.2(1/2), M.3(1/2)
> >
> > I'm not sure where the other 8 could be hiding.

Umm, Tucker, there are 15 items in this list. That explains at least one
that is "missing".

There are 5 "must"s in the Introduction (paragraphs 11, 13, 19/2, 38, 41/2).
I don't see any reason to change these.

There are two "must"s in the single paragraph 3.3.1(20.4/2). There also are
two "must"s in the note 7.5(9/2).

> > Only 9 of the above 14 are actually clear places
> > where "shall" should have been used instead.
> > The others are informal uses of "must."  We might
> > still want to purge them all, however, just to avoid
> > any confusion about what are the real requirements.
>
> What document by Derek Jones are you talking about?
>
> I object to blindly changing "must" to "shall".  Eschew obfuscation. Certainly
> the ones in "Language Summary" and "Examples" and other informal places can
> remain as is.

I think I agree. It's not worth changing.

> The two in 3.3.1(20.4) can be fixed by changing "must precede" to "precede",
> which matches the style used in the immediately preceding paragraphs, and
> I think matches the general style of "Dynamic Semantics", which says what
> happens, not what "shall happen".
>
> In 6.3.1(21.1), "must be" should be "is"; it's a definition.
>
> In 13.3(8.1/2), I could tolerate changing "must include" to
> "shall include",
> but "includes" would be just as good.
>
> In 13.13.2(55/2), "must" should be "shall".
>
> In 13.13.2(56/2), "must" should probably be "shall".
>
> Annex M is informative, so should not use "shall".

What is the alternative? A quick attempt to use other words doesn't seem to
work. Of course, leaving it as it is would be fine. OTOH, this is really
just reiterating requirements given elsewhere, so I don't think "shall" is
so bad.

> None of this has the slightest effect on implementers or users; as usual
in
> such cases, I'm happy to take "!No Action".
>
> I get 22 occurrences, by the way:
...

This didn't help any, as these are completely without (useful) context.
Other than to verify the number!

The search engine didn't help any, either - every page got matched whether
it contained "must" or not.(I'm not quite sure why, but I'm not curious
enough to go debug the code - one likely possibility is that it is a word
that is omitted from indexing and there is some bug in the override code
that is supposed to deal with the special case of finding unindexed words.)

I ended up doing a text search on the HTML text, which came up with a small
set of pages, and then searching each page individually in Firefox.

> I'll bet most of these come from Ada 83 or Ada 95 wording.

How much? The winnings would help ease my embarrassment about this issue!
Note that virtually every paragraph number in question has a /2 (meaning it
was modified or new Ada 2005 wording).

I'm embarrassed because this is something that I'm always explicitly looking
for, and I'm surprised that I missed that many. (While the rest of you are
also supposed to note such mistakes during editorial review, I get paid to
find them, so I'm not happy when I fail to do so.) I don't recall ever doing
a search for the word, though -- obviously we should have done that.

****************************************************************

From: Tucker Taft
Sent: Thursday, February 14, 2008  10:14 PM

To answer Bob's question about "what document by
Derek Jones are you talking about," he sent it
to the OWGV mailing list.  OWGV is an ISO working
group focusing on language vulnerabilities.
The document is called "Forms of language
specification."  I could ask him whether I could
forward it to the ARG mailing list if there
is sufficient interest.

****************************************************************

From: Robert A. Duff
Sent: Friday, February 15, 2008  7:09 PM

> > Annex M is informative, so should not use "shall".
                                      ^^^

> What is the alternative?

I think you missed the "not" -- that is, we agree that Annex M
need not change.

> I ended up doing a text search on the HTML text, which came up with a small
> set of pages, and then searching each page individually in Firefox.

Now you know why I like the .txt version!

After doing the grep, I did an incremental search in Emacs.
It's nice to have fancy fonts and formatting, but for searching
and cut&paste into emails, you can't beat the plain old 7-bit ascii!
(I concatenated all the *.txt files by hand, of course.
In the correct order.)

> > I'll bet most of these come from Ada 83 or Ada 95 wording.
> 
> How much? The winnings would help ease my embarrassment about this issue!

My standard amount in these cases is a nickel.  I didn't search the older
versions, but I thought I recognized some from Ada 83 -- particularly in
the "Language Summary".

I don't see any need for embarrassment.  There are NOT 22 bugs -- just 22 cases
to be looked at, and when I looked at them, I found only one case that
definitely ought to be "shall", and one "probable" case.  One and a half
minor bugs isn't a big deal!  (I looked at about 3/4 of the 22.)

****************************************************************

!topic S'Safe_[l]{L}ast
!reference Ada 2005 RM G.2.2(11)
!author Grein 2008.04.23

****************************************************************

!topic Strange reference in 13.3(75)
!reference 13.3(75), 3.9.2
!from Adam Beneschan 08-05-19
!discussion

Presentation nitpick:

13.3(75) reads:

    S'External_Tag denotes an external string representation for
    S'Tag; it is of the predefined type String. External_Tag may be
    specified for a specific tagged type via an
    attribute_definition_clause; the expression of such a clause shall
    be static. The default external tag representation is
    implementation defined. See 3.9.2 and 13.13.2. The value of
    External_Tag is never inherited; the default value is always used
    unless a new value is directly specified for a type.

Assuming someone reads this and then decides to follow the cross-references,
it's reasonable to think they might try 3.9.2 first since it's listed first;
but the effect is likely to be, "Huh?  Why did it refer me here?" since 3.9.2
says nothing about external tags or anything related to them---at least, I
don't see any connection. If the intent was that 13.13.2(29-34) is the
section that discusses T'Class'Input and 'Output (which use the external tags),
and those sections involve subprogram dispatching, perhaps it would be better
to remove the 3.9.2 reference from 13.3(75) and put them in 13.13.2(29-34).
Or, alternatively, was this 3.9.2 reference a typo (intended to be 3.9,
which would make sense)?

****************************************************************

!topic Wrong names in Wide_(Un)Bounded_IO package definitions
!reference A.11(4-5), A.4.7, A.4.8
!from Adam Beneschan 08-06-11
!discussion

A.11(4) says:

    The specification of package Wide_Text_IO.Wide_Bounded_IO is the same
    as that for Text_IO.Bounded_IO, except that any occurrence of
    Bounded_String is replaced by Wide_Bounded_String, and any occurrence
                                  ^^^^^^^^^^^^^^^^^^^
    of package Bounded is replaced by Wide_Bounded. The specification of
    package Wide_Wide_Text_IO.Wide_Wide_Bounded_IO is the same as that for
    Text_IO.Bounded_IO, except that any occurrence of Bounded_String is
    replaced by Wide_Wide_Bounded_String, and any occurrence of package
                ^^^^^^^^^^^^^^^^^^^^^^^^
    Bounded is replaced by Wide_Wide_Bounded.

The names noted are incorrect: they should be Bounded_Wide_String and
Bounded_Wide_Wide_String. 

There are similar errors in A.11(5).

****************************************************************

!topic Wrong name, missing names in 3.9(25.1)
!reference 3.9(25.1)
!from Adam Beneschan 08-06-13
!discussion

3.9(25.1) lists Interface_Ancestor_Tag as one of the routines that raises
Tag_Error if given a No_Tag argument.  But the correct name is
Interface_Ancestor_Tags (with an "s" at the end).

Also, it lists Expanded_Name, but shouldn't it also list Wide_Expanded_Name
and Wide_Wide_Expanded_Name?

****************************************************************

!topic _statement
!reference 9.6(22)
!from Christoph Grein 2008-08-07
!discussion
Quote: "..., the _statement is cancelled ..."
Is the fragment _statement intentional here? (No, I guess. This is already in RM 95.)

****************************************************************

From: Randy Brukardt
Sent: Saturday, August  9, 2008  12:58 AM

That is quite common in the RM 95; there were many such fragments around.
I've been trying to get rid of them when we have a reason to change a paragraph
anyway, but it doesn't seem important enough to do in general.
(This sort of thing made a mess for the automatic syntax link generator for the
HTML version of the Standard.)

****************************************************************

Questions? Ask the ACAA Technical Agent