Re: TSO receive on MultiVolume PS error

2016-06-01 Thread Field, Alan 
 Been using this mod for years and never had an issue. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 31, 2016 10:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO receive on MultiVolume PS error

On Tue, 31 May 2016 09:54:22 +, Field, Alan wrote:

>Blksize 3120 is hardcoded. This usermod removes that restriction:
>
>++ USERMOD (LM00062) REWORK(2016003) 
> /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET   
>TO 3120 (X'0C30').   
>THIS MOD SETS IT TO 0 (SYSTEM DETERMINED BLKSIZE).   
>INMXM IS IN SYS1.LINKLIB.
> */ .
>++ VER (Z038) FMID(HTE77A0)  
>.
>++ ZAP (INMXM) . 
> NAME INMXM  
>  VER 1AC4 ,0C30 
>  REP 1AC4 , 
> 
Clever.  I'll assume QSAM cheerfully deals with whatever BLKSIZE SDB selects.
Is RECEIVE equally happy with it?

But doesn't it still corrupt RECFM or LRECL of an existing data set?

Is the performance gain significant with modern DASD?  I'd care more for 
preserving RECFM and LRECL, even at the cost of TRANSMIT's failing.

-- gil

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


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.


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

Re: TSO receive on MultiVolume PS error

2016-05-31 Thread Jesse 1 Robinson 
I use RECEIVE into an existing data set all the time. I've never seen DCB 
corruption. 

SEND is another matter. Regardless of what you specify, the output is 3120. 
This usermod, which I've heard of but never used, apparently just zeroes out 
the hard-coded 3120 value. XMIT/RECEIVE is wy older than SDB. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Tuesday, May 31, 2016 8:31 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TSO receive on MultiVolume PS error

On Tue, 31 May 2016 09:54:22 +, Field, Alan wrote:

>Blksize 3120 is hardcoded. This usermod removes that restriction:
>
>++ USERMOD (LM00062) REWORK(2016003) 
> /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET   
>TO 3120 (X'0C30').   
>THIS MOD SETS IT TO 0 (SYSTEM DETERMINED BLKSIZE).   
>INMXM IS IN SYS1.LINKLIB.
> */ .
>++ VER (Z038) FMID(HTE77A0)  
>.
>++ ZAP (INMXM) . 
> NAME INMXM  
>  VER 1AC4 ,0C30 
>  REP 1AC4 , 
> 
Clever.  I'll assume QSAM cheerfully deals with whatever BLKSIZE SDB selects.
Is RECEIVE equally happy with it?

But doesn't it still corrupt RECFM or LRECL of an existing data set?

Is the performance gain significant with modern DASD?  I'd care more for 
preserving RECFM and LRECL, even at the cost of TRANSMIT's failing.

-- gil


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

Re: TSO receive on MultiVolume PS error

2016-05-31 Thread Paul Gilmartin 
On Tue, 31 May 2016 09:54:22 +, Field, Alan wrote:

>Blksize 3120 is hardcoded. This usermod removes that restriction:
>
>++ USERMOD (LM00062) REWORK(2016003) 
> /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET   
>TO 3120 (X'0C30').   
>THIS MOD SETS IT TO 0 (SYSTEM DETERMINED BLKSIZE).   
>INMXM IS IN SYS1.LINKLIB.
> */ .
>++ VER (Z038) FMID(HTE77A0)  
>.
>++ ZAP (INMXM) . 
> NAME INMXM  
>  VER 1AC4 ,0C30 
>  REP 1AC4 , 
> 
Clever.  I'll assume QSAM cheerfully deals with whatever BLKSIZE SDB selects.
Is RECEIVE equally happy with it?

But doesn't it still corrupt RECFM or LRECL of an existing data set?

Is the performance gain significant with modern DASD?  I'd care more for
preserving RECFM and LRECL, even at the cost of TRANSMIT's failing.

-- gil

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

Re: TSO receive on MultiVolume PS error

2016-05-31 Thread Field, Alan 
Blksize 3120 is hardcoded. This usermod removes that restriction:

