Re: User Login

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.