Conference vaxaxp::vmsnotes

    Setting default to a searchlist can be a bad idea if you don't know
    what to expect - and complaining about it usually shows you didn't know
    what to expect :-)
    
    >$!show default
    >$!  TESTLOG:[000000.USER.SUMNERC]                      <----- ?????
    >$!  =   SYS$SYSDEVICE:[000000.USER.SUMNERC.DEV]
    >$!  =   SYS$SYSDEVICE:[000000.USER.SUMNERC.PRODUCTS]
    
    The device spec is held in a logical (SYS$DISK) and the rest is held
    somewhere else (in P1 space?). When setting your default, DCL has to
    salt away a device spec and a directory spec: in this case TESTLOG:
    will be your device spec and your *current-at-the-time-of
    the-command-dir-spec* will be your directory spec (i.e. the latter is
    unchanged). Hence the confusing display.
    
    The RMS defaults applied to file and directory creation are subtly
    different, so directories get created in SYS$DISK:[whereever], where
    [wherever] will start off as your current dir spec if your new
    directory is a relative one (starts with a "[." or "<." ).
    
    So far as I know this behaviour has only received minor tweaks since
    searchlists were introduced back in V4 (1985 or so?), and each tweak
    broke some existing code. So I expect your chances of having this
    changed are minimal. (It may even be either documented or documented as
    unsupported by now).
    
    So I think the answer is "if it hurts, don't do it".
    
    Antonio
    
    

	.1 esentially says it all.

	SET DEFAULT does two things.  One, it defines the logical SYS$DISK
	to point to the current disk device.  And two, it calls $SETDDIR
	to set the default directory.

	When a search-list logical is used, SYS$DISK is changed to the
	name of the logical, and your default directory is unchanged -
	since DCL doesn't know what directories, if any, are in the search
	list.  Been this way forever - it's not going to change.

	The relative directory specification used in the CREATE/DIR command
	ends up appending the directory specification to the default dir,
	which was unchanged by SET DEFAULT.

	-Dave

re .1
    
>the rest is held somewhere else (in P1 space?)
    
PIO$GT_DDSTRING
    
re .0
    
    It's a bug disguised as a feature.
    
    There ought to be a STARS article for this (since in all probability it
    isn't going to get fixed). Can you write one/get the writing of one
    initiated?

>Syntax For Setting Default To A Search List Logical In V5 VMS
>How SET DEFAULT Deals With Logical Names
>[OpenVMS] SET/SHOW DEFAULT to Searchlist Returns Original Directory Also

Are three existing STARS articles covering this 'feature' that have
been available since 1986.  The last one is also covered in the
V5.5-2 release notes which state "This problem will be corrected
in a future release of VMS."

    re .4
    
    Does any of those articles mention or explain the effect on CREATE/DIR? 

Re: .5
>    Does any of those articles mention or explain the effect on CREATE/DIR? 

I've only checked the last one and it does not explicitly mention CREATE/DIR.

Re: .4

>                             The last one is also covered in the
>V5.5-2 release notes which state "This problem will be corrected
>in a future release of VMS."

Fixed how? The display is currently correct (albeit confusing). If you set
default to TESTLOG:[ANYWHERE] the display will still be correct. And a DIR will
work (it just might not list what you expected). I'm not sure what the author of
the release note thought would be the correction that should be applied.

The article lists (in the non customer readable portion):

\     QARs: V5 #06662, SPR_VMS_V5 #04108, DRAGON-FT #00539

so it has been around and known for quite a while. The last time I leafed
through the code that did this, it seemed fairly clear from the code and the
comments that its behaviour was intentional. 

I have my default set to such a logical quite a lot of the time (since the REO
build environment requires such searchlists) and I rarely notice "interesting"
effects. You learn to be careful about relative directory specs, other than that
it "just works".


Antonio

    
    Hello, 
    
    I don't mind starting a Stars article for the specific effects on
    $CREATE/DIR if anyone would be willing to proof-read it.  However I'm
    on on holiday tomorrow for a week, so it won't be until I return,
    Mid-March.
    
    Previous notes mention related STARS articles, please could someone
    post the article titles in here.  The one's I looked at mention
    senarios around RENAME (remote).  I also need to tell my customer that
    this is a known issue and the ins & outs of why it will/wont be fixed.
    
    Thanks for all of your replies and yes, this is my first "real" exposure
    to searchlist logicals :-)
    
    Cheers,
                                                                   
    Chris

