COBOL

COBOL

COBOL

COBOL is responsible for the efficient, reliable, secure, and unseen day-to-day operations of the world's economy.

 View Only
  • 1.  Unstring Problem

    Posted Thu January 21, 2016 02:22 PM

    Hi guys.

    Iam testing a program, so it basically read a register with 10 or more PICTURES, put them all into one string with a ";" between the fields.

    Then iam trying to unstring this string (only for test purpose) and put the infos into other pictures, but iam having problems.

    Unstring command work's well for the first 2 fields, then, bug everything.

    Someone can help me? Iam a beginner.

    Sorry for my poor english, i don't have much time to write this now.

    RELCAD01.TXT contains both, String (with work percefctly how i want), and into the next line, the unstring, where work only first 2 camps.

    Thanks everyone.

     

    PauloQuadros


  • 2.  Re: Unstring Problem

    Posted Thu January 21, 2016 06:54 PM

    This is a forum for IBM COBOL compilers. Are you using an IBM COBOL compiler? Or some other compiler?

    You have two problems.

    The first is that after you WRITE your record, you attempt to use the data in the FD. This is compiler-implemenation dependant, and can be affected, perhaps, by options/switches.

    Generally, in IBM Mainframe compilers, when you OPEN an output file your FD is pointed to an "output buffer". When you WRITE a record, the address of the FD is changed to the next available area for new data (if a buffer is filled, this address may be in a new buffer, and at some point buffers will actually be written to the physical media).

    Even your compiler does not do that (and I think it doesn't, at least with whatever switches you are using) it is not a good idea to do that. So don't attempt to use a record after you have written it.

    The second problem is that you have two record-areas defined for output under the same FD. This is an implicit REDEFINES in COBOL. Which means that both record-areas have the same address. Using UNSTRING with the same address for source and destination is undefined behaviour.

    If you define a separate file for your fixed-length output, or define the second output-record in the WORKING-STORAGE SECTION, and if you do the UNSTRING before the WRITE you should get your results.

    There are a number of other issues with your program. You need to find a site which deals with your compiler specifically, or look to ask questions on a more general site, like StackOverflow, for instance.

    From the DISPLAY MESSAGE BOX I'd guess you have a Micro Focus COBOL. They offer very good support on their website, although I don't know how they deal with beginners' questions.

     

    BillWoodger


  • 3.  Re: Unstring Problem

    Posted Fri January 22, 2016 06:27 AM

    Iam using Micro Focus COBOL, and iam using c60 for compiling, sorry about that.

    Well, using a Working Storage String solved my problem, now this work perfectly.

    Thank you so much!

    PauloQuadros


  • 4.  Re: Unstring Problem

    Posted Fri January 22, 2016 07:29 AM

    A bit more explanation.

     

    05 RELCAD02-UNSTRING-COD pic X(03) value SPACES.

                   05 RELCAD02-UNSTRING-NOME pic x(50) value spaces.

     

    unstring RELCAD01-STRING delimited by ";" or spaces into

    RELCAD02-UNSTRING-COD

    RELCAD02-UNSTRING-NOME

     

    The "or spaces" is the problem. The first element is a maximum of three bytes long. Not particularly relevant to the problem. The second element is a maximum of 50 bytes long. In your test-data, the maximum length for that element is 13 characters. When the UNSTRING processes that, it will implicitly MOVE the data, padding with space for unused bytes in RELCAD02-UNSTRING-NOME. Since your two 01-levels reference the same area, your remaining fields each get "nothing", padded by blanks, because of the specification of "spaces" as a delimiter. "spaces" on UNSTRING, as with any figurative-constant, is one byte long. If you want to delimit by spaces, then using "all spaces" or "all space" (they are equivalent) would do.

     

    Considering it is a name field of 50 characters anyway, it is likely to contain embedded spaces when you have any realistic test-data.

     

    Despite you getting the results you expect with your test-date, you do need quite a bit more work on the program. For instance, you are using PEFORM ... UNTIL ... and then you are doing a GO TO loop inside the PERFORM. Favour the first. You are using SECTIONs, but not consistently. There is no problem this time, but next time there may be. Your sequence to OPEN the file is... unusual. Etc. You have a fair start, but need more work.

    BillWoodger