Since each of the machines is handling only a part of the data, you could have them use FTP to transfer individual files to a central collection point, say the big mdisk currently in use.
Regards, Richard Schuh -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Ian S. Worthington Sent: Wednesday, May 02, 2007 1:10 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Link Multiple Write safely Hi Paul -- Many thanks for your considered note. Our (big) shop does uses SFS, quite a lot. I am in the process of taking a single process that has always used dedicated volumes and splitting it to run in multiple machines (as its now taking too long to finish (several days) and can easily be made to run in parallel). There are clear and obvious benefits, as you and others have discussed, to putting these volumes into a private SFS pool but I've been told it can't be done. The exact reasons have not been shared with me, but I do know a brick wall when I bang my head against one :) So I'm looking for a different approach and a few of the ideas that have been passed around here may, with just a few changes, work well, and can be done without us having to request activities from IBM (and their beleaguered support representative). i ------ Original Message ------ Received: From: "Paul B. Nieman" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Link Multiple Write safely > 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. > > = >