Is it really CREATE/DIR that's different, or is it simply any use of
relative-directory syntax, "[.chris_test]" or "[-.otherdir]"

    As far as I can see, it's just the relative directory syntax that
    matters. You think you are in FOO:[HERE] but you really are in
    FOO:[WHERE-I-STARTED], so all the relative stuff goes wrong. If you
    explicitly supply valid specs for the tree you really are in, it all
    works beautifully.
    
    Of course, when it goes wrong, it really does your head in - now where
    did that directory go :-)
    
    Antonio

    re .6
    
    When the STARS article refers to fixing something, the author may have
    had in mind just cleaning up the SHOW DEFAULT display. However that
    might be dangerous if other things (like relative directories) don't
    change in their behaviour.
    
    The more I think about this the more I think that no change will be
    made. Suppose I $ SET DEFAULT TESTLOG where TESTLOG is a search list.
    Consider that if a search list contains all rooted directories
    then it is valid to retain the current default directory whereas if the
    search list contains all non-rooted directories then the current
    default directory should be meaningless and if the search list contains
    a mixture then as far as I can see this is "invalid". [Here mixture means
    at the top level. Some of the translations may themselves be search
    lists, likewise independently constrained to be "homogeneous".]
    
    One possible approach is that SHOW DEFAULT would suppress the directory
    string when the search list is all non-rooted and SET DEFAULT will
    actually change the default directory string to an "appropriate" part
    of the first directory in the search list. This would make relative
    directories work better but would still have some surprise value (in
    particular CRE/DIR would work but DIR would look only in the first
    directory but that may be better than looking in the wrong place(?)).
    
    I think that a better fix might require a change to RMS which isn't
    likely to be popular with the engineer.
    
    re .7
    
    There is a list of relevant articles in .4 although I couldn't find the
    second listed. After reviewing the first and third, I believe that the
    third article should be added to (rather than a new article written).
    The third article lists the bad effect of doing
    
    $ DIR [.SUB]
    
    and it should also list the bad effect of doing
    
    $ CRE/DIR [.SUB]
    
    The behaviour probably won't be changed because of the difficulty of
    judging the effect on existing applications.
    
    re .8
    
    You are right. All relative directories give "erroneous" results but
    there is a very big difference between a DIRECTORY command that fails
    without side-effect and a CREATE/DIRECTORY command that silently
    succeeds and puts the directory in an unexpected place.

    Can someone explain why CREATE FOOBAR.TXT works perfectly well in the
    same environment as CREATE/DIR [.SUB] fails in.  I would have thought
    that they would exhibit the same behaviour.  Unless of course (very
    probably) I'm missing something important.
    
    I would appreciate an explanation if anyone is interested in helping me
    understand.
    
    Thanks very much for you help so far.
    
    Chris.
    PS. I will be away for a week from 1200 GMT today, so I wont be able to
    	get back to people who mail or reply here.  Once again, thanks.

    Creating a file just uses the documented process for defaults that we
    know and love: first the filename, then your default spec. Your default
    spec is SYS$DISK:{value-stored-by-$SETDDIR}. Since SYS$DISK fills in
    device and directory, {$SETDDIR} never gets used.
    
    CREATE/DIR presumably special cases dirs that start with [. or <. and
    uses [{$SETDDIR}.what-you-typed] with a default of SYS$DISK. In that
    case  the defaulting process already has a dir, so when it examines
    SYS$DISK it just plucks out the device portion and leaves the rest
    alone.
    
    That's all just a guess, you'll have to read the code (or wait for
    someone who knows the code) if you want to be sure.
    
    Antonio
    	

    re .11
    
    The difference lies within RMS. The behaviour is consistent if
    undesirable and/or confusing.
    
    Suppose my default is TESTLOG:[MUMBLE] where TESTLOG is, say,
    
    DISK1:[GARSON.X],DISK2:[GARSON.Y]
    
    If I parse FOOBAR.TXT then RMS notices that the file spec does not
    include device or directory and hence defaults them from the process
    default, and in particular defaults them both from the searchlist.
    After much hacking, when creating a file (as opposed to searching) this
    will result in DISK1:[GARSON.X]FOOBAR.TXT.
    
    If I parse [anything]FOOBAR.TXT, regardless of whether [anything] is
    relative or absolute, then RMS notices that the file spec does include
    a directory but does not include a device and hence defaults only the
    device from the default, and in particular from the searchlist, and
    when creating a file the result is DISK1:[anything]FOOBAR.TXT. As an
    added complication, while RMS does not default the directory from the
    default in this case, if the file spec includes a relative directory,
    it is treated as being relative to the default directory (rather than
    the piece of the searchlist that contributed the device).
    
    Hence the latter form is quite capable of working. It's just that since
    the resulting file spec is not expected the directory is not likely to
    exist and CREATE will just give an error. Hence even though the real
    difference is in RMS, you will see different behaviour in CREATE/DIR as
    compared with CREATE because CREATE/DIR in noticing that the unexpected
    directory does not exist will go ahead and create it (since that is its
    purpose).
    
    If TESTLOG were defined to contain rooted directories then RMS behaves
    differently (from the non-rooted case) but still consistently. However
    in this case no particular difference will be noted between relative
    and absolute directory spec usage. This case is less likely to cause
    confusion.

    To see that this is all behaviour of RMS rather than CREATE or CREATE/DIR
    do lots of
    
    $ WRITE SYS$OUTPUT F$PARSE("whatever",,,,"SYNTAX_ONLY")