Fred, Have you looked at using a special default esoteric for FTP allocation, like FTPDA and test for this against &UNIT in the ACS routines? Where true there can be some following logic to establish if &HLQ=&USER and deny the allocation within the ACS routines.
That way you would never get to the WTOR. It's off the top of my head, but I'm sure you can come up with the right variables to use in the ACS routines to block this allocation. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of > Fred Schmidt > Sent: Thursday, April 29, 2010 5:23 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: [IBM-MAIN] REPLY DEVICE NAME OR 'CANCEL' for FTP to mainframe and > SMS ACS routines > > Thanks for all the responses. Unfortunately, I don't think they solve the > issue... > > Terry Sambrooks <terry.sambro...@btclick.com> > It might be a sledge hammer approach, but is the ALLOCnn member of PARMLIB > any use. > ... see my original post... ALLOCxx would fail *all* such requests, not just > FTP, and I am nervous of the potential implications. > > Bri P <pilgrim...@ntlworld.com> > I don't have anything particularly fancy in place, just the FTP server > config statements for the default disk allocation volume, and DCB > parameters, and the rest is just RACF - they don't have write access. > .... a default disk allocation volume presumably bypasses SMS allocation... > this is not something we want. > > Lizette Koehler <stars...@mindspring.com> > Another thought might be an automation solution. > ... there doesn't seem to be anything in the WTOR or associated messages > that identifies this as an FTP. Again, we don't want all allocations to fail. > > Denis Gäbler <denisgaeb...@netscape.net> > I had a similar idea with an exit replying cancel to all WTORs for > unavailable volumes. > ... as for automation, this would cancel all such allocations. > > Paul Gilmartin <paulgboul...@aim.com> > Another thing could be to make the HFS directory the default when logging in > with a FTP client. > ... I suspect the problem is leaving out the quotes in the put to the > mainframe, which this suggestion would not address. And some of our FTP's > are to zFS/HFS files. > > Hal Merritt <hmerr...@jackhenry.com> > You might try removing the alias from the master catalog or blocking access > to specific user catalogs. > ... we do not have an alias defined and the user has no access to update the > master catalog. Unfortunately, SMS gets its ugly head in there looking for a > suitable volume before things get to the cataloging stage. > > I can't help but think that there must be something obvious that we have > overlooked, but can't find it. Why should FTP allocations be any different > to other allocations? > > Fred. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
