Reading between the lines and drawing some conclusions...
You have several service machines that have some cylinders of dedicated
minidisk space and write output files.
From a later email, your shop uses SFS, but doesn't want you to use it for
the LARGE amount of space that is currently dedicated to these service
machines.
I'm told I can't have it for these (whole pack) volumes. I'm not sure of
the
reasons. (WAG: Are there old technology disks that can't be converted to
SFS?)
(The implication (to me) is that you could have it for smaller minidisks,
but I may be reading too much into your words.)
Is it possible that your shop is falsely concerned about the amount of space
that will be needed for your SFS usage? The minidisks used for the output
files are likely over allocated to allow for size variations, so SFS may
return some space for you (some of which you will have to use for the SFS
control minidisks). You should get a reason for your shop not allowing the
use of SFS. Maybe you can allay their fears. (No, to the WAG, AFAIK;
someone else should answer that definitively.) Naturally, there might be a
cutover period where a larger amount of disk space would be needed, but you
should be able to work through that without having to double the space
allocated. (Again, I'm assuming that there is a space concern.)
The use of the reader doesn't sound appropriate. The large minidisks
implied suggests a high volume of write activity that would probably not
perform well. (At least, not as well as SFS.)
As others have said, SFS sounds appropriate. If there are concerns about
the performance of SFS, at least get that statement from your shop. Without
knowing why they are opposed to it, you can't build a justification.
While you are at it, some clarification of the current activity would also
help, to better understand the problem. Actually, why isn't the current
state (writing to separate minidisks) no longer acceptable? What are they
trying to achieve by combining them (space savings ;-) ? Or improved
cleanup (another reason for SFS, IMO)? Easier browsing (put the files into
directories named after the originating service machines and it is easy to
browse with DIRLIST)? This last (separate directories) also alleviates any
duplicate filename conflict problems that other solutions might have.
----- Original Message -----
From: "Ian S. Worthington" <[EMAIL PROTECTED]>
To: <IBMVM@LISTSERV.UARK.EDU>
Sent: Tuesday, May 01, 2007 1:00 PM
Subject: Re: Link Multiple Write safely
That's interesting, but conflicts with what some other folks have said here
earlier.
We are under CMS, and I don't want to do simultaneous update to a single
file,
just allow several service machine to write their output files to single
location, which requires a mw-tolerant directory.
Apparently we can't convert the minidisks we're using to SFS.
NFS, as mentioned earlier might be an option: I'm trying to find out if its
enabled.
ian
------ Original Message ------
Received: Tue, 01 May 2007 05:29:09 PM BST
From: "Schuh, Richard" <[EMAIL PROTECTED]>
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Link Multiple Write safely
There is a very big one at this shop that is mode 6, and has been shared
for the 9+ years that I have been here and, I think, about 6 years
before that. With mode 6, you can update in place so long as you do not
change the record length of an existing record. We have a source control
system that uses ISPF panels that requires that all users get the disk
having this pseudo maclib MW.
In any event, the updating of a record in place requires no changes that
will corrupt the disk if it is MW by several users, in our case, over
50, at the same time. So if that is how you intend to use the disk, MW
is perfectly safe under CMS.
Regards,
Richard Schuh
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On
Behalf Of Ed Zell
Sent: Tuesday, May 01, 2007 9:06 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Link Multiple Write safely
> Mode 6 files can be shared so long as the software takes
> care not to have record collisions. ISPF handles sharing
> its fake MACLIBs that way under CMS.
I don't think this is the case. None of our ISPF MACLIB's
are file mode 6.
I was under the impression that ISPF handles sharing by forcing
all updates to go through the ISPVM virtual machine. But I
could be wrong (as has happened many times in the past!).
Ed Zell
Illinois Mutual Life
(309) 674-8255 x-107
.
CONFIDENTIAL NOTICE: This communication, including any attachments, is
intended only for the use of the individual or entity to which it is
addressed and contains information which may be confidential. If you
are not the intended recipient, any distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, notify the sender immediately, delete the
communication and destroy all copies. Thank you for your compliance.
=
