Hercules CODEPAGE support question

[Robert Hodge]

________________________________
From: Robert Hodge <quatras.design-/***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Sun, July 4, 2010 8:36:34 PM
Subject: Hercules CODEPAGE support question

Note: Had problem subscribing to user group at first, so original message is being re-sent ...





I am trying to understand the rationale for Hercules' code page support.
Here is the excerpt from the Hercules User Reference for CODEPAGE:

Mapping     ASCII                       EBCDIC
437/037     437 PC United States        037 United States/Canada
437/500     437 PC United States        500 Latin 1
850/273     850 PC Latin 1              273 Austria/Germany
819/273     819 ISO-8859-1              273 Austria/Germany
819/277     819 ISO-8859-1              277 Denmark/Norway
819/278     819 ISO-8859-1              278 Finland/Sweden
819/280     819 ISO-8859-1              280 Italy
819/284     819 ISO-8859-1              284 Spain
819/285     819 ISO-8859-1              285 United Kingdom
819/297     819 ISO-8859-1              297 France
819/500     819 ISO-8859-1              500 International
437/1047    437 PC United States        1047 Open Systems Latin 1
819/1047    819 ISO-8859-1              1047 Open Systems Latin 1
1252/1047   1252 Windows Latin 1        1047 Open Systems Latin 1
850/1047    850 PC Latin 1              1047 Open Systems Latin 1

My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.

Now, 1252 is close enough to 8859-1 that I could treat them as equivalent (they're not, exactly; the Euro symbol I don't use but it's wrong), but I can't use 1047 on the mainframe because the PL/1 not character is in the wrong place for me.

What I need is either a mapping of 1252/037 (preferred) or 819/037 (reasonably OK).  But neither of these is available.

Questions:

1. Are there any plans to increase the Hercules codepage mappings to include either or both of the above?

2. Can anyone tell me exactly WHERE the default codepage/CCSID for MVS is stored?  I have been googling and searching documents until my eyeballs are bugging out and I can't find it.  It does not appear to be in SYS1.PARMLIB anywhere, and where else could it be?

Thanks.




[Non-text portions of this message have been removed]

[Tony Harminc]

Post by Robert Hodge
I am trying to understand the rationale for Hercules' code page support.
Mapping     ASCII                       EBCDIC
437/037     437 PC United States        037 United States/Canada
437/500     437 PC United States        500 Latin 1
850/273     850 PC Latin 1              273 Austria/Germany
819/273     819 ISO-8859-1              273 Austria/Germany
819/277     819 ISO-8859-1              277 Denmark/Norway
819/278     819 ISO-8859-1              278 Finland/Sweden
819/280     819 ISO-8859-1              280 Italy
819/284     819 ISO-8859-1              284 Spain
819/285     819 ISO-8859-1              285 United Kingdom
819/297     819 ISO-8859-1              297 France
819/500     819 ISO-8859-1              500 International
437/1047    437 PC United States        1047 Open Systems Latin 1
819/1047    819 ISO-8859-1              1047 Open Systems Latin 1
1252/1047   1252 Windows Latin 1        1047 Open Systems Latin 1
850/1047    850 PC Latin 1              1047 Open Systems Latin 1
My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.

Well, it is indeed a strange list. And there is the further problem
that some of these codepages encode different character sets, and so
there can never be a complete mapping between them. And some people,
believing themselves to be helpful, have provided mappings between
even compatible codepages (those that encode the same character set,
e.g. 037 and 819) that intentionally mismap identical characters to
others. Nothing good will come from this.

Post by Robert Hodge
Now, 1252 is close enough to 8859-1 that I could treat them as equivalent (they're not, exactly; the Euro symbol I don't use but it's wrong), but I can't use 1047 on the mainframe because the PL/1 not character is in the wrong place for me.

If you are talking about the old PL/I F, you can modify its accepted
character set fairly easily. Have a look at module IEMBX for a start.
Those 1960s designers had already considered not only character sets,
but that someone might want to use keywords from a language other than
English.

Post by Robert Hodge
What I need is either a mapping of 1252/037 (preferred) or 819/037 (reasonably OK).  But neither of these is available.
1. Are there any plans to increase the Hercules codepage mappings to include either or both of the above?

I believe you can supply your own mapping, but I must confess I
haven't tried it.

Post by Robert Hodge
2. Can anyone tell me exactly WHERE the default codepage/CCSID for MVS is stored?  I have been googling and searching documents until my eyeballs are bugging out and I can't find it.  It does not appear to be in SYS1.PARMLIB anywhere, and where else could it be?

When you say "MVS"... MVS 3.8 and the like have no concept of
codepage. The only character translations in there are for the ASCII
magnetic and paper tape support, and in certain TP access methods like
TCAM, VTAM, and perhaps even BTAM, that translate between line codes
(which could be ASCII) and EBCDIC.

Modern "MVS", i.e. z/OS also doesn't have a single global codepage
specification, but it does have fancy translation facilities of
various sorts, including UNICODE support, and support for tagging UNIX
files with their codepage. Start with "z/OS Support for Unicode:
Using Unicode Services" SA22-7649.

Tony H.

[Kevin Leonard]

Post by Robert Hodge
I am trying to understand the rationale for Hercules' code page support.

That's delicately phrased. Thank you. "Rationale" implies a bit
more organized thought than probably went into the process. We've
added code page mappings over the years as the need arose and no
existing mapping could be made to work. The hope is to keep these
ad hoc additions as few as possible, to reduce how fast the Hercules
code base keeps growing, but if something essential is missing we'll
add it.

Post by Robert Hodge
My problem is that none of these mappings are what I want. I have
a TN3270 package that uses MS codepage 1252, and I want my MVS to
run as codepage 037.
Now, 1252 is close enough to 8859-1 that I could treat them as
equivalent (they're not, exactly; the Euro symbol I don't use but
it's wrong), but I can't use 1047 on the mainframe because the PL/1
not character is in the wrong place for me.

What code point do you need the not sign to be? With the 1047
mappings, no matter what your screen may show you, ASCII circumflex
0x5e maps to EBCDIC not sign 05f and vice versa. That is, shift+6
generates a not sign. The intent of the 1047 mappings when they
were added, in fact, was to make languages like C and PL/I work
with characters like square brackets, curly braces and not sign.
If you're finding that's not working correctly, it's something
we need to fix.

The big difference between 037 and 1047, as I recall, is the
location of the square brackets: 0xba and 0xbb in 037, 0xad and
0xbd in 1047. This always used to annoy me when using DCF because
the people at my late employer who made the decision about default
code pages decided the default would map brackets to code points
different from the ones that 3270s were hardcoded to send.

Hercules allows user-defined code page mappings to be specified
on systems that support libiconv. Unfortunately, that leaves out
Windows. Fixing this is on my list of things to do someday.

Post by Robert Hodge
2. Can anyone tell me exactly WHERE the default codepage/CCSID
for MVS is stored? I have been googling and searching documents
until my eyeballs are bugging out and I can't find it.

With MVS 3.8, at least, I don't think it's formally defined. My
guess is that (1) I/O devices were hardwired to transmit specific
codes in response to specific characters, and (2) assemblers and
compilers contained hardcoded equates like:

NOTSIGN EQU X'5F'

mapping characters to code points, and those mappings would be
propagated through everything built with the tools. When I was
young, I though the code points as listed in the green card were
absolute and universal.

--

[ScottC]

Awhile back, we had a discussion (thread) on codepages as they relate to
file transfers using wc3270 (windows version of x3270), raising some of
these issues with the exact codepages you mention, here:

http://tech.groups.yahoo.com/group/hercules-os380/message/2595
<http://tech.groups.yahoo.com/group/hercules-os380/message/2595>
<http://tech.groups.yahoo.com/group/hercules-os380/message/2595>

And for reference, here is the best reference I have seen on the subject
of which characters are defined as what and where within the codepages
you are most concerned with:

http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Host\
_Code_Page_Issues.pdf
<http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Hos\
t_Code_Page_Issues.pdf>
<http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Hos\
t_Code_Page_Issues.pdf>

Good luck, Scott C



[Non-text portions of this message have been removed]

[ScottC]

Also, using ISPF EDIT mode under "REVIEW" within Turnkey MVS will
display characters as you would expect them to be displayed, as opposed
to using edit under the "RPF" editor.

If the OS you are using (i.e. MVS 3.8), I highly recommend using
"REVIEW" in ISPF EDIT mode instead of using "RPF". The "REVIEW" editor
looks and feels like ISPF PDF EDIT which is 100 times better (really!)
than the "RPF" editor. "RPF" is still useful, but if the "REVIEW"
editor's ISPF PDF EDIT mode could be incorporated in "RPF", what a kick
arse environment we would have! I guess I'm just dreaming!

Best Regards, ScottC

Post by ScottC
Awhile back, we had a discussion (thread) on codepages as they relate to
file transfers using wc3270 (windows version of x3270), raising some of
http://tech.groups.yahoo.com/group/hercules-os380/message/2595

<http://tech.groups.yahoo.com/group/hercules-os380/message/2595> >

Post by ScottC
And for reference, here is the best reference I have seen on the subject
of which characters are defined as what and where within the codepages

http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Host\
_Code_Page_Issues.pdf
<http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Hos\
t_Code_Page_Issues.pdf>

Post by ScottC
Good luck, Scott C

[Non-text portions of this message have been removed]

[Robert Hodge]

Thanks for the background, especially the Hummingbird / IBM Code Page pdf.  The code page Share 037/2 or 1140/2 is what I need, and I already have a 037/2 translation table for my terminal software.  What I am aiming for is an attempt to unify all the codepages so there's only one.  I can make any code page I want (I can customized my TN3270 session to be fully compatible end-to-end, but there are two other translations going on. 
 
First, Hercules has its own (limited number of) translation tables for converting unit-record I/O, not all of which are useful to everyone.  I believe the correct way to handle this is to have a codepage definition facility as part of the Hercules startup.  Instead of predefined code pages, there would be a number of external files defining several code pages, and Hercules users would select one with an INCLUDE or include-like facility.  If the canned code pages don't suit them, they could define their own, so they could make up their own definitions like 037/2, 1140/2 or anything else.  That's how I would like to see Hercules operate.  That way, it wouldn't be necessary to keep changing Hercules if the end users could easily do it themselves.
 
Second, MVS has its rules for handing ASCII to EBCDIC conversions for tape I/O.  I have seen a few references that the code page for ASCII tape I/O is 500, or may be encoded in the tape label.  I'm a little murky on this one.
 
What is really confusing me is the constant references on web pages to what people call the "default MVS code page".  "Everybody" seems to think that MVS has some kind of "default" EBCDIC code page, but I can't find any real references to it.  Is there really a default EBCDIC code page, or is this just a big misperception?  If there is such a default, I'd like to know where it's defined, but if there *isn't* any default, why in the world does everyone think there is?
 
 



________________________________
From: ScottC <scosel-zowzMcKzJCWxC8Nw+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Mon, July 5, 2010 6:07:28 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

Also, using ISPF EDIT mode under "REVIEW" within Turnkey MVS will
display characters as you would expect them to be displayed, as opposed
to using edit under the "RPF" editor.

If the OS you are using (i.e. MVS 3.8), I highly recommend using
"REVIEW" in ISPF EDIT mode instead of using "RPF". The "REVIEW" editor
looks and feels like ISPF PDF EDIT which is 100 times better (really!)
than the "RPF" editor. "RPF" is still useful, but if the "REVIEW"
editor's ISPF PDF EDIT mode could be incorporated in "RPF", what a kick
arse environment we would have! I guess I'm just dreaming!

Best Regards, ScottC

Post by ScottC
Awhile back, we had a discussion (thread) on codepages as they relate to
file transfers using wc3270 (windows version of x3270), raising some of
http://tech.groups.yahoo.com/group/hercules-os380/message/2595

<http://tech.groups.yahoo.com/group/hercules-os380/message/2595> >

Post by ScottC
And for reference, here is the best reference I have seen on the subject
of which characters are defined as what and where within the codepages

http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Host_Code_Page_Issues.pdf
<http://mimage.hummingbird.com/alt_content/binary/pdf/support/nc/IBM_Host_Code_Page_Issues.pdf>

Post by ScottC
Good luck, Scott C

[Non-text portions of this message have been removed]








[Non-text portions of this message have been removed]

[Gerhard Postpischil]

Hercules startup. Instead of predefined code pages, there
would be a number of external files defining several code
pages, and Hercules users would select one with an INCLUDE or
include-like facility. If the canned code pages don't suit
them, they could define their own, so they could make up
their own definitions like 037/2, 1140/2 or anything else.
That's how I would like to see Hercules operate. That way,
it wouldn't be necessary to keep changing Hercules if the end
users could easily do it themselves.

I second that, but I'd hope to need more than one INCLUDE per
device. Both the reader and print/punch devices have an ASCII
and EBCDIC option, and each mode should be supported in the same
execution.

Second, MVS has its rules for handing ASCII to EBCDIC
conversions for tape I/O. I have seen a few references that
the code page for ASCII tape I/O is 500, or may be encoded in
the tape label. I'm a little murky on this one.

I don't know whether the translation has a code page number;
I've always heard it referred to as ISCII (strictly speaking
ASCII is a 7-bit code). I first saw the translation in the Tape
Labels manual, complete with one error in the printed tables (I
never checked whether they followed up my error report with
corrections in subsequent editions). There is nothing special in
the tape label; open and EOV processing read the first record on
tape, if it's not EBCDIC VOL1 they try to interpret it as ISCII
to see if it's VOL1. If neither it's treated as unlabeled.

"Everybody" seems to think that MVS has some kind of
"default" EBCDIC code page, but I can't find any real
references to it. Is there really a default EBCDIC code
page, or is this just a big misperception? If there is such
a default, I'd like to know where it's defined, but if there
*isn't* any default, why in the world does everyone think
there is?

On the original green card IBM published both the BCD and EBCDIC
codes; I suspect that that may have given rise to the
misperception. As mentioned earlier in the thread, CRTs have
built-in codes, with national variations, that force a character
set (and I seem to recall BSC mode 3270s with a near ASCII
character set). The old 1403, 3211, etc. printers were character
set independent, as they allowed the user to program which
character on a train or chain corresponded to which code. The
only hard and fast dependencies I know of are in module
IGC0005A, CSECT IEAVAD51, which displays "unprintable"
characters as periods on a dump; the translation for "ASCII"
tapes; TSO's TIOC terminal tables; and VTAM terminal tables.

I expect that running all the system source through a
translator, and compiling/assembling that, would come pretty
close to providing a functional version of the system. Some
components would need fixes, where translation is performed, but
the basics should work.

Gerhard Postpischil
Bradford, VT

[Dave Wade]

Post by Robert Hodge

Post by Robert Hodge
"Everybody" seems to think that MVS has some kind of

"default" EBCDIC

Post by Robert Hodge
code page, but I can't find any real references to it. Is there
really a default EBCDIC code page, or is this just a big
misperception? If there is such a default, I'd like to know where
it's defined, but if there
*isn't* any default, why in the world does everyone think there is?

On the original green card IBM published both the BCD and EBCDIC
codes;

The later Yellow cards continue this convention. So I have a GX20-1850-3
dated November 1976, (There is a copy as PDF here:-

http://www.bitsavers.org/pdf/ibm/370/referenceCard/

It has four pages entitled "Code translation Table" which list for each HEX
value, OP Code, Graphic for BCDIC,EBCDIC & ASCII, 7-Track Tape, Card Code,
and the binary. In the notes it says there are two Graphics for EBCDIC the
first is the "IBM Standard US code" and the second is the T11 and TN print
train code. Sadly whilst it quotes definitive sources for the other
information on the card, there aren't any references for the translation
tables. I also seem to remember references to "Primary Currency Character"
and "Secondary Currency Character" code points which I don't see in manuals.
This always caused issues in the UK as the EBCDIC code points for "$" and
"cent" were displayed as "£" and "$" on a UK screen or printer. Very
confusing....

Post by Robert Hodge
I suspect that that may have given rise to the
misperception. As mentioned earlier in the thread, CRTs have
built-in codes, with national variations, that force a character
set (and I seem to recall BSC mode 3270s with a near ASCII
character set). The old 1403, 3211, etc. printers were character
set independent, as they allowed the user to program which
character on a train or chain corresponded to which code. The
only hard and fast dependencies I know of are in module
IGC0005A, CSECT IEAVAD51, which displays "unprintable"
characters as periods on a dump; the translation for "ASCII"
tapes; TSO's TIOC terminal tables; and VTAM terminal tables.
I expect that running all the system source through a
translator, and compiling/assembling that, would come pretty
close to providing a functional version of the system. Some
components would need fixes, where translation is performed, but
the basics should work.
Gerhard Postpischil
Bradford, VT

Dave Wade G4UGM
Illegitimi Non Carborundum

[Martin Trübner]

Dave,

I have GX20-1850-4 (1981) in front of me and here it says in the notes
about the columns:

Two columns of EBCDIC are shown. The first gives IBM standard US bit
pattern assignments. The second shows the T-11 and TN text
printing chains (120 graphics).

And: version -7 (1989) has the same text.

[Greg Price]

Post by Robert Hodge
Second, MVS has its rules for handing ASCII to EBCDIC conversions for tape I/O.

See the translate tables hard-coded in LPA module
IGC0010C, which is of course SVC 103 as used by
the XLATE macro and OPTCD=Q.

Cheers,
Greg P.

[Robert Hodge]

I found an online listing for IGC0010C (doesn't look like an official IBM file but seems reasonable), and I see how changing it could address this issue.  However, it's been a really long time since I used SMP/E.  Does anyone know how I could go about packaging this up and changing module IGC0010C to define my own default XLATE translation tables for SVC 103 ?  Thanks.




________________________________
From: Greg Price <greg.price-sFbbPxZDHXw0n/***@public.gmane.org>
To: "hercules-390-***@public.gmane.org" <hercules-390-***@public.gmane.org>
Sent: Tue, July 6, 2010 1:07:21 AM
Subject: Re: [hercules-390] Re: Hercules CODEPAGE support question

 

Post by Robert Hodge
Second, MVS has its rules for handing ASCII to EBCDIC conversions for tape I/O.

See the translate tables hard-coded in LPA module
IGC0010C, which is of course SVC 103 as used by
the XLATE macro and OPTCD=Q.

Cheers,
Greg P.







[Non-text portions of this message have been removed]

[Greg Price]

Post by Robert Hodge
Does anyone know how I could go about packaging this up and changing module IGC0010C to define

my own default XLATE translation tables for SVC 103 ?

I've had a go at coding up a sample usermod
downloadable from
www.prycroft6.com.au/vs2mods
- scroll down to the bottom and select ZP60029.
This is for MVS 3.8, but it could be used as a
basis for later OSes, though you'd have to
refit the offsets I expect.

Cheers,
Greg

[Robert Hodge]

Greg,

I looked at the samples on your web site.  They were very informative and that
was just the help I was looking for.  Thanks so much for your assistance.  You
have a lot of interesting stuff on your site, things that every Hercules user
would benefit from.

Thanks, Robert




________________________________
From: Greg Price <greg.price-sFbbPxZDHXw0n/***@public.gmane.org>
To: "hercules-390-***@public.gmane.org" <hercules-390-***@public.gmane.org>
Sent: Sat, July 10, 2010 6:41:49 AM
Subject: Re: [hercules-390] Hercules CODEPAGE support question

 

Post by Robert Hodge
Does anyone know how I could go about packaging this up and changing module
IGC0010C to define

my own default XLATE translation tables for SVC 103 ?

I've had a go at coding up a sample usermod
downloadable from
www.prycroft6.com.au/vs2mods
- scroll down to the bottom and select ZP60029.
This is for MVS 3.8, but it could be used as a
basis for later OSes, though you'd have to
refit the offsets I expect.

Cheers,
Greg







[Non-text portions of this message have been removed]

[Dave Wade]

This post might be inappropriate. Click to display it.

[dekel35]

Post by Robert Hodge
My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.

I might be wrong, but I don't believe these code pages have anything to do with terminal emulation programs connecting through TCP/IP to the host.
My understanding is that it relates to the display of hercules own data on the PC.
When MVS communicates with a 3270 emulator (e.g., pc based), it sends ebcdic data and the terminal displays that data according to the codepage defined to the terminal emulation. I doubt that hercules intervenes in that protocol and translates data back and forth. What am I missing?

[Robert Hodge]

You're right, for the 3270 emulator, Hercules doesn't get involved.  I use SDI's TN3270 Plus, which allows user-defined translation tables.  Where I have a problem is with Hercules' translation tables for unit-record I/O for card reader and printer emulation.  I can deal MVS tape translation issues, because I would rarely if ever use simulated tape files.  Here is the most common case:  I enter program source code via a TN3270 session, which I define as a custom translation of MS 1252 Windows code page to MVS 037 EBCDIC.  I compile the source code and get a listing file, which is written out by JES2, captured by Hercules, translated to ASCII using *some* Hercules translation table, and it ends up an ASCII text file on my PC.  Since Hercules' translation table choices don't account for this 1252-to-037 mapping, the ASCII version of the print file will not have all the characters correct.  The main areas where the characters are an issue are the
Not, Circumflex, and square brackets.  The Share 037/2 code page, in particular, addresses this issue quite nicely, but the problem is that Hercules doesn't allow me to specify this as a choice in the hercules.cfg CODEPAGE parameter.

That's why I'd like to see the .cfg option for CODEPAGE enhanced so that it would read in a text file and dynamically build a user-specified translation table for unit-record I/O. (Correct me if I'm wrong, but I don't think Hercules gets involved in EBCDIC/ASCII translation anywhere else except when it captures JES unit-record data).

Just FYI, here is a copy of the SDI TN3270 Plus translation table specification for 037/2.  It would be *great* if Hercules could read such a file or something very similar and use it to build its translation table and Hercules start-up time.  The format should be fairly self-evident; displayable characters are shown as-is, while undisplayable codes are represented as 2-character hex values.

Hope this proves interesting ....


*-------------------------------------------------*
*                                                 *
*            TN3270 Plus  (c) SDI 1997            *
*                                                 *
*     Host Code Page English-US C370 CECP V2      *
*       Also known as Share Code Page 37-2        *
*                                                 *
*-------------------------------------------------*
CodePage
Name "English-US C370 CECP V2"
CGCSGID 697 037
BEGIN
*    0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
00: 00 01 02 03 9c 09 86 7f 97 8d 8e 0b 0c 0d 0e 0f
10: 10 11 12 13 9d 85 08 87 18 19 92 8f 1c 1d 1e 1f
20: 80 81 82 83 84 0a 17 1b 88 89 8a 8b 8c 05 06 07
30: 90 91 16 93 94 95 96 04 98 99 9a 9b 14 15 9e 1a
40: 20 a0  â  À  à  á  ã  å  ç  ñ  ¢  .  <  (  +  |
50:  &  é  ê  ë  Ú  í  î  ï  ì  ß  !  $  *  )  ;  ¬
60:  -  /    Ä  À  Á  à Å  Ç  Ñ  Š  ,  %  _  >  ?
70:  Þ  É  Ê  Ë  È  Í  Π Ï  Ì  `  :  #  @  '  =  "
80:  Ø  a  b  c  d  e  f  g  h  i  «  »  ð  Ü  ß  ±
90:  °  j  k  l  m  n  o  p  q  r  ª  º  Ê  ž  Æ  €
A0:  µ  ~  s  t  u  v  w  x  y  z  ¡  ¿  Р [  Þ  ®
B0:  ^  £  ¥  ·  ©  §  ¶  Œ  œ  Ÿ  Ý  š  ¯  ]  Ž  ×
C0:  {  A  B  C  D  E  F  G  H  I ad  Π ö  ò  ó  õ
D0:  }  J  K  L  M  N  O  P  Q  R  ¹  û  Ì  ù  ú  ÿ
E0:  \  ÷  S  T  U  V  W  X  Y  Z  ²  Ô  Ö  Ò  Ó  Õ
F0:  0  1  2  3  4  5  6  7  8  9  ³  Û  Ü  Ù  Ú 9f
END


 



________________________________
From: dekel35 <jacob-d8ny+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Tue, July 6, 2010 7:04:26 AM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.

I might be wrong, but I don't believe these code pages have anything to do with terminal emulation programs connecting through TCP/IP to the host.
My understanding is that it relates to the display of hercules own data on the PC.
When MVS communicates with a 3270 emulator (e.g., pc based), it sends ebcdic data and the terminal displays that data according to the codepage defined to the terminal emulation. I doubt that hercules intervenes in that protocol and translates data back and forth. What am I missing?







[Non-text portions of this message have been removed]

[Rocky]

Hi
Actually I had the same problem. Lots of output in Hebrew which is/was unsupported on the printers in Hercules.
Terminal is not a problem because I can use my own code-table in the emulator. (which you pointed out)

I needed an urgent solution and what I did was put a pipe on the printer. Small C-Program that just translated the Hebrew EBCIDEC Hexadecimal equivalents to the relavant ASCII Hebrew equivalents that I wanted in windows.

it was lot more complicated than that because the Hebrew Windows API also does repositioning and reversal of characters,

Numbers and special symbols work differently than Letters. RTl LTR etc.
But it works for me and the output is very ledgible,,, (if you understand Hebrew). ?

One advantage of that was that I caught the JOB seperators in the PIPE and now every file that I print comes out separtely with a name which I pick up from the seperator page. And I don't need to close the printer etc. to get them. I just print and its there immediately

Roc



_____

From: hercules-390-***@public.gmane.org [mailto:hercules-390-***@public.gmane.org] On Behalf Of Robert Hodge
Sent: Tuesday, July 06, 2010 14:39
To: hercules-390-***@public.gmane.org
Subject: Re: [hercules-390] Re: Hercules CODEPAGE support question




You're right, for the 3270 emulator, Hercules doesn't get involved. I use SDI's TN3270 Plus, which allows user-defined translation tables. Where I have a problem is with Hercules' translation tables for unit-record I/O for card reader and printer emulation. I can deal MVS tape translation issues, because I would rarely if ever use simulated tape files. Here is the most common case: I enter program source code via a TN3270 session, which I define as a custom translation of MS 1252 Windows code page to MVS 037 EBCDIC. I compile the source code and get a listing file, which is written out by JES2, captured by Hercules, translated to ASCII using *some* Hercules translation table, and it ends up an ASCII text file on my PC. Since Hercules' translation table choices don't account for this 1252-to-037 mapping, the ASCII version of the print file will not have all the characters correct. The main areas where the characters are an issue are the
Not, Circumflex, and square brackets. The Share 037/2 code page, in particular, addresses this issue quite nicely, but the problem is that Hercules doesn't allow me to specify this as a choice in the hercules.cfg CODEPAGE parameter.

That's why I'd like to see the .cfg option for CODEPAGE enhanced so that it would read in a text file and dynamically build a user-specified translation table for unit-record I/O. (Correct me if I'm wrong, but I don't think Hercules gets involved in EBCDIC/ASCII translation anywhere else except when it captures JES unit-record data).

Just FYI, here is a copy of the SDI TN3270 Plus translation table specification for 037/2. It would be *great* if Hercules could read such a file or something very similar and use it to build its translation table and Hercules start-up time. The format should be fairly self-evident; displayable characters are shown as-is, while undisplayable codes are represented as 2-character hex values.

Hope this proves interesting ....

*-------------------------------------------------*
* *
* TN3270 Plus (c) SDI 1997 *
* *
* Host Code Page English-US C370 CECP V2 *
* Also known as Share Code Page 37-2 *
* *
*-------------------------------------------------*
CodePage
Name "English-US C370 CECP V2"
CGCSGID 697 037
BEGIN
* 0 1 2 3 4 5 6 7 8 9 A B C D E F
00: 00 01 02 03 9c 09 86 7f 97 8d 8e 0b 0c 0d 0e 0f
10: 10 11 12 13 9d 85 08 87 18 19 92 8f 1c 1d 1e 1f
20: 80 81 82 83 84 0a 17 1b 88 89 8a 8b 8c 05 06 07
30: 90 91 16 93 94 95 96 04 98 99 9a 9b 14 15 9e 1a
40: 20 a0 â À à á ã å ç ñ ¢ . < ( + |
50: & é ê ë Ú í î ï ì ß ! $ * ) ; ¬
60: - / Â Ä À Á Ã Å Ç Ñ Š , % _ > ?
70: Þ É Ê Ë È Í Î Ï Ì ` : # @ ' = "
80: Ø a b c d e f g h i « » ð Ãœ ß ±
90: ° j k l m n o p q r ª º Ê ž Æ €
A0: µ ~ s t u v w x y z ¡ ¿ Ð [ Þ ®
B0: ^ £ Â¥ · © § ¶ ÂŒ Âœ Ÿ Ý š ¯ ] ÂŽ ×
C0: { A B C D E F G H I ad Î ö ò ó õ
D0: } J K L M N O P Q R ¹ û Ì ù ú ÿ
E0: \ ÷ S T U V W X Y Z ² Ô Ö Ò Ó Õ
F0: 0 1 2 3 4 5 6 7 8 9 ³ Û Ü Ù Ú 9f
END



________________________________
From: dekel35 <jacob-d8ny+***@public.gmane.org <mailto:jacob%40mvsdasd.org> >
To: hercules-390-***@public.gmane.org <mailto:hercules-390%40yahoogroups.com>
Sent: Tue, July 6, 2010 7:04:26 AM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

My problem is that none of these mappings are what I want. I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.

I might be wrong, but I don't believe these code pages have anything to do with terminal emulation programs connecting through TCP/IP to the host.
My understanding is that it relates to the display of hercules own data on the PC.
When MVS communicates with a 3270 emulator (e.g., pc based), it sends ebcdic data and the terminal displays that data according to the codepage defined to the terminal emulation. I doubt that hercules intervenes in that protocol and translates data back and forth. What am I missing?

[Non-text portions of this message have been removed]






[Non-text portions of this message have been removed]

[Paul]

The Hercules CODEPAGE support is used to translate data from the GUEST os to the HOST os and vice versa. For example, when using SCP messages, "." prefixing, to send a command to the GUEST, host_to_guest() is called to translate the string to EBCDIC from the character set your machine is using.

Likewise, when a message is sent from the GUEST to the Hercules console, guest_to_host is called to translate it from EBCDIC.

The integrated TN3270 server, debugging information from the channel, printer, card reader, punch, 1052C and several utilities use the functions.

Essentially, anytime translation from/to EBCDIC is neccessary within Hercules itself, host_to_guest() and guest_to_host() are used and these functions use the codepages.

The public domain OSes, such as VSE, VM and MVS, were built before CCSIDs, NLS, etc. were developed. Both EBCDIC and ASCII translate tables are hardcoded in various modules. The translate tables generally matched what was on the references cards "green and yellow" for the processors of that period. ( Note: ASCII was only in the range of 0-127 decimal in value.)

FYI, in VM the DMKTTY support has tables adjusted to how the 270x machines put data on the channel; bit backwards, with various parity settings.

Paul

Post by Robert Hodge
________________________________
Sent: Sun, July 4, 2010 8:36:34 PM
Subject: Hercules CODEPAGE support question
Note: Had problem subscribing to user group at first, so original message is being re-sent ...
I am trying to understand the rationale for Hercules' code page support.
Mapping     ASCII                       EBCDIC
437/037     437 PC United States        037 United States/Canada
437/500     437 PC United States        500 Latin 1
850/273     850 PC Latin 1              273 Austria/Germany
819/273     819 ISO-8859-1              273 Austria/Germany
819/277     819 ISO-8859-1              277 Denmark/Norway
819/278     819 ISO-8859-1              278 Finland/Sweden
819/280     819 ISO-8859-1              280 Italy
819/284     819 ISO-8859-1              284 Spain
819/285     819 ISO-8859-1              285 United Kingdom
819/297     819 ISO-8859-1              297 France
819/500     819 ISO-8859-1              500 International
437/1047    437 PC United States        1047 Open Systems Latin 1
819/1047    819 ISO-8859-1              1047 Open Systems Latin 1
1252/1047   1252 Windows Latin 1        1047 Open Systems Latin 1
850/1047    850 PC Latin 1              1047 Open Systems Latin 1
My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.
Now, 1252 is close enough to 8859-1 that I could treat them as equivalent (they're not, exactly; the Euro symbol I don't use but it's wrong), but I can't use 1047 on the mainframe because the PL/1 not character is in the wrong place for me.
What I need is either a mapping of 1252/037 (preferred) or 819/037 (reasonably OK).  But neither of these is available.
1. Are there any plans to increase the Hercules codepage mappings to include either or both of the above?
2. Can anyone tell me exactly WHERE the default codepage/CCSID for MVS is stored?  I have been googling and searching documents until my eyeballs are bugging out and I can't find it.  It does not appear to be in SYS1.PARMLIB anywhere, and where else could it be?
Thanks.
[Non-text portions of this message have been removed]

[Paul]

Codepage 819/037 support has been added to the svn (6164).

Please double check the pages. There were several sites that referenced the translation and there were minor differences between the pages.

Paul

Post by Paul
The Hercules CODEPAGE support is used to translate data from the GUEST os to the HOST os and vice versa. For example, when using SCP messages, "." prefixing, to send a command to the GUEST, host_to_guest() is called to translate the string to EBCDIC from the character set your machine is using.
Likewise, when a message is sent from the GUEST to the Hercules console, guest_to_host is called to translate it from EBCDIC.
The integrated TN3270 server, debugging information from the channel, printer, card reader, punch, 1052C and several utilities use the functions.
Essentially, anytime translation from/to EBCDIC is neccessary within Hercules itself, host_to_guest() and guest_to_host() are used and these functions use the codepages.
The public domain OSes, such as VSE, VM and MVS, were built before CCSIDs, NLS, etc. were developed. Both EBCDIC and ASCII translate tables are hardcoded in various modules. The translate tables generally matched what was on the references cards "green and yellow" for the processors of that period. ( Note: ASCII was only in the range of 0-127 decimal in value.)
FYI, in VM the DMKTTY support has tables adjusted to how the 270x machines put data on the channel; bit backwards, with various parity settings.
Paul

Post by Robert Hodge
________________________________
Sent: Sun, July 4, 2010 8:36:34 PM
Subject: Hercules CODEPAGE support question
Note: Had problem subscribing to user group at first, so original message is being re-sent ...
I am trying to understand the rationale for Hercules' code page support.
Mapping     ASCII                       EBCDIC
437/037     437 PC United States        037 United States/Canada
437/500     437 PC United States        500 Latin 1
850/273     850 PC Latin 1              273 Austria/Germany
819/273     819 ISO-8859-1              273 Austria/Germany
819/277     819 ISO-8859-1              277 Denmark/Norway
819/278     819 ISO-8859-1              278 Finland/Sweden
819/280     819 ISO-8859-1              280 Italy
819/284     819 ISO-8859-1              284 Spain
819/285     819 ISO-8859-1              285 United Kingdom
819/297     819 ISO-8859-1              297 France
819/500     819 ISO-8859-1              500 International
437/1047    437 PC United States        1047 Open Systems Latin 1
819/1047    819 ISO-8859-1              1047 Open Systems Latin 1
1252/1047   1252 Windows Latin 1        1047 Open Systems Latin 1
850/1047    850 PC Latin 1              1047 Open Systems Latin 1
My problem is that none of these mappings are what I want.  I have a TN3270 package that uses MS codepage 1252, and I want my MVS to run as codepage 037.
Now, 1252 is close enough to 8859-1 that I could treat them as equivalent (they're not, exactly; the Euro symbol I don't use but it's wrong), but I can't use 1047 on the mainframe because the PL/1 not character is in the wrong place for me.
What I need is either a mapping of 1252/037 (preferred) or 819/037 (reasonably OK).  But neither of these is available.
1. Are there any plans to increase the Hercules codepage mappings to include either or both of the above?
2. Can anyone tell me exactly WHERE the default codepage/CCSID for MVS is stored?  I have been googling and searching documents until my eyeballs are bugging out and I can't find it.  It does not appear to be in SYS1.PARMLIB anywhere, and where else could it be?
Thanks.
[Non-text portions of this message have been removed]

[Tony Harminc]

Post by Paul
Codepage 819/037 support has been added to the svn (6164).
Please double check the pages. There were several sites that referenced

the translation and there were minor differences between the pages.

There should be no differencees between tables for codepages that encode the
identical character set, as these two do. If you have found differences,
someone has set up their own idea of what is convenient for them rather than
a correct mapping, and this is certainly going to cause trouble for someone
else at some point.

These are generated by a tiny REXX program from the IBM CDRA tables at
http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip Of
course you can just use the IBM binary tables directly rather than passing
them through a disassembly/reassembly process.

First in C style:

/* 037 to 819 */
static unsigned char

