Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

OMVS CP command anomaly

65 views
Skip to first unread message

Lionel B Dyck

unread,
Jul 27, 2020, 2:48:33 PM7/27/20
to
Here is the anomaly.



Created several ISPF panels from DTL. The result is an ISPF panel with
attribute characters that are binary (hex) with examples being x'01' ,
x'02', x'05, x'0D', and more.



Copying these PDS members to an OMVS filesystem using cp works fine. The
data is NOT being copied as binary.



The problem/anomaly is copying the files from OMVS into z/OS dataset members
results in these members being corrupted with the single record being
broken into one, or more, records.



Example: cp -A -U -v' rdir/*) "'"zos'"'



Any advice?



Thanks



Lionel B. Dyck <sdg><
Website: <https://www.lbdsoftware.com> https://www.lbdsoftware.com

"Worry more about your character than your reputation. Character is what
you are, reputation merely what others think you are." - John Wooden




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

Paul Gilmartin

unread,
Jul 27, 2020, 4:40:30 PM7/27/20
to
On Mon, 27 Jul 2020 13:48:21 -0500, Lionel B Dyck wrote:
>
>Created several ISPF panels from DTL. The result is an ISPF panel with
>attribute characters that are binary (hex) with examples being x'01' ,
>x'02', x'05, x'0D', and more.
>
>Copying these PDS members to an OMVS filesystem using cp works fine. The
>data is NOT being copied as binary.
>
I'd prefer binary (cp -B) for data containing nondisplayable characters.
>
>The problem/anomaly is copying the files from OMVS into z/OS dataset members
>results in these members being corrupted with the single record being
>broken into one, or more, records.
>
>Example: cp -A -U -v' rdir/*) "'"zos'"'
>
Which code points cause problems?

Do you intend to manipulate (Edit, Browse, ...) the OMVS files?

-- gil

Lionel B Dyck

unread,
Jul 27, 2020, 4:50:09 PM7/27/20
to
Example of the issue:

ISPF Panel code:

)ATTR
0D TYPE(PS)
05 TYPE(PS)
. . .
)BODY

Ideally would like a workstation IDE user to be able to view the data and perhaps update it and at some point return to z/OS for use.


Lionel B. Dyck <sdg><
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden

Itschak Mugzach

unread,
Jul 27, 2020, 5:00:33 PM7/27/20
to
what does it look like after copying from USS to PDS?

*| **Itschak Mugzach | Director | SecuriTeam Software **|** IronSphere
Platform* *|* *Information Security Continuous Monitoring for Z/OS, zLinux
and IBM I **| *

*|* *Email**: i_mu...@securiteam.co.il **|* *Mob**: +972 522 986404 **|*
*Skype**: ItschakMugzach **|* *Web**: www.Securiteam.co.il **|*

Paul Gilmartin

unread,
Jul 27, 2020, 5:46:37 PM7/27/20
to
On Mon, 27 Jul 2020 15:49:52 -0500, Lionel B Dyck wrote:

>Example of the issue:
>
>ISPF Panel code:
>
>)ATTR
> 0D TYPE(PS)
> 05 TYPE(PS)
>. . .
>)BODY
>
>Ideally would like a workstation IDE user to be able to view the data and perhaps update it and at some point return to z/OS for use.
>
This depends on the workstation users' having editors that
can deal with nondisplayable characters.

Aggravated by ASCII<=>EBCDIC.

I suppose that since ISPF supports hex editing, it was a natural
design choice to rely on nondisplayable characters in ISPF panel
definitions.

Using an ISPF look-alike on the workstation hardly solves the problem.

Andrew Rowley

unread,
Jul 27, 2020, 8:08:05 PM7/27/20
to
On 28/07/2020 4:48 am, Lionel B Dyck wrote:
> Created several ISPF panels from DTL. The result is an ISPF panel with
> attribute characters that are binary (hex) with examples being x'01' ,
> x'02', x'05, x'0D', and more.
>
> Copying these PDS members to an OMVS filesystem using cp works fine. The
> data is NOT being copied as binary.
>
> The problem/anomaly is copying the files from OMVS into z/OS dataset members
> results in these members being corrupted with the single record being
> broken into one, or more, records.
The most likely problem is that when you copy from dataset to file, line
end characters are being inserted at the end of every record. When you
copy back, line end characters are used to break the data back into
records, but the same character(s) exist in your panel definitions. Cp
cannot tell whether it is an inserted line end character or part of your
data.

Copying binary data as text is not guaranteed to give the correct result
after a round-trip. Depending on the data it can be almost correct or
even usually correct, but there is always a risk unless you can
guarantee that the line end characters do not exist in your data.

