Barbara Nitz wrote on 09/27/2005 01:05:50 AM:
Several comments on this:
First to Bob - thanks for the explanation. That explains why I get three
responses when I ask ip w for the cvtexit address. (Or why IPCS tells me
that an ASCB address is an ASCB.)
Shane, I don't think that IBM is
In [EMAIL PROTECTED], on 09/27/2005
at 07:05 AM, Barbara Nitz [EMAIL PROTECTED] said:
Greg, in this case I believe that just about everyone using GFS
traces would be greatful for an incomplete solution. If the amount of
data could get reduced to the non-trivial cases that you mentioned
above,
Go through a SYSTRACE and parse out the trace entries of interest,
then do IP WHERES on the PSW addresses to get the displacements in the
modules. Generate side by side listing of trace entry, psw address, r15,
r0, r1 and the module name and displacement.
That is one thing I had written a verbx
Barbara Nitz wrote on 09/26/2005 07:13:24 AM:
Some have suggested that we add an option to WHERE,
filtering based on data type. The most common filter that has been
proposed is a MODULE data type filter. It would be interesting to hear
opinions on this suggestion from regular IBM-MAIN
From: Robert Wright
...
As you and others have described what you'd like SYSTRACE to do, SYSTRACE
would use module filtering in its calls to the WHERE service routine
because it would want answers pertaining to modules and would not be
interested in answers pertaining to AREAs or STRUCTUREs.
Shane wrote on 09/26/2005 08:39:00 AM:
Now Bob, about some decent IPCS support for those GFS traces ...
Other than generic support in service aids components, I think that all GFS
trace data collection and formatting support is shipped via the VSM
component. Did you have something in mind that
From: Robert Wright
Other than generic support in service aids components, I think that all
GFS
trace data collection and formatting support is shipped via the VSM
component. Did you have something in mind that the service aids
components
could do to support such things better? Or do you
The formatting is excellent - the filtering is non-existent.
As I alluded earlier, the prime (extra) functionality I see as required
in
the field is the ability to identify storage leaks. An option to
eliminate all matched get-free pairs would go a *LONG* way to achieving
this goal.
I
On Mon, 26 Sep 2005 19:59:17 -0700, Greg Dyck wrote:
I believe IBM research[ed] has dabbled with this, but it is a non-trivial
task to do by IBM or by others. Some of the complications that
immediately come to mind are being able to free 8 byte multiple of
storage at a time independent of the
Several comments on this:
First to Bob - thanks for the explanation. That explains why I get three
responses when I ask ip w for the cvtexit address. (Or why IPCS tells me
that an ASCB address is an ASCB.)
Shane, I don't think that IBM is implementing this yet, it was just a
request and Bob
In
[EMAIL PROTECTED],
on 09/23/2005
at 10:49 AM, Robert Wright [EMAIL PROTECTED] said:
You're one level of service off.
Not really; my statement as written (If ...) is valid for both old
and new service levels. BTW, you might want to provide the PTF numbers
for those who are backlevel.
IPCS
Shmuel (Seymour J.) Metz wrote on 09/22/2005 01:58:42 PM:
If WHERE uses TPUT directly then you can still capture the output if
you run under Session Manager. You'll need a special logon proc.
Apologies for not being clearer in my previous response. I should not have
used level and service
Shmuel (Seymour J.) Metz wrote on 09/22/2005 01:58:42 PM:
If WHERE uses TPUT directly then you can still capture the output if
you run under Session Manager. You'll need a special logon proc.
You're one level of service off. WHERE and the rest of line mode IPCS use
TSO I/O service routines
In
[EMAIL PROTECTED],
on 09/21/2005
at 05:08 AM, Kenneth J. Kripke [EMAIL PROTECTED] said:
Apologies on the previous two incomplete posts.
Question: Is there a way to capture the results of an IP WHERE from a
REXX EXEC running under IPCS and store it in a REXX variable?
I don't think the
Question: Trapping/capturing output from an IPCS WHERE command.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
The Question: Is there a clean way to capture the results from an IP WHERE
command.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search
In article [EMAIL PROTECTED] you wrote:
The Question: Is there a clean way to capture the results from an IP WHERE
command.
Just add 'print' to the command to have it go to the file allocated to
IPCSPRNT. If you don't want to see the output on your terminal, add 'noterm'.
ip w x print noterm
Apologies on the previous two incomplete posts.
Question: Is there a way to capture the results of an IP WHERE from a REXX EXEC
running under IPCS and store it in a REXX variable?
I don't think the command uses PUTLINE to put the message out, but, I could be
wrong.
The Goal: Go through a SYSTRACE
On Wed, 21 Sep 2005 04:15:07 -0700 Kenneth J. Kripke
[EMAIL PROTECTED] wrote:
:The Question: Is there a clean way to capture the results from an IP WHERE
command.
Look at the EVAL* subcommands.
--
Binyamin Dissen [EMAIL PROTECTED]
http://www.dissensoftware.com
Director, Dissen Software, Bar
Kenneth J. Kripke wrote on 09/21/2005 07:15:07 AM:
The Question: Is there a clean way to capture the results from an
IP WHERE command.
The WHERE subcommand, like many IPCS subcommands uses symbol X as well as
its return code to make its results available to a command procedure.
There is a
Kenneth J. Kripke wrote on 09/21/2005 06:56:49 AM:
Question: Trapping/capturing output from an IPCS WHERE command.
Answer: (Ugly) SYSOUTTRAP in CLIST and REXX work fine in batch and
interactive line mode. Unfortunately, most IPCS use takes place from the
IPCS dialog, and the trapping of
Kenneth J. Kripke wrote on 09/21/2005 08:08:40 AM:
Question: Is there a way to capture the results of an IP WHERE from
a REXX EXEC
running under IPCS and store it in a REXX variable?
I don't think the command uses PUTLINE to put the message out, but, I
could be
wrong.
The Goal: Go through a
Binyamin Dissen wrote on 09/21/2005 08:34:56 AM:
On Wed, 21 Sep 2005 04:15:07 -0700 Kenneth J. Kripke
[EMAIL PROTECTED] wrote:
:The Question: Is there a clean way to capture the results from an
IP WHERE command.
Look at the EVAL* subcommands.
In the case of the WHERE subcommand, look at
Generally IPCS is a fine tool - but there are situations where it just
ain't shaped to fit.
UGLY - I'll tell you ugly.
Try parsing a (large) GFS trace for non-matching get/frees - from TCBs that
had a life not much longer than the duration of the obtained storage.
You might be surprised how often
24 matches
Mail list logo