cp_037_to_819[] = {

/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
*/
/* 0x */ "\x00\x01\x02\x03\x9C\x09\x86\x7F\x97\x8D\x8E\x0B\x0C\x0D\x0E\x0F"

/* 1x */ "\x10\x11\x12\x13\x9D\x85\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F"

/* 2x */ "\x80\x81\x82\x83\x84\x0A\x17\x1B\x88\x89\x8A\x8B\x8C\x05\x06\x07"

/* 3x */ "\x90\x91\x16\x93\x94\x95\x96\x04\x98\x99\x9A\x9B\x14\x15\x9E\x1A"

/* 4x */ "\x20\xA0\xE2\xE4\xE0\xE1\xE3\xE5\xE7\xF1\xA2\x2E\x3C\x28\x2B\x7C"

/* 5x */ "\x26\xE9\xEA\xEB\xE8\xED\xEE\xEF\xEC\xDF\x21\x24\x2A\x29\x3B\xAC"

/* 6x */ "\x2D\x2F\xC2\xC4\xC0\xC1\xC3\xC5\xC7\xD1\xA6\x2C\x25\x5F\x3E\x3F"

/* 7x */ "\xF8\xC9\xCA\xCB\xC8\xCD\xCE\xCF\xCC\x60\x3A\x23\x40\x27\x3D\x22"

/* 8x */ "\xD8\x61\x62\x63\x64\x65\x66\x67\x68\x69\xAB\xBB\xF0\xFD\xFE\xB1"

/* 9x */ "\xB0\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\xAA\xBA\xE6\xB8\xC6\xA4"

/* Ax */ "\xB5\x7E\x73\x74\x75\x76\x77\x78\x79\x7A\xA1\xBF\xD0\xDD\xDE\xAE"

/* Bx */ "\x5E\xA3\xA5\xB7\xA9\xA7\xB6\xBC\xBD\xBE\x5B\x5D\xAF\xA8\xB4\xD7"

/* Cx */ "\x7B\x41\x42\x43\x44\x45\x46\x47\x48\x49\xAD\xF4\xF6\xF2\xF3\xF5"

/* Dx */ "\x7D\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\xB9\xFB\xFC\xF9\xFA\xFF"

/* Ex */ "\x5C\xF7\x53\x54\x55\x56\x57\x58\x59\x5A\xB2\xD4\xD6\xD2\xD3\xD5"

/* Fx */ "\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\xB3\xDB\xDC\xD9\xDA\x9F"

};


