About all I can add is, I started to work with IND$FILE in 1987. And the associated fun things, like LU6.2 connections to PS/2's, PC/3270 and so on. I remember calling it Independent File Transfer. At the time it was cool, but so was Token Ring.
It was fine until someone wanted a big file, and didn't understand anything like data compression, or how little storage they had their PS/2, even if they got the file, they couldn't open it. It was slow, but honestly, unless you had something figured out a way to break file transfer into multiple streams everything was slow, unless it was worth it to make it faster. Dialup lasted far longer than I ever thought it would.
"Oh bye, bye, thirty-seven-O-five, closed the valve to chiller, but the chiller was dry..." <--- Yes I know, 3704/3705 air cooled, but nothing else worked.
"Why can't I send a VSAM or BDAM file on IND$FILE?" "Why can't I send character and non-character data mixed?" "You can, but it's not 'magic' on both ends." Got to know your data.
"I got my file and it's all encrypted, what's wrong?" "You might want to check the ASCII/TEXT box."
Still questions today on the mainframe BLKSIZE, or why a PDS won't work, on upload and the 'encrypted' data in the end file in any place it ends up.
Mark
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz
Sent: Sunday, December 02, 2018 1:20 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IND$FILE -- where did the name come from?
I believe that he's using a different meaning of client, e.g., customer.
IND$FILE, SFTP and WSA are all easier to use for people who are not at home with the Eunix utilities.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@LISTSERV.UA.EDU>
Sent: Thursday, November 29, 2018 5:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IND$FILE -- where did the name come from?
Post by Tom BrennanPost by Paul Gilmartinand employees use it to circumvent policies prohibiting data transfer.
Or maybe just to avoid delays in getting what an auditor might call
"proper" access. For example, I've used IND$FILE to transfer an entire
dumped/xmited 3390 volume to a client site,
Don't *you* need to be the client to control IND$FILE? (I'd say, "instructed a client to use IND$FILE to transfer from my site.")
Post by Tom Brennan... because getting sftp port
access (and the associated big ZFS allocated and mounted) would have
probably taken weeks.
Understood about port access. But no need for "big ZFS". once you have sftp you have ssh, so:
cp -B "//'ENTIRE.XMITED.VOLUME'" /dev/fd/1" | ssh client.site "cp -B /dev/fd/0 '//''client.site.volume'''"
(gasp!) Might even use OUTDD option of TRANSMIT to eliminate one more large data set.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------Disclaimer----------------------------
This email may contain privileged and/or confidential information that
is intended solely for the use of the addressee. If you are not the
intended recipient, you are strictly prohibited from disclosing, copying,
distributing or using any of the information contained in the transmission.
If you received this communication in error, please contact the sender
(“Company”) immediately and destroy the material in its entirety,
including all electronic and hard copies.
This communication may contain nonpublic personal information about
consumers which is subject to restrictions under the Gramm-Leach-Bliley
Act and the Sarbanes-Oxley Act. You may not directly or indirectly reuse
or disclose such nonpublic personal information for any purpose other than
to provide the services for which you are receiving the information.
There are risks associated with the use of electronic transmission. The
sender of this information does not control the method of transmittal or
any service providers and the sender assumes no duty, liability, or
obligation for the security, receipt, or any third party interception of
this transmission.
The Company reserves the right to amend statements made herein in the event
of a mistake. Unless expressly stated herein to the contrary, only agreements
in writing signed by an authorized officer of the Company may be enforced
against it.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN