Can I cast literal values?

This is rather a COBOL related question than a Micro Focus related question, I'm afraid:

From other programming languages I'm used to be able to provide literals instead of data items when I'm using them as a constant value (a so-called "r-value").

When such compiler complains that it doesn't know how to coerce the literal value to an expected data type, I'm usually able to add a cast modifier to that literal value, so the compiler will know how to store the literal value.

Is it possible in COBOL, too, to enter such literal and provide a casting expression along? E.g.:

CALL "PrintThis" USING BY CONTENT "This is a test." AS PIC A(50).

  • Not in traditional COBOL. Casts are a feature of Micro Focus managed COBOL (COBOL for .NET or JVM), but only to managed types, not traditional COBOL types.

    It's not clear what you're trying to achieve in your example. The "." character is not valid for PIC A(n), so you couldn't use the string "This is a test." for a PIC A(n) item anyway. The type of a passed parameter is determined by the linkage section of the called program, assuming it's COBOL; but in any case its type - that is, how the parameter is interpreted - is determined by the target, not the caller. There are cases where a parameter can be interpreted as a general type which contains enough information for the target to discern a more-specific type, but the initial type determination is always made by the target. None of the platforms supported by MF COBOL use ABIs which include precise type information with call parameters (and such ABIs are rare in general-purpose computing).

    A couple of unrelated comments:

    • Don't use BY CONTENT unless you have a reason to do so. It's inefficient.
    • Don't end statements with periods. While that was common in traditional COBOL, it can make the flow of execution non-obvious. Many modern COBOL developers recommend using COBOL-85 scope terminators (END-IF, etc); only using periods where required (e.g. after a paragraph/section name and at the end of a paragraph/section); and putting the period on a separate line, so it stands out visually, when it comes after a statement.

    So for example:

    do-something section.
        call "XYZ" using abc move foo to bar   .


  • You are right. I may have been unclear with my question.

    Actually, I took my original code from another question as a template for this question.

    In that code, I accidentally(?) used a literal value to call another program instead of having that literal value declared in the WORKING-STORAGE SECTION first.

    The approach of declaring a constant value in the WORKING-STORAGE SECTION first just to use it once seems cumbersome to me. That's what brought me to ask if there may be an abbreviated syntax available, merging a 2-step process into one, i. e.:

    Instead of being required to write:

        01 tLabel PIC X(25) VALUE "Test".

      CALL "PrintValue" USING BY CONTENT tLabel

    being able to just write:

      CALL "PrintValue" USING BY CONTENT tLabel AS PIC X(25)


    PS: Thank you for your valuable suggestions. I comprehend about the finalizing dot. I just added it to this single line of code to give a visual cue. I also apprehend about the ramifications of the CONTENT modifier.

  • Verified Answer

    In COBOL, one have to define the data in the Data Division before using it in the Procedure Division.

    That is the way the language was defined, and, from my experience with COBOL, it is a very good control, otherwise, declaring variables in the PD will make the programs difficult to maintain.

    That is my personal opinion, I have worked with COBOL from S/360 with punched-cards, while in the university, all the way to MF COBOL Visual 5.0. A long journey.


    Best regards


  • Depending on your requirements, you might want to look at managed COBOL, which provides a lot of syntactic sugar, including inline declarations and casts for managed types (though not traditional COBOL data items, as the PICTURE clause is still only recognized in the data division).
  • Thanks, for your very informative information about Managed COBOL.

    At this time, I'm learning traditional COBOL, that's why I marked 's reply as the most appropriate answer to my question. Managed COBOL will be by next step in my learning curve. So, your hints will surely become very useful in the near future to me.