|
Sure, Problem is that it wasn't needed years ago when the applications were originally written; nor was it given any thought as to a possible future requirement. Now we need it. Try to add it into the design of the applications themselves will not be very easy. Charles > -----Original Message----- > From: Mark S. Waterbury [mailto:mark.s.waterbury@xxxxxxx] > Sent: Friday, August 06, 2004 12:57 PM > To: Midrange Systems Technical Discussion > Subject: Re: Break Object Locks > > > Charles: > > In my opinion, this type of "locking" should be "designed in" to the > applications themselves (or perhaps if the application has > its own "menu > security" system, you can control it that way). > > For example, if there are certain critical areas of the > application that you > don't want any users to be able to go into at certain times (e.g. > end-of-month), you could create a data area that represents > this "critical > region" and then issue ALCOBJ against this *DTAARA, with > *SHRRD, and if > successful, allow the application to continue. Then, to > "lock out" the > users from that section, issue ALCOBJ for that data area with *EXCL... > > Does this "make sense" to you? > > Regards, > > Mark S. Waterbury > > ----- Original Message ----- > > From: <CWilt@xxxxxxxxxxxx> > > To: <midrange-l@xxxxxxxxxxxx> > > Sent: Friday, August 06, 2004 10:43 AM > > Subject: RE: Break Object Locks > > > > > Rob, > > > > Any thoughts as to how to prevent users from getting back > in to certain > > programs/files? > > > > We need to implement something to lock out accounting stuff > mostly during > > our end of month. Ending QINTER, isn't an option because > other users can > > still be working. > > > > Charles > > > > > > > -----Original Message----- > > > From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] > > > Sent: Thursday, July 01, 2004 4:08 PM > > > To: Midrange Systems Technical Discussion > > > Subject: Re: Break Object Locks > > > > > > > > > End all the jobs that have a lock on the file. Do it all the > > > time in our > > > backups. > > > > > > Rob Berendt > > > -- > > > Group Dekko Services, LLC > > > Dept 01.073 > > > PO Box 2000 > > > Dock 108 > > > 6928N 400E > > > Kendallville, IN 46755 > > > http://www.dekko.com > > > > > > > > > > > > > > > > > -- > > This is the Midrange Systems Technical Discussion > (MIDRANGE-L) mailing > list > > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > > or email: MIDRANGE-L-request@xxxxxxxxxxxx > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/midrange-l. > > > > -- > This is the Midrange Systems Technical Discussion > (MIDRANGE-L) mailing list > To post a message email: MIDRANGE-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/midrange-l > or email: MIDRANGE-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.