|
That's crazy... glad you found it. RPG IV should treat the file name and format name for single-format files interchangeably. The use of multi-format files (except for device files) is virtually non-existent and should be the exception when you are forced to use the format name. In 99.9% of the rest of situations you should always be using the File Name. And RPG IV should support that. I hate having to code: CustNo Chain CustRec If NOT %Found(CUSTMAST) ...coding the format name on the CHAIN and then the file name on the %FOUND. What a crazy, crazy design. It should all be file name. I would go so far as to say that RPG IV should give a warning message whenever a format name is used anywhere for single-format database files. -Bob Cozzi -----Original Message----- From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Tony Carolla Sent: Monday, January 24, 2005 11:40 AM To: RPG programming on the AS400 / iSeries Subject: Re: RNX1011 Error Okay, I found the solution. I apologize for dumping an essay on the group, but I was desperate. The problem was, on the CHAIN operation, I was using the file entry name (which is allowed, and per the IBM manuals, works). At times, it seems that, at least on my box, using the file name doesn't always work with CHAIN, and it seems, per the INFDS, to be looking for a blank format name (or perhaps this field in the INFDS is just blank because I used the filename on the CHAIN). So I changed the CHAIN op to the format name, and voila. This is a single-format PF, by the way. On Fri, 21 Jan 2005 15:41:04 -0800, Tony Carolla <carolla@xxxxxxxxx> wrote: > I have created a module in a service program, that calculates the > dollar value of a loss from a log file record. The module > occasionally needs to open a file (MEMBR), and chain to a record in > that file. > > Because we have multiple companies, the file opened could be in one of > 60 or so libraries. All copies of this file have the same name, same > meber name, and the same format identifier. I have set up the F spec > with an EXTFILE variable, and when I need to open the file, I close it > if open, resolve the EXTFILE variable, open the file, then chain. > Done it thousands of times, no problem. > > And the service program works beautifully, when called from another > RPG program. I have set up an SQL function for our 'reporting' users, > and this function calls the module and returns the cost to the SQL > view. And this works marvelously. Until it has to use one particular > copy of the MEMBR file. Just one of our copies, and it is the same > copy that errors out every time. When the view tries to call the > service program, it errors with the RNX1011 error, on the statement > number in the service program where the CHAIN op is at. I can use an > RPG program and resolve costs for all records that relate to the same > copy of the MEMBR file, but when I try to use the module from the SQL > function, the certain copy causes the error. > > I have verified that this copy is the same format name, same format, > same everything. How can I debug this error further? I have used > debugging, and the file that is open before the CHAIN is the correct > file, the fields used to CHAIN are valid, and nothing looks wrong, but > the CHAIN fails. HELP! > > > -- > "Enter any 11-digit prime number to continue..." > -- "Enter any 11-digit prime number to continue..." -- 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.
As an Amazon Associate we earn from qualifying purchases.
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.