In [EMAIL PROTECTED], on 01/09/2008
at 10:13 PM, Bruce Baxter [EMAIL PROTECTED] said:
As stated by another poster, there doesn't seem to be any way to
get it to honor this and strip it off on the final FTP.
You don't want FTP to strip it off, you want FTP to transmit the data
intact. The
On Mon, 14 Jan 2008 12:20:37 -0500, Shmuel Metz (Seymour J.) wrote:
What happens if you use struc?
IIRC, STRU R fails with a z/OS client and a non-IBM server, which
IIRC was the OP's required configuration.
Kobayashi Alternative?
-- gil
] On Behalf
Of Ed Gould
Sent: Friday, January 11, 2008 1:27 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer conundrum
I don't recall too much about SWIFT. Just that it existed that is about all.
Was it connected with TANDEM (et al) ?
In anycase we had only two customers that didn't do SNA and I
Interesting.
Thanks.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Anne Lynn Wheeler
Sent: Friday, January 11, 2008 9:45 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer conundrum
The following message is a courtesy copy
The following message is a courtesy copy of an article
that has been posted to bit.listserv.ibm-main as well.
[EMAIL PROTECTED] (Gary Green) writes:
I lost track of who posted the original inquiry, so take this for what it's
worth.
If the requirement is in the financial industry, could the
On Thu, 10 Jan 2008 15:54:23 -0700, Roger Bolan wrote:
I agree with John. TERSE is the simplest. You just terse the file on
the source z/OS system, then use binary for all transfers. Then there is
no problem of EBCDIC/ASCII, or RDW. The binary file arrives unchanged.
Then use TERSE to
On Fri, 11 Jan 2008 09:45:10 -0500, Anne Lynn Wheeler [EMAIL PROTECTED]
wrote:
http://www.swift.com/
swift-2 providing internet capability and opening up for b-to-b;
There is a good introduction to how SWIFT works in Ross Anderson's book
Security Engineering. The book is now available online,
to the host. Once there, the job would be kicked off and the file
received.
Again, JMTC
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Bruce Baxter
Sent: Thursday, January 10, 2008 10:53 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer
John S. Giltner, Jr. [EMAIL PROTECTED]
Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
10/01/2008 02:51
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: File Transfer conundrum
Any reason why you can't ftp
John S. Giltner, Jr. [EMAIL PROTECTED]
Sent by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
10/01/2008 02:51
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: File Transfer conundrum
Any reason why you can't ftp
Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To: IBM-MAIN@BAMA.UA.EDU IBM-MAIN@BAMA.UA.EDU
Sent: Thu Jan 10 05:37:38 2008
Subject: Re: File Transfer conundrum
Has MQSeries been considered? I'd have thought it would have solved most
problems like this. (unless one of the partners doesnt actually have
On Wed, 9 Jan 2008 22:13:13 -0600, Bruce Baxter ... wrote:
ftp directly between the two systems, quite simply isn't an option. Our
business partner chose the mechanism in palce to deal with multiple other
shops, and they're not likely to want to do this sort of one-off thing for us.
And how
, January 09, 2008 10:13 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer conundrum
ftp directly between the two systems, quite simply isn't an option. Our
business partner chose the mechanism in palce to deal with multiple
other
shops, and they're not likely to want to do this sort of one-off
to always be a point where the data can be intercepted.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Zaromil Tisler
Sent: Thursday, January 10, 2008 8:19 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer conundrum
On Wed, 9 Jan 2008 22:13:13
by: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
10/01/2008 02:51
Please respond to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
To
IBM-MAIN@BAMA.UA.EDU
cc
Subject
Re: File Transfer conundrum
Any reason why you can't ftp directly between the two z/OS system?
If security is an issue
Their other partners also have similar problems. I'm trying to coalesce a
group
of the techies that deal with this issue to have a conference call with techies
at the shop generating this data.
Bottom line: FTP is clearly not a drop in replacement for good old fashioned
tapes.
On Thu, 10
I agree with John. TERSE is the simplest. You just terse the file on
the source z/OS system, then use binary for all transfers. Then there is
no problem of EBCDIC/ASCII, or RDW. The binary file arrives unchanged.
Then use TERSE to unpack it and it automatically restores the correct DCB
On Wed, 9 Jan 2008 15:24:32 -0600, Bruce Baxter
[EMAIL PROTECTED] wrote:
We've routinely exhanged files with business partners running on z/OS
machines using tape for years.
We're now in the process of converting a number of these to electronic
means, using in part FTP.
[snip - common problems
On Jan 10, 2008, at 11:16 AM, Hal Merritt wrote:
My guess is that many shops are implementing PC to PC transfers and
buying some really expensive software to facilitate the process.
That is
hostpcnetworkpchost.
So far, we have been somewhat successful in insisting on a fully
automated, z/os
: File Transfer conundrum
On Jan 10, 2008, at 11:16 AM, Hal Merritt wrote:
My guess is that many shops are implementing PC to PC transfers and
buying some really expensive software to facilitate the process.
That is
hostpcnetworkpchost.
So far, we have been somewhat successful in insisting
the
network for other financial transactions; which I took to mean data
exchange...
JMTC
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf
Of Ed Gould
Sent: Thursday, January 10, 2008 8:52 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: File Transfer
On Jan 10, 2008, at 8:10 PM, Gary Green wrote:
I lost track of who posted the original inquiry, so take this for
what it's
worth.
If the requirement is in the financial industry, could the
communications
between the two/various systems use S.W.I.F.T. (Society for Worldwide
Interbank
We've routinely exhanged files with business partners running on z/OS
machines using tape for years.
We're now in the process of converting a number of these to electronic
means, using in part FTP. This is being done at the behest of one of our
business partners, who (IMHO) hasn't thought
the length header?
Larry Gray
Large Systems Engineering
Lowe's Companies
336-658-7944
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Bruce Baxter
Sent: Wednesday, January 09, 2008 4:25 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: File Transfer conundrum
A good philosophy is to use some program common to both sending and
receiving systems that will compress and possibly encrypt the data,
retaining the file's original record formatting as part of the new data
file. Transfer that new data file and decrypt/expand it at the receiving
site. XMIT can be
The simpliest thing, in my opinion, is to use TERSE on both ends and do
binary transfers.
--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology
The information contained in this e-mail message may
On Wed, 9 Jan 2008 16:31:03 -0500, Gray, Larry - Larry A wrote:
Have you tried LOCSITE RDW on your send to keep the length header?
I just tried it. It appears that on the send (PUT) it does
keep and transmit the RDWs. On the GET, however, it treats
them as data, and ISPF reports INVALID
On Wed, 9 Jan 2008 15:36:28 -0600, Thomas Kern wrote:
A good philosophy is to use some program common to both sending and
receiving systems that will compress and possibly encrypt the data,
retaining the file's original record formatting as part of the new data
file. Transfer that new data file
Any reason why you can't ftp directly between the two z/OS system?
If security is an issue you could use either IPSec tunnels between the
two systems or setup IBM SecureFTP server (SSL'ed FTP).
Bruce Baxter wrote:
We've routinely exhanged files with business partners running on z/OS
ftp directly between the two systems, quite simply isn't an option. Our
business partner chose the mechanism in palce to deal with multiple other
shops, and they're not likely to want to do this sort of one-off thing for us.
I also took some of the previous comments regarding the RDW site
On Jan 9, 2008, at 10:13 PM, Bruce Baxter wrote:
ftp directly between the two systems, quite simply isn't an
option. Our
business partner chose the mechanism in palce to deal with multiple
other
shops, and they're not likely to want to do this sort of one-off
thing for us.
I also took
[EMAIL PROTECTED] Subject
.EDU Re: File Transfer conundrum
On Jan 9, 2008, at 11:17 PM, Skip Robinson wrote:
-SNP---
-- TSO XMIT/RECEIVE, which has 'always' been incorporated in z/OS
and its
ancestors
SNIP
I am not sure why you put quotes around always but IIRC that TSOe
included xmit/receive as to when TSOe
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 01/10/2008
01:34:47 AM:
On Jan 9, 2008, at 11:17 PM, Skip Robinson wrote:
-SNP---
-- TSO XMIT/RECEIVE, which has 'always' been incorporated in z/OS
and its
ancestors
SNIP
I am not sure
34 matches
Mail list logo
