RE: CPY instead of CRTDUPOBJ ? (was: CD Burning software?)

I don't see any additional safeguards in
CRTDUPOBJ OBJ(MYOBJ) FROMLIB(MYLIB) OBJTYPE(*PGM) TOLIB(NEWLIB)
CRTDUPOBJ OBJ(MYOBJ) FROMLIB(MYLIB) OBJTYPE(*FILE) TOLIB(NEWLIB)
CRTDUPOBJ OBJ(MYOBJ) FROMLIB(MYLIB) OBJTYPE(*DTAARA) TOLIB(NEWLIB)

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
CRTDUPOBJ.


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
                    midrange-l






Andy,

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
CHAIN...??
SQL and/or OPNQRYF...?!?

So I had to ask myself, if I didn't know anything about OS/400, would I
take
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
accurate.)


If I didn't have to "chop the wood and carry the water" (ie sweeping,
etc.),
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
to
shop standards, because, IMV, it is the skill-level of the shop (which
varies over time) which ultimately determines which techniques are more
effective.


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
which...


Again, JMNSHO...

jt

| -----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
| > CRTDUPOBJ.
| >
| > 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.