In a recent note, Kenneth E Tomiak said:
> Subject: Re: ftp of exclusively used Member
>
> 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.
>
Those rules are described in:
Title: z/OS V1R7.0 ISPF Planning and Customizing
Document Number: GC34-4814-04
A.0 Appendix A. ISPF Enqueue Processing for Data Integrity
A.3 Member Name Enqueue
They are available for other tasks to use. Admittedly:
o I do not know that they are formally supported as Programming Interfaces.
o A prior section states that non-ISPF tasks must use exclusive SYSDSN ENQ
when updating a data set (but it makes no such statement about reading).
o There was a documented change in the convention several releases ago.
> 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.
>
When I need to do that, I use ISPF LM services in batch, as that financial
firm should also have done.
> 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.
>
Red herring. I also doubt (I haven't checked) that RFC 959 mentions
trying to work with z/OS SYSDSN enqueues.
> 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.
>
Red herring, again. It's the responsibility of the implementor of an FTP
server or client for a particular system to do what that system requires to
insure integrity. RFC 959 is properly silent on the method. The ENQ that
failed on an FTP GET was on SPFEDIT, as I reported, not on SYSDSN. So,
apparently FTP server is aware of and observes ISPF's integrity conventions.
> 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.
>
This protocol guarantees that no reader will observe a PDS member during
updating; no ENQ is necessary to assure a valid read. FTP server is being
unnecessarily restrictive by enforcing an SPFEDIT ENQ during a GET.
> 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.
>
z/OS assures integrity for PDSE directories and perhaps, but only recently,
for PDS directories. But, of old, it was easy to corrupt a PDS directory.
Heck, it's still easy: allocate the PDS with overriding DSORG=PS and do
a write to it. UNIX has always assured the integrity of its directories
against updates by nonprivileged users. MVS was far inferior; it's only
lately that z/OS catching up.
> But please, do not ask z/OS to circumvent data integrity.
>
The integrity mechanism is optional: z/OS still allows any two users to
allocate a data set with DISP=SHR and update it, subject only to RACF rules;
same as UNIX. Both systems have rules; more properly guidelines, since
buth systems allow them to be broken easily.
-- 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
