> On 2020-09-20, at 16:44:40, Rob van der Heij wrote: > > On Mon, 21 Sep 2020 at 00:07, Alan Altmark wrote: > >> Where I think it suffered the most is the inability to ACCESS a BFS >> directory like you access an SFS directory, with all that implies. But >> being able to jump into and out of the shell or to use the OPENVM command >> mitigates that to an extent. >> And all the limitations that implies: o It conceals the hierarchic nature of BFS/SFS -- there's nothing like FN FT FM/dir1/dir2 to get at directories under FM. o It limits the BFS namespace to the CMS 8.8.1 convention. (At least it's better than the obsolete 8.3.) And the character set is limited -- think "#include <stdio.h> o Drive letter exaustion. The VMLINK EXEC that does a LINk/ACCESS/run program/RELEASE/DETACH is a desperate circumvention. I've long thought that namespace could immediately be doubled by allowing both uppercase and lowercase drive letters.
> You have pipeline stages to list the BFS directory and to read and write > files in your BFS file space. I don't think it would take you too much > effort to write something similar to the typical "explorer" type user > interface. > Would that deal with classic (pre-Pipelines) utilities such as ASSEMBLE with SYSIN identified with a BFS file and SYSLIB identified with a concatenation of BFS, SFS, and MDFS directories? HLASM (ASMA90) on z/OS nicely handles a concatenation of zFS, PDSE, and PDS directories using allocation (like FILEDEF, only more general). -- gil