++ USERMOD (LM00062) REWORK(2016003) 
 /* TRANSMIT OUTDA() FORCES THE BLKSIZE OF THE OUTPUT DATA SET   
TO 3120 (X'0C30').   
THIS MOD SETS IT TO 0 (SYSTEM DETERMINED BLKSIZE).   
INMXM IS IN SYS1.LINKLIB.
 */ .
++ VER (Z038) FMID(HTE77A0)  
.
++ ZAP (INMXM) . 
 NAME INMXM  
  VER 1AC4 ,0C30 
  REP 1AC4 , 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Lizette Koehler
Sent: Friday, May 27, 2016 7:45 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO receive on MultiVolume PS error

Peter,

I have only seen BLKSIZE=3120 in the IBM Documentation for TSO XMIT.  

OUTDDNAME(ddname) | OUTFILE(ddname)
specifies the use of a preallocated file as the output data set for the 
TRANSMIT command. No data is written to SYSOUT for transmission and the system 
limit on the number of records that can be transmitted does not apply. TSO/E 
assigns the DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. Specify the 
ddname as either a sequential data set or a member of a partitioned data set.

Use OUTDDNAME or OUTFILE in conjunction with the INDDNAME or INFILE operand 
of the RECEIVE command. OUTDDNAME and OUTFILE are primarily intended for system 
programmer use.
OUTDSNAME(dsname) | OUTDATASET(dsname)
specifies the use of a data set as the output data set for the TRANSMIT 
command. No data is written to SYSOUT for transmission and the system limit on 
the number of records that can be transmitted does not apply. TSO/E assigns the 
DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. The data set must be a 
sequential data set.


And I agree that 27920 is better.  But I have not seen any doc from IBM stating 
it was good for XMIT.  If you have clarifying documentation, could you share?

It is possible that IBM's doc needs an update.  But at this time for the z/OS
V2.1 on Knowledge Center, I am not finding it.  If SDB (System Determined
Blksize) or a specification of 80x could be used, this might need an Doc Update 
to include that.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Peter Hunkeler
> Sent: Friday, May 27, 2016 4:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: TSO receive on MultiVolume PS error
> 
> 
> 
> > However, I don't think that is your problem. The XMIT dataset should 
> > be FB
> 80 3120.
> 
> 
> 
> Just for the records: The XMIT data set *must* be RECFM=FB, LRECL=80.
> The blocksize should be as large as possible to minimize the number of 
> I/O operations to be run. 27920 is optimal.
> 
> 
> --
> Peter Hunkeler
> 

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


This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. If 
you are not the named addressee you must not disseminate, distribute or copy 
this e-mail. Please notify the sender immediately by e-mail if you have 
received this e-mail by mistake and delete this e-mail from your system. If you 
are not the intended recipient you are notified that disclosing, copying, 
distributing or taking any action in reliance on the contents of this 
information is strictly prohibited.

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

Re: AW: Re: TSO receive on MultiVolume PS error

2016-05-28 Thread Paul Gilmartin 
On Sat, 28 May 2016 01:05:47 +0200, Peter Hunkeler wrote:

>Lizette, I agree that the doc needs to be updated. I'll submit an RCF.
>Gil's post made me thinking. As a matter of fact, I've been using larger 
>blocksizes for XMIT data sets for a long time, but only when allocating them 
>for FTP to upload one. So, RECEIVE happily accepts larger block sizes.
>
And if it's unspecified?  This might be INDD(allocated-unix-file).

>I never cared to look at what TRANSMIT allocated. I just tried and found that 
>TRANSMIT overrides the block size with 3120, when the data set already existed 
>(and uses this when it allocates the data set).
> 
If "overides" means "writes back to the DSCB" I can consider this data 
corruption,
particularly in the case of an existing PDS; SR-worthy.

And at least RFE-worthy, change the behavior to take the DCB OPEN exit, then,
o If RECFM is unspecified, supply FB
o If resulting RECFM is neither F nor FB, fail.
o If LRECL is unspecified, supply 80.
o If resulting LRECL is not 80, fail.
o Ignore BLKSIZE; let SDB have its way.
o Perform no consistency checks; OPEN will do that, possibly ABENDing.

As the OS becomes more complicated it becomes correspondingly less
acceptable to brush aside complaints with such as, "Oh!  Your PDS was
corrupted?  You should have RTFM; it's documented."

-- gil

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

