Debugging Built-in Functions (RPG ILE)

[Guest.Visitor]

Now that I've figured out how to use these wonderful new built-in functions on v4r4 (sort of), can someone tell me how to check them in debug?? (I use the standard AS/400 debugger). Also, what's the best method using the built-in functions to replace indicators where you SETLL and READE using partial keys? This is what I've found to work, but is it the best way? (The actual key for ICPRT1 is IACOM#, IAPRT# - I'm reading all parts for a given COM#). C IAKEY KLIST C KFLD IACOM# C* C MOVE WKCOM# IACOM# C* C IAKEY SETLL ICPRTMRR C DOU %EOF(ICPRT1) C IAKEY READE ICPRTMRR C IF NOT %EOF(ICPRT1) C C EVAL RCCOM# = IACOM# C EVAL RCPRT# = IAPRT# C EVAL RCPRTL = IA101 C* Any help is greatly appreciated.

[Guest.Visitor]

In the debugger, you can usually tell the values of the bifs by stepping through your code. But say you have a complex IF statement that means you can't tell from the debugger why you went into a particular part of the code. That COULD be a signal that your condition is too complex, but if your code is both correct and easy to understand, then for debugging purposes, add some temporary lines of code after the I/O that will make the values of the bifs obvious when you step through them. <pre> C setll REC C if %found C eval *in01 = *in01 C endif </pre> I don't think your code will work all the time since SETLL doesn't set %EOF. Use %FOUND to test whether you should go into your READE loop. Here is one way to code your loop: <pre> C k setll REC C if %found C k reade REC C dow not %eof C --- process record C k reade REC C enddo C endif </pre> Or, if you want to avoid two READEs you could code this way: <pre> C k setll REC C eval continue = %found C dow continue C k reade REC C eval continue = not %eof C if continue C --- process record C endif C enddo </pre> Or using CHAIN instead of SETLL to start the loop: <pre> C k chain REC C eval continue = %found C dow continue C --- process record C k reade REC C eval continue = not %eof C enddo </pre> Why aren't the I/O feedback bifs debuggable? Some of the bifs require code to be generated to calculate the value rather than just being a compiler-internal variable. Some of the bifs could be debuggable, but it would be almost impossible to explain which ones were debuggable and which weren't; also, it's possible that some would have to change to be non-debuggable. Barbara Morris, IBM Toronto Lab, RPG Compiler Development

[Guest.Visitor]

Thank you Barbara. I will revisit my code.