× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This became a problem in our interactive programs that adjusted inventory in
the 1980's.  We devised a plastic piece that could be glued over the key to
prevent it from ever being pressed.

In S36 days if you adjusted inventory while building an order file (not a
direct one that it) and the operator pressed the SysReq key and took a -3-
the "adds" were lost but the inventory stayed adjusted.  This caused no end
of problems.  I finally put a trap into the program and "caught" the VP of
sales who thought he should normally end the order program by pressing
SysReq and taking a -3-.

And they let these guys vote too......

Ah!!!! Direct files to the rescue but the pointers gave me a pointy head.

Jerry


----- Original Message -----
From: Graap, Ken <keg@nwnatural.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, February 05, 2002 10:59 AM
Subject: RE: Programmatically disable SysReq key


> If you wanted to control what a user can do with the SysRQ key, just
modify
> this message description:
>
> CPX2313
>
> Kenneth
>
> ****************************************
> Kenneth E. Graap
> IBM Certified Specialist
> AS/400e Professional System Administrator
> NW Natural (Gas Services)
> keg@nwnatural.com
> Phone: 503-226-4211 x5537
> FAX:    603-849-0591
> ****************************************
>
>
> -----Original Message-----
> From: Ed Fishel [mailto:edfishel@us.ibm.com]
> Sent: Tuesday, February 05, 2002 10:41 AM
> To: midrange-l@midrange.com
> Subject: Re: Programmatically disable SysReq key
>
>
>
> Fiona,
>
> >How about excluding *PUBLIC  from cmd TFRSECJOB ?
> >Is the overhead the same ?
>
> The amount of overhead for the presystem request exit program depends on
> the program. Most programmers should be able to write an efficient
> presystem request exit program that will not be noticed when it is called.
> Likewise, the authority check of the TFRSECJOB command is not something
> users will notice. You would have to press the system request key a very
> large number of times before you would notice any difference between these
> two solutions.
>
> A question that should be asked is what is the difference between these
two
> solutions. It has been pointed out that the a presystem request exit
> program can keep an *ALLOBJ user from using the system request menu. This
> is true, but it will not prevent them from using TFRSECJOB the next time
> they see a command line. So, if the objective is to keep any user from
> using the system request key during a critical part of the application,
> then a presystem request exit program is a good solution. On the other
> hand, if the objective is to always keep someone from using TFRSECJOB,
then
> you should remove their authority to that command.
>
> Ed Fishel,
> edfishel@US.IBM.COM
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> 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@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> 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 ...

Replies:

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.