Having done a few VSE to MVS migrations, let me speak to this at a conceptual level.
What kind of security risk is it for someone to duplicate a volume with sensitive data on it? This can be done with FLASHCOPY or physical volume backup (DSS). Granted, in a VSE shop, programmers get much more freedom than they do under MVS. And just like in the VSE shop, you can access NON-VSAM files as long as you know the VOLSER where the data is. So a CLIP and a VARY ONLINE and the data is available. However, if the senior level programmers have access to flashcopy, how would you know that a volume had not just been clobbered before you got it backed up? Two people using the same "phantom" volume, and the last one to write wins. How would you ensure that the production backups and the programmers are using different volumes for the flashcopy? UNLIKE VSE, MVS does not have the catalogs owning the volumes where their VSAM files are. So "catalog backup" doesn't work for MVS as it does for VSE. And DSS logical backups come close, but there are some gaps that can cause serious heartburn during DR testing. Again, not even using the MVS SMS capabilities, MVS manages files for you, while under VSE, without some third-party product, you (the data manager) must assign EXTENTS on volumes. Very different mind-set and function between MVS and VSE (and granted, my VSE knowledge is rather dated, I really haven't touch VSE for a while, and not even looked at z/VSE). DSS also allows you to take that logical backup and then rename for restore. How do you secure this, so that production data (perhaps subject to HIPPA) doesn't get out in the wild (as it were)? You will want to make sure that the security "keys" in your security system are set appropriately. Which brings up a new set of concepts. What Security system did you have for VSE? If you didn't have one, MVS does things at the data set name level. So it might not matter what the volser is, DSN=A.B.C obtained via the CATALOG system, or via VOLSER will be checked. Many concepts to understand that are very different in their implementations between the two environments. Regards, Steve Thompson <SNIPPAGE> That is the question I am trying to have answered. What harm might be done in giving programmers access to DSS COPY flashcopy? Going by the name of the resource and the comments on http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.i bm.zos.r9.e0zh300/dssracf.htm it would appear that this resource pertains only to DSS COPY and not to Flashcopy in general. Therefore I would think that giving programmers rights to it would not unexpectedly give us rights to something else. Does anyone disagree with this? To answer someone else's question about something having "changed" if we could do this before but can no longer, this is not the case. We are a new z/OS shop (in process converting from VSE), and I had just never tried this function before. Thanks! Frank <SNIPPAGE> -- Opinions expressed by this poster may not reflect poster's employer's views or policies. -- ---------------------------------------------------------------------- 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
