Discussion:
ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!
(too old to reply)
Farley, Peter x23353
2014-09-25 15:43:48 UTC
Permalink
Raw Message
Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents).

Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected.

Edit a new PDS member in ASCII or UTF-8 mode (HEX ON to show actual characters) and you get this, which is good and what you would expect to see:

EDIT TDPEFAR.CBT391.XPDFTEXT(TEMP) - 01.00 Columns 00001 00072
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
000001 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-=
576777766724766666662576766623333333333232222222222222222222222222222222
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
000002 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-=
576777766724766666662576766623333333333232222222222222222222222222222222
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------

However, edit an existing ASCII or UTF-8 member and you get this, which is unexpected and IMHO wrong:

EDIT TSOUSER.RECFMV.TEXTFILE (TEST) - 01.02 Columns 00001 00072
Command ===> Scroll ===> CSR
000318 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-= @@@@@@@@@@@@@@@@@@@@@@@
576777766724766666662576766623333333333232222222244444444444444444444444
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
000319 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
444444444444444444444444444444444444444444444444444444444444444444444444
000000000000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------
000320 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-= @@@@@@@@@@@@@@@@@@@@@@@@
576777766724766666662576766623333333333232222222444444444444444444444444
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------

Am I wrong to expect that editing or viewing an existing file or member in ASCII or UTF-8 mode should consistently use the ASCII/UTF-8 space character X'20'?

Peter

P.S. - This is on a z/OS V2.1 system.
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
p***@gmail.com
2014-09-25 15:56:38 UTC
Permalink
Raw Message
I found the same problem just this week. I think you are correct in you assumption.

John
Post by Farley, Peter x23353
Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents).
Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected.
EDIT TDPEFAR.CBT391.XPDFTEXT(TEMP) - 01.00 Columns 00001 00072
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
000001 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-=
576777766724766666662576766623333333333232222222222222222222222222222222
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
000002 Qwertyuiop Asdfghjkl Zxcvbnm 1234567890-=
576777766724766666662576766623333333333232222222222222222222222222222222
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
EDIT TSOUSER.RECFMV.TEXTFILE (TEST) - 01.02 Columns 00001 00072
Command ===> Scroll ===> CSR
576777766724766666662576766623333333333232222222244444444444444444444444
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
444444444444444444444444444444444444444444444444444444444444444444444444
000000000000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------
576777766724766666662576766623333333333232222222444444444444444444444444
17524959F00134678ABC0A8362ED01234567890DD0000000000000000000000000000000
------------------------------------------------------------------------------
Am I wrong to expect that editing or viewing an existing file or member in ASCII or UTF-8 mode should consistently use the ASCII/UTF-8 space character X'20'?
Peter
P.S. - This is on a z/OS V2.1 system.
--
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,
Paul Gilmartin
2014-09-25 16:46:14 UTC
Permalink
Raw Message
Post by Farley, Peter x23353
Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents).
Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected.
...
Am I wrong to expect that editing or viewing an existing file or member in ASCII or UTF-8 mode should consistently use the ASCII/UTF-8 space character X'20'?
P.S. - This is on a z/OS V2.1 system.
ISPF Edit is stupid and obsessive concerning trailing spaces. AFAIK, there's no way
to add trailing spaces to a record, nor to remove some but not all of them. I'm
dismayed but not surprised with what you observe. The hex display should
distinguish between blanks present in the line and the area beyond the end of
the line. Browse does this well: blanks appear as '40'; nonexistent characters
as blank space in the hex display.

BTW, how do non-ASCII UTF-8 characters, code points above 0xFF, appear in the
hex display? Does ISPF add a third or fourth line of hex as needed?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Gilmore
2014-09-25 17:28:25 UTC
Permalink
Raw Message
Why do I feel the need to defend things like ISPF too often here?

The ISPF editor makes a nulls mode available; it provides for optional
warning messages when blanks are truncated; etc., etc.

In general, it is much more parametric, both globally and for
individual users, than this discussion has so far suggested.

Moreover, there are elaborate facilities made available for supplying
and using exits than can modify its behavior.

It is an old, cosmetically ugly beast; and in many but not all
situations there are better alternatives to it available. It is not
nearly so bad as it is being represented as being.

Are we perhaps dealing here yet again with atrophied skill sets? With
people who no longer know how to use the facilities that IBM makes
available to them? With systems programmers who are non-programmers?

John Gilmore, Ashland, MA 01721 - USA

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2014-09-25 18:23:52 UTC
Permalink
Raw Message
John,

