> -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[EMAIL PROTECTED] On Behalf Of shai hess > Sent: Monday, January 28, 2008 12:33 PM > To: [email protected] > Subject: Re: DB2 queries without using MF. > > > HI, > > I think that there is a lot of confusion here. > > We talk about two subjects, Query DB2 from PC and emulate > 3390, mirroring > etc... > > > About DB2, OK there is no RACF in PC, without RACF the > security is not OK. > > About my product MFNetDisk with data in PC, I see a lot of > confusion. I am > RACF supporter as IBM, EMC, HDS disks are RACF supporter. > > Nobody from MF can access my data if RACF does not allowed > it!!! RACF is my > master, I will never do anything without RACF permission. > > Can you explain me what is wrong with data in PC and not in > IBM, HDS, EMC > PCs inside their boxes? > By the way two of these companies allowed accessing the data > from PC using > API, Why I can not do the same? > > Thanks, > Shai >
I think the concern, perhaps with little merit, is that the PC resident data may be accessed by some other PC process, without knowledge. This is likely due to all the horror stories about Windows being subverted and data mined with no knowledge of the company which owned the data. Now, with proper setup, this should not be a real concern. If the PC running your software is secured inside the data center, and if it either has no LAN access to anything other than the mainframe, then I can see using it. Especially, perhaps, for things which do not need the high security. The plus of the other DASD you mentioned is that it is not IP connected. It is connected via Fiber directly to the mainframe. That means that there is absolutely NO way for "somebody" to put a "sniffer" on the LAN and capture data in transit (we do all use TLS for our TN3270 sessions, right?). Of course, if this is a real concern, then the LAN could be set up so that the PC running MFNetDisk was on a separate VLAN or even a physically separate LAN segment that doesn't connect to anything else. Another part of the fear may be that mainframe information is being accessed without any mainframe auditing. I assume that any data which is transferred to another system has already been audited on the Mainframe as being "OK" to send. I also assume that the data, once on the receiving system, is properly secured and access audited if necessary. Lastly, suppose that all the above is properly vetted and secured. There needs to be some way for users of your API to know when the DB2 structure has been changed. For instance, suppose that a table is deleted, or just a column deleted. There needs to be some way for the people who maintain the PC application to know this and update their application. I know that this is a tremendous problem here. Because believe it or not, the PC application people scream if anything changes and they have to modify their code to adjust. This is not a problem with your product, but it is a problem if we on the mainframe side have been "bitten" by it. We have actually had to defer changes due to the PC processes not being updatable in a timely manner. So much for the PC having a faster development cycle. Again, at least around here. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. ---------------------------------------------------------------------- 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
