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-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: Sunday, December 02, 2018 1:20 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU> on behalf of Paul Gilmartin <0000000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Thursday, November 29, 2018 5:47 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: IND$FILE -- where did the name come from? On Thu, 29 Nov 2018 12:13:05 -0800, Tom Brennan wrote: > >> and 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.") >... 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 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 ----------------------------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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
