On Nov 14, 12:59 pm, bine <sabine.hubrig-schaumb...@sungard.de> wrote:
> On 14 Nov., 18:33, jprob...@gmail.com wrote:
>
>
>
>
>
> > On Nov 13, 6:35 pm, Hajo Ehlers <serv...@metamodul.com> wrote:
>
> > > ...
>
> > > > any ideas?
>
> > > try increasing ncargs and see if it fixes the problem. On each
> > > subshell the parent environment is given plus the additional new
> > > setting which might cause the subshell to run out of ENV memory.
>
> > > from IBM
> > > ...
> > > ncargs
> > > Purpose: Specifies the maximum allowable size of the ARG/ENV list (in
> > > 4 KB blocks) when running exec() subroutines.
> > > Values: Default: 6; Range: 6 to 1024
> > > Display: lsattr -E -l sys0 -a ncargs
> > > Change: chdev -l sys0 -a ncargs=NewValue Change takes effect
> > > immediately and is preserved over boot.
> > > ....
>
> > > To determine the correct OS level run:
> > > $ oslevel -s
>
> > > hth
> > > Hajo
>
> > Since you are nesting so deep, you may want to also check the number
> > of open files allowed for the user ID under which the application
> > runs. If you hit the limit, that can give unpredictable results.
>
> > J.- Zitierten Text ausblenden -
>
> > - Zitierten Text anzeigen -
>
> thanks J.
> do you have a hint as to how to detemine this value on commandline?
> I tried smit, the submenu of "Change / Show Characteristics of a
> User", but for my own user there weren't many values filled in so I
> seem to get everything from defaults.
> which file would that be anyway?
> e.g. "maximum processes per uid" might be CHILD_MAX in /usr/include/
> sys/limits.h and there is some OPEN_MAX as well but that's not per
> user but per process, according to the comment, so that might be a
> wrong source.
>
> so if it's configured userdependent, what do I tell my customer to
> call, to give me the information?
> thanks in advance
> bine- Hide quoted text -
>
> - Show quoted text -



You need to have the customer tell you what user the application runs
under. You can either look in /etc/security/limits or log in as the
application user and run ulimit -a to determine the settings.

Here is the brief description of the various settings (straight from
the comment block in /etc/security/limits):

* fsize - soft file size in blocks
* core - soft core file size in blocks
* cpu - soft per process CPU time limit in seconds
* data - soft data segment size in blocks
* stack - soft stack segment size in blocks
* rss - soft real memory usage in blocks
* nofiles - soft file descriptor limit
* fsize_hard - hard file size in blocks
* core_hard - hard core file size in blocks
* cpu_hard - hard per process CPU time limit in seconds
* data_hard - hard data segment size in blocks
* stack_hard - hard stack segment size in blocks
* rss_hard - hard real memory usage in blocks
* nofiles_hard - hard file descriptor limit
* The following table contains the default hard values if the
* hard values are not explicitly defined:
*
* Attribute Value
* ========== ============
* fsize_hard set to fsize
* cpu_hard set to cpu
* core_hard -1
* data_hard -1
* stack_hard -1
* rss_hard -1
* nofiles_hard -1
*
* NOTE: A value of -1 implies "unlimited"



J.

