Program Change

1780 pts.
Tags:
AS/400
CL Program
We have legacy software when a user sign's on it takes them to a CL program/menu. If I make a change to a program they have to sign off and back on to ge the new change. Is there anyway to force that change to that user without them signiong off? There has to be away to do this. Thanks

Answer Wiki

Thanks. We'll let you know when a new response is added.

Yes – no – depends on the design
- No, if you update the program called as sign-on the user will have to sign off to get the new version.
- But, you could split the program calling Pgm1 1 on sign-on .. at least I think this will reload Menu1

Pgm1

&IN03 *char 1
Loop:
Call Menu1 &IN03
if (&IN03 = ’1′) goto End
Goto Loop

End: Endpgm

Each time a selection is made in Menu1 it processes that selection and then ends and returns to Pgm1
If the passed parameter isn’t a 1 it reloads Menu1 (which might be new)

Phil

———————————-

I thought you were talking about the program specified in their profile or one they called from the initial program before you made the change and that’s still running. But are you saying that they don’t see any new program until they sign-off and sign back on?

Phil

They do not get the new program until the sign off and back on….
Ron
———————————————-
Ron
These are ILE programs? … SvcPgms? activation groups? Yes, there’s something banging around in my mind about this…I just can’t grab it.
Phil

ILE programs
Ron

+_+_+_+_+_+_+_+_+_+_+_+_+_+

Ron
Ok – found it, sorry it took so long, I’m just getting old. An article by Scott Klement.
Programs stay resident if the DFTACTGRP(*NO)

http://systeminetwork.com/article/terminate-and-stay-residentin-rpg

quote from the above web site & author:
“Program Activation
In the old days of running RPG in the OPM environment, a program was activated when you called it. If you set the LR indicator on and ended the program, the variables would be reset, the files would be closed, and it would be deactivated from memory.

Today in ILE RPG, the behavior is exactly the same when you specify DFTACTGRP(*YES) on the CRTBNDRPG command. However, if you specify DFTACTGRP(*NO), it doesn’t quite work the same way. With DFTACTGRP(*NO), the RPG program follows the rules of ILE. In the ILE environment, a program is to remain activated until the activation group is reclaimed.

Don’t get me wrong. If you turn LR on, your files will still be closed, and your variables will be reset to their initial values the next time the program is called. However, in ILE, LR does not control whether the program is deactivated. Instead, the program is deactivated only if the activation group ends. The fact that it’s still activated is useful, because it means it can sit dormant in memory until a signal arrives, then “wake up” and handle the signal.
Phil
This is very similar to the way Terminate Stay Resident (TSR) programs work in MS-DOS. Those programs end (i.e., “terminate”) in a manner that keeps them loaded into memory (i.e. ,”stay resident” in memory). Then, they can be attached to a hardware device (such as the system clock or the keyboard) and can take action when these hardware events occur. ILE programs don’t work exactly like that, of course. They can’t be connected to hardware events, but they can be connected to signals–and signals can be activated based on an interval of time, so that makes them very similar to an MS-DOS TSR that’s based on the system clock.”
Phil

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Gilly400
    Hi, Sounds to me like the programs aren't ending correctly (setting on *INLR) when the users return to their menu. You could try building a RCLRSC command into the menu so that it runs after each option has completed, this might help you out, but it would be better if the programs set on *INLR and ended correctly (thus removing the loaded object from storage). Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • RonKoontz
    The are ending ok. and the cl calls the program. But the uers session still has the old program till they signoff. Its weird...
    1,780 pointsBadges:
    report
  • Gilly400
    Hi, Have you tried checking the program stack of the job after the program has completed? Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • RonKoontz
    No I have not. What am I looking for?
    1,780 pointsBadges:
    report
  • Gilly400
    Hi, Was just wondering whether the called program was still in the stack for some reason, even after setting on LR and terminating normally? This could be explained by Phil's latest answer about the activation groups. There is apparently a reclaim activation group command (RCLACTGRP). Regards, Martin Gilbert.
    23,730 pointsBadges:
    report
  • BigKat
    You need to be careful issuing the RCLACTGRP. If you do have any service programs running and you issue it, you can wipe out the running service program, but the pointer/link to it still exists and the next time you run a program that uses that service program it will error.
    8,210 pointsBadges:
    report
  • RonKoontz
    BIGKAT, Good thinking. I will keep that in mind b/c I have a few of those.... its problably a good idea to have the user signoff and back on or change it when no user is using it. But its always good to know it can be done if you ahve too. Lots of times its a quick program change b/c testing was not done that well.... Thanks for all your input..
    1,780 pointsBadges:
    report
  • Vatchy
    There's a way to do this if you don't mind re-writing the program. First, you define the display with the maximum number of options that you will need - leave them blank. Define the menu options in a message file. Match the name of the field in the display file with the name of the option in the message file; MNU0001 = menu option 1. Store the description text in the MSGDTA field and the actual command in the SECLVL field. Each time the user chooses an option and the command finishes, loop around to reload from the message file again. Load the menu: RTVMSG MSGID(menu option) MSGF(lib/file) MSGDTA(&MENU) CHGVAR VAR(&MNU0001) VALUE(&MENU) User selects menu option 15: CHGVAR VAR(&MENU) VALUE('MNU00' *CAT &MNUOPT) /* Gives us MNU0015 */ RTVMSG MSGID(&MNUOPT) MSGF(lib/vile) SECLVL(&CMD) /* Gives us the command to execute */ If you reload the menu every time the user selects an option then you can change the menu at will, and the reloading happens so fast the user won't even notice. This also allows you to do all of your menu processing in CL - you only call an RPG program when necessary for additional processing.
    1,410 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following