Options:
- Maybe cp has an option where it doesn't insert/remove line endings
e.g. like IND$FILE file transfer has separate options for binary and
CRLF. The data would look like one long record, apart form the
incidental line end characters in your data. This is likely to cause
problems for git in displaying data, merging etc. (assuming this is for
Zigi).
- Copy as binary. The best-simplest option, however it would also cause
merge etc. problems
- Use an escape character scheme for binary characters e.g. quoted
printable. This adds a processing step - you can't use regular cp
command - but it gives you data in git that is mergable and mostly
readable as text.

--
Andrew Rowley
Black Hill Software

Paul Gilmartin

unread,
Jul 28, 2020, 12:20:08 PM7/28/20
to
On Tue, 28 Jul 2020 10:07:50 +1000, Andrew Rowley wrote:

>On 28/07/2020 4:48 am, Lionel B Dyck wrote:
>> Created several ISPF panels from DTL. The result is an ISPF panel with
>> attribute characters that are binary (hex) with examples being x'01' ,
>> x'02', x'05, x'0D', and more.
>> ...
>> The problem/anomaly is copying the files from OMVS into z/OS dataset members
>> results in these members being corrupted with the single record being
>> broken into one, or more, records. ...
>
>Copying binary data as text is not guaranteed to give the correct result
>after a round-trip. ...
>
>Options:
>- ...
>- Copy as binary. The best-simplest option, however it would also cause
>merge etc. problems
>- Use an escape character scheme for binary characters e.g. quoted
>printable. This adds a processing step - you can't use regular cp
>command - but it gives you data in git that is mergable and mostly
>readable as text.
>
Doesn't ISPF support panel definitions coded in Rexx? Rexx would
allow representing those nondisplayable characters as hexadecimal
strings.

It would be wonderful if ISPF supported UNIX directories in the
ISPPLIB (and other) concatenations as described in Using Data
Sets, eliminating the need for the back-and-forth copying. RFE?

There are workstation ISPF lookalikes. How portable are panel
definitions to those?

-- gil

Lionel B Dyck

unread,
Jul 28, 2020, 12:33:31 PM7/28/20
to
The problem is the x'0D' and x'15' characters which were generated from DTL. They copy (cp) fine from z/OS to OMVS but the copy back causes the data after either of those characters to go to a new record.

The solution is for the DTL developers to use the ISRDTLCV after they generate the panel.

Lionel B. Dyck <sdg><
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation. Character is what you are, reputation merely what others think you are." - John Wooden

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-...@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Tuesday, July 28, 2020 11:20 AM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

Paul Gilmartin

unread,
Jul 28, 2020, 12:50:04 PM7/28/20
to
On Tue, 28 Jul 2020 11:33:18 -0500, Lionel B Dyck wrote:
>
>The solution is for the DTL developers to use the ISRDTLCV after they generate the panel.
>
In II13067 I see the alarming language, "...attempts to ... Only unused characters
will be used."

IBM could have done better. If IBM cared.

Seymour J Metz

unread,
Jul 28, 2020, 1:08:50 PM7/28/20
to
I know how to code processing logic within a panel in REXX, but I'm not aware of any way to generate panel statements in REXX.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Tuesday, July 28, 2020 12:19 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

Seymour J Metz

unread,
Jul 28, 2020, 1:46:28 PM7/28/20
to
Different vendors had different degrees of compatibility. The few times I had a compatibility issue with TSPF, Tritus fixed it. CTC disn't seem to consider incompatibility to be important.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Tuesday, July 28, 2020 12:19 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

Seymour J Metz

unread,
Jul 28, 2020, 1:49:38 PM7/28/20
to
RFE.

Meanwhile, either don't use Eunix file to store panels or edit them first to replace CR, LF and NL (0A, 0D and 15) with something else.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Lionel B Dyck [lbd...@GMAIL.COM]
Sent: Monday, July 27, 2020 2:48 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: OMVS CP command anomaly

Here is the anomaly.



Created several ISPF panels from DTL. The result is an ISPF panel with
attribute characters that are binary (hex) with examples being x'01' ,
x'02', x'05, x'0D', and more.



Copying these PDS members to an OMVS filesystem using cp works fine. The
data is NOT being copied as binary.



The problem/anomaly is copying the files from OMVS into z/OS dataset members
results in these members being corrupted with the single record being
broken into one, or more, records.



Example: cp -A -U -v' rdir/*) "'"zos'"'



Any advice?



Thanks



