I don't see any additional safeguards in

That I don't see in
CPY OBJ('/qsys.lib/mylib.lib/myobj.pgm') TODIR('/qsys.lib/newlib.lib')
CPY OBJ('/qsys.lib/mylib.lib/myobj.file') TODIR('/qsys.lib/newlib.lib')
CPY OBJ('/qsys.lib/mylib.lib/myobj.dtaara') TODIR('/qsys.lib/newlib.lib')

Oh wait, you have that pesky DATA(*YES) you have to remember to answer in

Rob Berendt

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
Benjamin Franklin

                    "jt" <jt@ee.net>
                    Sent by:                  To:     <midrange-l@midrange.com>
                    midrange-l-admin@mi       cc:
                    drange.com                Fax to:
                                              Subject:     RE: CPY instead of 
CRTDUPOBJ ? (was: CD Burning software?)

                    12/08/2001 03:09 PM
                    Please respond to


And I think ANYBODY who disagrees with me MUST be a *nix gearhead...;-))

(PLEASE note emoticon...!)

One of the toughest choices all programmers face is when is it worth
learning two similar techniques.  (Not to drift off into another list,
but...) Tables and/or arrays...?  SETLL/READE (same klist) and/or
SQL and/or OPNQRYF...?!?

So I had to ask myself, if I didn't know anything about OS/400, would I
the trouble to learn both CPY and/or CRTDUPOBJ?  From what you just posted,
CPY is more versatile (handles both IFS and CPYF).

However, CPY ignores the advantages of verb/subject command structure, a
consistent approach, and causes excessive potential for errors coding the
object name.  This last is my hangup.

Even more, this documentation is intended for the customer-base, which
largely prefers the traditional commands.  Might be a good survey question
(hint, hint ;-), but I'm fairly sure that even amongst tool vendors, they
prefer the traditional.  IMV, this documentation overlooks who the primary
customer base is...  (And this list is a small subset of those hundreds of
thousands, at that, so a survey here is likely to only be partially

If I didn't have to "chop the wood and carry the water" (ie sweeping,
I'd give an example of proof-positive that I'm not unaware of how personal
preferences factor large in coding...  But I think these things come down
shop standards, because, IMV, it is the skill-level of the shop (which
varies over time) which ultimately determines which techniques are more

But I think personal preference is VERY over-used, and ignores the reality
that there ARE better ways, and worse ways...  Sure there's gradation.. of
course, it's rarely black-and-white.  But there are MORE effective and LESS
effective techniques, although there isn't always agreement on which are

Again, JMNSHO...


| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Andy Nolen-Parkhouse
| Sent: Saturday, December 08, 2001 2:09 PM
| To: midrange-l@midrange.com
| Subject: RE: CPY instead of CRTDUPOBJ ? (was: CD Burning software?)
| David,
| Personal preference strikes me as a good enough reason.  Perhaps also a
| bit of showboating.  Both CPY and CRTDUPOBJ will achieve the same
| result.
| Regards,
| Andy Nolen-Parkhouse
| > Ok, bit of confusion here ... on the above web page they reference
| copying
| > a program ... but they use IFS CPYcommand to do the copy instead of
| > regular
| >
| > Any ideas why?

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.