On Thu, Apr 26, 2018 at 11:45 AM, R.S. <[email protected]> wrote:
> "know your job" should not be an excuse for inconvenience. > Why realtively simple and frequently performed activities do require > sophisticated knowledge? > Why new user generations still have to thoroughly study ftp advanced > parameters to finally find out there is no solution for > downloading/uploading dss dumps? > We're talking about basic features which should be available for beginners. > Or maybe we don't want any beginners... > I generally agree with your points above. The only thing that would "worry" me is having a beginner using ADRDSSU. To do a "useful" file transfer to a non z/OS usually requires some "prep" work because most z/OS data has embedded "binary" values which generally cannot just be downloaded and used by some Windows or *IX type application. If the data is already "textual", then the user (beginner or not) does not need to know any advanced ftp parameters. This is an argument against FTP and for something like a "federated SQL database" (e.g. put data on z/OS in DB2 & access it from Windows using a DB2 client -- let DB2 worry about the translation) Speaking of "advanced ftp parameters", you want to know how to drive a Windows person insane? Create a file using a Windows application. Place that file on a "Windows share". Have that file be transferred to another Windows box (perhaps off-company) using the default ASCII mode. And, critically, have the ftp server which does the transfer be a UNIX machine using NFS to access the "Windows share". The file on the far end is now "corrupt" because the original 0x0A0D (Windows line ending) has "magically" changed to have an extra 0x0D at the end. Yes, this has happened here. It's even worse if the Windows app puts into a directory to automatically be FTP'd to z/OS by a UNIX server. Every line in the receiving DSN has a 0x0D at the end. Even worse is when a UNIX ftp server places a text file on a Windows share and then a Windows user ftps that to z/OS. The UNIX ftp server ends each line with a single 0x0A. The Windows ftp client does NOT recognise this as an end-of-line, but only as data. So, with WRAP ON, the z/OS file has a "stream" of bytes with 0x15 bytes instead of individual records. Yes, this has happened too. Correcting this was simple. I use z/OS UNIX to "cp" the data from the DSN to a z/OS UNIX file with -B (binary copy). I then did a "cp -T" to copy that same data back up to the same DSN. Problem fixed. I was definitely the wizard that day. So, in any mixed platform environment, the beginners are at a disadvantage. That is one reason given for the "Windows only" mantra chanted here. There is no need for people to be as intelligent or knowledgeable. > > Regards > -- > Radoslaw Skorupka > Lodz, Poland > -- We all have skeletons in our closet. Mine are so old, they have osteoporosis. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
