Cobol - Spanish characters in Cobol-how to?

Author

Spanish characters in Cobol-how to?

hp3kpro

2006-08-08, 6:55 pm

I am working on a Cobol program that produces letters. The verbage is
hard coded in the
program. My task is to add a Spanish translation to the current English
wording. My problem is: how do I get a tilde and accent marks in the
Spanish?

Thanks,
Brian

Howard Brazee

2006-08-08, 6:55 pm

hp3kpro

2006-08-08, 6:55 pm

HP3000. MPE\ix .

Howard Brazee wrote:
> On 8 Aug 2006 07:05:30 -0700, "hp3kpro" <BJLPA@hotmail.com> wrote:
>
>
> What is your environment?
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com

Howard Brazee

2006-08-08, 6:55 pm

On 8 Aug 2006 09:01:38 -0700, "hp3kpro" <BJLPA@hotmail.com> wrote:
[color=darkred]
>HP3000. MPE\ix .
>
>
>
>Howard Brazee wrote:

I can't help you there, maybe somebody else can.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

HeyBub

2006-08-08, 6:55 pm

hp3kpro wrote:
> I am working on a Cobol program that produces letters. The verbage is
> hard coded in the
> program. My task is to add a Spanish translation to the current
> English wording. My problem is: how do I get a tilde and accent marks
> in the Spanish?

Just type them in. COBOL doesn't care what characters are used in a text
field.

hp3kpro

2006-08-08, 6:55 pm

I wouldn't think the platform would be important as COBOL is pretty
much COBOL.
Do I have to resort to using some escape sequences or hex?
Thanks.

Howard Brazee wrote:
> On 8 Aug 2006 09:01:38 -0700, "hp3kpro" <BJLPA@hotmail.com> wrote:
>
>
> I can't help you there, maybe somebody else can.
>
> Posted Via Usenet.com Premium Usenet Newsgroup Services
> ----------------------------------------------------------
> ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
> ----------------------------------------------------------
> http://www.usenet.com

hp3kpro

2006-08-08, 6:55 pm

One can't type 2 characters at the same time. In other words, as in the
word nino, the "~" has to go above the second letter n.

HeyBub wrote:
> hp3kpro wrote:
>
> Just type them in. COBOL doesn't care what characters are used in a text
> field.

Howard Brazee

2006-08-08, 6:55 pm

On 8 Aug 2006 11:46:18 -0700, "hp3kpro" <BJLPA@hotmail.com> wrote:

>I wouldn't think the platform would be important as COBOL is pretty
>much COBOL.
>Do I have to resort to using some escape sequences or hex?
>Thanks.

Possibly. If your editor doesn't put them in, you would have to put
them in. But if you use hex, it matters whether you are using ASCII
or EBCDIC. But if you can type in your code (that isn't dependent
upon a font being loaded into Word or such), you should be able to use
it. Or you can use whatever your printer understands, if it is to be
printed.

I typed in alt-0241 to get this: ñ
I typed in alt-0209 to get this: Ñ

http://www.ascii.cl/htmlcodes.htm

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Richard

2006-08-08, 6:55 pm

hp3kpro wrote:
> I am working on a Cobol program that produces letters. The verbage is
> hard coded in the program.

That is the first mistake. The verbage should be, for example, a
template that the
program merges into. Then any template can be used without the program
caring.
I do most of my printer output by merging into postscript templates.
All my XML,
HTML and data interchange is templated.

You could write out a text merge file that a word processor could use.

> My task is to add a Spanish translation to the current English
> wording. My problem is: how do I get a tilde and accent marks in the
> Spanish?

Presumably the 'letters' are to be printed rather than just be part of
the program. This requires that you first ask what the printer requires
in order to produce the correct characters. Then you would need to find
out what value those characters were and work out how to generate them
in the program. The code set used by your screen and keyboard may be
quite different but that is irrelevant as long as it is correct on the
printer.

For example on HP LaserJet Roma-8 symbol set the N~ and n~ are hex B6
and B7. These may appear as box drawing characters under Windows. Of
course a spanish keyboard might be useful for this, and set the screen
using code-set or someother mechanism to display the required
characters.

James J. Gavan

2006-08-08, 6:55 pm

hp3kpro wrote:
> I am working on a Cobol program that produces letters. The verbage is
> hard coded in the
> program. My task is to add a Spanish translation to the current English
> wording. My problem is: how do I get a tilde and accent marks in the
> Spanish?
>
> Thanks,
> Brian
>
You might get some tips googling. Try the search phrase
"Spanish-Characters" in Google - I got 51,000 hits. There's a download
for $10 - don't know if it is relevant.

