Moving an Interactive call to another subsystem.

[trevor.lazarus@ssa.gov]

Start with TFRJOB Is this to just transfer the job to another subsystem? Or is there more to this... such as how to call a program and start it in another subsystem? Trevor

[jrhoads@cdsgroup.com]

TRNJOB - doesn't this transfer the whoel job? User, NUmber etc? I just want to call a program and move that call (active call) to another subsystem? Will TRFJOB still do the trick? Thanks.

[Guest.Visitor]

"Jrhoads" <Jrhoads@mcpressonline.com> wrote in message news:3d993ee2.1@WebX.WawyahGHajS... > TRNJOB - doesn't this transfer the whoel job? User, NUmber etc? I just want to call a program and move that call (active call) to another subsystem? Sounds like SbmJob. Bill

[jrhoads@cdsgroup.com]

For my circumstance, I can't use the SBMJOB command. I am adding a call to a program in the beginning of my app which will allow me to monitor how many people are in the application. I want to be able to control the number of users able to get into the sapplication at one time. I can submit it to a sub system with a limit to the number of jobs allowed (which is what I want to do) but if a user ends abnormally for some reason, there is no way to know which job was his to end. If I could do it with an interactive call, move the call to a new sub sytem, if the user ends abnormally it would end that job. Understand what I want to do? I am not sure how to go about this...? Any suggestions??? Thanks for the response. Jeff

[G.Gaunt]

Have you considered counting job locks on some token object in your application, instead of a incrementing a counter? They unlock when jobs end.

[jrhoads@cdsgroup.com]

I have, however, how much overhead is involced in doing this? What command is used? I will be doing all of this before the user even gets into the program. Would this cause a lot of overhead when doing it? Thanks for the response...

[G.Gaunt]

Lock overhead is negligible. Consider this application wrapper: <pre> ALCOBJ OBJ((LOCKER *DTAARA *SHRUPD)) /* do your application */ DLCOBJ OBJ((LOCKER *DTAARA *SHRUPD))</pre> When you want to see who's in your application, just type: <pre> WRKOBJLCK OBJ(LOCKER) OBJTYPE(*DTAARA)</pre> Also calling the Retrieve Job Locks (QWCRJBLK) API (in the Work Management APIs book) at application start-up could help you govern the number of concurrent users.

[Guest.Visitor]

If the job is interactive, the user can easily deallocate LOCKER. If the job runs in batch it will only be slightly trickier.

[jrhoads@cdsgroup.com]

Can anybody tell me if it is possible to move an interactive call to a different subsystem? If there a command to do this? I think this is a longshot but maybe somebody knows. Thanks.

[rdean400@yahoo.com]

Have you checked out the System Manager Reference? It has documentation for the license manager functions/APIs that are part of OS/400: Here's a link: http://publib.boulder.ibm.com:80/cgi-bin/bookmgr/BOOKS/qb3alk01/4.0 I've never had a need to do license management, but if I did, this would be the first place I'd check.

[B.Morris]

If you add a cancel handler at the top of your application, you can be sure you know when the application ends, for any reason. Here's the general method for using a cancel handler. main program (or some early program that is active during the whole application): - increment the counter, alcobj, whatever - enable the cancel handler "canhdlr" - do your application - call "cleanup" In "canhdlr": - call "cleanup" In "cleanup": - decrement the counter, dclobj, whatever - disable the cancel handler No matter whether your application ends normally or because of a crash, or subsystem end or whatever, your cleanup routine will get called. If your main program is CL or some other OPM program, change it to an RPGLE program that enables the cancel handler, calls your existing main program, and then calls cleanup. Here's a toy ILE RPG program that enables a cancel handler. To see it in action, start the debugger, and step through the program. To simulate the job ending or the program crashing, just use F3 to exit the debugger. This kills the program. Your cancel handler should fire, and call cleanup. H DFTACTGRP(*NO) D CanHdlr PR D Cleanup PR D Handler S * PROCPTR INZ(%PADDR('CANHDLR')) * enable the cancel handler C CALLB 'CEERTX' C PARM Handler C PARM *OMIT C PARM *OMIT * this is the "application" C EVAL *IN10 = '1' C EVAL *IN20 = '1' * end of the application C CALLP Cleanup * disable the cancel handler C CALLB 'CEEUTX' C PARM Handler C PARM *OMIT C RETURN P CanHdlr B c 'canhdlr' DSPLY C CALLP Cleanup P CanHdlr E P Cleanup B c 'cleanup' DSPLY P Cleanup E