Discussion:
[hercules-390] TN3270 emulation and code pages
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-13 19:53:16 UTC
Permalink
Does the CODEPAGE configuration option has any impact on how data entered via the keyboard is displayed on the screen when connecting to Hercules via a 3270 emulation client like C3270 or QWS3270 ?
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-13 19:58:54 UTC
Permalink
The data transmitted "on the wire" is EBCDIC; code page is a client issue.

On 04/13/2017 09:53 PM,
Post by ***@yahoo.com [hercules-390]
Does the CODEPAGE configuration option has any impact on how data
entered via the keyboard is displayed on the screen when connecting to
Hercules via a 3270 emulation client like C3270 or QWS3270 ?
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 20:19:38 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
Does the CODEPAGE configuration option has any impact on how data
entered via the keyboard is displayed on the screen when connecting to
Hercules via a 3270 emulation client like C3270 or QWS3270 ?
The data transmitted "on the wire" is EBCDIC; code page is a client issue.
I don't think that answers the question
I thought was being asked.

ASCII '[' is x'5b' and invariant.
EBCDIC '[' is x'ad' in code page 1047
EBCDIC '[' is x'ba' in code page 037 (from
memory, and doesn't matter if I'm wrong
as it is just an example).

If an EBCDIC file containing x'ad' is
sent to a printer, and the Hercules
EBCDIC code page (in the Hercules
config file) is 1047, then that character
will be dutifully translated *by
Hercules* to x'5b'.

If the EBCDIC file contains x'ba'
instead, then it will *not* be translated
to x'5b'. Again - by Hercules.

The question I believe is being asked,
is, if the Hercules config file has the
EBCDIC side set to 1047, and there
is a character x'ad' in a data file, and
c3270 is being used to view that data
file, will Hercules use its translate
table to correctly convert x'ad' to
x'5b', or is Hercules not involved at
all, and it is actually the c3270
application that is responsible for
the conversion, and may in fact fail
to translate x'ad' to x'5b', but
instead translate x'ba' to x'5b'?

My guess is that c3270 has its own
translate tables, but I'm not sure.

BFN. Paul.
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-04-13 20:05:59 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Does the CODEPAGE configuration option has any impact on
how data entered via the keyboard is displayed on the screen
when connecting to Hercules via a 3270 emulation client
like C3270 or QWS3270 ?
Yes.

The data Hercules receives from the TN3270 client is ASCII and must be translated to EBCDIC before passing it on to the guest. When the guest then decides to write something to its 3270 device, the data "received" by Hercules must then be translated from EBCDIC back into ASCII again before being transmitted to the TN3270 client. Your chosen Hercules CODEPAGE is used for both.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-13 20:12:39 UTC
Permalink
Not correct.

The data in a TN3270 session is EBCDIC, a 3270 data stream.

A TN session (typewriter) is, of course another kettle of fish.

On 04/13/2017 10:05 PM, ''Fish' (David B. Trout)'
***@gmail.com [hercules-390] wrote:
'\'Fish\' (David B. Trout)' david.b.trout@gmail.com [hercules-390]
2017-04-13 20:55:26 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
Not correct.
The data in a TN3270 session is EBCDIC, a 3270 data stream.
(Ack!) You are of course correct. My bad.
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
mail: ***@softdevlabs.com
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-13 21:24:20 UTC
Permalink
So if the 3270 data stream is EBCDIC, and I tell the 3270 emulation client that MF host code page is 424 (Hebrew), isn't it the emulator who's converting the windows ASCII values into EBCDIC way before Hercules sees the 3270 data stream ?
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 21:30:12 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
So if the 3270 data stream is EBCDIC, and I
tell the 3270 emulation client that MF host
code page is 424 (Hebrew), isn't it the emulator
who's converting the windows ASCII values
into EBCDIC way before Hercules sees the 3270 data stream ?
I believe that is totally correct.

And a google search shows this:

http://x3270.bgp.nu/Unix/c3270-man.html#Character-Sets

The -charset option or the "c3270.charset" resource controls the EBCDIC host character set used by c3270. Available sets include:

hebrew 424 iso8859-8


Does that solve the problem?

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 00:09:52 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
I tell the 3270 emulation client that MF host
code page is 424 (Hebrew)
BTW, I found this:

http://www.tachyonsoft.com/cp00424.htm

but I didn't find a machine-readable
version.

Since you know what it is you actually
need, you might want to consider
providing a 2-way translate table for
Hercules to use for future Hebrew
users sending data up via the card
reader and down via the printer.

Below are the 819/1047 tables I use.
A diff shows me that I have changed
these tables from standard Hercules
3.07, probably because the programming
characters weren't going through as
I expected.

Looking at this:

http://www.tachyonsoft.com/cp00424.htm

I can see that the '[' and ']' are being put
at positions other than x'ad' and x'bd'
where they need to be for C/Pascal
compilers, so I suggest that, as a
programmer yourself, you alter those
existing tables so that the programming
characters are preserved first and
foremost.

BFN. Paul.




/* 819 to 1047 */
static unsigned char
cp_819_to_1047[] = {
/* 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\x15\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\x5F\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\x25\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\xBB\xB4\x9A\x8A\xB0\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"
};


/* 1047 to 819 */
static unsigned char
cp_1047_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\x0A\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F"
/* 2x */ "\x80\x81\x82\x83\x84\x85\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\x5E"
/* 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 */ "\xAC\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\x9F"
};
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-14 00:37:37 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
http://www.tachyonsoft.com/cp00424.htm
but I didn't find a machine-readable version.
The official repository is at
https://www-01.ibm.com/software/globalization/cp/cp_cpgid.html This seems
to have replaced the old notion of referenceable printed or PDF IBM books,
so when they arbitrarily change the URL without notice next week, well who
knows... But they do have plain text and PDF versions.

And I see that CP 424 has been enhanced with two new characters since my -2
edition of the NLDG Volume 2 dated August 1994, so my quick eyeballing
seems to have been right.

