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

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

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.

> Andy,
> And I think ANYBODY who disagrees with me MUST be a *nix
> However, CPY ignores the advantages of verb/subject command structure,
> consistent approach, and causes excessive potential for errors coding
> 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
> (hint, hint ;-), but I'm fairly sure that even amongst tool vendors,
> prefer the traditional.  IMV, this documentation overlooks who the
> 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
> 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
> effective techniques, although there isn't always agreement on which
> 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
> | > regular
> | >
> | > Any ideas why?

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.