Programming Languages on Power

Programming Languages on Power

Connect, learn, share, and engage with IBM Power.

 View Only

  • 1.  Trying to close a "remote" activation group.

    Posted Fri October 11, 2024 02:18 PM

    Hello everyone!

    The question:
    We have a job running, which starts at the request of apache (it is a "REST service"). This job starts, but never ends, because from that job, different calls are made to different programs...
    Well ... some of those programs that run in this "job" are using service programs, which remains in memory.
    The problem I have is ... when I want to modify one of these service programs... what is the best way to proceed?  I know one of them is closing those jobs ... but, is there any other better way??  

    Thank you!



    ------------------------------
    Christian Larsen
    IBMi RPG Analyst/Developer
    Mayoral Moda Infantil, SAU
    Málaga
    +34 661627947
    Spain
    ------------------------------

    #RPG


  • 2.  RE: Trying to close a "remote" activation group.

    Posted Mon October 14, 2024 01:22 AM

    Hi Christian,

    You group your REST service at least into two group. For each group define let say port 9991 and 9992. Front end request should go to load balancer, and your load balancer will check if port 9991 is alive then request goes to group1 or  to group2 in case port 9992 is alive. In case both of them is alive, load balancer can sent to any group.
    If you need to refresh the job after deployment, first you kill port 9991 and wait until no more request coming in, then you kill all jobs in group1. After finish deployment, start the group1 and your port 9991. Do in the same for group2. With this approach, you can expect no downtime on the REST service.



    ------------------------------
    Hadi Santoso
    ------------------------------

    Original Message


  • 3.  RE: Trying to close a "remote" activation group.

    Posted Tue October 15, 2024 03:27 PM

    Its a great idea that Hadi suggested generally with any load balanced options for websites (definitely assists with uptime for service levels).

    If "bouncing" services might not be a viable option, consider similar mechanism that Alan Campin used with Trigger Mediator : https://www.think400.dk/downloads.htm 

    He loads service program details in UserSpace , then toggles appropriate refresh criteria when ever changes happen.

    Might  be of use to you in manner if you can retrofit mechanism.

    Regards

    Marius



    ------------------------------
    Marius le Roux
    Owner
    MLR Consulting
    ------------------------------

    Original Message


  • 4.  RE: Trying to close a "remote" activation group.

    Posted Wed October 16, 2024 05:45 AM

    It depends on the overall architecture that must be assessed.... but, never tried in this context, but, as a general idea to throw around, if you run a particular named activation group, you can run in the controlling top program a reclaim (RCLACTGRP ACTGRP(MYSRV001) ) when some condition arise (parameter, "refresh command", once some condition change etc.), this should unload the program resources and force a reload.

    *NEW ACTGRP, again depending on performance , architecture etc. should produce also this effect.

    Can be unrelated, and I was not using service program here, but just to open the discussion... I had a "service/daemon" program that had to run continuously unattended in a loop (drove a screen slideshow on a big screen showing info 24h/24h) in a job, I was using this strategy to force program swap consistently in the context of default vanilla program groups environment... only way I was able to swap it consistently... basically PGM001 was doing nothing, PGM002 what was driving things and I could hot swap it when needed keeping the slideshow process up..

    P.S. shame that even an IBM forum (!) doesn't have the option to format as RPG a code sample... bah... ;PPP

    DCL-PR pgmToCall EXTPGM(PgmName);
       END-PR;

DOW *ON AND NOT %SHTDN;
         pgmName = 'PGM001';
         pgmToCall();
         pgmName = 'PGM002';
         pgmToCall();
ENDDO;



    ------------------------------
    --ft
    ------------------------------

    Original Message


  • 5.  RE: Trying to close a "remote" activation group.

    Posted Wed July 09, 2025 02:08 PM

    I created something like that some weeks ago.

    A background job is running, and with every loop it runs a SQL query to find the latest change date of itself (the *PGM object) and all relevant service programs. If that date has changed since the first run, the program terminates with a special "return code" (I chose 'RC' for re-call). The surrounding CL program has an activation group of *NEW and detects the special return code 'RC'. If it receives that code it does a RCLACTGRP and restarts the background program.

    If you like I can send you my SQL - but it's quite simple with the PROGRAM_INFO view and MAX(SOURCE_FILE_CHANGE_TIMESTAMP) - I simply retrieve the maximum timestamp - as any change must be newer than the last maximum retrieved (normally at startup time). 

    This works quite well, and I normally don't have to re-start the background worker manually. Of course you have to create the list of service programs manually, as there is (AFAIK) no way to get a list of loaded service programs of a running job as loaded but inactive service programs are not in the call stack.

    HTH and kind regards,
    Daniel



    ------------------------------
    Daniel Gross
    #IBMChampion
    Senior Core Developer, Geis Group
    Pegnitz, Germany
    https://blog.qpgmr.de/
    ------------------------------

    Original Message


  • 6.  RE: Trying to close a "remote" activation group.

    Posted Wed July 09, 2025 05:08 PM
    I implemented something similar to Daniel's solution some years ago. 

    In my case each Service Program that was a candidate for a reset had its own named data area that contained the latest version number for that SP. That number was incremented any time the SP was updated. Each time the SP was invoked it checked its internal number with that in the data area and initiated the reset mechanism if there was a mismatch.

    In the case of Apache jobs, I also found it easier to recycle the server at off-peak times to minimize the number of resets during peak periods.

    An alternative approach is to switch to using pointers for the SP procedure calls and resolve those addresses dynamically at SP startup and whenever a reset is needed.




    Original Message


Related Content