In a recent note, McKown, John said:
> Date: Mon, 23 Oct 2006 19:05:38 -0500
>
> The single biggest problem with the NFS server is that it cannot "serve"
> the same "exported filesystem" in both ASCII and binary modes. It is
> strictly one or the other.
>
I have not experienced this; with the single wildcarded Solaris
mount map entry:
* -rw,soft
mvshost:&",text,lf,nofastfilesize,recfm(vb),lrecl(255),blksize(6160),writetimeout(2),attrtimeout(5),readtimeout(2)"
I can access either:
/proj/mainframe/hlq/name.syslin,binary,noeol/member
... and see the file as binary image, or:
/proj/mainframe/hlq/name.syslin/member
... and see it translated to ASCII. (The label attributes of
FB,80 override those in the mount map, contrary to the behavior
of JCL. But JCL is wrong in this matter.)
That said, the behavior of the z/OS NFS server is cumbersome and
unpredictable; barely acceptable. I often edit with "vi" on
Solaris a SYSEXEC member on z/OS, cycling rapidly through
test/debug/edit/save. But it's about 30 seconds before the
saved changes appear on z/OS.
Often, NFS server leaves an ENQ on the data set, rendering it
inaccessible for the duration. Sometimes the server forgets
to remove the ENQ when the file is closed, and must be recycled
to clear the condition.
If I save a RECFM=FB member which contains a trailing blank on
the client side, NFS server treats it as an I/O error. I
understand the rationale for this; I wish it could be optionally
overridden in the mount options.
The use of ',' as an option separator precludes serving HFS
filesystems in which pathnames contain ','; a convention of
RCS.
Etc.
-- gil
--
StorageTek
INFORMATION made POWERFUL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
