Comments on: RPG and Service Programs

By: murrayinfosys

murrayinfosys — Fri, 29 Oct 2010 00:14:14 +0000

All -
I use “Group” jobs all the time for testing. Especially for testing RPGSQL programs.
When I ENDGRPJOB, It removes ALL the activation group jobs within that job. Almost like SIGNOFF

Phil

By: bigkat

bigkat — Thu, 28 Oct 2010 13:17:37 +0000

BTW: group jobs are different than activation groups.

Group jobs are “kinda” like opening multiple virtual sessions, but all through one sign-on session. Whichever group job is active runs, and the rest wait on you to trasfer back and do something there. You can’t switch while a process is running, so if you key a command that is going to run (interactively) for 20 minutes you can’t switch over to do something else, but it is great to be able to pull up a screen in one job and when you need to lookup something to enter a second one without losing your place in the first

By: bigkat

bigkat — Thu, 28 Oct 2010 13:10:41 +0000

I still use group jobs because on some of the systems I work on, we aren’t allowed to sign-on to multiple sessions

By: tomliotta

tomliotta — Thu, 28 Oct 2010 08:12:42 +0000

…what is the command to “drop” the testing group?

For BigKat’s suggestion, review the CHGGRPA, TFRGRPJOB and ENDGRPJOB commands. They’ve kind of faded from use since PCs with multiple emulator session windows have taken over everything, but group jobs can supply some really nice effects. (TFRSECJOB can also be handy, combined with group jobs or not.)

Tom

By: tomliotta

tomliotta — Thu, 28 Oct 2010 08:03:39 +0000

I have an activation group that I use to store temporary data elements in. These data might be generated early in the job and be needed at any time later. It’s unpredictable when a data request module might be called; but as long as the activation group isn’t reclaimed, the data items are available and generally invisible.

No need to store in a temp object in QTEMP, which might be seen and displayed, not to mention possibly changed. No need to pass parms through an unknown series of program calls. Set it and forget it, until needed. If not needed, it goes away just like QTEMP.

Not a perfect solution for many things, but it works well for the right problems. Until you use features, you never know when they might be the right answer.

Tom

By: paolo51

paolo51 — Thu, 28 Oct 2010 06:41:07 +0000

Thanks for the clear frame of reference you added to the subject, Tom.
I admit I’ve always avoided working with activation group.
I simply did not understand his potential use in the activity of maintainig software.

By: tomliotta

tomliotta — Thu, 28 Oct 2010 01:02:43 +0000

You can probably imagine the potential problems if replacing a program actually replaced programs that were in use.

By keeping processes active within activation groups, you can update programs while production users are active. By running RCLACTGRP, your application can choose when to bring new versions into active jobs. You can collect multiple related programs into the same named activation group, or you can separate them into as many activation groups as you need.

You can use the activation group *NEW if you want a program to start its own temporary activation group that will automatically disappear as soon as the program ends.

You can use the activation group *CALLER when you want your program to run in the activation group of whatever program called yours (even if that one was *NEW or the ‘default’ activation group).

They’re a little confusing at first. They’re really handy when you see what they can be used for.

Tom

By: paolo51

paolo51 — Wed, 27 Oct 2010 15:31:35 +0000

That’s exactly what I was looking for: a way to clean up the working space.
Ok, but what is the command to “drop” the testing group?
Thak you.

By: bigkat

bigkat — Wed, 27 Oct 2010 14:46:24 +0000

I use multiple group jobs in my session. One to code/compile, another to test. After I make a test, I drop that group job. After recompiling, I start a new testing group job