Re: UTF-8 woes on z/OS, a solution - comments invited

[Paul Gilmartin]

On Tue, 5 Sep 2017 02:02:03 +0100, David W Noon wrote:

>On Mon, 4 Sep 2017 17:07:08 -0700, Charles Mills (charl...@mcn.org)
>wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in
><02b401d325da$f0cb4d30$d261e790$@mcn.org>):
>
>> COBOL or Java, but what about the OP's PL/I?
>
>IBM Enterprise PL/I has WIDECHAR(*), which supports UTF-16. It also has
>the UTF8(), UTF8TOCHAR() and UTF8TOWCHAR() built-in functions that
>translate host code page to UTF-8, UTF-8 to host code page, and UTF-8 to
>UTF-16, respectively. These will probably handle UTF-8 translations more
>reliably than IND$FILE does.
>
>The problem is the complexity that was previously hidden is now visibly
>the province of the programmer.
>
Why is there UTF-16?

o It's a variable-length encoding, involving the same complexities as UTF-8.

o It lacks the compactness of UTF-8 in the case of Latin text.

Is it because it's (sort of) an extension of UCS-2?

(What does Java use internally?)

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Linda]

Ummm and I heard (and used it as) it as Seriously Outa Luck!

Linda

Sent from my iPhone

> On Sep 4, 2017, at 1:50 PM, Charles Mills  wrote:
> 
> Not the way I heard it.
> 
> Charles
> 
> 
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Monday, September 4, 2017 1:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: UTF-8 woes on z/OS, a solution - comments invited
> 
>> On Mon, 4 Sep 2017 13:17:48 -0700, Charles Mills wrote:
>> 
>> ... another vulgar cliché, ... indeed SOL ...
> ???
> Simply Outa Luck?
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: IEAARR

[Peter Relson]

My take is this:

If you comply with the documented requirements of an interface then if you 
choose to "roll your own" rather than use the macro, you will survive.
And you should expect that we will provide notification (as an 
incompatibility) if that does not hold for some reason (upon which 
notification you will be on the hook to see that notification and react).

But that does mean that you have to start by complying (and that includes 
obeying the register-choice limitations). If you choose not to comply, 
whether you roll your own or not, and we change something that affects 
only someone who does not comply, we might notify, we might not. The risk 
is yours (and your customers') to bear. It is up to your customers (or you 
if it's for yourself) to gauge whether that risk is acceptable or not. And 
if you don't inform your customers of that risk, then they might be rather 
unhappy if something unfriendly results that they can tie to that 
occurrence.

Notification might include notification to ISVs in Partners in Development 
(if I have that name right) as well as within APAR hold data and/or 
release migration data depending on the delivery mechanism of the change.


in a way, macros are for the convenience of IBM, not the convenience of
the user programmer.

I'd say "not even close". They are clearly for the convenience of the user 
as well as for the provider (whether that provider by IBM or anyone else). 

It is far easier to invoke a macro than code all the bits and bytes (as 
well as getting whatever syntax checking the macro provides).
It is true that it is likely more convenient for the provider to describe 
how to invoke the macro than how to build the parameter area. 
IBM definitely chooses to consider the book description of the macro to be 
the interface. If you use the macro, then you are intended to be protected 
from incompatible changes.
If you do not, then you are on your own.


DCB

We are talking here about executable macros, not macros that define 
control blocks.


There is
no STORAGE macro; there is address = malloc(bytes) and free(address).

And that's one reason why C is a nice application programming language and 
not so great as a z/OS system programming language. 
If all z/OS storage were one subpool, there wouldn't be a z/OS.

Peter Relson
z/OS Core Technology Design


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Charles Mills]

Well there you go, then.

FTP or IND$FILE in binary.

Read in UTF-8 and translate to UTF-16.

Process in UTF-16.

Translate report UTF-16 to UTF-8.

Download in binary.

QED

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of David W Noon
Sent: Monday, September 4, 2017 6:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF-8 woes on z/OS, a solution - comments invited

On Mon, 4 Sep 2017 17:07:08 -0700, Charles Mills (charl...@mcn.org) wrote about 
"Re: UTF-8 woes on z/OS, a solution - comments invited" (in
<02b401d325da$f0cb4d30$d261e790$@mcn.org>):

