Siddharth902 Mar 30, 2010   4:15 AM GMT

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,

45 pointsBadges:

BigKat Mar 30, 2010   2:09 PM GMT

you basically have two options:

• 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).

9,460 pointsBadges:

jaydc400 Mar 30, 2010   5:38 PM GMT

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?

45 pointsBadges:

TomLiotta Mar 30, 2010   9:13 PM GMT

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

125,585 pointsBadges:

TomLiotta Mar 30, 2010   11:36 PM GMT

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

125,585 pointsBadges:

pdraebel Mar 31, 2010   8:38 AM GMT

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.

7,545 pointsBadges:

djac Mar 31, 2010   1:53 PM GMT

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.

900 pointsBadges:

Vatchy Mar 31, 2010   2:45 PM GMT

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.

1,415 pointsBadges:

Vatchy Mar 31, 2010   2:52 PM GMT

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.

1,415 pointsBadges:

djac Mar 31, 2010   3:24 PM GMT

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...

900 pointsBadges:

djac Mar 31, 2010   3:26 PM GMT

In fact you can also use the STATUS(*ACTIVE) parameter so you will only get the relevant jobs. Have to be careful of group and SYSRQS jobs though...

900 pointsBadges:

TomLiotta Mar 31, 2010   9:48 PM GMT

...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

125,585 pointsBadges:

TomLiotta Apr 5, 2010   9:19 PM GMT

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

125,585 pointsBadges: