[hercules-os380] Jason’s Hercules and TCP version

[W Mainframe [e-mail] [hercules-os380]]

Guys,I am trying to use Socket Jason version with my VMSP rel5. I am able to compile and run. Everythings are ok but no address is returned for SOCKTEST sample just an address pointer. A detail, I am running with a modified Hercules (Jason version).Any success in a environment like VMSP?
DanThank you

Sent from Yahoo Mail for iPhone


Begin forwarded message:

On Sunday, March 25, 2018, 3:45 PM, hercules-***@yahoogroups.com <hercules-***@yahoogroups.com> wrote:

 
Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the hercules-os380
group.

File : /herc380-stage144.zip
Uploaded by : kerravon86 <***@yahoo.com.au>
Description : TCP/IP fix for Linux

You can access this file at the URL:
https://groups.yahoo.com/neo/groups/hercules-os380/files/herc380-stage144.zip

To learn more about file sharing for your group, please visit:
https://help.yahoo.com/kb/index?page=content&y=PROD_GRPS&locale=en_US&id=SLN15398

Regards,

kerravon86 <***@yahoo.com.au>

#yiv8249758365 #yiv8249758365 -- #yiv8249758365ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv8249758365 #yiv8249758365ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv8249758365 #yiv8249758365ygrp-mkp #yiv8249758365hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv8249758365 #yiv8249758365ygrp-mkp #yiv8249758365ads {margin-bottom:10px;}#yiv8249758365 #yiv8249758365ygrp-mkp .yiv8249758365ad {padding:0 0;}#yiv8249758365 #yiv8249758365ygrp-mkp .yiv8249758365ad p {margin:0;}#yiv8249758365 #yiv8249758365ygrp-mkp .yiv8249758365ad a {color:#0000ff;text-decoration:none;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ygrp-lc {font-family:Arial;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ygrp-lc #yiv8249758365hd {margin:10px 0px;font-weight:700;font-size:78%;line-height:122%;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ygrp-lc .yiv8249758365ad {margin-bottom:10px;padding:0 0;}#yiv8249758365 #yiv8249758365actions {font-family:Verdana;font-size:11px;padding:10px 0;}#yiv8249758365 #yiv8249758365activity {background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv8249758365 #yiv8249758365activity span {font-weight:700;}#yiv8249758365 #yiv8249758365activity span:first-child {text-transform:uppercase;}#yiv8249758365 #yiv8249758365activity span a {color:#5085b6;text-decoration:none;}#yiv8249758365 #yiv8249758365activity span span {color:#ff7900;}#yiv8249758365 #yiv8249758365activity span .yiv8249758365underline {text-decoration:underline;}#yiv8249758365 .yiv8249758365attach {clear:both;display:table;font-family:Arial;font-size:12px;padding:10px 0;width:400px;}#yiv8249758365 .yiv8249758365attach div a {text-decoration:none;}#yiv8249758365 .yiv8249758365attach img {border:none;padding-right:5px;}#yiv8249758365 .yiv8249758365attach label {display:block;margin-bottom:5px;}#yiv8249758365 .yiv8249758365attach label a {text-decoration:none;}#yiv8249758365 blockquote {margin:0 0 0 4px;}#yiv8249758365 .yiv8249758365bold {font-family:Arial;font-size:13px;font-weight:700;}#yiv8249758365 .yiv8249758365bold a {text-decoration:none;}#yiv8249758365 dd.yiv8249758365last p a {font-family:Verdana;font-weight:700;}#yiv8249758365 dd.yiv8249758365last p span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv8249758365 dd.yiv8249758365last p span.yiv8249758365yshortcuts {margin-right:0;}#yiv8249758365 div.yiv8249758365attach-table div div a {text-decoration:none;}#yiv8249758365 div.yiv8249758365attach-table {width:400px;}#yiv8249758365 div.yiv8249758365file-title a, #yiv8249758365 div.yiv8249758365file-title a:active, #yiv8249758365 div.yiv8249758365file-title a:hover, #yiv8249758365 div.yiv8249758365file-title a:visited {text-decoration:none;}#yiv8249758365 div.yiv8249758365photo-title a, #yiv8249758365 div.yiv8249758365photo-title a:active, #yiv8249758365 div.yiv8249758365photo-title a:hover, #yiv8249758365 div.yiv8249758365photo-title a:visited {text-decoration:none;}#yiv8249758365 div#yiv8249758365ygrp-mlmsg #yiv8249758365ygrp-msg p a span.yiv8249758365yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;}#yiv8249758365 .yiv8249758365green {color:#628c2a;}#yiv8249758365 .yiv8249758365MsoNormal {margin:0 0 0 0;}#yiv8249758365 o {font-size:0;}#yiv8249758365 #yiv8249758365photos div {float:left;width:72px;}#yiv8249758365 #yiv8249758365photos div div {border:1px solid #666666;min-height:62px;overflow:hidden;width:62px;}#yiv8249758365 #yiv8249758365photos div label {color:#666666;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv8249758365 #yiv8249758365reco-category {font-size:77%;}#yiv8249758365 #yiv8249758365reco-desc {font-size:77%;}#yiv8249758365 .yiv8249758365replbq {margin:4px;}#yiv8249758365 #yiv8249758365ygrp-actbar div a:first-child {margin-right:2px;padding-right:5px;}#yiv8249758365 #yiv8249758365ygrp-mlmsg {font-size:13px;font-family:Arial, helvetica, clean, sans-serif;}#yiv8249758365 #yiv8249758365ygrp-mlmsg table {font-size:inherit;font:100%;}#yiv8249758365 #yiv8249758365ygrp-mlmsg select, #yiv8249758365 input, #yiv8249758365 textarea {font:99% Arial, Helvetica, clean, sans-serif;}#yiv8249758365 #yiv8249758365ygrp-mlmsg pre, #yiv8249758365 code {font:115% monospace;}#yiv8249758365 #yiv8249758365ygrp-mlmsg * {line-height:1.22em;}#yiv8249758365 #yiv8249758365ygrp-mlmsg #yiv8249758365logo {padding-bottom:10px;}#yiv8249758365 #yiv8249758365ygrp-msg p a {font-family:Verdana;}#yiv8249758365 #yiv8249758365ygrp-msg p#yiv8249758365attach-count span {color:#1E66AE;font-weight:700;}#yiv8249758365 #yiv8249758365ygrp-reco #yiv8249758365reco-head {color:#ff7900;font-weight:700;}#yiv8249758365 #yiv8249758365ygrp-reco {margin-bottom:20px;padding:0px;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ov li a {font-size:130%;text-decoration:none;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ov li {font-size:77%;list-style-type:square;padding:6px 0;}#yiv8249758365 #yiv8249758365ygrp-sponsor #yiv8249758365ov ul {margin:0;padding:0 0 0 8px;}#yiv8249758365 #yiv8249758365ygrp-text {font-family:Georgia;}#yiv8249758365 #yiv8249758365ygrp-text p {margin:0 0 1em 0;}#yiv8249758365 #yiv8249758365ygrp-text tt {font-size:120%;}#yiv8249758365 #yiv8249758365ygrp-vital ul li:last-child {border-right:none !important;}#yiv8249758365

[[e-mail] [hercules-os380]]

Can you be clearer about what you are running?

You have quoted a message that was the Paul
version. I wasn't aware that Jason had actually
produced a full Hercules. I thought he only
produced a DLL on an old version. Or are you
referring to the socket.c that Jason wrote but
that I used? Or perhaps Juergen's version
where he incorporated Jason's code?

BFN. Paul.



---In hercules-***@yahoogroups.com, <***@yahoo.com> wrote :


Guys, I am trying to use Socket Jason version with my VMSP rel5. I am able to compile and run. Everythings are ok but no address is returned for SOCKTEST sample just an address pointer. A detail, I am running with a modified Hercules (Jason version).
Any success in a environment like VMSP?


Dan
Thank you

Sent from Yahoo Mail for iPhone https://overview.mail.yahoo.com/?.src=iOS

Begin forwarded message:


On Sunday, March 25, 2018, 3:45 PM, hercules-***@yahoogroups.com <hercules-***@yahoogroups.com> wrote:
Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the hercules-os380
group.

File : /herc380-stage144.zip
Uploaded by : kerravon86 <***@yahoo.com.au>
Description : TCP/IP fix for Linux

You can access this file at the URL:
https://groups.yahoo.com/neo/groups/hercules-os380/files/herc380-stage144.zip

To learn more about file sharing for your group, please visit:
https://help.yahoo.com/kb/index?page=content&y=PROD_GRPS&locale=en_US&id=SLN15398

Regards,

kerravon86 <***@yahoo.com.au>

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Reading the ASMFCLG procedure cards list in one
of my assembling job spool files, I realized,
I may run something like this JCL stream:

//REFBACK JOB (001),'PEPPE',MSGLEVEL=(1,1),REGION=0K,
// MSGCLASS=X,CLASS=A,NOTIFY=PEPPE,COND=(0,NE)
//DRUN EXEC PGM=IEFBR14
//PGMDD DD DISP=SHR,DSN=PEPPE.LINKLIB(VS2FB)
//*
//RRUN EXEC PGM=*.DRUN.PGMDD
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DISP=SHR,DSN=PEPPE.ASM.IEBCOPY
//SYSUT2 DD DISP=SHR,DSN=PEPPE.ASM(T1)
//TRACE DD SYSOUT=*

to execute the module VS2FB stored into the PEPPE.LINKLIB
library dataset, using a PGM=*.DRUN.PGMDD referback.

Of course I may have used a STEPLIB card in the RRUN step to get the same
result, but now I wonder if these are the only two ways to load and
execute, from a JCL deck, a program module already stored into a library
dataset.

And I also wondering if, in the case I've to execute a "sequence" of
modules, stored in multiple different libraries, a single "IEFBR14" dummy
step, which list in one and only one step the DD cards for ALL the
libraries, may be a better way to code a JCL stream for such a job,
instead of multiple different STEPLIB cards in multiple random lines of
the JCL stream.

Something like:

//DRUN EXEC PGM=IEFBR14
//PGMDD1 DD DISP=SHR,HLQ.L1(M1)
//PGMDD2 DD DISP=SHR,HLQ.L2(M2)
....
//PGMDDN DD DISP=SHR,HLQ.LN(MN)
....
//RR1 EXEC PGM=*.DRUN.PGMDD1
....
//RR2 EXEC PGM=*.DRUN.PGMDD2
....
//RRN EXEC PGM=*.DRUN.PGMDDN

Thanks in advance for any insight, Peppe.

Peppe.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
And I also wondering if, in the case I've to execute a "sequence" of
modules, stored in multiple different libraries, a single "IEFBR14" dummy
step, which list in one and only one step the DD cards for ALL the
libraries, may be a better way to code a JCL stream for such a job,
instead of multiple different STEPLIB cards in multiple random lines of
the JCL stream.

Referback is useful for writing a multi-file tape when you ask for a
scratch tape, and subsequent steps need a volume serial.

I use it consistently when a temporary data set needs to be referred to
more than once in a subsequent step, something that's illegal when done
by DSN=&&xxx. E.g., I have a test procedure that runs an IEBUPDTE to
create source and macro members in a temporary PDS, and in the next step
uses that data set in both the SYSLIB and SYSIN assembly.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
And I also wondering if, in the case I've to execute a "sequence" of
modules, stored in multiple different libraries, a single "IEFBR14" dummy
step, which list in one and only one step the DD cards for ALL the
libraries, may be a better way to code a JCL stream for such a job,
instead of multiple different STEPLIB cards in multiple random lines of
the JCL stream.

Referback is useful for writing a multi-file tape when you ask for a
scratch tape, and subsequent steps need a volume serial.
I use it consistently when a temporary data set needs to be referred to
more than once in a subsequent step, something that's illegal when done
by DSN=&&xxx. E.g., I have a test procedure that runs an IEBUPDTE to
create source and macro members in a temporary PDS, and in the next step
uses that data set in both the SYSLIB and SYSIN assembly.

Thanks Gerhard. I'll keep a record about this hint on my logbook.

But I would like to have an answer about my question.

Is STEPLIB and REFERBACKs the ONLY two ways to execute a load module
stored in a library which is NOT in the MVS linklist, from JCL?

--- Changing TOPIC --

By the way. I think I got my first assembler MVS3.8j tool up and
running ;-)

Actually, at this moment, I've two load modules, VS2FB and FB2VS
which seems able to store a VS dataset into an FB dataset and
restore the original VS dataset from the FB dataset, where variable
length records are stored, contiguously, each one with its RDW,
as a "deck of cards".

They should work as the VTOF and FTOV parameters of the DFSORT
tool under a modern ZOS (not sure I didn't run it).

I had been able to unload a PDS, using IEBCOPY, into a VS
dataset, store the VS dataset into an FB/LRECL=80 dataset with VS2FB,
download the FB dataset, with a binary IND$FILE, on my Linux, upload
a new copy, again with a binary IND$FILE, of the FB dataset to
my SYS2/MVS3.8j, get back a new copy of the VS dataset with FB2VS and run
succesfully against it IEBCOPY, to load a new copy of the original PDS.

I hope it is a good test of the logic of my assembler programs,
IEBCOPY would scream loudly if even a single record of the VS
dataset it is not in right place, isn't? It even works for
a 3390 LINKLIB library, (RECFM=U,BLKSIZE=32760), stored on a
IEBCOPY 2314 DATASET, (RECFM=VS,LRECL=32760,BLKSZ=7294).

And, yes, I used some testcase to check real spanned records
were stored inside the VS datasets, with an IDCAMS/RECFM=U dump:

Block 1 00280000 00240100 F0F0F0F1 ...
Block 2 00280000 00240300 F3F4F5F6 ...
Block 3 00180000 00140200 F5F6F7F8 ...

restoring also for these testcases the original VS dataset,
(RECFM=VS,LRECL=84,BLKSIZE=40).

The two short assembler programs VS2FB/FB2VS use QSAM to perform such
"conversion" and it seems QSAM is more than enough, for
what I've seen so far. Using QSAM I didn't need to DEBLOCK
logical records and this helped me to keep the logic simple,
as my assembler/370 skills are still quite bounded.

I know XMIT370/RECV370 may do the very same job, but, as you
all already know, it had been a personal question between me
and MVS3.8j, this VS/FB "conversion" ;-)

I think I'm on the way to solve my personal question ;-)

I've to thank you so much Gerhard, for all the advices,
hints and code samples you gave me along the way.

Finally I had been able to "see" with my "naked eyes"
BDW and RDW block/record fields stored into a VS dataset,
as I did many test with both QSAM and BSAM, using ASSIST/SNAP
for debugging and IDCAMS to dump records.

Up to know, probably for my MVS naivness, I hadn't been
able, beside using XMIT370/RECV370, to perform such a conversion
in any other way.

I did many attempts, in many different ways, using RECFM=U
intermediate datasets, to achieve the same result that,
from what I read on the Web, may be easily obtained using
(DFSORT,VTOF,FTOV) under a modern ZOS, to download/upload
a VS dataset between a ZOS system and a Linux/Windows system
(actually it seems the only solution to this problem proposed
as an answer to this question, in the ZOS public forums).

But this is the first time I had been actually able,
without calling XMIT370/RECV370, to perform such a job,
using only standard MVS3.8j tools and my short assembler
attempts.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY
two ways to execute a load module
stored in a library which is NOT in the
MVS linklist, from JCL?

I think there's a JOBLIB too.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. I think I got my first assembler
MVS3.8j tool up and running ;-)

Congratulations!

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY
two ways to execute a load module
stored in a library which is NOT in the
MVS linklist, from JCL?

I think there's a JOBLIB too.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. I think I got my first assembler
MVS3.8j tool up and running ;-)

Congratulations!
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY
two ways to execute a load module
stored in a library which is NOT in the
MVS linklist, from JCL?

I think there's a JOBLIB too.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. I think I got my first assembler
MVS3.8j tool up and running ;-)

Congratulations!

---

Yep, I thought JOBLIB as a JCL "global" variation of STEPLIB,
Paul. Thanks for the precisation. Now we have 3 ways ;-)

Any other way?

---

Well, I know VS2FB/FB2VS are not such a achievement Paul,
but writing them, I had to opportunity to gain a better
understanding of QSAM/BSAM, beside refreshing my memory
on the "Principle of Operations" book ;-)

You already know how powerful is the combination of C/Assembler
on any platform, isn't? ;-)

My final goal is to get skilled enough in Assembler/370
to easily write C/Assembler tools, under MVS3.8j.

I'm just a beginner, an Assembler/370 newbie, but I'm
learning, slowly, but I'm still learning ;-)

By the way. Using GCCMVS/SUPA, at this very moment,
I handn't be able to perform a complete VS2FB/FB2VS conversion.

We have been speaking for years about this topic, here
in this group, but this is the very first time I may download an IEBCOPY
VS dataset on my Linux, which may be IEBCOPY restored under MVS3.8j,
without using XMIT370.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. Using GCCMVS/SUPA, at this very moment,
I handn't be able to perform a complete VS2FB/FB2VS conversion.

It should work. If it doesn't, we should go through
the debug process. But you probably need to use
true RECFM=V files, not VS files. Use copyfile
and hexdump and idcams print dump to see what
is happening.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. Using GCCMVS/SUPA, at this very moment,
I handn't be able to perform a complete VS2FB/FB2VS conversion.

It should work. If it doesn't, we should go through
the debug process. But you probably need to use
true RECFM=V files, not VS files. Use copyfile
and hexdump and idcams print dump to see what
is happening.

BFN. Paul.

---

Paul, it doesn't, at least with the versions
of GCCMVS/SUPA I have seen.

And what VS2FB/FB2VS do, can't be done without
a piece of logic I can't see in the sources,
for what I understand of the problem.

