|
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.