RE: OpsNav access to IFS (was RE: Transfer file using Ops Navigator? )

["jt" <jt@xxxxxx>]

Tom,

See inline.

jt

| -----Original Message-----
| From: midrange-l-admin@midrange.com
| [mailto:midrange-l-admin@midrange.com]On Behalf Of thomas@inorbit.com
| Sent: Thursday, December 13, 2001 11:16 PM
| To: midrange-l@midrange.com
| Subject: RE: OpsNav access to IFS (was RE: Transfer file using Ops
| Navigator? )
|
|
| On Thu, 13 December 2001, "jt" wrote:
|
| > I stand by the rest of my comments...  We're being told:  "it's
| my way, or
| > the highway".  Ops Nav is as slow as a pig stuck in mud,
|
| But you want to add functionality to slow it down more while
| duplicating existing desktop function?

I stand corrected, on this particular function.

|
| > Here's the litmus test...  Does the Ops Nav team EXCLUSIVELY
| use Ops Nav to
| > do all their day-to-day work...?!?  If the answer is "yes", then:
| >
| > Their liars...  or more likely...
| > They don't actually manage the systems they work on
| > and/or
| > They're not familiar enough with Command Entry
|
| What would this "litmus test" resolve? I'd feel comfortable
| offering a guarantee that they do not use it exclusively, most
| especially when the discussion is about PC functionality such as
| editing .html documents (or developing Java programs in VA Java or...).

Ya.. Rob straightened me out on that.  However, that confirms my opinion
that GUI is not best for all users, on all occasions.  I think the added
expense of providing this functionality is minimal, compared to the benefit
to the users.  The other litmus test I proposed was how long does it take
Simon Coulter to reach break even.  In fact, I'm downloading an evaluation
copy now, and may cast my ballot by purchasing this product.

|
| If the discussion had been about iSeries operations, then I
| suspect they would indeed use OpsNav much more than most sites
| do. Further, for iSeries operations that are not currently
| available through OpsNav, I suspect they're busy developing new
| OpsNav functions to handle those rather than duplicating Windows
| desktop functions. I'm pretty sure they aren't developing OpsNav
| for the pure perverse enjoyment of making us irritated. (Well,
| fairly sure.) It is indeed becoming more capable.

This is true.  I'm glad they're enhancing Ops Nav.  I don't much cotton to
the notion that they're doing this at the expense of enhancing similar APIs
and CL commands.  I've heard that the supposed reason is to avoid the high
cost of documenting and testing the APIs and CL commands.  I'm not saying
this is not true, but that I have a hard time buying the argument.

I don't believe that the cost of taking developed and tested modules and
wrapping an API or command around it, is anywhere in the same ballpark as
the cost of developing the code.  (If it is, I'd like to know why.)  I also
believe the cost of putting an Ops Nav front-end to this developed code is
going to be more than putting an API or command front-end.

So it appears, to me anyway, to be penny-wise and pound-foolish, to go to
the GREAT expense of putting a function ONLY into Ops Nav.  (Obviously,
there may be political issues that I'm not aware of, within IBM.)  But I
think it's primarily due to the decision to FORCE EVERYONE to use Ops Nav,
by whatever means are available.

I'd be overjoyed to be proven wrong, BTW.

I can be proven wrong very simply:  IBM could provide the necessary
documents so that the user community can write their own APIs and commands.
My understanding is that, in the case of at least some of these new
functions, IBM has NOT done this.  (In the case of Simon Coulter's package,
I know there are APIs for some of the things, but I'm not sure if there were
APIs for all of them, nor how much info he got from IBM docs and how much he
had to figure out himself.)  I don't recall what threads I heard the info in
this paragraph, but it was on these lists.