/* 819 to 037 */
static unsigned char

cp_819_to_037[] = {

/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
*/
/* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x25\x0B\x0C\x0D\x0E\x0F"

/* 1x */ "\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F"

/* 2x */ "\x40\x5A\x7F\x7B\x5B\x6C\x50\x7D\x4D\x5D\x5C\x4E\x6B\x60\x4B\x61"

/* 3x */ "\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\x7A\x5E\x4C\x7E\x6E\x6F"

/* 4x */ "\x7C\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xD1\xD2\xD3\xD4\xD5\xD6"

/* 5x */ "\xD7\xD8\xD9\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xBA\xE0\xBB\xB0\x6D"

/* 6x */ "\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96"

/* 7x */ "\x97\x98\x99\xA2\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xC0\x4F\xD0\xA1\x07"

/* 8x */ "\x20\x21\x22\x23\x24\x15\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B"

/* 9x */ "\x30\x31\x1A\x33\x34\x35\x36\x08\x38\x39\x3A\x3B\x04\x14\x3E\xFF"

/* Ax */ "\x41\xAA\x4A\xB1\x9F\xB2\x6A\xB5\xBD\xB4\x9A\x8A\x5F\xCA\xAF\xBC"

/* Bx */ "\x90\x8F\xEA\xFA\xBE\xA0\xB6\xB3\x9D\xDA\x9B\x8B\xB7\xB8\xB9\xAB"

/* Cx */ "\x64\x65\x62\x66\x63\x67\x9E\x68\x74\x71\x72\x73\x78\x75\x76\x77"

/* Dx */ "\xAC\x69\xED\xEE\xEB\xEF\xEC\xBF\x80\xFD\xFE\xFB\xFC\xAD\xAE\x59"

/* Ex */ "\x44\x45\x42\x46\x43\x47\x9C\x48\x54\x51\x52\x53\x58\x55\x56\x57"

/* Fx */ "\x8C\x49\xCD\xCE\xCB\xCF\xCC\xE1\x70\xDD\xDE\xDB\xDC\x8D\x8E\xDF"

};


