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



"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





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.