Shmuel Metz (Seymour J.) wrote:
Ok. If you say so. What was the first IBM utility?
I don't know[1] what the first IBM utility was that did a dynamic allocation,
but it wasn't IEHMOVE, because IEHMOVE did no such thing[2]. IEHMOVE was
documented as requiring a DD statement with unit, volume and
In fact Shmuel is, as so often, quite wrong.
IEHMOVE did require a DD statement for the target, move-to dataset;
and I did not, of course, say that it did not.
It did not, however, move the source dataset directly to this target.
Instead it allocated storage for a very different
In
CAE1XxDHzjQRW9FomT+2W_+ZM7B4MoT=iynf3jyrgj5xa0wh...@mail.gmail.com,
on 09/23/2013
at 06:09 AM, John Gilmore jwgli...@gmail.com said:
Instead it allocated storage for a very different
.,, target dataset dynamically.
I believe that most posters in this thread
John Gilmore wrote:
IEHMOVE did require a DD statement for the target, move-to dataset; and I did
not, of course, say that it did not.
It did not, however, move the source dataset directly to this target. Instead
it allocated storage for a very different
.,, target
On 9/23/2013 6:33 AM, Elardus Engelbrecht wrote:
Interesting. I think I also observed failed moves, but can't remember the fine
details. What RC and messages did it gave in such cases?
The only error, but not RC, I remember vividly is the case where a PDS
didn't have enough directory blocks
Gerhard Postpischil wrote:
The only error, but not RC, I remember vividly is the case where a PDS didn't
have enough directory blocks to add another member, did the add to the
directory anyway, causing the last name to be dropped from the directory. This
was particularly annoying when doing a
Gerhard is right in the sense that the asterisks-and-dots DSNAME could
sometimes be shorter. There were, however, circumstances in which
multiple-asterisk prefixes, infixes, and suffixes did occur.
I suspect that his homegrown utility scratched instances of such
datasets rapidly enough to make
On Mon, 23 Sep 2013 09:08:25 -0400, Gerhard Postpischil wrote:
...
And I think Mr. Gilmore had too many asterisks. The pattern I recall was
to prepend *. until a unique name resulted (IIRC, giving things like
*.*.*.jobname.other). I had a home-grown utility, run daily, that
scratched temporary
Historically, the use of a DSN{AME]= value like
*.*.GUBBINS
was not possible for an ordinary application programmer, whose JCL
would have been rejected as in error if it had contained such a DSN=
value. Such practices were once common for member names too. IBM for
long distributed CICS
On 9/23/2013 11:07 AM, John Gilmore wrote:
Historically, the use of a DSN{AME]= value like
*.*.GUBBINS
was not possible for an ordinary application programmer, whose JCL
would have been rejected as in error if it had contained such a DSN=
value.
Sorry to disagree, but application
On 9/23/2013 10:27 AM, Paul Gilmartin wrote:
Nowadays, might a viable practice be to scratch anything
that's neither catalogued nor allocated?
I didn't want to write a monograph, but keep the response brief. The
scratch program in question considers the (installation's)
classification of the
I was not using the word 'ordinary' in a pejorative or even
deprecatory way. I intended only to exclude very savvy people writing
application code in assembly language and their like.
I was at least half-aware of the DOS-compatibility quote-framed DSNAME
value loophole, but if I remember
In
2372770761776465.wa.elardus.engelbrechtsita.co...@listserv.ua.edu,
on 09/19/2013
at 01:19 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za
said:
Ok. If you say so. What was the first IBM utility?
I don't know[1] what the first IBM utility was that did a dynamic
allocation, but it
Shmuel Metz (Seymour J.) wrote:
John Gilmore said:
Moreover, it had some interesting design features. It was the first IBM
utility that allocated and used a dataset without having a JCL DD statement
for it available.
No.
Ok. If you say so. What was the first IBM utility?
Groete / Greetings
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mark Zelden
Sent: Tuesday, September 17, 2013 9:39 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBCOPY - MOVE
On Tue, 17 Sep 2013 12:21:06 -0700, Jon Perryman jperr
On Wed, 18 Sep 2013 13:49:11 +0200, Thomas Berg thomas.b...@swedbank.se wrote:
Plus that the point of IEBCOPY - at least for me - would be performance. It
happens that I need
to move a selected group of members repeatedly between many (and large)
PDS(E)'s.
So you actually have a good
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Mark Zelden
Sent: Wednesday, September 18, 2013 3:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBCOPY - MOVE
On Wed, 18 Sep 2013 13:49:11 +0200, Thomas Berg
thomas.b
On Wed, 18 Sep 2013 15:30:14 +0200, Thomas Berg thomas.b...@swedbank.se wrote:
Moving should come naturally together with copy...)
Exactly how someone new(ish) to the platform would see it. I've just always
accepted that IEBCOPY didn't do that and I needed another job step to
do the delete.
Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Ed Gould
Sent: Wednesday, September 18, 2013 6:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: IEBCOPY - MOVE
Mark,
I had a discussion at SHARE (long time ago grant you) with an IBM type.
I think I
Mark,
I had a discussion at SHARE (long time ago grant you) with an IBM type.
I think I remember this from the discussion.
IEBCOPY is for copying
COPY does not delete the input as it is a copy.
The design was never meant for moving, ie copy then deleting the
source member.
END
On Wed, 18 Sep 2013 11:52:02 -0500, Ed Gould wrote:
Mark,
I had a discussion at SHARE (long time ago grant you) with an IBM type.
I think I remember this from the discussion.
IEBCOPY is for copying
COPY does not delete the input as it is a copy.
The design was never meant for moving, ie copy
In
cae1xxdhg5hqaoa9r7aod0fisynm77e7coyv_e88rp0xzkah...@mail.gmail.com,
on 09/17/2013
at 10:07 PM, John Gilmore jwgli...@gmail.com said:
Moreover, it had some interesting design features. It was the first
IBM utility that allocated and used a dataset without having a JCL DD
statement for it
Does anyone know if there has ever been a requirement to support MOVE as
in COPY + DELETE in IEBCOPY like ISPF move does?
A newbie asked me about this today. It would be nice I suppose. Instead I
pointed him to PDS86, IDCAMS (yuck) or IEHPROGM (double yuck) as a
way to delete the members after
If you have the ISPF Productivity Toolkit'
http://www.redbooks.ibm.com/abstracts/tips0936.html installed, then you can use
it's batch utility.
Alternatively and free, it would very easy to write a REXX exec using ISPEXEC
LMMOVE and running a batch ISPF job.
Jon Perryman.
On 17 September 2013 15:01, Mark Zelden m...@mzelden.com wrote:
Does anyone know if there has ever been a requirement to support MOVE as
in COPY + DELETE in IEBCOPY like ISPF move does?
A newbie asked me about this today. It would be nice I suppose. Instead I
pointed him to PDS86, IDCAMS
On Tue, 17 Sep 2013 16:24:10 -0400, Tony Harminc t...@harminc.net wrote:
On 17 September 2013 15:01, Mark Zelden m...@mzelden.com wrote:
Does anyone know if there has ever been a requirement to support MOVE as
in COPY + DELETE in IEBCOPY like ISPF move does?
A newbie asked me about this
Chuckle
Sorry how about IEHMOVE :-)
Ed
On Sep 17, 2013, at 2:01 PM, Mark Zelden wrote:
Does anyone know if there has ever been a requirement to support
MOVE as
in COPY + DELETE in IEBCOPY like ISPF move does?
A newbie asked me about this today. It would be nice I suppose.
Instead I
On 17 September 2013 16:41, Mark Zelden m...@mzelden.com wrote:
On Tue, 17 Sep 2013 16:24:10 -0400, Tony Harminc t...@harminc.net wrote:
IEHMOVE. Heh...
Does the HEH mean you are joking or IEHMOVE is a joke?
I kind of thought the one Heh... would do for both.
No, it can't be used for this
On Tue, 17 Sep 2013 12:21:06 -0700, Jon Perryman jperr...@pacbell.net wrote:
If you have the ISPF Productivity Toolkit'
�http://www.redbooks.ibm.com/abstracts/tips0936.html�installed, then
you can use it's batch utility.
Alternatively and free, it would very easy to write a REXX exec using
IEHMOVE had/has some well-known foibles that could not be ignored
without very disagreeable consequences. If you knew about them you
could avoid these consequences; and it was heavily used, e.g., in
SYSGENS, in spite of its deficiencies.
Moreover, it had some interesting design features. It
30 matches
Mail list logo
