ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Referencing data structure subfields by posn

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

  • Referencing data structure subfields by posn

    I have a data structure that contains about 35-40 subfields, all of different lengths, all of them alphanumeric. I need to concatenate them together, separated by | to form a character string. Is there a way to reference the subfields by relative position in the data structure:

    Example:

    Data Structure is named DS

    SomeString = DS.1 + '|' + DS.2 + '|' ........................+ DS.35).

    I would like to concatenate all the subfields in a FOR .......ENDFOR loop instead of having 35 SomeString = statements.. Since the fields are not the same attributes, I cannot redefine them as an array or I would, hence this idea.

    Any ideas, suggestions?

    Much Thanks


  • #2
    If there is no concern with trimming the blank space between the fields, then you could just do it all in the data structure definition, no calculations necessary:
    Code:
    dcl-ds DS;
      field1 char(10);
      *n char(1) inz('|');
      field2 char(20);
      *n char(1) inz('|');
      field3 char(5);
      *n char(1) inz('|');
      ...etc.
    end-ds;

    Comment


    • #3
      What are you doing with the concatenated string? Writing it to an IFS file? Sending the string to a web service? Depending on what you want to do with it I can think of a couple of solutions that would work for you.

      Comment


      • #4
        Originally posted by JonBoy View Post
        What are you doing with the concatenated string? Writing it to an IFS file? Sending the string to a web service? Depending on what you want to do with it I can think of a couple of solutions that would work for you.
        I would be writing it to the IFS. I am told the business partners I would be sending it to don't want the carriage return or line feed (CR/LF) characters

        Thanks

        Comment


        • #5
          Well they must need some kind of record delimiter surely but ...

          If you can't change the DS the way Brian said, simply clone the DS with the new version including the |s as Brian showed - then use EVAL-CORR to copy the fields from the original to the new one.

          If you want a more generic solution (perhaps they will want more of these in the future) then there are lots of ways to do it - many of which would require that you create an external file definition that mirrors the DS.

          You could use either Open Access or DATA-GEN for this. DATA-GEN might be better in that it is designed to work from a DS. But it may not feed you the full length fields, not sure. Bigger problem is that the compiler will add the CR/LF to each record I suspect. Or you could just have it write to a buffer and then write that to the IFS yourself. Are you sure they won't accept CRLF? - it is a rather unusual requirement.

          Using OA would require the external file description, then write a handler. You could very easily and quickly modify the CSV writer that I described here - https://authory.com/JonParisAndSusan...With-Templates - the code is downloadable. You would need to replace the use of a comma by a | and omit the CRLF if they insist. If they want fixed length field fields then just remove the Trim logic.

          Once the program is changed simply declare a file with the hander specified and perform the Write from the DS.

          It would take me about 15 minutes but I'm familiar with the code so give yourself 30 <grin>

          As I say though - DATA-GEN is a better and more obvious fit (assuming you are on v7.3+) but you'll have to write the generator yourself using an IBM example as a guideline.

          Other methods would involve using the system tables to obtain the field lengths/offsets and then substring them out of the DS in a loop processing each field in turn. etc. etc.

          Comment


          • #6
            Originally posted by JonBoy View Post
            Are you sure they won't accept CRLF? - it is a rather unusual requirement.

            No, I am not sure, just what I was told. They saw the CR/LF when they viewed a file I sent them in NOTEDPAD ++ (souped up 3rd party counterpart to NOTEPAD, it allows you to view the CR/LF, hex and other stuff you can't see in Notepad) and told me that was causing a problem in loading the file into their system and asked me to resend the file with CR/LF removed, a case of faulty cause and effect analysis, I suspect. Most likely, once they see what removing them produces, they'll probably relent and I can file the request under the "Keep producing solutions until you find one that remedies the problem" category.

            Comment


            • gregwga50
              gregwga50 commented
              Editing a comment
              Sorry, places the /QUOTE in the wrong place. Can't edit

          • #7
            OK - so pick one of the options I gave you and go for it. Just make sure they put the "remove it" request in writing!

            Whatever are your "business partners" doing with this stuff?

            Comment


            • #8
              Can't you use %SUBST?

              Comment


              • #9
                Originally posted by JonBoy View Post
                Whatever are your "business partners" doing with this stuff?
                They are going to load the information I send them into https://dynamics.microsoft.com/en-us/ for the sales force to be able to use. In doing some fiddling of my own, I FTP'd a DB file from one of our iSeries box's to another one and presto no CRLF's in the target file. However, I FTP'd the same file to their platform using /Folder/subfolder/filename.dta format and it had the CRLF's in it when it got to them. So, apparently the CRLF's get put in during the FTP process.

                Comment


                • #10
                  Actually that makes their choice of data format even more surprising since most services of that nature (including this one I'm prepared to bet) use a web service to upload data. You could probably just short circuit the whole process and do the upload direct from your IBM i.

                  As to the CR/LF - the IBM i does not add them when FTPing records to another IBM i because the system does not use record delimiter characters - doesn't need them as all records are fixed length and the length is determined by the external description. Windoze on the other hand uses CR/LF so that gets added on the receiver's end.

                  Comment


                  • #11
                    FTP standards require software to add CRLF during transmission in ASCII mode. Unix/Mac software in ASCII mode will add a CR to each line when sending and remove it when saving. If you are sending a record-based file on IBM i, it will add CRLF to each record during transmission, and remove the CRLF when saving it to the resulting record-based file. If you send data in BINARY mode none of this happens.

                    Comment

                    Working...
                    X