Conference clt::cms

   Here's one way to generate the -CMS-E-NOSRCHLST error...
   OpenVMS Alpha V7.1, but I don't think that matters...

$ cms show vers
CMS Version V3.8-2
$ def foolist sys$sysdevice:[hoffman.SCRATCH.X.],sys$sysdevice:[hoffman.SCRATCH.Y.]
$ sho log foolist
   "FOOLIST" = "SYS$SYSDEVICE:[HOFFMAN.SCRATCH.X.]" (LNM$PROCESS_TABLE)
        = "SYS$SYSDEVICE:[HOFFMAN.SCRATCH.Y.]"
$ cms set lib foolist:[foo]
%CMS-E-NOREF, error referencing FOOLIST:[FOO]
-CMS-E-NOSRCHLST, search lists are not allowed in this context
%CMS-W-UNDEFLIB, library is undefined
$ sho log foolist
   "FOOLIST" = "SYS$SYSDEVICE:[HOFFMAN.SCRATCH.X.]" (LNM$PROCESS_TABLE)
        = "SYS$SYSDEVICE:[HOFFMAN.SCRATCH.Y.]"
$ dir foolist:[foo]

Directory SYS$SYSDEVICE:[HOFFMAN.SCRATCH.X.][FOO]

00CMS.CMS;1         01CMS.CMS;1         01CMS.HIS;1

Total of 3 files.

Directory SYS$SYSDEVICE:[HOFFMAN.SCRATCH.Y.][FOO]

00CMS.CMS;1         01CMS.CMS;1         01CMS.HIS;1

Total of 3 files.

Grand total of 2 directories, 6 files.

$

    Hi Steve,
    
    From what I can tell in looking at the code and its comments, it looks
    like the design decision to disallow search lists was made due to the
    possible confusion that might arise when CMS goes to locate its
    library, history, and element data files. Personally, I'm not sure that
    I would fault their reasoning. Supporting search lists in this way
    could lead to some very difficult support situations at the very least!
    :-)
    
    -- Daryl

Hi Daryl,

If I create 3 libraries and then set library to them:

$ cms set lib [.cmsa], [.cmsb], [.cmsc]
%CMS-I-LIBIS, library is PERFOM_USER8$:[MATTHES.CMSA]
%CMS-I-LIBINSLIS, library PERFOM_USER8$:[MATTHES.CMSB] inserted at end of library list
%CMS-I-LIBINSLIS, library PERFOM_USER8$:[MATTHES.CMSC] inserted at end of library list
%CMS-S-LIBSET, library set
-CMS-I-SUPERSEDE, library list superseded
$ cms sho lib
Your CMS library list consists of:
   PERFOM_USER8$:[MATTHES.CMSA]
   PERFOM_USER8$:[MATTHES.CMSB]
   PERFOM_USER8$:[MATTHES.CMSC]
   

What is the difference between that and what Steve is trying to do ??

Fred

    Hi Fred,
    
    What you're doing is using CMS to define a search list of libraries. No
    problem; CMS knows how to handle that quite well.
    
    What I think Steve is trying to do, on the other hand, is to use DCL to
    define a search list of *files* (which just happen to be CMS libraries,
    hopefully) and then instruct CMS to use that search list to find its
    associated internal files as if it were a single CMS library. What CMS
    would normally do with a search list like this is to treat the search
    list logical as a list of libraries (and not as a single library).
    However, the problem that Steve is encountering stems from the use of
    rooted directory specs. CMS apparently won't allow them in a search
    list even if they're concealed and/or terminal.
    
    -- Daryl
    

:    What I think Steve is trying to do, on the other hand, is to use DCL to
:    define a search list of *files* (which just happen to be CMS libraries,
:    hopefully) and then instruct CMS to use that search list to find its
:    associated internal files as if it were a single CMS library.

   Not quite.

   I'm trying to operate a set of CMS *libraries*, and be able to
   "swap" another complete CMS library into the "front" of the SET
   LIBRARY command for testing or similar purposes.  I'm looking
   to use a searchlist logical name for this, as that's what
   searchlists are for...

   We have hundreds of related CMS libraries for specific products,
   and all related libraries are located in the same root -- it's
   via this root logical name that I'm trying to add a searchlist;
   another translation...

   I'm *not* attempting to "slice and dice" the contents of a CMS
   library across multiple searchlist translations, and I would not
   expect CMS to deal with that situation...

   I'm ending up with a translation hack -- one that finds out which
   translation of the searchlist contains the library, and passes
   just that to the SET LIBRARY command -- which is effectively a
   variation of what was mentioned back in .1.

    Thanks for the clarification, Steve. If you like, I can raise this as a
    wish; I agree that it would be nice if CMS could do this. All that
    would be needed would be to devise a way to allow what you want to do
    while disallowing the potential for spaghetti library syndrome.
    
    -- Daryl

:    Thanks for the clarification, Steve. If you like, I can raise this as a
:    wish; I agree that it would be nice if CMS could do this...

    Please do.

:  ...All that would be needed would be to devise a way to allow what you
:  want to do while disallowing the potential for spaghetti library syndrome.

    Without looking at the CMS code, I'd base the location of the rest
    of the library off the returned path to the root 01CMS.CMS file.
    (RMS can quite easily return this information via the RSA/ESA buffers
    and associated pointers, and would thus be able to pass it back where
    CMS can later use it...)

>Please do.
    
    Done. This is CMS wish #68.
    
>Without looking at the CMS code, I'd base the location of the rest of the
>library off the returned path to the root 01CMS.CMS file. (RMS can quite
>easily return this information via the RSA/ESA buffers and associated
>pointers, and would thus be able to pass it back where CMS can later use
>it...)
    
    Actually, if I'm understanding you correctly, in this kind of situation
    all we want is for CMS to look at only the first element in the search
    list to resolve its file references; the rest of the list should be
    ignored. How difficult this would be to implement would depend on the
    pains taken by the original developers to preclude the use of
    unqualified rooted logicals in search lists.
    
    -- Daryl

:    Actually, if I'm understanding you correctly, in this kind of situation
:    all we want is for CMS to look at only the first element in the search
:    list to resolve its file references; the rest of the list should be
:    ignored. How difficult this would be to implement would depend on the
:    pains taken by the original developers to preclude the use of
:    unqualified rooted logicals in search lists.

   CMS would need to perform a standard RMS file access based on the
   specification -- if a searchlist, RMS would implicitly look for the
   specified file in each translation of the searchlist until a match
   is found or until no more translations are available.  On a match,
   CMS would then need to use the RMS-returned device and directory
   specification for all subsequent library accesses.

   In other words, what I'm after might _not_ have the matching entry
   in the first translation of the searchlist...  (That's not usually
   how one uses a searchlist...  For a more general example, consider
   how OpenVMS uses the SYS$SYSROOT searchlist to locate node-specific
   (SYS$SPECIFIC) files in preference to VMScluster-common (SYS$COMMON)
   files, but will transparently use files in SYS$COMMON if no files in
   SYS$SPECIFIC are matched...)

    Ah, yes, of course. Sorry for not grasping this sooner. :-)
    
    -- Daryl