RE: Weird problem with subfile in V5R4

Hi Jeff

It would be helpful to see the rest of the loop to see where and under what
conditions #RR is being incremented.


There's no need for the CAB statement as you have just initialised the #RR
field to 1 so it can't be zero unless the Z-ADD should really be an ADD in
which case style wise it would be neater to have a conditioning IF....ENDIF
structure instead:

c If #RR <> 0

c move *off *in99

c dou *in99 = *on

c move *off *in34

c rr# chain detail 99

c if *in99 = *on

c leave

c endif


c EndIf

Alternatively you could code positions 380 to 381 of the File Information
Data Structure for the display file to determine the number of records in
the subfile and then use a FOR....ENDFOR loop:

FFilename++IPEASFRlen+LKlen+AIDevice+.Keywords+++++++++++++++++++++++++++++
FMYFILE CF E WORKSTN INFDS(DSPFBK)

DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++++++++++++++++++++++++++
DDSPFBK DS
D DSP_FLAG1 367 368
D DSP_AID 369 369
D CURSOR 370 371
D DATA_LEN 372 375I 0
D SF_RRN 376 377I 0
D MIN_RRN 378 379I 0 *
D NUM_RCDS 380 381I 0

CL0N01Factor1+++++++Opcode&ExtExtended-factor2+++++++++++++++++++++++++++++
C For #RR = 1 to NUM_RCDS
...
...
C EndFor

If you stick with the DOU, you don't need to turn off *IN99 before hand as
the DOU loop will always go through the loop at least once, even if *IN99 is
on at the start. A better way than using indicators would be to make use of
the %FOUND built in function:

c dou Not %Found(dspfname)

c move *off *in34
c rr# Chain(e) detail
c If Not %Found(dspfname)

c leave
c endif


All the best

Jonathan

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Jeff Young
Sent: 08 April 2008 15:33
To: rpg400-l@xxxxxxxxxxxx
Subject: Weird problem with subfile in V5R4

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