AFAIK, only system programmers can set up ISPF exits, and I am not a sysprog.

The use of EBCDIC X'40' characters for trailing (non-existent) spaces in a putatively ASCII/UTF-8 edit or view display is both jarring and wrong.

I did have NULLS ON in the displays I showed, but those were existing lines of text transmitted to z/OS from elsewhere. It is not the entering of data which is the issue here, but the display of existing data.

I am not particularly against the ISPF editor function; in fact it has facilities I sorely miss when using other platform editors. But this behavior is not acceptable.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Gilmore
Sent: Thursday, September 25, 2014 1:28 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!

Why do I feel the need to defend things like ISPF too often here?

The ISPF editor makes a nulls mode available; it provides for optional
warning messages when blanks are truncated; etc., etc.

In general, it is much more parametric, both globally and for
individual users, than this discussion has so far suggested.

Moreover, there are elaborate facilities made available for supplying
and using exits than can modify its behavior.

It is an old, cosmetically ugly beast; and in many but not all
situations there are better alternatives to it available. It is not
nearly so bad as it is being represented as being.

Are we perhaps dealing here yet again with atrophied skill sets? With
people who no longer know how to use the facilities that IBM makes
available to them? With systems programmers who are non-programmers?

--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
shmuel+ (Shmuel Metz , Seymour J.)
2014-09-28 18:25:03 UTC
Permalink
Raw Message
In
<CAE1XxDE81Zg7OKq=***@mail.gmail.com>,
on 09/25/2014
Post by John Gilmore
Why do I feel the need to defend things like ISPF too often here?
Only your shrink knows for sure. While it is certainly true that many
complaints about ISPF were ill founded, there have also been
legitimate complains, and failing to correctly translate spaces is
clearly not correct behavior.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2014-09-25 18:15:47 UTC
Permalink
Raw Message
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, September 25, 2014 12:46 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!

<Snipped>

BTW, how do non-ASCII UTF-8 characters, code points above 0xFF, appear in the
hex display? Does ISPF add a third or fourth line of hex as needed?

No, all on the same line as additional characters, like this for the British pound symbol followed by the digit 1 and a space:

£1
CA32
2310

Or this for a capital letter B followed by the dagger character and a space:

B
4E8A2
22000

Peter
--


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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Gould
2014-09-25 21:31:29 UTC
Permalink
Raw Message
Post by Paul Gilmartin
ISPF Edit is stupid and obsessive concerning trailing spaces.
AFAIK, there's no way
to add trailing spaces to a record, nor to remove some but not all of them. I'm
dismayed but not surprised with what you observe. The hex display should
distinguish between blanks present in the line and the area beyond the end of
the line. Browse does this well: blanks appear as '40';
nonexistent characters
as blank space in the hex display.
Paul,
Maybe because I have leaned to love it (ISPF edit) I have gotten used
to its restrictions.
btw you can lengthen VB (ie clist) files quite easily example: ch
dsn dsname
Or I suppose ch dsname to dsn
Adding blanks (t the end is a little hard) but IIRC it can be done
I don't have a system on to try it but in the past I have done it
more than a few time all you have to is sit and think like ISPF and
the HW and TSO.

Ed

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2014-09-25 18:40:28 UTC
Permalink
Raw Message
A further discovery - Using the "EA" (Edit ASCII) command from the UDLIST display of a Unix File System directory of a copy of exactly the same data does NOT use X'40' for trailing (non-existent) spaces, but the expected X'20' instead.

So the behavior seems to relate to the file system source of the data; from "classic" MVS-type files the unexpected X'40' is used, from HFS/ZFS directories the expected X'20' is used.

Possibly fixable, possibly (B/W)AD. If someone who has authority to report bugs wishes to make a report, it would be interesting to hear IBM's response.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Farley, Peter x23353
Sent: Thursday, September 25, 2014 11:43 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: ASCII/UTF-8 Edit and View existing file use X'40' for trailing spaces on screen?!?!

Discovered this unpleasant fact today: Editing or Viewing an existing RECFM=VB UTF-8 file or PDS(E) member uses X'40' for the trailing spaces on screen (i.e., the part of each record past the end of the actual record contents).

Editing a new file or PDS(E) member using ASCII or UTF-8 mode uses X'20' for spaces as expected.
<Snipped>

--

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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
j***@googlemail.com
2018-03-01 10:08:10 UTC
Permalink
Raw Message
This bug is still there....

Loading...