Path: utzoo!utgpu!ugw.utcs.utoronto.ca!CUNYVM!IBMTCP-L Date: Mon, 5 Feb 90 06:01:05 EST Reply-To: IBM TCP/IP For VM List Sender: IBM TCP/IP For VM List From: Heinz Naef X-To: IBMTCP-L@CUNYVM.BITNET, wbwa@cgch.UUCP, whwb@cgch.UUCP, To: UofToronto LAN redistribution Message-ID: <90Feb5.064835est.57424@ugw.utcs.utoronto.ca> Newsgroups: list.ibmtcp-l Distribution: ut Approved: devnull@gpu.utcs.toronto.edu To: chx400!cernvax!CUNYVM.BITNET!IBMTCP-L Subject: Re: FTP Client in batch ..bad dsn prefix Newsgroups: list.ibmtcp-l In-Reply-To: <9002030545.AA21440@dxmint.cern.ch> Organization: CIBA-GEIGY AG, Basle, Switzerland Cc: whwb wwre wjdh wvmj wbwa David, in article <9002030545.AA21440@dxmint.cern.ch> you write: >When running the following job: > //FTPJOB JOB ,TIME=(0,1) > // EXEC PGM=IKJEFT01,DYNAMNBR=20 > //SYSTSPRT DD SYSOUT=A > //SYSTSIN DD * > FTP > /* > //INPUT DD * > host1.host2.domain > username > password > get foreign.file local.file > quit > /* > //OUTPUT DD SYSOUT=A > // > >FTP is not looking in the right place to get the name of the high-level >qualifier for the local dataset name. It seems to use the jobname >(FTPJOB) as the high level qualifier and attempts to make a dataset >named 'FTPJOB.local.file'. The question is "how can the background TMP know which TSO user it should represent?". If you are running a clean MVS/TSO system, you may have to add USER=,PASSWORD= to the JOB statement. There may be local arrangements, handled in some JOB-/STEP-/SAF-initialization exit routines, to get this sort of information from somewhere else. In our environment, for instance, we are propagating this information from the TSO user submitting the batch job. This prevents supplying critical data like the password in the job statement. I tested the job stream above on our system and it works great. > >I believe the correct answer would be to use the DSNAME PREFIX at >offset X'10' of the UPT, label=UPTPREFX. > You are right! Please read the enclosed message. > >Am I missing something? Is this a bug? > You only missed the fact of determining the correct userid, the rest "works as (currently) designed". > >BTW, we are running TCP/IP for MVS under MVS/XA with the PTF tape >applied. > We too. > -- Begin enclosed message This message addresses the concept used in MVS TCP/IP to build high level dataset name qualifiers for identifying a user or . It doesn't deal with the concept of naming the TCP/IP internal datasets. MVS TCP/IP adopted for the or identifiers in client or utility programs the concept used in the command language of early TSO releases: - If a or is specified within quotes, it is kept as it is, e. g. FTP "cd 'foo.bar'" changes the current directory to FOO.BAR. - If a or is specified without quotes, it is prepended by the TSO/SAF , e. g. for TSO user FOOBAR FTP "cd lib.data" changes the current directory to FOOBAR.LIB.DATA (if it was previously set to FOOBAR, which is the case at the beginning of an FTP session). In subsequent TSO releases, a user selectable object called was introduced. It allows a user to specify a value that is different to the TSO/SAF . Many installations, including ours, decided to take advantage of this option in order to optimize MVS master catalog usage ( = would require each TSO/SAF user to be anchored there). Under TSO/E (the most recent TSO release) the same concept is still there. In an environment where both TSO/E and MVS TCP/IP are used - which is the normal case - and != was chosen, the following problems occur: a) If the MVS TCP/IP FTP server is accessed by a user which is registered as a TSO (and SAF) user, the server cannot set the initial directory to the real root of the user's files. After USER and PASS validation, the user has to manually change to the real in order to make his or her files available. b) If a user forgets to manually set to the proper , then each attempt to create/alter a file will fail. c) MVS TCP/IP utility commands (e. g. makesite) fail because they try to dynamically allocate files with high level qualifier equal to . To eliminate these problems, MVS TCP/IP should be changed to fully adopt the concept of fully qualifying or identifiers, e. g. FTP server: - A new FTP server configuration option TSOCHECK/NOTSOCHECK should be introduced, with default TSOCHECK. - A new field "MyPrefix" should be added to the user (FTP client) related data structure of the FTP server (or better throughout the product). - After identifying a valid USER / PASS combination via RACROUTE VERIFY, the FTP server should fill both "MyId" and "MyPrefix" with as an initial value. - If TSOCHECK is enabled, the FTP server should now check if there is a TSO User Attribute Dataset (SYS1.UADS) present or the installation uses the SAF (e. g. RACF) TSO segment. If yes, it should check if is registered there. If yes, it should extract the UPTPREFX field from the UPT segment of the stored data for user and place it into "MyPrefix". - "MyPrefix" should be used instead of "MyId" at all places where a or has to be fully qualified. E. g. an FTP "cd" subcommand should implicitly use the value of "MyPrefix" to identify the user's root directory. This should be done in all client and server components (which dynamically allocate user related datasets or set directory names) throughout the MVS TCP/IP product. We regret that we can no longer change our environment to meet the requirements of the MVS TCP/IP product. This would consist of - adding > 4'500 TSO/SAF to the MVS master catalog - renaming > 80'000 MVS datasets (on online and offline media) - changing thousands of JCL streams to the new DSNAMEs, in production jobs and at the user's side Since the change involves an extension of a common data structure used throughout the product, we agree that it cannot easily be done as a local fix. Therefore, we ask you to plan this change for the next release of the product. Thanks, and best regards, Heinz Naef, c/o CIBA-GEIGY AG, R-1045.3.37, P.O.Box, CH-4002 Basel, Switzerland UUCP: cgch!whna Internet: whna%cgch.uucp@uunet.uu.net Phone: (+41) 61 697 26 75 BITNET: whna%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88 --- End of enclosed message Heinz Naef, c/o CIBA-GEIGY AG, R-1045.3.37, P.O.Box, CH-4002 Basel, Switzerland UUCP: cgch!whna Internet: whna%cgch.uucp@uunet.uu.net Phone: (+41) 61 697 26 75 BITNET: whna%cgch.uucp@cernvax.bitnet Fax: (+41) 61 697 32 88