Re: file update - change key value

[Jon Paris <jon.paris@xxxxxxxxxxxxxx>]

"Who would think that there is a compiler option to get by a specific error msg??"

Well it kinda has to be that way Joel.

The compiler with its default settings has (or at least used to have) to be ANSI compliant. The ability to change keys is an IBM i extension (ANSI expressly forbids it). So it is not really just suppressing an error message, although it sounds that way, it is actually causing it to bypass the check that ensures that the key was not changed during an update.

When I first went to work on the S/38 I thought it was insane that you could change the key on a record - I had not seen it on any of the dozen or so systems I had previously worked on - after I while I got used to the idea but it sure seemed weird at the start.

Onward!

  
On 2012-07-06, at 12:16 PM, Stone, Joel wrote:

> You are amazing - this worked like magic!
>
> Who would think that there is a compiler option to get by a specific error msg??
>
> Very nice - so simple and elegant.
>
> Every other option seemed messy - it would require LFs and SQL to update an identity column, or another CBL pgm to populate the key from an LF which didn't use this field as the primary key.
>
> Thanks so much!
>
> Ps it would be great if they put this tidbit under FS21 at http://publib.boulder.ibm.com/infocenter/iadthelp/v7r0/index.jsp?topic=/com.ibm.etools.iseries.langref.doc/c0925395700.htm
>
>
>
>
> -----Original Message-----
> From: cobol400-l-bounces@xxxxxxxxxxxx [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Jon Paris
> Sent: Friday, July 06, 2012 9:44 AM
> To: COBOL Programming on the iSeries/AS400
> Subject: Re: [COBOL400-L] file update - change key value
>
> I _think_ you need to compile the program with option NOFS21DUPKY to handle this.
>
> I'm digging waaaayyyy back in my memory banks but I'm pretty sure that is the one.
>
> Changing the key of a file is an absolute no-no in COBOL terms - but because DB2 allows it COBOL on IBM i was given an option to bypass the rule.  Please read up on it though.
>
>
> On 2012-07-06, at 9:53 AM, Lindstrom, Scott R. wrote:
>
> > All I can think of is to add the new record and delete the old record.  That's what we did back in my mainframe days when changing the key was not allowed.
> >
> > Scott Lindstrom
> > Reynolds Leveraged Services |  HP-UX, Linux, and AS/400 Administrator
> >
> >
> > -----Original Message-----
> > From: cobol400-l-bounces@xxxxxxxxxxxx [mailto:cobol400-l-bounces@xxxxxxxxxxxx] On Behalf Of Stone, Joel
> > Sent: Thursday, July 05, 2012 4:28 PM
> > To: 'COBOL Programming on the iSeries/AS400'
> > Subject: [COBOL400-L] file update - change key value
> >
> > I am building a file for ETL.
> >
> >
> > I stuck a seq # key on the front of the record (with duplicates).
> >
> > First, I populate the file with any customer record which was changed today - from the journal record - using a TAATOOL.
> >
> > The seq # key is zero for all these new adds.
> >
> > Next I come thru with a COBOL pgm and update the CUST records with current data.
> >
> > When I try to rewrite record - after changing the seq#, I receive error 21 - OS is stating I cannot change key if dup keys are allowed.
> >
> > I need to change the key from zero to a seq # for downstream processing - how can I get around this?
> >
> > I don't want to add another file in between to accomplish.
> >
> > Thanks!
> >
> >
> >
> > ______________________________________________________________________
> > This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
> > For more information please visit http://www.symanteccloud.com
> > ______________________________________________________________________
> > -- 
> > This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
> > To post a message email: COBOL400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
> > or email: COBOL400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/cobol400-l.
> >
> > -- 
> > This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
> > To post a message email: COBOL400-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
> > or email: COBOL400-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the archives
> > at http://archive.midrange.com/cobol400-l.
>
> Jon Paris
>
> www.partner400.com
> www.SystemiDeveloper.com
>
>
>
>
> -- 
> This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
> To post a message email: COBOL400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
> or email: COBOL400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/cobol400-l.
>
>
> ________________________________________________________________________
> This inbound email has been scanned for all viruses by the MessageLabs SkyScan
> service. 
> ________________________________________________________________________
>
> ______________________________________________________________________
> This outbound email has been scanned for all viruses by the MessageLabs Skyscan service.
> For more information please visit http://www.symanteccloud.com
> ______________________________________________________________________
> -- 
> This is the COBOL Programming on the iSeries/AS400 (COBOL400-L) mailing list
> To post a message email: COBOL400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/cobol400-l
> or email: COBOL400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/cobol400-l.

Jon Paris

www.partner400.com
www.SystemiDeveloper.com