On 01 Jun 2013 07:14, John Mathew wrote:
I need to develop a program that should not allow any user to login
into live system during some activity. For this program we need to
exclude few profiles that is a exception.
Can some please advise how to develop this.
The term "login" would need to be clarified, to obtain the best
responses. Likely useful to someone providing a response, is to have an
idea of the system Work Management setup and a more thorough definition
of what is required during that time-period of effective /login
prevention/ with regard to those subsystems [left] running and those
that will be started. What is done for existing activity by the
disallowed users, I suppose, we should infer already would have been
ended; and all Job Queues they could use have been held?
If the term /login/ in the context of the quoted message is limited
to /interactive/ signon via a local or virtual 5250 session, then what
is generally the most appropriate means to implement the desired effect
for a typical Work Management setup, is a Routing Program defined by the
Routing Entry (RTGE) [or Entries] for the interactive subsystem(s). The
Routing Data in the Job Description of the User Profile determines the
routing per the ADDRTGE or CHGRTGE established for the Subsystem
Description. Although it may sound complicated, it is often the
simplest and most encompassing, using one program that both replaces the
QCMD as the routing program and performs the decision-making to either
end the signon or to issue the request to Transfer Control to the
program it replaced; i.e. TFRCTL QCMD. Note: The QCL routing program
could be replaced similarly, additionally, or like all of the
unnecessary distinct compare values routing to the same program anyhow
per the generic Compare Value CMPVAL(*ANY), the use of Remove Routing
Entry (RMVRTGE) might be most appropriate.
However if\when the Initial Program (INLPGM) or a called program from
the Initial Program is already [or can be] established in all user
profiles that should be affected, and these users are prevented from
overriding the signon\initial program from the signon screen [or may be
necessary also they are prevented from changing that setting with
CHGPRF], then the InlPgm as the means to implement the desired effect is
generally acceptable, or possibly better than subsystem job routing.
If the overall concern during this particular time-period is
generically for the prevention of concurrent [conflicting] activity
being started, then the interactive login is only a fraction of the
possible origins for new jobs. If there must be control over /batch/
work that might enter an active subsystem, the initial program for a
user will be of little use. The routing entries also might not suffice
except possibly additionally for some submitted batch jobs. For example
there could be scheduled jobs or requests made into a server job such as
FTP or ODBC; such jobs might need to be prevented as well, but if they
are not, then realize that they can start new work [including new jobs]
just as could the same user could if signed on to an interactive session.
midrange.com