Re: AW: Re: TSO receive on MultiVolume PS error

2016-05-27 Thread Edward Finnell 
Think it's a holdover from old IEWL limitation of 3200 for blksize.  
TRANSMIT can do PDS or sequential.
If PDS it does the special IEBCOPY unload to 80/3120 FB documented in TSO  
Command Ref. Controlling member is IKJTSOxx. Yes Virginia there is a  
VIO(unit). 
 
 
In a message dated 5/27/2016 6:06:02 P.M. Central Daylight Time,  
p...@gmx.ch writes:

never  cared to look at what TRANSMIT allocated. I just tried and found 
that TRANSMIT  overrides the block size with 3120, when the data set already 
existed (and  uses this when it allocates the data set).  



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

AW: Re: TSO receive on MultiVolume PS error

2016-05-27 Thread Peter Hunkeler 
Lizette, I agree that the doc needs to be updated. I'll submit an RCF.
Gil's post made me thinking. As a matter of fact, I've been using larger 
blocksizes for XMIT data sets for a long time, but only when allocating them 
for FTP to upload one. So, RECEIVE happily accepts larger block sizes.
I never cared to look at what TRANSMIT allocated. I just tried and found that 
TRANSMIT overrides the block size with 3120, when the data set already existed 
(and uses this when it allocates the data set).



--
Peter Hunkeler



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

Re: TSO receive on MultiVolume PS error

2016-05-27 Thread Paul Gilmartin 
On Fri, 27 May 2016 05:45:05 -0700, Lizette Koehler wrote:
>
>I have only seen BLKSIZE=3120 in the IBM Documentation for TSO XMIT.
>
>OUTDDNAME(ddname) | OUTFILE(ddname)
>specifies the use of a preallocated file as the output data set for the
>TRANSMIT command. No data is written to SYSOUT for transmission and the system
>limit on the number of records that can be transmitted does not apply. TSO/E
>assigns the DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. Specify the
>ddname as either a sequential data set or a member of a partitioned data set.
> 
UNIX files and even POSIX pipes work.  I don't know whether they're considered
supported.  According to introductory matter in "Using Data Sets", data sets
can be UNIX files, but I've lost that argument with IBM support more than once.

But it raises the tantalizing possibility of piping from TRANSMIT into ssh and
having no requirement for a temporary data set (except for the IEBCOPY case.)

>Use OUTDDNAME or OUTFILE in conjunction with the INDDNAME or INFILE operand
>of the RECEIVE command. OUTDDNAME and OUTFILE are primarily intended for system
>programmer use.
>OUTDSNAME(dsname) | OUTDATASET(dsname)
>specifies the use of a data set as the output data set for the TRANSMIT
>command. No data is written to SYSOUT for transmission and the system limit on
>the number of records that can be transmitted does not apply. TSO/E assigns the
>DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. The data set must be a
>sequential data set.
>
>And I agree that 27920 is better.  But I have not seen any doc from IBM stating
>it was good for XMIT.  If you have clarifying documentation, could you share?
> 
Is TRANSMIT one of those accursed utilities that has DCB attributes hard coded
and writes them back to the DSCB, possibly corrupting a PDS?

-- gil

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

Re: TSO receive on MultiVolume PS error

2016-05-27 Thread Lizette Koehler 
Peter,

I have only seen BLKSIZE=3120 in the IBM Documentation for TSO XMIT.  

OUTDDNAME(ddname) | OUTFILE(ddname)
specifies the use of a preallocated file as the output data set for the
TRANSMIT command. No data is written to SYSOUT for transmission and the system
limit on the number of records that can be transmitted does not apply. TSO/E
assigns the DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. Specify the
ddname as either a sequential data set or a member of a partitioned data set.

Use OUTDDNAME or OUTFILE in conjunction with the INDDNAME or INFILE operand
of the RECEIVE command. OUTDDNAME and OUTFILE are primarily intended for system
programmer use.
OUTDSNAME(dsname) | OUTDATASET(dsname)
specifies the use of a data set as the output data set for the TRANSMIT
command. No data is written to SYSOUT for transmission and the system limit on
the number of records that can be transmitted does not apply. TSO/E assigns the
DCB attributes as LRECL=80, BLKSIZE=3120, and RECFM=FB. The data set must be a
sequential data set.