> COBOL or Java, but what about the OP's PL/I?

IBM Enterprise PL/I has WIDECHAR(*), which supports UTF-16. It also has the 
UTF8(), UTF8TOCHAR() and UTF8TOWCHAR() built-in functions that translate host 
code page to UTF-8, UTF-8 to host code page, and UTF-8 to UTF-16, respectively. 
These will probably handle UTF-8 translations more reliably than IND$FILE does.

The problem is the complexity that was previously hidden is now visibly the 
province of the programmer.
--
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[David W Noon]

On Mon, 4 Sep 2017 17:07:08 -0700, Charles Mills (charl...@mcn.org)
wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in
<02b401d325da$f0cb4d30$d261e790$@mcn.org>):

> COBOL or Java, but what about the OP's PL/I?

IBM Enterprise PL/I has WIDECHAR(*), which supports UTF-16. It also has
the UTF8(), UTF8TOCHAR() and UTF8TOWCHAR() built-in functions that
translate host code page to UTF-8, UTF-8 to host code page, and UTF-8 to
UTF-16, respectively. These will probably handle UTF-8 translations more
reliably than IND$FILE does.

The problem is the complexity that was previously hidden is now visibly
the province of the programmer.
-- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Charles Mills]

COBOL or Java, but what about the OP's PL/I?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Monday, September 4, 2017 4:00 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF-8 woes on z/OS, a solution - comments invited

Have you considered transferring it to z/OS in binary, rather than converting 
to EBCDIC. Then just process it in its UNICODE format, which either Java or 
Enterprise COBOL should be able to handle (Java by default, COBOL with 
appropriate UNICODE specifications).

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lack of Support for Doc for COBOL

[Edward Gould]

> On Sep 4, 2017, at 10:26 AM, scott Ford  wrote:
> 
> Very, considering there are literally hundreds if not thousands of shops
> still using COBOL..
> 
> 
> Scott
Amen to that Scott. At one place I worked there were on the order of 100,000+ 
(I have forgotten the exact number).
And that was in user libraries. I was curious and ran it on our link list and 
found 40.
They are still running everyday and keep working.
BTW the *oldest* COBOL program I found was from 1986.

Ed


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Walt Farrell]

Have you considered transferring it to z/OS in binary, rather than converting 
to EBCDIC. Then just process it in its UNICODE format, which either Java or 
Enterprise COBOL should be able to handle (Java by default, COBOL with 
appropriate UNICODE specifications).

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE

[Wayne Bickerdike]

SCLM supports a temp PDSE but IBM supplied default is PDS.

Found out while testing the V5 compiler when binder returned the IEW2606S
message.

On Tue, Sep 5, 2017 at 6:02 AM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:

> On Mon, 4 Sep 2017 19:27:42 +, Ze'ev Atlas wrote:
>
> >AppologyMy bug is obvious, my syslmod is a temp library Ze'ev Atlas
> >
> I believe that temporary PDSEs are supported nowadays (by z/OS, not
> necessarily by SCLM).  Would SMS rules help?
>
> > IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND
> CANNOT BE SAVED IN LOAD MODULE FORMAT.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Charles Mills]

Not the way I heard it.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, September 4, 2017 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF-8 woes on z/OS, a solution - comments invited

On Mon, 4 Sep 2017 13:17:48 -0700, Charles Mills wrote:
>
>... another vulgar cliché, ... indeed SOL ...
>
???
Simply Outa Luck?

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Paul Gilmartin]

On Mon, 4 Sep 2017 13:17:48 -0700, Charles Mills wrote:
>
>... another vulgar cliché, ... indeed SOL ...
>
???
Simply Outa Luck?

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Charles Mills]

After I read @Robert's reply to my note I was mentally composing more or less 
what @Gil writes below.

Paraphrasing the vulgar cliché, you can't put 20 bits of data in an 8-bit byte. 
Ultimately, EBCDIC is what it is, and it ain't UTF-8.

