ISPF is smart enough to know what ISPF is doing so you can get away with browsing and viewing the contents of an ISPF member being edited. Right up until they perform a save. If you were able to try to view the member while the pds was being updated you would have a problem. Obviously, you would not be able to swap your screen and try to view the same member while you were also doing a save. But another task not following the rules could. The rules are there for data integrity.
The problem with a PDS, not PDSE, comes when an ISPF task and a non-ISPF task try to update the same PDS. PDS, not just member. I did some work for a financial firm that every few months complained their batch job was not working. Turned out they were using DISP=SHR to put a member in a PDS their developers were regularly using. Every now and then, in that tiny window of opportunity, the batch job would try to update the pds and the same moment a develoepr was trying to save their work. During the process to create the member they both get the same TTR and start writing their data. Whoever is slower is the winner because they wrote last. The RFC for FTP does not include trying to work with the ISPF enqueues. Therefore, exclusive use to a non-ISPF task means it is busy, try again later. Funny you disagree, look at any operating system and any database and you find some form of a locking mechanism has been built to prevent access whlie it is being updated. And yes, they have record level locking when you want partial access to a database. But you do not get to read a record while it is being written out, you wait. So I still say, it is poor design to be trying to get or put a member that someone is editing. Code a smart script and try again instead of just stacking some commands and relying on luck for it to work. I preach what I practice. DISP=OLD exists for a reason. It may slow down your batch cycle, but then I do not want to lose money from my account because someone did not understand the importance of an enqueue. Since you won't get the RFC for FTP changed to check ISPF internal enqueues, maybe you can get ISPF to not take the exclusive lock until it really is writing. Who cares if two people both get the member in edit as long as ftp can get it at anytime. And whoever is slower, wins. Your testing shows that another user can not get the same member you can get. How is that different than ftp can not get the same member you can get. It is not. Since you have the exclusive lock you can get it as many times as you can nest view, browse or start more sessions. You have it, you have it. ISPF does not do an update-in-place to a PDS. It requests the next available TTR, does its writes, and updates the directory. Until the directory is updated with the new TTR your subsequent views and browses get the still-current TTR and you get the data at that TTR. And until the next available TTR is updated to point just past the last member, a batch job with DISP=SHR that writes a new member will get the same TTR ISPF is using to save your member. If you really need to ignore data integrity, use UNIX. There you can have multiple writers and readers using files as long as they do not all follow the UNIX locking mechanisms. As long as any one process ignores the locking, they can read or write a file some other process has locked. This falls under better the better design principle, if you truly do not care what data you get, then put your data under z/OS UNIX, either an HFS or zFS based filesystem and do not use applications with locking. But please, do not ask z/OS to circumvent data integrity. On Sat, 5 May 2007 10:19:32 -0600, Paul Gilmartin <[EMAIL PROTECTED]> wrote: >In a recent note, Kenneth E Tomiak said: > >> Date: Sat, 5 May 2007 08:57:16 -0500 >> >> The scarier part is someone suggested how to update an exclusively held >> member. The answer is, if you want to introduce data integrity problems to >> your system, please do not ask us for help. There is no good reason to try to >> get or put a member that is in use. z/OS 1.8 Communication Server comes >> with a REXX API to FTP. If you are using a dumb, or blind, script to transfer a >> file then you should upgrade and write some intelligent code to attempt the >> transfer, when you get the error that it is held, let logic dictate how long your >> code waits before trying again or giving up. A better design would have you >> figuring out who is editing a member you need to transfer. Something is wrong >> with your design. >> >I disagree. ..... snip .... >-- 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
