W dniu 2010-04-12 22:45, Ted MacNEIL pisze:
And, many disciplines, such as capacity planning.
Example: type 30, type 110 do not have serial numbers, LPAR names, etc.
Type 72, 74, etc don't have them either.
So what? I don't see any relationship to 110 or 30.
Then obviously you've never done
Then obviously you've never done Capacity Planning, Performance Management
or Chargeback.
Very far-fetched opinion, unjustified. To clarify: I don't see any
relationship to SCRT.
My point was there are many records that are dependent on independent SMFIDs.
I was giving examples and you said
W dniu 2010-04-13 11:05, Ted MacNEIL pisze:
But, back to my original point.
There are many reasons for unique SMFIDs, so why is SCRT an issue?
No. There are many reasons where unique SMF ID would be advantage, but
it's still not necessary. Convenient, not required.
You have to do it anyways,
No. There are many reasons where unique SMF ID would be advantage, but it's
still not necessary.
Even one is enough.
Once you have a single valid reason, all else pales in comparison.
Convenient, not required.
I disagree.
There are many 'required'.
And, one is enough.
Convenience is in the eye
Has anyone else downloaded the new version (18.2) and tested it yet?
I am getting errors and am wondering if anyone else is too. Maybe I got a bad
download from the net or a corrupted upload to my mainframe. Errors are below:
IEW2307E 1113 CURRENT INPUT MODULE NOT INCLUDED BECAUSE OF INVALID
It worked fine for me.
Gadi
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Richards, Robert B.
Sent: Monday, April 12, 2010 2:58 PM
To: IBM-MAIN@bama.ua.edu
Subject: Speaking of SCRT
Has anyone else downloaded the new version (18.2
Maybe I got a bad download from the net or a corrupted upload to my mainframe.
If you think that's the case, did you try retrieving a fresh copy?
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive
Not yet, but since Gadi replied with a good report, I'll grab it again.
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Ted MacNEIL
Sent: Monday, April 12, 2010 8:18 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Speaking of SCRT
Maybe I got
Okay, problem must be on my end then. I'll download/upload it again. Thanks!
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
gad...@malam.com
Sent: Monday, April 12, 2010 8:08 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Speaking of SCRT
[mailto:ibm-m...@bama.ua.edu] On Behalf Of
Richards, Robert B.
Sent: Monday, April 12, 2010 7:58 AM
To: IBM-MAIN@bama.ua.edu
Subject: Speaking of SCRT
Has anyone else downloaded the new version (18.2) and tested it yet?
I am getting errors and am wondering if anyone else is too. Maybe I got a bad
.
Bob
-Original Message-
From: Richards, Robert B.
Sent: Monday, April 12, 2010 8:51 AM
To: 'IBM Mainframe Discussion List'
Subject: RE: Speaking of SCRT
Still getting errors.
I am connected remotely today, coming in through PCOM and using IND$FILE with
Binary. Normally, I use HOD and FTP
On Mon, 12 Apr 2010 11:35:37 -0400, Richards, Robert B. wrote:
Somehow, the member I was copying into had gotten switched from CAPS OFF to
CAPS ON.
It's a good idea to use mixed case in one's comments, so if CAPS ON
corrupts your file, the change is visibly apparent.
I suspect Shane will
: Speaking of SCRT
On Mon, 12 Apr 2010 11:35:37 -0400, Richards, Robert B. wrote:
Somehow, the member I was copying into had gotten switched from CAPS OFF to
CAPS ON.
It's a good idea to use mixed case in one's comments, so if CAPS ON
corrupts your file, the change is visibly apparent.
I suspect
My €0.02:
1. I *hate* CAPS ON, especially automatic switch when lowercase
character is found (although this is NOT the case). I wish I would have
option for CAPS in profile.
2. Method of SCRT delivery is error prone. IMHO it would be better at
least to supply it as PDS, so the code would be in
4. (unrelated to original problem, but related to SCRT). IMO requirement for
unique SMF ID is silly and technically unfounded.
I disagree.
I've always had unique SMF id's, long before SCRT came out.
As a Capacity Analyst, it's the simplest way to identify systems uniquely.
So, I don't find
W dniu 2010-04-12 20:49, Ted MacNEIL pisze:
4. (unrelated to original problem, but related to SCRT). IMO requirement for
unique SMF ID is silly and technically unfounded.
I disagree.
I've always had unique SMF id's, long before SCRT came out.
As a Capacity Analyst, it's the simplest way to
No. The simplest way is to use identifier which is always unique, i.e.
LPARname optionally qualified with CPC serial.
None of those are in the type 89, iirc.
The only guarantee is the SMFID, which is in the common header section for all
SMF records, identifying which system cut the record.
W dniu 2010-04-12 21:22, Ted MacNEIL pisze:
No. The simplest way is to use identifier which is always unique, i.e. LPARname
optionally qualified with CPC serial.
None of those are in the type 89, iirc.
Bad assumption. See documentation. Last, but not least: I see nothing
wrong in CHANGE. It
And, many disciplines, such as capacity planning.
Example: type 30, type 110 do not have serial numbers, LPAR names, etc.
Type 72, 74, etc don't have them either.
So what? I don't see any relationship to 110 or 30.
Then obviously you've never done Capacity Planning, Performance Management or
19 matches
Mail list logo
