hi,
I want to change the user profile 's limit device session to some number value. I have created a CL program which has the parameter of user profile, user library and user limit device session value.
I created a display file to enter the user name , user profile and user limit device session value.
My question is how can i call this display file after creating a command on the basis of my CL program.
Please help,
Thanks,
Siddharth
Hi Tom,
Thanks for the update,
Can you please tell me what are the proper way to call a display file inside a CL program. Shall i user RCVF command or SNDRCVF command.
Also please let me know if i want to display my display file then should i call the CL pgm? Cannot i create a command so that calling that command will call my display file.? Please Advise.
Thanks,
create a command that simply calls a program and the called program can use a display file to get parameters it needs
create a command that calls a program passing it the parameters it needs to run. the command creates its own UIM display to handle prompting (as well as defaulting and validation)
option 1 requires you to create all of the logic and displays. option 2 uses built in logic and display capabilities. if you are making a new command, it is worth the extra effort to learn how to do the prompting, defaulting, and validation there (option 2). if you are retro-fitting something, it may be simpler to just call it (option 1).
To use a display file in a CL program, use the command SNDRCVF.
Yes, it is possible for you to create a command that does nothing more then call the CL program that will use your display file. But as Tom mentioned, why not just put your parameters into the command itself?
Can you please tell me what are the proper way to call a display file inside a CL program.
Declare the display file name using the DCLF command in the CL program. The file will either need to be library-qualified or need to exist in the library list of the job running the CLP.
Most often, programmers use the SNDRCVF command if both output and input are to be done for the same record format. SNDRCVF is more or less equivalent to EXFMT in RPG. If you prefer, you can use SNDF and RCVF to issue separate writes and reads; but that gets to be more complicated.
Still, why do it at all? It seems completely contradictory to the statement that the program "...has the parameter of user profile, user library and user limit device session value." If the program has those parameters, why would the display file ever be used?
Tom
I read the question again and now see that the display file allows entry of "the user name , user profile and user limit device session value." It's not clear why the program parameter list doesn't match the fields on the display file. Nor is it clear why user library is in one list and user name is in the other. And neither of those seem to have anything to do with limiting device sessions.
Perhaps there is much more to the CLP than simply changing a user profile's session limit. (But the use of a display file still doesn't seem necessary.)
Tom
The Limit device session parameter on a profile is a switch. Either limit to one session or allow multiple sessions. You cannot put a number in there to limit device sessions to eg 4.
I would think this is better done from the client side. I'm no group policy expert but i think it might be possible to use GP to limit the number of times a user can run the CA400 program PCSWS.EXE.
You can do this through a CL program at sign-on time: execute a WRKACTJOB to an outfile, then read through the outfile counting the number of times the user's name shows up. If it goes past four then just sign the user off.
Sorry, I should have said a spool file, not an outfile. Copy the spool file to a physical file using CPYSPLF and then read through that file, parsing it as you go.
Good idea vatchy, but WRKUSRJOB USER(username) would be better, specifying JOBTYPE(*INTERACT), will make a much smaller outfile. Then just scan and count jobs in ACTIVE status.... still think the group policy approach would be much more straightforward...
...limit the number of times a user can run the CA400 program PCSWS.EXE.
...which wouldn't affect the number of times that TN5250 or Mocha or even Windows telnet could be used, among others.
...execute a WRKACTJOB to an {spool} file...
I'd write a simple routing program for QINTER that ran QUSLJOB for the job user for *ACTIVE jobs of type 'I'nteractive and retrieved the list count. If it exceeded the number for that user, I'd end the job; otherwise TFRCTL to QCMD. The number could be stored in a simple database table.
Tom
Minor added note -- i 6.1 changes QLMTDEVSSN from holding only '0' or '1' (no limit or limit) to hold '0' through '9' so that up to nine sessions can be explicitly specified. User profile LMTDEVSSN() attributes are similarly changed.
This is still a CHAR value, not numeric.
Tom
Free Guide: Managing storage for virtual environments
Complete a brief survey to get a complimentary 70-page whitepaper featuring the best methods and solutions for your virtual environment, as well as hypervisor-specific management advice from TechTarget experts. Don’t miss out on this exclusive content!
Discuss This Question: 13  Replies
- create a command that simply calls a program and the called program can use a display file to get parameters it needs
- create a command that calls a program passing it the parameters it needs to run. the command creates its own UIM display to handle prompting (as well as defaulting and validation)
option 1 requires you to create all of the logic and displays. option 2 uses built in logic and display capabilities. if you are making a new command, it is worth the extra effort to learn how to do the prompting, defaulting, and validation there (option 2). if you are retro-fitting something, it may be simpler to just call it (option 1).