[While there is some neat stuff on the TachyonSoft site, I'd be wary of
using it for reference, particularly since Dave Bond seems to have left the
company he started, and I don't know who would be maintaining it.]

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 01:05:29 UTC
Permalink
The official repository is at https://www-01.ibm.com/software/globalization/cp/cp_cpgid.html
Ok, cool, so I can see:

819 here:

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP00819.txt

and 1047 here:

ftp://ftp.software.ibm.com/software/globalization/gcoc/attachments/CP01047.txt


I am contemplating writing a program
that would do a 2-way conversion of
two IBM files like above.

First it should secure all the standard
ASCII characters and their EBCDIC
equivalents in 1047 from a programmer's
point of view, ie ASCII caret goes to
EBCDIC logical not etc.

Then it can troll through those 2
input files above looking for any
unassigned slots that it can start
assigning.

Then the remaining unassigned slots
can be randomly filled to provide
2-way conversion of unknown
characters.

Any algorithm suggestions? I think
the arrays can start with the standard
ASCII characters already filled.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 01:50:04 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
First it should secure all the standard
ASCII characters and their EBCDIC
equivalents in 1047 from a programmer's
point of view, ie ASCII caret goes to
EBCDIC logical not etc.
And the ASCII characters less than
x'20' would presumably also be
immutable, including Unix LF
being translated to EBCDIC NL
(not LF).

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 00:40:51 UTC
Permalink
BTW, what code page translation is
used by the hetget "-a" option? It seems
hetget doesn't need/use the Hercules
config file where the code pages are
normally defined.

Thanks. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 05:34:09 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Since you know what it is you actually
need, you might want to consider
providing a 2-way translate table for
Hercules to use for future Hebrew
users sending data up via the card
reader and down via the printer.
Ok, I decided to write a program to
generate translate tables suitable
for use in Hercules etc.

Here is the C code and Windows
executable:

https://groups.yahoo.com/neo/groups/hercules-390/files/makecodp-stage1.zip

Here is how to run it:

makecodp cp01255.txt cp00424.txt

and the output for the above is below.

Let me know if you have any issues.
Don't feel obliged to run it. You didn't
ask for it and it doesn't directly
resolve your reported problem, but
it may come in useful one day.

BFN. Paul.


makecodp cp01255.txt cp00424.txt
proposing a translation from 5B to BA
ASCII 5B is immutable
proposing a translation from 5D to BB
ASCII 5D is immutable
proposing a translation from 5E to B0
ASCII 5E is immutable
proposing a translation from 80 to 9C
proposing a translation from 95 to B3
proposing a translation from A0 to 74
proposing a translation from A4 to 9E
proposing a translation from A8 to BD
EBCDIC BD is immutable
proposing a translation from AA to BF
proposing a translation from AC to 5F
EBCDIC 5F is immutable
proposing a translation from BA to E1
proposing a translation from E0 to 41
proposing a translation from E1 to 42
proposing a translation from E2 to 43
proposing a translation from E3 to 44
proposing a translation from E5 to 46
proposing a translation from E6 to 47
proposing a translation from E8 to 49
proposing a translation from EC to 54
proposing a translation from F0 to 58
proposing a translation from F1 to 59
proposing a translation from F2 to 62
proposing a translation from F3 to 63
proposing a translation from F4 to 64
proposing a translation from F5 to 65
proposing a translation from F6 to 66
proposing a translation from F7 to 67
proposing a translation from F8 to 68
proposing a translation from F9 to 69
proposing a translation from FA to 71
proposing a translation from FD to FD
proposing a translation from FE to FE
ASCII to EBCDIC
\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x15\x0B\x0C\x0D\x0E\x0F
\x10\x11\x12\x13\x3C\x3D\x32\x26\x18\x19\x3F\x27\x1C\x1D\x1E\x1F
\x40\x5A\x7F\x7B\x5B\x6C\x50\x7D\x4D\x5D\x5C\x4E\x6B\x60\x4B\x61
\xF0\xF1\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\x7A\x5E\x4C\x7E\x6E\x6F
\x7C\xC1\xC2\xC3\xC4\xC5\xC6\xC7\xC8\xC9\xD1\xD2\xD3\xD4\xD5\xD6
\xD7\xD8\xD9\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xE9\xAD\xE0\xBD\x5F\x6D
\x79\x81\x82\x83\x84\x85\x86\x87\x88\x89\x91\x92\x93\x94\x95\x96
\x97\x98\x99\xA2\xA3\xA4\xA5\xA6\xA7\xA8\xA9\xC0\x4F\xD0\xA1\x07
\x9C\x21\x22\x23\x24\x25\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B
\x30\x31\x1A\x33\x34\xB3\x36\x08\x38\x39\x3A\x3B\x04\x14\x3E\xFF
\x74\xAA\x4A\xB1\x9E\xB2\x6A\xB5\xBB\xB4\xBF\x8A\xB0\xCA\xAF\xBC
\x90\x8F\xEA\xFA\xBE\xA0\xB6\x35\x9D\xDA\xE1\x8B\xB7\xB8\xB9\xAB
\xCB\xCF\xCD\xCC\xCE\x9B\x9F\x70\x20\xDE\x72\x73\x78\x75\x76\x77
\xAC\xDD\xED\xEE\xEB\xEF\xEC\x9A\x80\x8D\x8E\xFB\xFC\xBA\xAE\x8C
\x41\x42\x43\x44\x45\x46\x47\x48\x49\x51\x52\x53\x54\x55\x56\x57
\x58\x59\x62\x63\x64\x65\x66\x67\x68\x69\x71\xDB\xDC\xFD\xFE\xDF
EBCDIC to ASCII
\x00\x01\x02\x03\x9C\x09\x86\x7F\x97\x8D\x8E\x0B\x0C\x0D\x0E\x0F
\x10\x11\x12\x13\x9D\x0A\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F
\xC8\x81\x82\x83\x84\x85\x17\x1B\x88\x89\x8A\x8B\x8C\x05\x06\x07
\x90\x91\x16\x93\x94\xB7\x96\x04\x98\x99\x9A\x9B\x14\x15\x9E\x1A
\x20\xE0\xE1\xE2\xE3\xE4\xE5\xE6\xE7\xE8\xA2\x2E\x3C\x28\x2B\x7C
\x26\xE9\xEA\xEB\xEC\xED\xEE\xEF\xF0\xF1\x21\x24\x2A\x29\x3B\x5E
\x2D\x2F\xF2\xF3\xF4\xF5\xF6\xF7\xF8\xF9\xA6\x2C\x25\x5F\x3E\x3F
\xC7\xFA\xCA\xCB\xA0\xCD\xCE\xCF\xCC\x60\x3A\x23\x40\x27\x3D\x22
\xD8\x61\x62\x63\x64\x65\x66\x67\x68\x69\xAB\xBB\xDF\xD9\xDA\xB1
\xB0\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\xD7\xC5\x80\xB8\xA4\xC6
\xB5\x7E\x73\x74\x75\x76\x77\x78\x79\x7A\xA1\xBF\xD0\x5B\xDE\xAE
\xAC\xA3\xA5\x95\xA9\xA7\xB6\xBC\xBD\xBE\xDD\xA8\xAF\x5D\xB4\xAA
\x7B\x41\x42\x43\x44\x45\x46\x47\x48\x49\xAD\xC0\xC3\xC2\xC4\xC1
\x7D\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\xB9\xFB\xFC\xD1\xC9\xFF
\x5C\xBA\x53\x54\x55\x56\x57\x58\x59\x5A\xB2\xD4\xD6\xD2\xD3\xD5
\x30\x31\x32\x33\x34\x35\x36\x37\x38\x39\xB3\xDB\xDC\xFD\xFE\x9F
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 06:28:54 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Here is the C code
I've made a tricky section a bit clearer,
as per below. But not re-released.

BFN. Paul.


/* let's say ...
current is:
A 1 to 4
E 4 to 1
E 2 to 7
A 7 to 2
proposed is:
A 1 to 2
E 2 to 1
that mandates this change:
A 7 to 4
E 4 to 7
so that we can do the above proposal
*/

/* save relevant old mappings */
olde = atoe[hexa]; /* olde e.g. is 4 */
olda = etoa[hexe]; /* olda e.g. is 7 */

/* now do the proposal */
atoe[hexa] = hexe; /* e.g. position 1 is set to 2 */
etoa[hexe] = hexa; /* e.g. position 2 is set to 1 */

/* now restore the 1:1 mapping */
atoe[olda] = olde; /* e.g. position 7 is set to 4 */
etoa[olde] = olda; /* e.g. position 4 is set to 7 */
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 07:40:56 UTC
Permalink
I did the following experiment:

Typed the Hebrew alpha-bet in sequence into a source file in TSO editor:


WTO 'HEBREW TEXT: 'תשךק׊ץ׀ףעסנןמםלכךיטחזוהדגבא'


On the TSO edit screen it is displayed like this:


WTO 'HEBREW TEXT: àáóãÀåÊçÚéêëìíîïðñòóÎõö÷Þùú'



Switched to HEX display:


000009 WTO 'HEBREW TEXT: àáóãÀåÊçÚéêëìíîïðñòóÎõö÷Þùú'


446444444 555555555 666666667
123456789 123456789 234567891


Now here is the 424 code page:


https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference15.htm https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference15.htm



So mostly, the input I have typed is represented correctly in EBCDIC except:


The third char "ג" should be X'43' but instead it was translated to X'63'. all else is good.


Of course the char values on the screen are all incorrect and I don't know what component is translating them
wrong.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-14 07:53:30 UTC
Permalink
Anything happening on your screen is done by the terminal emulator. So
if the Hebrew comes out like code page 819, your emulator is lacking
either in functionality or configuration.

Note that uppercase does show as Latin, as it should (but that would
apply to just about any code page).

Have you tried Telnet (TN3270) directly into the MVS system? That would
cut out the middleman (Hercules).

On 04/14/2017 09:40 AM,
Post by ***@yahoo.com [hercules-390]
WTO 'HEBREW TEXT: 'תשךק׊ץ׀ףעסנןמםלכךיטחזוהדגבא'
WTO 'HEBREW TEXT: àáóãÀåÊçÚéêëìíîïðñòóÎõö÷Þùú'
000009 WTO 'HEBREW TEXT: àáóãÀåÊçÚéêëìíîïðñòóÎõö÷Þùú'
446444444
555555555 666666667
123456789
123456789 234567891
https://www.ibm.com/support/knowledgecenter/en/SSEQ5Y_5.9.0/com.ibm.pcomm.doc/reference/html/hcp_reference15.htm
The third char "ג" should be X'43' but instead it was translated to
X'63'. all else is good.
Of course the char values on the screen are all incorrect and I don't
know what component is translating them
wrong.
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 08:28:24 UTC
Permalink
Do you mean trying to Telnet directly into the internal IP of the MVS system ?

As far as the emulator setup, I tried with QWS3270 and WC3270, both support MF codepage 424, and with either one when I type the 3rd letter in the hebrew alpha-bet, the EBCDIC value that ends up in the MF source file is X'63' and not X'43' as it should be.


However, if I create an ASCII file on the PC with hebrew letters, and upload the file via the emulator file transfer tool into a MF file, the third letter of the alphabet comes out as X'43' as it should.


So only when typing directly into the emulator the third character is translated wrong.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 08:35:28 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
I tried with QWS3270 and WC3270
Did QWS3270 display all the Hebrew
characters as junk like wc3270 did?

BFN. Paul.
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 08:45:42 UTC
Permalink
Yes, all hebrew characters show up wrong on the screen either when typed or when uploaded from an ASCII pc file.
When uploaded from PC the EBCDIC representation is correct.
When typed in from the keyboard into the emulator session, all but the third character are correct in the EBCDIC representation.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 08:51:13 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Yes, all hebrew characters show up wrong
on the screen either when typed or when
uploaded from an ASCII pc file.
In *both* QWS3270 and wc3270, right?

Maybe you should try some other emulators.
There are several emulators that people
swear by.

And do any of the emulators allow you to
define your own translate table?

BFN. Paul.
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 08:57:57 UTC
Permalink
I will look for another emulator to see if it makes any difference. Thanks.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 08:30:39 UTC
Permalink
Are you using the ISPF editor or
something else?

Are you using z/OS?
Post by ***@yahoo.com [hercules-390]
The third char "ג" should be X'43' but instead
it was translated to X'63'. all else is good.
Sounds like c3270 has an error in the
translate tables.

I took a look at the c3270 source code,
and there is a file Unicode.c (see below),
but I haven't deciphered it.
Post by ***@yahoo.com [hercules-390]
Of course the char values on the screen
are all incorrect and I don't know what
component is translating them wrong.
Are you invoking c3270 with the
-charset hebrew
option?

You might be the first person to have
tried that, and it seems the reverse
direction, ie going from MVS to PC,
is quite broken and you may need to
report this to the author.

Would you be content with sending
the code up via the card reader,
letting Hercules translate it instead
of c3270?

Are you willing to recompile Hercules?

Are you willing to use an older version
of Hercules, ie a slightly modified 3.07?

BFN. Paul.



C:\scratch\heb\suite3270-3.5\Common>grep cp424 unicode.c
{ "cp424", { 0x5d0, 0x05d1, 0x05d2, 0x05d3, 0x05d4, 0x05d5, 0x05d6, 0x05d7, 0x05d8, 0x00a2, 0x002e, 0x003c, 0x0028, 0x002b, 0x007c, 0x0026, 0x05d9, 0x05da, 0x05db, 0x05dc, 0x05dd, 0x05de, 0x05df, 0x05e0, 0x05e1, 0x0021, 0x0024, 0x002a, 0x0029, 0x003b, 0x00ac, 0x002d, 0x002f, 0x05e2, 0x05e3, 0x05e4, 0x05e5, 0x05e6, 0x05e7, 0x05e8, 0x05e9, 0x00a6, 0x002c, 0x0025, 0x005f, 0x003e, 0x003f, 0x0000, 0x05ea, 0x0000, 0x0000, 0x00a0, 0x0000, 0x0000, 0x0000, 0x21d4, 0x0060, 0x003a, 0x0023, 0x0040, 0x0027, 0x003d, 0x0022, 0x0000, 0x0061, 0x0062, 0x0063, 0x0064, 0x0065, 0x0066, 0x0067, 0x0068, 0x0069, 0x00ab, 0x00bb, 0x0000, 0x0000, 0x0000, 0x0000, 0x00b0, 0x006a, 0x006b, 0x006c, 0x006d, 0x006e, 0x006f, 0x0070, 0x0071, 0x0072, 0x0000, 0x0000, 0x0000, 0x00b8, 0x0000, 0x00a4, 0x00b5, 0x007e, 0x0073, 0x0074, 0x0075, 0x0076, 0x0077, 0x0078, 0x0079, 0x007a, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x00ae, 0x005e, 0x00a3, 0x00a5, 0x00b7, 0x00a9, 0x00a7, 0x00b6, 0x00bc, 0x00bd, 0x00be, 0x005b, 0x005d, 0x00af, 0x00a8, 0x00b4, 0x00d7, 0x007b, 0x0041, 0x0042, 0x0043, 0x0044, 0x0045, 0x0046, 0x0047, 0x0048, 0x0049, 0x00ad, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x007d, 0x004a, 0x004b, 0x004c, 0x004d, 0x004e, 0x004f, 0x0050, 0x0051, 0x0052, 0x00b9, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x005c, 0x00f7, 0x0053, 0x0054, 0x0055, 0x0056, 0x0057, 0x0058, 0x0059, 0x005a, 0x00b2, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0030, 0x0031, 0x0032, 0x0033, 0x0034, 0x0035, 0x0036, 0x0037, 0x0038, 0x0039, 0x00b3, 0x0000, 0x0000, 0x0000, 0x0000 }, "424", "0x054501a8", false },
{ "hebrew", "cp424" },
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 09:17:56 UTC
Permalink
Yes, I am invoking WC3270 with Hebrew CP424 option. It behaves exactly the same as QWS3270 when typing in Hebrew letters. Both emulators do not display any hebrew letters on the screen even when the internal EBCDIC hex values are correct.


What is the procedure to send a file up via the card reader from the PC ?
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 09:27:23 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
What is the procedure to send a file up
via the card reader from the PC ?
Start with some simple JCL like this:

C:\mvs380_work\iebgener>type iebgen.jcl
//MYJOB JOB CLASS=C,REGION=0K
//*
//S1 EXEC PGM=IEBGENER
//SYSUT1 DD *
LINE 1
LINE TWO
main()
{
char buf[50];
}
/*
//SYSUT2 DD SYSOUT=*
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//

C:\mvs380_work\iebgener>


And then on the Hercules console,
do something like:

devinit 00c c:\example.jcl eof

I normally have a jcl directory
under c:\mvs380 so I instead
use:

devinit 00c jcl/hercauto.jcl eof

ie a relative path.

After that simple JCL is working,
try changing SYSUT2 to some
dataset instead of SYSOUT.

Another option I would consider
if it was me, would be to modify
miniunz to have an extra translate
table for Hebrew, and do all my
work on the PC, zip it up, then
send it up via tape, as binary, and
then unzip all my code and do a
compile or whatever.

BFN. Paul.
Bernd Oppolzer berndoppolzer@yahoo.com [hercules-390]
2017-04-14 09:38:35 UTC
Permalink
BTW:

when sending a file from the PC to Hercules MVS this way,
which contains JCL, I have the problem that the file on Hercules MVS
will be empty because of the JCL in the input file ...
(maybe other errors ... the IEBGENER JCL will be garbage)

only solution up until now:

shift the JCL in the PC file one position to the right
then transfer using IEBGENER
then shift it back on Hercules

Same problem with program sources which contained /* ... */
style comments in column 1; I had to change all those comments
to (* ... *) - both are possible in my version of Stanford Pascal.

Any ideas or suggestions?

Kind regards

Bernd
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com [hercules-390]
What is the procedure to send a file up
via the card reader from the PC ?
C:\mvs380_work\iebgener>type iebgen.jcl
//MYJOB JOB CLASS=C,REGION=0K
//*
//S1 EXEC PGM=IEBGENER
//SYSUT1 DD *
LINE 1
LINE TWO
main()
{
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 10:00:15 UTC
Permalink
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
when sending a file from the PC to Hercules MVS this way,
which contains JCL, I have the problem that the file on Hercules MVS
will be empty because of the JCL in the input file ...
(maybe other errors ... the IEBGENER JCL will be garbage)
Same problem with program sources which contained /* ... */
style comments in column 1; I had to change all those comments
to (* ... *) - both are possible in my version of Stanford Pascal.
Any ideas or suggestions?
Change from this:

//SYSUT1 DD *
LINE 1
LINE TWO
/*

to

//SYSUT1 DD DLM='$$'
LINE 1
LINE TWO
$$

Of course, this whole think is donkey
business in the first place.

What I really recommend is that you
send a zip file up via the tape drive.

Or use this wrapper script:

C:\mvs380>pc2mf
Usage example: pc2mf pdpgoal.txt PDPCLIB.DOC(PDPGOAL) [ascii]

C:\mvs380>

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 10:19:57 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
//SYSUT1 DD DLM='$$'
Oops. Typo. Should be:

//SYSUT1 DD DATA,DLM='$$'

BFN. Paul.
Bernd Oppolzer berndoppolzer@yahoo.com [hercules-390]
2017-04-14 13:13:09 UTC
Permalink
Thank you very much, it works !


COPYMVS.CMD:

@echo off
if "%1" == "" goto :noparm
if "%2" == "" goto :noparm
if not exist %1 goto :fehler
if exist copymvs.tmp del copymvs.tmp
if exist copymvs2.tmp del copymvs2.tmp
rexx copymvs.rex %1 %2
if not exist copymvs.tmp pause
copy copymvs.tmp+%1+copymvs2.tmp copymvs.tmp
nc -w1 127.0.0.1 3505 <copymvs.tmp
goto :fertig
:fehler
echo Datei %1 nicht vorhanden
goto :fertig
:noparm
rexx copymvs.rex
goto :fertig
:fertig


COPYMVS.REX:

/* REXX */

/************************************************/
/* */
/* Kopieren File nach MVS Dataset */
/* mit IEBGENER-Job */
/* */
/************************************************/

arg pcfile mvsfile

if pcfile = "" | mvsfile = "" then do
say "usage: copymvs <pcfile> <mvsfile>"
exit
end

x = pos(".",pcfile)
if x = 0 then do
membname = pcfile
end
else do
membname = left(pcfile, x - 1)
end

zeile1 = "//PASCALN1 JOB (ACCNT),'IEBGENER',CLASS=A,MSGCLASS=X,"
zeile2 = "// USER=PASCALN,PASSWORD=PAS"
zeile3 = "//*"
zeile4 = "//* INPUT DATA INTO A MEMBER WITH IEBGENER"
zeile5 = "//*"
zeile6 = "//INPUT EXEC PGM=IEBGENER"
zeile7 = "//SYSPRINT DD DUMMY"
zeile8 = "//SYSIN DD *"
zeile9 = "//SYSUT2 DD DISP=SHR,DSN=PASCALN."mvsfile"("membname")"
zeilea = "//SYSUT1 DD DATA,DLM='$$'"

zeileb = "$$"

fname = "copymvs.tmp"
x = lineout(fname, zeile1)
x = lineout(fname, zeile2)
x = lineout(fname, zeile3)
x = lineout(fname, zeile4)
x = lineout(fname, zeile5)
x = lineout(fname, zeile6)
x = lineout(fname, zeile7)
x = lineout(fname, zeile8)
x = lineout(fname, zeile9)
x = lineout(fname, zeilea)

fname2 = "copymvs2.tmp"
x = lineout(fname2, zeileb)

exit
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
//SYSUT1 DD DLM='$$'
//SYSUT1 DD DATA,DLM='$$'
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 21:57:24 UTC
Permalink
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
Thank you very much, it works !
say "usage: copymvs <pcfile> <mvsfile>"
That looks like the start of something
very beautiful.

You have encapsulated the copy process
with a script, such that the internals can
change without the user being affected.

Note that although I have my own scripts,
they all involve MVS being shut down,
and I'm the only person on the planet
that operates MVS with a fresh IPL
every time. So you have an opportunity
to corner the market here, if you can
get it all working.

One thing that you don't have in your
script is a "binary" option. To implement
binary transfer (e.g. a zip file) using
your existing JCL, you can encapsulate
your binary input file with mvsendec,
which you should already have, but
if not, it is here:

http://pdos.cvs.sourceforge.net/viewvc/pdos/pdos/pdpclib/mvsendec.c?view=markup

Using the encb and decb options.

Sending a huge file up via the card
reader has an issue that you might
fill up the spool. You might be able
to avoid that problem by using a
second card reader for your data
file, I don't know. Personally I think
the correct solution to this problem
is to use tape instead of cards. On
tape you can have a proper
RECFM=U file.

You define a tape with a RECFM=U
binary file on it like this:

C:\mvs380\tapes>type pctomf_bin.tdf
@TDF
hercauto.dat FIXED RECSIZE 6144
TM
TM
EOT

C:\mvs380\tapes>


I think the above is quite confusing. It
says "FIXED" but actually it supports
RECFM=U with a short last block.
Or RECFM=FB with a short last block
too.

But in order to use tapes, you need
some way of doing a devinit on the
tape drive. In my case the startup
scripts automatically do the required
devinits before starting the card
reader. I don't actually know how to
do it automatically on a running
system. I vaguely recall that there
is an MVS utility that allows you to
execute Hercules commands.

Note that in my case I don't care
about time taken for repeated IPLs
since I can IPL and run an
IEFBR14 in about 4 seconds.

Even if you feel the need to keep
your system up permanently, you
can still encapsulate all of your
work into a batch file. E.g. when
I am building any utility, e.g.
brexx, sed, minizip etc etc, all I
do is type in "allmvs" at the
Windows prompt. Here's an
example:

C:\devel\brexx\mvs>type allmvs.bat
del alljcl.jcl
del output.txt
call zipmvs
call subjobs

C:\devel\brexx\mvs>


Depending on what you are doing, you
too could zip up all your Pascal
development and send it to the
mainframe and sit back and relax
waiting for a result.

Note that building BREXX or whatever
takes about 5 minutes, as I am too
lazy to even switch off optimization
during development, or tailor the
JCL to only rebuild the module of
interest. Some people do nothing and
just listen to music to relax. I sometimes
listen to music and relax while a build
is going on. Or eat dinner if I am
rebuilding GCC which takes about
an hour rather than 5 minutes.

I think you should aim to replace my
runmvs command:

C:\>runmvs
Usage runmvs jcl.file print.file [aux_input.file|none] [aux_output.file|none] [ascii|binary|rdwund|rdwvar|vart] [ascii|binary] [awstap.file|none]
e.g. runmvs compile.jcl output.txt world.c world.s ascii ascii
or runmvs buildgcc.jcl output.txt source.zip xmit.dat
default is for files (if provided) to be binary

C:\>

with an identical command that instead
communicates with a running system.

Preferably with comments in English
so that others can maintain it too!

Like I said - there's a market out there
to corner. :-)

Technically even I may stop continually
re-ipling my system if there was a
replacement runmvs with no downside.
Although I really do like the consistency
of a fresh IPL for every run, so maybe
not. :-) But like I said - most people will
be using TSO and not want to exit their
TSO session. But if they're doing that,
then there's no point in runmvs anyway,
as their data is on the mainframe, not
the PC. So who knows. I guess it is
you personally who needs to define
what you are trying to do and thus
what scripts would be useful.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 22:11:44 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
script is a "binary" option. To implement
binary transfer (e.g. a zip file) using
your existing JCL, you can encapsulate
your binary input file with mvsendec,
You might be able to use uuencode
instead of mvsendec. mvsendec is
just a very simple replacement for
uuencode in that it only uses
uppercase hex. If you have decent
translate tables the full range of
uuencode characters should be
available.

