Re: Weird problem with subfile in V5R4 - Solved

[Jeff Young <cooljeff913@xxxxxxxxx>]

Thanks to all who responded.
The RR# was correctly incremented in a later part of the code.
The issue turned out to be that another routine was executing before the chain that I was looking at the read the entire subfile and had inadvertently overwritten the data for record 2 - n with the data from the first record.
By the time the Chain that I was looking at took place, the subfile had been corrupted, and I was seeing the same data on each chain as a result.
It looked like I was not getting the buffer refreshed from what I could tell at the time.
 
I appreciate all the suggestions.
 
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 


  
 





----- Original Message ----
From: Jerry Adams <jerry@xxxxxxxxxxxxxxx>
To: RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
Sent: Tuesday, April 8, 2008 12:36:29 PM
Subject: 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.
> >
> >