In , on 05/24/2010
at 07:50 AM, Paul Gilmartin said:
>The old name goes away immediately, even if someone else is using the
>file arbitrarily long.
To be more precise, a program that opened the old name will continue
using the old inode instead of the inode for the next file created
with the
On Mon, May 31, 2010 at 11:26 PM, Paul Gilmartin wrote:
>
>
> In the case of the C RTL, the programmer should be given the
> choice of ENQ SYSDSN EXC or ISPF serialization which has an
> excellent track record when used properly.
>
> -- gil
>
>
Paul,
I agree!
Kirk
-
On Mon, 31 May 2010 17:13:27 -0400, Shmuel Metz (Seymour J.) wrote:
>In , on 05/24/2010
> at 07:41 AM, Paul Gilmartin aid:
>
>>ISPF also does ENQ SYSDSN SHR, and for load modules, SYSIEWLP, so it
>>provides protection from programs not doing the same thing.
>
>No, only from programs allocating e
In , on 05/24/2010
at 07:41 AM, Paul Gilmartin said:
>ISPF also does ENQ SYSDSN SHR, and for load modules, SYSIEWLP, so it
>provides protection from programs not doing the same thing.
No, only from programs allocating exclusive. It doesn't protect from
programs using DISP=SHR without the ISPF
On Sun, 23 May 2010 20:06:56 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>o rename() is atomic.
>
>FSVO atomic. The old name does not go away immediately if someone else
>is using the file. That's often what you want, but not always.
>
The old name goes away immediately, even if someone else is using
On Sun, 23 May 2010 20:01:50 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>The clean way forward was devised by [I]SPF some time ago in the
>>SPFEDIT ENQ.
>
>No.
>
>>I believe it assures data integrity;
>
>It doesn't.
>
>>NFS server and FTP server (others?)
>>use the technique to cooperate with ISPF.
In , on 05/21/2010
at 07:46 AM, Paul Gilmartin said:
>The clean way forward was devised by [I]SPF some time ago in the
>SPFEDIT ENQ.
No.
>I believe it assures data integrity;
It doesn't.
>NFS server and FTP server (others?)
>use the technique to cooperate with ISPF.
K3wl. What if it isn'
In , on 05/21/2010
at 03:10 PM, Paul Gilmartin said:
>POSIX rename() has some properties remarkably suited to this purpose:
And some not so suited.
>o rename() is atomic.
FSVO atomic. The old name does not go away immediately if someone else
is using the file. That's often what you want, b
There are sensible error messages given by a z/OS subsystem? We'll blow me
over with a feather!
:-(
On 5/21/2010 at 12:25 AM, in message
, "Hunkeler
Peter (KIUP 4)" wrote:
>> o Kudos to FTP server -- the messages are excellent.
>
> Could only be topped if the message would the who the
> holder
On Fri, 21 May 2010 13:41:25 -0500, Al Cole wrote:
>In all of the FTP data processes that I create, I require that the users edits
>and maintains the data file in their application directories.
>When they have completed creating the file, the user or the application will
>move the file to an FTP
>So how is MVS supposed to distinguish between an instance of someone who
>shouldn't be editing the data or has no intention of saving vs. someone who is
>editing critical changes that must be saved before the next remote GET should
>be allowed
Can't do it.
Using EDIT as BROWSE is an educationa
In all of the FTP data processes that I create, I require that the users edits
and maintains the data file in their application directories.
When they have completed creating the file, the user or the application will
move the file to an FTP server. By doing so, the user or application is statin
On Fri, 21 May 2010 10:47:38 -0700, Charles Mills
wrote:
>"Old data" is not a problem. Had he FTPed two minutes earlier he would have
>gotten "old" data. All data is "old" in that it may change at some point in
>the future. The "problem" is only if the user does a "preliminary" save --
>being ca
r having made half of his changes -- and you GET a
version that was never intended to be integral.
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Patrick Lyon
Sent: Friday, May 21, 2010 10:23 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re:
On Fri, 21 May 2010 12:25:00 -0500, Joel C. Ewing
wrote:
>If it is more important that the GET have minimal possibility of failure
>than to get the absolutely latest update, the best option may be to make
>a mirror copy of the data at an agreed on point in time into a dataset
>with restricted RE
On 05/21/2010 11:59 AM, Edward Jaffe wrote:
> Hunkeler Peter (KIUP 4) wrote:
>> Ed: How happy would you be if your automated ftp process successfully
>> replaces the member someone else is editing at
>> the same time. A single SAVE and your successfull ftp isn't
>> worth a dime anymore.
>>
>
>
On Fri, 21 May 2010 09:56:27 -0700, Edward Jaffe
wrote:
>Unless I'm missing something, it seems like any "Joe Blow" goofing
>around and/or with malicious intent can exploit this behavior to "break"
>any process involving remote FTP GET.
>
>--
Edward - Then "any Joe Blow" should not have read ac
Hunkeler Peter (KIUP 4) wrote:
Ed: How happy would you be if your automated ftp process
successfully replaces the member someone else is editing at
the same time. A single SAVE and your successfull ftp isn't
worth a dime anymore.
That is a different scenario entirely. My situation is not a
>>Could only be topped if the message would the who the
>>holder was.
>>
>It does. Re-quoting from the OP:
>
>> is held by: 008F EDJXADM EXCL on SPFEDIT
My appologies go to FTP!
--
Peter Hunkeler
Credit Suisse
--
For IBM-
>Ed's example concerned retrieving the member, not storing it.
It seems this is not my best day for posting. I'll go look
for a new pair of glasses; These seem to blank out words :-)
--
Peter Hunkeler
Credit Suisse
--
For IBM-MA
On Fri, 21 May 2010 04:56:35 -0400, Shmuel Metz (Seymour J.) wrote:
>
>>/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"
>
>>requests EXCL SYSDSN ENQ. I think this misspecification is inherent
>>in the C RTL.
>
>It's not a misspecification. Would you really prefer an ABEND or a
>damaged di
On Fri, 21 May 2010 08:25:58 +0200, Hunkeler Peter (KIUP 4) wrote:
>>Would anyone care to submit a Requirement that ISPF defer
>>requesting the EXCL SPFEDIT until the first SAVE?
>
>I would vote against it. Definitely! If I'm in EDIT, I expect
>that nothing can change the content under the covers,
On Fri, 21 May 2010 08:25:27 +0200, Hunkeler Peter (KIUP 4) wrote:
>>o Kudos to FTP server -- the messages are excellent.
>
>Could only be topped if the message would the who the
>holder was.
>
It does. Re-quoting from the OP:
> is held by: 008F EDJXADM EXCL on SPFEDIT
-- gil
On Thu, 20 May 2010 18:17:18 -0500 Paul Gilmartin
wrote:
:>BTW, how can I interrupt IEBCOPY in this situation. PA1
:>gave me a READY prompt, but when I pressed ENTER the IEBCOPY
:>messages resumed. I finally resigned myself to pressing
:>ENTER until they finished scrolling by.)
Pressing enter
In , on 05/20/2010
at 06:17 PM, Paul Gilmartin said:
>TRANSMIT is a horse of a different choler.
Perhaps, but it doesn't appear to be ignoring DCB attributes.
>TRANSMIT FOO.BAR FILE(PUTDD) OUTDSN(TEMP.FOOXMIT)
What does the TSO command reference say about the semantics of that
command?
In , on 05/20/2010
at 12:28 PM, Paul Gilmartin said:
>And, truly annoying:
>/bin/cp /what/ever "//'SYS2.MVSMODS.CNTL(ISTINCLM)'"
>requests EXCL SYSDSN ENQ. I think this misspecification is inherent
>in the C RTL.
It's not a misspecification. Would you really prefer an ABEND or a
damage
>Would anyone care to submit a Requirement that ISPF defer
>requesting the EXCL SPFEDIT until the first SAVE?
I would vote against it. Definitely! If I'm in EDIT, I expect
that nothing can change the content under the covers, no matter
whether I'm going to actuially change the content or not.
>o Kudos to FTP server -- the messages are excellent.
Could only be topped if the message would the who the
holder was.
--
Peter Hunkeler
Credit Suisse
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send emai
On Thu, 20 May 2010 17:20:49 -0700, Charles Mills wrote:
>> I believe that in this case FTP client either "re-allocat[ed] a
>> clone" or bypassed the allocation and used UNIX system calls to
>> access the related path.
>
>May be. Do you see allocation messages? Do you see any references to
>SYS000
] On Behalf
Of Paul Gilmartin
Sent: Thursday, May 20, 2010 4:17 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP Get Blocked by ISPF EDIT
On Thu, 20 May 2010 14:16:05 -0700, Charles Mills wrote:
>I believe FTP by DD name applies to both GETs and PUTs but only to the
>client end. You cannot do a P
On Thu, 20 May 2010 14:16:05 -0700, Charles Mills wrote:
>I believe FTP by DD name applies to both GETs and PUTs but only to the
>client end. You cannot do a PUT to or a GET from a DD name (only the
>converse). OTOH, I believe it does use the DD allocation rather than
>re-allocating a clone.
>
I j
List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Paul Gilmartin
Sent: Thursday, May 20, 2010 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: FTP Get Blocked by ISPF EDIT
On Thu, 20 May 2010 20:26:57 +0300, Binyamin Dissen wrote:
>On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe wrote:
>
>
On Thu, 20 May 2010 09:44:07 -0700, Edward Jaffe wrote:
>
>125-FTP Server unable to obtain SHARED use of
>SYS2.MVSMODS.CNTL(ISTINCLM) which
>is held by: 008F EDJXADM EXCL on SPFEDIT
>125 Data set SYS2.MVSMODS.CNTL(ISTINCLM) is not available
>550 SYS2.MVSMODS.CNTL(ISTINCLM) used exclusively by some
On Thu, 20 May 2010 20:26:57 +0300, Binyamin Dissen wrote:
>On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe wrote:
>
>:>Did you know that z/OS ftp GET is blocked by ISPF EDIT? =-O
>
>:>ftp> cd 'sys2.mvsmods.cntl'
>:>ftp> get istinclm istinclm.jcltxt
>
>Wouldn't the DDNAME approach work?
>
No, bec
On Thu, 20 May 2010 11:50:43 -0500, McKown, John wrote:
>> -Original Message-
>> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe
>>
>> Did you know that z/OS ftp GET is blocked by ISPF EDIT? =-O
>>
>> This is a little scary since we use ftp all over the place in our
>> automated p
On Thu, 20 May 2010 09:44:07 -0700 Edward Jaffe
wrote:
:>Did you know that z/OS ftp GET is blocked by ISPF EDIT? =-O
:>This is a little scary since we use ftp all over the place in our
:>automated processes!
:>ftp> cd 'sys2.mvsmods.cntl'
:>250 The working directory "SYS2.MVSMODS.CNTL" is a pa
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:ibm-m...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Thursday, May 20, 2010 11:44 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: FTP Get Blocked by ISPF EDIT
>
> Did you know that z/OS ftp GET is bl
Did you know that z/OS ftp GET is blocked by ISPF EDIT? =-O
This is a little scary since we use ftp all over the place in our
automated processes!
ftp> cd 'sys2.mvsmods.cntl'
250 The working directory "SYS2.MVSMODS.CNTL" is a partitioned data set
ftp> get istinclm istinclm.jcltxt
200 Port req
38 matches
Mail list logo
