In a message dated 7/14/2005 11:33:27 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Speaking about M$ did you see where they are attempting to get into the
storage business? Talk about scary.
>>
wouldn't be too worried, after they claim the patents on all
known recording techniqu
On Jul 14, 2005, at 9:36 AM, Ed Finnell wrote:
In a message dated 7/13/2005 8:35:44 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Unfortunately, we are!
I though M$ had the patent on this delivery model...
Speaking about M$ did you see where they are attempting to get into
In a message dated 7/13/2005 8:35:44 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
Unfortunately, we are!
>>
I though M$ had the patent on this delivery model...
--
For IBM-MAIN subscribe / signoff / archive a
...
"Holy spaghetti Batman, who's testing these things?"
...
Unfortunately, we are!
-teD
In God we Trust!
All others bring data!
-- W. Edwards Deming
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send emai
> "Holy spaghetti Batman, who's testing these things?"
Probably went to the lowest bidder.
CONFIDENTIALITY NOTICE: This electronic transmission (including any
accompanying attachments) is intended solely for its authorized
recipient(s), and may contain confidential and/or legally privileged
in
In a message dated 7/13/2005 3:41:56 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
the conditions at the 1.4 and 1.5 levels (1G0 and 1H0) and reported on
validity in the opposite way. Good is bad; bad is good. A philosophical and
ethical conundrum if ever there was one. The 1.6 (1J0
SO, Skip, are you saying 1.6 is bad ("good is bad, bad is good") or 1.6
is good? But then, I just used "bad" when I meant "bad" but "bad is good"
so did I mean "good"?
I certainly meant well.
Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209
Please forgive me if this is old news. OA11927 was PE'ed on 7/11 . This is
the guy that set out to 'restore' the bogus stats in LISTCAT so that
programs expecting numeric data would not blow up S0C7; the stats would be
marked invalid in some other field. Unfortunately, OA11927 somehow mixed up
the
In <[EMAIL PROTECTED]>, on 07/08/2005
at 10:37 PM, "Joel C. Ewing" <[EMAIL PROTECTED]> said:
>LISTCAT stats have been around for at least several decades, maybe
>since the beginnings of OS/360.
There was no AMS, LISTCAT or VSAM in OS/36 0. VSAM came in as an ICR
for OS/VS1 and OS/VS2 R1 (SVS
-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
In <[EMAIL PROTECTED]>,
on 07/06/2005
at 10:32 AM, "Farley, Peter x23353" <[EMAIL PROTECTED]> said:
>I never even envisioned automated tools looking at VSAM stats. My
>ASSumption when reading Mark&
Joel,
>
> If those 20 minutes of stats show enough CI splits to justify a
> reorganize of the file, it doesn't matter that this only represents 20
> minutes of activity. If the CI-split count is above your reorg
> threshold, it also doesn't matter if you lost 15 hours of CI-split
> counts becaus
In <[EMAIL PROTECTED]>,
on 07/06/2005
at 10:32 AM, "Farley, Peter x23353" <[EMAIL PROTECTED]> said:
>I never even envisioned automated tools looking at VSAM stats. My
>ASSumption when reading Mark's posts was that he was referring to
>individual programmers looking at individual VSAM file stat
In <[EMAIL PROTECTED]>,
on 07/06/2005
at 05:29 PM, Donald Pagdin <[EMAIL PROTECTED]> said:
>So it is assembler that can bite the unwary yet diligent programmer.
That's the theory, but there seem to be more problems with buffer
overruns in C programs than with other languages, including assembl
In <[EMAIL PROTECTED]>,
on 07/06/2005
at 12:00 AM, Ted MacNEIL <[EMAIL PROTECTED]> said:
>Open/Close processing is not cheap.
>Also, if you have (partial-)release on close, you can easily create a
>multi-(tiny)extent file in no time.
No. TCLOSE is not CLOSE. The data set remains open and there
At 08:22 -0700 on 07/07/2005, Mark Thomen wrote about Re: IBM VSAM
Statistics are often Bogus:
"Robert A. Rosenberg" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> Since CEMT P SHUT I causes a CONTROLLED issuance of an Abnormal
> Terminati
At 06:49 -0500 on 07/07/2005, Chase, John wrote about Re: IBM VSAM
Statistics are often Bogus:
Aren't they the same IBM lab that gave us IGDZILLA?
If there was a IMG prefix, they could do IMGOJIRA ("I'm GOJIRA") -
Gojira being the real name of the Japanese Monster called
Ron and Jenny Hawkins wrote:
Tom, et al,
I was just thinking... CICS aside, when a job ABENDS while updating a KSDS
file, what is the most common thing that happens to allow the job to be
rerun? Delete and restore the KSDS, right? So what good are the accumulated
statistics at this point - valid
On Jul 8, 2005, at 4:04 PM, Bruce Black wrote:
Job is updating the vsam cluster. Job abends.
Job is checkpoint restarted.
job completes (with closes to the dataset in question)
Are the stats now correct?
If by statistics, you mean those things listed under STATISTICS in a
LISTCAT
STATISTI
Job is updating the vsam cluster. Job abends.
Job is checkpoint restarted.
job completes (with closes to the dataset in question)
Are the stats now correct?
If by statistics, you mean those things listed under STATISTICS in a LISTCAT
STATISTICS
Ed asked:
>Which brings up a question (at least in my mind).
>Job is updating the vsam cluster. Job abends.
>Job is checkpoint restarted.
>job completes (with closes to the dataset in question)
>Are the stats now correct?
Since they are unreliable, it does not matter.
CONFIDENTIALITY NOTICE:
On Jul 8, 2005, at 2:42 AM, R.S. wrote:
So, we come into philosofical considerations.
After VSAM restore (bacause of job failure) we have reorganized
cluster. Assumed logical backup/restore.
BTW: We say 'cluster', but the considerations are mostly for KSDS or
vRRDS. There are no splits in ESDS
So, we come into philosofical considerations.
After VSAM restore (bacause of job failure) we have reorganized cluster.
Assumed logical backup/restore.
BTW: We say 'cluster', but the considerations are mostly for KSDS or
vRRDS. There are no splits in ESDS, LDS, or RRDS.
Ab ovo: What stats are fo
Radoslaw,
As far as I recall it uses Export for Catalogs and REPRO for other VSAM.
Ron
>
> Unless it was physical dump. It depends on backup technique and datamover.
> BTW: is it REPRO or EXPORT ?
>
> --
> Radoslaw Skorupka
> Lodz, Poland
>
---
Geez is this thread ever going to die? It has not edged
towards Jaffe's conjecture yet, so it might keep limping
along. Darren could kill it at any second (if we're lucky)
> I do want to thank Mark for his open and
> candid responses, and that he (at least) has tried to do
> something about thi
> You wouldn't want to be doing a large number of TCLOSEs per run... on
>the order of 1's or maybe 10's but not 100's and certainly not 1000's.
>You'll be swatting a gnat with a nuclear device in short order with
>this approach. (These statistics just aren't that important.)
I agree to doing a re
On Thu, 7 Jul 2005 14:30:16 -0500, Martin Kline wrote:
>I believe John suggested using CLOSE TYPE=T to get a user equivalent of
>interval recording. This should update the catalog, and generate a type-64
>SMF record with bit 4 of SMF64RIN set. My question is whether multiple
>such type-64 records
I believe John suggested using CLOSE TYPE=T to get a user equivalent of
interval recording. This should update the catalog, and generate a type-64
SMF record with bit 4 of SMF64RIN set. My question is whether multiple
such
type-64 records have to be manually accumulated. In other words, if I
gene
There is a product from Mainstar Software that we used many years ago
called VSAM Manager.
I checked their web site - www.mainstar.com and it is still listed with
the following description:
VSAM Manager analyzes logical record to CI relationships - checking for
potential efficiency
--SNIP---
If he's talking about VSAMAID from CA, the manual states:
Once installation has been completed, it is necessary to perform a
statistics collection run for the VSAM clusters in batch. Although this
process has been optimized to execute as quickly as possible, the
Tom said:
>I commend Mark for taking the issue in hand and trying to implement a long
>term solution, and for raising it to the level where it is discussed so
>that the appropriate awareness is reached, but Mark doesn't need my
>commendation for job satisfaction.
>
>Say what you want about IBM but
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould
> Sent: Thursday, July 07, 2005 11:36 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
>
>
> Bruce,
>
> Not
On Jul 7, 2005, at 8:39 AM, Bruce Black wrote:
Somewhere in the back of my paged out (permanently?) memory is there
used to be (or there is one currently) a utility that went through
the catalog and looked for vsam datasets and listed any that
according to its recommendation ones that needed
"Robert A. Rosenberg" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> At 07:36 -0500 on 07/06/2005, Chase, John wrote about Re: IBM VSAM
> Statistics are often Bogus:
>
> >The fact remains that CEMT P SHUT I causes an ABNORMAL termination o
UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
>
> ...
> As for Alte-Leipziger I can say "it's not issue for us".
> ...
>
> I couldn't find the meaning of that compound word.
>
-
bject: Re: IBM VSAM Statistics are often Bogus
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould
> Sent: Wednesday, July 06, 2005 9:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
&
Somewhere in the back of my paged out (permanently?) memory is there
used to be (or there is one currently) a utility that went through the
catalog and looked for vsam datasets and listed any that according to
its recommendation ones that needed
re-orging. My mind just can't remember the name.
The programme prefix for dfpSMS is IGD.
Years ago, either the main module or an alias was IGDZILLA.
“I, God-Zilla”.
Still true. Back when SMS was new, the lmod size was about 1M, making
it the largest module in LPA. Today the size is about 2.3M, still the
largest module in LPA by a goodly
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ed Gould
> Sent: Wednesday, July 06, 2005 9:47 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
>
>
>
> Peter,
>
&g
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ron and Jenny Hawkins
>
> Tom, et al,
>
> I was just thinking... CICS aside, when a job ABENDS while
> updating a KSDS file, what is the most common thing that
> happens to allow the job to be rerun? Delete and rest
Ron and Jenny Hawkins wrote:
Radoslaw,
Now there's an interesting point. If I recall correctly a Logical Dataset
Restore uses IDCAMS REPRO under DFDSS, so what you get is a reorged KSDS
with stats that say it isn't.
Unless it was physical dump. It depends on backup technique and datamover.
BT
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Ted MacNEIL
>
> ...
> 1) One can always do one's own interval accounting by opening
> and closing the file periodically.
> ...
>
> I hope you are joking!
That would be somewhat like sending separate 18-wheelers to d
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Edward E. Jaffe
>
> Mark Thomen wrote:
>
> >That's what module IFG0TC0A ("IFG-gotcha") does.
>
> I've always called it "I-F-Gotcha!" or just "I've Gotcha!"
And VSE VSAM gives us IKQVDU (IKQ Voodoo).
-jc-
-
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Bruce Black
>
> >That's what module IFG0TC0A ("IFG-gotcha") does.
> >
> Who said IBM doesn't have a sense of humor? Thanks,Mark,
> that gave me the giggles.
Aren't they the same IBM lab that gave us IGDZILLA?
And
TED] On
> Behalf Of R.S.
> Sent: Thursday, 7 July 2005 6:40 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: FW: IBM VSAM Statistics are often Bogus
>
> Ron,
> Please, correct me if I'm wrong.
> Job fails, so cluster must be deleted and restored from backup. Am I
> rig
Ron,
Please, correct me if I'm wrong.
Job fails, so cluster must be deleted and restored from backup. Am I
right ?
So, IMHO restore also restores VSAM stats, doesn't it ?
I mean restore, not REPRO or IMPORT.
--
Radoslaw Skorupka
Lodz, Poland
Ron and Jenny Hawkins wrote:
Tom, et al,
I was
At 07:36 -0500 on 07/06/2005, Chase, John wrote about Re: IBM VSAM
Statistics are often Bogus:
The fact remains that CEMT P SHUT I causes an ABNORMAL termination of CICS,
as would the MVS CANCEL or FORCE command. The fact also remains that on a
commanded ABNORMAL termination of (anything
On Jul 6, 2005, at 9:48 PM, Ed Finnell wrote:
--SNIP-
I'm decent, but was able to just cut and paste! Then I went and
did a review of the Oracle Grid. Hmmm, wonder how in the world they
stay up forever with no abends and no catalogs??? Hmmm.
Well, I am not a ORACLE fa
Richards.Bob wrote:
... For now, I off to search the Internet for the meaning of "boustrophedon".
Back and forth like an old dot matrix printer.
--
-
| Edward E. Jaffe||
| Mgr,
10:57 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject:Re: IBM VSAM statistics are often bogus
In a message dated 7/6/2005 9:54:54 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
boustrophedon
'Hot air balloon'
In a message dated 7/6/2005 9:54:54 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
boustrophedon
'Hot air balloon'
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] wi
uly 06, 2005 10:47 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM statistics are often bogus
> The penance for both of us is to write "Invalid data is invalid data"
>ten thousand times. Under ISPF EDIT, it should take us roughly ten
>seconds.
A more exiguous
In a message dated 7/6/2005 9:43:31 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
You must be a typist. It took me 7 of the 10 to type the words!
>>
I'm decent, but was able to just cut and paste! Then I went and
did a review of the Oracle Grid. Hmmm, wonder how in the world they
The penance for both of us is to write "Invalid data is invalid data"
ten thousand times. Under ISPF EDIT, it should take us roughly ten
seconds.
A more exiguous penalty is clearly called for.
My preference would be to require you format it in boustrophedon
parametrically in full n-chara
On Jul 6, 2005, at 9:32 AM, Farley, Peter x23353 wrote:
I never even envisioned automated tools looking at VSAM stats. My
ASSumption when reading Mark's posts was that he was referring to
individual
programmers looking at individual VSAM file stats for guidance. My
experience is obviously se
Statistics are often Bogus
In a message dated 7/6/2005 6:52:42 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
The penance for both of us is to write "Invalid data is invalid data" ten
thousand times. Under ISPF EDIT, it should take us roughly ten seconds.
R10 Inval
In a message dated 7/6/2005 6:52:42 P.M. Central Standard Time,
[EMAIL PROTECTED] writes:
The penance for both of us is to write "Invalid data is invalid data" ten
thousand times. Under ISPF EDIT, it should take us roughly ten seconds.
R10 Invalid data is invalid data
rr
rr
3.7
Thursday, 7 July 2005 1:28 AM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
>
> Ok, I'll be the whipping boy.
>
> Why can't the Operating System be "Enhanced" to intercept the Abend and
> close the files.
> Close any input
On Jul 5, 2005, at 7:00 PM, Ted MacNEIL wrote:
...
1) One can always do one's own interval accounting by opening and
closing
the file periodically.
...
I hope you are joking!
Ted,
Along similar lines we had a programmer close and open a vsam dataset
after each search. I agree with you.
Under ISPF EDIT, it should take us roughly ten seconds.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Farley, Peter x23353
Sent: Wednesday, July 06, 2005 10:32 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics
In a message dated 7/6/2005 4:24:41 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>A Devil's Advocate might be tempted to say just because you don't ABEND
>does not mean that
>a user did not overlay or incorrectly modify VSAM control blocks that are
>in user key. How can
>you e
...
As for Alte-Leipziger I can say "it's not issue for us".
...
I couldn't find the meaning of that compound word.
-teD
In God we Trust!
All others bring data!
--Deming
--
For IBM-MAIN subscribe / signoff / archi
Will this thread never end? Mark Thomen explained now several times the why and
the current state of this issue. Please raise requirements if you relay on
those statistics and explain the business case
and also how did you handle this the last nn years in the past. I believe a lot
of customers
...
Why? I've been known to do CLOSE TYPE=T on sequential datasets after
processing "n" records. Of course, IIRC, it was a specialized
application. Lost is the mists of pre-history, now.
...
Open/Close processing is not cheap.
Also, if you have (partial-)release on close, you can easily create a
...
Who said IBM doesn't have a sense of humor? Thanks,Mark, that gave me
the giggles.
...
I verified this one years ago.
I don't know if it's still true.
The programme prefix for dfpSMS is IGD.
Years ago, either the main module or an alias was IGDZILLA.
“I, God-Zilla”.
(8-{]}
-teD
In Go
>A Devil's Advocate might be tempted to say just because you don't ABEND does
>not mean that a user did not overlay or incorrectly modify VSAM control
>blocks that are in user key. How can you ever trust the stats?
>Bill Fairchild
Note:
CICS, recovering an application abend (via DTB) does not ha
Bill Fairchild writes:
A Devil's Advocate might be tempted to say just because you don't ABEND
does not mean that
a user did not overlay or incorrectly modify VSAM control blocks that are
in user key. How can
you ever trust the stats?
and there is of course a sense in which his argument is
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL
> Sent: Tuesday, July 05, 2005 7:00 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: IBM VSAM Statistics are often Bogus
>
>
> ...
> 1) One ca
...
1) One can always do one's own interval accounting by opening and closing
the file periodically.
...
I hope you are joking!
-teD
In God we Trust!
All others bring data!
--Deming
--
For IBM-MAIN subscribe / s
Mark Thomen wrote:
That's what module IFG0TC0A ("IFG-gotcha") does.
I've always called it "I-F-Gotcha!" or just "I've Gotcha!"
--
-
| Edward E. Jaffe||
| Mgr, Research & Developmen
That's what module IFG0TC0A ("IFG-gotcha") does.
Who said IBM doesn't have a sense of humor? Thanks,Mark, that gave me
the giggles.
--
Bruce A. Black
Senior Software Developer for FDR
Innovation Data Processing 973-890-7300
personal: [EMAIL PROTECTED]
sales info: [EMAIL PROTECTED]
tech sup
In a message dated 7/6/2005 2:51:54 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
Most of the VSAM control blocks are in user key. If these have been
overlaid or incorrectly modified, writing this data to the catalog may
BREAK THE DATA SET. The effects of breaking the data set are
<[EMAIL PROTECTED]> wrote in message
news:...
> Ok, I'll be the whipping boy.
>
> Why can't the Operating System be "Enhanced" to intercept the Abend and
> close the files.
That's what module IFG0TC0A ("IFG-gotcha") does.It is an exit invoked
by task termination to process open files. However
In a message dated 7/6/2005 12:56:40 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
It doesn't take a weatherman to know
>which the wind is blowing.
...which WAY the wind is blowing. (Unless you were trying to imply
no 'way' in your original sentence?)
If we are going to quibbl
On Wed, 6 Jul 2005 13:23:13 -0400, Kirk Talman wrote:
>7/6/2005 11:32 AM Tom Schmidt wrote
>>There is a more fundamental issue here: VSAM keeps its statistics records
>>in KEY 8 storage in the address space's private area, ... Those
>>statistics records can, and often are in the case of a storage
Ok, I'll be the whipping boy.
Why can't the Operating System be "Enhanced" to intercept the Abend and
close the files.
Close any input file and/or VSAM file. There is already alot of processing
that occurs after
the abend by building the dump thru Abend-Aid and other debuggers. We
already have C
7/6/2005 11:32 AM Tom Schmidt <[EMAIL PROTECTED]> wrote
There is a more fundamental issue here: VSAM keeps its statistics records
in KEY 8 storage in the address space's private area, ... Those
statistics
records can, and often are in the case of a storage overlay, subject to
corruption and/or de
- Original Message -
From: "Mark Thomen" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
Sent: Wednesday, July 06, 2005 11:26 AM
Subject: Re: IBM VSAM Statistics are often Bogus
Had I worked in VSAM for 30+ years I'd have made this change a long time
ago
You want "good" stats to base things such as REORGs on? Go to DB2. And
pay for it.
Only in FOSS will you get something for "free" (either Libre or Gratis).
And, in FOSS, if you don't like it, you can "fix" it yourself. If you
don't have the talent to "fix" it yourself, then either: (1) nicely ask
In a message dated 7/6/2005 10:26:57 A.M. Central Standard Time,
[EMAIL PROTECTED] writes:
invalid data? If your checking statement said you had $3,127.47 but next
to it in parentheses it said "(but this amount is invalid)", would you go
out and try to spend the money? No, I think you'd b
On Wed, 6 Jul 2005 06:57:38 EDT, Bill Fairchild wrote:
>
>In a message dated 7/6/2005 5:22:42 A.M. Central Daylight Time,
>Bob Richards writes:
>
>> In the case of an ABEND or CICS "close immediate" situation, what
>information would you like Mark to write to the file? And where is this
>>informati
"Dave Juraschek" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> I guess what really peeves me is not that the stats are invalid -
although
> that is certainly disturbing to say the least.
> That is clear (to me now).
>
> What really is unconscionable is Mark's admission that IBM
"Dave Juraschek" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> > ... CICS "close immediate" situation
>
> This really is a red herring.
>
> The CICS CEMT PERFORM SHUT IMMEDIATE is completely IBM code. This is an
> example of where this is absolutely not a user/application/cust
See my earlier reply to Mr. Richards for the ASSumptions behind that
statement.
Peter
-Original Message-
From: Ted MacNEIL [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 6:14 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
...
Just because they are
ssage-
From: Richards.Bob [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 6:32 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
Your paragraph:
"Just because they are not written when something BAD happens is NOT a
reason to see them as invalid or use
> -Original Message-
> From: IBM Mainframe Discussion List On Behalf Of Dave Juraschek
>
> > ... CICS "close immediate" situation
>
> This really is a red herring.
More than a few shops use CEMT P SHUT I as their "normal" means of
terminating CICS, despite the warnings in the CICS docume
> ... CICS "close immediate" situation
This really is a red herring.
The CICS CEMT PERFORM SHUT IMMEDIATE is completely IBM code. This is an
example of where this is absolutely not a user/application/customer problem.
If it is violating some IBM VSAM file rule, it's still an IBM problem and
one
portant to him.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Bill Fairchild
Sent: Wednesday, July 06, 2005 6:58 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
In a message dated 7/6/20
In a message dated 7/6/2005 5:22:42 A.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
> In the case of an ABEND or CICS "close immediate" situation, what
information would you like Mark to write to the file? And where is this
information
supposed to come from?
I think you are assu
In a message dated 7/5/2005 10:04:27 P.M. Central Daylight Time,
[EMAIL PROTECTED] writes:
>BTW.
>My set of initials was:
>BTDT. DLI. DWTDIA!
>Been there, done that.
>Didn't like it.
>Don't want to do it again!
Thanks for explaining your abbreviations, initials, acridnyms.
IPTSWOC
-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
I guess what really peeves me is not that the stats are invalid - although
that is certainly disturbing to say the least.
That is clear (to me now).
What really is unconscionable is Mark's admission that IBM has known
I guess what really peeves me is not that the stats are invalid - although
that is certainly disturbing to say the least.
That is clear (to me now).
What really is unconscionable is Mark's admission that IBM has known this
for 30+ years and has not cared or bothered to fix it yet. Mark's response
On Jul 4, 2005, at 7:00 PM, Ted MacNEIL wrote:
-SNIP--
In God we Trust!
All others bring data!
--Deming
And don't trust VSAM stats either:-)
Ed
--
For IBM-MAIN subscribe / signoff / archive
...
Straight face? Heck, how about a clean conscience?
...
I have been burned too many times making decisions/recommendations
based on valid data.
Invalid data? ... don't think so!
BTW.
My set of initials was:
BTDT. DLI. DWTDIA!
Been there, done that.
Didn't like it.
Don't want to do it a
face? Heck, how about a clean conscience?
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Ted MacNEIL
Sent: Monday, July 04, 2005 8:00 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
...
Just be
e it my $.04 cents.
Bob
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Farley, Peter x23353
Sent: Tuesday, July 05, 2005 5:52 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
PMFJI here, but I cannot hold my (v
...
Just because they are not written when something BAD happens is NOT a reason
to see them as invalid or useless.
...
I don't get it!
Invalid data is invalid data!
We make enough bad decisions with valid data.
How can you say that with a straight face?
-teD
In God we Trust!
All others bring
om: Mark Thomen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 05, 2005 5:41 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IBM VSAM Statistics are often Bogus
"Joel C. Ewing" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> I strongly disagree on the desirabili
...
> This also suggests that calling the statistics "INVALID" may be too
> strong a pejorative, as all the counts reflect actual activity to the
> file - it's just that they do not represent ALL the activity to the
file.
I'm afraid I don't understand how this doesn't make the results "invalid".
"Joel C. Ewing" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> I strongly disagree on the desirability of suppressing VSAM statistics
> in these cases. It would be much better to display them while
> indicating that they are incomplete.
>
> The delta in the LISTCAT VSAM statist
o
see how it would be useful whether the statistics were in error or not.
Ron
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
> Behalf Of Joel C. Ewing
> Sent: Saturday, 2 July 2005 3:50 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re:
1 - 100 of 120 matches
Mail list logo