I suppose you might be able to create a custom EBCDIC code page that included 
"your" European characters -- assuming no more than thirty or so, and then 
configure z Unicode Services to handle it. Otherwise, to invoke another vulgar 
cliché, you are indeed SOL (without your homegrown, um, solution).

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Monday, September 4, 2017 12:26 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: UTF-8 woes on z/OS, a solution - comments invited

On Mon, 4 Sep 2017 20:59:12 +, Robert Prins wrote
>
>I can probably find a set of code-pages that correctly translate the 
>two byte
>UTF-8 "ü" character to a one byte EBCDIC "ü" character, but how would 
>those same two code-pages translate the Polish "ł", the Danish "ø", the 
>Baltic "ė", and the Greek "Θ", which appear in the same PC-side file to 
>one single character... And back to the correct UTF-8 character...
>
>That makes the problem maybe more understandable?
> 
If SBCS is a requirement, then if there is an EBCDIC SBCS code page that 
contains "ü", "ł", "ø", "ė", and "Θ", iconv can probably translate UTF-8 to 
that code page.  Otherwise, you're SOL.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE

[Paul Gilmartin]

On Mon, 4 Sep 2017 19:27:42 +, Ze'ev Atlas wrote:

>AppologyMy bug is obvious, my syslmod is a temp library Ze'ev Atlas
> 
I believe that temporary PDSEs are supported nowadays (by z/OS, not
necessarily by SCLM).  Would SMS rules help?

> IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND 
>CANNOT BE SAVED IN LOAD MODULE FORMAT. 

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Robert Prins]

On 2017-09-04 19:24, Paul Gilmartin wrote:
> On Mon, 4 Sep 2017 20:59:12 +, Robert Prins wrote


I can probably find a set of code-pages that correctly translate the two
byte UTF-8 "ü" character to a one byte EBCDIC "ü" character, but how would
those same two code-pages translate the Polish "ł", the Danish "ø", the
Baltic "ė", and the Greek "Θ", which appear in the same PC-side file to one
single character... And back to the correct UTF-8 character...

That makes the problem maybe more understandable?

If SBCS is a requirement, then if there is an EBCDIC SBCS code page that 
contains "ü", "ł", "ø", "ė", and "Θ", iconv can probably translate UTF-8 to

that code page.  Otherwise, you're SOL.


That's why I'm now using the code that I posted. It works, assuming the UTF-8
data is correct. If that isn't the case, then I'm SOL, and the users get what
they deserve, GIGO! ;)

Robert
--
Robert AH Prins
robert(a)prino(d)org

--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Robert Prins]

On 2017-09-04 19:24, Paul Gilmartin wrote:

On Mon, 4 Sep 2017 20:59:12 +, Robert Prins wrote


I can probably find a set of code-pages that correctly translate the two byte
UTF-8 "ü" character to a one byte EBCDIC "ü" character, but how would those same
two code-pages translate the Polish "ł", the Danish "ø", the Baltic "ė", and the
Greek "Θ", which appear in the same PC-side file to one single character... And
back to the correct UTF-8 character...

That makes the problem maybe more understandable?


If SBCS is a requirement, then if there is an EBCDIC SBCS code page that
contains "ü", "ł", "ø", "ė", and "Θ", iconv can probably translate UTF-8 to that
code page.  Otherwise, you're SOL.


That's why I'm now using the code that I posted. It works, assuming the UTF-8 
data is correct. If that isn't the case, then I'm SOL, and the users get what 
they deserve, GIGO! ;)


Robert
--
Robert AH Prins
robert(a)prino(d)org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE

[Ze'ev Atlas]

AppologyMy bug is obvious, my syslmod is a temp library Ze'ev Atlas

 IEW2606S 4B39 MODULE INCORPORATES VERSION 3 PROGRAM OBJECT FEATURES AND CANNOT 
BE SAVED IN LOAD MODULE FORMAT. 


XXSYSLMOD  DD  DSNAME=                                       IEFC653I 
SUBSTITUTION JCL - DSNAME=&(GO),DISP=(MOD,PASS),SPACE=(


   

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Paul Gilmartin]

On Mon, 4 Sep 2017 20:59:12 +, Robert Prins wrote
>
>I can probably find a set of code-pages that correctly translate the two byte
>UTF-8 "ü" character to a one byte EBCDIC "ü" character, but how would those 
>same
>two code-pages translate the Polish "ł", the Danish "ø", the Baltic "ė", and 
>the
>Greek "Θ", which appear in the same PC-side file to one single character... And
>back to the correct UTF-8 character...
>
>That makes the problem maybe more understandable?
> 
If SBCS is a requirement, then if there is an EBCDIC SBCS code page that
contains "ü", "ł", "ø", "ė", and "Θ", iconv can probably translate UTF-8 to that
code page.  Otherwise, you're SOL.

See:  https://en.wikipedia.org/wiki/Pigeonhole_principle

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Robert Prins]

On 2017-09-04 17:55, Charles Mills wrote:

I don't understand the problem.


That's correct.


Yes, ü is two bytes (not characters as you wrote!) in UTF-8.


You're correct again.

But if the translation is working correctly and the code page is specified 
correctly it should become one byte in EBCDIC, and assuming the report 
program treats it as a literal of some sort -- does not expect to deduce 
meaning from each byte -- it should be perfectly happy with S?d (pretending

? is an EBCDIC ü) as a district or whatever name. The report columns should
be correct, and it should come back to UTF-8 land as ü, with the proper
number of padding blanks.



It sounds like you are incorrectly translating ü to *two* EBCDIC characters,
and that is the root of your problem. See if you can't translate to an
EBCDIC code page that includes ü.


I can probably find a set of code-pages that correctly translate the two byte
UTF-8 "ü" character to a one byte EBCDIC "ü" character, but how would those same
two code-pages translate the Polish "ł", the Danish "ø", the Baltic "ė", and the 
Greek "Θ", which appear in the same PC-side file to one single character... And 
back to the correct UTF-8 character...


That makes the problem maybe more understandable?

Robert


Charles


-Original Message- From: IBM Mainframe Discussion List 
[mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Robert Prins Sent: Monday, 
September 4, 2017 12:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: UTF-8 woes 
on z/OS, a solution - comments invited


OK, I solved the problem, but maybe someone here can come up with something
a bit more efficient...

There is a file in the non-z/OS world, that used to be pure ASCII (actually 
CP437/850), but that has now been converted to UTF-8, due to further 
internationalisation requirements. Said file was uploaded to z/OS, processed 
into a set of datasets containing various reports, and those reports were 
later downloaded to the non-z/OS world, using the same process that was used 
to upload them, which could be one of two, IND$FILE, or FTP.


Both FTP and IND$FILE uploads had (and still have) no problems with 
CP437/850/UTF-8 data, and although an ü might not have displayed as such on 
z/OS, it would have transferred back to the same ü. However, an ü in UTF-8 
now consists of two characters, and that means that, replacing spaces with 
'=' characters, the original


|=Süd| |=Nord===|

report lines now come out as

|=Süd===| |=Nord===|

when opened in the non z/OS world with an UTF-8 aware application.

-- For 
IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu with the message: INFO IBM-MAIN





--
Robert AH Prins
robert(a)prino(d)org

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: UTF-8 woes on z/OS, a solution - comments invited

[Charles Mills]

I don't understand the problem. 

Yes, ü is two bytes (not characters as you wrote!) in UTF-8. But if the 
translation is working correctly and the code page is specified correctly it 
should become one byte in EBCDIC, and assuming the report program treats it as 
a literal of some sort -- does not expect to deduce meaning from each byte -- 
it should be perfectly happy with S?d (pretending ? is an EBCDIC ü) as a 
district or whatever name. The report columns should be correct, and it should 
come back to UTF-8 land as ü, with the proper number of padding blanks.

It sounds like you are incorrectly translating ü to *two* EBCDIC characters, 
and that is the root of your problem. See if you can't translate to an EBCDIC 
code page that includes ü.

Charles


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Robert Prins
Sent: Monday, September 4, 2017 12:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: UTF-8 woes on z/OS, a solution - comments invited

OK, I solved the problem, but maybe someone here can come up with something a 
bit more efficient...

There is a file in the non-z/OS world, that used to be pure ASCII (actually 
CP437/850), but that has now been converted to UTF-8, due to further 
internationalisation requirements. Said file was uploaded to z/OS, processed 
into a set of datasets containing various reports, and those reports were later 
downloaded to the non-z/OS world, using the same process that was used to 
upload them, which could be one of two, IND$FILE, or FTP.

Both FTP and IND$FILE uploads had (and still have) no problems with
CP437/850/UTF-8 data, and although an ü might not have displayed as such on 
z/OS, it would have transferred back to the same ü. However, an ü in UTF-8 now 
consists of two characters, and that means that, replacing spaces with '=' 
characters, the original

|=Süd|
|=Nord===|

report lines now come out as

|=Süd===|
|=Nord===|

when opened in the non z/OS world with an UTF-8 aware application.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

UTF-8 woes on z/OS, a solution - comments invited

[Robert Prins]

OK, I solved the problem, but maybe someone here can come up with something a 
bit more efficient...


There is a file in the non-z/OS world, that used to be pure ASCII (actually 
CP437/850), but that has now been converted to UTF-8, due to further 
internationalisation requirements. Said file was uploaded to z/OS, processed 
into a set of datasets containing various reports, and those reports were later 
downloaded to the non-z/OS world, using the same process that was used to upload 
them, which could be one of two, IND$FILE, or FTP.


Both FTP and IND$FILE uploads had (and still have) no problems with 
CP437/850/UTF-8 data, and although an ü might not have displayed as such on 
z/OS, it would have transferred back to the same ü. However, an ü in UTF-8 now 
consists of two characters, and that means that, replacing spaces with '=' 
characters, the original


|=Süd|
|=Nord===|

report lines now come out as

|=Süd===|
|=Nord===|

when opened in the non z/OS world with an UTF-8 aware application.

Given that, and in this case I was lucky, the PC file had the option to add 
comment-type lines, I solved the problem (the z/OS dataset is processed with 
PL/I) by adding an extra line to the input file of the required comment 
delimiter followed by "ASCII " followed by the 240 ASCII characters from '20'x 
to 'ff'x. The PL/I program uses this "special meta-data comment" to transform 
the input data, which has been translated by IND$FILE/FTP to EBCDIC back into a 
format where all UTF-8 initial characters are translated to '1' and all UTF-8 
follow-on bytes to '0', i.e.


dcl ascii char (240); /* containing the 240 characters from '20'x to 'ff'x, read 
in via an additional comment record in the original non-z/OS file */

dcl utf8  char (240) init (('' ||
'' ||
'' ||
'' ||
'' ||
'0011' ||
'1000'));

and to get the number of UTF-8 displayable characters of, e.g. myvar, a char(47) 
variable, I use the following


dcl a47(47) pic '9';
dcl morechar (20) var;

string(a47) = translate(myvar, utf8, ascii);
more= copy(' ', 47 - sum(a47));

where "more" is the number of extra blanks that needs to be added into the 
report column to ensure that the columns line-out again in the non-z/OS UTF-8 
world. The (relative) beauty of this approach lies in the fact that the 
technique is completely code-page independent, and could even be used with the 
PL/I compiler on Windows.


The above works like a charm, however, both translate() and sum(), especially of 
pic '9' data, are not exactly the most efficient functions, so the question is, 
can anyone think of a more efficient way, other than the quick(?) and dirty 
solution of using a macro on the non-z/OS side, to set "more" the the required 
number of characters. I'm open to a PL/I callable assembler routine, but the 
process must be, like the one above, completely code-page independent!


Robert
--
Robert AH Prins
robert.ah.prins(a)gmail.com

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lack of Support for Doc for COBOL

[Farley, Peter x23353]

"... continuous documentation delivery ..."  Huh.  Didn't we used to have that 
with a few little things IBM called TNL's?

For hardcover textbooks they issue "Errata" texts on the bookseller or author's 
website(s).  IBM could do that much, but choose not to.  Not sad but dumb, IMHO.

Peter

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of scott Ford
Sent: Monday, September 04, 2017 11:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Lack of Support for Doc for COBOL

Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott

On Fri, Sep 1, 2017 at 9:55 AM Charles Mills  wrote:

> Sad.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: Friday, September 1, 2017 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Lack of Support for Doc for COBOL
>
> COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
> dates.
>
> So here is a response to a document error that was acknowledged as being
> valid:
>
> --
>
> Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
> should be none, and SEP|NOSEP should be the abbreviations for the TEST
> suboptions SEPARATE|NOSEPARATE.
>
> However, we do not update the COBOL V4.2 documentation any longer. We now
> support continuous documentation delivery for COBOL V6.1 and V5.2 only.
>
> Sorry for the inconveniences caused. Let us know if you have further
> questions.
>
> Thanks,
> Dana Zhang 张丹
>
> COBOL Information Developer, PMP
> DevOps Systems ID, China Development Lab, IBM
>
> --
>
> The manual has not been updated since “Second Edition (August 2009)”. So
> one wonders how many errors in the doc have been reported that were not
> applied to this manual.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

This message and any attachments are intended only for the use of the addressee 
and may contain information that is privileged and confidential. If the reader 
of the message is not the intended recipient or an authorized representative of 
the intended recipient, you are hereby notified that any dissemination of this 
communication is strictly prohibited. If you have received this communication 
in error, please notify us immediately by e-mail and delete the message and any 
attachments from your system.


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: zFS Growth and effect on applications in z/OS

[Ed Jaffe]

On 9/3/2017 7:33 PM, Lizette Koehler wrote:

1) what is the impact of dynamic growth on zFS users?
  a) Does it cause an application to fail during growth


