Move part of textfield to itself

We are running Microfocus Cobol in a Linux Environment and recently upgraded to VisulCobol 2 2 1.

We have discovered a couple of things where this version is acting in a different way compared to our old one.

I have one example that I would like to share. Maybe someone else has faced the same problem.

example:

01     W-INIT    PIC X(20) VALUE '1234567890ABCDEFGHIJ'.

01     X1          PIC X(20) VALUE SPACE.

MOVE W-INIT TO X1

MOVE X1(10:10) TO X1(11:10)    

After the second MOVE X1 will contain '12345678900000000000' .

It seems like the tenth position,"0" in this case, will duplicate into position 11 and 10 positions forward. This is a different behaviour compared to our previous version where it worked fine.

If moving to a new variable it works fine, but if you are trying to move around within the same variable you get this problem.

There is of course a simple way to work around this problem by moving to another variable but this kind of sourcecode are in quite a lot of places so I would prefer another solution. Compile-option or something like that.

Anyone had this trouble?

best regards

Peter   

 

  • I think the result of the MOVE is correct. 40 years ago I used this with assembler programming. Effectively it is a loop of moving 1 character 10 times. Position 10 to 11, 11 to 12 etc.

    Freundliche Grüsse

    Werner Lanter

  • The compiler directive BYTE-MODE-MOVE controls this behavior.  You seem to be depending on NOBYTE-MODE-MOVE, which is documented as the default.  The behavior you describe is BYTE-MODE-MOVE, as done by IBM mainframes.  It would take some research and some answers from you to know why the behavior changed for you.  It's possible the default was changed to BYTE-MODE-MOVE in the new version.  Alternatively, you may have accidentally set the BYTE-MODE-MOVE directive, possibly in a configuration file that you did not know you were using.  You could use the $SET SETTINGS directive at the beginning of your source file to see what directives are set for your compilation.

  • Hi Guys

    Thanks for your incredibly fast answers.

    Bruce, I figured there could be some compilers declaratives issues so I was reading them through when your answer arrived.

    I tried to set the BYTE-MODE-MOVE, I didn't really know the difference , and tested.

    As you say, the NOBYTE-MODE-MOVE should be the default and I think it is.

    I followed your suggestion, putting in the $SET SETTINGS in the source file and got this among other things:

    Setting: NOACCEPTREFRESH NOACU NOACUCOMMENT NOACU-UNDERSCORE NOADV ALIGN"8"

    *          ALPHASTART"1" ALTER NOAMODE ANIM ANS85 APOST NOAREACHECK ARITHMETIC

    *          "MF" ASSIGN"EXTERNAL" NOASSIGN-PRINTER NOAUTOLOCK NOBELL BINLIT

    *          "NUMERIC" BOUND NOBRIEF NOBS2000 BWZSTAR NOBYTEMODEMOVE CALLFH

    *          "EXTFH" NOCALLMCS NOCALLRECOVERY CALLSORT"EXTSM" CANCEL CANCELLBR

    *          NOCHANGEMESSAGE CHARSET"ASCII" CHECKDIV"ANSI" NOCHECKREFMOD NOCICS....goes on forever....

    NOBYTEMODEMOVE seems to be the default.

    I tried both options but I didn't see any difference.

    I still think the solution to this and some other odd things that have occurred lies in these declaratives.

  • Hi

     

    Micro focus class overlapping moves as undefined.

    "">documentation.microfocus.com:8080/.../HRLHLHDPF60RU031.html

     

    Micro focus allow some control using byte-mode-move directive.

    "">documentation.microfocus.com:8080/.../HRCDRHCDIR8G.html

     

    basically when doing overlap move output can only be controlled using byte-mode-move

    using this code

    >>>>>> 

           01 WS-SOMEFIELD               PIC X(26).

     

               MOVE "ABCDEFGHIJKLMNOPQRSTUVWXYZ" TO WS-SOMEFIELD

               display "before WS-SOMEFIELD <", WS-SOMEFIELD, ">"

               MOVE WS-SOMEFIELD(3:10) TO WS-SOMEFIELD(4:10)

               display "After WS-SOMEFIELD <", WS-SOMEFIELD, ">"

    >>>>>> 

    Without byte-mode-move

    before WS-SOMEFIELD <ABCDEFGHIJKLMNOPQRSTUVWXYZ>

    After   WS-SOMEFIELD <ABCCCEFGGIJKKNOPQRSTUVWXYZ>

    Press enter ....

     

    Using byte-mode-move

    before WS-SOMEFIELD <ABCDEFGHIJKLMNOPQRSTUVWXYZ>

    After WS-SOMEFIELD <ABCCCCCCCCCCCNOPQRSTUVWXYZ>

    Press enter ....

     

    The output will change depending 32 or 64 bit or the underlying CPU used, moving overlapping items is truly undefined and should not be relied upon.

     

     

    >>>>>>> moving the data backwards will work thou, just a possible work around

           identification division.

           program-id. Program1.

          

           environment division.

           configuration section.

     

           data division.

           working-storage section.

           01 WS-SOMEFIELD               PIC X(26).

           01 ans                         pic x.

           01 movelength                 pic 9(4) comp.

           01 startfrom                   pic 9(4) comp.

           01 startto                     pic 9(4) comp.

           01 i                          pic 9(4) comp.

           01 j                           pic 9(4) comp.

     

           01 ptrStr       pointer   value null.

           linkage section.

           01 lkStr         pic x     any length.

          

           procedure division.

           main section.

           main-010.

          

               MOVE "ABCDEFGHIJKLMNOPQRSTUVWXYZ" TO WS-SOMEFIELD

               display "before WS-SOMEFIELD <", WS-SOMEFIELD, ">"

               MOVE WS-SOMEFIELD(3:10) TO WS-SOMEFIELD(4:10)

               display "After WS-SOMEFIELD <", WS-SOMEFIELD, ">"

         *

         * move backwards make sure copy okay,

         * no validation of movelength as demo

         *

               MOVE "ABCDEFGHIJKLMNOPQRSTUVWXYZ" TO WS-SOMEFIELD

               move 10 to movelength

               move 3 to startfrom

               move 4 to startto

         *

         * Using pointers to make generic routine

         *

               set ptrStr to address of WS-SOMEFIELD

               set address of lkStr   to ptrStr

               compute i = startfrom movelength - 1

               compute j = startto movelength - 1

             display "before WS-SOMEFIELD <", WS-SOMEFIELD, ">"

               perform movelength times

                 move lkStr(i:1) to lkStr(j:1)

                 subtract 1 from j

                 subtract 1 from i

               end-perform

               display "after WS-SOMEFIELD <", WS-SOMEFIELD, ">"

               display "Press enter ...."

               accept ans

               .

           main-090.

     

               goback.

     

           end program Program1.

    >>>>>>>>> 

     

    >>>>>>>output from above program

    before WS-SOMEFIELD <ABCDEFGHIJKLMNOPQRSTUVWXYZ>

    After WS-SOMEFIELD <ABCCCCCCCCCCCNOPQRSTUVWXYZ>

    before WS-SOMEFIELD <ABCDEFGHIJKLMNOPQRSTUVWXYZ>

    after WS-SOMEFIELD <ABCCDEFGHIJKLNOPQRSTUVWXYZ>

    Press enter ....

    >>>>>>>>>>>>> 

     

  • Hi again,

    Thanks for your input.

    I have tested to compile with NOBYTEMODEMOVE och BYTEMODEMOVE but there is no difference. I get exactly the same result.

    I managed to finf our old environment and compiler which was 5.0 and compiled my program with the $SET SETTINGS-option and then compared the declaratives between the two Environments and there are some differences of course, but both had the NOBYTEMODEMOVE set.

    I run a test with the program compiled in the old Environment and I clearly get a different result. Not fully correct either, when I look into it more deeply, so I think I will just grab the bull by the horns and correct the programs using this kind of move instead of searchning for compiler options to solve it.

    Thanks again for your input.

    I have another, even more confusing, problem which started when we switched version and I may post it,

    if my fiddeling with the declaratives don't work.

    /pi