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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.