and then in ASM format for those who find it easier reading:

* From CP = 037 To CP = 819
DC X'000102039C09867F978D8E0B0C0D0E0F' 00-0F
DC X'101112139D8508871819928F1C1D1E1F' 10-1F
DC X'80818283840A171B88898A8B8C050607' 20-2F
DC X'909116939495960498999A9B14159E1A' 30-3F
DC X'20A0E2E4E0E1E3E5E7F1A22E3C282B7C' 40-4F
DC X'26E9EAEBE8EDEEEFECDF21242A293BAC' 50-5F
DC X'2D2FC2C4C0C1C3C5C7D1A62C255F3E3F' 60-6F
DC X'F8C9CACBC8CDCECFCC603A2340273D22' 70-7F
DC X'D8616263646566676869ABBBF0FDFEB1' 80-8F
DC X'B06A6B6C6D6E6F707172AABAE6B8C6A4' 90-9F
DC X'B57E737475767778797AA1BFD0DDDEAE' A0-AF
DC X'5EA3A5B7A9A7B6BCBDBE5B5DAFA8B4D7' B0-BF
DC X'7B414243444546474849ADF4F6F2F3F5' C0-CF
DC X'7D4A4B4C4D4E4F505152B9FBFCF9FAFF' D0-DF
DC X'5CF7535455565758595AB2D4D6D2D3D5' E0-EF
DC X'30313233343536373839B3DBDCD9DA9F' F0-FF

