RE: LVLCHK *NO

Nigel,
        It is truely a good thing when one finally receives email with an
alternate point of view. And, I must say, you have expressed a point of view
different from what else has been set. The key word in your reply is
"could." As in "could be missing out [on] a system ..." The fact is, not
many people, and rightfully so, are willing to take the "could" chance. The
"could" that could occur is not a good could. 

To let you all know, I brought the first three responses to the attention of
the I.T. Director, as it appeared that the responses were not going to
change. I thought I was understanding the situation correctly, I just wanted
some agreement from the technical community. I'm afraid that when I
presented him with my discovery he showed signs of "head buried in sand"
syndrome. It is my understand, now, that this could be worse than
lvlchk(*no).
**************************************

"The point I really wanted to make is that by dismissing a solution or
vendor,  based on one isolated aspect of their development standards, you
could be missing out  a system which is well-designed, costs less to
maintain, and performs better than one of the alternatives !   Maybe I
should have just said that at the top !!"  


Nigel Waters
----------------------------

ps...   this was the same site that had one display file with over
two-hundred formats... but thats another story !!
(strangely enough, the display file was lvlchk(*no) too !)



Dave wrote..

>>3) What would be the most likely reason a third party vendor would use
>>LVLCHK *NO?

>The third party vendor has no confidence in the integrity of his package.


Chris  wrote..

>Return your software package for a full refund.  LVLCHK(*NO) is a BIG NO
NO.
>You are correct with your understanding of LVLCHK.  If the file has been
>changed you may get decimal data errors, data placed into the wrong fields,
>all sorts of problems.  The most likely reason is laziness.  Fire that
>software vender.

Michael wrote..

> Why would a third party vendor use LVLCHK *NO?  Because if they recompile
> all of their programs they have to RETEST all of their programs, and this
> takes time and $$.  They're shortcutting their own development process at
> the expense of the client's data.




$ConflictAction: 1

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