RE: SQL update vs RPG/DDS update

["Wilt, Charles" <WiltC@xxxxxxxxxx>]

Gene,

Where is the original chain with no lock and initial saving of the data into savmstr?

Charles


> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx 
> [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Gene Burns
> Sent: Friday, October 05, 2007 3:30 PM
> To: RPG programming on the AS400 / iSeries
> Subject: Re: SQL update vs RPG/DDS update
>
> Joe,
>
> I see that I should have added more documentation with the code.
>
> savmstr DS is the file from the first chain when the user 
> entered the program.
> newmstr DS is the changes made in the program, but not yet 
> sent to the file mstrDS DS is reset at the last chain to 
> whatever the file currently contains
>
> mstrDS is the only DS updated when the file is read or chained to.
> The others are updated through savmstr = mstrDS and newmstr = 
> mstrDS statements.
>
>
>         // if changes have been made, check file for changes
>         if newmstr <> savmstr;
>
>           // get the current record from the file
>           chain (cmyrin: cmycin) clmmas;  // loads mstrDS
>
>           // compare the current record in the file to the 
> original before
>           //    making changes
>           if savmstr = mstrDS;        If the file was changed 
> by another
> user these will not be equal
>             mstrDS = newmstr;   // set fields to new values
>             clchgd = today;
>             clchgt = %time();
>             clchgu = userid;
>             update clmmas;
>             savmstr = mstrDS;  // update saved DS to new values
>             origscreen = screenDS;
>             completed = *on;
>           else;             // file has been changed by another user
>             unlock hclmmas;            The lock is then 
> released, however
> clchgu does not show the update from the file
>             completed = *off;
>             message = NoUpdMst + %trim(clchgu) + Retry;
>             wrkadj = *zero;
>             wrkadj2 = *zero;
>             wrkadj3 = *zero;
>           endif;
>         else;
>           // no changes have been made, do not update
>           completed = *on;
>           //message = *blanks;
>           wrkadj = *zero;
>           wrkadj2 = *zero;
>           wrkadj3 = *zero;
>
>           // get the current record from the file
>           chain(n) (cmyrin: cmycin) clmmas;  // loads mstrDS
>
> Deletes are not allowed on this file, so there was no need to 
> check the found condition.  If you got this far the record is 
> known to exist.
> Hopefully, this explains why I am puzzled.  If I am just not 
> understanding what is going on here with these DS please 
> enlighten me, because this is driving me nuts!
>
> Thanks for your time.
>
> Gene
>
> On 10/5/07, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> > > From: Gene Burns
> > >
> > > CHAIN followed by UPDATE, but with an externally defined DS.
> > >
> > >      fhclmmas   uf   E           K DISK
> > > |    d mstrDS        e ds                  extname(hclmmas)
> > >
> > >
> > >           // get the current record from the file
> > >           chain (cmyrin: cmycin) clmmas;  // loads mstrDS
> > >
> > >           // compare the current record in the file to 
> the original
> > before
> > >           //    making changes
> > >           if savmstr = mstrDS;
> > >             mstrDS = newmstr;   // set fields to new values
> > >             clchgd = today;
> > >             clchgt = %time();
> > >             clchgu = userid;
> > >             update clmmas;
> > >             savmstr = mstrDS;  // update saved DS to new values
> > >             origscreen = screenDS;
> > >             completed = *on;
> > >           else;             // file has been changed by 
> another user
> > >             unlock hclmmas;
> > >             completed = *off;
> > >             message = NoUpdMst + %trim(clchgu) + Retry;
> > >             wrkadj = *zero;
> > >             wrkadj2 = *zero;
> > >             wrkadj3 = *zero;
> > >           endif;
> > >         else;
> > >
> > >
> > > When the file has been updated by someone else the DS are 
> different, 
> > > HCLMMAS is unlocked, and the message is (supposedly) set 
> telling the 
> > > user who updated the file.
> >
> > I'm not sure what you're saying.  The code is fine, and you 
> should get 
> > errors if someone changes the record (provided savmstr and 
> newmstr are 
> > the correct size).
> >
> >
> > > The CLCHGU field is in the file, but is blank at this 
> point in the 
> > > program.  Checking the file shows that these fields have
> > been
> > > updated and CLCHGU is not blank.
> >
> > At WHAT point?  Since the "mstrDS = newmstr" wipes out the original 
> > data, the only place where the fields are guaranteed to 
> match the file 
> > is the if statement immediately after the chain but before 
> the mstrDS 
> > = newmstr is executed.  If at that point you see the file different 
> > than what you have in your program, then you have a problem I have 
> > never encountered in my career.
> >
> > Anything other than that is more than likely a logic problem.
> >
> > Joe
> >
> > P.S. You also aren't checking for a not found condition on 
> the chain, 
> > and you definitely should in case someone deleted the record.
> >
> > --
> > 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.
> >
> --
> 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.

This e-mail transmission contains information that is intended to be confidential and privileged.  If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful.  Please reply to the message immediately by informing the sender that the message was misdirected.  After replying, please delete and otherwise erase it and any attachments from your computer system.  Your assistance in correcting this error is appreciated.