Conference vaxaxp::vmsnotes

>    So which is right though? Is space valid in a volume label (in which
>    case PCSI should be fixed to work with that) or is space invalid (in
>    which case INIT etc. should be fixed not to allow it)?
>    
>    The online doco and online help both just say "12 ANSI characters"
>    without saying what that includes. Anyone know? Pointer to some ANSI
>    standard if relevant?

This particular issue is NOT a PCSI issue!

For various reasons, INITIALIZE will accept a superset of the labels that
behaive well with OpenVMS.  And the INITIALIZE on-line documentation
also says:
    
    DIGITAL strongly recommends that a disk volume label
    should only consist of alphanumeric characters, dollar signs ($),
    underscores (_), and hyphens (-).
    
Perhaps it should add that a space character is not alhphanumeric?
(debatable whether it is or not.)

One problem with charcters other than those we recommend is that the
label string  becomes part of a DISK$<label> logical name when the disk is
mounted.  DCL must be able to understand the translation of this logical.
An imbedded space causes problems.  

And if you want to see some "interesting" behaviour, include a "!" 
in a disk label!

    : This particular issue is NOT a PCSI issue!
    
    In the traditional "we told you not to do that" sense, Charlie is
    quite correct.  In the sense of returning a highly cryptic and hard
    to resolve error, we (OpenVMS) need to look at handling this in a
    somewhat more graceful fashion.  (Or -- at minimum -- we need to
    better document this overtly odd behaviour of PCSI in the relevent
    section of the error messages and recovery documentation.)
    

re .6
    
>This particular issue is NOT a PCSI issue!
    
    The information that you provide doesn't support this conclusion.
    
    What is an "ANSI" character?
    
    My guess is that VMS wanted to support some ANSI standard for volume
    labelling (a reasonable goal) but not all parts of VMS support it
    equally. Someone needs to make a call on the status of that support
    e.g. drop it or implement it.

