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

Andy,

See inline...

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of Andy Nolen-Parkhouse
| Sent: Sunday, December 09, 2001 7:12 AM
| To: midrange-l@midrange.com
| Subject: RE: CPY instead of CRTDUPOBJ ? (was: CD Burning software?)
| Importance: High
|
|
| jt,
|
| As opposed to a reactionary 400 zealot gearhead I presume?  ;-)

Precisely...!

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

Can't say I'd disagree with you...;-)

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

I may be reactionary, but try to stay this side of "dinosaur".  From what
I've seen of objective analysis, *nix s*cks.. bigtime...  Recall some
pointed discussion on that fact, by one of the primaries of Gnome...  Miguel
de somebody...  I can try to find that, if there some question on the issue.

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

True...

|
| 2) If the objects used are entirely within the QSYS file system, use the
| legacy naming conventions and commands.

Sounds good to me...

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

I figured there would be a hitch to this "lovefest", somewhere along the
lines...;-)  Given the option, and all things being equal, I'd use the
legacy approach...  Because I don't associate "legacy" with something bad,
but something tried and true.  JMHO...


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

Well.. this is where all things are not equal:  I have a strong preference
for not mixing programming styles, also.  So I would have to think about
whether to take a mixed-mode approach, in a given program...  I dunno...

But use of the IFS-naming scheme, exclusively, leads one right down the path
of making up a command that has keywords and parms that don't make any
sense.. like the CDRST in the example.

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

Ya...  I'll need to do that, probably shortly...

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

It makes real good sense...  I don't have a problem with the concept.  I
have a problem making keying errors.  Keyword parms being sufficiently prone
to error, I don't like the idea of making it any more complex than what it
is...  Is not the time fixing the keying errors..  It's the train of thought
that gets disrupted by entering a cotton-pickin command 2 or 3 times to get
it to execute correctly.  So I don't much cotton to a object naming scheme
that is a lot longer, and more prone to errors to boot.  I've used this
sufficiently that it is no longer foreign, but it's still going to be longer
and prone to errors.

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

Partially true...  Well, completely true, give Tom's fact that QSYS objects
are also a part of the IFS, contrary to how it's normally thought of.  But
in the sense most people think of, the IFS isn't the be-all and end-all..
contrary to what many believe.

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

No doubt about that...  It will further the success of the platform, and it
has...

AFAIK, these are a very small percentage of the total platform, however...
Sure they get all the attention, but that doesn't mean that's where the
customer base is...  I seriously doubt (but don't know for sure) that the
number of Domino and Websphere installs signifies when compared to legacy
systems.  BUT ESPECIALLY IF YOU LOOK AT THE CUSTOMER BASE FROM THE POINT OF
VIEW OF DOLLARS, as opposed to units or CPW or somesuch.

|
| Those are my thoughts anyway.
| Regards,
| Andy
|

Good thoughts...!  Thanks...

And I really DON'T know the actual numbers that make up the customer base...
I have my suspicions.

But I SURE know which customers are getting the attention of IBM and the
media...  I know which customers are SUPPOSED to represent the wave of the
future...  (And those are the ones going to NT, *nix, and other IBM/non-IBM
platforms.)

'Fraid that don't mean much, to me:  I don't know if you recall, Andy, that
I'm supposed to be flippin burgers, as of several years ago, according to
the "majority" view...  (I say "majority" because the "silent majority" is
just that.. silent...)

jt


| > 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?
|
| _______________________________________________
| 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.
|