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




 The problem on above is that I can easily tell if *on means successful
or not successful.

I do this all the time. In fact, many of my /COPY members for service programs have this same definition:

      /if not defined(SUCCESS)
     D SUCCESS         C                   CONST(*ON)
      /define SUCCESS
      /endif

      /if not defined(FAIL)
     D FAIL            C                   CONST(*OFF)
      /define FAIL
      /endif

I use the /if not defined() logic to let me put this same code in many service programs without a conflict (since SUCCESS is always *ON, and FAIL is always *OFF, it doesn't matter which /copy book I get it from.)

That way, I can make the code quite obvious:

     if ( purch_load_inotes(ItemNo) = FAIL);
       errMsg = purch_error();
       // show errMsg to user
     endif;

Some other people have suggested changing the way you name your subprocedure. And that's a good idea if your subprocedure's purpose is to validate something. For your example it makes sense:

     if  (ScreenInputValid());
       // do this
     else;
       // do that
     endif;

However, that's not always what your subprocedure does. I use success/fail for lots of different types of subproocedures, not just validity checking.

For example:

     if ( order_loadCustOrdersList() = SUCCESS );

Sure, i could rename it to read "order_CustOrderListLoadedSuccessfully" or something like that, but to me, it's no longer obvious that the subprocedure actually loads it the order list. At that point, it looks like you're just checking to see if it was successful, instead of actually doing the work.

So for a routine that's primary purpose isn't to check something, I use the SUCCESS/FAIL constants.

Hope that makes sense.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.