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 correct
On Mon, 23 Sep 2013 13:08:01 -0400, Gerhard Postpischil wrote:
>
>Sorry to disagree, but application programmers had wide leeway in
>creating "funny" names. For DOS compatibility, a DSN was allowed to be
>quoted, and could contain a number of special characters that would fail
>in JCL unquoted. Wit
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
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 programmers
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 materia
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 tempora
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 th
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
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 t
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
>.,, tar
In
,
on 09/23/2013
at 06:09 AM, John Gilmore said:
>Instead it allocated storage for a very different
>.,, target dataset dynamically.
I believe that most posters in this thread interpreted "allocation" as
referring to the Allocation component of the operating sys
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
.
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
In
<2372770761776465.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>,
on 09/19/2013
at 01:19 AM, Elardus Engelbrecht
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 wasn't IEHMOVE, because IEHMOVE
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 / Gre
In
,
on 09/17/2013
at 10:07 PM, 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.
>it has always had a bad rap.
It earned it.
--
Shmuel (Sey
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
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 co
Original 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 SHA
On Wed, 18 Sep 2013 15:30:14 +0200, Thomas Berg 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.
Mark
--
Mark Zelden - Z
> -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
On Wed, 18 Sep 2013 13:49:11 +0200, Thomas Berg 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 business case!
I pos
> -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:
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 was
On Tue, 17 Sep 2013 12:21:06 -0700, Jon Perryman 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 ISPEXEC
>LMMOVE an
On 17 September 2013 16:41, Mark Zelden wrote:
> On Tue, 17 Sep 2013 16:24:10 -0400, Tony Harminc 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 function. Even the functi
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.
Inst
On Tue, 17 Sep 2013 16:24:10 -0400, Tony Harminc wrote:
>On 17 September 2013 15:01, 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 nic
On 17 September 2013 15:01, 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
> pointed him to PDS86, IDCAMS (yuck) o
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.
>
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 a
31 matches
Mail list logo
