Activation group problem - IBM AS400

This is a discussion on Activation group problem - IBM AS400 ; I made an utility with some srvpgm a command and a command processing program that bind to a srvpgm. For some starnge reason the very first time the command run, fail with no message, just doesn't do its duty. All ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Activation group problem

  1. Activation group problem

    I made an utility with some srvpgm a command and a command processing
    program that bind to a srvpgm. For some starnge reason the very first
    time the command run, fail with no message, just doesn't do its duty.
    All next times I execute the command in the same job, it runs just fine.
    Tracing the job I see that when it's time to execunte a certain
    procedure, a C function, a CEE3101 massege comes out and the control
    return to the main procedure without having done nothing and without any
    message. The C function doesn't do anything particular, it just fopen a
    stream file, do some calculation fwrite its results an fclose.
    Recreating the srvpgm with a named activation group, as suggested by
    CEE3101 message, it runs fine even the first time. This way, any global
    varaible used by the service program is not the same as the program sees
    , so the content is lost.
    So I created the program with a named activation group and the service
    program with action group *caller. In my opinion both program and the
    service program should run in the named activation grout, not the
    default one. But the very strange thing is that the behavior is the same
    as at the beginnig.
    The same behaviour can be reproduced starting from V4R4 up to V5R4, so
    I'm confident that it should not be an OS problem, I pretty sure that's
    a problem of mine!
    Could someone explain such figure?

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  2. Re: Activation group problem

    On Jun 22, 7:30 am, "Dr.UgoGagliardelli"
    wrote:
    > I made an utility with some srvpgm a command and a command processing
    > program that bind to a srvpgm. For some starnge reason the very first
    > time the command run, fail with no message, just doesn't do its duty.
    > All next times I execute the command in the same job, it runs just fine.
    > Tracing the job I see that when it's time to execunte a certain
    > procedure, a C function, a CEE3101 massege comes out and the control
    > return to the main procedure without having done nothing and without any
    > message. The C function doesn't do anything particular, it just fopen a
    > stream file, do some calculation fwrite its results an fclose.
    > Recreating the srvpgm with a named activation group, as suggested by
    > CEE3101 message, it runs fine even the first time. This way, any global
    > varaible used by the service program is not the same as the program sees
    > , so the content is lost.
    > So I created the program with a named activation group and the service
    > program with action group *caller. In my opinion both program and the
    > service program should run in the named activation grout, not the
    > default one. But the very strange thing is that the behavior is the same
    > as at the beginnig.
    > The same behaviour can be reproduced starting from V4R4 up to V5R4, so
    > I'm confident that it should not be an OS problem, I pretty sure that's
    > a problem of mine!
    > Could someone explain such figure?
    >
    > --
    > Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    > Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    > Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    > schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'


    I agree, it should work. Try specifying named activation group on the
    srvpgm as well.

    If it still fails, check if you have some uninitialized variables.

    And this may be a superfluous question, but did you sign off and sign
    on after you recreated the service program?


  3. Re: Activation group problem

    Message description is : CEE3101, &1 cannot be called in the default
    activation group.

    That means that you MUST activate your objets in a nammed activation
    group. So your first PGM have to be compiled with a nammed ACTGRP and
    you SRVPGM can stay *CALLER (I prefer a nammed ACTGRP but it's your
    choice)

    It should work.

    Try RCLACTGRP ACTGRP(NAMED_ACTIVATION_GROUP). It works much friendly
    than a sign off.


  4. Re: Activation group problem

    il 22/06/2007 17.07, Scrive Elvis 36721672:
    > On Jun 22, 7:30 am, "Dr.UgoGagliardelli"
    > wrote:
    >> I made an utility with some srvpgm a command and a command processing
    >> program that bind to a srvpgm. For some starnge reason the very first
    >> time the command run, fail with no message, just doesn't do its duty.
    >> All next times I execute the command in the same job, it runs just fine.
    >> Tracing the job I see that when it's time to execunte a certain
    >> procedure, a C function, a CEE3101 massege comes out and the control
    >> return to the main procedure without having done nothing and without any
    >> message. The C function doesn't do anything particular, it just fopen a
    >> stream file, do some calculation fwrite its results an fclose.
    >> Recreating the srvpgm with a named activation group, as suggested by
    >> CEE3101 message, it runs fine even the first time. This way, any global
    >> varaible used by the service program is not the same as the program sees
    >> , so the content is lost.
    >> So I created the program with a named activation group and the service
    >> program with action group *caller. In my opinion both program and the
    >> service program should run in the named activation grout, not the
    >> default one. But the very strange thing is that the behavior is the same
    >> as at the beginnig.
    >> The same behaviour can be reproduced starting from V4R4 up to V5R4, so
    >> I'm confident that it should not be an OS problem, I pretty sure that's
    >> a problem of mine!
    >> Could someone explain such figure?
    >>
    >> --
    >> Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    >> Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    >> Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    >> schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

    >
    > I agree, it should work. Try specifying named activation group on the
    > srvpgm as well.

    I tried:
    pgm -> *CALLER srvpgm -> *CALLER fails
    pgm -> NAMED srvpgm -> *CALLER fails
    pgm -> *CALLER srvpgm ->NAMED not an otpion because of global vars
    pgm -> NAMED srvpgm ->NAMED escape messages sent to the *CTLBDY end the
    job abnormally!

    running under debug it never fails!

    > If it still fails, check if you have some uninitialized variables.
    >
    > And this may be a superfluous question, but did you sign off and sign
    > on after you recreated the service program?
    >

    Sure, to test the error condition I must start a new job, otherwise
    after the 1st time it never fails.

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  5. Re: Activation group problem

    il 22/06/2007 17.16, Scrive jean-laurent.maestre@axon-id.com 36721672:
    > Message description is : CEE3101, &1 cannot be called in the default
    > activation group.
    >
    > That means that you MUST activate your objets in a nammed activation
    > group. So your first PGM have to be compiled with a nammed ACTGRP and
    > you SRVPGM can stay *CALLER (I prefer a nammed ACTGRP but it's your
    > choice)

    I saw it, for that I recreate the program with a named activation group
    and left the service frogram with actgrp(*caller) but do not fix the
    problem. If I do the opposite the problem is fixed but the program loose
    the global variables exported by the service program as their scope is
    at actgroup level.

    >
    > It should work.
    >
    > Try RCLACTGRP ACTGRP(NAMED_ACTIVATION_GROUP). It works much friendly
    > than a sign off.

    The only may I found to reproduce the failing condition is to start a
    new job, rclactgrp *eligible, rclrsc do not clean the job enough to have
    the program fail.

    I cannot see where to go, I started to read "ILE Concetps" over again!
    But I haven't found yet something helpfull.
    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  6. Re: Activation group problem

    il 22/06/2007 19.28, Scrive Dr.UgoGagliardelli 36721672:
    > il 22/06/2007 17.16, Scrive jean-laurent.maestre@axon-id.com 36721672:
    > I cannot see where to go, I started to read "ILE Concetps" over again!
    > But I haven't found yet something helpfull.

    I isolated the failing function in a single service program with named
    activation group and now... it fails as well!

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  7. Re: Activation group problem

    On Jun 22, 1:41 pm, "Dr.UgoGagliardelli"
    wrote:
    > il 22/06/2007 19.28, Scrive Dr.UgoGagliardelli 36721672:> il 22/06/2007 17.16, Scrive jean-laurent.maes...@axon-id.com 36721672:
    > > I cannot see where to go, I started to read "ILE Concetps" over again!
    > > But I haven't found yet something helpfull.

    >
    > I isolated the failing function in a single service program with named
    > activation group and now... it fails as well!
    >
    > --
    > Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    > Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    > Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    > schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'


    I would make sure starting program is not set to *CALLER. That would
    avoid the *DFTACTGRP and the original CEE3101 error no matter what the
    service program is set to (named or *caller).

    Do you get a different error now?
    If so, for me problem was always uninitialized global (a.k.a. static)
    variable. Sounds like you have it localized to a single function so
    it shouldn't be hard to find which one it is.


  8. Re: Activation group problem

    il 22/06/2007 21.38, Scrive Elvis 40354320:
    > On Jun 22, 1:41 pm, "Dr.UgoGagliardelli"
    > wrote:
    >> il 22/06/2007 19.28, Scrive Dr.UgoGagliardelli 36721672:> il 22/06/2007 17.16, Scrive jean-laurent.maes...@axon-id.com 36721672:
    >>> I cannot see where to go, I started to read "ILE Concetps" over again!
    >>> But I haven't found yet something helpfull.

    >> I isolated the failing function in a single service program with named
    >> activation group and now... it fails as well!
    >>
    >> --
    >> Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    >> Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    >> Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    >> schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

    >
    > I would make sure starting program is not set to *CALLER. That would
    > avoid the *DFTACTGRP and the original CEE3101 error no matter what the
    > service program is set to (named or *caller).

    Disregarding *caller or a different value, CEE3101 was simply
    misleading. It seems that is an internal job message that has nothing to
    do with program flow.
    I discovered the real mistake that was obviously (now is obvious!)
    caused by an hill code, there was:
    if ((fd = open(blablabla)) > 0) {
    read...
    close(fd);
    } else {
    ....report errno if > 0
    }
    The first time fd=0, so the file was not closed and errno=0, so no errno
    was reported, the second run fd=1 and the process ran fine,
    Just changing the comparison to >= 0 the problem was solved.
    As I usually code >= 0, to me has been very hard to see. The strange
    thing was that with debug fd is always > 0, maybe debugger opens some
    files itself influencing how program behaved.
    Sorry for the unjustified alarm.
    :-)


    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

+ Reply to Thread