× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dean

At 07:14 PM 4/16/1998 EDT, you wrote:
>Peter (et al),
>
>In a message dated 98-04-16 11:06:34 EDT, you write:
>
>> Having a library in front of QSYS is not a big problem.  However, a
>>  software provider has to provide the ability to remove the objects in this
>>  library if the user desires by taking an option from a menu.  The product
>>  still should be able to function, maybe not all functions but should give
>>  you the major portion.  That should be documentated.
>
>Have _NONE_ of these vendors heard of the "Product Library" option for
>commands and menus?  It puts the library in question either above or below
the
>current library (can't remember which), but _below_ QSYSLIBL.  If the vendor
>requires multiple libraries, and is obnoxious enough to force them into
>QSYSLIBL, they could just as easily hardcode anything in the product library
>to specifically refer to the other library names...

Come on, Dean, are you _really_ advocating hardcoded libraries? Would _you_
do that?  <g>

As far as 'product libs' go, I know for a fact that Help Sys has used them
at least since 1990.

On our system, there is a library called RBTSYSLIB. It was placed at the
_bottom_ of QSYSLIBL. It contains only objects that are common to more than
one of the Help Sys products. Would you rather they put it at the top of
QUSRLIBL?

The issue may be that this action was not documented. If not, it should
have been.

Bottom line for me--I _do_ trust the people at Help Systems. Why? Because I
know them personally. I worked in tech support there myself until early '91
(fact was, I was let go, so the fact I am supportive of their efforts comes
not from anything I get from them). The kind of treatment Laura Ausel tells
us about was not at all to be tolerated when I worked there.

I also have personal knowledge of the skills of the person who's done much
of their MI work. Using MI has its risks, of course, but to my knowledge,
his work has never caused a problem on a customer's machine. Other vendors
cannot say that. (This statement is based on personal experience, but I
won't give out details, since they could be unnecessarily harmful to
otherwise reputable persons who just made a mistake--as haven't we all?)

Besides my personal knowledge, they have a very solid track record, as Paul
M. (?) said, espec. where tech support is concerned. And they do have over
6000 customers, I think (at least according to their ads).

The strength of the reactions to Laura's posting has surprised me. Is there
more going on here? What is the big problem with a vendor's use of MI?
Pathfinder uses it, I bet J.D. Edwards does, Charlie Tuner does (doesn't
it, Peter?), Pathfinder does. And what's the problem if a vendor can create
a system domain program? Many of these vendors are business partners with
IBM and can certainly get info that the rest of us 'normal' users don't
get. I mean, IBM has all kinds of system domain programs on all of our
systems. Are we to throw out the baby with the bathwater?

Is there a fear of some secret, dangerous behavior on the part of vendors?
Yes, they should be responsible. I'm not sure how far responsibility
extends, when it comes to proprietary kinds of things.

I'd be interested in a thread on this list about the concerns with MI and
related items. Comments are being made, pro and con, but the basis is not
always obvious. For one thing, the fact that some (perhaps much--certainly
not all) of MI is now documented (again) and usable directly in C on the
400 suggests we should not fear it, just highly respect it.

Just some thoughts

Vernon Hamberg
Systems Software Programmer
Old Republic National Title Insurance Company
400 Second Avenue South
Minneapolis, MN 55401
(612) 371-1111 x480


+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.