Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Tips and Techniques: Move Off of Resulting Indicators

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • R.Cozzi
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Couldn't you "just" put the value of %FOUND or whatever into a work field? You could use compiler directives to avoid embedding that unnecessary code into production. (See code example.)
    Code

    Leave a comment:


  • R.Cozzi
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    I think you missed my point. When a single format database file is specified, the use of the format name should be transparent. That is I should be able to use the File name and ignore the format name. Obviously if you have a multiformat file this request would not apply. THe use of multi format files in new code is so rare that it is virtually not an issue.

    Leave a comment:


  • avrahamn@coop.co.il
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Factor2+++++++Result++++++++Len++DcHiLoEq C CustNo Chain CustMast C if %Found() C DOU %EOF() ** Blah, blah, blah C CustNo ReadE C enddo C endif This chain was done for the purpose of relating to tha data inside the loop, which is not so clear from the code. Besides that, READE comes after the program relating to the data, which is the oposite fo straight-forward. Here is the more improved code, which is easier to understand.
    Code

    Leave a comment:


  • avrahamn@coop.co.il
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    The ILE debugger need to be enhanced to be able to test %EOF() if it is on or off, abs the same for other built ins.

    Leave a comment:


  • M.Savino
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    The fact is that we can have multi-format logicals like the example below (not Joins). And many shops and probably some software vendors take advantage of the technique. That would make it impractical to eliminate record format names or render them irrelevant. As I recall multi-format logicals works great in situations where active and historical data are in separate PF's but the layout and field names are identical. I haven't used one of these in a while, but I did a quick test. Read/Chain/Set** operations using the LF Name will result in a Union of the data, while operations against the Format Name(s) will act on only the based on PF with the associated format. Chain and EOF indicator logic worked the same as any other DB File. Except that you had to know that when reading by Format, the second PF could have data that matches your search, even though the Format that you're currently processing is EOF or Not Found. So that would seem to raise an interesting question about the BIFs. Since you can Read and Chain by Format but must use File Name for EOF and Not Found. Mike
    Code

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Good idea. Thanks. Our shop is not in the habit (and I would guess many of us RPG programmers are not) of checking for other conditions that cause an I/O failure. We assume record not found means that the key we requested doesn't exist in the file and we assume that a read failure is a record lock. As the other reply points out, however, once we start using other methods of control, like triggers, we may need to start checking other reasons if we want to give detailed feedback to the user as to why something didn't happen or couldn't be done instead of just saying "It failed.". Garrett

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Then... code the STATUS in the SDS and look at that value in debug, and you can use the %BIF's. Chris

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    I agree with Mr Tyler. I like the look of the BIF's code but I wish I could "see" the BIF result in debug, like I can see the indicator AND then, of course, it would be nice to be able to change the value of the BIF (like I can change the value of the resulting indicator) so I can excercize the code (if I want). Garrett

    Leave a comment:


  • robberendt
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Good point on debugging the chain. Doesn't a chain failure update the exception in the SDS? If not, what about the file information data structure? Shouldn't they not 'assume' certain criteria about a failure anyway? Couldn't a read loop fail because of reasons other than an eof condition? Like a read trigger says that this person is not authorized to this record?

    Leave a comment:


  • Matt.Tyler
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    The reason some of the "programmers" here have not adopted the bifs is because they believe they can have better control over their programs when they can see the results of a IO function in an indicator. Its mostly a debug thing. They want to see if the program will go into a DOW loop based on an indicator value without needing to have it step over that piece of code.

    Leave a comment:


  • R.Cozzi
    replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    Yes, qualifying them is okay. But IBM makes you use the File names instead of record format names on the built-in functions. This is a pain in the butt. I wish RPG IV would ignore database record format names--make the irrelavant so I don't have to care about them. In V5R2 and even more so in V5R3 this is less of an issue--but it continues to be my wish.

    Leave a comment:


  • Guest's Avatar
    Guest replied
    Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    This tip is a "must read" for modern programming! To further clarify your code "qualify" the BIFs when programming, it not only makes it easier to see what you are doing but it avoids logic errors when dealing with multiple files. .....C*Rn01Factor1+++++++OpCode(ex)Factor2+++++++R esult++++++++Len++DcHiLoEq C CustNo Chain CustMast C if %Found(CustMast) C DOU %EOF(CustMast) C If CustNo = 'something' C CustNo Chain CustAddr C If %Found(CustAddr) ** Blah, blah, blah C EndIf C EndIf C Else ** Blah, blah, blah C CustNo ReadE C enddo C endif

    Leave a comment:


  • Tips and Techniques: Move Off of Resulting Indicators

    ** This thread discusses the article: Tips and Techniques: Move Off of Resulting Indicators **
    ** This thread discusses the Content article: Tips and Techniques: Move Off of Resulting Indicators **
    0
Working...
X