Sorry for not coming back earlier - a minor panic at this end took precedence…
Elardus: "...despite all the tuning and resizing attempts, it was... " Precisely so. No matter what I did at the global level, the developer was overriding with his own specification. He had completely missed the significance of the string '768M' in his command, and I had not been party to actually running the test. In the event, the developer sent me a screen shot that showed both the REXXSTOR output *and* the command text. One look from my 'different set of eyes' was enough to crack the problem. Seymour: I've often considered the idea of a simple cardboard cut-out of a figure - not necessarily human! - mounted on a spring such that it appears to nod or shake it's head as it bounces. Place this 'device' on your desk beside you as you perform a personalised 'walk-through' of your problem program, and I'm fairly certain that the time taken for problem determination and source identification would be at least halved... One day I'll get around to making such a thing. Regards Sean On Mon, 26 Nov 2018 at 19:21, Seymour J Metz <[email protected]> wrote: > 1. A different set of eyes is always an asset > > 2. Sometimes when I explain a problem to a different set of eyes I see > the solution myself; > there seems to be a psychological difference between explaining > something and analyzing it > > 3. If you can reproduce the problem, that helps; if you can reproduce it > with instrumentation > turned on, you're hallway to a solution. > > 4. Check your assumptions, especially about version control. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > ________________________________________ > From: IBM Mainframe Discussion List <[email protected]> on behalf > of Sean Gleann <[email protected]> > Sent: Monday, November 26, 2018 6:14 AM > To: [email protected] > Subject: Re: Region size for OMVS tasks > > 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 <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