And I agree that 27920 is better.  But I have not seen any doc from IBM stating
it was good for XMIT.  If you have clarifying documentation, could you share?

It is possible that IBM's doc needs an update.  But at this time for the z/OS
V2.1 on Knowledge Center, I am not finding it.  If SDB (System Determined
Blksize) or a specification of 80x could be used, this might need an Doc Update
to include that.


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Peter Hunkeler
> Sent: Friday, May 27, 2016 4:23 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: AW: Re: TSO receive on MultiVolume PS error
> 
> 
> 
> > However, I don't think that is your problem. The XMIT dataset should
> > be FB
> 80 3120.
> 
> 
> 
> Just for the records: The XMIT data set *must* be RECFM=FB, LRECL=80.
> The blocksize should be as large as possible to minimize the number of I/O
> operations to be run. 27920 is optimal.
> 
> 
> --
> Peter Hunkeler
> 

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

AW: Re: TSO receive on MultiVolume PS error

2016-05-27 Thread Peter Hunkeler 


> However, I don't think that is your problem. The XMIT dataset should be FB
80 3120.



Just for the records: The XMIT data set *must* be RECFM=FB, LRECL=80.
The blocksize should be as large as possible to minimize the number of I/O 
operations to be run. 27920 is optimal.


--
Peter Hunkeler







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

Re: TSO receive on MultiVolume PS error

2016-05-24 Thread Paul Gillis 
IND$FILE is only useful for small datasets. Its performance is woeful for
larger datasets and it is not well supported under some 3270 emulators, I
would use FTP/SFTP/NFTP etc instead.

Cheers,
Paul Gillis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Anthony L. Zak
Sent: Monday, 23 May 2016 1:34 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO receive on MultiVolume PS error

TRANSMIT, a TSO command processor running on the z/OS M/F, repackages the
input dataset and then writes it to JES to be handled via NJE which means
the data can be RECEIVEd wherever there is NJE connectivity.  IND$FILE
piggybacks over a 3270 type session with Comm Server and AFAIK only gets you
as far as the host you have the 3270 session with. One could use them in
series.  How about using z/OS Explorer which is a 21st century product?
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu>
Sender:   IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Date: Sun, 22 May 2016 20:53:26 
To: <IBM-MAIN@LISTSERV.UA.EDU>
Reply-To: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: [IBM-MAIN] TSO receive on MultiVolume PS error

On 2016-05-22, at 14:31, R.S. wrote:

> W dniu 2016-05-20 o 18:33, Paul Gilmartin pisze:
>>> 
>> My quick check for this is (IIRC):
>> 
>> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>> 
>> ... at both ends of the transfer and compare the checksums and lengths.
>> 
> I remember how I spent half a day on such problem.
> I had to download PTF package then move it from one PC to another, using
pendrive, then upload it to z/OS and do SMPE tasks.
> I took a lot of time to recognize the reason is failing pendrive (nota
bene with IBM logo! ;-))) ). It simply changed some bytes within the file
with no CRC32 error or so. It was the last thing on the list of suspects.
>  
Ouch!  Do you mean the pendrive reported no error, or that you got the same
CRC32 on the originating PC and the destination PC?

Windows is woefully deficient in checksum utilities.  One must install one.
I use Cygwin.

But my suggestion was elliptical.  I should have mentioned the need to use
TRANSMIT with the OUTDSN option; FTP/SFTP/IND$FILE; then compare checksums;
then RECEIVE with the INDSN option.

Can TRANSMIT use IND$FILE for the TCP/IP challenged?  Can IND$FILE transfer
z/OS to z/OS?

-- gil

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

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

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

Re: TSO receive on MultiVolume PS error

2016-05-24 Thread Paul Gillis 
I only use XMIT a.b DA(dsn) OUTDA(FB80) for smallish datasets that I may wish 
to read on a PC, otherwise a DFDSS Dump and TRS has been my standard for years 
and can handle single or multiple datasets. I used this where my intent is to 
move data from one system to another via any other type of system 
(Linux/Wndows/OS X) or just to move the data.

Cheers,
Paul Gillis

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mick Graley
Sent: Tuesday, 24 May 2016 1:59 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: TSO receive on MultiVolume PS error