* From CP = 819 To CP = 037
DC X'00010203372D2E2F1605250B0C0D0E0F' 00-0F
DC X'101112133C3D322618193F271C1D1E1F' 10-1F
DC X'405A7F7B5B6C507D4D5D5C4E6B604B61' 20-2F
DC X'F0F1F2F3F4F5F6F7F8F97A5E4C7E6E6F' 30-3F
DC X'7CC1C2C3C4C5C6C7C8C9D1D2D3D4D5D6' 40-4F
DC X'D7D8D9E2E3E4E5E6E7E8E9BAE0BBB06D' 50-5F
DC X'79818283848586878889919293949596' 60-6F
DC X'979899A2A3A4A5A6A7A8A9C04FD0A107' 70-7F
DC X'202122232415061728292A2B2C090A1B' 80-8F
DC X'30311A333435360838393A3B04143EFF' 90-9F
DC X'41AA4AB19FB26AB5BDB49A8A5FCAAFBC' A0-AF
DC X'908FEAFABEA0B6B39DDA9B8BB7B8B9AB' B0-BF
DC X'6465626663679E687471727378757677' C0-CF
DC X'AC69EDEEEBEFECBF80FDFEFBFCADAE59' D0-DF
DC X'4445424643479C485451525358555657' E0-EF
DC X'8C49CDCECBCFCCE170DDDEDBDC8D8EDF' F0-FF

Tony H.


[Non-text portions of this message have been removed]

[Paul]

Hercules SVN(6165) has this set of tables.

Paul

Post by Paul

Post by Paul
Codepage 819/037 support has been added to the svn (6164).
Please double check the pages. There were several sites that referenced

the translation and there were minor differences between the pages.
There should be no differencees between tables for codepages that encode the
identical character set, as these two do. If you have found differences,
someone has set up their own idea of what is convenient for them rather than
a correct mapping, and this is certainly going to cause trouble for someone
else at some point.
These are generated by a tiny REXX program from the IBM CDRA tables at
http://download.boulder.ibm.com/ibmdl/pub/software/dw/java/cdctables.zip Of
course you can just use the IBM binary tables directly rather than passing
them through a disassembly/reassembly process.
/* 037 to 819 */
static unsigned char
cp_037_to_819[] = {
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
*/
/* 0x */ "\x00\x01\x02\x03\x9C\x09\x86\x7F\x97\x8D\x8E\x0B\x0C\x0D\x0E\x0F"
/* 1x */ "\x10\x11\x12\x13\x9D\x85\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F"
/* 2x */ "\x80\x81\x82\x83\x84\x0A\x17\x1B\x88\x89\x8A\x8B\x8C\x05\x06\x07"
/* 3x */ "\x90\x91\x16\x93\x94\x95\x96\x04\x98\x99\x9A\x9B\x14\x15\x9E\x1A"
/* 4x */ "\x20\xA0\xE2\xE4\xE0\xE1\xE3\xE5\xE7\xF1\xA2\x2E\x3C\x28\x2B\x7C"
/* 5x */ "\x26\xE9\xEA\xEB\xE8\xED\xEE\xEF\xEC\xDF\x21\x24\x2A\x29\x3B\xAC"
/* 6x */ "\x2D\x2F\xC2\xC4\xC0\xC1\xC3\xC5\xC7\xD1\xA6\x2C\x25\x5F\x3E\x3F"
/* 7x */ "\xF8\xC9\xCA\xCB\xC8\xCD\xCE\xCF\xCC\x60\x3A\x23\x40\x27\x3D\x22"
/* 8x */ "\xD8\x61\x62\x63\x64\x65\x66\x67\x68\x69\xAB\xBB\xF0\xFD\xFE\xB1"
/* 9x */ "\xB0\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\xAA\xBA\xE6\xB8\xC6\xA4"
/* Ax */ "\xB5\x7E\x73\x74\x75\x76\x77\x78\x79\x7A\xA1\xBF\xD0\xDD\xDE\xAE"
/* Bx */ "\x5E\xA3\xA5\xB7\xA9\xA7\xB6\xBC\xBD\xBE\x5B\x5D\xAF\xA8\xB4\xD7"
/* Cx */ "\x7B\x41\x42\x43\x44\x45\x46\x47\x48\x49\xAD\xF4\xF6\xF2\xF3\xF5"
/* Dx */ "\x7D\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\xB9\xFB\xFC\xF9\xFA\xFF"
/* Ex */ "\x5C\xF7\x53\x54\x55\x56\x57\x58\x59\x5A\xB2\xD4\xD6\xD2\xD3\xD5"
/* Fx */ "\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\xB3\xDB\xDC\xD9\xDA\x9F"
};
/* 819 to 037 */
static unsigned char
cp_819_to_037[] = {
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF
*/
/* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x25\x0B\x0C\x0D\x0E\x0F"
/* 1x */ "\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F"
/* 2x */ "\x40\x5A\x7F\x7B\x5B\x6C\x50\x7D\x4D\x5D\x5C\x4E\x6B\x60\x4B\x61"
/* 3x */ "\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\x7A\x5E\x4C\x7E\x6E\x6F"
/* 4x */ "\x7C\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xD1\xD2\xD3\xD4\xD5\xD6"
/* 5x */ "\xD7\xD8\xD9\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xBA\xE0\xBB\xB0\x6D"
/* 6x */ "\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96"
/* 7x */ "\x97\x98\x99\xA2\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xC0\x4F\xD0\xA1\x07"
/* 8x */ "\x20\x21\x22\x23\x24\x15\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B"
/* 9x */ "\x30\x31\x1A\x33\x34\x35\x36\x08\x38\x39\x3A\x3B\x04\x14\x3E\xFF"
/* Ax */ "\x41\xAA\x4A\xB1\x9F\xB2\x6A\xB5\xBD\xB4\x9A\x8A\x5F\xCA\xAF\xBC"
/* Bx */ "\x90\x8F\xEA\xFA\xBE\xA0\xB6\xB3\x9D\xDA\x9B\x8B\xB7\xB8\xB9\xAB"
/* Cx */ "\x64\x65\x62\x66\x63\x67\x9E\x68\x74\x71\x72\x73\x78\x75\x76\x77"
/* Dx */ "\xAC\x69\xED\xEE\xEB\xEF\xEC\xBF\x80\xFD\xFE\xFB\xFC\xAD\xAE\x59"
/* Ex */ "\x44\x45\x42\x46\x43\x47\x9C\x48\x54\x51\x52\x53\x58\x55\x56\x57"
/* Fx */ "\x8C\x49\xCD\xCE\xCB\xCF\xCC\xE1\x70\xDD\xDE\xDB\xDC\x8D\x8E\xDF"
};
* From CP = 037 To CP = 819
DC X'000102039C09867F978D8E0B0C0D0E0F' 00-0F
DC X'101112139D8508871819928F1C1D1E1F' 10-1F
DC X'80818283840A171B88898A8B8C050607' 20-2F
DC X'909116939495960498999A9B14159E1A' 30-3F
DC X'20A0E2E4E0E1E3E5E7F1A22E3C282B7C' 40-4F
DC X'26E9EAEBE8EDEEEFECDF21242A293BAC' 50-5F
DC X'2D2FC2C4C0C1C3C5C7D1A62C255F3E3F' 60-6F
DC X'F8C9CACBC8CDCECFCC603A2340273D22' 70-7F
DC X'D8616263646566676869ABBBF0FDFEB1' 80-8F
DC X'B06A6B6C6D6E6F707172AABAE6B8C6A4' 90-9F
DC X'B57E737475767778797AA1BFD0DDDEAE' A0-AF
DC X'5EA3A5B7A9A7B6BCBDBE5B5DAFA8B4D7' B0-BF
DC X'7B414243444546474849ADF4F6F2F3F5' C0-CF
DC X'7D4A4B4C4D4E4F505152B9FBFCF9FAFF' D0-DF
DC X'5CF7535455565758595AB2D4D6D2D3D5' E0-EF
DC X'30313233343536373839B3DBDCD9DA9F' F0-FF
* From CP = 819 To CP = 037
DC X'00010203372D2E2F1605250B0C0D0E0F' 00-0F
DC X'101112133C3D322618193F271C1D1E1F' 10-1F
DC X'405A7F7B5B6C507D4D5D5C4E6B604B61' 20-2F
DC X'F0F1F2F3F4F5F6F7F8F97A5E4C7E6E6F' 30-3F
DC X'7CC1C2C3C4C5C6C7C8C9D1D2D3D4D5D6' 40-4F
DC X'D7D8D9E2E3E4E5E6E7E8E9BAE0BBB06D' 50-5F
DC X'79818283848586878889919293949596' 60-6F
DC X'979899A2A3A4A5A6A7A8A9C04FD0A107' 70-7F
DC X'202122232415061728292A2B2C090A1B' 80-8F
DC X'30311A333435360838393A3B04143EFF' 90-9F
DC X'41AA4AB19FB26AB5BDB49A8A5FCAAFBC' A0-AF
DC X'908FEAFABEA0B6B39DDA9B8BB7B8B9AB' B0-BF
DC X'6465626663679E687471727378757677' C0-CF
DC X'AC69EDEEEBEFECBF80FDFEFBFCADAE59' D0-DF
DC X'4445424643479C485451525358555657' E0-EF
DC X'8C49CDCECBCFCCE170DDDEDBDC8D8EDF' F0-FF
Tony H.
[Non-text portions of this message have been removed]

[Kevin Leonard]

Post by Paul
Hercules SVN(6165) has this set of tables.
Paul

Post by Paul

Post by Paul
Codepage 819/037 support has been added to the svn (6164).
Please double check the pages. There were several sites that referenced

the translation and there were minor differences between the pages.

These tables are 819 to 037 version 1, which isn't going to
fix the original problem. I have the other three (1252/037,
819/037v2 and 1252/037v2), but I don't want to commit the
changes until I can compile and test them, and right now I'm
having problems compiling. Here's the 1252/037v2 tables. I
think they're right, but please take a look and make sure they're
doing what you want. From what I've been able to find, 037
version 2 swaps LEFT SQUARE BRACKET with LATIN CAPITAL LETTER
Y WITH ACUTE (EBCDIC code points 0xBA and 0xAD), and RIGHT SQUARE
BRACKET with DIAERESIS (EBCDIC code points 0xBB and 0xBD).


/* 1252 (MS Windows Latin-1) to 037 Version 2 (EBCDIC US/Canada SHARE) */
static unsigned char
cp_1252_to_037v2[] = {
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF */
/* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x25\x0B\x0C\x0D\x0E\x0F"
/* 1x */ "\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F"
/* 2x */ "\x40\x5A\x7F\x7B\x5B\x6C\x50\x7D\x4D\x5D\x5C\x4E\x6B\x60\x4B\x61"
/* 3x */ "\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\x7A\x5E\x4C\x7E\x6E\x6F"
/* 4x */ "\x7C\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xD1\xD2\xD3\xD4\xD5\xD6"
/* 5x */ "\xD7\xD8\xD9\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xAD\xE0\xBD\xB0\x6D"
/* 6x */ "\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96"
/* 7x */ "\x97\x98\x99\xA2\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xC0\x4F\xD0\xA1\x07"
/* 8x */ "\x3F\x21\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x09\x3F\x1B"
/* 9x */ "\x30\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x3F\x14\x3F\x3F"
/* Ax */ "\x41\xAA\x4A\xB1\x9F\xB2\x6A\xB5\xBB\xB4\x9A\x8A\x5F\xCA\xAF\xBC"
/* Bx */ "\x90\x8F\xEA\xFA\xBE\xA0\xB6\xB3\x9D\xDA\x9B\x8B\xB7\xB8\xB9\xAB"
/* Cx */ "\x64\x65\x62\x66\x63\x67\x9E\x68\x74\x71\x72\x73\x78\x75\x76\x77"
/* Dx */ "\xAC\x69\xED\xEE\xEB\xEF\xEC\xBF\x80\xFD\xFE\xFB\xFC\xBA\xAE\x59"
/* Ex */ "\x44\x45\x42\x46\x43\x47\x9C\x48\x54\x51\x52\x53\x58\x55\x56\x57"
/* Fx */ "\x8C\x49\xCD\xCE\xCB\xCF\xCC\xE1\x70\xDD\xDE\xDB\xDC\x8D\x8E\xDF"
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF */
};
static unsigned char
cp_037v2_to_1252[] = {
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF */
/* 0x */ "\x00\x01\x02\x03\x07\x09\x07\x7F\x07\x8D\x07\x0B\x0C\x0D\x0E\x0F"
/* 1x */ "\x10\x11\x12\x13\x9D\x07\x08\x07\x18\x19\x07\x8F\x1C\x1D\x1E\x1F"
/* 2x */ "\x07\x81\x07\x07\x07\x0A\x17\x1B\x07\x07\x07\x07\x07\x05\x06\x07"
/* 3x */ "\x90\x07\x16\x07\x07\x07\x07\x04\x07\x07\x07\x07\x14\x15\x07\x1A"
/* 4x */ "\x20\xA0\xE2\xE4\xE0\xE1\xE3\xE5\xE7\xF1\xA2\x2E\x3C\x28\x2B\x7C"
/* 5x */ "\x26\xE9\xEA\xEB\xE8\xED\xEE\xEF\xEC\xDF\x21\x24\x2A\x29\x3B\xAC"
/* 6x */ "\x2D\x2F\xC2\xC4\xC0\xC1\xC3\xC5\xC7\xD1\xA6\x2C\x25\x5F\x3E\x3F"
/* 7x */ "\xF8\xC9\xCA\xCB\xC8\xCD\xCE\xCF\xCC\x60\x3A\x23\x40\x27\x3D\x22"
/* 8x */ "\xD8\x61\x62\x63\x64\x65\x66\x67\x68\x69\xAB\xBB\xF0\xFD\xFE\xB1"
/* 9x */ "\xB0\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\xAA\xBA\xE6\xB8\xC6\xA4"
/* Ax */ "\xB5\x7E\x73\x74\x75\x76\x77\x78\x79\x7A\xA1\xBF\xD0\x5B\xDE\xAE"
/* Bx */ "\x5E\xA3\xA5\xB7\xA9\xA7\xB6\xBC\xBD\xBE\xDD\xA8\xAF\x5D\xB4\xD7"
/* Cx */ "\x7B\x41\x42\x43\x44\x45\x46\x47\x48\x49\xAD\xF4\xF6\xF2\xF3\xF5"
/* Dx */ "\x7D\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\xB9\xFB\xFC\xF9\xFA\xFF"
/* Ex */ "\x5C\xF7\x53\x54\x55\x56\x57\x58\x59\x5A\xB2\xD4\xD6\xD2\xD3\xD5"
/* Fx */ "\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\xB3\xDB\xDC\xD9\xDA\x07"
/* x0 x1 x2 x3 x4 x5 x6 x7 x8 x9 xA xB xC xD xE xF */
};

[Kevin Leonard]

OK, support has been added for the following code page
mappings:

819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2

Please test and make sure it does what you want.

Documentation for the CODEPAGE initialization statement:

CODEPAGE mapping

specifies the codepage conversion mapping table used
for ASCII/EBCDIC translation.

default specifies traditional Hercules codepage mapping.

Other supported codepage mappings are:

Mapping Description
ASCII EBCDIC
437/037 437 PC United States 037 United States/Canada
437/500 437 PC United States 500 International
437/1047 437 PC United States 1047 Open Systems Latin 1
819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
819/273 819 ISO-8859-1 273 Austria/Germany
819/277 819 ISO-8859-1 277 Denmark/Norway
819/278 819 ISO-8859-1 278 Finland/Sweden
819/280 819 ISO-8859-1 280 Italy
819/284 819 ISO-8859-1 284 Spain
819/285 819 ISO-8859-1 285 United Kingdom
819/297 819 ISO-8859-1 297 France
819/500 819 ISO-8859-1 500 International
819/1047 819 ISO-8859-1 1047 Open Systems Latin 1
850/273 850 PC Latin 1 273 Austria/Germany
850/1047 850 PC Latin 1 1047 Open Systems Latin 1
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2
1252/1047 1252 Windows Latin 1 1047 Open Systems Latin 1

Iconv single byte codepages may also be used (e.g. UTF8/EBCDIC-CP-NL)
if the host environment supports iconv.

If no codepage is specified then the environment variable
HERCULES_CP will be inspected. The default codepage mapping
is default.

--

[Kevin Leonard]

Post by Kevin Leonard
OK, support has been added for the following code page
819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2

Sorry for another self-reply...

The additional code page mappings are in SVN 6167.
I've tested all four. All four are recognized properly,
and round-trip tests (read a card, punch a card) produce
the expected results.

