Re: User Login

[CRPence <CRPbottle@xxxxxxxxx>]

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.