Create and initial sigon program for that user and change their USRPRF to use it.
In that program use the TFRJOB command. YOu can put in a JOBQ that is associated with a different subsystem.
-------
If you name the devices in a similar fashion (eg. other*) you can add a generic Work Station Entry to assign these devices to that subsystem.
ADDWSE SBSD(OTHERSBS) WRKSTN(OTHER*)
Now all devices starting with OTHER would start under the OTHERSBS subsystem.
Voodoo
-------
Last Wiki Answer Submitted: October 9, 2009 3:23 pm by CharlieBrowne33,730 pts.
All Answer Wiki Contributors: CharlieBrowne33,730 pts.
If you live outside the United States, by submitting your email address you consent to having your personal data transferred to and processed in the United States.
What activity do you want to have in a particular subsystem for a user? FTP? ODBC? Telnet? What business need is driving the separation by subsystem? Language? Performance? Off-hours work?
Describe the business case and the appropriate solution might be available.
He probably has the need, just needs a technical solution.
I agree, but the need for what? “Connect a user to a subsystem” doesn’t have any useful meaning by itself.
Does it simply mean that interactive jobs for one user should go to a particular subsystem? If it’s because one subsystem is English and another is French for example, there are system facilities that can help. Languages can be associated with subsystems and routing can make decisions. When I’ve needed to work in a particular subsystem, it’s often been because I needed interactive access that the general user base would be shut out of. Normal interactive subsystems might be ended and operational staff needed a subsystem that was open only to them. So, maybe it’s not a language problem; maybe it’s system management — a different approach would be useful. Or maybe one user has a need for regular, intense interactive queries. Subsystem usage for performance is best handled with its appropriate method.
But maybe it’s not interactive at all. Maybe it refers to how you can run ODBC jobs in different subsystems. That’s handled very differently than any of the others. Or other servers…?
I have no problem providing some help. Can you explain what the OP needs?
We do something very similar in our shop. We cloned QINTER SBSD as MISINTER. Then we assigned the IT users to that sub-system. If we ever need to knock all the interactive users off the system while we perform critical updates we can do that and still keep our IT folks alive.
All users have a signon program specified for the “Initial program to call” on their profiles. Then we just re-name the signon program (SIGNON to SIGNONX) this way they just error out when the signon routine can’t find the program specified for the “Initial program to call”. This works well if you want to let them finish up what they are working on but once they sign off they won’t be able to get back on.
What activity do you want to have in a particular subsystem for a user? FTP? ODBC? Telnet? What business need is driving the separation by subsystem? Language? Performance? Off-hours work?
Describe the business case and the appropriate solution might be available.
Tom
You must be a consultant. He probably has the need, just needs a technical solution. BTDT.
He probably has the need, just needs a technical solution.
I agree, but the need for what? “Connect a user to a subsystem” doesn’t have any useful meaning by itself.
Does it simply mean that interactive jobs for one user should go to a particular subsystem? If it’s because one subsystem is English and another is French for example, there are system facilities that can help. Languages can be associated with subsystems and routing can make decisions. When I’ve needed to work in a particular subsystem, it’s often been because I needed interactive access that the general user base would be shut out of. Normal interactive subsystems might be ended and operational staff needed a subsystem that was open only to them. So, maybe it’s not a language problem; maybe it’s system management — a different approach would be useful. Or maybe one user has a need for regular, intense interactive queries. Subsystem usage for performance is best handled with its appropriate method.
But maybe it’s not interactive at all. Maybe it refers to how you can run ODBC jobs in different subsystems. That’s handled very differently than any of the others. Or other servers…?
I have no problem providing some help. Can you explain what the OP needs?
Tom
We do something very similar in our shop. We cloned QINTER SBSD as MISINTER. Then we assigned the IT users to that sub-system. If we ever need to knock all the interactive users off the system while we perform critical updates we can do that and still keep our IT folks alive.
All users have a signon program specified for the “Initial program to call” on their profiles. Then we just re-name the signon program (SIGNON to SIGNONX) this way they just error out when the signon routine can’t find the program specified for the “Initial program to call”. This works well if you want to let them finish up what they are working on but once they sign off they won’t be able to get back on.
Voodoo