>Question, how are you going to handle security, especially if its RACF?
Two options: 1. Query MVS RACF from PC before accessing the data. 2. Using MFNetDisk security which allow only specific IP to access the data (IPOK in my documentation). >Security, Security and more Security. MFNetDisk mirrors and data is not going to be a site which everyone in the world can access, put virus and surf the Internet. I want to hear from all of you (please do not mention RACF again because this will force me to access MF) what you think about security in MFNetDisk data and mirrors. What is the best way to handle security better then allowed only specific PC to access the data. Thanks, Shai On 1/25/08, Ed Gould <[EMAIL PROTECTED]> wrote: > > Shai: > > Question, how are you going to handle security, especially if its RACF? > > Ed > > On Jan 25, 2008, at 1:15 AM, shai hess wrote: > > > I agree with you. > > > > To develop the support for DB2 queries in PC without accessing the > > MF is > > complicate mission. > > > > I will do it only if many people will ask me to do this feature. > > > > But I think that the benefit of accessing the DB2 from PC can save > > a lot of > > money because it will save the people the money to buy more MF and > > software > > and the performance will be the best (the speed of the Intel > > processor and > > the hard disk). > > > > Thanks, > > Shai > > > > > > On 1/24/08, Timothy Sipples <[EMAIL PROTECTED]> wrote: > >> > >> Rob Wunderlich writes: > >>> JDBC/ODBC access to z/os DB2 works well, but it's expensive > >>> (relative term). > >> > >> I think you used the word "perceived" elsewhere, and there are those > >> perceptions, yes. It's a multi-party effort to make sure the truth is > >> understood. > >> > >>> The cost for drivers, whether DB2 Connect or another vendor, is > >>> enormous. > >> I > >>> have web servers, data warehousing, windows server apps and desktop > >>> clients all accessing DB2 data. If I want to add a CPU to webapp > >>> server, > >> the > >>> driver upgrage fee is more than the cost of the entire server. > >> > >> You would seem to be in the perfect situation, at least outwardly, > >> for DB2 > >> Connect Unlimited Edition. It's very much like the MQ Client Access > >> Feature: you pay a fixed rate based on your MSUs, and you're done. > >> You > >> don't even need to contact IBM when you add server #685 or user > >> #3163. > >> (Put Connect on Linux on z and add a zIIP for best results.) Other > >> vendors > >> may offer similar terms. > >> > >> I'm sure all those Web servers, data warehousing servers, and > >> server apps > >> are free to acquire and maintain, but that's a topic for another > >> day. :-) > >> > >> On the general topic, there are about a million ways already to > >> copy DB2 > >> z/OS data somewhere and do something with it. They all share some > >> common > >> disadvantages, many already mentioned. The winds seem to be blowing > >> against > >> doing that sort of thing nowadays. A lot of businesses are terribly > >> worried > >> about failing to protect sensitive data, and the word "copy" is > >> inherently > >> antithetical to data protection (except in the narrow and tightly > >> controlled DR sense). I call the trend "data recentralization." > >> There's > >> also an increasing appreciation for the high costs of too highly > >> distributed data models, and data warehouses are becoming much more > >> mission-critical (and numerous).... Interesting times we live in. > >> > >> My free advice, for what it's worth, is to figure out better ways for > >> customers to take advantage of DB2 (and other data) right on the > >> mainframe, > >> to answer critical business questions on a need-to-know basis, with > >> up-to-the-second consistency. There's a tremendous market for > >> that. IMHO, > >> creating the million-and-first way to copy data somewhere else to > >> then > >> operate on it won't be as interesting. > >> > >> By the way, I expect that going behind DB2's back and accessing > >> underlying > >> files will become increasingly less and less fruitful. DB2 > >> function has > >> been galloping ahead rapidly, and it's going to get more and more > >> difficult > >> to make any sense of what's underneath. There's also no guarantee > >> whatsoever that what's underneath will stay the same from version to > >> version. And more and more of it is going to be encrypted anyway > >> as, for > >> example, customers use SQL ENCRYPT vocabularies, so you'll need > >> the key(s) > >> to decode it. Those who have the key probably won't (shouldn't) > >> give it. > >> There are also complications like stored procedures, which are > >> getting > >> more > >> numerous and complex, expanding data types, XML, rapid changes to > >> indices, > >> conversion to Unicode.... This stuff is in very rapid motion, and > >> you'll > >> need to keep up. > >> > >> Basically what you're talking about is reverse engineering a good > >> chunk of > >> DB2, and to keep reverse engineering it as DB2 evolves. My hunch > >> is that's > >> a big, never-ending project. :-) > >> > >> - - - - - > >> Timothy Sipples > >> IBM Consulting Enterprise Software Architect > >> Specializing in Software Architectures Related to System z > >> Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific > >> E-Mail: [EMAIL PROTECTED] > >> --------------------------------------------------------------------- > >> - > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
