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?

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.

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'

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'

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'

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.

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'