Hi,
Sorry I didn't see this sooner, I was at a client site, who strangely
enough, was also converting from 1.7 to 1.11. I don't normally have (or
want) to go to a site to do the upgrade, but in this case there were some
extenuating circumstances that made it logical to be there in person. The
G'Day All Readers,
I am trying to find the job name which created a VSAM dsn. I read type 61, 62
64 and came up empty. The DSN was created on May 20, 2010. I have read the
SMF tapes for the whole week and I didn't find anything. Is there some other
SMF type record I should read?
Thanks
On Mon, 14 Jun 2010 07:52:57 -0700, John Dawes
jhn_da...@yahoo.com.au wrote:
G'Day All Readers,
I am trying to find the job name which created a VSAM dsn. I read type 61,
62 64 and came up empty. The DSN was created on May 20, 2010. I have
read the SMF tapes for the whole week and I
I would have thought that you'd find it with SMF61 but if not did you try
to see if it was a rename, ie SMF66. Other option would be to check the
VVDS update, SMF60
HTH
Jack Kelly
202-502-2390 (Office)
From:
John Dawes jhn_da...@yahoo.com.au
To:
IBM-MAIN@bama.ua.edu
Date:
06/14/2010 10:54
In a message dated 6/14/2010 10:02:08 A.M. Central Daylight Time,
ptl...@midamerican.com writes:
John, give types 63 69 a try as well.
Micheal Cleary's DAF pgm is built for this. Name and SMF should filter it
all out. If it's a broad range might want to filter VSAM and RACF first
then
Eureke, record type 63 found it, Thanks to all who helped.
--- On Tue, 15/6/10, Patrick Lyon ptl...@midamerican.com wrote:
From: Patrick Lyon ptl...@midamerican.com
Subject: Re: SMF QUESTION - TRACKING VSAM CLUSTER
To: IBM-MAIN@bama.ua.edu
Received: Tuesday, 15 June, 2010, 1:01 AM
On Mon, 14
Type 63? Have I stepped through a time warp this morning? I thought VSAM
catalogs were obsolete years ago.
David Elliot
zSeries Software Support
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
John Dawes
Sent: Monday, June 14, 2010
Edward Jaffe wrote:
I can't for the life of me explain why this is not HIPER, but if you
use PDSEs in your shop I highly recommend APAR OA30338.
FYI. This APAR has now been marked HIPER DATALOSS.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA
I prefer to have the ISV datasets in LINKLST statements in PROGxx
cataloged in the master catalog and not use volume references.
My co-worker doesn't think it as a big deal and usually uses a load
library cataloged in the ISV usercat and a volume reference.
Am I just being anal (I really don't
We have our CICS, DB2 and IMS system datasets residing on Non-SMS volumes
that are not cataloged in the master catalog. The datasets are shared among
fourteen (14) LPARs without any problems. We are an ISV.
On Mon, Jun 14, 2010 at 12:13 PM, Gibney, Dave gib...@wsu.edu wrote:
I prefer to have
Just to be clear, I know that either technique works perfectly well. I
am asking if there is any real argument that one or the other is
superior in anyway.
Like I said, I might just be excessively anal about the issue. I find
volume references (parm, JCL, etc.), anywhere there is a choice not to
Hi Dave,
I am an old dinosaur and, like you, prefer to isolate non-CPAC datasets in a
separate user catalog. Once upon a time, I used different HLQs to permit me to
do this AND list LNKLST / LPALST datasets is PARMLIB without a volume
reference. Example:
SYSV.** for all ISV datasets except
Like I said, I might just be excessively anal about the issue. I find volume
references (parm, JCL, etc.), anywhere there is a choice not to
use them, irritating.
If you're anal, then so am I.
I prefer things to be found through the catalogue, rather than having to
remember, and maintain, where
Either way works.
It's more about what you are comfortable with (even if you are
OCD/anal).
I always felt the trick was to pick one and stick with it and not mix
the two.
Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g.
SYSX.prodver.*) and non mastercat entries as
Personally I prefer a unique HLQ for ISV datasets in the mastercat (e.g.
SYSX.prodver.*) and non mastercat entries as MVS.prodver.* (for example).
I don't like versions in LNKLST datasets.
I have no problem with them in maintenance or steplibs.
But, regardless of the HLQ, they should not have
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL
Sent: Monday, June 14, 2010 3:56 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Linklst; 6 of 1/half dozen of the other?
Personally I prefer a unique HLQ for ISV datasets in
On Mon, Jun 14, 2010 at 4:04 PM, McKown, John john.mck...@healthmarkets.com
wrote:
I don't like versions in LNKLST datasets.
I have no problem with them in maintenance or steplibs.
But, regardless of the HLQ, they should not have versioning
in the production environment, IMO.
I agree
I agree with you about versions. My manager, OTOH, totally disagrees. So we do
it his way.
Don't you just hate it when managers make technical decisions?
Staff should be smart enough to determine the best way to organise the products.
Managers should be smart enough to let staff do their jobs
It is mostly a religious issue, but for some products there are practical
considerations.
I don't see it as 'religious'; just less editing of PARMLIB.
I'm curious.
Can you give an example of when the version should be included in the LNKLST?
Or, am I reading too much into 'practical
Actually our naming conventions are
Production MVS.prod.*(.lpar) SYSX.prod.*(.lpar)
(.lpar) if I need LPAR specific datasets
Install/TestMVS.prodVnnn.*
SYSX.prodV99.* which is a linklisted copy of a
MVS.prodVnnn.* load although I
From: Starr, Alan alan_st...@calpers.ca.gov
To: IBM-MAIN@bama.ua.edu
Sent: Mon, June 14, 2010 2:42:35 PM
Subject: Re: Linklst; 6 of 1/half dozen of the other?
Hi Dave,
---SNIP
I am against having any vendors library in the
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Ed Gould
Sent: Monday, June 14, 2010 2:24 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Linklst; 6 of 1/half dozen of the other?
Hi Dave,
---SNIP
On Mon, 14 Jun 2010 14:34:25 -0700, Gibney, Dave wrote:
Current product in question is FDRABR. He has also done Syncsort like
this. Both are needed early in the IPL and if there is a way to avoid
link/lpa listing them, I don't know it.
In many cases, I do prefer ISV in the system search
Dave Gibney
Information Technology Services
Washington State University
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Paul Gilmartin
Sent: Monday, June 14, 2010 2:51 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Linklst; 6 of 1/half
On Mon, 14 Jun 2010 15:44:58 -0700, Gibney, Dave wrote:
I've tried to promote fully qualified aliases to have a static name in
the JCL and other places while supporting versioning in the actual
dataset name.
It's been successful with a different set of products/co-worker, but
he recently took
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
---BeginMessage---
On
---snip---
I prefer to have the ISV datasets in LINKLST statements in PROGxx
cataloged in the master catalog and not use volume references. My
co-worker doesn't think it as a big deal and usually uses a load library
cataloged in the
On Mon, 14 Jun 2010 12:13:04 -0700, Gibney, Dave gib...@wsu.edu wrote:
I prefer to have the ISV datasets in LINKLST statements in PROGxx
cataloged in the master catalog and not use volume references.
My co-worker doesn't think it as a big deal and usually uses a load
library cataloged in the
Tony Harminc writes:
The part that's not clear to me is that the Rational Developer for
System z Unit Test environment clearly supports multiple users, but it
sounds as though each user must have a separately licensed copy of the
prereq Rational Developer for System z. Is this a technical or a
29 matches
Mail list logo