Jimmy

Frederico Fonseca

2006-08-09, 3:55 am

On 8 Aug 2006 07:05:30 -0700, "hp3kpro" <BJLPA@hotmail.com> wrote:

>I am working on a Cobol program that produces letters. The verbage is
>hard coded in the
>program. My task is to add a Spanish translation to the current English
>wording. My problem is: how do I get a tilde and accent marks in the
>Spanish?
>
>Thanks,
>Brian

This is not a COBOL problem. COBOL will accept anything you enter in
an accept or that you read from a file (with some exceptions, but not
applicable on this case!!)

To get ANY accented character you need to have you editor and your
workstation prepared to accept those, and eventually also your OS.
For example a "ã" is done by pressing "~" followed by a "a". Similar
for "ñ".

Once you have that done you just type away what you need, either on
the source code or within a COBOL accept.

Its a bad idea to have this hardcoded on the program source.
You should really have a file containing all the "strings" that are
language dependent, with a key containing the language, and the
"message key" to be used by a particular program.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Caederus

2006-08-09, 7:55 am

I have worked with multinational characters in the past. If it's hard
coded or in an external file the important thing is what code page the
printer will support. (850 1250, 1252, 8851...). This is important
because an N with a tilda can be mapped in different places for
different code pages. The first 128 characters will be the same for
each code page (assuming ASCII) but the last 128 can be any which way.

Then if you want to hard code the verbage (not my recomendation) then
you go into the code with an editor that allows you go into a hex mode.
It may not look good on the screen if the terminal emulation
application you are using assumes a different code page than they one
you are using for the printer, but it will work.

hp3kpro wrote:[color=darkred]
> I wouldn't think the platform would be important as COBOL is pretty
> much COBOL.
> Do I have to resort to using some escape sequences or hex?
> Thanks.
>
> Howard Brazee wrote:

2006-08-09, 7:55 am

In article <1155121633.557633.67410@i42g2000cwa.googlegroups.com>,
Caederus <davidburnham@gmail.com> wrote:
>I have worked with multinational characters in the past.

So have I... there was Gerhard, there was Yasminda, there was Luigi, there
was Yi-fu, there was N'gotzke... well, each character had only one
nationality but the crew was one of multi-national characters.

'We serve hard drinks in here for men who want to get drunk fast and we
don't need any 'characters' around to give the joint 'atmosphere'. -
bar-owner Nick in 'It's A Wonderful Life'

DD

HeyBub

2006-08-09, 7:55 am

Frederico Fonseca wrote:

>
> Its a bad idea to have this hardcoded on the program source.
> You should really have a file containing all the "strings" that are
> language dependent, with a key containing the language, and the
> "message key" to be used by a particular program.
>

This is an example of a programming technique that's not necessarily taught
but is often learned by experience.

Many (many) years ago the company for whom I worked used a commercial
program for which it seemed we were getting a new version every couple of
w

s. It was a LARGE program.

Curious, I looked at the EXE file with a hex editor. 60% of the program
consisted of literal renditions of various messages - mostly error
conditions. I took that observation to heart.

In the fullness of time, my company now assigns numbers to various
machine-to-human messages and call a message handler. The handler looks up
the actual message in a file and displays same. The message file is
humongous but the application's code is quite small.

Couple of side benefits: The message handler also logs the message - and the
operator response - to a file and this 'diary' can be examined after the
fact ("Ah, it seems as if 'JOE' did delete the record.").

Howard Brazee

2006-08-09, 7:55 am

On Wed, 09 Aug 2006 09:11:39 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>To get ANY accented character you need to have you editor and your
>workstation prepared to accept those, and eventually also your OS.
>For example a "ã" is done by pressing "~" followed by a "a". Similar
>for "ñ".

What editor does that? ~n

~N

Frank Swarbrick

2006-08-09, 6:55 pm

HeyBub<heybubNOSPAM@gmail.com> 08/09/06 6:54 AM >>>
>Frederico Fonseca wrote:
>
>
>
>This is an example of a programming technique that's not necessarily taught

>but is often learned by experience.
>
>Many (many) years ago the company for whom I worked used a commercial
>program for which it seemed we were getting a new version every couple of
>w

s. It was a LARGE program.
>
>Curious, I looked at the EXE file with a hex editor. 60% of the program
>consisted of literal renditions of various messages - mostly error
>conditions. I took that observation to heart.
>
>In the fullness of time, my company now assigns numbers to various
>machine-to-human messages and call a message handler. The handler looks up

