Our ACC product hooks common allocation. We have been doing this type of thing for 20 years (ACC/SRS, Stop-X37, Pool-DASD). The ACC product already has code that adds SUBSYS to dd statements and then uses the subsystem open/close routines to front-end get/put. The hook is used for a compression product that is used in Japan (we don't sell this part in the US). We could look at adding a different module that would do record level security instead of calling the compression routine. Send me an email with your phone number if you want to talk about it.
I am not sure if any other shops would want something like this. If not, then it might not make sense for us to support something for just one. Tom "Victor Gil" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > Thanks a lot to everybody responded. > > Sam, moving production files to a DBMS is not an option at this time as it > would require enormous changes to the applictions. And, yes, we are talking > about thousands of files. > > David, I am not longer a fan of any smart "hooks" into MVS services > [certainly not into OPEN or SVC 99 logic] mainly because of the potential > issues with code maintenance. [Although I have to admit, 25 years ago it > was fun to take over DOS 3.x by coding your own $$B-transient module that > would merely change the new PSW address for, say, Program Interruptions, to > an address passed on the call and then just execute the $$B-module <was it > through SVC 2?> from your problem state routine and divide something by > zero]. And field-level encryption, again, requires massive changes to the > applications. > > TomW, Buying a product that allows to add SUBSYS= to a given DD would be > difficult to justify, but I'd love to learn what MVS services it uses to > perform its magic in the case of a dynamic allocation. > > TomS, I know very little about BatchPipes, but from your description they > don't sound any better than the subsystem approach in terms of the issue > with dynamic allocation. As to your question - the confidential fields > [like the social security number] would be returned scrambled. Obviuosly > they won't participate in any arithmetic computation, nor can they serve as > the "keys" to further locate any associated data. > > Still trolling for ideas, > -Victor- > > ---------------------------------------------------------------------- > 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