Yes XMIT definitely supports DSORG=PS RECFM=U data sets.
Good example being DFDSS dumps.
I regularly use DFDSS to dump multiple data sets, then XMIT that dump data set 
to get a very portable RECFM=FB LRECL=80 version of the dump.
Cheers,
Mick.


On 20 May 2016 at 18:36, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote:
> OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS 
> files with RECFM U? The only RECFM U files I know of are load modules, but 
> they are PO, not PS. In any case the error message refers to the XMITted 
> file, not the target.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] 
> On Behalf Of Paul Gilmartin
> Sent: Friday, May 20, 2016 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TSO receive on MultiVolume PS error
>
> On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>>
>>Are you sure your dataset has been transferred properly and fully and without 
>>errors before you tried out RECEIVE?
>>
> My quick check for this is (IIRC):
>
> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>
> ... at both ends of the transfer and compare the checksums and lengths.
>
> (Or you could write an assembler program using CSNBOWH.)
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

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

Re: TSO receive on MultiVolume PS error

2016-05-23 Thread Mick Graley 
Yes XMIT definitely supports DSORG=PS RECFM=U data sets.
Good example being DFDSS dumps.
I regularly use DFDSS to dump multiple data sets, then XMIT that dump
data set to get a very portable RECFM=FB LRECL=80 version of the dump.
Cheers,
Mick.


On 20 May 2016 at 18:36, Jesse 1 Robinson <jesse1.robin...@sce.com> wrote:
> OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS 
> files with RECFM U? The only RECFM U files I know of are load modules, but 
> they are PO, not PS. In any case the error message refers to the XMITted 
> file, not the target.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
> Behalf Of Paul Gilmartin
> Sent: Friday, May 20, 2016 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TSO receive on MultiVolume PS error
>
> On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>>
>>Are you sure your dataset has been transferred properly and fully and without 
>>errors before you tried out RECEIVE?
>>
> My quick check for this is (IIRC):
>
> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>
> ... at both ends of the transfer and compare the checksums and lengths.
>
> (Or you could write an assembler program using CSNBOWH.)
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: TSO receive on MultiVolume PS error

2016-05-22 Thread Anthony L. Zak 
TRANSMIT, a TSO command processor running on the z/OS M/F, repackages the input 
dataset and then writes it to JES to be handled via NJE which means the data 
can be RECEIVEd wherever there is NJE connectivity.  IND$FILE  piggybacks over 
a 3270 type session with Comm Server and AFAIK only gets you as far as the host 
you have the 3270 session with. One could use them in series.  How about using 
z/OS Explorer which is a 21st century product?
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu>
Sender:   IBM Mainframe Discussion List 
Date: Sun, 22 May 2016 20:53:26 
To: 
Reply-To: IBM Mainframe Discussion List 
Subject: Re: [IBM-MAIN] TSO receive on MultiVolume PS error

On 2016-05-22, at 14:31, R.S. wrote:

> W dniu 2016-05-20 o 18:33, Paul Gilmartin pisze:
>>> 
>> My quick check for this is (IIRC):
>> 
>> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>> 
>> ... at both ends of the transfer and compare the checksums and lengths.
>> 
> I remember how I spent half a day on such problem.
> I had to download PTF package then move it from one PC to another, using 
> pendrive, then upload it to z/OS and do SMPE tasks.
> I took a lot of time to recognize the reason is failing pendrive (nota bene 
> with IBM logo! ;-))) ). It simply changed some bytes within the file with no 
> CRC32 error or so. It was the last thing on the list of suspects.
>  
Ouch!  Do you mean the pendrive reported no error, or that you got the
same CRC32 on the originating PC and the destination PC?

Windows is woefully deficient in checksum utilities.  One must install
one.  I use Cygwin.

But my suggestion was elliptical.  I should have mentioned the need to
use TRANSMIT with the OUTDSN option; FTP/SFTP/IND$FILE; then compare
checksums; then RECEIVE with the INDSN option.

Can TRANSMIT use IND$FILE for the TCP/IP challenged?  Can IND$FILE
transfer z/OS to z/OS?

-- gil

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

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

Re: TSO receive on MultiVolume PS error

