If they're THAT good, hire them. 8-)
On Oct 15, 2010, at 10:53 AM, "Scott Rohling" <scott.rohl...@gmail.com<mailto:scott.rohl...@gmail.com>> wrote: Once it's loaded in memory -- what prevents that determined user from reading it out of memory and creating a file? Might have to write your own module.. but I'm just saying ;-) Scott Rohling On Fri, Oct 15, 2010 at 8:11 AM, David Boyes <<mailto:dbo...@sinenomine.net>dbo...@sinenomine.net<mailto:dbo...@sinenomine.net>> wrote: You'll never be able to stop people from copying files to their A disk - and making modifications - including removing any checks you make for an X disk, etc. Users can do an EXECDROP or EXECLOAD on their own - there's not many good ways to stop a determined user from shooting themselves in the foot if they want to. Check out Ken Chamberlain’s LIB tool. It solves this problem by not letting the users actually get to the exec directly – the exec is stored on a disk managed by a virtual machine, and the exec is transferred directly into memory in the user’s virtual machine when you do a LIB EXEC fn fm. The user never has the ability to copy or modify the exec because they never have access to the file. You put a short “stub” exec on the public disk that just does the LIB EXEC command. LIB also keeps counts of how frequently a file is used, and a lot of other nifty stuff. It’s available from the VM Workshop tape (google for it) for free. It’s also a terrific example of how to do highspeed IUCV programming.
