|
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 mailing list archive is Copyright 1997-2025 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.