|
jt, As opposed to a reactionary 400 zealot gearhead I presume? ;-) Aside from a brief fling getting Domino to run on Linux, I've no professional experience on UNIX-like systems. Using the example provided by David, I would have used the CRTDUPOBJ command. I don't disagree with your main points, but if two 400 gearheads are to wax rhapsodic over the singular beauty of the native AS/400 command structure, we will accomplish nothing. Except perhaps to cement our reputations as dinosaurs and to alienate those who come to the iSeries platform from other backgrounds. Regarding standards and the use of universal (the entire IFS) naming conventions, I would go with the following: 1) If the objects used are entirely outside of the QSYS file system, use universal naming. There is not much choice here. 2) If the objects used are entirely within the QSYS file system, use the legacy naming conventions and commands. 3) If the objects used are within QSYS as well as other file systems, use your judgment when a choice between equivalent commands is presented. The example cited falls into the third category and I have no problem with it. Because the code requires manipulation of stream files there is no choice but to use universal naming within those chunks of code. Regarding learning two styles of coding and using CPY and CRTDUPOBJ as an example. There is no choice, if a developer is dealing with all aspects of the IFS file system, but to learn to use CPY effectively. I used to agree with your point about the excessive potential for errors in coding object names, but no longer. It was, for me, more a case of lack of familiarity than the awkwardness of universal naming. After the first few tries and frequent consultation of help text, it now makes sense. 'qsys.lib/libname.lib/objectname.objecttype' And if it is a datafile, add 'membername.mbr'. That all makes sense to me and I no longer make silly mistakes, even though it appeared foreign at first exposure. Regarding what the customer-base prefers. I have no idea. I do know that the future of the platform and the growth of market share depends upon its success in selling systems using the entire IFS. IBM's greatest recent success (I think) in selling iSeries to new customers has been with Lotus Domino. Now they're pushing WebSphere. I got certified in Domino, have learned something about WebSphere, and have definitely worked to understand the command necessary to work with those products. That's not just a career thing, in the long run I believe it will further the success of the platform itself. Those are my thoughts anyway. Regards, Andy > Andy, > > And I think ANYBODY who disagrees with me MUST be a *nix gearhead...;-)) > > 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.) > > 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 > > | 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?
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.