Storing a RECFM=VS (RECFM=V[B] wouldn't make such a difference) into a
RECFM=FB, if I'm not wrong, requires using or an EOF FB CARD,
as last record, or an header FB CARD, as first record, with the length
of the original RECFM=VS stored. The FB output dataset,
in the general case, can't have the same length of the sum
of the VS records, so its last DATA record would
contains "garbage", again in the general case, its
MVS EOF can't be the same of the logical VS EOF.

The last solution, using QSAM in not-REWRITE
mode (a must, if pure sequential FB output devices
are involved, like tapes or punch), requires
two sequential steps over the VS dataset, one for computing
the length, the second for writing the FB dataset,
with header. I don't like "two steps" for such a simple
task, so I went for an EOF FB CARD, using the fact
the RDW field is ALWAYS an HALF WORD stored into
a FULL WORD, reading/writing with QSAM, for
what I can see (please correct me if this is not
the case), so the RDW value "FFFF FFFF" can be
used as an EOF mark.

There is another subtle drawback, actually.

Without constraints over the modulo
VS-LRECL%FB-LRECL (in C notation), it may happens
an RDW VS record field (a complete one, full word, 4 bytes
long) get "broken" over two contiguos cards,
in this way (real RFE hex dump):

(end of FIRST card)
12345
FFFFF0
123450

(begin of SECOND card)
| 000
400FFF
F00000

where RDW="004F 0000" (79) and the remaind is (1).

I'm just writing the logic for this case. By now
my code works only for the cases where the euclidean division
remind VS-LRECL%FB-LRECL is ZERO.

I had been just lucky enough, with IEBCOPY VS inputs and
a (RECFM=FB,LRECL=80) output, the remaind was always ZERO, but
the general case, for what I can see, requires handling
the cases where remaind=1,2,3 .

I may be wrong, Paul. In this case I would be like
to be addressed to the source where the conversion
VS/FB is actually done.

Thanks, Peppe.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo)

Post by ***@yahoo.com.au [hercules-os380]
It should work. If it doesn't, we should go through
the debug process. But you probably need to use
true RECFM=V files, not VS files. Use copyfile
and hexdump and idcams print dump to see what
is happening.
Paul, it doesn't, at least with the versions
of GCCMVS/SUPA I have seen.

So it needs to be debugged, because it is
meant to work.

Post by ***@yahoo.com.au [hercules-os380]
And what VS2FB/FB2VS do, can't be done without
a piece of logic I can't see in the sources,
for what I understand of the problem.
Storing a RECFM=VS (RECFM=V[B] wouldn't make such a difference) into a
RECFM=FB, if I'm not wrong, requires using or an EOF FB CARD,
as last record, or an header FB CARD, as first record, with the length
of the original RECFM=VS stored. The FB output dataset,
in the general case, can't have the same length of the sum
of the VS records, so its last DATA record would
contains "garbage", again in the general case, its
MVS EOF can't be the same of the logical VS EOF.

copyfile (or rather, pdpclib) will gracefully pad
the F80 dataset with NUL characters, as allowed
by the C90 standard.

Post by ***@yahoo.com.au [hercules-os380]
(begin of SECOND card)

pdpclib gracefully allows RDWs or data to be
split across records.

Post by ***@yahoo.com.au [hercules-os380]
I may be wrong, Paul. In this case I would be like
to be addressed to the source where the conversion
VS/FB is actually done.

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/stdio.c

line 1421 shows an F being padded out with
NULs as you should already be seeing with
copyfile.

Line 5142 has comments explaining that
writing lots of NULs to a V will be silently
ignored.

Note that this means that all programs,
e.g. uudecode, will behave as desired,
it's not something that is unique to copyfile,
which is a very simple program and has
nothing MVS-specific in it.

This is the latest dev code, so if you are
looking at the latest released code the line
numbers will be a little different, but if you
search for the function names the code
should be in what you have too, as it is not
a recent addition.

If it's not working I need hexdumps and
idcams dumps of a small file to figure out
what is happening.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Thu, 29 Mar 2018, ***@yahoo.com.au [hercules-os380] wrote:

If it's not working I need hexdumps and
idcams dumps of a small file to figure out
what is happening.

---

Paul, we already did that round, for what
I remember.

I was not able to get it working up to now.

If you have a "working" testcase, I'll
be happy to test your example.

For "working", I mean an example of how,
using "copyfile" I can go from an IEBCOPY
VS, through an FB, to another IEBCOPY VS.

The IEBCOPY program, will be the judge.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If you have a "working" testcase, I'll
be happy to test your example.

See below. But remember, it needs to be
V, not VS, so you need to have a reasonable
blocksize on your load module dataset so that
it doesn't span records. I'm not sure if
spanning works.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
For "working", I mean an example of how,
using "copyfile" I can go from an IEBCOPY
VS, through an FB, to another IEBCOPY VS.
The IEBCOPY program, will be the judge.

Here is IEBCOPY's judgement:

IEB167I FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY SYSUT1 -
IEB154I HEXDUMP HAS BEEN SUCCESSFULLY LOADED
IEB144I THERE ARE 0000293 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY SYSUT2
IEB149I THERE ARE 0000043 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY
IEB147I END OF JOB -00 WAS HIGHEST SEVERITY CODE


BFN. Paul.



//HERC01A JOB CLASS=C,REGION=0K
//*
//* Test COPYFILE
//*
//HEXDUMP EXEC PGM=HEXDUMP,PARM=''
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//IEBCOPY EXEC PGM=IEBCOPY
//SYSUT1 DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//SYSUT2 DD DSN=&&TEMP1,SPACE=(CYL,(10,10)),UNIT=SYSALLDA,
// DISP=(NEW,PASS)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COPY INDD=((SYSUT1,R)),OUTDD=SYSUT2
SELECT MEMBER=HEXDUMP
/*
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=&&TEMP1,DISP=(OLD,PASS)
//OUT DD DSN=&&TEMP2,SPACE=(CYL,(10,10)),UNIT=SYSALLDA,
// DISP=(NEW,PASS),DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=&&TEMP2,DISP=(OLD,PASS)
//OUT DD DSN=&&TEMP3,SPACE=(CYL,(10,10)),UNIT=SYSALLDA,
// DISP=(NEW,PASS),DCB=(RECFM=V,LRECL=16000,BLKSIZE=16004)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//IEBCOPY EXEC PGM=IEBCOPY
//SYSUT1 DD DSN=&&TEMP3,DISP=(OLD,PASS)
//SYSUT2 DD DSN=&&TEMP4,SPACE=(CYL,(10,10,44)),UNIT=SYSALLDA,
// DISP=(NEW,PASS)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//HEXDUMP2 EXEC PGM=HEXDUMP,PARM=''
//STEPLIB DD DSN=&&TEMP4,DISP=(OLD,PASS)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If you have a "working" testcase, I'll
be happy to test your example.

See below. But remember, it needs to be
V, not VS, so you need to have a reasonable
blocksize on your load module dataset so that
it doesn't span records. I'm not sure if
spanning works.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
For "working", I mean an example of how,
using "copyfile" I can go from an IEBCOPY
VS, through an FB, to another IEBCOPY VS.
The IEBCOPY program, will be the judge.

Here is IEBCOPY's judgement:

IEB167I FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY SYSUT1 -
IEB154I HEXDUMP HAS BEEN SUCCESSFULLY LOADED
IEB144I THERE ARE 0000293 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY SYSUT2
IEB149I THERE ARE 0000043 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY
IEB147I END OF JOB -00 WAS HIGHEST SEVERITY CODE


---

It looks we are using different versions of "copyfile", then,
Paul.

May you arrange things so I may download a copy of
the PDPCLIB.LINKLIB (possibly plain AMODE=24) you are
using? So I may test the last updated version?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
May you arrange things so I may download a copy of
the PDPCLIB.LINKLIB (possibly plain AMODE=24) you are
using? So I may test the last updated version?

I've uploaded copyfile.exe which is an IEBCOPY
unload of just copyfile.exe. You may wish to use
your own program to restore it to a V dataset.
I would normally use copyfile to do that, but you
don't trust your copyfile. somitcw has a program
that will do the job too, but I've never used that.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I've uploaded copyfile.exe which is an IEBCOPY
unload of just copyfile.exe. You may wish to use
your own program to restore it to a V dataset.
I would normally use copyfile to do that, but you
don't trust your copyfile. somitcw has a program
that will do the job too, but I've never used that.

As an alternative, why not use this recent copy
of copyfile in JCL form:

https://groups.yahoo.com/neo/groups/hercules-os380/files/makeutil.zip

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
May you arrange things so I may download a copy of
the PDPCLIB.LINKLIB (possibly plain AMODE=24) you are
using? So I may test the last updated version?

I've uploaded copyfile.exe which is an IEBCOPY
unload of just copyfile.exe. You may wish to use
your own program to restore it to a V dataset.
I would normally use copyfile to do that, but you
don't trust your copyfile. somitcw has a program
that will do the job too, but I've never used that.

BFN. Paul.

---

Got it in one of my linklibs, just for check:

LAST LINK-EDITED ON 2/17/18 BY LKED 5752SC104 V03 M08

Correct, Paul?

Peppe.

[[e-mail] [hercules-os380]]

LAST LINK-EDITED ON 2/17/18 BY LKED 5752SC104 V03 M08
Correct, Paul?

Looks correct, but bear in mind that it is just
crap in my dev system, not a controlled
release. PDPCLIB is not in a good state at
the moment and I believe I backed out the
latest mvssupa before building that module,
so matching source is not straightforward,
as what is currently in git is something that
I am not comfortable with.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

LAST LINK-EDITED ON 2/17/18 BY LKED 5752SC104 V03 M08
Correct, Paul?

Looks correct, but bear in mind that it is just
crap in my dev system, not a controlled
release. PDPCLIB is not in a good state at
the moment and I believe I backed out the
latest mvssupa before building that module,
so matching source is not straightforward,
as what is currently in git is something that
I am not comfortable with.

BFN. Paul.

---

Well, I used again this version, to
"copyfile -bb" to an FB (which looks
correct to my eyes) one of my IEBCOPY
VS dataset, one I'm using for my tests,
an UNLOAD of my PEPPE.ASM assembler
sources dataset.

The VS length "copyfile -bb" reports is
the same than my VS2FB tool reports:

copyfile -bb 'peppe.asm.iebcopy' 'peppe.asm(D3)'
copying from file 'peppe.asm.iebcopy', mode binary
to file 'peppe.asm(D3)', mode binary
912588 bytes copied

VS records#: 83
VS length : 912588
FB records#: 11408
FB length : 912640

i.e. length=912588, over 83 records.

My FB2VS tool, currently in develope, can't be always trusted,
can be trusted for this particular IEBCOPY dataset and reports,
on restoring to the VS dataset:

VS records#: 83
VS lenck : 912588
VS length : 912588
FB records#: 11408
FB length : 912640

coherently with VS2FB. I'm able to use IEBCOPY to unload the original PDS.

This is what happens if I try to use the same
version you uploaded Paul, if I try to restore
with "copyfile -bb" the PEPPE.ASM(D3) member
it created, from TSO:

copyfile -bb 'peppe.asm(D3)' 'peppe.asm.iebcopy1'
copying from file 'peppe.asm(D3)', mode binary
to file 'peppe.asm.iebcopy1', mode binary
COPYFILE ENDED DUE TO ERROR+
?
USER ABEND CODE 0002
READY

the very same ABEND of the 2011 version I was
using so far.

I run the same job using this JCL:

//COPYJ JOB (IEBG),'PEPPE',MSGLEVEL=(1,1),REGION=0K,
// MSGCLASS=X,CLASS=A,NOTIFY=PEPPE,COND=(0,NE)
//COPY EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//IN DD DISP=SHR,DSN=PEPPE.ASM(D3)
//OUT DD DISP=SHR,DSN=PEPPE.ASM.IEBCOPY1
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY

and this what I get on console:

JOB 1086 IEF403I COPYJ - STARTED - TIME=19.06.37
JOB 1086 +MVSSUPA - @@AWRITE - invalid RECFM=Vxx request
JOB 1086 +MVSSUPA - DD OUT
JOB 1086 IEF450I COPYJ COPY - ABEND S000 U0002 - TIME=19.06.38
JOB 1086 IEFACTRT - Stepname Procstep Program Retcode
JOB 1086 COPYJ COPY COPYFILE AB U0002
JOB 1086 IEF404I COPYJ - ENDED - TIME=19.06.38

My IEBCOPY VS datasets, the original and the copy created
from FB2VS, are allocated as (RECFM=VS,LRECL=19056,BLKSIZE=7294
from IEBCOPY over a 2314 DASD, by IEBCOPY.

I reallocated the IEBCOPY1 dataset, the copy, over a 3390,
with (RECFM=VS,LRECL=19056,BLKSZIE=19060) and run again
the COPYFILE JOB. Same output on console:

JOB 1087 IEF403I COPYJ - STARTED - TIME=19.14.48
JOB 1087 +MVSSUPA - @@AWRITE - invalid RECFM=Vxx request
JOB 1087 +MVSSUPA - DD OUT
JOB 1087 IEF450I COPYJ COPY - ABEND S000 U0002 - TIME=19.14.49
JOB 1087 IEFACTRT - Stepname Procstep Program Retcode
JOB 1087 COPYJ COPY COPYFILE AB U0002
JOB 1087 IEF404I COPYJ - ENDED - TIME=19.14.49

and same U0002 abend.

Peppe.

[[e-mail] [hercules-os380]]

I believe this is caused by an invalid RDW
being given by the C code. The C code will
have just copied it unmodified from the
input dataset.

If you have put invalid RDWs like x'FFFF'
into the stream, that's probably what is
causing the crash.

I think the best thing to do is:

1. You should have 2-3 different versions of
copyfile available to you. See which of them
work with this JCL:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18066

2. Make your own assembler programs behave
the same as copyfile, ie pad with NULs instead
of x'FF' so that we have 3 different ways of
handling IEBCOPY unloads - copyfile, somitcw's
version, and your version.

3. If you can get (1) above working, then see
which steps can be replaced by your own
program and still work.

4. Write a small C program that looks at the
RDWs in the bad input file (that causes
copyfile to abend) and print out the smallest
and largest RDWs, and see if the smallest
is less than or equal to 4, or if the largest is
larger than the LRECL of the output dataset.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible triple post due to yahoo, and also check
the file area for the code to download)

Post by ***@yahoo.com.au [hercules-os380]
4. Write a small C program that looks at the
RDWs in the bad input file (that causes
copyfile to abend) and print out the smallest
and largest RDWs, and see if the smallest
is less than or equal to 4, or if the largest is
larger than the LRECL of the output dataset.

Try the attached, and also below in case the
attachment fails to go through.

BFN. Paul.



/*********************************************************************/
/* */
/* This Program Written by Paul Edwards. */
/* Released to the Public Domain */
/* */
/*********************************************************************/
/*********************************************************************/
/* */
/* rdwcheck - analyze an RDW file (IEBCOPY unload) */
/* */
/*********************************************************************/

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

static unsigned char rdw[4];
static unsigned char buf[70000];
static long offset = 0;
static long maxoff = 0;
static unsigned int maxlen = 0;
static unsigned int len;
static unsigned int ret;

int main(int argc, char **argv)
{
FILE *fp;

if (argc <= 1)
{
printf("usage: rdwcheck <rdw file>\n");
return (EXIT_FAILURE);
}

fp = fopen(*(argv + 1), "rb");
if (fp == NULL)
{
printf("can't open %s\n", *(argv + 1));
return (EXIT_FAILURE);
}

while (1)
{
ret = fread(rdw, 1, 4, fp);
if (ret == 0) break;
if (ret < 4)
{
printf("only partial rdw at %ld\n", offset);
break;
}
if ((rdw[2] != 0) || (rdw[3] != 0))
{
printf("last 2 bytes of RDW non-zero at %ld\n", offset);
break;
}
len = rdw[0] << 8 | rdw[1];
if (len <= 4)
{
printf("rdw too small (%d) at offset %ld\n", len, offset);
break;
}
if (len > maxlen)
{
maxlen = len;
maxoff = offset;
}
offset += 4;
len -= 4;
ret = fread(buf, 1, len, fp);
if (ret != len)
{
printf("only read %u bytes instead of %u at offset %ld\n",
ret, len, offset);
break;
}
offset += len;
}
printf("max RDW was %u at offset %ld\n", maxlen, maxoff);
return (0);
}

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

I believe this is caused by an invalid RDW
being given by the C code. The C code will
have just copied it unmodified from the
input dataset.

If you have put invalid RDWs like x'FFFF'
into the stream, that's probably what is
causing the crash.

I think the best thing to do is:

1. You should have 2-3 different versions of
copyfile available to you. See which of them
work with this JCL:

https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18066

2. Make your own assembler programs behave
the same as copyfile, ie pad with NULs instead
of x'FF' so that we have 3 different ways of
handling IEBCOPY unloads - copyfile, somitcw's
version, and your version.

3. If you can get (1) above working, then see
which steps can be replaced by your own
program and still work.

4. Write a small C program that looks at the
RDWs in the bad input file (that causes
copyfile to abend) and print out the smallest
and largest RDWs, and see if the smallest
is less than or equal to 4, or if the largest is
larger than the LRECL of the output dataset.

BFN. Paul.

---

I didn't put ANYTHING in the FB dataset,
Paul.

If you look to my command log, Paul,
COPYFILE had as input dataset an FB
dataset (D3) created by COPYFILE.

Instead FB2VS had as input file the
FB dataset created by VS2FB (D1),
both stored in my PEPPE.ASM FB80
PDS.

By the way, I DO NOT have GCCMVS
on board on my SYS2, so, please
don't ask me to test source C program,
as I can't, currently, compile
them on my developing environmen.

COPYFILE is NOT able to copy back
ITS FB dataset, where COPYFILE and
only COPYFILE wrote RDW fields.

If you want a copy of my IEBCOPY
dataset, on a virtual tape, to test
it in your environment, we may arrange
for a file exchange.

For what I can see by now, COPYFILE
is not able to restore the FB dataset
COPYFILE created from an IEBCOPY VS dataset,
it abends U002 with the message I posted
in my previous message.

Peppe.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo)

Post by ***@yahoo.com.au [hercules-os380]
https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18066

You didn't answer whether this JCL worked or not.

Post by ***@yahoo.com.au [hercules-os380]
If you look to my command log, Paul,
COPYFILE had as input dataset an FB
dataset (D3) created by COPYFILE.

Ok, that should work. So please provide
this FB dataset to me so that I can analyze it.

Post by ***@yahoo.com.au [hercules-os380]
By the way, I DO NOT have GCCMVS
on board on my SYS2, so, please
don't ask me to test source C program,
as I can't, currently, compile
them on my developing environmen.

You can run the program on your Linux
system if you want. Just transfer the file
in binary mode. Or use "hetget" to extract
it from tape.

Post by ***@yahoo.com.au [hercules-os380]
If you want a copy of my IEBCOPY
dataset, on a virtual tape, to test
it in your environment, we may arrange
for a file exchange.

