Skip to main content

[archive] R$io/i$io

  • December 13, 2007
  • 12 replies
  • 0 views
D

[Migrated content. Thread originally posted on 03 December 2007]

I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
77 KEY-VAL SIGNED-LONG.
...
*
SET IO-START-FUNCTION TO TRUE.
SET IO-F-NOT-LESS TO TRUE.
MOVE START-KEY TO KEY-VAL CONVERT.
CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


Any assistance on these two issues would be appreciated!

    12 replies

    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    You may want to look at the definitions in filesys.def. I think the correct function for r$io is R-OPEN-FUNCTION
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    You may want to look at the definitions in filesys.def. I think the correct function for r$io is R-OPEN-FUNCTION
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    You may want to look at the definitions in filesys.def. I think the correct function for r$io is R-OPEN-FUNCTION


    Thanks for the response! I had checked that out earlier and the documentation had both I-OPEN-FUNCTION and R-OPEN-FUNCTION defined as the same value, so I had I-OPEN-FUNCTION in both places to try and condense my logic down as much as possible. The open returns successfully, it's the read using r$io that's crashing the runtime.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Sounds like a runtime error. I would report it to Technical support.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Sounds like a runtime error. I would report it to Technical support.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Sounds like a runtime error. I would report it to Technical support.


    D'oh, that's what I was afraid of. Thanks for the help!
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Sounds like a runtime error. I would report it to Technical support.


    D'oh, that's what I was afraid of. Thanks for the help!
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    I created a simple program that allows you to put in one record into a relative file. Then use the push button on the screen to call R$IO. The file get opened.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    I created a simple program that allows you to put in one record into a relative file. Then use the push button on the screen to call R$IO. The file get opened.


    Yeah I can get the file opened just fine with R$IO, but the runtime was crashing when I passed the returned file handle to R$IO to start it for a read. I just went back over the documentation and this looks like it was user error all along. I misread the documentation when trying to condense my code down. R-START-FUNCTION is defined as 7, I-START-FUNCTION is 8, so I was trying to do a write instead of a start. Boy don't I feel dumb! I'm still having the same issue with trying to use an alternate key with I$IO however.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    I created a simple program that allows you to put in one record into a relative file. Then use the push button on the screen to call R$IO. The file get opened.


    Yeah I can get the file opened just fine with R$IO, but the runtime was crashing when I passed the returned file handle to R$IO to start it for a read. I just went back over the documentation and this looks like it was user error all along. I misread the documentation when trying to condense my code down. R-START-FUNCTION is defined as 7, I-START-FUNCTION is 8, so I was trying to do a write instead of a start. Boy don't I feel dumb! I'm still having the same issue with trying to use an alternate key with I$IO however.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Although it may not be very helpful I believe the source to Alfred uses I$IO and it is able to access files based on alternate keys.
    D

    [Migrated content. Thread originally posted on 03 December 2007]

    I'm trying to improve our inhouse toolkits, and am currently writing a hexdump style record viewer using R$IO and I$IO. I'm having a problem with each and was hoping someone here would be able to point out what I need to do differently.

    R$IO: I haven't seen any sample code for this, but assume it works like I$IO. I've read the 7.2 documentation for this call, and set things up like it looks they need to be. I can get a successful open, but when I call it for the START_FUNCTION it crashes on me. Is there something different I need to be doing to start this other than:
    77 KEY-VAL SIGNED-LONG.
    ...
    *
    SET IO-START-FUNCTION TO TRUE.
    SET IO-F-NOT-LESS TO TRUE.
    MOVE START-KEY TO KEY-VAL CONVERT.
    CALL "R$IO" USING IO-FUNCTION, FILE-HANDLE, KEY-VAL, IO-START-MODE.

    I$IO: This works like a champ except for one (seemingly minor) issue. On files with alternate keys, it returns back the correct number of keys when I query for file information. However, when I attempt to start the file it only ever recognizes the primary key. No matter which keynum I pass I$IO it _always_ uses the primary key as the key of reference. Is this a bug or am I doing something wrong?


    Any assistance on these two issues would be appreciated!
    Although it may not be very helpful I believe the source to Alfred uses I$IO and it is able to access files based on alternate keys.

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement