Re: IEBCOPY - MOVE
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 disposition; it used OPENJ to access individual data sets on the volume. Shmuel, thank you very much for your kind and interesting answer. Much appreciated. :-) [1] I suspect that it was SMP. Those OCO thing makes guessing more difficult... ;-) [2] In fact, dynamic allocation didn't yet exist. Yes, indeed, I remember that dynamic allocation was not there at those times. Thanks again Shmuel! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 .,, target dataset dynamically. Only after it had notionally completed its move to that interim, dynamically allocated dataset successfully did it rename it and scratch the source dataset. The problems were, to adopt part of one of Shmuel's overused locutions, in the details. In particular, IEHMOVE sometimes scratched the source dataset in circumstances in which the target dataset was unavailable/unusable. Shmuel has a long history of partial, selective quotation asnd equally selective fixation on irrelevant detail in orfer to make one of his debater's points. By now he is a fixture here. I should miss his posts if they ceased to appear on IBM-MAIN. They do, however, need to be understood for what they are, viz., the now sometimes ill-considered work of a gadfly. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 interpreted allocation as referring to the Allocation component of the operating system rather than to DADSM. But then, you knew that. Shmuel has a long history of partial, selective quotation asnd equally selective fixation on irrelevant detail in orfer to make one of his debater's points. Au contraire, you have a long history of misrepresenting what I and others have written. They do, however, need to be understood for what they are, Which you are incapable of. Whether you elieve it or not, the great john gilmore is capable of being wrong. the now sometimes ill-considered work of a gadfly. PKB. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 dataset dynamically. Only after it had notionally completed its move to that interim, dynamically allocated dataset successfully did it rename it and scratch the source dataset. I have observed that behaviour for large datasets on a slow system. You could actually see that temp dsn. Thanks John. Much appreciated. In particular, IEHMOVE sometimes scratched the source dataset in circumstances in which the target dataset was unavailable/unusable. 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? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 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 sysgen, as the ruined data set (usually LINKLIB or SVCLIB) became useless, and the sysgen had to be restarted from scratch, with larger allocations. Back then we had a practice of taking values from the storage estimates book, and increasing them at least three-fold. 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 data sets, and *. was one of the patterns it looked for, in addition to the more common SYSn. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 sysgen, as the ruined data set (usually LINKLIB or SVCLIB) became useless, and the sysgen had to be restarted from scratch, with larger allocations. Urrhhh! Lots of [exciting] pain! ;-) At least I'm not alone with that pain. [1] ;-D Backup + checkpointing plans won't help you here, because you BUILD things up from scratch... Back then we had a practice of taking values from the storage estimates book, and increasing them at least three-fold. And still run out of space? I usually used values of 10 times of everything (primary, secondary, dir space, etc). Other reason is that those estimates are sometimes based on a specific device and specific defaults, not very helpful, mind you... After all setup is completed, I just trimmed excess space just to keep my storage admin guy happy. ;-) Groete / Greetings Elardus Engelbrecht [1] - I was at one stage unfortunate not to able to claim overtime worked just because of that disaster where I had to redo everything after hours (no SMP/E), because the project was behind schedule and I have a *grumpy* boss. :-/ Fun, big fun... ;-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 the appearance of their more baroque forms unlikely in his environment(s).In more cluttered ones they became ever more baroque in pursuit of uniqueness. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DSNAME Syntax (was: IEBCOPY - MOVE)
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 data sets, and *. was one of the patterns it looked for, in addition to the more common SYSn. Nowadays, might a viable practice be to scratch anything that's neither catalogued nor allocated? Has IBM published a warning that such data set names are reserved for IBM, and not to be used by application programmers, or does IBM rely on common knowledge of programmers to avoid them? Is there a similar part of the name space reserved for ISVs? I know that in UNIX there is a convention (not published as a standard?) that pathnames incorporating a registered domain name (rewritten big-endian) are reserved for the registrant. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
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 materials as PDS members having formally illicit
names like MCGUFFN¢. The motivation was, of course, to avoid names
that conflicted with those already used by a customer.
The notorious retention date of 99.365 is another, slightly different,
example of the misuse of as coding scheme to encode information it was
not designed to represent.
I should like to think that we were now q
On 9/23/13, Paul Gilmartin paulgboul...@aim.com wrote:
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 data sets, and *. was one of the patterns it looked
for, in addition to the more common SYSn.
Nowadays, might a viable practice be to scratch anything
that's neither catalogued nor allocated?
Has IBM published a warning that such data set names
are reserved for IBM, and not to be used by application
programmers, or does IBM rely on common knowledge
of programmers to avoid them?
Is there a similar part of the name space reserved for
ISVs? I know that in UNIX there is a convention (not
published as a standard?) that pathnames incorporating
a registered domain name (rewritten big-endian) are
reserved for the registrant.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
John Gilmore, Ashland, MA 01721 - USA
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
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 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. With a little more work, any character combination
could be used in a DSN when allocating with SVC 32.
Gerhard Postpischil
Bradford, Vermont
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
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 volume, the allocation or last use date, etc. Some volumes are classified as customer owned, and those either do not get cleaned automatically, or only on request. Storage packs may be used only with known high-level indices, etc. Sort work packs get cleaned unconditionally when not in use, ad nauseam. An uncataloged data set on an SMS volume is a serious problem, better examined on a case by case basis. On a non-SMS volume it's fair game if it has a temporary name, or if it hasn't been used in some time we try to locate the owner and find out what the intent is. Conversely a catalog entry for a non-existent data set is removed during weekly clean up. Has IBM published a warning that such data set names are reserved for IBM, and not to be used by application programmers, or does IBM rely on common knowledge of programmers to avoid them? I'm not aware of a formal declaration, but the format is explained in several publications. But I have run into an analogous problem with unlabeled tapes. IBM documentation (Tape Labels?) states that the system will generate unique serials for NL tapes, in the form Ln, but I've never met a customer who's aware of that. In one case a customer, working for a firm whose name started with L, had a tape overwritten due to bad naming. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DSNAME Syntax (was: IEBCOPY - MOVE)
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 correctly there were even more limitations on the use of these quote-framed DSNAME values than Paul Gilmartin has set out, including some contexts in which they could not be used at all. --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 wasn't IEHMOVE, because IEHMOVE did no such thing[2]. IEHMOVE was documented as requiring a DD statement with unit, volume and disposition; it used OPENJ to access individual data sets on the volume. [1] I suspect that it was SMP. [2] In fact, dynamic allocation didn't yet exist. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
-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...@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 ISPEXEC LMMOVE and running a batch ISPF job. Jon Perryman. Not nearly as easy as PDS86, but that wasn't my question. 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. Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 business case! I posted the question because I was asked by an off shore person. To them it seemed logical that there should be a *standard* utility to do this and I can see why they think that. I've never really thought about it but after I was asked I could think of many times it would have come in handy. At my current shop, and some others I have been at, changes that go in during a maintenance window are preferred to have batch jobs pre-staged. So instead of step 10 in the implementation plan being use ISPF to copy / move / rename PDS members from a to b it should be in a batch job. It ends up being quicker and less error prone. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
-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...@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 business case! I posted the question because I was asked by an off shore person. To them it seemed logical that there should be a *standard* utility to do this and I can see why they think that. I've never really thought about it but after I was asked I could think of many times it would have come in handy. At my current shop, and some others I have been at, changes that go in during a maintenance window are preferred to have batch jobs pre-staged. So instead of step 10 in the implementation plan being use ISPF to copy / move / rename PDS members from a to b it should be in a batch job. It ends up being quicker and less error prone. The last point isn't the least one... ! (Another point - design - is that when you have a tool that handles PDS members why restrict it to just copy (+rename) ? Moving should come naturally together with copy...) Best Regards Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
Maybe it's time for an IEBPDS or IEBMBR utility ? :) (Or if we want follow the current logic: IEBMOVE ?) Med Vänlig Hälsning Thomas Berg ___ Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ) -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 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 conversation--- I think a solid easily made requirement for a separate utility for moving members. ie a replacement for IEHMOVE (shudder) can be made. Ed On Sep 18, 2013, at 8:36 AM, Mark Zelden wrote: 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. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 conversation--- I think a solid easily made requirement for a separate utility for moving members. ie a replacement for IEHMOVE (shudder) can be made. Ed On Sep 18, 2013, at 8:36 AM, Mark Zelden wrote: 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. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 then deleting the
source member.
END conversation---
I think a solid easily made requirement for a separate utility for
moving members. ie a replacement for IEHMOVE (shudder) can be made.
Why not an enhancement to IEBCOPY. DRY.
But what about ISPF LM services in batch? Is the COPY/MOVE
utility readily available that way? And doesn't ISPF nowadays
employ IEBCOPY for copying. (I find some 30-year samples
suggesting that SPFCOPY exist{s|ed} as an interface to IEBCOPY).
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 available. No. it has always had a bad rap. It earned it. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IEBCOPY - MOVE
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 the copy. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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. From: Mark Zelden m...@mzelden.com Does anyone know if there has ever been a requirement to support MOVE as in COPY + DELETE in IEBCOPY like ISPF move does? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 (yuck) or IEHPROGM (double yuck) as a way to delete the members after the copy. IEHMOVE. Heh... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 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 the copy. IEHMOVE. Heh... Does the HEH mean you are joking or IEHMOVE is a joke? No, it can't be used for this function. Even the functions it does work for (moving a PDS plus merge) don't work with SMS controlled DASD. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 pointed him to PDS86, IDCAMS (yuck) or IEHPROGM (double yuck) as a way to delete the members after the copy. Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 function. Even the functions it does work for For some value of work. (moving a PDS plus merge) don't work with SMS controlled DASD. That wasn't a requirement you mentioned. Regardless, the whole notion of move invites problems. And IEHMOVE in particular has had a long history of deleting source datasets that it thought or claimed it had first successfully copied. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 ISPEXEC LMMOVE and running a batch ISPF job. Jon Perryman. Not nearly as easy as PDS86, but that wasn't my question. Thanks, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
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 the first IBM utility that allocated and used a dataset without having a JCL DD statement for it available. Moreover, in those pre-OCO days one could look at the code to see how it did this. I should not today recommend its use to the uninitiated, but it has always had a bad rap. -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
