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



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.



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.