Message HHC01474I during Hercules initialization will
document the selected CODEPAGE mapping.

[Robert Hodge]

Thanks so much the *really* quick response to this.  I am still pretty new to
the Hercules world, and I have never done my own builds off of SVN, only used
pre-built code.  Is there a really simple explanation somewhere of the exact
steps I need to go through to download off SVN and perform the build process? 


Thanks, Robert.




________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Thu, July 8, 2010 4:06:25 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

Post by Kevin Leonard
OK, support has been added for the following code page
819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2

Sorry for another self-reply...

The additional code page mappings are in SVN 6167.
I've tested all four. All four are recognized properly,
and round-trip tests (read a card, punch a card) produce
the expected results.

Message HHC01474I during Hercules initialization will
document the selected CODEPAGE mapping.
--
Kevin







[Non-text portions of this message have been removed]

[Kevin Leonard]

This post might be inappropriate. Click to display it.

[Robert Hodge]

Just one thing about code pages to consider when anybody has nothing better to
do ...

There is an EBCDIC code page 1140, which contains the Euro symbol.  As Wiki
describes it, CCSID 1140 is the Euro currency update of code page/CCSID 37. In
that code page, the [EBCDIC] "€" (currency) character at code point 9F is
replaced with the "€" (Euro) character.

I personally don't use Euro characters, but for those who do outside the US this
could be useful for them.  Since Windows 1252 has a Euro at X'80' but standard
8859-1 does not, there is no need to map from 8859-1 to any 1140 code page.  As
I see it, the most useful mappings would be:

1252/1140 1252 Windows Latin 1 1140 [037+Euro] United States/Canada
1252/1140v2 1252 Windows Latin 1 1140 [037+Euro] United States/Canada version 2

For round-trip purposes, the old 1252 "€" (currency) character at X'A4' has to
go somewhere else since the Euro would now occupy EBCDIC X'9F'.  In my SDI
TN3270 Plus code page 37, the 1252 currency got mapped to EBCDIC X'9F' and the
1252 Euro was stashed at EBCDIC X'20' (probably for lack of a better place to
put it).  For their code page 1140, they just swapped X'20' and X'9F' mappings. 
Perhaps the Hercules equivalents of these could do the same thing, and otherwise
the 1252/037 and 1252/037v2 mappings could just be cloned.

Again, I don't personally use Euro symbols but I suspect may other people do, so
perhaps this could be a useful addition at some point.

Thanks, Robert




________________________________
From: Robert Hodge <quatras.design-/***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Thu, July 8, 2010 7:12:03 PM
Subject: Re: [hercules-390] Re: Hercules CODEPAGE support question

 
Thanks so much the *really* quick response to this.  I am still pretty new to
the Hercules world, and I have never done my own builds off of SVN, only used
pre-built code.  Is there a really simple explanation somewhere of the exact
steps I need to go through to download off SVN and perform the build process? 

Thanks, Robert.

________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Thu, July 8, 2010 4:06:25 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

Post by Kevin Leonard
OK, support has been added for the following code page
819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2

Sorry for another self-reply...

The additional code page mappings are in SVN 6167.
I've tested all four. All four are recognized properly,
and round-trip tests (read a card, punch a card) produce
the expected results.

Message HHC01474I during Hercules initialization will
document the selected CODEPAGE mapping.
--
Kevin

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]

[Kevin Leonard]

Post by Robert Hodge
Just one thing about code pages to consider when anybody
has nothing better to do ...

Thanks for reminding me of this. I've got the Hummingbird
code page document with code page 1040 version 2 here, and
I've looked at it, and it needs to be implemented some day.
In the past week's flurry of activity, it got pushed aside
in an attempt to not add any more confusion to meeting
the immediate requirements. It's on my list, though.

[Kevin Leonard]

I've got the Hummingbird code page document with code page
1040 version 2 here

Duh. 1140 version 2. I knew what I wanted to say, but
my fingers had other ideas.

--

[Robert Hodge]

This discussion brings up good point.  On Hummingbird and SDI TN3270 Plus (and
probably others), you can set up any code page you want, even customize your own
particular flavor, and on Hercules you (Kevin) can define new tables for the
CODEPAGE command, but does MVS or any other IBM system know anything about these
"Version 2" tables like 037/2 and/or 1140/2 ?  I know that SHARE came up with
the idea, and it's a good one, but is there any way MVS know or 'can' know about
CP 1140/2, outside of doing a usermod on SVC 103 ?  For my money, 1140/2 seems
to be the ideal table for Windows users (English speaking ones, at least) to
have available.




________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Sat, July 10, 2010 10:39:32 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

I've got the Hummingbird code page document with code page
1040 version 2 here

Duh. 1140 version 2. I knew what I wanted to say, but
my fingers had other ideas.

[Gerhard Postpischil]

This discussion brings up good point. On Hummingbird and SDI TN3270 Plus (and
probably others), you can set up any code page you want, even customize your own
particular flavor, and on Hercules you (Kevin) can define new tables for the
CODEPAGE command, but does MVS or any other IBM system know anything about these
"Version 2" tables like 037/2 and/or 1140/2 ? I know that SHARE came up with
the idea, and it's a good one, but is there any way MVS know or 'can' know about
CP 1140/2, outside of doing a usermod on SVC 103 ? For my money, 1140/2 seems
to be the ideal table for Windows users (English speaking ones, at least) to
have available.

By default, JES2 will translate printer output (see module
HASPPRPU in SYS1.HASPSRC). My JES2 PARM definition has UCS=NONE
to shift the translation to Hercules printer support.

Gerhard Postpischil
Bradford, VT

[Tony Harminc]

This discussion brings up good point.  On Hummingbird and SDI TN3270 Plus (and
probably others), you can set up any code page you want, even customize your own
particular flavor, and on Hercules you (Kevin) can define new tables for the
CODEPAGE command, but does MVS or any other IBM system know anything about these
"Version 2" tables like 037/2 and/or 1140/2 ?  I know that SHARE came up with
the idea, and it's a good one, but is there any way MVS know or 'can' know about
CP 1140/2, outside of doing a usermod on SVC 103 ?  For my money, 1140/2 seems
to be the ideal table for Windows users (English speaking ones, at least) to
have available.

In a word - no. The SHARE invention of 037/2 precedes IBM's
"invention" of 1047, and was a recommendation of the SHARE ÆCS report
headed by Edwin Hart at Johns Hopkins University. This was at one of
those times when IBM was being largely non co-operative, and SHARE was
pushing for a code page with the square brackets at the "right" place
( i.e. where the TN print train had them; not where someone put them
in the 3270 CECP). SHARE wanted an 037 with the square brackets
interchanged with the codepoints in the 3270 CECP, and instead IBM
came up with 1047, which has that but buggers up the logical not sign.
I remember a SHARE meeting before this in California where a senior
IBM guy showed up for a big announcement, and it turned out to be that
IBM had decided what the universal EBCDIC code page would be. Long
pause, and I stood up and asked what it was. He said IBM was not ready
to announce that yet. I asked if he could give us a hint. and he said
that IBM liked CP 500. At that point someone (who is still heard from
on IBM-MAIN from time to time) stood up and said he was outraged at
this non-response, and demanded action. There was huge applause, and
this was at a time when SHARE was really in IBM's pocket, and it was
Just Not Done to speak to senior IBMers like that.

BTW, y'all have Mr. Hart to thanks for the fact that UNICODE and ISO
10646 are compatible today, rather than having diverged hopelessly. He
is the one who bashed heads together and convinced the commercial
(vendor) folks behind UNICODE and the government bureaucrats behind
10646 that they both faced marginalization if they didn't get their
acts together.

Tony H.

[Robert Hodge]

I have finally settled on 1252/1140 as the codepage place I can live with.
If the lords of codepages (Kevin?) could add this one in their spare time (ha,
yeah right),
I promise not to ask again (until the next).

Since there is no MVS or later that supports the V2 share variants, I have given
up trying to adopt them.

Thanks, Robert




________________________________
From: Robert Hodge <quatras.design-/***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Fri, July 9, 2010 7:28:34 PM
Subject: Re: [hercules-390] Re: Hercules CODEPAGE support question

 
Just one thing about code pages to consider when anybody has nothing better to
do ...

There is an EBCDIC code page 1140, which contains the Euro symbol.  As Wiki
describes it, CCSID 1140 is the Euro currency update of code page/CCSID 37. In
that code page, the [EBCDIC] "€" (currency) character at code point 9F is
replaced with the "€" (Euro) character.

I personally don't use Euro characters, but for those who do outside the US this

could be useful for them.  Since Windows 1252 has a Euro at X'80' but standard
8859-1 does not, there is no need to map from 8859-1 to any 1140 code page.  As
I see it, the most useful mappings would be:

1252/1140 1252 Windows Latin 1 1140 [037+Euro] United States/Canada
1252/1140v2 1252 Windows Latin 1 1140 [037+Euro] United States/Canada version 2

For round-trip purposes, the old 1252 "€" (currency) character at X'A4' has to
go somewhere else since the Euro would now occupy EBCDIC X'9F'.  In my SDI
TN3270 Plus code page 37, the 1252 currency got mapped to EBCDIC X'9F' and the
1252 Euro was stashed at EBCDIC X'20' (probably for lack of a better place to
put it).  For their code page 1140, they just swapped X'20' and X'9F' mappings. 

Perhaps the Hercules equivalents of these could do the same thing, and otherwise

the 1252/037 and 1252/037v2 mappings could just be cloned.

Again, I don't personally use Euro symbols but I suspect may other people do, so

perhaps this could be a useful addition at some point.

Thanks, Robert

________________________________
From: Robert Hodge <quatras.design-/***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Thu, July 8, 2010 7:12:03 PM
Subject: Re: [hercules-390] Re: Hercules CODEPAGE support question

 
Thanks so much the *really* quick response to this.  I am still pretty new to
the Hercules world, and I have never done my own builds off of SVN, only used
pre-built code.  Is there a really simple explanation somewhere of the exact
steps I need to go through to download off SVN and perform the build process? 

Thanks, Robert.

________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Thu, July 8, 2010 4:06:25 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

Post by Kevin Leonard
OK, support has been added for the following code page
819/037 819 ISO-8859-1 037 United States/Canada
819/037v2 819 ISO-8859-1 037 United States/Canada version 2
1252/037 1252 Windows Latin 1 037 United States/Canada
1252/037v2 1252 Windows Latin 1 037 United States/Canada version 2

Sorry for another self-reply...

The additional code page mappings are in SVN 6167.
I've tested all four. All four are recognized properly,
and round-trip tests (read a card, punch a card) produce
the expected results.

Message HHC01474I during Hercules initialization will
document the selected CODEPAGE mapping.
--
Kevin

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]







[Non-text portions of this message have been removed]

[Kevin Leonard]

Post by Robert Hodge
I have finally settled on 1252/1140 as the codepage place
I can live with. If the lords of codepages (Kevin?) could
add this one in their spare time (ha, yeah right), I
promise not to ask again (until the next).

OK, I'll work on it. Probably happen before world peace,
but no telling how much before.

[Robert Hodge]

Kevin,

Here is what I would like to see as the 1252/1140 code page.

I have generated the following code in the same style as "codepage.c".

Where I differ from codepage.c is that my table allows for a binary end-to-end
round trip without loss, rather than substituting X'07' for undefined positions.

This would be great if you could add this for me verbatim.  I do think that a
number of users have very specific needs, and would benefit from a a generalized
user-code-page loader function, if time can ever be carved out to make such a
thing.

Here is the code for the code pages in question. 
Thanks, Robert




 /* 1252 (MS Windows Latin-1) to 1140 (EBCDIC US/Canada) + Euro */
 /* table is lossless binary end-to-end translation in both directions */