Just upload it to the files area will be fine.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
(possible double post due to Yahoo)
https://groups.yahoo.com/neo/groups/hercules-os380/conversations/messages/18066

You didn't answer whether this JCL worked or not.

Post by ***@yahoo.com.au [hercules-os380]
If you look to my command log, Paul,
COPYFILE had as input dataset an FB
dataset (D3) created by COPYFILE.

Ok, that should work. So please provide
this FB dataset to me so that I can analyze it.

Post by ***@yahoo.com.au [hercules-os380]
By the way, I DO NOT have GCCMVS
on board on my SYS2, so, please
don't ask me to test source C program,
as I can't, currently, compile
them on my developing environmen.

You can run the program on your Linux
system if you want. Just transfer the file
in binary mode. Or use "hetget" to extract
it from tape.

Post by ***@yahoo.com.au [hercules-os380]
If you want a copy of my IEBCOPY
dataset, on a virtual tape, to test
it in your environment, we may arrange
for a file exchange.

Just upload it to the files area will be fine.

BFN. Paul.

---

I didn't answer because I didn't try it, Paul.

I've one IEBCOPY dataset which, in my env,
by me, can't be converted VS/FB/VS, and a single
case is more than enough.

It may be I've done mistakes, up to now, Paul,
but if it is my fault, it is evident I can't find
it by myself, after years of failures.

I saved a copy of my PEPPE.ASM.IEBCOPY dataset,
converted to the D3 (RECFM=FB,LRECL=80) dataset at the URL:

http://www.vitillaro.org/curr/D3.zip

unzip the file, binary upload D3 as a (RECFM=FB,LRECL=80),
and you may analyze it by yourself.

COPYFILE should be able to copy back it onto a
a RECFM=VS,LRECL=19056,BLKSIZE=7294 dataset
without errors, beside the fact is good or
not for IEBCOPY, isn't?

About a copy of the original PEPPE.ASM.IEBCOPY
VS dataset, I think the best way, if you actually
need it, is to arrange for a tape dump, as I'm
not actually sure downloading it in binary with
IND$FILE is a good idea.

If you think you badly need it, I may provide
the dump, Paul.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I didn't answer because I didn't try it, Paul.
I've one IEBCOPY dataset which, in my env,
by me, can't be converted VS/FB/VS, and a single
case is more than enough.

It was a clean testcase in my opinion. Regardless,
we can debug without it.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
unzip the file, binary upload D3 as a (RECFM=FB,LRECL=80),
and you may analyze it by yourself.

D3 passes my analysis, and copyfile doesn't
have an error when it restores it. But IEBCOPY
has a problem when it tries to unload it:

IEB139I I/O ERROR DURING LOAD - HERC01A ,IEBCOPY ,1B2,DA,SYSUT1 ,READ ,WRNG.LEN.RECORD,000001A600000C,BSAM

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
COPYFILE should be able to copy back it onto a
a RECFM=VS,LRECL=19056,BLKSIZE=7294 dataset
without errors, beside the fact is good or
not for IEBCOPY, isn't?

Well you said you tried BLKSIZE=19060 and that
that also failed. I'm not sure about spanned
records, but 19060 should work, and does work
on my system.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
About a copy of the original PEPPE.ASM.IEBCOPY
VS dataset, I think the best way, if you actually
need it, is to arrange for a tape dump, as I'm
not actually sure downloading it in binary with
IND$FILE is a good idea.

Can we instead have you do your work on a
program-generated output file? ie a file that
consists of:

LINE1
LINE2

etc

Then I can see if my IEBCOPY unload + copyfile
differs from yours.

All done with a stream of JCL that creates
the initial PDS and populates it with the
above data, then does the iebcopy unload
and copyfile.

I think it will take a while to debug this, so
if we can isolate the problem to small,
clean data, that would be good. We can't
(easily) debug iebcopy itself to find out what
it thinks is wrong with the data.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I didn't answer because I didn't try it, Paul.
I've one IEBCOPY dataset which, in my env,
by me, can't be converted VS/FB/VS, and a single
case is more than enough.

It was a clean testcase in my opinion. Regardless,
we can debug without it.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
unzip the file, binary upload D3 as a (RECFM=FB,LRECL=80),
and you may analyze it by yourself.

D3 passes my analysis, and copyfile doesn't
have an error when it restores it. But IEBCOPY
has a problem when it tries to unload it:

IEB139I I/O ERROR DURING LOAD - HERC01A ,IEBCOPY ,1B2,DA,SYSUT1 ,READ ,WRNG.LEN.RECORD,000001A600000C,BSAM

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
COPYFILE should be able to copy back it onto a
a RECFM=VS,LRECL=19056,BLKSIZE=7294 dataset
without errors, beside the fact is good or
not for IEBCOPY, isn't?

Well you said you tried BLKSIZE=19060 and that
that also failed. I'm not sure about spanned
records, but 19060 should work, and does work
on my system.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
About a copy of the original PEPPE.ASM.IEBCOPY
VS dataset, I think the best way, if you actually
need it, is to arrange for a tape dump, as I'm
not actually sure downloading it in binary with
IND$FILE is a good idea.

Can we instead have you do your work on a
program-generated output file? ie a file that
consists of:

LINE1
LINE2

etc

Then I can see if my IEBCOPY unload + copyfile
differs from yours.

All done with a stream of JCL that creates
the initial PDS and populates it with the
above data, then does the iebcopy unload
and copyfile.

I think it will take a while to debug this, so
if we can isolate the problem to small,
clean data, that would be good. We can't
(easily) debug iebcopy itself to find out what
it thinks is wrong with the data.

BFN. Paul.

---

This is weird Paul. D3 is correct, but I can't
copy it with the copyfile you sent me, while
you can with your copyfile?

Damn, how may I call "copyfile -bb" in the wrong
way from both TSO and JCL? You have seen my
commands and my JCL. They are as simple as possible
and copyfile is the binary module you sent me,
we have verified its date.

We are not using the same copyfile version, Paul
OR I've a GIANT BUG in my SYS2 which show up
only with copyfile.

I can't see any other option left.

Peppe-.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I didn't answer because I didn't try it, Paul.
I've one IEBCOPY dataset which, in my env,
by me, can't be converted VS/FB/VS, and a single
case is more than enough.

It was a clean testcase in my opinion. Regardless,
we can debug without it.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
unzip the file, binary upload D3 as a (RECFM=FB,LRECL=80),
and you may analyze it by yourself.

D3 passes my analysis, and copyfile doesn't
have an error when it restores it. But IEBCOPY
IEB139I I/O ERROR DURING LOAD - HERC01A ,IEBCOPY ,1B2,DA,SYSUT1 ,READ ,WRNG.LEN.RECORD,000001A600000C,BSAM

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
COPYFILE should be able to copy back it onto a
a RECFM=VS,LRECL=19056,BLKSIZE=7294 dataset
without errors, beside the fact is good or
not for IEBCOPY, isn't?

Well you said you tried BLKSIZE=19060 and that
that also failed. I'm not sure about spanned
records, but 19060 should work, and does work
on my system.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
About a copy of the original PEPPE.ASM.IEBCOPY
VS dataset, I think the best way, if you actually
need it, is to arrange for a tape dump, as I'm
not actually sure downloading it in binary with
IND$FILE is a good idea.

Can we instead have you do your work on a
program-generated output file? ie a file that
LINE1
LINE2
etc
Then I can see if my IEBCOPY unload + copyfile
differs from yours.
All done with a stream of JCL that creates
the initial PDS and populates it with the
above data, then does the iebcopy unload
and copyfile.
I think it will take a while to debug this, so
if we can isolate the problem to small,
clean data, that would be good. We can't
(easily) debug iebcopy itself to find out what
it thinks is wrong with the data.
BFN. Paul.
---
This is weird Paul. D3 is correct, but I can't
copy it with the copyfile you sent me, while
you can with your copyfile?
Damn, how may I call "copyfile -bb" in the wrong
way from both TSO and JCL? You have seen my
commands and my JCL. They are as simple as possible
and copyfile is the binary module you sent me,
we have verified its date.
We are not using the same copyfile version, Paul
OR I've a GIANT BUG in my SYS2 which show up
only with copyfile.
I can't see any other option left.
Peppe-.

Paul, are you "copyfile -bb D3" to a VS or to a VB datset?
I can copy to a VB, I get U002 only when copying to a VS.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, are you "copyfile -bb D3" to a VS or to a VB datset?
I can copy to a VB, I get U002 only when copying to a VS.

I checked your original message and now I can
see that you mentioned VS. As I have said,
I'm not sure what the state of VS is, so we need
to stick with creating V or VB datasets.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible triple post due to yahoo)

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
We are not using the same copyfile version, Paul
OR I've a GIANT BUG in my SYS2 which show up
only with copyfile.
I can't see any other option left.

If PDPCLIB has an uninitialized variable that is
causing the issue, it may only occur on your
system, not mine. With computer bugs, anything
is possible.

I've looked back at your original message, and
it seems the other thing I missed was that you
seem to have created peppe.asm.iebcopy as
a VS dataset. As I have said, PDPCLIB is not
known to work for VS datasets, you need to
ensure that IEBCOPY creates a V dataset
by putting the output on a 3390 so that it can
create a LRECL large enough to hold a full
record with no spanning. Ideally the blocksize
of your original dataset is something sensible
like 6160, as hopefully IEBCOPY will produce
a BLKSIZE bigger than that.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
(possible triple post due to yahoo)
We are not using the same copyfile version, Paul
OR I've a GIANT BUG in my SYS2 which show up
only with copyfile.
I can't see any other option left.

If PDPCLIB has an uninitialized variable that is
causing the issue, it may only occur on your
system, not mine. With computer bugs, anything
is possible.

I've looked back at your original message, and
it seems the other thing I missed was that you
seem to have created peppe.asm.iebcopy as
a VS dataset. As I have said, PDPCLIB is not
known to work for VS datasets, you need to
ensure that IEBCOPY creates a V dataset
by putting the output on a 3390 so that it can
create a LRECL large enough to hold a full
record with no spanning. Ideally the blocksize
of your original dataset is something sensible
like 6160, as hopefully IEBCOPY will produce
a BLKSIZE bigger than that.

BFN. Paul.

---

Damn, I did't create PEPPE.ASM.IEBCOPY
as a VS dataset. IEBCOPY created it
this way and it also choosed the LRECL
and the BLKSIZE. For what I understand
IEBCOPY build its own DCB at runtime,
computed from the input PDS DCB.

IEBCOPY output datasets are VS datasets,
not VB datasets, its program internal DCB drive
that, even specifying a DCB from the
JCL DD card wouldn't do anything different.

The program DCB has precedence over the
JCL DD DCB, they are merged, but what
is specified by the program in its DCB
drive the game, Paul. You can't change it.

Peppe.

[[e-mail] [hercules-os380]]

(possible triple post due to yahoo)

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I've looked back at your original message, and
it seems the other thing I missed was that you
seem to have created peppe.asm.iebcopy as
a VS dataset.

Sorry, I meant peppe.asm.iebcopy1

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Damn, I did't create PEPPE.ASM.IEBCOPY
as a VS dataset. IEBCOPY created it
this way and it also choosed the LRECL
and the BLKSIZE. For what I understand
IEBCOPY build its own DCB at runtime,
computed from the input PDS DCB.
IEBCOPY output datasets are VS datasets,
not VB datasets, its program internal DCB drive
that, even specifying a DCB from the
JCL DD card wouldn't do anything different.

The iebcopy output dataset showing as VS is
fine, *so long as* the blocksize is big enough
such that it is really V, not VS. Make sure
your PDS has a sensible blocksize, like
6160.

Then, when you are using copyfile to *write*
a V dataset, give it a V dataset, not VS.
IEBCOPY will accept a V, and even if it
doesn't, you can do a DCB override to turn
the V into VS.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
such that it is really V, not VS. Make sure
your PDS has a sensible blocksize, like
6160.

ie try reallocating your ASM dataset so that
it is a reasonable size. If you insist on having
an ASM with a large blocksize, and then you
insist on unloading to a 2314 drive, IEBCOPY
has no choice but to span the records, and
when you're dealing with real spanned records,
PDPCLIB, and thus COPYFILE, may not work.

I suggest getting something working before
testing to see what copyfile does with spanned
records on input and/or output.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
such that it is really V, not VS. Make sure
your PDS has a sensible blocksize, like
6160.

ie try reallocating your ASM dataset so that
it is a reasonable size. If you insist on having
an ASM with a large blocksize, and then you
insist on unloading to a 2314 drive, IEBCOPY
has no choice but to span the records, and
when you're dealing with real spanned records,
PDPCLIB, and thus COPYFILE, may not work.

I suggest getting something working before
testing to see what copyfile does with spanned
records on input and/or output.

---

Ok, Paul, many of the errors I've seen from
SUPA came from this misunderstand, I guess.

I assumed SUPA was able to manage IEBCOPY VS native datasets,
it doesn't, SUPA may only handle them as V datsets,
assuming there are NOT spanned records into the dataset,
i.e. assuming BLKSIZE is large enough to accomodate
each record in a SINGLE block.

This should be equivalent to assume each block in
the IEBCOPY native VS output dataset contains one and only one record,
i.e. records don't span a single RDW across two distinct blocks,
[(BDW1,RDW1),(BDW2,RDW2)], RDW=RDW1+RDW2.

Do I understand correctly, now?

By the way, I've no reasons to insist storing
IEBCOPY over a 2314 with a small BLKSIZE beside
the goal which drived me.

And the goal was exactly to constraint IEBCOPY
to really SPAN records into the VS dataset
to test my VS2FB/FS2VS, and SUPA, over such
datasets.

In real life I may have used a 3390/3380
and I wouldn't have seen what now I've seen,
Paul.

Things are beginning to be more clear now
and I'm beginning to understand where my
problems with IEBCOPY datasets came.

By the way. The way IEBCOPY choose
LRECL,BLKSIZE from the input PDS
DCB is documented by IBM for a modern ZOS:

https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.idau100/unldds.htm

and this note:

"Note: Applications reading an unload data set should be aware that for
RECFM=VS data sets, the actual length of an assembled logical record could
exceed 32760 bytes, even if the LRECL was reduced to 32760 by this step."

may really become a problem for SUPA, as, for what
I can understand, an IEBCOPY coming from a ZOS may
contains records longer of 32760, the maximum BLKSIZE
MVS3.8j may handle, if I understood correctly.

We have no control over how and when IEBCOPY decide
to SPAN a very long record and restoring such an
IEBCOPY VS dataset as a V dataset, may be impossible,
a real BET each time for each IEBCOPY dataset.

I do not like betting, Paul.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
We have no control over how and when IEBCOPY decide
to SPAN a very long record and restoring such an
IEBCOPY VS dataset as a V dataset, may be impossible,
a real BET each time for each IEBCOPY dataset.
I do not like betting, Paul.

From what I remember, somitcw has stated that for
our systems, IEBCOPY VS datasets are actually
really V.

Although I think that assumes that you're not
taking the LRECL to the edge of what the
disk supports.

But the fundamental point is that our IEBCOPY
doesn't split blocks for fun, and so long as you
have a reasonable LRECL on your source
dataset, it shouldn't be spanning records.

And if you ensure that the records aren't
spanned, copyfile appears to work, and
at least for input will accept a VS dataset
and treat it like V. Your experiments suggest
that it can't handle VS for an output dataset
though, at least in some circumstances.
This is not surprising as I've never tested
spanning and I'm not advertising it as
working.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
We have no control over how and when IEBCOPY decide
to SPAN a very long record and restoring such an
IEBCOPY VS dataset as a V dataset, may be impossible,
a real BET each time for each IEBCOPY dataset.
I do not like betting, Paul.

From what I remember, somitcw has stated that for
our systems, IEBCOPY VS datasets are actually
really V.

Although I think that assumes that you're not
taking the LRECL to the edge of what the
disk supports.

But the fundamental point is that our IEBCOPY
doesn't split blocks for fun, and so long as you
have a reasonable LRECL on your source
dataset, it shouldn't be spanning records.

And if you ensure that the records aren't
spanned, copyfile appears to work, and
at least for input will accept a VS dataset
and treat it like V. Your experiments suggest
that it can't handle VS for an output dataset
though, at least in some circumstances.
This is not surprising as I've never tested
spanning and I'm not advertising it as
working.

BFN. Paul.

---

Fine, as long as I understand what is going
on, and now I think I understand, Paul.

If I may give an advice, it would be a good
idea to support VS datasets in SUPA, so,
under any version of MVS, even on a modern
ZOS, SUPA would be able to manage them
in the correct way.

An alternative is to "refuse" to fopen()
a VS dataset, with a nice error to the
user, while SUPA doesn't support VS
datasets. Only God knows what SUPA
read or, worse, write from or into
a VS dataset, as SUPA is now.

Thanks for all the insights you gave
to me Paul, and for all the tests
you have done.

In the meanwhile I'll go ahead with my VS2FB/FB2VS tools,
using, as you have done in SUPA, x00 as an EOF marker,
in any case is a good exercise for my assembler and
MVS skills, beside I'll actually use them or
COPYFILE.

It is a nice way to be compatible with
other MVS tools around, like IND$FILE
and hetget. I didn't get that fact
while I was thinking to a 0xFF EOF.

It remains the point a logical EOF
is needed in the FB dataset, when
the VS dataset length doesn't perfectly
fit a multiple of the FB LRECL.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I may give an advice, it would be a good
idea to support VS datasets in SUPA, so,
under any version of MVS, even on a modern
ZOS, SUPA would be able to manage them
in the correct way.

Yes, that's one of many enhancements I could
name, but it's not high on my priority list.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
An alternative is to "refuse" to fopen()
a VS dataset, with a nice error to the
user, while SUPA doesn't support VS
datasets. Only God knows what SUPA
read or, worse, write from or into
a VS dataset, as SUPA is now.

Well I don't want to add that enhancement
yet, as I would prefer the other enhancement
of properly supporting VS. Also, VS does
work on read I believe, so long as you give
it non-spanned data, which is what I really
deal with.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
In the meanwhile I'll go ahead with my VS2FB/FB2VS tools,
using, as you have done in SUPA, x00 as an EOF marker,
in any case is a good exercise for my assembler and
MVS skills, beside I'll actually use them or
COPYFILE.

I don't think you should call it a marker. You
simply pad an F80 file with 0-79 NUL
characters as required by the F80 format
and in accordance with what C90 allows.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
It is a nice way to be compatible with
other MVS tools around, like IND$FILE
and hetget. I didn't get that fact
while I was thinking to a 0xFF EOF.