Note that not everyone has decent
translate tables, e.g. some people
run with code page 037 instead of
1047. So maybe stick with
mvsendec. :-)

BFN. Paul.
Bernd Oppolzer berndoppolzer@yahoo.com [hercules-390]
2017-04-15 07:48:24 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
say "usage: copymvs <pcfile> <mvsfile>"
One thing that you don't have in your
script is a "binary" option. To implement
binary transfer (e.g. a zip file) using
your existing JCL, you can encapsulate
your binary input file with mvsendec,
Now that you're talking about that:

I used Pascal programs ENCOD / DECOD, which translate
binary content to hex (one byte to two bytes) and the line ends
to # - and vice versa, to transfer binary data (object modules)
between MUSIC/SP and VM/370. And because the compiler
has been ported to Windows recently, ENCOD / DECOD will
run on Windows (and Linux, and OS/2), too.

So this will be another way of transferring the content using
IEBGENER from PC to Hercules / MVS - but normally, transferring
binary content doesn't make much sense due to endianness and
codepage differences. Only for archiving purposes ...

Kind regards

Bernd
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 22:23:21 UTC
Permalink
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
but normally, transferring
binary content doesn't make much sense due to endianness and
codepage differences. Only for archiving purposes ...
Well, that "archiving purposes" is pretty
important, isn't it? If your MVS procedure
creates some load modules, you will
probably want to ship those load modules
using XMIT, so you need to create a
binary XMIT. You also need to be able
to send that XMIT up to the mainframe
on some other site. So the need for
binary transfer exists.

Also, if you have 100 Pascal source files,
and some of those files contain lines that
are more than 80 characters long, then
it exceeds the ability of the card reader
to send them up as ASCII being
converted into EBCDIC. I'm not familiar
with Pascal, so let's stick to C. C has
both source files and headers. The
way I send them up to the mainframe
is to zip up the C files into a CLIB.zip
and zip up the H files into an HLIB.zip,
then zip both of those up into an
ALL.zip, then transfer ALL.zip up to
the mainframe in binary mode, unzip
ALL.zip in binary mode, and then
unzip CLIB and HLIB in text mode,
letting miniunz take care of the code
page translation. And of course miniunz
knows the format of the zip file, including
endianness.

