Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Reading a file backwards

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Reading a file backwards

    Hi All, It's been a while since I did an RPG II project on the S/36, but here goes. I have a requirement to find all a specific clients records in a file, and then read them from end to beginning, or go to the last record for that client and then read the file in reverse, or backwards. Without re-sorting, or creating a new index, is there the equivalent of a SETLL, say SET UPPER LIMIT that can perform this function? Mucho thanks! Howard

  • #2
    Reading a file backwards

    Check the SETGT opcode.

    Comment


    • #3
      Reading a file backwards

      Howard Weintraub wrote: Without re-sorting, or creating a new index You certainly are limitng your S/36 options. Why is using #GSORT or the BLDINDEX command out of the question in this case? Surely your answer lies here. Dave

      Comment


      • #4
        Reading a file backwards

        Joe, TTBOMK, SETGT is not available in RPG II. Dave

        Comment


        • #5
          Reading a file backwards

          Thanks, David! That makes Howard's job harder, though. Howard, if SETGT is not available, then drop another line and we can discuss the possibilities. We can do something with partial keys and *HIVAL and SETLL. Joe

          Comment


          • #6
            Reading a file backwards

            Joe, "We can do something with partial keys and *HIVAL and SETLL" Actually, *HIVAL isn't available in RPG II either. In fact, READP wasn't even available for the first few releases of S/36 SSP. IIRC, it was added somewhere around SSP v4 or so. RPG II isn't even very friendly to partial keys. Unlike RPG III and IV program-described files, RPG II validates the F-spec record length at open time against the file being opened and issues a halt rather than a warning to the job log. It's been awhile, but I *think* if the key length is wrong, it may do the same thing. At any rate, he doesn't need a partial key here. He can define an alpha field the length of the key, and initialize to the equivalent of *HIVAL. In theory he should use BITON '01234567' for each byte, but in practice it may be sufficient to use all 9's using MOVEL '99999999' etc. (RPG II does not have *ALL'9' either.) Then use SETLL with the field, and a READP inside a DOWxx/DOUxx loop. These are a little more messy in RPG II, because you can't use *INxx in the DOW/DOU either. Isn't RPG II fun? The language sure has come a long way since those days! And I can't wait for RPG IV under V5R1... Doug

            Comment


            • #7
              Reading a file backwards

              David, "Why is using #GSORT or the BLDINDEX command out of the question in this case? Surely your answer lies here." If an index already exists, it would be faster to read it backwards using READP than to use #GSORT. You can't specify descending keys, so BLDINDEX is no better than the existing index unless of course it is for diferent key field(s). Assuming the existing primary key (or an existing alt index) is for the correct key field(s), than SETLL to a high value followed by READP is the best you can do. Note that blocking would be disabled by default, by can be overridden with // FILE NAME-xxx,IBLOCK-yyy,DBLOCK-zzz to block either index entries, data records, or both. Doug

              Comment


              • #8
                Reading a file backwards

                Isn't RPG II fun? Okay, I'm out of my element. I don't remember the last time I programmed in RPG II, so I'll leave it in the hands of the experts... >smile<

                Comment


                • #9
                  Reading a file backwards

                  Doug Handy asked: Isn't RPG II fun? So's S/36 COBOL! I have one client for whom I have been developing native applications for years, but they still have a great store of S/36 RPG and COBOL programs. Some of these programs date backe to the S/3! The client has expressed no interest whatsoever in bringing these programs up-to-date. Essentially any conversions I do, I do as a bottom of the barrel priority. The conversion process has been going on for nearly three years, with no end in sight. Occasionally I may have to modify unconverted programs, and because the effort to modify is minimal, compared with the effort to convert, the programs remain in S/36 mode a while longer. I would wince at all of this, but for the fact, that the programs are being used, and the day to day (non-technical) work is getting done. The company is getting along just fine, just the way they are. As I talk with others, I find many who are in similar situations. It is not surprising to have so many S/36 questions appear in these forums. What might be surprising, is that the questioners reach the forums at all. Just as an experiment, take a look at the computer screens at your bank, your gas station, your doctor's office, etc. etc. Take a private survey, as to how many of these screens are character based, as opposed to GUI based. You may be surprised, but then again, you may not. Dave

                  Comment


                  • #10
                    Reading a file backwards

                    Howard, the other problem with #gsort is that if any records are added to the file, they are not available to see until the program is ended and re-started. I can't swear to the availability of SETGT on the /36 becase we used RPGIII from ASNA back in 84 or 85. This gave us most of the Sys/38 RPG/III abilities. We had IFxx/DOxx/CASxx/CABxx/*INxx/FEOD and all sorts of stuff, and it more than possible that SETGT was one of their enhancements. The best bet (I programmed on the /34 and /36 for 8 year) is to create an index. If the client wants to see the records in descending order, use SETLL over the maximum value of the key field. ZZZZZZZZZZ 999999999, etc. If the file is not overly large and there is no reason to modify the records, I would create an array to hold the data and fill it from the file. Read the file in FIFO format, increment the array each time the record is read, keep track of the counter and then when the page keys are pressed, add/sub from the element and load the screen. -bret

                    Comment


                    • #11
                      Reading a file backwards

                      Howard, This sounds like what we used to use a Record Address File for. But, I believe Sort was necessary for it, though. Bill

                      Comment


                      • #12
                        Reading a file backwards

                        Howard, Maybe i'm already too late, but: - You should create a field with a length equal to the key of this file - Fill it with the key you're looking for - Add 1 - Key SETLL File Then, in a loop - READP File (and check if it is still the right customer or whatever checks you need) HTH Leo

                        Comment

                        Working...
                        X