We use zFS for our corporate SMB server and git repositories.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.ioea700/ioea7d0041006636.htm 
states, "The aggregate is extended when an operation cannot complete 
because the aggregate is full. If the extension is successful, the 
operation is again transparently driven to the application." Not the 
best English in the world there  but, they're obviously attempting 
to say the operation is automatically retried without application 
involvement and that has been my observation.


However, applications that ask for file system stats are given an answer 
without being suspended. (Can't imagine how/why zFS should do anything 
different there.)


Therefore, a "clever" application *could* report an "out of space" 
condition if it thinks there is not enough free space remaining. I have 
seen this from a few older Windows applications (VSS I think?), but 
never from things like ftp or sftp.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Lack of Support for Doc for COBOL

[scott Ford]

Very, considering there are literally hundreds if not thousands of shops
still using COBOL..


Scott

On Fri, Sep 1, 2017 at 9:55 AM Charles Mills  wrote:

> Sad.
>
> Charles
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Steve Thompson
> Sent: Friday, September 1, 2017 5:22 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Lack of Support for Doc for COBOL
>
> COBOL 4.2 is still supported, and orderable. There are no posted EOM or EOS
> dates.
>
> So here is a response to a document error that was acknowledged as being
> valid:
>
> --
>
> Thanks for your comment. You are correct: abbreviation for TEST|NOTEST
> should be none, and SEP|NOSEP should be the abbreviations for the TEST
> suboptions SEPARATE|NOSEPARATE.
>
> However, we do not update the COBOL V4.2 documentation any longer. We now
> support continuous documentation delivery for COBOL V6.1 and V5.2 only.
>
> Sorry for the inconveniences caused. Let us know if you have further
> questions.
>
> Thanks,
> Dana Zhang 张丹
>
> COBOL Information Developer, PMP
> DevOps Systems ID, China Development Lab, IBM
>
> --
>
> The manual has not been updated since “Second Edition (August 2009)”. So
> one wonders how many errors in the doc have been reported that were not
> applied to this manual.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Scott Ford
IDMWORKS
z/OS Development

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: I am getting IEW2606S in HEWL despite the fact that the target library IS PDSE

[Paul Gilmartin]

On Mon, 4 Sep 2017 15:50:28 +1000, Wayne Bickerdike wrote:

>Dave has identified the problem. SYSLMOD needs DSNTYPE=LIBRARY.
>
>If you use SCLM, the supplied linkedit language definition also lacks
>DSNTYPE=LIBRARY.
>
>IBM are a bit amiss here because SCLM uses an intermediate load library to
>copy the resultant load module and this defaults to a PDS.
>
>Took me a few days to work this out.
> 
"... a bit amiss ..." ==> SR, IMO.

But SCLM users haven't cared.  And IBM doesn't care about costing
customers "a few days", each.

If IBM deems program object support in SCLM RFE-worthy, then shame on IBM.

-- gil

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN