The Micro Focus Developer doc related to CBL_GET-CURRENT-DIR suggests this:   "Use the "BY VALUE LENGTH OF directory-name SIZE 4" construct to pass the name-length parameter."  Based on the explanation in the doc, if I have a MY-DIR-NAME PIC X(80 and a MY-DIR-NAME-LENGTH PIC 9(4) then I can MOVE LENGTH OF MY-DIR-NAME TO MY-DIR-NAME-LENGTH in order to initialize it to a value of 80 in this example.  My question is about the terminology and concept of the "Use the "BY VALUE LENGTH OF directory-name SIZE 4" construct.  I would like to see an example of this and/or any links to doc explaining this concept behind this construct.

Thanks!

OK, Update.

I now can see how it might be used.  Instead of setting up an actual MY-DIR-NAME-LENGTH variable in working storage to be initialized with the length of MY-DIR-NAME, you can just use the expression "BY VALUE LENGTH OF MY-DIR-NAME SIZE 4" as a phrase at the appropriate point in the CBL_GET_CURRENT_DIR library routine/command, thereby eliminating an extra variable and a separate statement to initialize it.  However, the "SIZE 4" part... where is this explained?

 Thanks,

Hello Eric,

A suggestion about locating the programs that reference a given file. In Visual COBOL for Eclipse, you can search for a string that appears in files in all open projects. This is done using the menu option Search->File (the shortcut for this is CTRL-H), then enter desired string in the "containing text" field . By default, this will search all of the open projects in the current workspace. However, you can also constrain the search to a "working set", which is a subset of projects (for this workspace) that you would have previously defined.

Since this will only search open projects, you'll need to first be sure all projects you want searched are open in Eclipse.

Cool thanks! That worked perfectly.

Is a cobol file conversion program needed or is there a tool to increase the Record Size of an existing file?

Hi Eric,

There is a utility provided with Visual COBOL that includes the ability to expand a file. The utility is named "rebuild". The rebuild utility has many different capabilities, but one of these is to copy an existing file and specify the record length of the newly created copy. This is done using the /r option (use -r on Unix). Here is an example:

Let's say I have a file that is 190 bytes in length. I can see a report about the file using the -n option of the rebuild command:

$ rebuild -n BLAIRF190.DAT

       File                             :   BLAIRF190.DAT

       Organization                     :   Indexed

       Format                           :   IDX-8

       Recording Mode                   :   Fixed

       Compression                     :   N

       Maximum Record Length           :               190

       Minimum Record Length           :               190

       Index Node Size                 :             1024

       Number of data records           :                 1

       Data Created With Extfh Version :             19999

       Last Updated With Extfh Version :             19999

       Key Description (where 'Start' is measured from offset 1):

         Key       Start     Length     Dupl     Key Comp   Sparse Char

           0           1         6       N

Now, I can use the -r option of the rebuild command to create a copy of the file with a record length of 200 bytes:

$ rebuild BLAIRF190.DAT, BLAIRF200.DAT -r:f200

BLAIRF190.DAT, BLAIRF200.DAT -r:f200

Rebuild successful - records read =         1

Finally, I can view the information about my new file to confirm the record length:

$ rebuild -n BLAIRF200.DAT

       File                             :   BLAIRF200.DAT

       Organization                     :   Indexed

       Format                           :   IDX-8

       Recording Mode                   :   Fixed

       Compression                     :   N

       Maximum Record Length           :               200

       Minimum Record Length           :               200

       Index Node Size                 :             1024

       Number of data records           :                 1

       Data Created With Extfh Version :             19999

       Last Updated With Extfh Version :             19999

       Key Description (where 'Start' is measured from offset 1):

         Key       Start     Length     Dupl     Key Comp   Sparse Char

           0           1         6       N

There are many options for the rebuild command, and it does require some care in use. One recommended step is to always ensure you have a backup of a file before you attempt to modify it with rebuild. You can find documentation of the rebuild command's options in the Visual COBOL for Eclipse documentation here:

Finally, I should mention that by default, the added bytes in an indexed file are filled with hex zeros (low values). As you'll see in the documentation, the -r option does include a way to specify the fill character used.

Wow, that is exactly what I was hoping for ...

Its a shame we don't use copybooks, or it would be a simple 5 minute fix for all programs/systems that require a record size adjustment.

Thanks for taking the time to respond, I'm so used to doing this the hardway, I thought I could ask and hope to find a better method.

Which you provided, Thanks again.

Eric Boatman

You don't say what version of Visual COBOL for .NET you're using. With recent dialects, it would be something like the following:

method-id. limparTextBoxes.
procedure division using by value controles as type Control.ControlCollection.
    declare ctrl as type Control
    perform varying ctrl through controles
        if ctrl instance of type TextBox
            declare tb as type TextBox = ctrl as type TextBox
            set tb::Text to string::Empty
        end-if
    end-perform
end method limparTextBoxes.

I haven't tried that. I didn't use all the most recent syntax enhancements, since I don't know which ones your version of Visual COBOL supports.

I have a solution for converting the screens dialog system for VS2013, look at mmsis.com.br/converter.htm

I want to convert a NetExpress solution that has dialog system screen into Visual Cobol,  I have the Visual cobol on a separate laptop than the current NetExpress project.  Is there a standalone DIalog systems download that I can install on my new laptop to look at the screens for the new solution?

private void limparTextBoxes(Control.ControlCollection controles)

{

    foreach (Control ctrl in controles)
    {     
        if (ctrl is TextBox)
        {
            ((TextBox)(ctrl)).Text = String.Empty;
        }
    }
}

To call

limparTextBoxes(this.Controls);

Thank you for your help. Your example works to forms without containers and in this post I forgot to specify this. I got as follows, do not know if it's the best way, but it works.

method-id tsBtnLimpa_Click final private.

procedure division using by value sender as object e as type System.EventArgs.

   invoke limpaCampos()

end method.

method-id. limpaCampos public.

    *> le os controles dentro do (container) panel principal        

    perform varying myobj as type Control thru self::panel::Controls

         *> limpa os textboxs dentro do panel principal

         if myobj instance of type TextBox

            declare tb as type TextBox = myobj as type TextBox

            set tb::Text to string::Empty

         end-if  

         *> limpa o checkBox dentro do panel principal

         if myobj instance of type CheckBox

            declare tb as type CheckBox = myobj as type CheckBox

            set tb::Checked to false

         end-if            

         *> limpa o maskedTextBox dentro do panel principal

         if myobj instance of type MaskedTextBox

            declare tb as type MaskedTextBox = myobj as type MaskedTextBox

            set tb::Text to string::Empty

         end-if          

         if myobj instance of type GroupBox

            *> limpa os controles dentro dos containers GroupBoxs

            perform varying ctrl as type Control thru myobj as type GroupBox::Controls

                   *> limpa textboxs

                   if ctrl instance of type TextBox

                      declare tb as type TextBox = ctrl as type TextBox

                      set tb::Text to string::Empty

                   end-if

                   *> limpa maskedTextBoxs

                   if ctrl instance of type MaskedTextBox

                      declare tb as type MaskedTextBox = ctrl as type MaskedTextBox

                      set tb::Text to string::Empty

                   end-if  

            end-perform

         end-if  

    end-perform

end method.

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.

http://documentation.microfocus.com:8080/help/topic/com.microfocus.eclipse.infocenter.visualcobol.eclipsewin/HRLHLHDPF60RU031.html?resultof=%22%42%59%54%45%2d%4d%4f%44%45%2d%4d%4f%56%45%22%20

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

http://documentation.microfocus.com:8080/help/topic/com.microfocus.eclipse.infocenter.visualcobol.vs2012/HRCDRHCDIR8G.html?resultof=%22%42%59%54%45%2d%4d%4f%44%45%2d%4d%4f%56%45%22%20

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 ....

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

You may need to specify NO LOCK in the READ statement.  RM/COBOL doesn't try to lock a record when a file is only open INPUT, but Visual COBOL might.

Several details are missing from your description of the problem:

(1) Did you compile with directive dialect(rm)?

(2) Have you converted your data files to Micro Focus format or are you using filetype(21) directive at compile time and the original RM/COBOL data files at runtime?

(3) What do your lock mode clauses say (if there are any) and what does your OPEN statement say, both for the application and the report program(s)?

(4) Can you provide a small test case that demonstrates exactly what you are doing?

WITH IGNORE LOCK is a Micro Focus Visual COBOL option in the READ statement for relative and indexed files (not sequential organization files).  It might resolve your problem.

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   

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

In the Read statement on the maintenance program that is doing the I-O read?

1.  With MF's help, our programs were converted using their modernization tool & then editing by our staff - we are NOT using dialect(rm)

2.  We converted our data files to MF

3.  We do not use any lock clauses so whatever is the default is in play.

As I stated in my original post,  WITH IGNORE LOCK will not compile. The compiler in says IGNORE is invalid.  The files in question are indexed files.  We do have the RETRYLOCK in our cobol.dir file.

4. Regarding test case - very simple.  Program A - maintenance program does a read on a I-O file. The report program has the file opened for input.  Does a start on the file and then a read next.  If someone is sitting on a record in program A, the report program will lock up or stop at the point where it  tries to read the record open in Program A.

select file assign to random "apy68"

    organization is indexed

     access mode is dynamic

     record key is file-key

*****select has multiple alternate keys as well.

Program A:

open i-o file

.

.

.

move co-no to file-co-no

move location to file-location

move item-no to file-item-no

read file invalid key

  close file

  exit.

Report Program

open input file

.

.

.

.

move location to file-location

move co-no to file-co-no

move space to file-item-no

start file key not less than file-key

  invalid key  move error-msg

                     display error-msg.

if not eof

  read file next record

      at end move "Y" to eof.

The conversion tool for RM/COBOL to Visual COBOL provides a directives file legacy_dialect.dir that removes the IGNORE keyword from the language.  This is because IGNORE is not an RM/COBOL reserved word.  The RM/COBOL program may have used IGNORE as a user-defined word and errors would happen if it was a reserved word.  Assuming your particular programs do not use IGNORE as a user-defined word, edit the legacy_dialect.dir file to comment out the "remove(ignore)" line by changing it to "& remove(ignore)".  Then there should be no problem with a READ statement that specifies the "WITH IGNORE LOCK".  If specifying NO LOCK is not sufficient for Visual COBOL to read through locks, then the IGNORE LOCK option is your best alternative.

One more thing.  The tool also provides a directives.dir file that contains the remove(IGNORE) directive.  The legacy_dialect.dir file is used during the conversion process.  The directives.dir file is the one that you need to comment out the remove(IGNORE) directive.  My regrets for not stating this in the earlier response.