2016-05-22 Thread Paul Gilmartin 
On 2016-05-22, at 14:31, R.S. wrote:

> W dniu 2016-05-20 o 18:33, Paul Gilmartin pisze:
>>> 
>> My quick check for this is (IIRC):
>> 
>> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>> 
>> ... at both ends of the transfer and compare the checksums and lengths.
>> 
> I remember how I spent half a day on such problem.
> I had to download PTF package then move it from one PC to another, using 
> pendrive, then upload it to z/OS and do SMPE tasks.
> I took a lot of time to recognize the reason is failing pendrive (nota bene 
> with IBM logo! ;-))) ). It simply changed some bytes within the file with no 
> CRC32 error or so. It was the last thing on the list of suspects.
>  
Ouch!  Do you mean the pendrive reported no error, or that you got the
same CRC32 on the originating PC and the destination PC?

Windows is woefully deficient in checksum utilities.  One must install
one.  I use Cygwin.

But my suggestion was elliptical.  I should have mentioned the need to
use TRANSMIT with the OUTDSN option; FTP/SFTP/IND$FILE; then compare
checksums; then RECEIVE with the INDSN option.

Can TRANSMIT use IND$FILE for the TCP/IP challenged?  Can IND$FILE
transfer z/OS to z/OS?

-- gil

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

Re: TSO receive on MultiVolume PS error

2016-05-22 Thread R.S. 

W dniu 2016-05-20 o 18:33, Paul Gilmartin pisze:

On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:

Are you sure your dataset has been transferred properly and fully and without 
errors before you tried out RECEIVE?


My quick check for this is (IIRC):

 cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum

... at both ends of the transfer and compare the checksums and lengths.

(Or you could write an assembler program using CSNBOWH.)

I remember how I spent half a day on such problem.
I had to download PTF package then move it from one PC to another, using 
pendrive, then upload it to z/OS and do SMPE tasks.
I took a lot of time to recognize the reason is failing pendrive (nota 
bene with IBM logo! ;-))) ). It simply changed some bytes within the 
file with no CRC32 error or so. It was the last thing on the list of 
suspects.


Regards
--
Radoslaw Skorupka
Lodz, Poland






---
Treść tej wiadomości może zawierać informacje prawnie chronione Banku 
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie 
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem 
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania 
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie 
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być 
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie 
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość 
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is 
intended solely for business use of the addressee. This e-mail may only be 
received by the addressee and may not be disclosed to any third parties. If you 
are not the intended addressee of this e-mail or the employee authorized to 
forward it to the addressee, be advised that any dissemination, copying, 
distribution or any other similar activity is legally prohibited and may be 
punishable. If you received this e-mail by mistake please advise the sender 
immediately by using the reply facility in your e-mail software and delete 
permanently this e-mail including any copies of it either printed or saved to 
hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, 
www.mBank.pl, e-mail: kont...@mbank.pl
Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru 
Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. 
Według stanu na dzień 01.01.2016 r. kapitał zakładowy mBanku S.A. (w całości 
wpłacony) wynosi 168.955.696 złotych.


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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Wayne Bickerdike 
Don't preallocate the target dataset. The RECEIVE will allocate the correct
attributes.

However, I don't think that is your problem. The XMIT dataset should be FB
80 3120.

Just RECEIVE INDSN('MY.XMIT') DATASET('NEW.DATASET'). If you get the same
error, reallocate your XMIT dataset to 3120 LRECL as mentioned by others.

On Sat, May 21, 2016 at 3:36 AM, Jesse 1 Robinson <jesse1.robin...@sce.com>
wrote:

> OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS
> files with RECFM U? The only RECFM U files I know of are load modules, but
> they are PO, not PS. In any case the error message refers to the XMITted
> file, not the target.
>
> .
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-302-7535 Office
> robin...@sce.com
>
>
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Paul Gilmartin
> Sent: Friday, May 20, 2016 9:33 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: (External):Re: TSO receive on MultiVolume PS error
>
> On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
> >
> >Are you sure your dataset has been transferred properly and fully and
> without errors before you tried out RECEIVE?
> >
> My quick check for this is (IIRC):
>
> cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum
>
> ... at both ends of the transfer and compare the checksums and lengths.
>
> (Or you could write an assembler program using CSNBOWH.)
>
> -- gil
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>