What's the alternative?

And note that I send ALL.zip up via
the tape drive rather than trying to
send a large file up via the card
reader. You may prefer to send
files up via ftp. Maybe that is the
way you can avoid having to
issue devinits on a running system.
I didn't think of that until just now.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-15 22:51:38 UTC
Permalink
"If your MVS procedure
creates some load modules, you will
probably want to ship those load modules
using XMIT, so you need to create a
binary XMIT. You also need to be able
to send that XMIT up to the mainframe
on some other site. So the need for
binary transfer exists."

Just curious ... why wouldn't you ship object and link on the target
system?

What if the target system has different PTF levels than the generating
system?

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
but normally, transferring
binary content doesn't make much sense due to endianness and
codepage differences. Only for archiving purposes ...
Well, that "archiving purposes" is pretty
important, isn't it? If your MVS procedure
creates some load modules, you will
probably want to ship those load modules
using XMIT, so you need to create a
binary XMIT. You also need to be able
to send that XMIT up to the mainframe
on some other site. So the need for
binary transfer exists.
Also, if you have 100 Pascal source files,
and some of those files contain lines that
are more than 80 characters long, then
it exceeds the ability of the card reader
to send them up as ASCII being
converted into EBCDIC. I'm not familiar
with Pascal, so let's stick to C. C has
both source files and headers. The
way I send them up to the mainframe
is to zip up the C files into a CLIB.zip
and zip up the H files into an HLIB.zip,
then zip both of those up into an
ALL.zip, then transfer ALL.zip up to
the mainframe in binary mode, unzip
ALL.zip in binary mode, and then
unzip CLIB and HLIB in text mode,
letting miniunz take care of the code
page translation. And of course miniunz
knows the format of the zip file, including
endianness.
What's the alternative?
And note that I send ALL.zip up via
the tape drive rather than trying to
send a large file up via the card
reader. You may prefer to send
files up via ftp. Maybe that is the
way you can avoid having to
issue devinits on a running system.
I didn't think of that until just now.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 23:01:51 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
If your MVS procedure
creates some load modules, you will
probably want to ship those load modules
using XMIT, so you need to create a
binary XMIT. You also need to be able
to send that XMIT up to the mainframe
on some other site. So the need for
binary transfer exists.
Just curious ... why wouldn't you ship object
and link on the target system?
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode, so the need for binary
transfers still exists. (note that my
comment was that Bernd's script
doesn't support binary yet).

And if you have multiple load
modules, and ship source code
as well, an XMIT would normally
be the easiest to handle. Maybe
a DFDSS dump would be a bit
better.
Post by Joe Monk ***@gmail.com [hercules-390]
What if the target system has different
PTF levels than the generating system?
I don't really understand this. When
I produce a GCC or BREXX or
SED or any other load module,
designed to run on anything from
MVS 3.8j to z/OS, I never ever
consider what PTFs might be
installed in a particular destination.
I only concern myself that I am
coding to the published specifications
such that if anything doesn't work,
the customer needs to report the
problem to IBM so that they can
fix their system.

So far I've not had feedback from a
single person saying that the load
modules I produce didn't work on
their system and they needed to
get some PTFs from IBM to fix
their broken system.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-15 23:15:02 UTC
Permalink
"Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode"

Why? Object code (linker input) is 80 byte card images ... pure text.

"I don't really understand this. When
I produce a GCC or BREXX or
SED or any other load module,
designed to run on anything from
MVS 3.8j to z/OS, I never ever
consider what PTFs might be
installed in a particular destination."

Well, for instance, if you produce a load module using a VSAM routine to
which a PTF has been applied on your system, but is not applied on the
target system, you might get differing results, or an abend.

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
If your MVS procedure
creates some load modules, you will
probably want to ship those load modules
using XMIT, so you need to create a
binary XMIT. You also need to be able
to send that XMIT up to the mainframe
on some other site. So the need for
binary transfer exists.
Just curious ... why wouldn't you ship object
and link on the target system?
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode, so the need for binary
transfers still exists. (note that my
comment was that Bernd's script
doesn't support binary yet).
And if you have multiple load
modules, and ship source code
as well, an XMIT would normally
be the easiest to handle. Maybe
a DFDSS dump would be a bit
better.
What if the target system has different
PTF levels than the generating system?
I don't really understand this. When
I produce a GCC or BREXX or
SED or any other load module,
designed to run on anything from
MVS 3.8j to z/OS, I never ever
consider what PTFs might be
installed in a particular destination.
I only concern myself that I am
coding to the published specifications
such that if anything doesn't work,
the customer needs to report the
problem to IBM so that they can
fix their system.
So far I've not had feedback from a
single person saying that the load
modules I produce didn't work on
their system and they needed to
get some PTFs from IBM to fix
their broken system.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 23:26:54 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
It is in no way pure text. The object
code contains the result of the
assembler translating things like
MVC into a hex code. It needs to
remain in that form, not translated
into ASCII as if it was text.
Post by Joe Monk ***@gmail.com [hercules-390]
Well, for instance, if you produce a
load module using a VSAM routine
to which a PTF has been applied on
your system, but is not applied on
the target system, you might get
differing results, or an abend.
A VSAM routine that is linked into
my load module, or one that is
fetched from the link list at runtime?

If the former, then any bugs in it
will probably be visible on any
system and it requires me to
regenerate the load module.

If the latter, and the VSAM routine
is not actually my code, then it is
the user's responsibility to provide
a correctly working VSAM routine,
not mine.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 00:18:52 UTC
Permalink
"If the latter, and the VSAM routine
is not actually my code, then it is
the user's responsibility to provide
a correctly working VSAM routine,
not mine."

Normally when a software company distributes software, there are
pre-requistes that must be complied with, which are supplied as a part of
the documentation.

For instance, this software runs on Windoze 7 Pro, 64-bit, and requires
SP1, as well as KBXXXXXX

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
It is in no way pure text. The object
code contains the result of the
assembler translating things like
MVC into a hex code. It needs to
remain in that form, not translated
into ASCII as if it was text.
Post by Joe Monk ***@gmail.com [hercules-390]
Well, for instance, if you produce a
load module using a VSAM routine
to which a PTF has been applied on
your system, but is not applied on
the target system, you might get
differing results, or an abend.
A VSAM routine that is linked into
my load module, or one that is
fetched from the link list at runtime?
If the former, then any bugs in it
will probably be visible on any
system and it requires me to
regenerate the load module.
If the latter, and the VSAM routine
is not actually my code, then it is
the user's responsibility to provide
a correctly working VSAM routine,
not mine.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 00:29:06 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
If the latter, and the VSAM routine
is not actually my code, then it is
the user's responsibility to provide
a correctly working VSAM routine,
not mine.
Normally when a software company
distributes software, there are pre-requistes
that must be complied with, which are
supplied as a part of the documentation.
For instance, this software runs on Windoze
7 Pro, 64-bit, and requires SP1, as well
as KBXXXXXX
Ok. I guess that is people who are using
the latest and greatest versions of
Windows or z/OS.

When I code, I code for the lowest common
denominator as far as I can.

So when I write 32-bit PC code, I code to
the 80386, not the 80486.

My MVS software runs even on MVS 3.8j.
Possibly even older. As such, it is expected
to work on any later version of MVS, up
to the latest z/OS.

There is one semi-exception. If you try
to run my code on MVS/XA up to early
MVS/ESA, you will need to change the
attributes of the program from AM31
to AM24, as AM31 does not work on
those old versions.

OS/390 and above will handle pure
31-bit execution.

Also my applications are quite basic.
Using very old access methods. If
I was writing a utility to scan the
latest RACF tables, the situation
would probably be different and I
would need to specify exactly
which version of RACF my code
will work with, and it's likely to be
a fairly recent release, not something
from the 1980s. :-)

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 00:23:57 UTC
Permalink
"It is in no way pure text."

Has to be. Thats why there are TXT records in the object file! Even
IBM refers to it as the "TEXT" of the program...


- the text of the program - the instructions and data, as output by the
language translator (TXT)


https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieav100/iea3v1_List_the_contents_of_an_object_module.htm

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
It is in no way pure text. The object
code contains the result of the
assembler translating things like
MVC into a hex code. It needs to
remain in that form, not translated
into ASCII as if it was text.
Post by Joe Monk ***@gmail.com [hercules-390]
Well, for instance, if you produce a
load module using a VSAM routine
to which a PTF has been applied on
your system, but is not applied on
the target system, you might get
differing results, or an abend.
A VSAM routine that is linked into
my load module, or one that is
fetched from the link list at runtime?
If the former, then any bugs in it
will probably be visible on any
system and it requires me to
regenerate the load module.
If the latter, and the VSAM routine
is not actually my code, then it is
the user's responsibility to provide
a correctly working VSAM routine,
not mine.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 00:40:17 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
It is in no way pure text.
Has to be.
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text.

What is your definition of "text"? If you
are copying IBM's definition of "text"
as "binary output from the assembler,
such as OP codes, that must be
preserved and cannot be translated
into ASCII and be meaningful", then
my original comment about needing
to transfer in binary mode still stands.

Because no matter what adjective
IBM uses to describe the content
of an object file, it is what most
people, including me, call "binary",
and must be exactly preserved
as it has no meaning outside of
that, any more than a zip file
would have meaning if it was
blindly translated from ASCII
to EBCDIC.

My definition of "text" on the other
hand is that it contains characters
that are recognized by a human
reader, in some sort of language,
like English or German, and the
binary representation of those
characters is not important, and
probably unknown, to the human.
Post by Joe Monk ***@gmail.com [hercules-390]
Thats why there are TXT records in
the object file! Even IBM refers to it
as the "TEXT" of the program...
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion. If you instead refer
to the documentation of the IBM C
compiler, and look up the difference
between fopen() with "r" vs "rb" you
should see a different, and more
accurate/useful definition.
Post by Joe Monk ***@gmail.com [hercules-390]
the text of the program - the instructions
and data, as output by the language
translator (TXT)
I think they should have used "contents"
instead of "text" to avoid this confusion.
This is the first time I've seen any
confusion though, as ordinary users
don't read object code, and programmers
should be able to recognize binary
opcodes as binary, regardless of any
adjective IBM cares to use.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 00:49:46 UTC
Permalink
"You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text."

Correct, because in a transfer between two mainframes, the file can be
transferred as a text file.

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
It is in no way pure text.
Has to be.
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text.
What is your definition of "text"? If you
are copying IBM's definition of "text"
as "binary output from the assembler,
such as OP codes, that must be
preserved and cannot be translated
into ASCII and be meaningful", then
my original comment about needing
to transfer in binary mode still stands.
Because no matter what adjective
IBM uses to describe the content
of an object file, it is what most
people, including me, call "binary",
and must be exactly preserved
as it has no meaning outside of
that, any more than a zip file
would have meaning if it was
blindly translated from ASCII
to EBCDIC.
My definition of "text" on the other
hand is that it contains characters
that are recognized by a human
reader, in some sort of language,
like English or German, and the
binary representation of those
characters is not important, and
probably unknown, to the human.
Post by Joe Monk ***@gmail.com [hercules-390]
Thats why there are TXT records in
the object file! Even IBM refers to it
as the "TEXT" of the program...
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion. If you instead refer
to the documentation of the IBM C
compiler, and look up the difference
between fopen() with "r" vs "rb" you
should see a different, and more
accurate/useful definition.
Post by Joe Monk ***@gmail.com [hercules-390]
the text of the program - the instructions
and data, as output by the language
translator (TXT)
I think they should have used "contents"
instead of "text" to avoid this confusion.
This is the first time I've seen any
confusion though, as ordinary users
don't read object code, and programmers
should be able to recognize binary
opcodes as binary, regardless of any
adjective IBM cares to use.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 01:02:46 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text.
Correct, because in a transfer between
two mainframes, the file can be transferred
as a text file.
In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too.

That doesn't make an executable
a text file. If you start calling executable
files "text files" there is no longer any
meaning for the word "binary".

What is your definition of a "binary"
file?

Also, when transferring an object
file from one mainframe to another
in text mode, there may be character
conversion done for the different
code pages used, e.g. 1047 to 037.
That will totally destroy your object
file. This destruction won't happen if
you do a binary transfer, which is
exactly what is required for an
object file.

If you go to the effort to ensure that
the code pages are identical on both
ends to ensure that absolutely no
bytes are converted, then all you are
doing is ensuring that you are doing
a binary transfer, and you just wish
to avoid using the word "binary"
publicly, for reasons unknown.

BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 02:42:37 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too.
Uh, no. That is, unless you don't care if your executable runs at the other
end. You seem to asume that

1) All UNIX systems use the same character encoding,

