Currency Sign needs at point of RUNNING a suite of programs

[Vincent (Bryan) Coen]

I have an Accounting suite tht in some small cases requires a currency sign to be used on a very limited number of reports. One example is on a Payroll system for the printing of payment documents.

Now at the point of compiling the system I cannot know what that sign will be i.e., $, £ or another so cannot use it in the source code.

How do I change it to the required one (may be via the system parameter file field when running the applications ?

One idea I had was to inspect and change any $ (say as set in the pictures requiring it with the replacement such as pound, euro etc prior to sending to a printer or other device but that involves a lot of clock cycles if there is an easier way.

Here I am not going to use LANG settings as they may well not be set even if correct !
It seams to vary depending on platform.

[Mickey White]

Vincent, how do you know at run time which one, if any, to use?

[Simon Sobisch]

The program knows where to use a a currency sign.
Which one to use is set in a system parameter (ISAM/DB -> old style), a configuration file/env var (PC style) or via LC_MONETARY (which can come from an env var or the system configuration).

If that works in GnuCOBOL (I'm not sure, but it could be) then LC_MONETARY should really be the preferred option.

... quick check: FUNCTION CURRENCY-SYMBOL() should use LC_MONETARY already, all other places seem to use the program's CURRENCY SYMBOL definition which is a compile-time constant.
Also: use of FUNCTION MONETARY-DECIMAL-POINT() and FUNCTION MONETARY-THOUSANDS-SEPARATOR() would work that way.

COBOL2002+ allows something like CURRENCY SIGN IS "literal" PICTURE SYMBOL IS $ (which is not yet supported in GnuCOBOL but should not be too hard to implement if really needed) - the issue here is: it really has to be a literal, as the content needs to be verified (in theory we could add an extension which verifies it at compile time and uses $ if it isn't valid).

Or even a runtime setting like COB_CURRENCY_SIGN, defaulting to either zero or space = use the program one, but can be set to a character value or a literal to override. This is something that Chuck could have a look at, if interested.
... second thought: no, that is often useless as you still would have to set the period and comma dynamically, but a boolean COB_CURRENCY_USES_LOCALE, defaulting to true, and would be applied to all fields (also on MOVE) that has a currency sign in - that would work.

I do wonder if there really is no format or function that would automatically apply LC_MONETARY to every place at runtime ...

[Chuck Haatvedt]

This may be possible in that currency symbol / decimal point and thousands separator are defined at the module level if my memory is correct. We could have a runtime configurable setting which would cause these values to be extracted from the locale and used throughout the gnucobol program.

#define _LCONV_DEFINED
  struct lconv {
    char *decimal_point;
    char *thousands_sep;
    char *grouping;
    char *int_curr_symbol;
    char *currency_symbol;
    char *mon_decimal_point;
    char *mon_thousands_sep;
    char *mon_grouping;
    char *positive_sign;
    char *negative_sign;
    char int_frac_digits;
    char frac_digits;
    char p_cs_precedes;
    char p_sep_by_space;
    char n_cs_precedes;
    char n_sep_by_space;
    char p_sign_posn;
    char n_sign_posn;
#if __MSVCRT_VERSION__ >= 0xA00 || _WIN32_WINNT >= 0x601
    wchar_t* _W_decimal_point;
    wchar_t* _W_thousands_sep;
    wchar_t* _W_int_curr_symbol;
    wchar_t* _W_currency_symbol;
    wchar_t* _W_mon_decimal_point;
    wchar_t* _W_mon_thousands_sep;
    wchar_t* _W_positive_sign;
    wchar_t* _W_negative_sign;
#endif
  };

  Chuck Haatvedt

[Simon Sobisch]

yes, see the functions mentioned above that already use this structure; it would be possible to just call them [or better: an internal version that points to the data, not creating a field, which is used by then intrinsics then] if the new setting is enabled)

Note: a nice part is that you can set this locale also in COBOL and also dynamically (for example from a parameter in your system table, if you like that ;-)

[Vincent (Bryan) Coen]

It is requested within parameter set up as a one char symbol  i.e., PIC X.

On 20/10/2025 18:35, Mickey White wrote:

Vincent, how do you know at run time which one, if any, to use?

[Chuck Haatvedt]

Vince,

to understand your requirements a bit better, are you looking for a method to change the currency symbol at runtime without changes to the code. If so this may be possible by setting the locale before execution. it may be possible to create a CBL_SET_CURRENCY_SYMBOL routine which could access the locale and extract the currency symbol and then set the COBOL currency symbol to that value.

here is an example of this ... let me know if this is something you would be interested in exploring more and if so I can discuss this with Simon.

#include <stdio.h>
#include <locale.h>
#include <string.h> // For strlen()

int main() {
    // 1. Set the locale for monetary formatting based on the user's environment.
    // An empty string "" for the locale name tells setlocale to use the
    // value of the corresponding environment variable (e.g., LC_MONETARY).
    if (setlocale(LC_MONETARY, "") == NULL) {
        fprintf(stderr, "Could not set locale.\n");
        return 1;
    }

    // 2. Get the locale information structure.
    struct lconv *lc = localeconv();
    if (lc == NULL) {
        fprintf(stderr, "Could not get locale information.\n");
        return 1;
    }

    // 3. Access and print the currency symbol.
    const char *currency_symbol = lc->currency_symbol;

    if (currency_symbol && strlen(currency_symbol) > 0) {
        printf("Currency symbol: %s\n", currency_symbol);
    } else {
        printf("Currency symbol not defined for this locale.\n");
    }

    return 0;
}

 Chuck Haatvedt

[Vincent (Bryan) Coen]

From what I can gleam from this code (C is a bit rusty) it only provides the direct value such as en-GB.(font type) as agains the actual currency symbol but if there is a way then yes it could work for me Providing there is a way of replacing the default vaalue say using $, replacing it pre display or printing etc.

Of course the other option which I do not like as it involves a lot of clock cycles is to use SUBSTITUTE etc or examine x replacing "$" with new-symbol.

A bit of a pain doing so for every group item that contains such a symbol.

Just trying to see if there is a easier way by replacing the one provided to the compiler and replacing it at runtime in some way.

[Michael Del Solio]

Maybe you could read the currency symbol from an environment variable and build an output string for display:

       IDENTIFICATION DIVISION.
       PROGRAM-ID. CURRENCY-ENV-2.

       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-AMOUNT             PIC 9(6)V99 VALUE 9876.54.
       01  WS-AMOUNT-FMT         PIC Z(6)9.99.
       01  WS-CURRENCY-SYMBOL    PIC X(8) VALUE SPACE.
       01  WS-OUTPUT-STR         PIC X(40).
       01  WS-ENV-VALUE          PIC X(32).

       PROCEDURE DIVISION.
           *> Read currency symbol from environment
           ACCEPT WS-ENV-VALUE FROM ENVIRONMENT "CURRENCY"

           IF FUNCTION TRIM(WS-ENV-VALUE) = SPACES
              MOVE "$" TO WS-CURRENCY-SYMBOL
           ELSE
              MOVE FUNCTION TRIM(WS-ENV-VALUE) TO WS-CURRENCY-SYMBOL
           END-IF

           MOVE WS-AMOUNT TO WS-AMOUNT-FMT

           STRING FUNCTION TRIM(WS-CURRENCY-SYMBOL TRAILING)
                  " "
                  WS-AMOUNT-FMT
                  DELIMITED BY SIZE
                  INTO WS-OUTPUT-STR
           END-STRING

           DISPLAY "Amount: " WS-OUTPUT-STR
           GOBACK.

Test under Ubuntu 24.04 with:

cobc -x CURRENCY-ENV-2.COB

With this test.sh the output is like:

export CURRENCY="€"; ./CURRENCY-ENV-2
export CURRENCY="£"; ./CURRENCY-ENV-2
export CURRENCY="$"; ./CURRENCY-ENV-2
export CURRENCY="¥"; ./CURRENCY-ENV-2
unset CURRENCY; ./CURRENCY-ENV-2

./test.sh
Amount: €    9876.54
Amount: £    9876.54
Amount: $    9876.54
Amount: ¥    9876.54
Amount: $    9876.54

[Vincent (Bryan) Coen]

Was hoping for a floating symbol such as $123.45 being replaced say by £123.45 at the point of moving the value to the field prior to printing / or display of field or line containing field.

[Simon Sobisch]

Chuck's version (yes, we discussed the implementation up-front and changed it before the actual work ;-) will be runtime-only and handle the floating-symbol.
As it is a runtime setting you can adjust it before every statement via SETto enable/disable it and you should also be able to set the locale adjustment within the program.

And if you don't like the default locales, you can even copy their definition and setup this one.

sudo cp /usr/lib/locale/somelocale /usr/lib/locale/mylocale
sudo localedef -i mylocale /usr/lib/locale/mylocale
COB_LOCALE_CURRENCY=yes LC_MONETARY=mylocale cobcrun yourprogram

Note that this is non-standard - the COBOL standard has the locale-format for the PICTURE clause - but I'm not aware of an implementation supporting it - that would definitely be better (but needs work in the compiler, runtime and shared structures).

[Eugenio Di Lorenzo]

Thanks for the clarification.
I would like to add and remind everyone that a detailed and formalized analysis is also the essential basis for adequate documentation in the manuals.

[Ralph Linkletter]

Having worked side by side with Chuck on many zOS compatibility issues I wonder the feasibility of producing an analysis and spec.
Most of Chuck efforts are buried deep in the bowels of the run time "C" code.
The runtime "C" code is complex. Deep level indirection is used - often pointing at "C" data structures.

I think changes are noted in the Source Code Management facility.

I would think that you could gain insight from the source management facility used by GnuCOBOL.

However if you are not an expert level "C" programmer that may not be a viable option to document features.

Ralph

[Vincent (Bryan) Coen]

Other than to use Doxygen -  vis Brian)  but I personally call it
doxymoron - hopefully for the obvious reason.

On 22/10/2025 21:15, Ralph Linkletter wrote:

Having worked side by side with Chuck on many zOS compatibility issues
I wonder the feasibility of producing an analysis and spec.
Most of Chuck efforts are buried deep in the bowels of the run time
"C" code.
The runtime "C" code is complex. Deep level indirection is used -
often pointing at "C" data structures.

I think changes are noted in the Source Code Management facility.

I would think that you could gain insight from the source management
facility used by GnuCOBOL.

However if you are not an expert level "C" programmer that may not be
a viable option to document features.

Ralph

[Anonymous]

Obviously, I'm referring to functional analysis, not technical analysis of how the program code is written.
I'd say that functional analysis is always not only possible, but mandatory.
Defining the functional objectives of an implementation.
What objectives it must achieve and how.
How the application must function, both at the macro and detailed levels.
This is independent of how the code is written, and it's very difficult to extract it by reading the source code of any language.
This applies in all cases.
Code should never be produced without a formalized functional analysis in as much detail as possible.

Functional analysis is not only useful for producing good documentation, but also for defining a correct and adequate test plan and, therefore, for the subsequent release.
These are basic concepts for software development.
E.Di Lorenzo

[Vincent (Bryan) Coen]

Solution needs to be a facility to replace the current floating symbol
as say in PIC $(5)9.99 or similar.

On 20/10/2025 19:13, Michael Del Solio wrote:

Maybe you could read the currency symbol from an environment variable
and build an output string for display:

|IDENTIFICATION DIVISION. PROGRAM-ID. CURRENCY-ENV-2. DATA DIVISION.
WORKING-STORAGE SECTION. 01 WS-AMOUNT PIC 9(6)V99 VALUE 9876.54. 01
WS-AMOUNT-FMT PIC Z(6)9.99. 01 WS-CURRENCY-SYMBOL PIC X(8) VALUE
SPACE. 01 WS-OUTPUT-STR PIC X(40). 01 WS-ENV-VALUE PIC X(32).
PROCEDURE DIVISION. *> Read currency symbol from environment ACCEPT
WS-ENV-VALUE FROM ENVIRONMENT "CURRENCY" IF FUNCTION
TRIM(WS-ENV-VALUE) = SPACES MOVE "$" TO WS-CURRENCY-SYMBOL ELSE MOVE
FUNCTION TRIM(WS-ENV-VALUE) TO WS-CURRENCY-SYMBOL END-IF MOVE
WS-AMOUNT TO WS-AMOUNT-FMT STRING FUNCTION TRIM(WS-CURRENCY-SYMBOL
TRAILING) " " WS-AMOUNT-FMT DELIMITED BY SIZE INTO WS-OUTPUT-STR
END-STRING DISPLAY "Amount: " WS-OUTPUT-STR GOBACK. |

Test under Ubuntu 24.04 with:

|cobc -x CURRENCY-ENV-2.COB |

With this test.sh the ouput is like:

|exportCURRENCY="€";./CURRENCY-ENV-2
exportCURRENCY="£";./CURRENCY-ENV-2
exportCURRENCY="$";./CURRENCY-ENV-2
exportCURRENCY="¥";./CURRENCY-ENV-2 unsetCURRENCY;./CURRENCY-ENV-2 |
|./test.sh Amount: € 9876.54 Amount: £ 9876.54 Amount: $ 9876.54
Amount: ¥ 9876.54 Amount: $ 9876.54 |

Attachments:

• CURRENCY-ENV-2.COB
  https://sourceforge.net/p/gnucobol/discussion/help/thread/0c0afe6002/7a72/attachment/CURRENCY-ENV-2.COB
  (1.1 kB; application/octet-stream)
  

[Vincent (Bryan) Coen]

Chuck amd Mickey;

That does not provide me the currency symbol so would have to have a tranlation facility to convert what is provided e.g., for LC_MONETARY = en_GB.UTF-8 work out for "en-GB" the value via some kind of predefined table and as that does not exist I have no way of working it out.

I have set a new parameter field for Currency (pic X) to hold it but user must provide it during system set up 0 I cannot see any way to otherwise automate that bit.

Now with the field set (by users) I know what the symbol is (assuming it "Can" be defined" in this way as some I suspect are not in a standard font set for the platform used (i.e., Linux, Windows, OSX etc). as example here in the UK I use UTF-8 on Linux but for Windows (11) it is something else (no, I do not know what).

Otherwise I would need a process that provides it so the simplist way is to ask the user at the point of parameter input. This way it leave the issue with the user.

That now said I still have to automate any data fields using something line PIC $9(6),99 / $(6).99 to replace the symbol for all such outputs - printing or display.

It has been many years since I have used currency symbols, I have managed to just not use them as I have assumed user / end user would know the currency :)

The above mostly because of this problem as when I experimented with the UK one it was a mess using £ as that is not in all font sets for each char codings. - UTF-8 has some of these issues :(
HEre an example of using it within Cobol as it is NOT one character - at least according to GC.

Above going by memory which at my age (78) is getting a wee bit rusty.

[Simon Sobisch]

Per COBOL rules this works indeed only if the sign is a single character - and GnuCOBOL internally has "single character must be single byte".
What does work is to use an encoding that has your character-sign as a single-byte, but that means your output files will use the same encoding and if you use terminal output you better ensure that the terminal uses the same encoding as well.

See also that old SO Q+A https://stackoverflow.com/questions/54974226/ubuntu-gnucobol-currency-sign-is-%C2%A3-causes-compile-errors

[Arnold Trembley]

There is another option to use ISO 4217 currency codes which are either three letters or three digits. You can use either the alphabetic or the numeric currency code.
https://en.wikipedia.org/wiki/ISO_4217

https://www.iban.com/currency-codes

For example:

USD/840 is United States Dollars
EUR/978 is Eurozone Euros (multiple countries)
GBP/826 is United Kingdom Pounds Sterling
CHF/756 is Swiss Francs (Confederation Helvetique)
JPY/392 is Japanese Yen
CNY/156 is Chinese RenMinBi (China New Yuan)

This standard might be very helpful for any accounting system that deals with three or more currencies in the same report. There are almost 300 different currency codes in use for international bank settlements.

But unfortunately, ISO 4217 this doesn't offer one-character currency symbols.

[Arnold Trembley]

Here's another resource:

https://currencycalculate.com/list-of-currency-symbols/

Note that some currencies DO NOT have any single-character currency code or symbol.

Given that a "character" in COBOL is pretty much limited to an 8-bit byte, it is never going to be possible to support a large number of special currency symbols in a single national code-set (ASCII or EBCDIC).

The only reason that webpage can display so many currency code symbols is because it is encoded in UTF-8 (UniCode Translation Format - 8-bit) in which any "character" is variable length, either 8, 16, 24, or 32 bits long.

You can make some other interesting observations by reading that list. For example, several countries use the "dollar sign" ($), including Australia, Canada, Singapore, Tuvalu, USA, even though the currencies have different exchange rates. There is a similar situation with the "pound sign" (£), which is used by Egypt, Lebanon, Syria, and the UK. I find it ironic that China and Japan both use the same symbol for their different currencies (¥). And of course the Euro symbol (€) covers multiple countries.

I honestly cannot guess what the best solution to this question would be, but I would probably lean towards using UTF-8, because it can support "glyphs" outside the current locale code-set.

[Eugenio Di Lorenzo]

The following might be another solution.

        >>SOURCE FREE
IDENTIFICATION DIVISION.
PROGRAM-ID. TESTCURRENCY.
DATA DIVISION.
WORKING-STORAGE SECTION.
01  AAA PIC $$$$$$$$9.
01  BBB PIC XXXXXXXXX.
01 wUSDOLLAR PIC X VALUE '$'.
01 wGBPOUND  PIC X VALUE '£'.
01 wEURO     PIC X VALUE '€'.
PROCEDURE DIVISION.
    Move 123 to AAA
    DISPLAY AAA
    MOVE function substitute(AAA,wUSDOLLAR,wGBPOUND) TO BBB
    DISPLAY BBB
    MOVE function substitute(AAA,wUSDOLLAR,wEURO) TO BBB
    DISPLAY BBB

    Move 12345 to AAA
    DISPLAY AAA
    MOVE function substitute(AAA,wUSDOLLAR,wGBPOUND) TO BBB
    DISPLAY BBB
    MOVE function substitute(AAA,wUSDOLLAR,wEURO) TO BBB
    DISPLAY BBB

    Move 123 to AAA
    DISPLAY AAA
    INSPECT AAA REPLACING ALL wUSDOLLAR BY wGBPOUND
    DISPLAY AAA

    Move 12345 to AAA
    INSPECT AAA REPLACING ALL wUSDOLLAR BY wEURO
    DISPLAY BBB

    ACCEPT OMITTED 
    STOP RUN.

Always use a PIC with the normal $ symbol and then use the SUBSTITUTEfunction or INSPECTverb to change it to any other currency before displaying on screen or printing on a report.

NOTE: Oddly enough, the SUBSTITUTE function's ability to use the same input and output field doesn't seem to work properly.
This Sample doesnot work:
MOVE function substitute(AAA,wUSDOLLAR,wGBPOUND) TO AAA

[Chuck Haatvedt]

I am working to add support for using the first character of the currency string from the locale depending on the setting of a runtime configuration / environment variable.

Updates will be provided as I work towards having something available for beta testing. The changes are more complex than I initially thought they would be.

      Chuck Haatvedt

[Anonymous]

Hi Chuck, I recommend producing a detailed and approved analysis document before making any changes or implementations to the GnuCOBOL software.
Otherwise, there's a risk that the solution you create will not be accepted within the project and will therefore need to be modified at the very least, perhaps more than once.

[Vincent (Bryan) Coen]

This first character, is that the currency symbol such as £ $ etc (I was going to include a euro symbol but despite my keyboard having it on key "2" I cannot select it - a Logitech MX pain !

Bye the bye, what is happening regarding the routine accept_numeric ?

Works for me apart of getting it picked up when running app as it often cannot find it unless I embed it into the Cobol code.

Was hoping it would be added into the ACCEPT logic for both data item and SS area for numeric items but it seems to have gone very quiet.

[Ralph Linkletter]

Anonymous
". . . there's a risk that the solution you create will not be accepted within the project"
Who or what determines acceptability ?
As far as I know there is no governing body that passes judgement on volunteer efforts to improve GnuCOBOL.
Who are you poster "Anonymous" ?
I know for a fact that Chuck is an extraordinary developer.
I also know Chuck had discussions with GnuCOBOL principals whereupon the analysis done for this effort was thorough and the objective clearly specified.

Ralph