Lionel B. Dyck <sdg><
Website: <https://secure-web.cisco.com/143mQQzEcxCxgC8V8eR3KnfsIcTqIWRZAWgo8H1JiOpfDT_Ub38XVhWULdaeykuPTeKQeZIGJ3nAXW6rjzIZ_o4iEoPKobmaPlgYlzMsYxGzdOKaq7FLOaT7cuw9bQ4i1OKZadZdPpA55_btGuBSwxiMlSbSe7e5GSiTBNaEDnYGqt4NpzTx29alb3_gFlEZC2u3BH6x-FrmQcDeod9z-L4SdKEgg-l-1VJCJ7_je35jD5PUYtSb3R7t1yqVYfjQWdDeXb4rJKj5PWRSqI3cxWIb0Yzg2fRq1QZ2htV41CS6c3hi8D6TdAnbLS5mMq-AEvvpHzu9uhRdK-1OJv_HPQJa-yKgkXjgUjqHQ8WP2SWejxC_UTaQRfgQ17U_Ab7bnG88UHzL9vaJoVwL2oBAku8t8g12EJxKSoiLGggI-k0fULiSk0R7ZtflBLbt6z_2T/https%3A%2F%2Fwww.lbdsoftware.com> https://secure-web.cisco.com/143mQQzEcxCxgC8V8eR3KnfsIcTqIWRZAWgo8H1JiOpfDT_Ub38XVhWULdaeykuPTeKQeZIGJ3nAXW6rjzIZ_o4iEoPKobmaPlgYlzMsYxGzdOKaq7FLOaT7cuw9bQ4i1OKZadZdPpA55_btGuBSwxiMlSbSe7e5GSiTBNaEDnYGqt4NpzTx29alb3_gFlEZC2u3BH6x-FrmQcDeod9z-L4SdKEgg-l-1VJCJ7_je35jD5PUYtSb3R7t1yqVYfjQWdDeXb4rJKj5PWRSqI3cxWIb0Yzg2fRq1QZ2htV41CS6c3hi8D6TdAnbLS5mMq-AEvvpHzu9uhRdK-1OJv_HPQJa-yKgkXjgUjqHQ8WP2SWejxC_UTaQRfgQ17U_Ab7bnG88UHzL9vaJoVwL2oBAku8t8g12EJxKSoiLGggI-k0fULiSk0R!
7ZtflBLbt6z_2T/https%3A%2F%2Fwww.lbdsoftware.com

Paul Gilmartin

unread,
Jul 28, 2020, 3:03:19 PM7/28/20
to
On Tue, 28 Jul 2020 11:33:18 -0500, Lionel B Dyck wrote:

>The problem is the x'0D' and x'15' characters which were generated from DTL. They copy (cp) fine from z/OS to OMVS but the copy back causes the data after either of those characters to go to a new record.
>
I'm inclined to regard the output of a language translator or generator
such as DTL as a binary object akin to SYSPUNCH/SYSLIN, subject to
editing only at the user's own risk.

For storing binary objects (other than program objects) in zFS is
FILEDATA=RECORD. That is transparent to and supported by
utilities such as IEBGENER. ISPF Edit seems savvy to RECORD,
but I've made only a cursory try. I don't know that ISPF with
RECORD preserves trailing blanks.

I doubt that OCOPY, OGET, OPUT, or /bin/cp supports
FILEDATA=RECORD.

How does git/zigi deal with executables/program objects?

>The solution is for the DTL developers to use the ISRDTLCV after they generate the panel.
>
... subject to its own limitations.

-- gil

Seymour J Metz

unread,
Jul 28, 2020, 3:35:10 PM7/28/20
to
Will ISPF correctly process a panel contianing 0A, 0D and 15 if it has FILEDATA=RECORD?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Tuesday, July 28, 2020 3:03 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

Paul Gilmartin

unread,
Jul 28, 2020, 3:50:00 PM7/28/20
to
On Tue, 28 Jul 2020 19:34:53 +0000, Seymour J Metz wrote:

>Will ISPF correctly process a panel contianing 0A, 0D and 15 if it has FILEDATA=RECORD?
>
FILEDATATA=RECORD has a requisite of PATH=...

Will ISPF correctly process a panel from an ISPPLIB catenand specified
with PATH=?

Seymour J Metz

unread,
Jul 28, 2020, 7:12:08 PM7/28/20
to
If not, why did Lionel store it in one?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List [IBM-...@LISTSERV.UA.EDU] on behalf of Paul Gilmartin [0000000433f0781...@LISTSERV.UA.EDU]
Sent: Tuesday, July 28, 2020 3:49 PM
To: IBM-...@LISTSERV.UA.EDU
Subject: Re: OMVS CP command anomaly

David Crayford

unread,
Jul 29, 2020, 12:13:24 AM7/29/20
to
On 2020-07-29 3:03 AM, Paul Gilmartin wrote:
>> The problem is the x'0D' and x'15' characters which were generated from DTL. They copy (cp) fine from z/OS to OMVS but the copy back causes the data after either of those characters to go to a new record.
>>
> I'm inclined to regard the output of a language translator or generator
> such as DTL as a binary object akin to SYSPUNCH/SYSLIN, subject to
> editing only at the user's own risk.

I'm in 100% agreement with Paul. We only store DTL source in Git not the
generated objects. Git is for source code.
0 new messages