Well, be careful there, as IND$FILE was
influenced by PDPCLIB and hetget -b is
specific to Hercules/380. So that's a bit of
a circular argument.

However, IBM has an "rdw" option on ftp
which produces the same result of just
RDWs, but it only works going from
mainframe to PC. I have already asked
them to make it go both ways:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=63596

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I may give an advice, it would be a good
idea to support VS datasets in SUPA, so,
under any version of MVS, even on a modern
ZOS, SUPA would be able to manage them
in the correct way.

Yes, that's one of many enhancements I could
name, but it's not high on my priority list.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
An alternative is to "refuse" to fopen()
a VS dataset, with a nice error to the
user, while SUPA doesn't support VS
datasets. Only God knows what SUPA
read or, worse, write from or into
a VS dataset, as SUPA is now.

Well I don't want to add that enhancement
yet, as I would prefer the other enhancement
of properly supporting VS. Also, VS does
work on read I believe, so long as you give
it non-spanned data, which is what I really
deal with.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
In the meanwhile I'll go ahead with my VS2FB/FB2VS tools,
using, as you have done in SUPA, x00 as an EOF marker,
in any case is a good exercise for my assembler and
MVS skills, beside I'll actually use them or
COPYFILE.

I don't think you should call it a marker. You
simply pad an F80 file with 0-79 NUL
characters as required by the F80 format
and in accordance with what C90 allows.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
It is a nice way to be compatible with
other MVS tools around, like IND$FILE
and hetget. I didn't get that fact
while I was thinking to a 0xFF EOF.

Well, be careful there, as IND$FILE was
influenced by PDPCLIB and hetget -b is
specific to Hercules/380. So that's a bit of
a circular argument.

However, IBM has an "rdw" option on ftp
which produces the same result of just
RDWs, but it only works going from
mainframe to PC. I have already asked
them to make it go both ways:

https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=63596

---

Paul, I understand you have your own priorities and that your work is a
"free gift". I just gave an humble hint that may be useful for future
users and will probably avoid future discussions on this list about
SUPA/COPYFILE/IEBCOPY spanned records datasets topics. Of course, you are
free to read it as you prefer, Paul.

I've also noticed IND$FILE is compiled with GCC370 and uses PDPCLIB/SUPA,
so it is not an accident it behaves quite in the same way of COPYFILE and
I can see ways to use this nice behaviour, now I know about it.

But the NULL pad at the tail of the last card of an FB dataset IT IS
actually a logical EOF mark inserted into the data stream.

Try to pad with 0x40, SPACE padding, as I naively did in my first VS2FB
version, and get some fun from what happens when an RDW=0x4040 (16448 half
word) is being read from the last record of the FB dataset, if you don't
check in your logic for a 0x40404040 invalid full word RDW value, which
again happens to be a not valid RDW full word value.

Again it is a damned EOF mark. The fact you pad with 0x00000000, with
0x40404040, with 0xFFFFFFFF or with any other not valid value for an RDW,
it is just an arbitrary choice. While there are rationals for the 0x00 pad
(it makes the code simpler) any other choice would be as good as a NULL
padding, when the RDW field just contains zeros in the low half word and
can't be zero on the high half word.

In any case, you need a "mark" which tell you are at end of a "logical
stream of data", when the V[x] dataset records doesn't perfectly "fit" the
last FB record and the last record contains data which have to be
discarded by the program logic, which translates in a COMPARE for an
invalid RDW and a BRANCH in the 370 machine code.

You may name this "mark" as you like.

I will always think to this "mark" as a logical End-Of-File. Period.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I understand you have your own priorities and that your work is a
"free gift". I just gave an humble hint that may be useful for future
users and will probably avoid future discussions on this list about
SUPA/COPYFILE/IEBCOPY spanned records datasets topics. Of course, you are
free to read it as you prefer, Paul.

Well in this case Gerhard has taken a look at
the code and suggested a fix, so I am happy
to try it out. I'm in the process of doing that
at the moment in a controlled manner (by
rebuilding GCCMVS which acts as my
testsuite).

It's a volunteer project, and the apparent
bug is in code I am not familiar with, so
things happen at random.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But the NULL pad at the tail of the last card of an FB dataset IT IS
actually a logical EOF mark inserted into the data stream.

This "mark" may be 0 bytes long. Or it may be 1
byte long. It's strange to call something that
doesn't even exist (0 bytes long) as a "EOF
mark".

But it's a semantic debate. So long as you put
0 or 1 byte when appropriate, rather than
deliberately generating a 4-byte null RDW, you
can call it whatever you want. :-)

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, I understand you have your own priorities and that your work is a
"free gift". I just gave an humble hint that may be useful for future
users and will probably avoid future discussions on this list about
SUPA/COPYFILE/IEBCOPY spanned records datasets topics. Of course, you are
free to read it as you prefer, Paul.

Well in this case Gerhard has taken a look at
the code and suggested a fix, so I am happy
to try it out. I'm in the process of doing that
at the moment in a controlled manner (by
rebuilding GCCMVS which acts as my
testsuite).

It's a volunteer project, and the apparent
bug is in code I am not familiar with, so
things happen at random.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But the NULL pad at the tail of the last card of an FB dataset IT IS
actually a logical EOF mark inserted into the data stream.

This "mark" may be 0 bytes long. Or it may be 1
byte long. It's strange to call something that
doesn't even exist (0 bytes long) as a "EOF
mark".

---

Actually, Paul, may be 0,1,2,3 bytes long, the
remaind of the euclidean division of a natural
integer by 4, the length of the RDW field.

If it happens it has length=0, the "logical mark"
collapse into the "physical EOF mark", MVS hide
at the end of ANY dataset.

If it doesn't, it MUST be present in the FB stream
with length=1,2,3.

In any case the code MUST have a check for this
"logical mark", otherwise the code will be happy
to write records which doesn't actually exist as
it can't anticipate the value of the eclidean
division in any way.

Call it as you like. Do you have a better name
to assign? ;-)

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Call it as you like. Do you have a better name
to assign? ;-)

Yes, a better name is "my application is tolerant
of any number of NUL padding bytes at the end
of the input dataset".

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

By the way, at the light of what I've seen so far,
I tried another interesting path, it probably worth
to be reported here and probably on a list followed
by Mike Rayborn, the IND$FILE author (anyone knows
if is it possible to contact him?)

I created an IEBCOPY VS dataset, a PEPPE.ASM PDS UNLOAD again,
which "shouldn't" contains spanned records, as it
has a DCB=(RECFM=VS,LRECL=19056,BLKSIZE=19060), over
a 3390, named PEPPE.ASM.IEBCOPY2.

Then I downloaded, using IND$FILE, in binary, with RDW,
using IND$FILE-2.0.5 RDW option, the IEBCOPY dataset
PEPPE.ASM.IEBCOPY2 on my Linux, as the /tmp/Z1 file
and I verified the RDW were actually stored into the
file stream with an "xxd -E" dump.

I've then preallocated a DCB=(RECFM=V,LRECL=19056,BLKSIZE=19060) dataset,
named PEPPE.ASM.IEBCOPY3, on the same 3390, and I tried to upload, again
in binary, again with the IND$FILE RDW option, the /tmp/Z1 file to
the preallocated (large enough) PEPPE.ASM.IEBCOPY3 dataset.

Funny enough IND$FILE failed to write with the error:

IND$FILE ended with RC=20

I guess for a SUPA error, after the first few records.

Then I uploaded the /tmp/Z1 file into one of my PEPPE.ASM
(RECFM=FB,LRECL=80,BLKSIZE=19040) members, as PEPPE.ASM(Z1), again with
IND$FILE, again in binary, again with the RDW option, this time
succesfully, and the PEPPE.ASM(Z1) hex stream looked correct from REVIEW.

Using, from TSO, the last "copyfile" Paul sent me, I succesfully copied
with the command

copyfile -bb 'PEPPE.ASM(Z1)' 'PEPPE.ASM.IEBCOPY3"

the PEPPE.ASM(Z1) FB member, which looks correct, over the
PEPPE.ASM.IEBCOPY3, DCB=(RECFM=V,LRECL=19056,BLKSIZE=19060) dataset
and IEBCOPY had been LOADed succesfully the IEBCOPY3 RECFM=V dataset
into a new copy of my PEPPE.ASM PDS dataset.

Well, it looks to me IND$FILE-2.0.5 had been linked with an old
buggy version of SUPA routines, if it fails with an error, while COPYFILE
succeeed doing the very same job, OR it use some other different
way to write datasets.

If the first one would be the case, it would be really nice if IND$FILE
get linked with a new correct version of SUPA.

Using IND$FILE for directly upload/download IEBCOPY datasets, beside the
pending problem of VS IEBCOPY spanned record presence, would
be really a nice gift, which avoid any other conversion when
time to exchange IEBCOPY unload datasets come.

Well a nice gift for any MVS3.8j user, which has the habit
to work with RFE from a TSO session in a terminal emulator, like me
at least ;-) ... as it would allow to download/upload IEBCOPY datasets
in a very easy, and fast, at least with x3270, fashion.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Well, it looks to me IND$FILE-2.0.5 had been linked with an old
buggy version of SUPA routines, if it fails with an error, while COPYFILE
succeeed doing the very same job, OR it use some other different
way to write datasets.

Mike took a beta GCC/PDPCLIB and then
made his own modifications to PDPCLIB,
so I'm not sure what state that is in.

Really we're due for a proper release of
GCCMVS. It's been a very long time
between releases. But I'm still not done
with new development. And PDOS needs
to recover from TRKCALC still. :-)

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
We have no control over how and when IEBCOPY decide
to SPAN a very long record and restoring such an
IEBCOPY VS dataset as a V dataset, may be impossible,
a real BET each time for each IEBCOPY dataset.
I do not like betting, Paul.

I also think you are overstating the risk for z/OS.

Your link clearly says the LRECL will be:

16 bytes + the block size + the key length of the input data set

So all you need to do is ensure a reasonable
blocksize for your input dataset.

And your link also says (regarding the output
blocksize):

The block size value is then compared with the largest block size acceptable to the output device. If the output device capacity is smaller then the block size, it is set to the maximum allowed for the output device.

So all you need to do is ensure that you are
storing the output dataset on a reasonable
volume so that it has no reason to span.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I assumed SUPA was able to manage IEBCOPY VS native datasets,
it doesn't, SUPA may only handle them as V datsets,
assuming there are NOT spanned records into the dataset,
i.e. assuming BLKSIZE is large enough to accomodate
each record in a SINGLE block.

MVSSUPA was written so that @@AOPEN does a GETMAIN for the LRECL of a
V(B)S data set, and @@AREAD should assemble the logical record in that
area. Unless you are reading in block mode, the spanning should be
transparent. If it is not, there is a program error.

Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

(possible triple post due to Yahoo)

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I assumed SUPA was able to manage IEBCOPY VS native datasets,
it doesn't, SUPA may only handle them as V datsets,
assuming there are NOT spanned records into the dataset,
i.e. assuming BLKSIZE is large enough to accomodate
each record in a SINGLE block.

area. Unless you are reading in block mode, the spanning should be
transparent. If it is not, there is a program error.

Peppe has identified at least one program error,
but it is on output.

When destination is VS rather than V, then a
RDW of 19056, when written to:

//OUT DD DSN=&&TEMP2,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=VS,LRECL=19056,BLKSIZE=19060)

produces:

13.47.14 JOB 1 +MVSSUPA - @@AWRITE - invalid RECFM=Vxx request
13.47.14 JOB 1 +MVSSUPA - DD OUT
13.47.14 JOB 1 IEF450I HERC01A COPYFILE - ABEND S000 U0002
13.47.14 JOB 1 HERC01A COPYFILE COPYFILE AB 2

Bumping the LRECL and BLKSIZE up by 4 makes
the problem go away. Also using V instead of VS
makes the problem go away. So there appears to
be a calculation that is off by 4 bytes.

But fixing that is not a priority for me, and not
likely to be fixed with me maintaining the code
now. Note that the latest code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

If anyone can spot a one-line fix for the
above problem, I can make the change
and test it.

BFN. Paul.

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
When destination is VS rather than V, then a
//OUT DD DSN=&&TEMP2,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=VS,LRECL=19056,BLKSIZE=19060)
13.47.14 JOB 1 +MVSSUPA - DD OUT
13.47.14 JOB 1 IEF450I HERC01A COPYFILE - ABEND S000 U0002
13.47.14 JOB 1 HERC01A COPYFILE COPYFILE AB 2
Bumping the LRECL and BLKSIZE up by 4 makes
the problem go away. Also using V instead of VS
makes the problem go away. So there appears to
be a calculation that is off by 4 bytes.

