On Fri, 6 May 2022 12:43:30 +0000, Clifford McNeill wrote:
>IBM's Native American name shall be Broken-Link.
> Cliff
>
Which leads me to wonder, how will DSFS represent a broken
symbolic link in a PDSE member?
On Fri, 6 May 2022 08:46:24 -0500, Bill Schoen wrote:
>>> "Good Job IBM!" "'Bout Damn Time".. but also
>>> "Where's the rest (VSAM, VBS, z/OS to OMVS) ?
>
RECFM=VBS,LRECL=X would seem to be the natural representation
of a file which might contain more than 32760 bytes between LFs.
>At the moment there still is a development team.
>
It seems that for the interim (of possibly arbitrary duration) there's need
for a "DSFS limitations and Restrictions" manual.
Should I expect differences in the outcome of:
cp source //\'my.pdse(member)\' # and
cp source /dsfs/my.pdse/member # ?
(Also, does DSFS obey TSO DSN prefixing?)
What does "some-command >>/dsfs/my.pdse/member" do?
Does it copy to do the append?
Will "some-command >>/dsfs/my.ps.log.file" perform the append
without the ENQ EXC of DISP=MOD?
Suppose a PDSE contains members created by ISPF, with stats,
and others created by (e.g.) IEBGENER with no stats. Will DSFS
fall back to FAMS metadata as NFS does:
<https://www.ibm.com/docs/en/zos/2.2.0?topic=sets-time-stamps-pdss-pdses>?
How consistent will the behavior be among:
o Accessing a PDS(E) as DSFS via ISPF 3.17
o Accessing directly as a DSN via other ISPF services
o Accessing from a (Linux) desktop via NFS.
Case insensitivity is a bane! In some of the instances above,
the user will see member names in UPPER case; in others,
lower. Consistency should prevail, allowing orderly copy/paste
from one member display to a command line.
--
Thanks,
gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