>the actual message in a file and displays same. The message file is
>humongous but the application's code is quite small.
>
>Couple of side benefits: The message handler also logs the message - and
the
>operator response - to a file and this 'diary' can be examined after the
>fact ("Ah, it seems as if 'JOE' did delete the record.").

I agree that putting messages in files instead of hard coding them makes
things more flexible. But, and having never done it, I wonder if it doesn't
also complicate things. Specifically, I often to a source code search for
error messages. But if the messages are not in the source code this seems
to me to mean you have to search the message files for the message, and then
cross-reference them back to the source code. Is this in fact much of an
issue?

Just wondering... I can't imagine we'll change our ways any time soon, but
who knows?

Frank

---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA

Donald Tees

2006-08-09, 6:55 pm

Xref: number1.nntp.dca.giganews.com comp.lang.cobol:160355

Frank Swarbrick wrote:
> HeyBub<heybubNOSPAM@gmail.com> 08/09/06 6:54 AM >>>
>
>
>
>
>
>
> the
>
>
>
> I agree that putting messages in files instead of hard coding them makes
> things more flexible. But, and having never done it, I wonder if it doesn't
> also complicate things. Specifically, I often to a source code search for
> error messages. But if the messages are not in the source code this seems
> to me to mean you have to search the message files for the message, and then
> cross-reference them back to the source code. Is this in fact much of an
> issue?
>
> Just wondering... I can't imagine we'll change our ways any time soon, but
> who knows?
>
> Frank
>
>
> ---
> Frank Swarbrick
> Senior Developer/Analyst - Mainframe Applications
> FirstBank Data Corporation - Lakewood, CO USA

A specific error code is as easy to search for as a literal, provided
you are carefull how you key them. If the error handler is coded as an
object, then it makes it simple to eventually handle multiple languages.

Donald

2006-08-09, 6:55 pm

In article <ebd29d$5uo$1@emma.aioe.org>,
Donald Tees <donald_tees@donald-tees.ca> wrote:
>Frank Swarbrick wrote:

[snip]
[color=darkred]

[snip]
[color=darkred]

[snip]
[color=darkred]
>A specific error code is as easy to search for as a literal, provided
>you are carefull how you key them. If the error handler is coded as an
>object, then it makes it simple to eventually handle multiple languages.

Hmmmmmm... not even an object or a subroutine... but it isn't a simple
'all ya gotta do is'. Consider:

(Procedure Division code only - determining file layouts and
Working-Storage entries are exercises left to the reader.)

Open Input Paymaster
If Not Good-Paymaster-IO
Display 'Invalid Open Paymaster - File Status = ', PM-Stat
Perform Blow-Em-Up
End-If

.... and ...

Open Input Paymaster
If Not Good-Paymaster-IO
Move 'FEEN0025' to ErrMast-key
Perform Generic-Error-Rtn
Evaluate True
When Errmast-Action = 'ABEND'
Perform Blow-Em-Up
End-Evaluate
End-If

Now... the hardcoded 'FEEN0025' can be seen as a near-mnemonic for File
Error, ENglish, number 0025; error codes can be grouped by type and
language this way. A copybook can be defined with error-codes so that
hardcoding is avoided... the difficulties, of course, are standard ones:

1) The copybook and Error Master File must be maintained; routine file
maintenance is a task that, in my experience, is notoriously prone to
neglect.

2) Programmers need time to get familiar with the codes... and time is
money, there's always enough time to do it over but never enough time to
do it right, there isn't an entry in the Error Master for this situation
so a hardcoded error will be allowed Just This Once... et and cetera.

DD

Donald Tees

2006-08-09, 6:55 pm

docdwarf@panix.com wrote:
>
>
> Hmmmmmm... not even an object or a subroutine... but it isn't a simple
> 'all ya gotta do is'. Consider:
>
> (Procedure Division code only - determining file layouts and
> Working-Storage entries are exercises left to the reader.)
>
> Open Input Paymaster
> If Not Good-Paymaster-IO
> Display 'Invalid Open Paymaster - File Status = ', PM-Stat
> Perform Blow-Em-Up
> End-If
>
> ... and ...
>
> Open Input Paymaster
> If Not Good-Paymaster-IO
> Move 'FEEN0025' to ErrMast-key
> Perform Generic-Error-Rtn
> Evaluate True
> When Errmast-Action = 'ABEND'
> Perform Blow-Em-Up
> End-Evaluate
> End-If
>
> Now... the hardcoded 'FEEN0025' can be seen as a near-mnemonic for File
> Error, ENglish, number 0025; error codes can be grouped by type and
> language this way. A copybook can be defined with error-codes so that
> hardcoding is avoided... the difficulties, of course, are standard ones:
>
> 1) The copybook and Error Master File must be maintained; routine file
> maintenance is a task that, in my experience, is notoriously prone to
> neglect.
>
> 2) Programmers need time to get familiar with the codes... and time is
> money, there's always enough time to do it over but never enough time to
> do it right, there isn't an entry in the Error Master for this situation
> so a hardcoded error will be allowed Just This Once... et and cetera.
>
> DD
>