>    DIGITAL strongly recommends that a disk volume label
    
    Yes, I saw that too but it isn't good enough. We should either make it
    work or if we can't/wont make it work then we should either
    
    1. change the help text to say that only those chars are supported
    
    or preferably
    
    2. change INITIALIZE to enforce that set.
    
    Imagine J. Random Customer issues an INIT command. If the command works
    then that's the end of it. If the command fails then the customer may
    read the help to see why. My guess is that most customers don't know
    what the legal set of characters is and as long as they don't get an
    error on the INIT (or MOUNT or BACKUP), they will never consider that
    they may have a latent problem (which has now emerged).
    
    Is there some good reason why PCSI can't be made to work with more
    diverse labels?
    
    Perhaps INIT should issue an informational diagnostic when it creates a
    volume with a label that goes against Digital's "strong recommendation".
    Maybe MOUNT too. I'm only suggesting this though because I know there
    will be cries of "we can't fix it now because customers may be relying
    on it". Customers do some strange things. I can't imagine why anyone
    would need a volume label with weird characters in it but they can
    always surprise me.
    
    [I'll make a note to QAR this in my next QAR storm.]

>DCL must be able to understand the translation of this logical.
    
    It is likely that the logical name won't be useful but that's OK
    because the MOUNT command can be asked to create some other logical
    name so the DISK$label name need never be used.

>And if you want to see some "interesting" behaviour, include a "!" 
>in a disk label!
    
    I don't imagine that this causes either INIT or MOUNT to fail. Can you
    elaborate? [I don't have a spare disk otherwise I would just try it.]

re: .8
    
>    My guess is that VMS wanted to support some ANSI standard for volume
>    labelling (a reasonable goal) but not all parts of VMS support it
>    equally. Someone needs to make a call on the status of that support
>    e.g. drop it or implement it.

My guess is sligtly different -- I don't think we ever wanted to "support
some ANSI standard for volume labelling".  I think we wanted to be able
to CREATE lables following some standard.  But it appears that what we
wanted to "support" was a sub-set of that standard.

Apparently, what we may have failed to do was (1) to clearly define and
differentiate what is possible to do from what is supported, and (2) to handle
failures from unsupported cases better.

Personally, I think that the "strongly recommends" language satisfies (1).
(2) is harder.  I know that the OpenVMS Alpha install/upgrade procedure
will *NOT* let you set a volume label to any unsupported value.  
(Offhand, I'm not certain about the VAX procedures.)

It would be possible to check the existing label and refuse to continue (or
pehaps just warn?)  if the existing label was not a supported value.  

There is no reason that the POLYCENTER Software Installation (PCSI)
couldn't make a similar check.

MOUNT could do something special, like not creating a DISK$<label> logical
if the lable is unsupported.

INITIALIZE and SET VOLUME/LABEL could have special warnings.

Where else???

How much effort is appropriate to support something that we've defined as
being unsupported?

re .9
    
>Apparently, what we may have failed to do was (1) to clearly define and
>differentiate what is possible to do from what is supported,
    
    "Supported" has two meanings.
    
    One meaning refers to what the documentation specifies. On that score
    the documentation is ambiguous. On the one hand it says that "you can
    specify a maximum of 12 ANSI characters" but on the other hand it says
    that "Digital strongly recommends...". We'll have to agree to disagree
    (or leave it to the lawyers) about whether the latter statement
    overrides the former. My interpretation is that by its very nature a
    strong recommendation against something implies that it *is* supported
    (because otherwise the doco could simply have stated that the thing is
    not supported).
    
    Of course it is a little difficult to determine what is supported
    because ANSI characters are not defined. And one could argue that the
    SPD is a more definitive specification of what is suppported but at a
    quick look the SPD didn't seem to cover this.
    
    [The other meaning refers to what actually gets supported and it
    seems likely that if a customer calls up Digital and says that his
    volume label can't be used with PCSI then Digital will not change PCSI
    to work with the volume label and hence the volume label that the
    customer has set is not being supported.]
    
>MOUNT could do something special, like not creating a DISK$<label> logical
>if the label is unsupported.
    
    I don't think this is a good idea. It is true that RMS cannot use a
    logical name containing certain characters but that does not prevent a
    program from using the logical name.
    
    
    At the very least the documentation should be changed, probably
    deleting the reference to "12 ANSI characters" and just documenting the
    subset that Digital is actually going to support. If the ANSI ref. is
    left in then additional doco of what actually goes wrong is needed e.g.
    you will not be able to use the DISK$ logical name in file
    specifications, you will not be able to install products on the disk
    using PCSI (if that's correct).

re: .10
>    At the very least the documentation should be changed, probably
>    deleting the reference to "12 ANSI characters" and just documenting the
>    subset that Digital is actually going to support. If the ANSI ref. is
>    left in then additional doco of what actually goes wrong is needed e.g.
>    you will not be able to use the DISK$ logical name in file
>    specifications, you will not be able to install products on the disk
>    using PCSI (if that's correct).

Actaully, we support SETING the label to any 12 ansi characters; we just don't
support USING it in all situations if it contains anything other that 0-9,
A-Z, "-", "_" or "$".

But I agree that the on-line documentation could be improoved by saying that
if you don't follow the practice that we "strongly recommend" then various
OpenVMS commands and utililites will not function as documented.  
Or some such ... 

If someone is sufficiently concerend, QAR it.

    For what it is worth, I did QAR this and referred this note entry last
    week.  QAR #698.
    -Don

    re .12
    
    For the record that QAR number is a reference to EVMS-RAVEN.
    
    Anybody know what
    
    C: 6    E: 14   V: 8    I: 1    T: 29
    
    means? It is in the answer to that QAR.

    It's an scheme we (VMS Engineering) use to rate QARs with
    a finer granularity than showstopper, high, medium or low.
    
    C: = Cause,  E: = Effect,  V: = Visibility,  I: = Impact 
    [+/-] = Adjustments

    T: = Total Rating

	C: Cause (10)
	-------------
	10 - Normal operation
	9 - Normal error recovery
	8 - Normal I/O error
	6 - Supported but unusual
	5 - Resource exhaustion
	4 - Command specific
	3 - Load specific
	2 - Unusual circumstances or environment
	0 - operator initiated

	E: Effect (40)
	--------------
	40 - Data corruption
	40 - Security hole
	38 - Non-priv system crasher
	   --------
	35 - Cluster hang
	33 - Cluster crash
	   --------
	30 - System hang
	28 - System crash
	   - Can't boot
	   --------
	20 - Incorrect data/status
	18 - Process hang
	16 - Process crash
	14 - Operation fails
	12 - Performance degradation
	10 - Causes confusion
	8 - Bad look and feel
	  - Overt Stupidity
	2 - Suggestion
	
	V: Current Visibility (20)
	--------------------------
	20 - CLD
	17 - Frequent QARs from already shipped sites
	   - Urgent problem blocking release (ex. blocking QTV)
	   - Core deliverable of release
	14 - QAR from prominent site on already shipped product
	12 - multiple QARs
	10 - QAR from prominent FT site (QTV/STE/HW groups/LP/RTL)
	8 - single report - already shipped product
	4 - single report - FT site
	
	I: Potential Impact (30)
	------------------------
	30 - all sites
	22 - high %
	15 - many sites
	5 - small %
	1 - rare
	
	Adjustments:
	-----------
	+10 for easy s/w fix to save $$$ (cost to fix now is significantly
	    less than support cost)
	+10 for regression
	-10 if age>2 years -or- doubly deferred