ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Sub-stringed fields in LF

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

  • Sub-stringed fields in LF

    Hi,
    I have encountered something I've never seen before. In a LF there is a 100 byte field labeled as 'unused' in the middle of the DDS. Over time, fields have been carved out of this unused field by sub-stringing the field. Why new fields weren't just added to the end of the DDS I do not know. I can only imagine whomever did it first decided to use some of this empty territory rather than waste it and the next programmer followed his/her lead. Anyway, I need to use one of these existing sub-stringed fields in a program for I/O/U.

    What I'm looking for is guidance as to how to get the data into the program and then write or update it. As you can guess, I have met with some difficulty in doing this hence this posting. Searching the internet was less than helpful.

    ​​​​​​​Any assistance will be appreciated.
    Mike.
    Everyday's a school day, what grade are you in?

  • #2
    In S/36 compatable RPG II programs, the record length must match what is coded on the F-spec for the file or the program will fail with an error. So people will insert huge unused fields in order to be able to add fields while keeping the record-length constant.

    If you are not using the S/36 environment, then I agree with you that it'd be better to avoid the 'unused' fields and just add new fields onto the end.

    With regards to your question about getting data into the program and write/update, I'm not sure that I understand the challenge. Why can't you do that?

    Comment


    • redvan
      redvan commented
      Editing a comment
      Well,
      I have tried but have not been successful. Realizing that the sub-stringed fields are part of a larger field, I used a data structure and defined each field for it's length then used the parent field in exception output but things are not lining up properly. SO, I wanted to know if there was some unknown to me consideration or trick to getting this to work. I wasn't asking you to do it for me.

  • #3
    What I've always done is reduce the size of the larger field, and insert a new field after it. This keeps the positions of all of the existing fields and keeps the record length the same. Then, you can recompile any programs that are checking the format level id to pick up the new definitions, and all is well.

    I've never tried the data structure approach you're taking. It sounds like it'd work (if coded properly) but I haven't tried it, so not sure what all the caveats might be.

    Comment


    • #4
      I've used an overlay DS approach for a similar scenario in the past with no issues so I don't believe there's any additional considerations needed. If the substring is working, then surely a DS would have to work for it.
      Are you using positions for the definitions of the fields? Positions might be an easier way to tackle this since you'd have those numbers already.

      Comment


      • #5
        redvan, can you show how you defined your data structure?

        Comment


        • #6
          All,
          I discovered that the issue was my error in the positioning, I was off by one in the data structure for the remaining space. There were three fields at the beginning then the remaining space then another field on the end. Don't know why they didn't just continue after the last field but this is what they did.

          Thanks for the help.
          Everyday's a school day, what grade are you in?

          Comment

          Working...
          X