-- 
Wayne V. Bickerdike

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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Jesse 1 Robinson 
OP referred to a 'PS with Fo[r]mat U'. Does XMIT/RECEIVE even support PS files 
with RECFM U? The only RECFM U files I know of are load modules, but they are 
PO, not PS. In any case the error message refers to the XMITted file, not the 
target. 

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Paul Gilmartin
Sent: Friday, May 20, 2016 9:33 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: TSO receive on MultiVolume PS error

On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>
>Are you sure your dataset has been transferred properly and fully and without 
>errors before you tried out RECEIVE?
> 
My quick check for this is (IIRC):

cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum

... at both ends of the transfer and compare the checksums and lengths.

(Or you could write an assembler program using CSNBOWH.)

-- gil


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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Paul Gilmartin 
On Fri, 20 May 2016 06:14:44 -0500, Elardus Engelbrecht wrote:
>
>Are you sure your dataset has been transferred properly and fully and without 
>errors before you tried out RECEIVE?
> 
My quick check for this is (IIRC):

cp -B "//'DSN(MEMBER)'" /dev/fd/1 | cksum

... at both ends of the transfer and compare the checksums and lengths.

(Or you could write an assembler program using CSNBOWH.)

-- gil

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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Lizette Koehler 
I am not clear on what you are trying to do.  But TSO XMIT uses a PS 80 3120 
file size even with load modules for the unloaded TSO XMIT'd file.

Here is a nice write up of using TSO XMIT and FTP to move a load module from 
one system to another.

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

(Watch the wrap)

You might wish to review the TSO COMMAND manual for TSO XMIT (TRANSMIT) or use 
the TSO HELP function (TSO HELP XMIT) and see what is needed to send files.
SA32-0975-00z/OS V2.1 TSO/E Command Reference


https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ikjc500/transmi.htm


So long as the transmitted dataset has the correct attributes, all you should 
need to do is TSO RECEIVE INDS()

If you could show the attributes of your transmitted dataset it will help.

Most of the time the TSO XMIT'd file will use LRECL=80  BLKSIZE=3120.  If the 
attributes do not match what was sent to you, you might see this message.

Next, browse the transmitted file and make sure it has the correct characters 
at the beginning of the dataset.  If it does not, then it was corrupted before 
it came to you.

You should see something like this:
ß\INMR01
36

Ñ

The important part is the \INMR01  -  if it is missing, then the xmit'd file is 
not valid


Lizette


> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Nathan Astle
> Sent: Friday, May 20, 2016 3:57 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: TSO receive on MultiVolume PS error
> 
> Hi,
> 
> I am trying to receive an XMI file to a PS with Fomat U, but I receive a
> message as
> 
> 
>  INMR108I RECEIVE command terminated.  Trailer record missing
>  ***
> 
> I am not sure if my target pre-allocated file has any problem.
> 
> Could someone please clarify me on the above ?
> 
> Nathan
> 

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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Walt Farrell 
On Fri, 20 May 2016 16:26:37 +0530, Nathan Astle  wrote:

>I am trying to receive an XMI file to a PS with Fomat U, but I receive a
>message as
>
>
> INMR108I RECEIVE command terminated.  Trailer record missing
> ***
>
>I am not sure if my target pre-allocated file has any problem.

If you look up that message you'll see that it indicates an error with the 
input file.


The RECEIVE command processor encountered an input file with a missing trailer 
control record. The error was probably the result of an incomplete transmission 
from the originator.


-- 
Walt

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

Re: TSO receive on MultiVolume PS error

2016-05-20 Thread Elardus Engelbrecht 
Nathan Astle wrote:

>I am trying to receive an XMI file to a PS with Fomat U, but I receive a 
>message as
> INMR108I RECEIVE command terminated.  Trailer record missing
 ***
>I am not sure if my target pre-allocated file has any problem.

Perhaps, can you compare the attributes of the original dataset with your 
pre-allocated output dataset? All attributes must be the same. What is the 
LRECL? It should be zero.

Are you sure your dataset has been transferred properly and fully and without 
errors before you tried out RECEIVE?

Groete / Greetings
Elardus Engelbrecht

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