2) All UNIX systems use the same Application Binary Interface (ABI).

Neither is true, nor has either ever been true except perhaps in the very
earliest days of UNIX when it ran on exactly one platform.

Tony H.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 02:45:25 UTC
Permalink
"In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too."

Nope. Unix running on a DEC is not the same Unix running on an X86 box.

Joe
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too.
Uh, no. That is, unless you don't care if your executable runs at the
other end. You seem to asume that
1) All UNIX systems use the same character encoding,
2) All UNIX systems use the same Application Binary Interface (ABI).
Neither is true, nor has either ever been true except perhaps in the very
earliest days of UNIX when it ran on exactly one platform.
Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:52:21 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too.
Nope.
It's the principle that matters. If I
show an instance of any two boxes
successfully transferring a Unix
executable without altering any
of the data, does that mean, in
your eyes, that Unix executables
are not binary?
Post by Joe Monk ***@gmail.com [hercules-390]
Unix running on a DEC
So? Two DEC Unixes transferring
a load module successfully, the
same as you claimed MVS could
do. Are DEC Unix load modules
binary or text under your definitions?

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:50:10 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
In a transfer between two Unix
systems, an executable file (ie
a load module) can be transferred
in text mode too.
Uh, no. That is, unless you don't care if
your executable runs at the other end.
You seem to asume that
1) All UNIX systems use the same character encoding,
Ok, that's just being picky. It's the
principle of text transfers sometimes
being able to NOT mangle binary
data on ASCII machines.

So two Linux/386 with the same
code pages then.
Post by ***@yahoo.com.au [hercules-390]
2) All UNIX systems use the same
Application Binary Interface (ABI).
That is irrelevant to the fact that the
binary file survives a text transfer.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 01:06:19 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text.
Correct, because in a transfer between
two mainframes, the file can be transferred
as a text file.
Also, in what circumstances do you
recommend that a mainframe file
be transferred as a binary file instead
of a text file?

What sort of mainframe file matches
your definition of "binary", thus needing
a binary transfer?

Please answer for both a transfer to
another mainframe and a transfer from
MVS to Unix.

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 01:06:18 UTC
Permalink
"Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion."

It's been that way since the 360 days...

OBJECT AND LOAD MODULES

Object modules and load modules have the same basic logical structure.
Each consists
of:

• Text, containing the instructions and data of the program.

http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/ibm/360/os/R21.7_Apr73/GC28-6538-10_Linkage_Editor_Rel_21_Apr73.pdf


Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
It is in no way pure text.
Has to be.
Post by ***@yahoo.com.au [hercules-390]
Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode
Why? Object code (linker input) is 80
byte card images ... pure text.
You were disputing my claim that object
code needs to be transferred in binary
mode, because it is allegedly text.
What is your definition of "text"? If you
are copying IBM's definition of "text"
as "binary output from the assembler,
such as OP codes, that must be
preserved and cannot be translated
into ASCII and be meaningful", then
my original comment about needing
to transfer in binary mode still stands.
Because no matter what adjective
IBM uses to describe the content
of an object file, it is what most
people, including me, call "binary",
and must be exactly preserved
as it has no meaning outside of
that, any more than a zip file
would have meaning if it was
blindly translated from ASCII
to EBCDIC.
My definition of "text" on the other
hand is that it contains characters
that are recognized by a human
reader, in some sort of language,
like English or German, and the
binary representation of those
characters is not important, and
probably unknown, to the human.
Post by Joe Monk ***@gmail.com [hercules-390]
Thats why there are TXT records in
the object file! Even IBM refers to it
as the "TEXT" of the program...
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion. If you instead refer
to the documentation of the IBM C
compiler, and look up the difference
between fopen() with "r" vs "rb" you
should see a different, and more
accurate/useful definition.
Post by Joe Monk ***@gmail.com [hercules-390]
the text of the program - the instructions
and data, as output by the language
translator (TXT)
I think they should have used "contents"
instead of "text" to avoid this confusion.
This is the first time I've seen any
confusion though, as ordinary users
don't read object code, and programmers
should be able to recognize binary
opcodes as binary, regardless of any
adjective IBM cares to use.
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 01:08:52 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion.
It's been that way since the 360 days...
Yes, and I had hoped that in the decades
since IBM created this unusual wording,
people would have figured out that that
does NOT mean that load modules do
NOT contain binary data, and that they
do in fact contain OP codes of translated
instructions like MVC, and data doesn't
get any binary-er than op codes!

BFN. Paul.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-16 01:23:20 UTC
Permalink
"that they
do in fact contain OP codes of translated
instructions like MVC, and data doesn't
get any binary-er than op codes!"

The op-code for MVC is D2. D2 is the character K.

So when I see a K in a object deck, is it the character K or the op-code D2?

Joe
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion.
It's been that way since the 360 days...
Yes, and I had hoped that in the decades
since IBM created this unusual wording,
people would have figured out that that
does NOT mean that load modules do
NOT contain binary data, and that they
do in fact contain OP codes of translated
instructions like MVC, and data doesn't
get any binary-er than op codes!
BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 01:35:13 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
that they
do in fact contain OP codes of translated
instructions like MVC, and data doesn't
get any binary-er than op codes!"
The op-code for MVC is D2. D2 is the character K.
So when I see a K in a object deck, is it
the character K or the op-code D2?
That's the whole point. A transfer program
has NO IDEA which one it is.

If a text mode transfer is done from MVS
to Unix, an EBCDIC to ASCII conversion
will be attempted, and that x'D2' above
will be converted EVEN IF IT AS OP
CODE NOT the letter K.

A binary mode transfer must be done to
preserve the original file. And then only
an application that understands load
modules or object decks can possibly
decipher that, and potentially display
the letter "K" in ASCII if it has determined
that the x'D2' is a letter, not an op code.

A load module is probably not actually
decipherable, because it is ultimately
impossible to know if something is a
letter or an op code, you really only
find out when the op code is actually
executed. But for a different binary
file, like XMIT or ZIP, you can indeed
accurately analyze the file and know
for certain when a particular byte is
a binary length or an ASCII file name.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 01:40:25 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
A load module is probably not actually
decipherable, because it is ultimately
impossible to know if something is a
letter or an op code, you really only
find out when the op code is actually
executed.
Note that the assembler at the time
it is assembling some assembler
code will normally know whether it
is an op code or a letter that is being
inserted into the object file.

It is the disassembler that has a hell
of a problem trying to figure out which
one it was.

And the loader/execution does not
need to know which is which until
such time as the op code is actually
executed.

BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 02:51:35 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Yes, that's a strange definition for IBM
to use, and apparently is enough to
cause confusion.
It's been that way since the 360 days...
Yes, and I had hoped that in the decades
since IBM created this unusual wording,
It wasn't unusual at the time. And it's still not unreasonable that a
document talking about notions like object code should have to take the
trouble to point out that it's in binary and that sending it to foreign
systems as though it were character strings may mess it up.

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:56:44 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
It wasn't unusual at the time. And it's still
not unreasonable that a document talking
about notions like object code should
have to take the trouble to point out that
it's in binary and that sending it to foreign
systems as though it were character strings
may mess it up.
Did you mean to say "should NOT have ..."?

Personally I have no idea how any
programmer could call object code
text, even if IBM uses that word,
and insist that it is not binary, and
give as proof that it is not binary
that an MVS to MVS text transfer
doesn't mangle any characters.

I don't know whether IBM needs
to explicitly mention that text does
not mean text in current vernacular.

BFN. Paul.

Bernd Oppolzer berndoppolzer@yahoo.com [hercules-390]
2017-04-15 23:35:45 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by Joe Monk ***@gmail.com [hercules-390]
"Even if you only produced a single
program, the object code would
still need to be transferred in binary
mode"
Why? Object code (linker input) is 80 byte card images ... pure text.
These comments show an interesting understanding of "text" format ...

the 80 byte card images of "object code" is not "text format" in that sense
that is can be transferred to the PC (and translated to ASCII) and that
it does
then make any sense there, because the content is to a large part binary
machine
instructions, which will be garbage after the codepage translation.

Same goes for ZIP files that are constructed on Windows (for example)
and then transferred to the mainframe; if I unzip them there, I will get -
for example - source files in a foreign codepage, which are kind of
useless.

XMIT (which seems to be a format to transfer binary content between
mainframes)
is probably useless on the PC platform etc. etc.

That's what I meant: if I do a binary transfer between different platforms,
I only can imagine some sort of archive usage (the foreign platform only
is used as a sort of archive server, but not for USING the binary data).

On the other hand:

some programming languages, including PL/1 and Pascal, for example,
can process 80 byte object code files as "TEXT" files without problems;
there are no restrictions or problems (like some other languages have them,
with hex zeroes, for example). These languages even don't make a difference
between textfiles and binary files - but that's another story. The problems
arise when platform boundaries are crossed.

Kind regards

Bernd
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 23:51:33 UTC
Permalink
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
Same goes for ZIP files that are constructed on Windows (for example)
and then transferred to the mainframe; if I unzip them there, I will get -
for example - source files in a foreign codepage, which are kind of useless.
Sorry, I don't know what you are
talking about regarding "kind of
useless". What exactly do you
have in mind zipping stuff on
Windows and then unzipping
on MVS that doesn't work?

I do this all the time and it works
just fine.

Are you zipping assembler code,
Pascal code, documentation or
what?

Depending on your answer, there
may be a market for an updated
miniunz. I need to know your
"user requirements".

I can guarantee that all the 7-bit
ASCII characters will correctly
find a home in EBCDIC 1047.

BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 02:09:44 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
I can guarantee that all the 7-bit
ASCII characters will correctly
find a home in EBCDIC 1047.
This is not so subtly different from "I can guarantee that all the 7-bit
ASCII characters will find their correct home in EBCDIC 1047".

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:23:15 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
I can guarantee that all the 7-bit
ASCII characters will correctly
find a home in EBCDIC 1047.
This is not so subtly different from "I can
guarantee that all the 7-bit ASCII
characters will find their correct home
in EBCDIC 1047".
Yes, you are correct. There are
multiple definitions of "correct"
at play, and I'm not claiming
that mine is the only one.
Post by Tony Harminc ***@gmail.com [hercules-390]
Same goes for ZIP files that are constructed on Windows (for example)
and then transferred to the mainframe; if I unzip them there, I will get -
for example - source files in a foreign codepage, which are kind of useless.
And given that I unzip (on the mainframe)
files that were constructed on Windows,
and get excellent results, exactly what I
expect, and I have done this numerous
times, the conclusion of "kind of useless"
is very inaccurate for *my* usage *at
least*.

I get exactly what I expect as a C
programmer who expects all characters
on the US ASCII keyboard to be
available, and has no expectation of
other characters, like Euro or "cent",
from being displayed "correctly".

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:37:22 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
I can guarantee that all the 7-bit
ASCII characters will correctly
find a home in EBCDIC 1047.
This is not so subtly different from "I can
guarantee that all the 7-bit ASCII
characters will find their correct home
in EBCDIC 1047".
Yes, you are correct. There are
multiple definitions of "correct"
at play, and I'm not claiming
that mine is the only one.
Post by Tony Harminc ***@gmail.com [hercules-390]
Same goes for ZIP files that are constructed on Windows (for example)
and then transferred to the mainframe; if I unzip them there, I will get -
for example - source files in a foreign codepage, which are kind of useless.
And given that I unzip (on the mainframe)
files that were constructed on Windows,
and get excellent results, exactly what I
expect, and I have done this numerous
times, the conclusion of "kind of useless"
is very inaccurate for *my* usage *at
least*.

I get exactly what I expect as a C
programmer who expects all characters
on the US ASCII keyboard to be
available, and has no expectation of
other characters, like Euro or "cent",
from being displayed "correctly".

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 00:14:24 UTC
Permalink
XMIT (which seems to be a format to transfer binary content between mainframes)
is probably useless on the PC platform etc. etc.
I don't think this is true either. XMIT is in
a well-defined format, so a PC program
can be constructed such that it expects
data to be in EBCDIC and thus the
application needs to do any conversions
itself. This has already been done, and
you can see the result below.

Similarly CMS uses "vmarc" files for
data interchange, and that too can be
coded for in an ASCII environment.
See below too.

BFN. Paul.


C:\>recv390
Error opening input file OS390.XMI
Execution will terminate following display of help.
Press enter to continue


Syntax: [options...] [[path]fn[.exti] [exto]]

path path name of input file (default=current directory)
fn[.exti] input file name (default fn=OS390 ext=XMI)
[exto] output file extension (default=TXT)
output fn = PDS member name
Help (default: not displayed
Default options on/yes(+) off/no(-) unless error occurs):
------------------------------------------- ------------------------------
+tran translate from EBCDIC to ASCII -about copyright & version
-seq remove sequence field -help general help
+trim remove trailing blanks -syntax syntax help
-rdw no OS/390 RDW -helpbug debug help
+dir display PDS directory -helptran translation help
+write write output file(s) -helprdw RDW help
+halt issue <press enter> prompt -helpseq sequence field help
+xmisum display TRANSMIT dataset summary
+dsattr display dataset attributes
-dirhex don't display directory entries'
userdata in hex
-map don't show translation table

Press enter to continue


C:\>vma
vma - List/Extract files from VMARC archives

Usage: vma [options] input [fn [ft [fm ]]]

Options:
-a convert extracted files to ASCII
-c convert names to lowercase
-h display usage summary
-l list files (default)
-m fm replace filemode...0=remove
-q do not list files
-s safe, slow, subfile searching
-u f,t (f)rom and (t) UCM filenames
-v verbose listing
-x extract files
-V display version

input:
name of the VMARC archive

fn, ft, fm:
filter on file name, type, and/or mode
(case is significant)

f,t:
paths to translateion tables (see README)

C:\>
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 00:54:14 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
And note that I send ALL.zip up via
the tape drive rather than trying to
send a large file up via the card
reader. You may prefer to send
files up via ftp. Maybe that is the
way you can avoid having to
issue devinits on a running system.
I didn't think of that until just now.
Although if you're on a system with
ftp available, ie TK4- or z/OS,
then maybe you don't need your
batch file in the first place.

Does your Pascal compiler need
more than 10 MiB of memory to
compile large programs hence
you "need" MVS/380?

BFN. Paul.
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-04-14 15:39:52 UTC
Permalink
Post by Bernd Oppolzer ***@yahoo.com [hercules-390]
when sending a file from the PC to Hercules MVS this way,
which contains JCL, I have the problem that the file on Hercules MVS
will be empty because of the JCL in the input file ...
(maybe other errors ... the IEBGENER JCL will be garbage)
Same problem with program sources which contained /* ... */
style comments in column 1; I had to change all those comments
to (* ... *) - both are possible in my version of Stanford Pascal.
Any ideas or suggestions?
Change the DD * to DD DATA,DLM='??'
follow by text
terminate with ?? (columns 1-2)

The ?? are two characters that do not appear in column 1 of your data.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 10:40:45 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Another option I would consider
if it was me, would be to modify
miniunz to have an extra translate
table for Hebrew, and do all my
work on the PC, zip it up, then
send it up via tape, as binary, and
then unzip all my code and do a
compile or whatever.
I have just done the above - add
Hebrew support to minizip. It needs
to be compiled with -DHEBREW
and you need to unzip with the "-c"
option as well as "-a". I did a brief
test and it seemed to be fine.

You can find that here:

https://groups.yahoo.com/neo/groups/hercules-390/files/minizip-stage20.zip

I won't be offended if you don't use it,
as you didn't actually ask for this.

You need a C compiler. GCCMVS
(free) is available if you don't already
have one.

If you prefer, I can do an IEBCOPY
unload of the load module.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 10:49:07 UTC
Permalink
Perhaps some instructions might help!

In the zip file you will find a zip file
called minijcl.zip.

Within that, there are jobs mini1 to
mini7. I run all of them in sequence.

Depending on how you plan to do
things, you may need to skip or
change the JCL.

BFN. Paul.
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-14 11:07:05 UTC
Permalink
Thanks a lot. I will spend time on this after the weekend...
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-14 18:19:06 UTC
Permalink
Hang on.

You have specified the *output* code table. But did you also specify a
Hebrew *keyboard*? At least in Pcomm 3270 those are independent; you
can attach a US keyboard to a Hebrew display.

On 04/14/2017 01:07 PM,
***@yahoo.com [hercules-390] wrote:
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 01:36:18 UTC
Permalink
Can someone elaborate on the theory
of code pages?

I am wondering why no-one has ever
requested (thus perhaps this is not
the right solution to the problem) the
minizip translate tables to be updated
to give translations for other languages.
The only options that have existed for
many years are 1047 and 037 - ie 2
American formats and zero formats
for anyone else.

I'm guessing that 819 to 1047 covers
not just America but most of Europe,
which greatly trims down the number
of people likely to request a change.

And the Greeks are presumably too
broke to be able to afford computers,
so that's their language out too.

The Russians are subject to sanctions,
so they're not allowed to buy
computers.

And so it's only now that Jews and
Arabs have paused fighting each
other for long enough to start
requesting code page updates.

But even so, let's take a look at
1255 to 424. 1255 has a "Nun"
at position x'f0'. In 424 it is at
position x'58'. So we have an
obvious need for a translation
here. Or do we?

819 x'f0' is "eth Icelandic Small".
1047 x'58' is "i Grave Small". So
clearly an 819 to 1047 conversion
is unsuitable for Hebrew. Or is it?

Why do Hebrew people actually
care if the "Nun" is at position
x'58' on the mainframe? What's
wrong with the 1047 position of
x'8c' (which is also "eth Icelandic
Small").

Why not just configure the terminal
to display EBCDIC x'8c', converted
to ASCII x'f0' (as per 1047 to 819
rules), as a "Nun"?

Basically what are non-English
language people trying to achieve
with non-819/1047 translations?

For that matter, what are English
language people trying to achieve
with 819 to 037 instead of 819 to
1047?

And actually, when Michel Beaulieu
released dosvs5pack-v1r0m1-run.zip
he switched 819/1047 to 437/500
in Hercules which took me about a
day to figure out why my C programs
weren't compiling on DOS/VS.

That implies that there is something
wrong with 819/1047 for a French
Canadian user. What?

Also I have released a new version
of my utility that defines all the
immutable ASCII values in hex
instead of a character literal so it
should run fine on an EBCDIC
system if for some reason you
want to do the conversion there
instead of on the PC:

https://groups.yahoo.com/neo/groups/hercules-390/files/makecodp-stage4.zip

BFN. Paul.
Mike Schwab Mike.A.Schwab@gmail.com [hercules-390]
2017-04-15 17:08:01 UTC
Permalink
Has anyone considered putting all the translation tables into a load
module, then selecting which table with a parm. When during startup
the code page is determined and the address is stored in a fixed
location. Then when the translate function is called, it uses the
address in the fixed location.
Post by ***@yahoo.com.au [hercules-390]
Can someone elaborate on the theory
of code pages?
I am wondering why no-one has ever
requested (thus perhaps this is not
the right solution to the problem) the
minizip translate tables to be updated
to give translations for other languages.
The only options that have existed for
many years are 1047 and 037 - ie 2
American formats and zero formats
for anyone else.
I'm guessing that 819 to 1047 covers
not just America but most of Europe,
which greatly trims down the number
of people likely to request a change.
And the Greeks are presumably too
broke to be able to afford computers,
so that's their language out too.
The Russians are subject to sanctions,
so they're not allowed to buy
computers.
And so it's only now that Jews and
Arabs have paused fighting each
other for long enough to start
requesting code page updates.
But even so, let's take a look at
1255 to 424. 1255 has a "Nun"
at position x'f0'. In 424 it is at
position x'58'. So we have an
obvious need for a translation
here. Or do we?
819 x'f0' is "eth Icelandic Small".
1047 x'58' is "i Grave Small". So
clearly an 819 to 1047 conversion
is unsuitable for Hebrew. Or is it?
Why do Hebrew people actually
care if the "Nun" is at position
x'58' on the mainframe? What's
wrong with the 1047 position of
x'8c' (which is also "eth Icelandic
Small").
Why not just configure the terminal
to display EBCDIC x'8c', converted
to ASCII x'f0' (as per 1047 to 819
rules), as a "Nun"?
Basically what are non-English
language people trying to achieve
with non-819/1047 translations?
For that matter, what are English
language people trying to achieve
with 819 to 037 instead of 819 to
1047?
And actually, when Michel Beaulieu
released dosvs5pack-v1r0m1-run.zip
he switched 819/1047 to 437/500
in Hercules which took me about a
day to figure out why my C programs
weren't compiling on DOS/VS.
That implies that there is something
wrong with 819/1047 for a French
Canadian user. What?
Also I have released a new version
of my utility that defines all the
immutable ASCII values in hex
instead of a character literal so it
should run fine on an EBCDIC
system if for some reason you
want to do the conversion there
https://groups.yahoo.com/neo/groups/hercules-390/files/makecodp-stage4.zip
BFN. Paul.
------------------------------------
------------------------------------
http://groups.yahoo.com/group/hercules-390
http://www.hercules-390.org
------------------------------------
Yahoo Groups Links
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 01:52:37 UTC
Permalink
Post by Mike Schwab ***@gmail.com [hercules-390]
Has anyone considered putting all the translation tables into a load
module, then selecting which table with a parm.
IBM doubtless has a patent on that... But it's probably expired by now.
Post by Mike Schwab ***@gmail.com [hercules-390]
When during startup
the code page is determined and the address is stored in a fixed
location. Then when the translate function is called, it uses the
address in the fixed location.
Not everyone wants to use just one code page at a time.

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 07:27:48 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Below are the 819/1047 tables I use.
A diff shows me that I have changed
these tables from standard Hercules
3.07, probably because the programming
characters weren't going through as
I expected.
I investigated this, and found that the
problem was that standard 3.07 was
translating Unix LF into MVS LF
instead of MVS NL as needed by C
programs.

C:\devel\makecodp\hercdiff>diff std307.txt herc380.txt
5c5
< /* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x25\x0B\x0C\x0D\x0E\x0F"
---
Post by ***@yahoo.com.au [hercules-390]
/* 0x */ "\x00\x01\x02\x03\x37\x2D\x2E\x2F\x16\x05\x15\x0B\x0C\x0D\x0E\x0F"
13c13
< /* 8x */ "\x20\x21\x22\x23\x24\x15\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B"
---
Post by ***@yahoo.com.au [hercules-390]
/* 8x */ "\x20\x21\x22\x23\x24\x25\x06\x17\x28\x29\x2A\x2B\x2C\x09\x0A\x1B"
29,30c29,30
< /* 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"
---
Post by ***@yahoo.com.au [hercules-390]
/* 1x */ "\x10\x11\x12\x13\x9D\x0A\x08\x87\x18\x19\x92\x8F\x1C\x1D\x1E\x1F"
/* 2x */ "\x80\x81\x82\x83\x84\x85\x17\x1B\x88\x89\x8A\x8B\x8C\x05\x06\x07"
C:\devel\makecodp\hercdiff>


Also note that I have a new cut of makecodp
available here:

https://groups.yahoo.com/neo/groups/hercules-390/files/makecodp-stage2.zip

I just cleaned up the code after
switching warnings on in bcc32.
No real technical change.

BFN. Paul.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-14 07:44:39 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
I investigated this, and found that the
problem was that standard 3.07 was
translating Unix LF into MVS LF
instead of MVS NL as needed by C
programs.
In most VMers' view, LF -> NL translation is a bug (but clearly not one
that will be fixed). EBCDIC x'15' was used by EBCDIC typewriters (274x)
to indicate that the new line key was pressed, and hence went into
CONTASK processing as indicating end-of-command, so that you could stack
commands in one Diagnose 8 by separating them with x'15'. This survives
to this day.

NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.

Be sure also to use EBCDIC code page 1047 rater than 037 or 037-2, as is
often done erroneously.
kerravon86@yahoo.com.au [hercules-390]
2017-04-14 01:39:46 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
I tell the 3270 emulation client that M
host code page is 424 (Hebrew)
If I write a program to create Hercules
code conversions, I already know the
Hebrew host code page is 424, but
what is the code page for your ASCII PC?

The choice here:

https://www-01.ibm.com/software/globalization/cp/cp_cpgid.html

is 803 (another EBCDIC which we can
presumably ignore), 856, 916, 1255.

The description of 916 says that it is
also ISO 8859 Part 8 (1988).

The description of 1255 also says
that it matches ISO 8859-8 (CP 00916)
but seems to have more additions,
which are way above my head.

My guess is that we should be using
1255, but that a lot of the characters
won't actually find a mapping in 424,
so it will be a moot point.

BFN. Paul.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-04-13 20:08:54 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
Does the CODEPAGE configuration option has any impact on
how data entered via the keyboard is displayed on the screen
when connecting to Hercules via a 3270 emulation client
like C3270 or QWS3270 ?
Yes.
The data Hercules receives from the TN3270 client is ASCII and must be translated to EBCDIC before passing it on to the guest. When the guest then decides to write something to its 3270 device, the data "received" by Hercules must then be translated from EBCDIC back into ASCII again before being transmitted to the TN3270 client. Your chosen Hercules CODEPAGE is used for both.
Fish,

From reading the question, I think he means that when a types a certain
key, then something else may show (before anything is sent). That's
purely local to the emulator and the codepage configured for hercules
won't have any effect there.

--Ivan



[Non-text portions of this message have been removed]
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 20:18:40 UTC
Permalink
Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The data Hercules receives from the TN3270
client is ASCII and must be translated to
EBCDIC before passing it on to the guest.
The 3270 data stream contains some
binary data that should NOT be
translated, doesn't it?

I would have thought that only the
c3270 application could know which
bit is user input and which bit is binary,
thus c3270 would need to do the
translation of the user input.

And thus c3270 would need to maintain
its own translate tables.

Also, if Hercules was doing the
translation, then how could ind$file
work? ind$file has its own translate
tables too, doesn't it? Or does it
pick it up from c3270 or Hercules?

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 20:21:33 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
I would have thought that only the
c3270 application could know which
bit is user input and which bit is binary,
thus c3270 would need to do the
translation of the user input.
But if it was a 3215 telnet session, I
would instead expect that to go
through the Hercules codepage
translation defined in the Hercules
config file.

BFN. Paul.
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-13 20:19:09 UTC
Permalink
Thanks for the info. So that explains why typing Hebrew in the emulated session is displayed as garbage on the screen.
From what I read there is no code page for Hebrew in Hercules.


Dani Kalmar
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-04-13 20:26:33 UTC
Permalink
On 4/13/2017 10:19 PM,
Post by ***@yahoo.com [hercules-390]
Thanks for the info.
So that explains why typing Hebrew in the emulated session is
displayed as garbage on the screen.
From what I read there is no code page for Hebrew in Hercules.
Dani Kalmar
Dani,

You're probably going to need a unicode capable system and 3270 emulator.

Going from UNICODE to EBCDIC is not a simple task (and probably - but I
don't know much) converting UNICODE to DBCS EBCDIC, so the 3270 terminal
must be ready for it.

--Ivan


[Non-text portions of this message have been removed]
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-13 20:32:22 UTC
Permalink
Dani,

The point here is that the data you see on your screen in the 3270
window is presented to your terminal's operating system in ASCII.

If you run VM on Hercules, you might get away with uppercase input and
using the uppercase English messages.
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
On 4/13/2017 10:19 PM,
Post by ***@yahoo.com [hercules-390]
Thanks for the info.
So that explains why typing Hebrew in the emulated session is
displayed as garbage on the screen.
From what I read there is no code page for Hebrew in Hercules.
Dani Kalmar
Dani,
You're probably going to need a unicode capable system and 3270 emulator.
Going from UNICODE to EBCDIC is not a simple task (and probably - but I
don't know much) converting UNICODE to DBCS EBCDIC, so the 3270 terminal
must be ready for it.
--Ivan
[Non-text portions of this message have been removed]
------------------------------------

------------------------------------

Community email addresses:
Post message: hercules-***@yahoogroups.com
Subscribe: hercules-390-***@yahoogroups.com
Unsubscribe: hercules-390-***@yahoogroups.com
List owner: hercules-390-***@yahoogroups.com

Files and archives at:
http://groups.yahoo.com/group/hercules-390

Get the latest version of Hercules from:
http://www.hercules-390.org


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/hercules-390/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/hercules-390/join
(Yahoo! ID required)

<*> To change settings via email:
hercules-390-***@yahoogroups.com
hercules-390-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
hercules-390-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/
ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7@yahoo.com [hercules-390]
2017-04-13 20:59:32 UTC
Permalink
My problem is not with messages. I have character literals in COBOL source with Hebrew letters that are messed up. and I need them to be
in Hebrew for validation processing.
Joe Monk joemonk64@gmail.com [hercules-390]
2017-04-13 21:01:27 UTC
Permalink
Yep ... you'll have to use unicode.

Joe

On Thu, Apr 13, 2017 at 3:59 PM,
Post by ***@yahoo.com [hercules-390]
My problem is not with messages.
I have character literals in COBOL source with Hebrew letters that are
messed up. and I need them to be
in Hebrew for validation processing.
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 21:11:05 UTC
Permalink
Post by Joe Monk ***@gmail.com [hercules-390]
Post by ***@yahoo.com [hercules-390]
My problem is not with messages.
I have character literals in COBOL
source with Hebrew letters that are
messed up. and I need them to be
in Hebrew for validation processing.
Yep ... you'll have to use unicode.
Why? 256 values should be enough
to store all standard EBCDIC values
plus the extra Hebrew characters.

The source code in question almost
certainly came from a single byte
character set.

BFN. Paul.
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-04-13 21:47:29 UTC
Permalink
On 4/13/2017 10:59 PM,
Post by ***@yahoo.com [hercules-390]
My problem is not with messages.
I have character literals in COBOL source with Hebrew letters that are
messed up. and I need them to be
in Hebrew for validation processing.
Dani,

My guess now is that your tn3270 client has to be able to convert Code
Page 424 to either Unicode or Code Page 856.

As said before, the contents of your dataset are going to be sent
unabridged to your TN3270 emulator.

For C3270, try c3270 -charset CP424 (but depending where the c3270
session is started, you may run into other problems).

--Ivan


[Non-text portions of this message have been removed]
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-13 22:18:08 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
My guess now is that your tn3270 client has to be able to convert Code
Page 424 to either Unicode or Code Page 856.
This is probably close, but as so often when people try to do (loosely)
"ASCII" <-> "EBCDIC" conversions, they are often not converting the same
character set. So e.g. the popular code pages (CPs) 037 and 1047 and 819
and a whole bunch more all encode IBM Character Set (CS) 697, i.e. they
contain exactly the same set of characters mapped to different byte values.
But there are other CPs that encode a different CS, e.g. CP 850 has most
characters mapped to the same places as CP 819, but there are more
characters that cannot be translated to CP 037 or 1047 or indeed 819
because they don't exist in those target CPs.

So in this case CP 424 encodes CS 941, which includes 25 Hebrew letters, 26
Latin letters (both upper and lower case), and various other things. CP 856
encodes CS 986, which has a larger number of characters, also including
both Hebrew and Latin letters. There appear to be two more Hebrew letters
than CS 941; I don't know Hebrew, so I don't know if this makes sense.
Perhaps they are like English letters Þ and Ð; used only for historical
purposes.

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 23:03:52 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
My problem is not with messages. I have
character literals in COBOL source with
Hebrew letters that are messed up. and
I need them to be in Hebrew for validation
processing.
Can you elaborate on "messed up"?
What character are you typing, what
is it's ASCII value, and what is the
expected EBCDIC value, and what
EBCDIC value are you actually
getting?

Note that if you are using the RPF
editor, and you have caps on
(default), then the crude uppercasing
algorithm that is used, ie OR x'40',
may be stuffing up your Hebrew
characters. If so, try typing "asis"
first.

Also, if you are using the Yahoo
groups interface to reply to
messages, can you please click
on "> show message history"
down the bottom so that we can
see which message you are
replying to.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-13 20:38:05 UTC
Permalink
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by ***@yahoo.com [hercules-390]
Thanks for the info.
So that explains why typing Hebrew in the emulated session is
displayed as garbage on the screen.
From what I read there is no code page for Hebrew in Hercules.
You're probably going to need a unicode capable system and 3270 emulator.
Going from UNICODE to EBCDIC is not a simple task (and probably - but I
don't know much) converting UNICODE to DBCS EBCDIC, so the 3270 terminal
must be ready for it.
It is only CJK (Chinese/Japanese/Korean)
that requires 2 bytes to store all their
characters (because they didn't invent an
alphabet).

I would hope the user could code up a
suitable Hebrew code page that at least
allow Hebrew to go up via the card reader
and down via the printer.

They could use their Windows Hebrew
editor to maintain their files. That is
exactly how I do my work already - I
virtually never use a 3270 emulator.
I just use the card reader, tape drive
and printer. ie traditional MVS before
TSO. Apparently I'm the oldest fogey
in the world.

BFN. Paul.
Gregg Levine gregg.drwho8@gmail.com [hercules-390]
2017-04-13 20:44:13 UTC
Permalink
Hello!

Actually one does exist for both... But both the OS running on the PC
and via Hercules properly grok it.

-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."
Post by ***@yahoo.com.au [hercules-390]
Post by Ivan Warren ***@vmfacility.fr [hercules-390]
Post by ***@yahoo.com [hercules-390]
Thanks for the info.
So that explains why typing Hebrew in the emulated session is
displayed as garbage on the screen.
From what I read there is no code page for Hebrew in Hercules.
You're probably going to need a unicode capable system and 3270 emulator.
Going from UNICODE to EBCDIC is not a simple task (and probably - but I
don't know much) converting UNICODE to DBCS EBCDIC, so the 3270 terminal
must be ready for it.
It is only CJK (Chinese/Japanese/Korean)
that requires 2 bytes to store all their
characters (because they didn't invent an
alphabet).
I would hope the user could code up a
suitable Hebrew code page that at least
allow Hebrew to go up via the card reader
and down via the printer.
They could use their Windows Hebrew
editor to maintain their files. That is
exactly how I do my work already - I
virtually never use a 3270 emulator.
I just use the card reader, tape drive
and printer. ie traditional MVS before
TSO. Apparently I'm the oldest fogey
in the world.
BFN. Paul.
------------------------------------
------------------------------------
Ivan Warren ivan@vmfacility.fr [hercules-390]
2017-04-13 20:01:28 UTC
Permalink
Post by ***@yahoo.com [hercules-390]
Does the CODEPAGE configuration option has any impact on how data
entered via the keyboard is displayed on the screen when connecting to
Hercules via a 3270 emulation client like C3270 or QWS3270 ?
Dear ahngb4nond2fjs4iv3chtuacfjmf4dgzileuxli7,

It shouldn't. Keyboard output on a 3270 terminal is purely a local
matter. Hercules is only involved when an AID key is pressed.

--Ivan


[Non-text portions of this message have been removed]
Richard Chycoski myyahoo@chycoski.com [hercules-390]
2017-04-15 01:42:38 UTC
Permalink
"John P. Hartmann"
Post by ***@yahoo.com.au [hercules-390]
I investigated this, and found that the
problem was that standard 3.07 was
translating Unix LF into MVS LF
instead of MVS NL as needed by C
programs.
In most VMers' view, LF -> NL translation is a bug (but clearly not one
that will be fixed). EBCDIC x'15' was used by EBCDIC typewriters (274x)
to indicate that the new line key was pressed, and hence went into
CONTASK processing as indicating end-of-command, so that you could stack
commands in one Diagnose 8 by separating them with x'15'
Post by ***@yahoo.com.au [hercules-390]
NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.
Be sure also to use EBCDIC code page 1047 rater than 037 or 037-2, as is
often done erroneously.
Did you mean the 3215 (and such) console printers? The 274x terminals
were six-bit BCD (and 'correspondence') terminals, with different
control character codes.

- Richard, VE7CVS
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 01:52:24 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.
When doing an EBCDIC conversion to
ASCII with a Unix destination, the NL
is expected to be converted into a
single ASCII character, 0x0a.

Even on Windows, where there is
indeed a CRLF sequence in the
output files, in the actual C program
there is just a single NL character
whose value, again, is 0x0a.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 01:55:48 UTC
Permalink
Apologies Richard.

The below should have been addressed
to John, not you.

BFN. Paul.
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.
When doing an EBCDIC conversion to
ASCII with a Unix destination, the NL
is expected to be converted into a
single ASCII character, 0x0a.

Even on Windows, where there is
indeed a CRLF sequence in the
output files, in the actual C program
there is just a single NL character
whose value, again, is 0x0a.

BFN. Paul.
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 04:00:33 UTC
Permalink
Post by 'John P. Hartmann' ***@gmail.com [hercules-390]
NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.
In actual fact, the EBCDIC NL is normally
not seen at all. When a C program on an
EBCDIC system emits a NL (x15) instead
of being translated into a CRLF sequence
it is instead translated into some spaces
to fill up RECFM=F, or into an RDW in
the case of RECFM=V, or into a block
boundary in the case of non-PDPCLIB
RECFM=U.

BFN. Paul.
Gerhard Postpischil gerhardp@charter.net [hercules-390]
2017-04-15 06:22:40 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
In actual fact, the EBCDIC NL is normally
not seen at all. When a C program on an
EBCDIC system emits a NL (x15) instead
of being translated into a CRLF sequence
it is instead translated into some spaces
to fill up RECFM=F, or into an RDW in
the case of RECFM=V, or into a block
boundary in the case of non-PDPCLIB
RECFM=U.
How does an "actual fact" differ from a normal fact?

NL is used regularly when coding a VTAM application to a line mode
terminal (VTAM handles the translation to terminal code). And it's
sometimes seen in TSO applications.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com
kerravon86@yahoo.com.au [hercules-390]
2017-04-15 06:39:51 UTC
Permalink
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
In actual fact, the EBCDIC NL is normally
not seen at all. When a C program on an
EBCDIC system emits a NL (x15) instead
of being translated into a CRLF sequence
it is instead translated into some spaces
to fill up RECFM=F, or into an RDW in
the case of RECFM=V, or into a block
boundary in the case of non-PDPCLIB
RECFM=U.
How does an "actual fact" differ from a normal fact?
That is normal English. I think it means
"actually I've had another thought to
correct/expand my previous thought".
Post by Gerhard Postpischil ***@charter.net [hercules-390]
NL is used regularly when coding a VTAM application to a line mode
terminal (VTAM handles the translation to terminal code). And it's
sometimes seen in TSO applications.
Ok. I don't really understand the issue
Post by Gerhard Postpischil ***@charter.net [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
In most VMers' view, LF -> NL translation is a bug (but clearly not one
that will be fixed). EBCDIC x'15' was used by EBCDIC typewriters (274x)
to indicate that the new line key was pressed, and hence went into
CONTASK processing as indicating end-of-command, so that you could stack
commands in one Diagnose 8 by separating them with x'15'
Is there a problem with C on EBCDIC
systems using x'15' to represent NL,
in the same way that Windows uses
x'0a' to represent NL, and in both
cases, when you actually write to
some actual file, a translation will
be done that (in both cases) sees
the internal NL translated to something
else?

I'm not familiar with VTAM applications
either. I assume that if a particular
device needs some particular binary
string sent to it, that it will be necessary
to customize that instead of relying
on someone else's translate tables?

BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 02:00:29 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Is there a problem with C on EBCDIC
systems using x'15' to represent NL,
in the same way that Windows uses
x'0a' to represent NL,
Other than that Windows does not use X'0A" to represent NL...
Post by ***@yahoo.com.au [hercules-390]
and in both
cases, when you actually write to
some actual file, a translation will
be done that (in both cases) sees
the internal NL translated to something
else?
If you need some standard representation in your programming language for
NL in some character encoding, I suppose that's OK. Most programming
languages seem to manage fine without such a notion. Certainly many C
programs need to deal with multiple character representations at the same
time. Imagine a web server running on z/OS (or MVS 3.8 for that matter); it
needs to deal with data on the wire that's primarily in an ASCII dialect,
and also with files and/or datasets that are mostly in EBCDIC. Is it really
worth having a magic sequence \n or whatever that is NL in one of these
representations? IBM C has some kind of #PRAGMA to tell it how to treat
constants, but that gets ugly pretty fast.

Tony H.
kerravon86@yahoo.com.au [hercules-390]
2017-04-16 02:07:31 UTC
Permalink
Post by Tony Harminc ***@gmail.com [hercules-390]
Post by ***@yahoo.com.au [hercules-390]
Is there a problem with C on EBCDIC
systems using x'15' to represent NL,
in the same way that Windows uses
x'0a' to represent NL,
Other than that Windows does not
use X'0A" to represent NL...
That's quibbling. I meant most/all C
compilers running on a Windows
platform use 0x0a as the internal
representation of NL, which you can
see if you do:

printf("%02x\n", '\n');

BFN. Paul.
Tony Harminc tharminc@gmail.com [hercules-390]
2017-04-16 02:03:48 UTC
Permalink
Post by ***@yahoo.com.au [hercules-390]
Post by Gerhard Postpischil ***@charter.net [hercules-390]
How does an "actual fact" differ from a normal fact?
That is normal English. I think it means
"actually I've had another thought to
correct/expand my previous thought".
Perhaps unique to EN-AU. Your earlier suggestion that you change your use
of "I expect that..." to "I prefer that...". is a very good one.

Tony H.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-15 10:09:12 UTC
Permalink
All of this has nothing to do with OS/360 or its follow-ons. The
discussion of CR and LF and what not is about one particular C library's
way of accommodating the C standard.
'John P. Hartmann' jphartmann@gmail.com [hercules-390]
2017-04-15 06:12:14 UTC
Permalink
Right. CP took care of that as soon as data were in from the 270x.
After that all terminals (until the 3270 support arrived) were treated
like consoles.
Post by Richard Chycoski ***@chycoski.com [hercules-390]
"John P. Hartmann"
Post by ***@yahoo.com.au [hercules-390]
I investigated this, and found that the
problem was that standard 3.07 was
translating Unix LF into MVS LF
instead of MVS NL as needed by C
programs.
In most VMers' view, LF -> NL translation is a bug (but clearly not one
that will be fixed). EBCDIC x'15' was used by EBCDIC typewriters (274x)
to indicate that the new line key was pressed, and hence went into
CONTASK processing as indicating end-of-command, so that you could stack
commands in one Diagnose 8 by separating them with x'15'
Post by ***@yahoo.com.au [hercules-390]
NL is equivalent to the CR-LF ASCII sequence; it has no corresponding
single ASCII character.
Be sure also to use EBCDIC code page 1047 rater than 037 or 037-2, as is
often done erroneously.
Did you mean the 3215 (and such) console printers? The 274x terminals
were six-bit BCD (and 'correspondence') terminals, with different
control character codes.
- Richard, VE7CVS
RIchard myyahoo@chycoski.com [hercules-390]
2017-04-15 21:56:55 UTC
Permalink
No worries, Paul.

- Richard, VE7CVS
kerravon86
Apologies Richard.
The below should have been addressed
to John, not you.
BFN. Pau
Loading...