On 14 Nov., 21:10, jprob...@gmail.com wrote:
> On Nov 14, 12:59 pm, bine <sabine.hubrig-schaumb...@sungard.de> wrote:
>
>
>
>
>
> > On 14 Nov., 18:33, jprob...@gmail.com wrote:
>
> > > On Nov 13, 6:35 pm, Hajo Ehlers <serv...@metamodul.com> wrote:
>
> > > > ...
>
> > > > > any ideas?
>
> > > > try increasing ncargs and see if it fixes the problem. On each
> > > > subshell the parent environment is given plus the additional new
> > > > setting which might cause the subshell to run out of ENV memory.
>
> > > > from IBM
> > > > ...
> > > > ncargs
> > > > Purpose: Specifies the maximum allowable size of the ARG/ENV list (in
> > > > 4 KB blocks) when running exec() subroutines.
> > > > Values: Default: 6; Range: 6 to 1024
> > > > Display: lsattr -E -l sys0 -a ncargs
> > > > Change: chdev -l sys0 -a ncargs=NewValue Change takes effect
> > > > immediately and is preserved over boot.
> > > > ....
>
> > > > To determine the correct OS level run:
> > > > $ oslevel -s
>
> > > > hth
> > > > Hajo
>
> > > Since you are nesting so deep, you may want to also check the number
> > > of open files allowed for the user ID under which the application
> > > runs. If you hit the limit, that can give unpredictable results.
>
> > > J.- Zitierten Text ausblenden -
>
> > > - Zitierten Text anzeigen -
>
> > thanks J.
> > do you have a hint as to how to detemine this value on commandline?
> > I tried smit, the submenu of "Change / Show Characteristics of a
> > User", but for my own user there weren't many values filled in so I
> > seem to get everything from defaults.
> > which file would that be anyway?
> > e.g. "maximum processes per uid" might be CHILD_MAX in /usr/include/
> > sys/limits.h and there is some OPEN_MAX as well but that's not per
> > user but per process, according to the comment, so that might be a
> > wrong source.
>
> > so if it's configured userdependent, what do I tell my customer to
> > call, to give me the information?
> > thanks in advance
> > bine- Hide quoted text -
>
> > - Show quoted text -
>
> You need to have the customer tell you what user the application runs
> under. You can either look in /etc/security/limits or log in as the
> application user and run ulimit -a to determine the settings.
>
> Here is the brief description of the various settings (straight from
> the comment block in /etc/security/limits):
>
> * fsize - soft file size in blocks
> * core - soft core file size in blocks
> * cpu - soft per process CPU time limit in seconds
> * data - soft data segment size in blocks
> * stack - soft stack segment size in blocks
> * rss - soft real memory usage in blocks
> * nofiles - soft file descriptor limit
> * fsize_hard - hard file size in blocks
> * core_hard - hard core file size in blocks
> * cpu_hard - hard per process CPU time limit in seconds
> * data_hard - hard data segment size in blocks
> * stack_hard - hard stack segment size in blocks
> * rss_hard - hard real memory usage in blocks
> * nofiles_hard - hard file descriptor limit
> * The following table contains the default hard values if the
> * hard values are not explicitly defined:
> *
> * Attribute Value
> * ========== ============
> * fsize_hard set to fsize
> * cpu_hard set to cpu
> * core_hard -1
> * data_hard -1
> * stack_hard -1
> * rss_hard -1
> * nofiles_hard -1
> *
> * NOTE: A value of -1 implies "unlimited"
>
> J.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

thanks J.
I don't have access to /etc/security and below,
"ulimit -a" tells me (on my machine) some different parameters
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000
but as nofiles is among them I'll ask the customer to run that on his
machine with his user as well

On 8 Nov., 21:03, bine <sabine.hubrig-schaumb...@sungard.de> wrote:
> I have a very alarming (not to say "shocking!") behaviour on a
> customer's AIX (5.3-64 bit, the exact bos I haven't determined yet)
> that a ksh-script called from a deeper level (of shell-script-calls)
> inside of our Application fails to handle errorelvels correctly, in 2
> different constructs, that is: receving the value of a return from a
> function wrongly and later getting the wrong errorlevel after the exit
> of a subshell, whereas the same script called directly from
> commandline behaves perfect.

update for those that are still interested to what it might lead
to ...

1) setting ncargs from default 6 to 20 didn't help

2) ulimit -a giving
ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000
is the same as on our AIX5.3 and the customer's older AIX5.2 where the
wrong errorhandlings don't occur.
the nofiles to me seems big enough because we don't handle a lot of
files anymore (having the data in a database) except those few
batchscripts AND we work with lesser values on SuSE9 for example
without problems.

3) calling a standardprogram from within our application instead of
their (legal, but still uncommon) customerspecial script works
perfectly well (which leads in the direction that there MUST be
somthing wrong with their script which isn't that obvious)

4) eliminating the cobol-demon and calling their script using an new
fake intermediate skript instead did also work well (which again leads
to the assumption that their script isn't THAT bad in the end),
but still: we only do 'CALL "SYSTEM" USING ...' for that purpose
inside of the cobol and that for years now and I really fear to blame
MicroFocus for that, only so far as this cob-process of course might
require more memory and ressources than my simple faked-skript-demon

which leads to the question:

is there a chance to monitor ressources (best without root to test for
me here, but if root is needed give it to me anyway, as the customer
is more priviledged ;-)
while running our tests to see which ressource might run out without
really giving a sign/message/errorlevel but just failing in correct
return/exit-errorlevelhandling?

what's worrying me most (besides that the application doesn't work) is
that I don't see any hint as to where an error occurs (only when
debugging I see the incorrect results in $?). I just get
"unpredictable results" which in my opinion is a very bad thing for a
runtimesystem. I'd prefer to have stderr-messages and/or errorlevels
because of the problems which I might interpret to find my (or the
customer's) faults, really!

thanks for your patience again,
and have a nice weekend,
bine