Agreed to all of the above.

The advantage to the oject is that there are no "other" dependant
copies. For example, the oject code may or may not open a window. With
a straightforward copy, you are going to have to put aditional copies
into your code to handle the window code ... screen section copies, for
eaxmple.

I've been burnt several times with that type of dependant copy code ...
ypu want to modify a single error handling procedure, and as a result
have to modify a working storage section copy. As a result of that, you
end up having to change dozens of other programs.

Donald

James J. Gavan

2006-08-09, 6:55 pm

Donald Tees wrote:
> docdwarf@panix.com wrote:
>
> Agreed to all of the above.
>
> The advantage to the oject is that there are no "other" dependant
> copies. For example, the oject code may or may not open a window. With
> a straightforward copy, you are going to have to put aditional copies
> into your code to handle the window code ... screen section copies, for
> eaxmple.
>
> I've been burnt several times with that type of dependant copy code ...
> ypu want to modify a single error handling procedure, and as a result
> have to modify a working storage section copy. As a result of that, you
> end up having to change dozens of other programs.
>
> Donald

I can't disagree with the concept of separate error message files - and
OO-wise M/F uses an error class with messages. However I am sympathetic
to the concerns Doc raised.

Given that a (large) installation does have an error message file then
it is an absolute MUST that it is tightly controlled, somebody
performing the control function just like the DBA controls the DB. If
not, then it is likely say over a period of ten years that 30% of the
contained messages maybe redundant, having been replaced by new messages
or new programs. (I doubt I'm illustrating an hypothetical).

The message file is one thing "RW" got right :-). I use Level 88's to
control messages in one class, then invoke method "errorMessages" to get
the appropriate literal, (one reason why the retained Working-Storage
Section in M/F methods is useful). Then I mused if I wanted to have my
English messages in French or German, I could use a switch at
application start to invoke methods "EnglishMessages", "FrenchMessages"
or "GermanMessasges". RW picked up on this immediately saying I should
be using a message file. But my concern is control of that file, which
could grow like Topsy.

Naturally to get the correct literals for French or German, it would be
a disaster to use Babelfish :-). You require a particular language
technician to get those right, possibly some service from the UN or EU.

Bear in mind my methods "messages", while part of the particular class
are only memory-resident when invoked. Plus, as I code I can enter :-

if this is wrong
set ErrorClientNumber to true

without interrupting my train of thought. Subsequently I can do a quick
search of "set Error", adding the Level 88 names and then finish off by
taking that complete Error Code List and building the method
"errorMessages".

If I add to the "EnglishMessages" then of course I have to discipline
myself to add to the "FrenchMessasges" and "GermanMessages".

An ErrorMessaageFile is the generally accepted way to go. However, which
approach are you most comfortable with. One other factor - messages I
have for the Program/Class EditCustomersNames are likely unique to that
one Program/Class.

Jimmy

HeyBub

2006-08-09, 6:55 pm

docdwarf@panix.com wrote:
>
> 2) Programmers need time to get familiar with the codes... and time is
> money, there's always enough time to do it over but never enough time
> to
> do it right, there isn't an entry in the Error Master for this
> situation
> so a hardcoded error will be allowed Just This Once... et and cetera.

Agreed. Here's how we do it:

....
If MYDATA-NUM < 0
Move S00345 to ERROR-MSG-NUMBER *> Hourly rate too small
Call 'ERROR-HANDLER' using ERROR-BLOCK
...

Note the comment, placed there by the coder of the exception condition. This
usually serves as a short explanation for the maintenance programmer as to
what it's all about.

Frederico Fonseca

2006-08-10, 3:55 am

On Wed, 09 Aug 2006 07:48:59 -0600, Howard Brazee <howard@brazee.net>
wrote:

>On Wed, 09 Aug 2006 09:11:39 +0100, Frederico Fonseca
><real-email-in-msg-spam@email.com> wrote:
>
>
>What editor does that? ~n
>
>~N
In Windows? All that I know of.

