Wouldn't it be nice to have a file system that worked across ALL OS's VM/CMS, VSE, MVS, LINUX? Oh! Wasn't VSAM supposed to do that? I digress.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Ian S. Worthington Sent: Wednesday, May 02, 2007 3:11 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Link Multiple Write safely I tried that too. No dice. i ------ Original Message ------ Received: From: "Schuh, Richard" <[EMAIL PROTECTED]> To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Link Multiple Write safely > And if worse comes to worse, you could request that a separate SFGS file > pool be built for just your data. > > Regards, > Richard Schuh > > > -----Original Message----- > From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On > Behalf Of Paul B. Nieman > Sent: Wednesday, May 02, 2007 11:00 AM > 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. > > = > __________________________________________________________________ << ella for Spam Control >> has removed VSE-List messages and set aside VM-List for me You can use it too - and it's FREE! http://www.ellaforspam.com
