|
Booth, Rule #1: Update files are NEVER blocked on the AS/400 (a pet peeve of mine; S/36 could block on update, and double-buffer as well!) AFAIK, access by key, by itself, does not disqualify a file from being blocked. This has been a bit of a mystery to me. If a keyed file is blocked, how is it blocked? Is it a contiguous block of physical records which happens to hold the record being accessed. Or is the block made up of (potentially) non-contiguous physical records that follow the keyed access path? Blocking is prevented by using OVRDBF SEQONLY(*NO); my original post mentioned OVRDBF NBRRCDS(1) which I don't think is correct. Someone else here can verify that. Again, I want to reiterate that the RRN retrieved from the INFDS in an RPG-IV program is _always_ current, regardless of blocking. - Dan Bale -----Original Message----- From: boothm@earth.Goddard.edu [mailto:boothm@earth.Goddard.edu] Sent: Wednesday, February 16, 2000 7:43 PM To: RPG400-L@midrange.com Subject: RE: Record Number Please go further with this explanation. I had assumed, apparently wrongly, that if a file was accessed by key it retrieved records one at a time instead of in blocks. What has to be done to prevent blocking? _______________________ Booth Martin boothm@earth.goddard.edu http://www.spy.net/~booth _______________________ "Bale, Dan" <DBale@TFSA.Textron.com> Sent by: owner-rpg400-l@midrange.com 02/16/2000 04:54 PM Please respond to RPG400-L To: "'RPG400-L@midrange.com'" <RPG400-L@midrange.com> cc: Subject: RE: Record Number Booth, Jim, In RPG-III, as in Booth's example, retrieving the file's current RRN cannot be done reliably with just the code you provided. For input-only files, you risk getting the first RRN in the block of records read. So, for example, on your first read you get a block of records that consist of RRN 1 through 8, the INFDS will report the RRN as being 1 for each of those 8 records. I believe the way to overcome that is to OVRDBF NBRRCDS(1), although I may be wrong on that. Since no record blocking occurs with an update file, you could use this technique without the OVRDBF. In RPG-IV, I seem to recall that Barbara Morris stated a few months ago that the INFDS reports the current RRN at all times, regardless of record blocking or the fact that the file is input-only. O.K., I just looked it up in the ILE RPG Programmer's Guide, Appendix 1.1.4 (Behavioral Differences Between OPM RPG/400 and ILE RPG for AS/400) I/O: 8. In ILE RPG, the relative record number and key fields in the database-specific feedback section of the INFDS are updated on each input operation when doing blocked reads. - Dan Bale -----Original Message----- From: Martin, Booth [mailto:BoothM@goddard.edu] Sent: Wednesday, February 16, 2000 3:18 PM To: 'RPG400-L@midrange.com' Subject: RE: Record Number Jim, this worked for me: FAPDUE IF E DISK FAPDUE1 IF E K DISK INFDS(DB1) F RENAME(RAPDUE:RAPDUE1) FAPDUE2 IF E K DISK INFDS(DB2) F RENAME(RAPDUE:RAPDUE2) FAPDUE3 IF E K DISK INFDS(DB3) F RENAME(RAPDUE:RAPDUE3) D DB1 DS D DB1RRN 397 400B 0 D DB2 DS D DB2RRN 397 400B 0 D DB3 DS D DB3RRN 397 400B 0 Then, on the subfile I put DB_RRN into a hidden field and could show file 1, 2, or 3 in the subfile, depending on which file the user requested, and then when a user selected a subfile item I could READS and chain to the unindexed physical file with RRN for updates. -----Original Message----- From: Jim Langston [mailto:jlangston@conexfreight.com] Sent: Wednesday, February 16, 2000 11:46 AM To: boothm@goddard.edu Subject: Record Number I am searching through a file for some strings, and I need to find out what the record numbers are. I am opening the file Input, Full Procedural, externally described, and as I understand it, this uses sequential processing, that is, record numbers. Once I find my string, how do I find out what record number I am actually on? Until I find out I am going to just increment a counter and hope it's right, but as we all know, deleted records mess this up. Thanks. Regards, Jim Langston +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.