英文:
How to use CP to copy variable length datasets and pds members?
问题
我一直在尝试在OMVS下使用cp命令将z/OS数据集复制到OMVS文件中，复制到OMVS似乎可以工作，但是复制回z/OS时出现严重错误，多个记录被合并。
我没有看到任何支持可变长度记录的cp选项。
目前我还没有可用的dsfs。
帮忙（请）
英文:
I've been trying to use cp under OMVS to copy z/OS datasets into OMVS files and the copy to OMVS seems to work but the copy back to z/OS fails miserably with multiple records combined.
I don't see any cp option to support variable length records.
I don't have dsfs available yet.
Help (please)
答案1
得分: 3
UNIX文件是字节流而不是记录组织的。一旦将数据复制到UNIX文件中，所有关于记录边界的信息都会丢失。因此，当将UNIX文件复制到某个MVS数据集时，z/OS UNIX没有关于在何处将字节流拆分成记录的信息，除了数据集的逻辑记录长度（LRECL）。
有一个例外情况：“文本”文件。在文本文件中，行由换行字符或字符分隔。将这样的文件复制到MVS数据集时，将去除换行字符，并且每个换行字符后都会开始一个新记录。
cp命令有一些选项，可以告诉它，要处理什么类型的数据，以及如果适用，要使用什么类型的换行字符在UNIX文件一侧使用。
英文:
UNIX files are byte stream not record organized. Once you copy data into a UNIX file, all information on record boundaries is lost. Therefore, when you copy a UNIX file to some MVS data set, z/OS UNIX has no information on where to split the byte stream into records, except from the data set's logical record length (LRECL).
There is one exception: "text" files. In text files, lines are delimited by an end-of-line character or characters. When copying such a file to an MVS data set, the end-of-line character(s) are stripped, and a new record is started by each.
There are options to the cp command to tell is, what kind of data, and if applicable, whar kind of end-of-line character(s) to use on the UNIX file side.
答案2
得分: 2
以下是翻译好的部分：
"让我们尝试一些测试和假设。所以我将创建一个数据集 VB1.DATA，格式为 RECFM=VB，LRECL=100，并添加一些记录如下：
现在我可以使用 OMVS 复制它到一个新的 USS 文件，然后查看字节：
你可以看到，cp 添加了 x'15' 字节来标记可变长度行的结尾。当然，ISPF 编辑在 ishell 下知道 x'15' 字节，USS 文件的数据看起来就像原始源代码，尽管文件末尾有额外的 15（这在 x86 Linux 中不是这样的）
所以如果我把它复制回 MVS，会为我创建一个新的 VB 数据集。系统决定 LRECL=1028，但这对我们来说没有问题。
然后，新的 VB2.DATA 与原始的 VB1.DATA 完全匹配。所以我没有看到问题。然而...
所以让我们更改 MVS 源文件 VB1.DATA 中的一行，并添加一个十六进制零，比如下面的第二行：
然后 cp 和 od 来显示：
等一下，我看到了零，但我们的 x'15' 换行符发生了什么？零显然使 cp 认为数据是“二进制”的，并消除了 x'15' 换行符。
所以让我们复制回 MVS，结果是一个混乱的消息，我认为这与 Lionel 描述的“多个记录合并”相匹配。
因此，如果我的示例与 Lionel 的问题有关，我的理论是：
- Lionel 的问题不是由 cp USS 到 MVS 引起的，而是由 cp MVS 到 USS 引起的。
- Lionel 没有在 cp 命令上使用 -B、-X、-T 或 -F 参数，根据文档，这些参数表示“如果不指定 -F|B|T 或 X，则 cp 将首先检查指定的 MVS 数据集的格式，然后尝试确定文件类型。”
- 这种自动格式决策似乎是基于文件中是否有 x'00'，至少在我的快速测试中是这样。
所以如果我复制带有 x'00' 的文件到 USS 并指定 -T 选项：
... x'15' 字节又回来了，x'00' 当然还在那里。所以让我们使用相同的 -T 选项将其复制回 MVS，以便 x'15' 字节引起分开的记录：
而且数据就像刚开始一样，包括 x'00'
现在让我们将 MVS 源文件中的 x'00' 更改为 x'15'，然后经过相同的过程。我们最终得到：
那显然是一个全新的问题，就像 phunsoft 说的那样，这意味着二进制和文本并不总是能够混合。但看起来，MVS 和 USS 之间的 cp 逻辑的设计者尽力而为。"
英文:
Let's try some tests and assumptions. So I'll create dataset VB1.DATA as RECFM=VB LRECL=100 and add a few records like this:
TED013.VB1.DATA Columns 00001 00072
Command ===> Scroll ===> CSR
****** ***************************** Top of Data ******************************
000001 1111
000002 22222222
000003 333333333333
****** **************************** Bottom of Data ****************************
Now I can use OMVS and copy that to a new USS file, and then examine the bytes:
cp "//vb1.data" vb1.data
od -x vb1.data
0000000000 F1F1 F1F1 15F2 F2F2 F2F2 F2F2 F215 F3F3
0000000020 F3F3 F3F3 F3F3 F3F3 F3F3 1500
You can see where cp added x'15' bytes to mark the ends of the variable length lines. And of course ISPF edit under ishell knows about the x'15' bytes and the USS file data looks just like the original source, despite the extra 15 at the end of the file (which is not the case in x86 Linux)
/u/TED013/vb1.data Columns 00001 00072
Command ===> Scroll ===> PAGE
****** ***************************** Top of Data ******************************
000001 1111
000002 22222222
000003 333333333333
****** **************************** Bottom of Data ****************************
So if I cp that back to MVS, a new VB dataset is created for me. The system decided on LRECL=1028 but that's no problem here.
cp vb1.data "//vb2.data"
And that new VB2.DATA matches up exactly with the original VB1.DATA. So I don't see a problem. Yet...
So let's change one of the lines in the MVS source VB1.DATA and add a hex zero, such as line 2 below:
TED013.VB1.DATA Columns 00001 00072
Command ===> hex on Scroll ===> CSR
****** ***************************** Top of Data ******************************
000001 1111
FFFF44444444444444444444444444444444444444444444444444444444444444444444
111100000000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------
000002 2222 222
FFFF0FFF4444444444444444444444444444444444444444444444444444444444444444
222202220000000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------
000003 333333333333
FFFFFFFFFFFF444444444444444444444444444444444444444444444444444444444444
333333333333000000000000000000000000000000000000000000000000000000000000
------------------------------------------------------------------------------
****** **************************** Bottom of Data ****************************
... and then cp and od to display:
cp "//vb1.data" vb1.data
od -x vb1.data
0000000000 F1F1 F1F1 F2F2 F2F2 00F2 F2F2 F3F3 F3F3
0000000020 F3F3 F3F3 F3F3 F3F3
Wait a second, I see the zero, but what happened to our x'15' line breaks? The zero apparently causes cp to think the data is "binary" and eliminates the x'15' line breaks.
So let's copy back to MVS, and the result is a jumbled mess which I think matches Lionels description of "multiple records combined".
cp vb1.data "//vb2.data"
TED013.VB2.DATA Line 0000000000 Col 001 080
Command ===> Scroll ===> CSR
********************************* Top of Data **********************************
11112222.222333333333333
******************************** Bottom of Data ********************************
So if my example matches Lionel's problem at all, my theory is:
- Lionel's problem is not caused by the cp USS to MVS, but by the cp MVS to USS.
- Lionel isn't using the -B, -X, -T, or -F parms on the cp command, which according to the book says "If you do not specify either -F|B|T or X, cp will first check the format of the MVS data set indicated and then try to determine the type of file."
- That automated format decision seems to be based on if there is a x'00' somewhere in the file, at least in my quick tests.
So if I copy the file with the x'00' to USS and specify the -T option:
cp -T "//vb1.data" vb2.data
od -x vb2.data
0000000000 F1F1 F1F1 15F2 F2F2 F200 F2F2 F215 F3F3
0000000020 F3F3 F3F3 F3F3 F3F3 F3F3 1500
... the x'15' bytes are back, and the x'00' is still there of course. So let's copy back to MVS using the same -T option so the x'15' bytes cause separate records:
cp -T vb2.data "//vb2.data"
TED013.VB2.DATA Line 0000000000 Col 001 080
Command ===> Scroll ===> CSR
********************************* Top of Data **********************************
1111
2222.222
333333333333
******************************** Bottom of Data ********************************
And there's the data, as it started, including the x'00'
Now let's change the x'00' in the MVS source file to x'15', and run through the same process. We end up with:
TED013.VB2.DATA Line 0000000000 Col 001 080
Command ===> Scroll ===> CSR
********************************* Top of Data **********************************
1111
2222
222
333333333333
******************************** Bottom of Data ********************************
That's obviously a whole new problem, which (like phunsoft said) means binary and text can't always mix. But still, it looks like the designers of the cp logic between MVS and USS tried their best.
答案3
得分: 0
我不确定这是否有帮助，因为我不了解您的PDS成员。然而，这些示例对我有效：
$ ls
$ cp "//'MYID.PROGRAMS.JCL(ASM2)'" .
$ ls
asm2
cp 还有一个 --sparse=always 选项，可能会有帮助。
英文:
I'm not sure if this helps or not since I'm not sure about your PDS members. However these examples work for me:
$ ls
$ cp "//'MYID.PROGRAMS.JCL(ASM2)'" .
$ ls
asm2
There is also a --sparse=always option for cp which might help.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论