[Info-vax] Calling $CREPRC in COBOL

[Stephen Hoffman]

On 2022-06-27 18:25:14 +0000, Dave Froble said:

> On 6/27/2022 1:18 PM, Simon Clubley wrote:
>> 
>> What we _really_ need are logical names whose name (not contents) can 
>> be specified as a UTF-8 character sequence... :-)
> 
> Enlighten me.  I cannot think of one reason why ...

That was intended a joke, of course.

There is, however, much more to the computing world than what can be 
represented in DEC MCS and ISO Latin 1.

OpenVMS RMS has support for UTF-8, not that much else does.

Reference those RMS files through encoding hackery is certainly 
possible, of course.

Dealing with UTF-8 is something an increasing number of apps have to deal with.

Websites and web servers have been UTF-8 for a number of years.

On OpenVMS, most apps ignore UTF-8, and require / assume / force 
arriving data to ASCII.

Unfortunately, that can be names and addresses and other data that 
doesn't map to ASCII.

Dates too are "fun", but I'll leave that "fun" for another, um, day.

Sure, we can all continue to use ASCII and DEC MCS, and can ignore the 
whole character encoding issue.

And can map "unsupported" string encodings using UUID-generated names 
(aliases), as my earlier joke had alluded.

Which is about the best option on OpenVMS, if porting is not a possibility.

If you're US based and not working outside of Romance languages, this 
is less of an issue.

Though I'd consider testing customer-facing data interfaces with UTF-8.

This whole thing becomes a non-issue* in environments where UTF-8 is native.

*Mostly. UTF-8 still has some surprises waiting, including the byte 
order mark, language-specific sort orders, and non-breaking spaces.

Getting to fully native UTF-8 support in the OpenVMS operating system, 
tools, and platforms, is unlikely on any reasonable VSI OpenVMS 
timeline.



-- 
Pure Personal Opinion | HoffmanLabs LLC