Hello Peter Problem solved! Your idea(s) regarding the SMF30 record analysis eventually led me to reproducing the test environment used by the developer so that I could run the tests myself. One look at the command being used showed what the problem was - there was a parametrised upper limit of 768M on the memory to be used. The developer had completely missed this information. Bumping the parm value to 1G was enough to get the test through, but I'm still arguing for all such limits to be removed - "let the system sort itself out, don't try and 'second guess' things..."
Such a simple thing, spotted by a different set of eyes being used, but that's frequently the root cause in problems such as this, I find. Also, your comment about chopping columns off the REXXSTOR output showed that I was using an old version of Mark's work. That has been addressed. Thank you very much for all your efforts and input on this. I really appreciate it. Regards Sean On Fri, 23 Nov 2018 at 06:35, Peter Hunkeler <p...@gmx.ch> wrote: > > > One more thought: Look At he SMF30 records for one such session. You > should get an idea of what‘s going on in that process and its child > processes. There will be one record for each command, i.e. when a fork()ed > or spawd()ed process ends, and at each exec(). You may find the one program > eating up all that storage. > > > — > Peter Hunkeler > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