static unsigned char
cp_1252_to_1140[] = {
 /*          x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF */
 /* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x25\x0B\x0C\x0D\x0E\x0F"
 /* 1x */ "\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F"
 /* 2x */ "\x40\x5A\x7F\x7B\x5B\x6C\x50\x7D\x4D\x5D\x5C\x4E\x6B\x60\x4B\x61"
 /* 3x */ "\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\x7A\x5E\x4C\x7E\x6E\x6F"
 /* 4x */ "\x7C\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xD1\xD2\xD3\xD4\xD5\xD6"
 /* 5x */ "\xD7\xD8\xD9\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xBA\xE0\xBB\xB0\x6D"
 /* 6x */ "\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96"
 /* 7x */ "\x97\x98\x99\xA2\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xC0\x4F\xD0\xA1\x07"
 /* 8x */ "\x9F\x21\x22\x23\x24\x15\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B"
 /* 9x */ "\x30\x31\x1A\x33\x34\x35\x36\x08\x38\x39\x3A\x3B\x04\x14\x3E\xFF"
 /* Ax */ "\x41\xAA\x4A\xB1\x20\xB2\x6A\xB5\xBD\xB4\x9A\x8A\x5F\xCA\xAF\xBC"
 /* Bx */ "\x90\x8F\xEA\xFA\xBE\xA0\xB6\xB3\x9D\xDA\x9B\x8B\xB7\xB8\xB9\xAB"
 /* Cx */ "\x64\x65\x62\x66\x63\x67\x9E\x68\x74\x71\x72\x73\x78\x75\x76\x77"
 /* Dx */ "\xAC\x69\xED\xEE\xEB\xEF\xEC\xBF\x80\xFD\xFE\xFB\xFC\xAD\xAE\x59"
 /* Ex */ "\x44\x45\x42\x46\x43\x47\x9C\x48\x54\x51\x52\x53\x58\x55\x56\x57"
 /* Fx */ "\x8C\x49\xCD\xCE\xCB\xCF\xCC\xE1\x70\xDD\xDE\xDB\xDC\x8D\x8E\xDF"
 };       /* x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF */

static unsigned char
cp_1140_to_1252[] = {
 /*          x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF */
 /* 0x */ "\x00\x01\x02\x03\x9C\x09\x86\x7F\x97\x8D\x8E\x0B\x0C\x0D\x0E\x0F"
 /* 1x */ "\x10\x11\x12\x13\x9D\x85\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F"
 /* 2x */ "\xA4\x81\x82\x83\x84\x0A\x17\x1B\x88\x89\x8A\x8B\x8C\x05\x06\x07"
 /* 3x */ "\x90\x91\x16\x93\x94\x95\x96\x04\x98\x99\x9A\x9B\x14\x15\x9E\x1A"
 /* 4x */ "\x20\xA0\xE2\xE4\xE0\xE1\xE3\xE5\xE7\xF1\xA2\x2E\x3C\x28\x2B\x7C"
 /* 5x */ "\x26\xE9\xEA\xEB\xE8\xED\xEE\xEF\xEC\xDF\x21\x24\x2A\x29\x3B\xAC"
 /* 6x */ "\x2D\x2F\xC2\xC4\xC0\xC1\xC3\xC5\xC7\xD1\xA6\x2C\x25\x5F\x3E\x3F"
 /* 7x */ "\xF8\xC9\xCA\xCB\xC8\xCD\xCE\xCF\xCC\x60\x3A\x23\x40\x27\x3D\x22"
 /* 8x */ "\xD8\x61\x62\x63\x64\x65\x66\x67\x68\x69\xAB\xBB\xF0\xFD\xFE\xB1"
 /* 9x */ "\xB0\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\xAA\xBA\xE6\xB8\xC6\x80"
 /* Ax */ "\xB5\x7E\x73\x74\x75\x76\x77\x78\x79\x7A\xA1\xBF\xD0\xDD\xDE\xAE"
 /* Bx */ "\x5E\xA3\xA5\xB7\xA9\xA7\xB6\xBC\xBD\xBE\x5B\x5D\xAF\xA8\xB4\xD7"
 /* Cx */ "\x7B\x41\x42\x43\x44\x45\x46\x47\x48\x49\xAD\xF4\xF6\xF2\xF3\xF5"
 /* Dx */ "\x7D\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\xB9\xFB\xFC\xF9\xFA\xFF"
 /* Ex */ "\x5C\xF7\x53\x54\x55\x56\x57\x58\x59\x5A\xB2\xD4\xD6\xD2\xD3\xD5"
 /* Fx */ "\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\xB3\xDB\xDC\xD9\xDA\x9F"
 };       /* x0  x1  x2  x3  x4  x5  x6  x7  x8  x9  xA  xB  xC  xD  xE  xF */



 



________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Fri, July 16, 2010 10:14:25 PM
Subject: [hercules-390] Re: Hercules CODEPAGE support question

 

Post by Robert Hodge
I have finally settled on 1252/1140 as the codepage place
I can live with. If the lords of codepages (Kevin?) could
add this one in their spare time (ha, yeah right), I
promise not to ask again (until the next).

OK, I'll work on it. Probably happen before world peace,
but no telling how much before.
--
Kevin







[Non-text portions of this message have been removed]

[Kevin Leonard]

Robert:

How did you generate your code page? Do you have
machine-readable source for what you built it from?

[Robert Hodge]

Hello Kevin,

1. I generated my code page by first editing an SDI TN3270 codepage
configuration text file and turning it into C code.  I then used that C code to
re-generate a copy of the original config file and did a diff on it, just to
make sure I did it right.  Next, I took the code table from that C code and
inverted it; TN3270 only really defines an ebcdic to ascii, and so I create a
map to go the other way.  In both cases, I double checked that every code point
is assigned once and only once.  After that, I just loop through the tables and
printf the code points in a format that corresponds to the way "codepage.c" does
it.

2. Yes, I have machine readable source.  I can send it to you if you like, but
I'd rather send it just to you, not to the whole group, if you have a private
email.  The code is nothing fancy, just hacked together just as you would
expect, but it's a small amount of code and you shouldn't have any issues with
it.

3. By the way, SDI's config pages fill in unassigned EBCDIC code points with
ASCII C1 codes from X'80' to X'9F' to make sure that the translation is binary
lossless in both directions.  Since the particular code points are in fact
unassigned, the choice of which specific C1 value to use is basically
arbitrary.  However, there appears to already be an agreed-upon list of
substitution values to use.  For example, here is a MS web page that has this
list:
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/EBCDIC/CP037.TXT

If you check you will find that my code page definition agrees with theirs,
except for CP 1140, ebcdic positions X'20' and X'9F' are swapped from CP 37 to
get the Euro character in the right place.

4. By the way, I was looking at the Hercules manual where it describes dynamic
load modules.  Do you suppose there is a way that users could package up their
own code page definitions into an agreed-up format and put them into a dynamic
module?  (Just a thought.) 


My first thought on this task was just to read in a text file with 512 code
points; there would be a hercules cmd like "CODEPAGE USER filename" that would
load it.  If you are interested in that approach, by the way, I'd be happy to
write some prototype code to implement it.  As an aside, I thought it would be
interesting to use an actual snippet of C code that defines the two tables (A to
E and E to A) as the format of the parameter list, and just skip over comments,
type names and variable names, only looking at the C strings.  (Funny, eh?)

Regards, Robert

 



________________________________
From: Kevin Leonard <hercules-list-+***@public.gmane.org>
To: hercules-390-***@public.gmane.org
Sent: Sun, July 18, 2010 10:42:23 PM
Subject: [hercules-390] Re: Proposed Hercules CODEPAGE support question

 
Robert:

How did you generate your code page? Do you have
machine-readable source for what you built it from?
--
Kevin







[Non-text portions of this message have been removed]

[Robert Hodge]

I have run into this message on Hercules startup,
 
HHCLC042E Port 00: Read error: Bad file descriptor
 
There are a number of web sites around that mention this message and have some
supposed solutions, but none of them seem to work.  Does anyone know of the
cause of this message?  It is not mentioned on the Hercules web page that has
the error messages, so I would assume it's a new message (running Herc 3.07).
 
Thanks,  Robert




[Non-text portions of this message have been removed]