Re: Weird problem with subfile in V5R4

I am obviously missing something here, but I do not see how this could possibly work, as described, under any release on which I have ever worked. I see where RR# is initialized to 1, but I cannot find where it is ever incremented. I, also, fail to see the reason for the CABEQ since RR# could never be 0 at that point since it was just initialized to 1.

Maybe I have been doing it wrong all of these years but, aside from whether one uses a DOU, DOW, or FOR loop, I have always incremented to relative record number at some point in the loop (except the FOR).
On the other hand, since the ENDDO is not included, perhaps there is more to the code that covers that. Otherwise, since RR# is not incremented in the sample code, the program would go into a loop on any release.


* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Alan Shore wrote:

Hi Jeff
this sounds like a missing ptf.
However, can you post the SFLCTL from the DDS, as well as the f-spec for
the workstation definition



Alan Shore

NBTY, Inc
(631) 244-2000 ext. 5019
AShore@xxxxxxxx
"If you're going through Hell, keep going" - Winston Churchill

rpg400-l-bounces@xxxxxxxxxxxx wrote on 04/08/2008 10:33:06 AM:

All,
I have a client on V5R4.
Recently, I made a change to a program that had not been changed since

V5R3.

The program displays a subfile and then chains from record 1 to the
end processing the data.
What is happening now is that even though the record number used to
chain to the subfile changes, the data returned is always from
record 1. The program in debug mode indicates that the record
number being returned does in fact match the record used to chain.
Tested with an old copy of the program from V5R3 and it works as it

should.

The following is part of the DDS for the subfile, and the relevant
part of the RPGLE code:
A R DETAIL
A*%%TS SD 20080319 155307 VAIJY REL-V5R4M0 5722-WDS
A SFL
A SBBOCD 3S 0H
A SBORD 9S 0H
A SBLINE 4S 0H
A SBITDC 3S 3H
A SBLOC 4A H
A HSEL 1A H
A SBPRIC R H REFFLD(##PRCE_SEL)
A SBFPRIC R H REFFLD(##PRCE_SEL)
A SBITD2Y R H REFFLD(##DESC_30)
A SBYNTX 1A H
A $BPRIC 11S 4H
A SVIN25 1A H
A SBITEM R O 5 1REFFLD(##ITEM)
A COLOR(WHT)
A SBITD1 R O 5 22REFFLD(##DESC_30)
A COLOR(WHT)
A SBITD2X 14A O 5 53TEXT('Description')
A COLOR(WHT)
A SBINV R Y O 5 68REFFLD(##INV)
A COLOR(WHT)


c z-add 1 rr#
c rr# cabeq 0 errorc
move *off *in99
c dou *in99 = *on
c move *off *in34
c rr# chain detail 99
c if *in99 = *on
c leave
c endif

A breakpoint at the endif after the chain shows the same data being
retreived regardless of the value in rr#.

I tried to duplicate this in a small sample program, but can not make it

fail.

This is a very important program for the client, and also, this type
of processing is common throughout the system.
I am very concerned that if there is a IBM issue here, they may
start having other serious problems.

TIA,

Jeff Young
Sr. Programmer Analyst
IBM -e(logo) server Certified Systems Exper - iSeries Technical
Solutions V5R2
IBM Certified Specialist- e(logo) server i5Series Technical
Solutions Designer V5R3
IBM Certified Specialist- e(logo)server i5Series Technical
Solutions Implementer V5R3




--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing

list

To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.