In Unix environment? VI (and all other standard Unix like editors),
QEDIT and others.

As I said this is a OS problem mainly, followd by emulator (if using a
OS that requires one), and only then a editor. For example Unix vi may
in some OS versons require further configuration definitions.

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Richard

2006-08-10, 3:55 am

Frederico Fonseca wrote:

> In Windows? All that I know of.
>
> In Unix environment? VI (and all other standard Unix like editors),
> QEDIT and others.
>
> As I said this is a OS problem mainly, followd by emulator (if using a
> OS that requires one), and only then a editor. For example Unix vi may
> in some OS versons require further configuration definitions.
>
> Frederico Fonseca
> ema il: frederico_fonseca at syssoft-int.com

You seem to be in Italy so it would be reasonable to guess that your
systems are installed for the locale of a european country. Thus the
systems work to give these shortcut ways of entering the european
characters.

This does not usually work on US or english locale systems.

In KDE (Linux) I can turn that behaviour on or off as required.

http://www.tuxmagazine.com/node/1000044

Howard Brazee

2006-08-10, 7:55 am

On Thu, 10 Aug 2006 08:07:27 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>In Windows? All that I know of.

I've probably used fewer than a dozen Windows editors without coming
across this. The ones I have on this machine don't do this.

So I infer that it isn't a property of the editor, but am guessing
that it is part of the Windows setup - probably set up as the default
depending on what native language support is required.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Michael Wojcik

2006-08-10, 6:55 pm

In article <12dksi8io31nsf5@news.supernews.com>, "HeyBub" <heybubNOSPAM@gmail.com> writes:
>
> Agreed. Here's how we do it:
>
> ...
> If MYDATA-NUM < 0
> Move S00345 to ERROR-MSG-NUMBER *> Hourly rate too small
> Call 'ERROR-HANDLER' using ERROR-BLOCK
> ...
>
> Note the comment, placed there by the coder of the exception condition. This
> usually serves as a short explanation for the maintenance programmer as to
> what it's all about.

This is a useful technique, though I prefer to take it one step
further: my error handler receives both a message number and default
message text.

If for some reason message-text lookup fails - the message file has
gone missing or some such - the user still gets the number and the
default text, which is perhaps not as immediately useful as a
localized message but generally better than a number and something to
the effect of "message text not found".

And the maintenance programmer can see at a glance what message is
intended, thanks to the default text.

--
Michael Wojcik michael.wojcik@microfocus.com

Aw, shucks. And I was just trying to be rude. -- P.J. Plauger

Frederico Fonseca

2006-08-10, 6:55 pm

Reply to both Richard and Howard
Top post only.

If on windows one only has to install the locales (along with the
keyboard mapping).

On a *Nix environment it will depend on which one, and on whether
X-Windows is being used or not.

But IT IS PRIMARALY a OS setup that is needed to allow for both input
and display of such characters.

On some cases its possible to have the OS prepared for it already, but
still be using a program that is not prepared to allow for thesechars.
Not very common on these days.

So even the US guys can have this, but the main problem is that most
english based people will be completely ignorant on this matter, as
they have never needed it, so they dont even know what to do to have
them.
On the other hand, a Spanish or Portuguese or French will always be
aware of this problem.

(I am Portuguese for those that dont know, and working in Ireland. My
Work PC's have both Irish and Portuguese keyboards installed, so I can
use either when I need.)

On Thu, 10 Aug 2006 08:07:27 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>On Wed, 09 Aug 2006 07:48:59 -0600, Howard Brazee <howard@brazee.net>
>wrote:
>
>In Windows? All that I know of.
>
>In Unix environment? VI (and all other standard Unix like editors),
>QEDIT and others.
>
>As I said this is a OS problem mainly, followd by emulator (if using a
>OS that requires one), and only then a editor. For example Unix vi may
>in some OS versons require further configuration definitions.
>
>
>
>Frederico Fonseca
>ema il: frederico_fonseca at syssoft-int.com

Frederico Fonseca
ema il: frederico_fonseca at syssoft-int.com

Howard Brazee

2006-08-11, 6:55 pm

On Fri, 11 Aug 2006 00:16:17 +0100, Frederico Fonseca
<real-email-in-msg-spam@email.com> wrote:

>(I am Portuguese for those that dont know, and working in Ireland. My
>Work PC's have both Irish and Portuguese keyboards installed, so I can
>use either when I need.)

The keyboards are a big help. That way you don't need anything
else. I end up using alt-commands when I want to type a ¿
(alt-0191). I keep a bookmark where I can find these in a hurry.

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Sponsored Links