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
>
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 i
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 allude
> > 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
>
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
> 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
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 y
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 th
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 STRUCT
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-MAI
>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 verb
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 "ser
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.
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 routin
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
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
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 subcomm
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 thro
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 ter
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 di
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
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 a
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 not
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 th
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 http://
25 matches
Mail list logo