After label WRITEVAT there is an LA R1,4(,R5); try zapping that to LA
R1,0(,R5) - I'll have to test this to confirm what it is supposed to be
doing.


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[[e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
After label WRITEVAT there is an LA R1,4(,R5); try zapping that to LA
R1,0(,R5) - I'll have to test this to confirm what it is supposed to be
doing.

Thanks for the fix, Gerhard. That does indeed
solve the problem, and Peppe, you may download
a new copyfile from here:

https://groups.yahoo.com/neo/groups/hercules-os380/files/copyfile.zip

that fixes your reported problem.

There may still be other problems related to VS
reading or writing, so if you have test data to
exercise copyfile, you may wish to report any
more anomalies to see if Gerhard has another
one line fix.

Speaking of which, Gerhard, the comment says:

- LA R1,4(,R5) GET RECORD + BDW LENGTH
+ LA R1,0(,R5) GET RECORD + BDW LENGTH

Should I change that to say just:

GET RECORD LENGTH

?

One thing though Peppe - I'm not sure if you
can take a spanned file, and then respan it
to a different blocksize and then still have
IEBCOPY happy with it. But if the LRECL
and BLKSIZE are the same input and
output, then I would expect that COPYFILE
should produce an identical output file if
the spanning code works. COPYFILE does
not do any trick like copying whole blocks
directly from input to output, so there's no
need to have an intermediate FB file.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]
After label WRITEVAT there is an LA R1,4(,R5); try zapping that to LA
R1,0(,R5) - I'll have to test this to confirm what it is supposed to be
doing.

Thanks for the fix, Gerhard. That does indeed
solve the problem, and Peppe, you may download
a new copyfile from here:

https://groups.yahoo.com/neo/groups/hercules-os380/files/copyfile.zip

that fixes your reported problem.

There may still be other problems related to VS
reading or writing, so if you have test data to
exercise copyfile, you may wish to report any
more anomalies to see if Gerhard has another
one line fix.

Speaking of which, Gerhard, the comment says:

- LA R1,4(,R5) GET RECORD + BDW LENGTH
+ LA R1,0(,R5) GET RECORD + BDW LENGTH

Should I change that to say just:

GET RECORD LENGTH

?

One thing though Peppe - I'm not sure if you
can take a spanned file, and then respan it
to a different blocksize and then still have
IEBCOPY happy with it. But if the LRECL
and BLKSIZE are the same input and
output, then I would expect that COPYFILE
should produce an identical output file if
the spanning code works. COPYFILE does
not do any trick like copying whole blocks
directly from input to output, so there's no
need to have an intermediate FB file.

---

Ok, Paul, with this version of copyfile, let me
call it, as a reference, "COPYFILE.R1"/03-31-18
(the previous one being "COPYFILE.R0"/03-30-18),
I had been able to copy our testcase "PEPPE.ASM(D3)",
the same member of the previous test, over PEPPE.ASM.IEBCOPY1,
DCB=(RECFM=VS,LRECL=19056,BLKSIZE=7294) (the same DCB
of the original IEBCOPY), with the command

copyfile -bb 'peppe.asm(D3)' 'peppe.asm.iebcopy1'
copying from file 'peppe.asm(D3)', mode binary
to file 'peppe.asm.iebcopy1', mode binary
912640 bytes copied

without any ABEND (but the number of bytes copied
looks wrong to my eyes, as it should be 912588, not
912640).

Unfortunately, the copy get scrambled. The DCB
changes from RECFM=VS to RECFM=VBS (WHY?) and, from a visual
inspection, PEPPE.ASM.IEBCOPY1, seems quite different
from the original.

IEBCOPY is not happy at all to have this dataset
as its input SYSUT1:

IEB139I I/O ERROR DURING LOAD - IEBLOAD ,LOAD ,120,DA,SYSUT1
,READ ,WRNG.LEN.RECORD,00000021000B01,BSAM

and terminates with:

IEBLOAD LOAD IEBCOPY RC= 0008

Well, at least COPYFILE.R1 doesn't ABEND U002 anymore, but it definitely
doesn't restore the original VS dataset, as we expected I think,
because this dataset IS a RECFM=VS and it CONTAINS real spanned records.

I can't test the D3 stream by now with my FB2VS, as I've
to change my code for the NULL EOF mark, from the 0xFF mark,
but I'll do as soon as I've done the change.

A side note. For what I've been reading of IEBCOPY,
from the IBM documentation, IEBCOPY use the SYSUT1 input
DCB info to compute the DCB of its SYSUT2 output dataset.

I think the damned IEBCOPY logic about this it is really
involved and it is really bad we don't have access to the IEBCOPY
source. It would be really nice to see how IEBCOPY go from
the input DCB to the output DCB.

So, in general, it shouldn't be a good idea to reblock
an IEBCOPY input dataset, doing a copy, as changing the input
DCB would change the output (LRECL,BLKSIZE).

As a conclusion, I think is "safer", when exchanging "native"
IEBCOPY VS input dataset, to exchange also their DCBs, as "guessing"
may not be a good idea.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Ok, Paul, with this version of copyfile, let me
call it, as a reference, "COPYFILE.R1"/03-31-18
(the previous one being "COPYFILE.R0"/03-30-18),

Can we use ISO dates?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
copyfile -bb 'peppe.asm(D3)' 'peppe.asm.iebcopy1'
copying from file 'peppe.asm(D3)', mode binary
to file 'peppe.asm.iebcopy1', mode binary
912640 bytes copied
without any ABEND (but the number of bytes copied
looks wrong to my eyes, as it should be 912588, not
912640).

It's based on the input file. copyfile doesn't
know that the NUL bytes written to the output
file are being quietly dropped.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Unfortunately, the copy get scrambled. The DCB
changes from RECFM=VS to RECFM=VBS (WHY?)

I think Gerhard would need to answer that.
Can you confirm that V stays as V instead
of being changed to VB, and that it is only
VS that changes to VBS?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
and, from a visual
inspection, PEPPE.ASM.IEBCOPY1, seems quite different
from the original.

Are you able to detect the first change?
Note that if you do a batch hexdump, using
a RECFM=U override for the input file,
we will see all the BDWs and RDWs. Or
you could use the override to use copyfile
to copy into a RECFM=U and then IND$FILE
can transfer it to the PC so that you can
use PC utilities.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IEBCOPY is not happy at all to have this dataset

Yes, I got the same error with your D3, but
I don't know what is causing that. I assume
that the original copyfile from the spanned
file is not assembling records correctly. But
it's possible that IEBCOPY somehow knows
which records are spanned and complains
when the spanning has been removed.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I can't test the D3 stream by now with my FB2VS, as I've
to change my code for the NULL EOF mark, from the 0xFF mark,
but I'll do as soon as I've done the change.

Ok, cool.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I think the damned IEBCOPY logic about this it is really
involved and it is really bad we don't have access to the IEBCOPY
source. It would be really nice to see how IEBCOPY go from
the input DCB to the output DCB.

Why do you think we don't have the source?
We have most source code. This appears to
be the IEBCOPY main module:

https://sourceforge.net/p/mvs380/mvssrc/ci/master/tree/asm/iebdscpy.asm

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
So, in general, it shouldn't be a good idea to reblock
an IEBCOPY input dataset, doing a copy, as changing the input
DCB would change the output (LRECL,BLKSIZE).
As a conclusion, I think is "safer", when exchanging "native"
IEBCOPY VS input dataset, to exchange also their DCBs, as "guessing"
may not be a good idea.

Well the safest thing to do is to not span.
But even with spanning, I would hope that
IEBCOPY was robust enough to handle
a reblocking depending on device type.
But LRECL should remain consistent, as
that is a reflection of the source PDS's
approximate block size.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
Are you able to detect the first change?

I have run my own test and detected a problem.

Here is the JCL:

//HERC01A JOB CLASS=C,REGION=0K
//*
//* Test COPYFILE
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-tt dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD *
0123456789
/*
//OUT DD DSN=&&TEMP1,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=VS,LRECL=100,BLKSIZE=12)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//HEXDUMP EXEC PGM=HEXDUMP,PARM='dd:in'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=&&TEMP1,DISP=(OLD,PASS),
// DCB=(RECFM=U,LRECL=0,BLKSIZE=1000)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//


And here is the output:

000000 000C0000 00080100 F0F1F2F3 000C0000 ........0123....
000010 00080300 F4F5F6F7 000A0000 00080200 ....4567........
000020 F8F9 89

The problem is that last x'0008'. It should be x'0006'.
The BDW has been correctly adjusted for the last
short (2 bytes of data) block but not the SDW.

The assembler code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

if you want to try to spot the logic flaw.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I have run my own test and detected a problem.

Note that this is the first time I have actually
tested spanned records and also note the
C code acts as a test driver for the assembler.

Post by ***@yahoo.com.au [hercules-os380]
000010 00080300 F4F5F6F7 000A0000 00080200 ....4567........

Note that that x'0200' is correctly identifying the
last segment. So most of the code is working.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
if you want to try to spot the logic flaw.

I think I have a fix myself. The second bunch
of these changes:

C:\devel\pdos\pdpclib>git diff mvssupa.asm
diff --git a/pdpclib/mvssupa.asm b/pdpclib/mvssupa.asm
index c7c76ad..ffce2f5 100644
--- a/pdpclib/mvssupa.asm
+++ b/pdpclib/mvssupa.asm
@@ -2585,7 +2585,7 @@ WRITEVAT L R9,BUFFEND GET BUFFER END
SR R9,R6 LESS CURRENT POSITION
TM ZRECFM,DCBRECSB SPANNED?
BZ WRITEVAR NO; ROUTINE VARIABLE WRITE
- LA R1,4(,R5) GET RECORD + BDW LENGTH
+ LA R1,0(,R5) GET RECORD + BDW LENGTH
C R1,ZPLRECL VALID SIZE? GP14233
BH WRITEBAD NO; TAKE A DIVE
TM IOPFLAGS,IOFLSDW CONTINUATION ?
@@ -2601,9 +2601,12 @@ WRITEVAW CH R9,=H'5' AT LEAST FIVE BYTES LEFT ?
LR R7,R5 USE ONLY WHAT'S AVAILABLE
MVCL R6,R4 COPY SDW + DATA
ST R6,BUFFCURR UPDATE NEXT AVAILABLE
+ LR R7,R6 r7 is free i think, not sure about r9
+* so save highwater mark
SR R6,R8 LESS START
STH R6,0(,R8) UPDATE BDW
- STH R9,0(,R3) FIX RDW LENGTH
+ SR R7,R3 get record length
+ STH R7,0(,R3) FIX RDW LENGTH
MVC 2(2,R3),=X'0100' SET FLAGS FOR START SEGMENT
OI IOPFLAGS,IOFLDATA SHOW WRITE DATA IN BUFFER GP14363
TM IOPFLAGS,IOFLSDW DID START ?

C:\devel\pdos\pdpclib>


Would someone like to review my work?

Original code is here still:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

And it is line 2606 that has the issue:

STH R9,0(,R3) FIX RDW LENGTH

It's not fixing the length, it's just storing how
many bytes were originally available in the
output buffer.

I'll have a new copyfile in a couple of hours
when the full rebuild has been done.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I think I have a fix myself.

You can see the new output here:

000000 000C0000 00080100 F0F1F2F3 000C0000 ........0123....
000010 00080300 F4F5F6F7 000A0000 00060200 ....4567........
000020 F8F9 89


BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I'll have a new copyfile in a couple of hours
when the full rebuild has been done.

New version now available:

https://groups.yahoo.com/neo/groups/hercules-os380/files/copyfile.zip

The normal notification email seems to have
disappeared randomly as randomly happens.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo)

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Unfortunately, the copy get scrambled. The DCB
changes from RECFM=VS to RECFM=VBS (WHY?)

I ran a testcase to see if I got the same effect,
and I did not. The output file stays as VS.

Here is the JCL:

//HERC01A JOB CLASS=C,REGION=0K
//*
//* Test COPYFILE
//*
//S1 EXEC PGM=IEFBR14
//DD1 DD DSN=HERC01.IEBCOPY,DISP=(MOD,DELETE),
// UNIT=SYSALLDA,SPACE=(TRK,(0))
//*
//S2 EXEC PGM=IEFBR14
//DD1 DD DSN=HERC01.IEBCOPY,DISP=(NEW,CATLG),
// UNIT=SYSALLDA,SPACE=(CYL,(1,1)),
// DCB=(RECFM=VS,LRECL=19056,BLKSIZE=19060)
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=HERC01.IN,UNIT=TAPE,VOL=SER=PCTOMF,
// DISP=OLD,LABEL=(1,NL),
// DCB=(RECFM=U,LRECL=0,BLKSIZE=32760)
//OUT DD DSN=&&TEMP1,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=FB,LRECL=80,BLKSIZE=32720)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=&&TEMP1,DISP=(OLD,PASS)
//OUT DD DSN=HERC01.IEBCOPY,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//


And here is what the file looks like after the above,
when viewed with RPF 3.4:

HERC01.IEBCOPY SEASIK 18.090 PS V S 19056 19060 2 30 8


BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Unfortunately, the copy get scrambled. The DCB
changes from RECFM=VS to RECFM=VBS (WHY?) and, from a visual
inspection, PEPPE.ASM.IEBCOPY1, seems quite different
from the original.

I did my own experiments with the latest COPYFILE
and got this difference:

C:\mvs380_work\copyfile2>diff temp1.txt temp2.txt | head
1c1
< 000000 003C0000 00380000 00CA6D0F 02004A7D .........._...▒'
---

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
000000 1C7E0000 00380000 00CA6D0F 02004A7D .=........_...▒'

ie the output file has become blocked, and
I don't think IEBCOPY will be happy about
that, especially the first record.

I was able to reproduce the problem with a
simple testcase:

//HERC01A JOB CLASS=C,REGION=0K
//*
//* Test COPYFILE
//*
//COPYFILE EXEC PGM=COPYFILE,PARM='-tt dd:in dd:out'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD *
0123456789
0123456789
/*
//OUT DD DSN=&&TEMP1,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=VS,LRECL=100,BLKSIZE=120)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//HEXDUMP EXEC PGM=HEXDUMP,PARM='dd:in'
//STEPLIB DD DSN=PDPCLIB.LINKLIB,DISP=SHR
//IN DD DSN=&&TEMP1,DISP=(OLD,PASS),
// DCB=(RECFM=U,LRECL=0,BLKSIZE=1000)
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//SYSIN DD DUMMY
//*
//

produces:

000000 00200000 000E0000 F0F1F2F3 F4F5F6F7 ........01234567
000010 F8F9000E 0000F0F1 F2F3F4F5 F6F7F8F9 89....0123456789

ie it has put two records into a single block.

So that's definitely a bug.

I tried to rectify the bug by writing to a RECFM=V,
but although that fixed the first record, IEBCOPY
still didn't like I think some other record, so I suspect
there is an additional bug somewhere.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

It looks Yahoo is loosing messages, again ;-(

Trying to post again, possibly a duplicate, apologies.

Post by ***@yahoo.com.au [hercules-os380]
I think I have a fix myself.

You can see the new output here:

000000 000C0000 00080100 F0F1F2F3 000C0000 ........0123....
000010 00080300 F4F5F6F7 000A0000 00060200 ....4567........
000020 F8F9 89


BFN. Paul.

---

Paul, this is a busy saturday here in Italy, a family Eastern saturday,
and, while I'm reading your posts, I can't do much to verify what you are
doing, by now.

But I'm positive about the fact my DCB,
(RECFM=VS,LRECL=19056,BLKSIZE=7294, different from your, change from VS to
VSB after copyfile run.

And yes, I tried to copyfile over a LRECL=19056,BLKSIZE=19060, 3090
instead of 2314, the RECFM doesn't change, it remains VS after a
successful copyfile, but IEBCOPY scream like a crazy about an I/O error.

By the way. I was reading ZOS forum about this problem and there people
assume such a download/upload of an IEBCOPY VS dataset is IMPOSSIBLE, they
assume an intermediate FB container, like the one provided by XMIT370, is
always needed, beside using IND$FILE or FTP (or tapes, like you are
doing).

Well, they may be wrong about the possibility to actually do the
download/upload, but I think they are right about the fact the original
IEBCOPY DCB info must be preserved in some way, by hand, writing
(LRECL,BLKSIZE) somewhere or automatically, writing it into a
container.

So, in the future, Paul, please, when you upload an IEBCOPY V[x] dataset,
like "copyfile.exe", please write somewhere the (LRECL,BLKSIZE) of
the original IEBCOPY dataset. This may make restoring a download
a little bit easier.

As I already wrote, I don't like betting and I don't like guessing.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But I'm positive about the fact my DCB,
(RECFM=VS,LRECL=19056,BLKSIZE=7294,
different from your, change from VS to
VSB after copyfile run.

Ok, I have new information on that too. It stays
as VS only if the BLKSIZE = LRECL + 4. Otherwise
it blocks. ie either bigger or smaller it will block.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
So, in the future, Paul, please, when you upload an IEBCOPY V[x] dataset,
like "copyfile.exe", please write somewhere the (LRECL,BLKSIZE) of
the original IEBCOPY dataset. This may make restoring a download
a little bit easier.

But that's exactly the complication I don't want.
I want distributing MVS executables to be the
same as distributing Windows executables.

I always use reasonable blocksizes so that it
never spans.

And so long as it never spans, you should be able
to copy into the largest LRECL & BLKSIZE you can,
ie LRECL=32756,BLKSIZE=32760, and then it will
always work.

Is that not good enough?

Another option is you could run rdwcheck over the
file and find out the minimum LRECL you need
that way.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

And so long as it never spans, you should be able
to copy into the largest LRECL & BLKSIZE you can,
ie LRECL=32756,BLKSIZE=32760, and then it will
always work.

Is that not good enough?

Another option is you could run rdwcheck over the
file and find out the minimum LRECL you need
that way.

---

What you do for your own, Paul, is one thing, when
you try to share what you do, remember people
do not read your brain, people read what is
plainly written somewhere, eventually, as it
happens often people don't even read what is
already clearly written.

As always, is just an humble hint, Paul, an
hint which would probably shortcut discussions
and avoid troubles and misunderstandings.

Another humble hint, Paul. Although I understand
how easy is to create and download a VS IEBCOPY
output dataset, it is not an "easy" exchange media
under MVS.

I would strongly advice you to use XMIT370
instead than the native IEBCOPY data stream,
strictly uploading FB datasets.

You have created an interesting problem, Paul,
with your preference for V[x] and U datasets,
but you didn't make things easy for naive MVS users.

I may understand you may assume knowledge in this
group, Paul. It is your group, where you mainly
follow your interests, but you use the same
strategy in "all" the hercules group.

I'm starting to understand the MVS access methods
complexity just now, after five years of
experience and I've to admit a large number
of my tests came from trying to "unpack"
datasets you have shared in various formats
on many hercules groups.

You may have spared me a lot of time clearly
explaining how you created your datasets and
how is possible to restore them, in the style
Jay Moseley uses on his Web site, I'm sure
even you appreciated trying to generate MVS.

You didn't, I learned a lot from these experiments
and tests, I'm grateful anyway to you for your
efforts and time.

I hope we will remain in touch, in all the
hercules groups, Paul, beside my naive
advices.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I would strongly advice you to use XMIT370
instead than the native IEBCOPY data stream,
strictly uploading FB datasets.

The official release of COPYFILE is part of
GCCMVS, and that is indeed an XMIT. I provide
JCL to create and restore that.

The official release of BREXX etc is a DFDSS
dump dataset, and that is indeed in RDW format,
but I have instructions there to use COPYFILE.

For unofficial betas of anything I produce, it is
very easy for me to type in "lm2pe" to get an
executable. I don't need to construct JCL to
produce an XMIT. And I have a "pe2lm" to
restore an executable. I think these things
are what is simple. I don't see why an XMIT
should be simpler when dealing with a
single executable.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
You have created an interesting problem, Paul,
with your preference for V[x] and U datasets,
but you didn't make things easy for naive MVS users.

Actually I was inspired by a naive MVS user
years ago who did an IND$FILE of a module
from a linklib and attempted to take it
somewhere and it didn't work. I haven't
totally solved that problem, but it's something
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format
which can indeed be copied with a normal
IND$FILE.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
You may have spared me a lot of time clearly
explaining how you created your datasets and
how is possible to restore them, in the style
Jay Moseley uses on his Web site, I'm sure
even you appreciated trying to generate MVS.

Ok. This is the first time anyone has asked
for such a thing. I have certainly explained
things in messages here before, and I have
told people they need to use copyfile to
handle my unofficial distributions. I don't
know much about creating web pages, so
tend to do things in text format, and you can
see that I have explained about RDW format here:

http://mvs380.sourceforge.net/System380.txt

It includes this line:

If RDW-format data is stored in RECFM=U and you want to move it into its natural format, then use COPYFILE (with -bb option) to do that.

But I can see that I have failed to document the
"PE format" executable. Is adding a paragraph
there sufficient?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
For unofficial betas of anything I produce, it is
very easy for me to type in "lm2pe" to get an
executable. I don't need to construct JCL to
produce an XMIT. And I have a "pe2lm" to
restore an executable. I think these things
are what is simple. I don't see why an XMIT
should be simpler when dealing with a
single executable.

I have been thinking about this some more.

It is normal for there to be an "executable format"
which has a whole lot of stuff at the front. Whether
it is a.out format or Windows PE format or MSDOS
format.

The MVS load module format also has this, but
there are two problems:

1. Some of the necessary data is stored in the PDS
directory.

2. It relies on the hardware to provide the record
separators.

IEBCOPY solves both of these problems and is
the official way of encapsulating a load module,
even if you later use XMIT and maybe TERSE
to compress it.

So the IEBCOPY format looks like what is
required to bring MVS load modules into sync
with what a Unix/Windows person would
expect.

Remember that I am selling MVS to Unix/Windows
people, not the reverse.

You could argue that I should then add an extra
layer on top of the IEBCOPY format, the XMIT
layer. So I could have a hexdump.exe that is
actually an XMIT. But handling XMIT is quite
difficult. It is designed to work at a dataset
level, so it names an actual dataset. What
dataset would that be? SYS2.LINKLIB? I only
want to transport a single load module.

So I would need to copy from SYS2.LINKLIB
into some temporary dataset, and then XMIT
that. I can't use a normal temporary dataset,
I would need to name it HERC01 or
something for XMIT to be able to handle it.

It gets real complicated real fast.

If there was some utility that went directly
from an XMIT to an MVS load module, then
we could use XMIT and ignore the dataset
name contained within the XMIT. But we
don't have such a utility, and even if we did,
is this the right way to go, adding another
layer? We may as well add the TERSE
layer.

And remembering that all the while we have
an IEBCOPY layer inside the XMIT which we
can't eliminate.

So that is why my (long term) goal at the moment
is to be able to change from using lm2pe into
mf2pc:

C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe

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


I don't think that executables should be transported
different from other files, other than they need to be
in binary mode.

That is something that I wish to sell to Unix programmers
who I want to target MVS for their freeware. I want to be
able to say that MVS is just as simple as Unix, there's
just some minor semantical differences. But currently
that is not the case. Currently you can't just ftp a load
module in binary mode and get anything usable. That
is quite odd.

I have another plan as well. I wish to write my own
linker that directly produces an IEBCOPY unload
format executable. Unix programmers can then
take that file and ftp it or whatever. However, I will
tell them that if they want to *run* that executable,
they first need to *install* it, just like they typically
do on Unix. And I'll just tell them that the install
process is different on MVS in that you can't
easily go from an installed module back to a
transportable module, but why would you need to
do that anyway, when you just built the
transportable module!

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

Why don't you try installing z390 and dumping a ESA390 program stored
on a Windows / Linux system?

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
For unofficial betas of anything I produce, it is
very easy for me to type in "lm2pe" to get an
executable. I don't need to construct JCL to
produce an XMIT. And I have a "pe2lm" to
restore an executable. I think these things
are what is simple. I don't see why an XMIT
should be simpler when dealing with a
single executable.

I have been thinking about this some more.
It is normal for there to be an "executable format"
which has a whole lot of stuff at the front. Whether
it is a.out format or Windows PE format or MSDOS
format.
The MVS load module format also has this, but
1. Some of the necessary data is stored in the PDS
directory.
2. It relies on the hardware to provide the record
separators.
IEBCOPY solves both of these problems and is
the official way of encapsulating a load module,
even if you later use XMIT and maybe TERSE
to compress it.
So the IEBCOPY format looks like what is
required to bring MVS load modules into sync
with what a Unix/Windows person would
expect.
Remember that I am selling MVS to Unix/Windows
people, not the reverse.
You could argue that I should then add an extra
layer on top of the IEBCOPY format, the XMIT
layer. So I could have a hexdump.exe that is
actually an XMIT. But handling XMIT is quite
difficult. It is designed to work at a dataset
level, so it names an actual dataset. What
dataset would that be? SYS2.LINKLIB? I only
want to transport a single load module.
So I would need to copy from SYS2.LINKLIB
into some temporary dataset, and then XMIT
that. I can't use a normal temporary dataset,
I would need to name it HERC01 or
something for XMIT to be able to handle it.
It gets real complicated real fast.
If there was some utility that went directly
from an XMIT to an MVS load module, then
we could use XMIT and ignore the dataset
name contained within the XMIT. But we
don't have such a utility, and even if we did,
is this the right way to go, adding another
layer? We may as well add the TERSE
layer.
And remembering that all the while we have
an IEBCOPY layer inside the XMIT which we
can't eliminate.
So that is why my (long term) goal at the moment
is to be able to change from using lm2pe into
C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe
C:\>mf2pc
Usage example: mf2pc PDPCLIB.DOC(PDPGOAL) pdpgoal.txt [ascii]
I don't think that executables should be transported
different from other files, other than they need to be
in binary mode.
That is something that I wish to sell to Unix programmers
who I want to target MVS for their freeware. I want to be
able to say that MVS is just as simple as Unix, there's
just some minor semantical differences. But currently
that is not the case. Currently you can't just ftp a load
module in binary mode and get anything usable. That
is quite odd.
I have another plan as well. I wish to write my own
linker that directly produces an IEBCOPY unload
format executable. Unix programmers can then
take that file and ftp it or whatever. However, I will
tell them that if they want to *run* that executable,
they first need to *install* it, just like they typically
do on Unix. And I'll just tell them that the install
process is different on MVS in that you can't
easily go from an installed module back to a
transportable module, but why would you need to
do that anyway, when you just built the
transportable module!
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-os380]]

(possible double post due to yahoo)

Post by Mike Schwab ***@gmail.com [hercules-os380]
Why don't you try installing z390 and dumping
a ESA390 program stored on a Windows / Linux system?

For what purpose?

And by "dumping" do you mean "analyzing", with
a view to copying?

If z390 has its own special format for executables,
that's fine, but I don't see any way that it is going
to be superior to the (relative) simplicity of IEBCOPY.

Out of all the things to standardize on, I think
IEBCOPY is the superior choice.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"That is something that I wish to sell to Unix programmers
who I want to target MVS for their freeware. I want to be
able to say that MVS is just as simple as Unix, there's
just some minor semantical differences."

What makes you think that anyone is going to allow UNIX "freeware" to
pollute a clean z/OS system? I'd be willing to bet that it won't even be
compatible with system security on z/OS.

Joe

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
For unofficial betas of anything I produce, it is
very easy for me to type in "lm2pe" to get an
executable. I don't need to construct JCL to
produce an XMIT. And I have a "pe2lm" to
restore an executable. I think these things
are what is simple. I don't see why an XMIT
should be simpler when dealing with a
single executable.

I have been thinking about this some more.
It is normal for there to be an "executable format"
which has a whole lot of stuff at the front. Whether
it is a.out format or Windows PE format or MSDOS
format.
The MVS load module format also has this, but
1. Some of the necessary data is stored in the PDS
directory.
2. It relies on the hardware to provide the record
separators.
IEBCOPY solves both of these problems and is
the official way of encapsulating a load module,
even if you later use XMIT and maybe TERSE
to compress it.
So the IEBCOPY format looks like what is
required to bring MVS load modules into sync
with what a Unix/Windows person would
expect.
Remember that I am selling MVS to Unix/Windows
people, not the reverse.
You could argue that I should then add an extra
layer on top of the IEBCOPY format, the XMIT
layer. So I could have a hexdump.exe that is
actually an XMIT. But handling XMIT is quite
difficult. It is designed to work at a dataset
level, so it names an actual dataset. What
dataset would that be? SYS2.LINKLIB? I only
want to transport a single load module.
So I would need to copy from SYS2.LINKLIB
into some temporary dataset, and then XMIT
that. I can't use a normal temporary dataset,
I would need to name it HERC01 or
something for XMIT to be able to handle it.
It gets real complicated real fast.
If there was some utility that went directly
from an XMIT to an MVS load module, then
we could use XMIT and ignore the dataset
name contained within the XMIT. But we
don't have such a utility, and even if we did,
is this the right way to go, adding another
layer? We may as well add the TERSE
layer.
And remembering that all the while we have
an IEBCOPY layer inside the XMIT which we
can't eliminate.
So that is why my (long term) goal at the moment
is to be able to change from using lm2pe into
C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe
C:\>mf2pc
Usage example: mf2pc PDPCLIB.DOC(PDPGOAL) pdpgoal.txt [ascii]
I don't think that executables should be transported
different from other files, other than they need to be
in binary mode.
That is something that I wish to sell to Unix programmers
who I want to target MVS for their freeware. I want to be
able to say that MVS is just as simple as Unix, there's
just some minor semantical differences. But currently
that is not the case. Currently you can't just ftp a load
module in binary mode and get anything usable. That
is quite odd.
I have another plan as well. I wish to write my own
linker that directly produces an IEBCOPY unload
format executable. Unix programmers can then
take that file and ftp it or whatever. However, I will
tell them that if they want to *run* that executable,
they first need to *install* it, just like they typically
do on Unix. And I'll just tell them that the install
process is different on MVS in that you can't
easily go from an installed module back to a
transportable module, but why would you need to
do that anyway, when you just built the
transportable module!
BFN. Paul.

[[e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
That is something that I wish to sell to Unix programmers
who I want to target MVS for their freeware. I want to be
able to say that MVS is just as simple as Unix, there's
just some minor semantical differences.

What makes you think that anyone is going
to allow UNIX "freeware" to pollute a clean
z/OS system? I'd be willing to bet that it
won't even be compatible with system
security on z/OS.

Such policies are beyond my scope. I wish to
produce freeware such as GCCMVS and
SEASIK regardless.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

You could argue that I should then add an extra
layer on top of the IEBCOPY format, the XMIT
layer. So I could have a hexdump.exe that is
actually an XMIT. But handling XMIT is quite
difficult. It is designed to work at a dataset
level, so it names an actual dataset. What
dataset would that be? SYS2.LINKLIB? I only
want to transport a single load module.

---

Paul, you seem to forget XMIT370 just add an "extra FB layer"
to the IEBCOPY VS native output dataset, that, under
the cover, it is still the IBM IEBCOPY utility which perform the
"dirty task" of UNLOADing a PDS content into a VS dataset,
in the best way IBM knows how this task has to be performed.

XMIT370 just do what I'm trying to do, as an assembler
exercise with VS2FB, but in a really more sophisticated way, i.e.
it stores the IEBCOPY VS output SYSUT2 dataset into
its (RECFM=FB,LRECL=80,BLKSIZE=3200) XMITOUT dataset
and I guess it also adds all the info which then RECV370
needs to restore the IEBCOPY VS dataset from its
XMITIN FB datset, before, again, calling IEBCOPY to
perform the task.

As an example this JCL stream:

//XMITSEL JOB (PEPPE),'IEB',CLASS=A,MSGCLASS=X,NOTIFY=PEPPE
// REGION=0K
//*
//XMIT EXEC PGM=XMIT370
//SYSUT1 DD DISP=SHR,DSN=PEPPE.LINKLIB
//SYSUT2 DD DISP=(,DELETE,DELETE),DSN=&&SYSUT2,
// SPACE=(TRK,(600,150)),
// UNIT=SYSALLDA
//SYSPRINT DD SYSOUT=*
//XMITLOG DD SYSOUT=*
//XMITOUT DD DISP=(,CATLG),DSN=PEPPE.IEBCOPY.XMIT,
// SPACE=(TRK,(600,150)),
// UNIT=SYSALLDA
//SYSIN DD *
COPY INDD=((SYSUT1,R)),OUTDD=SYSUT2
SELECT MEMBER=SORT
/*

directly call XMIT370 to store the "SORT" load module,
and ONLY the SINGLE "SORT load module", from my "PEPPE.LINKLIB"
dataset, which contains a LARGE number of modules, into its
XMITOUT (RECFM=FB,LRECL=80,BLKSIZE=3200) PEPPE.IEBCOPY.XMIT dataset,
basically passing SYSIN directly to IEBCOPY, as the job output show:

IEB167I FOLLOWING MEMBER(S) UNLOADED FROM INPUT DATA SET REFERENCED BY SYSUT1 -
IEB154I SORT HAS BEEN SUCCESSFULLY UNLOADED
IEB147I END OF JOB -00 WAS HIGHEST SEVERITY CODE

where IEBCOPY, and note it is IEBCOPY speaking, confirm is UNLOADING just
SORT, and nothing else, from my PEPPE.LINKLIB load library.

Then this JCL stream execute RECV370:

//RECVSEL JOB (PEPPE),'IEB',CLASS=A,MSGCLASS=X,NOTIFY=PEPPE,
// REGION=0K
//*
//RECV EXEC PGM=RECV370
//SYSUT1 DD DISP=(,DELETE,DELETE),DSN=&&SYSUT1,
// SPACE=(TRK,(600,150)),
// UNIT=SYSALLDA
//SYSUT2 DD DISP=SHR,DSN=PEPPE.IEBCOPY.TESTLIB
//SYSPRINT DD SYSOUT=*
//RECVLOG DD SYSOUT=*
//XMITIN DD DISP=SHR,DSN=PEPPE.IEBCOPY.XMIT
//SYSIN DD DUMMY

asking RECV370 to convert the "XMITIN DD DSN=PEPPE.IEBCOPY.XMIT"
XMIT370 FB dataset into a suitable SYSUT1 IEBCOPY VS dataset, I guess
identical to the XMIT370 SYSUT2 temporary dataset, not really
different from what my FB2VS do in a simpler way, but "probably"
reading PRECIOUS informations XMIT370 has stored into the data stream
about the IEBCOPY VS DCB.

(Note the RECV370 SYSIN is an empty DUMMY datset here, but, again
it may be any valid IEBCOPY SYSIN, as I bet, again is passed
directly to IEBCOPY, you may want to test this point).

Then the real job of RECV370 is actually done and I bet now RECV370 calls
IEBCOPY to restore the contents of SYSUT1 into SYSUT2, in
this case an already existing load library, i.e. PEPPE.IEBCOPY.TESTLIB.

And here it is the output of the RECVSEL job, Paul:

IEB167I FOLLOWING MEMBER(S) LOADED FROM INPUT DATA SET REFERENCED BY SYSUT1 -
IEB154I SORT HAS BEEN SUCCESSFULLY LOADED
IEB144I THERE ARE 0000144 UNUSED TRACKS IN OUTPUT DATA SET REFERENCED BY SYSUT2
IEB149I THERE ARE 0000255 UNUSED DIRECTORY BLOCKS IN OUTPUT DIRECTORY

which I think proves my picture is basically correct, as also proved
from the SORT load modules correctly restored, by IEBCOPY, not
by RECV370, into my PEPPE.IEBCOPY.TESTLIB:

NAME SSI SIZE TTR ALIAS-OF AC -- --
.. SORT 1K 0000A0 000521 IERRCO00 00 DC EP0

Making the thing simpler, XMIT370 calls IEBCOPY which reads
its commands from SYSIN and UNLOAD to SYSUT1(VS), XMIT370 then takes
SYSUT1(VS) and converts to XMITOUT(FB). From the other side
RECV370 converts its XMITIN(FB) into its SYSUT1(VS), then calls
IEBCOPY which LOAD SYSUT1(VS) to the final PDS SYSUT2, with whatever DCB
it is suitable for the data to be LOADED.

In other words, XMIT370/RECV370 basically, for UNLOADING/LOADING
PDS, and PDS selected members, behaves AS IEBCOPY, because it
is IEBCOPY which perform the task, but converting to and from
easier to manage and exchange FB datasets.

Now, Paul, please, explain me where is the difference with what
you are doing with native IEBCOPY VS output datasets, which just
makes the damn thing more complex to manage, at least for a naive
user, as I'm?

My 2 cents, Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, you seem to forget XMIT370 just add an "extra FB layer"
to the IEBCOPY VS native output dataset, that, under
the cover, it is still the IBM IEBCOPY utility which perform the
"dirty task" of UNLOADing a PDS content into a VS dataset,
in the best way IBM knows how this task has to be performed.

No, I understand that.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
//SYSIN DD *
COPY INDD=((SYSUT1,R)),OUTDD=SYSUT2
SELECT MEMBER=SORT
/*

Ok, I wasn't aware of that syntax.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Now, Paul, please, explain me where is the difference with what
you are doing with native IEBCOPY VS output datasets, which just
makes the damn thing more complex to manage, at least for a naive
user, as I'm?

XMIT370/RECV370 are not the utilities normally
used to handle XMITs. The TSO commands RECEIVE
and TRANSMIT are, and I'm not sure the syntax
you showed is supported to transmit just a single
module.

Regardless, I consider this extra layer to be what
is complex.

I agree that transferring a RECFM=FB file is
easier than transferring a RECFM=VB file, but
I think that problem should be addressed
differently rather than adding another layer
of encapsulation to avoid that problem. IBM
has already partially solved the problem by
providing an "rdw" option to ftp. They've
already semi-agreed to make "rdw"
bidirectional. As you noted, our IND$FILE
also has an RDW option. COPYFILE and
somitcw's utility can take care of the RDWs
if you haven't managed to transfer directly
into a RECFM=V dataset.

I have documented RECFM=V RDWs in
System380.txt. I guess I am adding a
requirement that naive users learn about
RDWs than learn about how difficult RDWs
are to deal with that they instead need to
learn about XMIT format when asking "why
is it so difficult to copy a single executable?".

I agree that there is an issue with RECFM=V
binary datasets. Sometimes people store
zip files in there where the RDWs need to be
ignored, and sometimes the RDWs need to
be preserved. I think this is the fundamental
problem, and I think the solution is to stop
storing zip files in there and store them in
RECFM=U instead, leaving RECFM=V for
people who are genuinely using the RDWs.

With that (possibly flawed) philosophy, the
solution to RDW problems is education and
updating utilities like IBM's ftp which only
works one way, rather than adding an FB
layer purely because V is too damned
difficult to transfer. If you do want to add an
FB layer, you can simply use copyfile -bb
to transfer into FB prior to using IND$FILE
or whatever. But using copyfile (or XMIT)
like that is fundamentally flawed. The user
and the utilities instead should be able to
directly take care of RDWs.

Am I wrong?

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
difficult to transfer. If you do want to add an
FB layer, you can simply use copyfile -bb
to transfer into FB prior to using IND$FILE
or whatever.

Or potentially we could have another utility that
replaces IEBCOPY (or calls IEBCOPY under
the covers) and outputs to RECFM=F or U
to make using IND$FILE easier. But without
an extra layer of encapsulation, ie it's still
normal IEBCOPY format. The utility could
ensure that records aren't spanned as well,
instead of relying on the user of IEBCOPY
being reasonable.

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
be preserved. I think this is the fundamental
problem, and I think the solution is to stop
storing zip files in there and store them in
RECFM=U instead, leaving RECFM=V for
people who are genuinely using the RDWs.

Note that it is not really my intention to get
existing MVS users to change their practices.
I am mainly trying to set guidelines that I can
pass on to Unix C programmers who insist
that MVS is too weird to target. I want to
convince them that if "proper practices" are
used, MVS is only slightly different from
Unix, especially when viewed from a C90
perspective. Hell, even the file format is
identical to Unix so long as RECFM=U is
used. ie text and binary are the same, and
NL terminators are used for lines. The only
thing that changes is EBCDIC is used
instead of ASCII, a ridiculously minor
change, and the US ASCII keyboard can
continue to be used as there is a one to
one match for every key on the keyboard.

BFN. Paul.

[[e-mail] [hercules-os380]]

One more thing to note.

The way I am using IEBCOPY is actually a
subset of its capabilities. Even if I wish to
ship 3 programs, rather than doing a single
IEBCOPY unload of all 3, I instead do 3
separate unloads to create 3 separate
distribution EXE files.

That is deliberately done to make it as easy
to use MVS executables as Unix/Windows.
PDOS demonstrates that ease, but I don't
yet have the required MVS enhancements
to do the same thing there, and instead
rely on executables being "installed".

BFN. Paul.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
The way I am using IEBCOPY is actually a
subset of its capabilities. Even if I wish to
ship 3 programs, rather than doing a single
IEBCOPY unload of all 3, I instead do 3
separate unloads to create 3 separate
distribution EXE files.

I would be happy for zip to be enhanced to
be able to zip 3 separate modules within a
zip file though. The zip file could be the
container instead of xmit. I'm happy to have
that. XMIT is a container for datasets, not
executables, so I don't think that is
appropriate.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, you seem to forget XMIT370 just add an "extra FB layer"
to the IEBCOPY VS native output dataset, that, under
the cover, it is still the IBM IEBCOPY utility which perform the
"dirty task" of UNLOADing a PDS content into a VS dataset,
in the best way IBM knows how this task has to be performed.

No, I understand that.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
//SYSIN DD *
COPY INDD=((SYSUT1,R)),OUTDD=SYSUT2
SELECT MEMBER=SORT
/*

Ok, I wasn't aware of that syntax.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Now, Paul, please, explain me where is the difference with what
you are doing with native IEBCOPY VS output datasets, which just
makes the damn thing more complex to manage, at least for a naive
user, as I'm?

XMIT370/RECV370 are not the utilities normally
used to handle XMITs. The TSO commands RECEIVE
and TRANSMIT are, and I'm not sure the syntax
you showed is supported to transmit just a single
module.

Regardless, I consider this extra layer to be what
is complex.

I agree that transferring a RECFM=FB file is
easier than transferring a RECFM=VB file, but
I think that problem should be addressed
differently rather than adding another layer
of encapsulation to avoid that problem. IBM
has already partially solved the problem by
providing an "rdw" option to ftp. They've
already semi-agreed to make "rdw"
bidirectional. As you noted, our IND$FILE
also has an RDW option. COPYFILE and
somitcw's utility can take care of the RDWs
if you haven't managed to transfer directly
into a RECFM=V dataset.

I have documented RECFM=V RDWs in
System380.txt. I guess I am adding a
requirement that naive users learn about
RDWs than learn about how difficult RDWs
are to deal with that they instead need to
learn about XMIT format when asking "why
is it so difficult to copy a single executable?".

I agree that there is an issue with RECFM=V
binary datasets. Sometimes people store
zip files in there where the RDWs need to be
ignored, and sometimes the RDWs need to
be preserved. I think this is the fundamental
problem, and I think the solution is to stop
storing zip files in there and store them in
RECFM=U instead, leaving RECFM=V for
people who are genuinely using the RDWs.

With that (possibly flawed) philosophy, the
solution to RDW problems is education and
updating utilities like IBM's ftp which only
works one way, rather than adding an FB
layer purely because V is too damned
difficult to transfer. If you do want to add an
FB layer, you can simply use copyfile -bb
to transfer into FB prior to using IND$FILE
or whatever. But using copyfile (or XMIT)
like that is fundamentally flawed. The user
and the utilities instead should be able to
directly take care of RDWs.

Am I wrong?

BFN. Paul.

---

You make the thing more complex without gaining
anything back, Paul.

And increasing complexity without getting something
back is ALWAYS a mistake, Occam Razor docet.

It is an old, dear, good principle which should
be ALWAYS applied.

Said that, a question arise.

Do XMIT370/RECV370 run under ANY MVS version?
From MVS3.8j, through MVS/SP and MVS/ESA, up to a modern ZOS
beside the RECEIVE/TRANSMIT commands?

I guess they do. Why they shouldn't? They perform
a really simple task, like mine VS2FB/FB2VS, the
real work is done by the IBM IEBCOPY, available
ony any MVS version. And, are you sure Paul
the TRANSMIT/RECEIVE commands don't use IEBCOPY
in the same way XMIT370/RECV370 do?

If they do, we may UNLOAD and LOAD a "SINGLE MODULE"
from and to a load library, using a simple to exchange
FB dataset, EXACTLY in the same way we do, inside
a single MVS/ZOS system with IEBCOPY.

Whatever IEBCOPY do, XMIT370/RECV370 can do,
the viceversa is not true, but for PDS they
may be considered functional equivalent,
beside the format of their datasets.

And without any need to use a file image tape
and external tools, we may even punch or read
an XMIT FB dataset, if we wish, or use IND$FILE
or FTP, or whatever we like, being sure IEBCOPY
will be ALWAYS able to restore load modules, or
any fancy dataset IEBCOPY is able to UNLOAD/LOAD
without any need to bet or guess.

Do you really think, Paul, is easier to educate
people or to ask IBM to change the way is doing
its things rather than simply switching from IEBCOPY
native VS dataset to FB XMIT datsets?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
You make the thing more complex without gaining
anything back, Paul.

This is not complex:

C:\>pe2lm
Usage example: pe2lm hexdump.exe PDPCLIB.LINKLIB

The only thing simpler than that is:

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


I consider being able to ship an executable as
simple and gaining something.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
And increasing complexity without getting something
back is ALWAYS a mistake, Occam Razor docet.

Occam's Razor says to me that I should be moving
from pe2lm to pc2mf, and I have already done that
with PDOS, but changing MVS is more difficult, so
in the meantime pe2lm has to suffice.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Do XMIT370/RECV370 run under ANY MVS version?
From MVS3.8j, through MVS/SP and MVS/ESA, up to a modern ZOS
beside the RECEIVE/TRANSMIT commands?

I believe so, but they are unlikely to be installed
on a z/OS system. It's true that reverse ftp rdw
is also not installed on a z/OS system, but I
believe the proper solution to that problem is
for IBM to make ftp rdw bidirectional. And in
the meantime, the solution is not to throw the
baby out with the bathwater but instead use
a simple utility, ie copyfile, or somitcw's, or
your FB2VS, or a site can roll their own.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I guess they do. Why they shouldn't? They perform
a really simple task, like mine VS2FB/FB2VS, the
real work is done by the IBM IEBCOPY, available
ony any MVS version. And, are you sure Paul
the TRANSMIT/RECEIVE commands don't use IEBCOPY
in the same way XMIT370/RECV370 do?

They do use IEBCOPY as far as I am aware.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If they do, we may UNLOAD and LOAD a "SINGLE MODULE"
from and to a load library,

I don't know that TRANSMIT has that facility,
even though XMIT370 does.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
using a simple to exchange FB dataset,

This is exactly the problem. FB shouldn't be
any easier to exchange than V. The people
who wrote IEBCOPY should have used FB
if V is so unmanageable. Or alternatively we
can learn to manage V.

I believe you're choosing the wrong solution
to this complexity of MVS, and the proper
solution is to fix MVS. IBM has already
started on this by providing the rdw option
to ftp.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
EXACTLY in the same way we do, inside
a single MVS/ZOS system with IEBCOPY.

Not sure what you're talking about there.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Whatever IEBCOPY do, XMIT370/RECV370 can do,

Sure. With an extra layer, and that layer, like
DFDSS, deals with datasets, not executables.

When I ship the GCCMVS I am shipping datasets
and XMIT370 is the appropriate thing to use.

When I ship SEASIK I am dealing with lots of
datasets from different products and DFDSS
is the most appropriate in my opinion.

I am only using IEBCOPY as a means to an
ends. It's the appropriate thing to use to
flatten a single load module. I am happy to
use another utility like zip if it does the same
thing, but I expect the module to stand
alone outside of zip.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
And without any need to use a file image tape
and external tools, we may even punch or read
an XMIT FB dataset,

The PC equivalent of punching a fixed length
card is the xmodem protocol which I believe
will pad to 128 bytes. Or some other protocol
has that characteristic.

That does not mean zip is an inappropriate
container because it doesn't produce files
of a multiple of 128. Nor is it inappropriate
because when run on a mainframe it
doesn't produce a multiple of 80.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
if we wish, or use IND$FILE
or FTP, or whatever we like, being sure IEBCOPY
will be ALWAYS able to restore load modules, or
any fancy dataset IEBCOPY is able to UNLOAD/LOAD
without any need to bet or guess.

I agree that the XMIT container is more robust
than my use of IEBCOPY unloads with today's
technology.

But I don't think XMIT is the way forward. I have
explained what I think is the way forward (a
SYS2.EXE, bidirectional IBM ftp rdw, zip etc).

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Do you really think, Paul, is easier to educate
people or to ask IBM to change the way is doing
its things rather than simply switching from IEBCOPY
native VS dataset to FB XMIT datsets?

For my target audience, yes. Shipping a
hexdump.exe allows me to say to Unix
people "see - MVS is as simple as Unix
if used properly". Shipping a hexdump-xmit
is not, and is a direct sign to Unix people
that MVS is irretrievably spastic.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

On Sun, 1 Apr 2018, ***@yahoo.com.au [hercules-os380] wrote:

I don't know that TRANSMIT has that facility,
even though XMIT370 does.

---

It does, Paul, I can't test it directly, but TRANSMIT has
exactly the same behaviour and it actually use IEBCOPY
in the same way XMIT370 call it, if I'm reading correctly
the documentation.

Look Paul, now I know what I've to "google for", I've found
a simple and clear reference in minutes:

https://www.ibm.com/developerworks/community/blogs/cicsabel/entry/transfering_load_modules_between_mainframes_using_xmit_and_ftp20?lang=en

XMIT (NODEID.ARNOLD) DSNAME('ARNOLD.COBOL.LOAD') -
OUTDSNAME('ARNOLD.COBOL.SEQ') MEMBERS(HELLOW)

If I had a ZOS/TSO USERID available, I may have tested this
in minutes, from the TSO command line, it is even easier
than with XMIT370:

MEMBERS(name)

and you have selected a SINGLE load module inside
the 'ARNOLD.COBOL.LOAD' load library to UNLOADed
and stored into an FB dataset, under ZOS.

By the way, I even tried to RECV370 on already existing
load library, containing other modules. RECV370 (and I bet
RECEIVE), correctly merge the module without touching the
other modules or violating the PDS integrity in any way.

By the way. I didn't test it, I plan to test, but I bet
XMIT370 may store its XMITOUT/FB as a member of an FB/PDS
and RECV370 may restore from an XMITIN pointing to a member
of an FB/PDS.

This is going to be more complex, but if I understand
the paradigm correctly, the PDS just need to be (RECFM=FB,LRECL=80),
the BLKSIZE should be irrilevant. But I wouldn't bet on this.

XMIT370 may have BLKSIZE=3200 wired in its XMITOUT DCB and
it may "scramble" any existing PDS with a different BLKSIZE,
when it writes to it, so be careful about this experiment, Paul.
I'll be extremely cautios and I'll use a "test" PDS for that ;-)

So, we may have XMIT/RECV "FB/80/3200/libraries" (using
(RECFM=FB,LRECL=80,BLKSIZE=3200) should be a safe choice),
where, space allowing, we may store hundreds of XMITs datasets,
without clobbering master or user catalogs.

I think I'm starting to understand how MVS programmers think :-)

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
MEMBERS(name)

Ok, cool.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. I didn't test it, I plan to test, but I bet
XMIT370 may store its XMITOUT/FB as a member of an FB/PDS
and RECV370 may restore from an XMITIN pointing to a member
of an FB/PDS.

Yes, this is how GCCMVS is shipped. An XMIT
of XMITs.

But that doesn't mean that I think XMIT is a
suitable format for a load module. Any more
than a zip -0 is suitable for a Windows
executable to interpret. Even though it is
technically possible.

BFN. Paul.

[Joe Monk [e-mail] [hercules-os380]]

"I think I'm starting to understand how MVS programmers think :-)"

You are Peppe. Everything revolves around punched cards in MVS ... because
those are the roots of the systems we have. In the days that this version
of MVS was actually running in production, there would've been RJE
terminals with a punched card reader and a printer.

So many of the utilities we have are geared towards FB80 datasets, because
that is the heritage of OS/360, upon which OS/VS2 3.8J is based.

Joe

Post by ***@yahoo.com.au [hercules-os380]
I don't know that TRANSMIT has that facility,
even though XMIT370 does.
---
It does, Paul, I can't test it directly, but TRANSMIT has
exactly the same behaviour and it actually use IEBCOPY
in the same way XMIT370 call it, if I'm reading correctly
the documentation.
Look Paul, now I know what I've to "google for", I've found
https://www.ibm.com/developerworks/community/blogs/cicsabel/entry/
transfering_load_modules_between_mainframes_using_xmit_and_ftp20?lang=en
XMIT (NODEID.ARNOLD) DSNAME('ARNOLD.COBOL.LOAD') -
OUTDSNAME('ARNOLD.COBOL.SEQ') MEMBERS(HELLOW)
If I had a ZOS/TSO USERID available, I may have tested this
in minutes, from the TSO command line, it is even easier
MEMBERS(name)
and you have selected a SINGLE load module inside
the 'ARNOLD.COBOL.LOAD' load library to UNLOADed
and stored into an FB dataset, under ZOS.
By the way, I even tried to RECV370 on already existing
load library, containing other modules. RECV370 (and I bet
RECEIVE), correctly merge the module without touching the
other modules or violating the PDS integrity in any way.
By the way. I didn't test it, I plan to test, but I bet
XMIT370 may store its XMITOUT/FB as a member of an FB/PDS
and RECV370 may restore from an XMITIN pointing to a member
of an FB/PDS.
This is going to be more complex, but if I understand
the paradigm correctly, the PDS just need to be (RECFM=FB,LRECL=80),
the BLKSIZE should be irrilevant. But I wouldn't bet on this.
XMIT370 may have BLKSIZE=3200 wired in its XMITOUT DCB and
it may "scramble" any existing PDS with a different BLKSIZE,
when it writes to it, so be careful about this experiment, Paul.
I'll be extremely cautios and I'll use a "test" PDS for that ;-)
So, we may have XMIT/RECV "FB/80/3200/libraries" (using
(RECFM=FB,LRECL=80,BLKSIZE=3200) should be a safe choice),
where, space allowing, we may store hundreds of XMITs datasets,
without clobbering master or user catalogs.
I think I'm starting to understand how MVS programmers think :-)
Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
"I think I'm starting to understand how MVS programmers think :-)"
You are Peppe. Everything revolves around punched cards in MVS ... because
those are the roots of the systems we have. In the days that this version
of MVS was actually running in production, there would've been RJE
terminals with a punched card reader and a printer.
So many of the utilities we have are geared towards FB80 datasets, because
that is the heritage of OS/360, upon which OS/VS2 3.8J is based.
Joe

Thanks Joe, I really appreciate your comment about
my MVS understanding, it means I'm doing progress, beside
my age, each day more, doesn't help me much :-)

What I've to face now, is the problem to understand
how our group host, here, in this list, think.

It looks is really more difficult than understanding
MVS paradigms.

Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Joe Monk ***@gmail.com [hercules-os380]
You are Peppe. Everything revolves around punched cards in MVS ... because
those are the roots of the systems we have. In the days that this version
of MVS was actually running in production, there would've been RJE
terminals with a punched card reader and a printer.

This point, Joe, deserves a dedicated post.

Yep, I now understand the central role of punched cards
in the IBM MVS architecture, a role I didn't appreciate
at my IBM time of being a VM/CMS user.

I've to say I already had an abstract idea, before
touching MVS, thinking about why CRT terminals had
this a weird number of columns standard ;-)

But an abstraction is one thing, touching it with
my naked fingers is another. And I needed quite
a lot of time to change how my UNIX brain is wired,
wired around unstructured streams of bytes,
streams of bytes that actually are the REAL
ABSTRACTION.

Even in our modern days, physical devices,
like a real hard disk, are not organized,
at the physical level, as unstructured stream
of bytes.

At the physical level there are "markers",
physical "sector sizes", which establish
what is the atomic unit of information which may
be exchanged from lower to upper software layers,
where the abstraction is implemented.

In the "dark age" of MVS3.8j the abstraction
was still in its infancy and there existed
a so large number of possibilities, the physical
level was presented to final users in all of
its glory, like for example the BLKSIZE of
a dataset or of a reader, a tape, a punch
or a printer.

I'm really happy I met MVS, by an accident I would say,
some years ago and that MVS "unwired" my brain to the
point I can now be at least an MVS user, if not an
MVS sysadmin or system programmer.

And I'm really grateful to all the "hercules community",
in its multigroup incarnations, to have provided me
with a such good support in terms of software, information,
documentation, discussion and, last but not least, patience :-)

Peppe.

[[e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format

Note that PDOS already executes these
IEBCOPY unloads directly.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo)

Post by ***@yahoo.com.au [hercules-os380]
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format

Note that PDOS already executes these
IEBCOPY unloads directly.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
(possible double post due to Yahoo)
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format

Note that PDOS already executes these
IEBCOPY unloads directly.

BFN. Paul.

---

And, Paul, forgive my question, how many users
currently PDOS has around the world?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format

Note that PDOS already executes these
IEBCOPY unloads directly.

And, Paul, forgive my question, how many users
currently PDOS has around the world?

That is not my point. My point is that PDOS
has proven the technology to show what is
possible, and the next step is to get MVS
to have the same feature that PDOS has.

This is just one of many MVS changes I
want to see. Another is for MVS to be able
to execute Windows 32-bit executables.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
I hope to solve. I hope for there to be a
SYS2.EXE RECFM=U dataset containing
executables in IEBCOPY unload format

Note that PDOS already executes these
IEBCOPY unloads directly.

And, Paul, forgive my question, how many users
currently PDOS has around the world?

That is not my point. My point is that PDOS
has proven the technology to show what is
possible, and the next step is to get MVS
to have the same feature that PDOS has.

This is just one of many MVS changes I
want to see. Another is for MVS to be able
to execute Windows 32-bit executables.

BFN. Paul.

---

Ok, Paul, you are free to model PDOS as you
best like, beside any user PDOS may have or
not have.

But you are asking to naive MVS users, like
me, to become crazy trying to UNLOAD IEBCOPY
native VS datasets, like your copyfile.exe,
for doing simple things, like testing patches
or zaps, under MVS, not PDOS.

I'm an MVS3.8j user, not a PDOS user, and I
would prefer a simpler way to exchange datasets
under MVS, where I perform tests you requested.

If you wish MVS users around the world use,
verify and test your tools, under MVS, please
provide us with a more suitable exchange format.

It would make our lifes easier and would allow
us to verify your tools and answer to your
questions in a shorter time, saving the time
needed to solve the "puzzle" of uploading
your datasets to our beloved MVS.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But you are asking to naive MVS users, like
me, to become crazy trying to UNLOAD IEBCOPY
native VS datasets, like your copyfile.exe,
for doing simple things, like testing patches
or zaps, under MVS, not PDOS.

You are asking me to move away from my
very simple to use lm2pe script to capture
an arbitrary executable on my system and
construct some custom JCL to execute
XMIT.

I guess it may be possible to construct a
lm2xmit script now that I have that syntax
from you to handle a single module.

And it may also be possible to reverse
that with an xmit2lm script.

But then I can't take the shipped executable
to PDOS because it has xmit baggage
around it.

I don't think xmit baggage is the way to go
just because it produces a multiple of 80.
That shouldn't be a driver any more than
128 should be a driver.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I'm an MVS3.8j user, not a PDOS user, and I
would prefer a simpler way to exchange datasets
under MVS, where I perform tests you requested.

Do you want to work with me to create a
pe2lm script on your system?

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If you wish MVS users around the world use,
verify and test your tools, under MVS, please
provide us with a more suitable exchange format.

I do already for formal releases of GCCMVS,
but I am planning on switching to zip files
containing .exe files for other products like
BREXX, with JCL like this:

//IEBCOPY1 EXEC PGM=IEBCOPY
//SYSUT1 DD DSN=&BRXPREF..LINKLIB,DISP=SHR
//SYSUT2 DD DSN=&&COPY,SPACE=(CYL,(1,1)),UNIT=SYSALLDA,
// DISP=(NEW,PASS)
//SYSPRINT DD SYSOUT=*
//SYSIN DD DUMMY
//*
//COPYFIL1 EXEC PGM=COPYFILE,PARM='-bb dd:in dd:out'
//STEPLIB DD DSN=&PDPPREF..LINKLIB,DISP=SHR
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//IN DD DSN=&&COPY,DISP=(OLD,PASS)
//OUT DD DSN=&&PE(BREXX),DISP=(OLD,PASS)
//*
//ZIP EXEC PGM=MINIZIP,PARM='-x .exe -l -o dd:out dd:in'
//STEPLIB DD DSN=&MINPREF..LINKLIB,DISP=SHR
//SYSIN DD DUMMY
//SYSPRINT DD SYSOUT=*
//SYSTERM DD SYSOUT=*
//IN DD DSN=&&PE,DISP=(OLD,PASS)
//OUT DD DSN=HERC01.ZIP,DISP=(,KEEP),UNIT=TAPE,
// LABEL=(1,SL),VOL=SER=MFTOPC,
// DCB=(RECFM=U,LRECL=0,BLKSIZE=6233)
//SYSUT1 DD DSN=&&TEMP,DISP=(,DELETE),UNIT=SYSALLDA,
// SPACE=(CYL,(10,10))

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
It would make our lifes easier and would allow
us to verify your tools and answer to your
questions in a shorter time, saving the time
needed to solve the "puzzle" of uploading
your datasets to our beloved MVS.

Ok, you're right about that. I would like things
to be easy on your system too.

I actually ship these executables zipped.
Is there any reason you can't upload the
zip file and have JCL to unzip then
IEBCOPY load the unzipped executable?
Why should that be any more difficult than
loading an XMIT? Also, are you actually
loading files via the card reader? Is that
why you like a multiple of 80? I believe
you can send a non-80 multiple up the
card reader and it will pad the last record,
and zip can handle that.

Hopefully we can come up with something
mutually acceptable now that I understand
your concern.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Ok, you're right about that. I would like things
to be easy on your system too.

I actually ship these executables zipped.
Is there any reason you can't upload the
zip file and have JCL to unzip then
IEBCOPY load the unzipped executable?
Why should that be any more difficult than
loading an XMIT? Also, are you actually
loading files via the card reader? Is that
why you like a multiple of 80? I believe
you can send a non-80 multiple up the
card reader and it will pad the last record,
and zip can handle that.

---

Yep, you did, you provided a zip file,
copyfile.zip, you are right.

Sorry I didn't solved the Nth puzzle
you proposed me, Paul, because I still have
to load ZIP/UNZIP on my SYS2, while
XMIT370/RECV370 are provided on the Moseley
SYSCPK volume for free and so I had it
onboard, as any MVS3.8j user, I guess,
as any ZOS user have TRANSMIT/RECEIVE
from IBM, with their payed system, I guess.

So, I unzipped copyfile.zip and extracted
copyfile.exe BEFORE even trying to upload
what you posted on Yahoo and found myself
facing with the problem to upload a V IEBCOPY dataset
instead of an FB XMIT dataset, ready to
be restored from RECV370. A problem I solved,
by the way, by myself.

Did I write I'm a naive MVS user?

Yes, I did.

Peppe.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo)

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I assumed SUPA was able to manage IEBCOPY VS native datasets,
it doesn't, SUPA may only handle them as V datsets,
assuming there are NOT spanned records into the dataset,
i.e. assuming BLKSIZE is large enough to accomodate
each record in a SINGLE block.

area. Unless you are reading in block mode, the spanning should be
transparent. If it is not, there is a program error.

Peppe has identified at least one program error,
but it is on output.

When destination is VS rather than V, then a
RDW of 19056, when written to:

//OUT DD DSN=&&TEMP2,SPACE=(CYL,(10,10)),UNIT=3390,
// DISP=(NEW,PASS),DCB=(RECFM=VS,LRECL=19056,BLKSIZE=19060)

produces:

13.47.14 JOB 1 +MVSSUPA - @@AWRITE - invalid RECFM=Vxx request
13.47.14 JOB 1 +MVSSUPA - DD OUT
13.47.14 JOB 1 IEF450I HERC01A COPYFILE - ABEND S000 U0002
13.47.14 JOB 1 HERC01A COPYFILE COPYFILE AB 2

Bumping the LRECL and BLKSIZE up by 4 makes
the problem go away. Also using V instead of VS
makes the problem go away. So there appears to
be a calculation that is off by 4 bytes.

But fixing that is not a priority for me, and not
likely to be fixed with me maintaining the code
now. Note that the latest code is here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/mvssupa.asm

If anyone can spot a one-line fix for the
above problem, I can make the change
and test it.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
I assumed SUPA was able to manage IEBCOPY VS native datasets,
it doesn't, SUPA may only handle them as V datsets,
assuming there are NOT spanned records into the dataset,
i.e. assuming BLKSIZE is large enough to accomodate
each record in a SINGLE block.

area. Unless you are reading in block mode, the spanning should be
transparent. If it is not, there is a program error.

Well, if there is flaw in the logic, Gerhard, I'm pretty
sure you will be able to fix it.

I will be glad to use a version of SUPA which may correctly
handle spanned records.

I'm slowly, as always, beginning to understand what is
hiding behind QSAM/BSAM and the only way to get a clear
picture is to do my own experiments in assembler, directly calling
QSAM/BSAM from my own code.

As I pictured, SUPA do its best trying to hide complexity
from MVS datasets. But complexity can't be "erased" without
actually erasing "information", as complexity, information
and entropy are pretty the same damned thing ;-)

So, I'm trying to do my best to understand what is hiding
behind SUPA, i.e. MVS access methods ;-)

Thanks as always Gerhard, Peppe.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
May you arrange things so I may download a copy of
the PDPCLIB.LINKLIB (possibly plain AMODE=24) you are
using? So I may test the last updated version?

I've uploaded copyfile.exe which is an IEBCOPY
unload of just copyfile.exe. You may wish to use
your own program to restore it to a V dataset.
I would normally use copyfile to do that, but you
don't trust your copyfile. somitcw has a program
that will do the job too, but I've never used that.
BFN. Paul.

---

Paul, a question about this copyfile.exe.

This contains an IEBCOPY dataset, ok, I restored
it with IEBCOPY succesfully.

But how you downloaded it as a file to your Windows
this dataset?

If I'm not wrong I just see RDW fields
and record data, without any BWD field, hex dumping
copyfile.exe file on my Linux:

00000000: 0038 0000 00ca 6d0f 0200 1800 0000 c000 ......_.......{.
00000010: 0000 1814 3030 200e 0000 7ff8 0376 000f .........."8....
00000020: bb60 0100 0010 010b 0000 0000 0000 0000 .-..............
00000030: 0000 0000 0000 0000 0118 0000 0100 0000 ................
00000040: ff00 0000 8f0b 6644 04a4 d0e8 5000 4520 .........u}Y&...
00000050: 0000 0122 0000 0122 000e 000f 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000150: 0124 0000 0000 0000 0000 0000 0008 0100 ................
00000160: ffff ffff ffff ffff 0032 c3d6 d7e8 c6c9 ..........COPYFI
00000170: d3c5 0007 0e2c 0007 1e00 0000 0000 02c2 LE.............B
00000180: 010d b018 0000 0104 8800 0001 0000 ffff ........h.......

How do you have transfered it to Windows, may I ask you to post
the details?

If I try to binary download one of my VS IEBCOPY
datasets, with IND$FILE, I loose all the BDW,RDW fields, I just
get the record data.

Maybe you have used the TK4- FTP?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But how you downloaded it as a file to your Windows
this dataset?

I use this:

C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe

which does an IEBCOPY unload, then an IEBCOPY
to a RECFM=U output tape, and then I extract the
first file from the tape using "hetget -b".

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I'm not wrong I just see RDW fields
and record data, without any BWD field

Yes, that is correct. Just RDW, no BDW.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I try to binary download one of my VS IEBCOPY
datasets, with IND$FILE, I loose all the BDW,RDW fields, I just
get the record data.

I use tape to transfer binary data up and down,
I rarely start a 3270 terminal, and I never use
ind$file, although I thought there was an option
in the latest ind$file to copy RDWs.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Maybe you have used the TK4- FTP?

No, I don't have ftp working on my system yet.
I'm still getting nntp to work.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
But how you downloaded it as a file to your Windows
this dataset?

I use this:

C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe

which does an IEBCOPY unload, then an IEBCOPY
to a RECFM=U output tape, and then I extract the
first file from the tape using "hetget -b".

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I'm not wrong I just see RDW fields
and record data, without any BWD field

Yes, that is correct. Just RDW, no BDW.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
If I try to binary download one of my VS IEBCOPY
datasets, with IND$FILE, I loose all the BDW,RDW fields, I just
get the record data.

I use tape to transfer binary data up and down,
I rarely start a 3270 terminal, and I never use
ind$file, although I thought there was an option
in the latest ind$file to copy RDWs.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Maybe you have used the TK4- FTP?

No, I don't have ftp working on my system yet.
I'm still getting nntp to work.

BFN. Paul.
--
Thanks Paul. I found my way with last version
of IND$FILE to get the same result, just RDW
fields.

It is enough to add the "RDW" IND$FILE option, in the
x3270 terminal emulator, after the host
Data Set Name. The emulator will send the command
with the RDW option, as IND$FILE expect it.

Definitely easier than using a virtual tape
and hetget, isn't?

Now this is very a good reason for going without an EOF
marker, but padding with NULLS. It is compatible
with what hetget and IND$FILE do.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Definitely easier than using a virtual tape
and hetget, isn't?

Not for me. I prefer to use micro-emacs as my
editor and I haven't been able to port that to
the mainframe yet. So I operate MVS from
the Windows command line, and this is
really easy to type in:

C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe


BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Definitely easier than using a virtual tape
and hetget, isn't?

Not for me. I prefer to use micro-emacs as my
editor and I haven't been able to port that to
the mainframe yet. So I operate MVS from
the Windows command line, and this is
really easy to type in:

C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe

---

Paul, it may be easy for you, "lm2pe" doesn't
mean anything to the anyone else in the world
I guess, if you don't specify the details.

Any way, now, with your previous message,
I've a more clear idea of what you are doing.

Jone one question left.

IEBCOPY would LOAD from a VB datset? It doesn't
scream an error with a VB dataset in input,
instead of the original VS dataset?

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]

Post by ***@yahoo.com.au [hercules-os380]
C:\>lm2pe
Usage example: lm2pe PDPCLIB.LINKLIB HEXDUMP hexdump.exe

Paul, it may be easy for you, "lm2pe" doesn't
mean anything to the anyone else in the world
I guess, if you don't specify the details.

lm = load module
pe = iebcopy with just rdw

So the above command very very quickly
produces an iebcopy unload file on my PC,
ready to be zipped and shipped.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
IEBCOPY would LOAD from a VB datset? It doesn't
scream an error with a VB dataset in input,
instead of the original VS dataset?

I'm not sure about that. I think I always give it
a RECFM=V which it is happy to accept - it
doesn't insist on a VS, because V is basically
a subset of VS. But VB is not a subset of VS,
so it may complain about that. Even if it works,
I would suggest avoiding VB, as that is not
what is documented as working.

BTW, are you familiar with what blocksizes
that IEBCOPY produces when it does an
unload? I wonder if it uses a fixed size of
7294 instead of adjusting to a combination
of the input dataset and the disk track
length. That would explain a lot. All bets
are off if you have spanned records. Note
that I normally do unloads of datasets that
have a maximum blocksize of 6233 (the
universal blocksize), although I believe
I successfully unloaded and reloaded
mvs380mn/mvs380ft from SYS2.LINKLIB
with an unfortunately large blocksize, but
I believe I needed to muck around with
organizing a 3390 work dataset for it to
work.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible double post due to yahoo)

But I can't see any track of the VS dataset lenght,
neither an indication of any EOF mark at the tail

I'm not sure why you think some sort of
indicator is required. If PDPCLIB is given
a NULL RDW to write to a V dataset, it
just ignores the data and treats that as EOF.

padded with NULLS, while the tail of my VS2FB dataset

I wasn't aware there was such a thing as an
RDW EOF. Can you do a hexdump and
idcams print dump of an IEBCOPY file and
see if there is an RDW of x'FFFF' in it? I
just did a hexdump test and didn't see such
a thing.

BTW, if such a thing as an x'FFFF' RDW
exists then what on earth is the BDW set to?

Trying to restore that very simple VS dataset,
(RECFM=VS,LRECL=79,BLKSIZE=79),

Those are unusual DCB characteristics. I realize
with spanned you can do that, but if you stick to
RECFM=V, then the BLKSIZE should be at least
4 larger than the LRECL to allow a BDW.

USER ABEND CODE 0002

There should have also been a message written
to the job log and maybe console. If you run in
batch you will see that.

BFN. Paul.

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by ***@yahoo.com.au [hercules-os380]
(possible double post due to yahoo)
But I can't see any track of the VS dataset lenght,
neither an indication of any EOF mark at the tail

I'm not sure why you think some sort of
indicator is required. If PDPCLIB is given
a NULL RDW to write to a V dataset, it
just ignores the data and treats that as EOF.

Post by ***@yahoo.com.au [hercules-os380]
padded with NULLS, while the tail of my VS2FB dataset

I wasn't aware there was such a thing as an
RDW EOF. Can you do a hexdump and
idcams print dump of an IEBCOPY file and
see if there is an RDW of x'FFFF' in it? I
just did a hexdump test and didn't see such
a thing.

BTW, if such a thing as an x'FFFF' RDW
exists then what on earth is the BDW set to?

Post by ***@yahoo.com.au [hercules-os380]
Trying to restore that very simple VS dataset,
(RECFM=VS,LRECL=79,BLKSIZE=79),

Those are unusual DCB characteristics. I realize
with spanned you can do that, but if you stick to
RECFM=V, then the BLKSIZE should be at least
4 larger than the LRECL to allow a BDW.

Post by ***@yahoo.com.au [hercules-os380]
USER ABEND CODE 0002

There should have also been a message written
to the job log and maybe console. If you run in
batch you will see that.

BFN. Paul.

---

Such an RDW doesn't exist, this is exactly
the point, so it can be used as an EOF on the
FB dataset, not in the VS dataset, where
(BDW,RDW) fields, and the system EOF, do that job.

Remember I'm using QSAM, not BSAM, so I never
see BDW fields, I just see RDWs where the second
half word is ALWAYS zero.

Yes, you can actually use a ZERO tail RDW, if you
manage the fact the TAIL of the FB dataset is not ALWAYS
a complete FULL WORD, 4 bytes long.

It may happen the padding tail
is an "incomplete" word, with length of 1,2,3 bytes
or a tail doesn't exist at all, the program
just read the EOF of the FB dataset (zero length,
perfect "fit" of the VS records).

Good point, Paul, but I would still prefer to have always
a clear and plain EOF mark, which is ALWAYS a FULL word,
a mark that can't be a valid RDW field, even if
that lead to pay, eventually, the price of a SINGLE
empty CARD, filled with FF, without any data payload,
although I understand why you can't allow that in
the SUPA stdio library.

About my "unusual" dataset, yep I'm using VS datasets
because I would like to manage any possible VS dataset
which IEBCOPY may generate. We don't have any control
on the way IEBCOPY choose (RECFM,BLKSIZE) of its
output VS dataset, do we?

That the reason I choosed QSAM (SUPA use BSAM if I'm
reading correctly). With QSAM, if I'm right, managing
a RECFM=VS or a RECFM=V[B] should be quite the same.

The QSAM access method is deblocking/blocking records
for me, at the price of copying around buffers, it always
assemble into the user buffer a "complete record", with
its RDW, without any BDW.

Peppe.

[[e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Yes, you can actually use a ZERO tail RDW, if you
manage the fact the TAIL of the FB dataset is not ALWAYS
a complete FULL WORD, 4 bytes long.

Yes, I manage that fact. And the C90 standard
allows me to pad with NULs. It doesn't allow
padding with x'FF'. I see no reason to use
x'FF' instead of just allowing a natural C90
compliant end to the data stream.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
About my "unusual" dataset, yep I'm using VS datasets
because I would like to manage any possible VS dataset
which IEBCOPY may generate. We don't have any control
on the way IEBCOPY choose (RECFM,BLKSIZE) of its
output VS dataset, do we?

You can make sure your input load modules have
a sensible blocksize and if they don't, you can
manage the output disk to be a 3380 or 3390 so
that hopefully a large LRECL can be defined as
required.

I'm not that familiar with it. That's just my
understanding of what is required to avoid
spanned records.

However, my tests with copyfile indicate that
spanned seems to work anyway.

BFN. Paul.

[[e-mail] [hercules-os380]]

(possible double post due to Yahoo, and
also out of order because another post
of mine has already appeared)

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Paul, it doesn't, at least with the versions
of GCCMVS/SUPA I have seen.

So it needs to be debugged, because it is
meant to work.

You are using copyfile with "-bb" rather than
the default "-tt", right?

BFN. Paul.

[Mike Schwab [e-mail] [hercules-os380]]

:A JOBLIB is used for steps without a STEPLIB. It doesn't use JOBLIB
after a STEPLIB doesn't have the EXEC=PGM.

Post by ***@yahoo.com.au [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY
two ways to execute a load module
stored in a library which is NOT in the
MVS linklist, from JCL?

I think there's a JOBLIB too.

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
By the way. I think I got my first assembler
MVS3.8j tool up and running ;-)

Congratulations!
BFN. Paul.
------------------------------------
------------------------------------
------------------------------------
Yahoo Groups Links

[Gerhard Postpischil [e-mail] [hercules-os380]]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY two ways to execute a load module
stored in a library which is NOT in the MVS linklist, from JCL?

Sorry, I should have been more explicit. As Paul noted, there is JOBLIB,
but I don't know any other JCL method for invoking load modules, or I
would have said so.

(I just got back from three days in the hospital, and am not thinking
too clearly).


Gerhard Postpischil
Bradford, VT

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Giuseppe Vitillaro [e-mail] [hercules-os380]]

Post by Gerhard Postpischil ***@charter.net [hercules-os380]

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-os380]
Is STEPLIB and REFERBACKs the ONLY two ways to execute a load module
stored in a library which is NOT in the MVS linklist, from JCL?

Sorry, I should have been more explicit. As Paul noted, there is JOBLIB,
but I don't know any other JCL method for invoking load modules, or I
would have said so.
(I just got back from three days in the hospital, and am not thinking
too clearly).

Ops, apologies Gerhard, I hope you will get well soon!
Best wishes, Peppe.