Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

DSPRCDFMT -- An API Alternative to DSPFFD

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

  • DSPRCDFMT -- An API Alternative to DSPFFD

    ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
    ** This thread discusses the Content article: DSPRCDFMT -- An API Alternative to DSPFFD0

  • #2
    DSPRCDFMT -- An API Alternative to DSPFFD

    ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
    We have been using the dsprcdfmt (LO command) for many years and are very happy with the command. However we just recently went from V5R1 to V5R2 and the QUSRTVUS API is no longer working. We are getting the following error,"The call to program QUSRTVUS ended in error (C G S D F)" with higher level messages of, "Value 155905152 for starting position parameter is not valid", "Length of data is not valid" and "Information not retrieved from user space". If anyone has ran across this and knows how to fix it, please let us know. Your help would be greatly appreciated. Tim

    Comment


    • #3
      DSPRCDFMT -- An API Alternative to DSPFFD

      ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
      I have been using a similar command to DspRcdFmt called DFF (Display File Fields, or "Format Fields" if you will) for many years also; I never use DspFFD because hard-to-read. However, we are not at V5R2 yet so I have not run across any problems with QUsRtvUs yet. I suspect that the problem is using an incorrect offset to the data portion. I got a similar error on a client box running V3R7 or V3R6, many years ago; but I never got a chance to fix the problem. Your offsets to the data portion of the User Space should not be hard-coded (I haven't read the article yet); they should come from the control section. That way, no problems going from release to release when IBM changes the offsets. If that is not the problem, maybe an APAR is in order. However, you could read the User Space directly with MI. I havn't tried this yet; but it should not be too hard. Hope this helps! If you like, I can send source for the DFF command; you could compile it and see if it fixes the problem with calling QUsRtvUs. Rich Hart

      Comment


      • #4
        DSPRCDFMT -- An API Alternative to DSPFFD

        ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
        I checked out the article just now. Well, it works (or DID until V5R2!), but it is a bit crude. The author first reads the UsrSpc to get the Data_Section_Offset, _Number_of_Entries, and _Entry_Length. However, the first read is in the middle of the Control Section and overlaps into the Header section to get the File_Name, et cetera. This is very hard to understand. The first read should be to the control section. It should always be 128 bytes; the length of the control section is at User_Space_Offset 65 (base 1, not base zero!). Then, the next read should be to the Header area to get the File_Name, etc. Then finally loop thru the data section to get the field information using the offset and entry length from the Control Area. Using separate internal data structures to hold (1) the Control info (2) Header info (3) Field detail info makes the program easier to understand, albeit a bit longer. I had forgotten that there is another way to read a User Space (which is the method I use) without resorting to MI...as fast and fun as that might be! You can call the QUsPtrUs API to get a pointer to the User space (or use the RsvlSp instruction!) and read it that way. This method bypasses using the QUsRtvUs API altogether. But, either method should work, provided the offsets are correct and no IBM fix is needed. Again, I have source available upon request. Rich Hart

        Comment


        • #5
          DSPRCDFMT -- An API Alternative to DSPFFD

          ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
          Hi Rich. I also use the DSPRCDFMT all the time. We will be upgrading to V5R2 soon. May I see the source on how you fixed this? And also, can you describe also how the QUsPtrUs API works. Thanks in Advance. Danny.

          Comment


          • #6
            DSPRCDFMT -- An API Alternative to DSPFFD

            ** This thread discusses the article: DSPRCDFMT -- An API Alternative to DSPFFD **
            Hi Danny, I will answer your second question first, about how the QUsPtrUs API works (you call it using all caps; but I like to mix cases for readability). Here is the relevant information from the IBM "OS/400 System API Reference" manual: The "Retrieve Pointer to User Space" (QUSPTRUS) API retrieves a pointer to the contents of a user-domain user space. The data in that user space then can be directly manipulated by high-level language programs that support pointers, such as C or COBOL. [and now, RPG!] The QUSPTRUS API will not return a pointer to a system-domain user space; you must use system APIs to access system-domain user spaces. If you attempt to retrieve the pointer to a system domain user space, an error will be returned. Thus saith IBM. Don't worry about the system domain spaces; any User Space created by the // DspRcdFmt tool will be in the user domain! There are just two parms to pass to the QUsPtrUs API, the twenty-byte fully qualifed User Space name (Name + Library, both left adjusted), and the Pointer return variable. The API returns a pointer to the space, assuming that it exists. Armed with the pointer, you can then read the Space directly, no call to QUsRtvUs is needed (that is, with ILE RPG or another language that supports pointers). About your first question: After playing with // DspRcdFmt all weekend, I am sure that there is no problem with the IBM QUsRtvUs API. The magic is in using the right offsets. More about this later!

            Comment

            Working...
            X