Re: RPG400...a chain, a reade, no indicators...now what?

Hi Rick,

I'm moving my replies to RPG400-L since it's a better place for this
than MIDRANGE-L.

On Wed, 18 Dec 2002, Rick Rayburn wrote:
>
> The following code should not be unusual (i think) in an RPG400 program:
>
> Dou Not % error
> Key Reade (E) File
> If %error
> (error msg sending routine)
> iter
> endif
> Enddo
>

I'd do something more like (and this is somewhat simplified pseudocode):

dou %eof

key reade(e) file

select
when  %eof
  (out of records to process)
when %error and errid=cpf5027
  (call service program routine that gets userid/job holding lock, and
   display as status msg showing what the hold-up is)
iter
when %error and errid=xxxx  (other error that I expected)
  (handle error appropriately)
iter
when %error (error I didnt expect)
  (send back an escape message to caller, this ends program)
endsl

enddo

Of course, I'm still at V4R5 (you know, I really should upgrade!) there
may be newer techniques w/the new error trapping op codes.

> In RPG3 days, the "If %error" would more than likely have been a check for
> an error indicator. And if you were in a loop because of a lock, you could
> debug your way out by changing the value of the indicator to allow the code
> to fall through. How does one handle that in the above scenario?

IMHO, changing the indicator to indicate that it's not an error leads
to ugly code.  Especially since indicators in RPG3 didn't have meaningful
names attached to them.

If you like that paradigm however, why not do something like this:

D cust_file_err   S              1N   inz(*off)

dou cust_file_err = *off

key reade(e) custfile

eval cust_file_err = %error

if cust_file_err = *on and errid=CPF5027
eval cust_file_err = *off
endif

enddo

Surely, the name "cust_file_error" would be easier to figure out than
*in41.  Yet, aside from that, you've got the exact same capabilities.

> For that
> matter, how do you view, within debug, a successful or unsuccessful chain,
> or read, that is not governed by an indicator if your debug statement falls
> on that testing line of code (e.g. If %found (file)...)??

You could do this the same way.   Assuming you did a chain (not a reade)
you'd assign the value of %found to an indicator.  Preferably, a named
indicator like 'cust_record_found' (or whatever)

key chain custfile
eval cust_record_found = %found

But, I wonder why you need to do this?  I've been using the BIFs instead
of indicators, and I never seem to need to display this in debug.

If you have something like this:

key chain myfile

if %found
(do something)
else
(do something)
endif

it's pretty obvious whether the chain succeeded by which code is being
executed.  What good does checking the value of %found do you?  Unless, of
course, you think the IF op-code is malfunctioning :)

Or, if there are errors you want to trap, more like this:

key chain(e) myfile

select
when %error and errid=CPF5027
(handle record lock)
when %error
(handle unspecified error)
when not %found
(handle record not found)
other
(handle success)
endsl

>
> Thanks again to all who give their time and efforts to those of us who need
> the help.
>

Hope my reply helps you.  Happy Holidays.