Re: Difference between DISP=NEW and MOD for a PDS member?

2011-03-04 Thread McBride, Catherine
DISP=MOD was originally created as a means to append EREP data to the EREP 
history tape data set. Of course in today's world it gets used for everything.  
However if memory serves trying to use DISP=MOD in place of DISP=NEW would 
cause an error in the EREP job stream. Perhaps it behaves differently with 
other types of DTF's. 

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Fri Mar 04 18:34:22 2011
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Yes. Notice that it makes no distinction between MOD and NEW for a member.
That is exactly why I asked the question.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Gerhard Adam
Sent: Friday, March 04, 2011 4:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Has it occurred to anyone to just look at the JCL Reference manual?

 When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or
partitioned data set extended (PDSE), and you also specify a member name in
the DSNAME parameter, the member name must not already exist. If the member
name already exists, the system terminates the job.

When you specify DISP=OLD for a PDS or a PDSE, and you also specify a member
name in the DSNAME parameter, the data set must already exist. If the member
name already exists and the data set is opened for output, the system
replaces the existing member with the new member. If the member name does
not already exist and the data set is opened for output, the system adds the
member to the data set.

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a
member name, the system positions the read/write mechanism at the end of the
data set. The system does not make an automatic entry into the directory.

When you specify DISP=MOD for a PDS or a PDSE, and you do specify a member
name, the system positions the read/write mechanism at the end of the data
set. If the member name already exists, the system terminates the job.

When you specify DISP=SHR for a partitioned data set extended (PDSE) and
also specify a member name, then:

* If the member name exists, the member can have one writer or be shared
by multiple readers, or

* If the member name does not exist, the member can be added to the data
set. Thus, multiple jobs can access different members of the data set and
add new members to the data set concurrently -- but concurrent update access
to a specific member (or update and read by other jobs) is not valid. 

--
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

--
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


Re: Difference between DISP=NEW and MOD for a PDS member?

2011-03-04 Thread McBride, Catherine
Sir it is not my place to ask you why you asked a particular question, or why 
you want to use a particular approach. Your reasons are really none of my 
business. If the same approach caused problems in our shop I may mention it as 
a professional courtesy relative  to the technical discussion. If people don't 
think something is worth discussing they don't have to reply.  

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Fri Mar 04 19:13:32 2011
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

That could be. JCL apparently converts DISP=MOD to DISP=NEW internally
(x'C0' is what ends up in JFCBIND2 for either one).

That's why I was asking. They are both supported -- why, I wondered -- is
there a difference?

I'm not just playing with JCL variations in my spare time. I have
responsibility for a virtualization product that does a lot of varied
processing depending on many details of its execution environment. I have a
bug involving the treatment of PDS members DISP=NEW/MOD. I'm trying to
figure out what the distinctions are, if any. Face it, the MVS documentation
tends to be very scattered. It's tough to know whether the discussion you
have found is the only relevant discussion. And it's tough to run an
experiment when you don't know what exactly you are looking for.

It may be a poor practice in actual coding, but customers/users do what they
do. It's supported by IBM. Not good form for a product to fail. And it's
supported by IBM but it's a poor coding practice is not an argument I want
to have with a customer or prospect.

BTW, which one is poor coding practice, NEW or MOD?

Geez! Why do I have to defend asking a question on IBMMAIN?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Gerhard Adam
Sent: Friday, March 04, 2011 4:57 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Why should it make a distinction?  DISP=MOD and DISP=NEW behave exactly the
same way for a new data set also.

In fact, a DISP=MOD doesn't make logical sense for a PDS, since it isn't
sequential data that is being appended, nor does it make sense for a
directory.  While the manual indicates that both forms work, they seem like
a poor practice in actual coding.


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Charles Mills
Sent: Friday, March 04, 2011 4:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Yes. Notice that it makes no distinction between MOD and NEW for a member.
That is exactly why I asked the question.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Gerhard Adam
Sent: Friday, March 04, 2011 4:08 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Difference between DISP=NEW and MOD for a PDS member?

Has it occurred to anyone to just look at the JCL Reference manual?

 When you specify DISP=MOD or DISP=NEW for a partitioned data set (PDS) or
partitioned data set extended (PDSE), and you also specify a member name in
the DSNAME parameter, the member name must not already exist. If the member
name already exists, the system terminates the job.

When you specify DISP=OLD for a PDS or a PDSE, and you also specify a member
name in the DSNAME parameter, the data set must already exist. If the member
name already exists and the data set is opened for output, the system
replaces the existing member with the new member. If the member name does
not already exist and the data set is opened for output, the system adds the
member to the data set.

When you specify DISP=MOD for a PDS or a PDSE, and you do not specify a
member name, the system positions the read/write mechanism at the end of the
data set. The system does not make an automatic entry into the directory.

When you specify DISP=MOD for a PDS or a PDSE, and you do specify a member
name, the system positions the read/write mechanism at the end of the data
set. If the member name already exists, the system terminates the job.

When you specify DISP=SHR for a partitioned data set extended (PDSE) and
also specify a member name, then:

* If the member name exists, the member can have one writer or be shared
by multiple readers, or

* If the member name does not exist, the member can be added to the data
set. Thus, multiple jobs can access different members of the data set and
add new members to the data set concurrently -- but concurrent update access
to a specific member (or update and read by other jobs) is not valid. 

--
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 

Re: Problem Objects: A Freudian Slip?

2011-02-26 Thread McBride, Catherine
You made my day with that one! LOL!!!

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Sat Feb 26 08:23:58 2011
Subject: Problem Objects:  A Freudian Slip?

The z/OS MVS JCL Reference defines DSNTYPE=LIBRARY as:  
Specifies a DFSMS-managed partitioned data set extended (PDSE). A PDSE can 
contain data and problem object members.  
Given the history of PDSEs, surely the use of problem for program is more 
than simply a random typo.  
Paging Dr. Freud!  

  
--
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


Re: Question about wiping a DS8100

2011-02-25 Thread McBride, Catherine
It really depends upon how stringent the requirements are in the shop
where the person who posted the original question works.  Here we have
some additional requirements, other shops may not.   
 
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Mark Pace
Sent: Friday, February 25, 2011 2:52 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about wiping a DS8100

Plus, unlike a PC drive, on the DS8100 the data is stripped over
multiple drives.  Making data recovery on individual drives an exercise
in futility.

On Fri, Feb 25, 2011 at 3:00 PM, Robert A. Rosenberg
hal9...@panix.comwrote:

 At 14:34 -0600 on 02/24/2011, McBride, Catherine wrote about Re: 
 Question about wiping a DS8100:


  Yes, using the web-based Storage Manager application to change the 
 ranks
 from one format to another will certainly work.
 I was told that changing from one format to the other 3 times would 
 be best.


 That need to switch 3 times is based on your level of desire to 
 prevent recovery of your data. The first switch will remove all the 
 directory data and overwrite all the tracks. That makes all the data 
 vanish. However there are forensic  methods that may be able to read 
 the erased data although it has been overwritten. Thus the additional 
 reformats (which makes the data harder to find on the drive using the 
 forensic methods). This is the same situation as with PC Hard Drives 
 and Secure Erase. You use a higher Secure Erase setting to rewrite the

 tracks more times. Unless you expect that someone is going to go to 
 the trouble to do that level of data recovery, just removing the 
 directories and overwriting the tracks (so the data is no longer there
for normal reading or viewing the tracks) should be enough.


 --
 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




--
Mark D Pace
Senior Systems Engineer
Mainline Information Systems

--
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

--
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


Re: USERCAT QUESTION

2011-02-24 Thread McBride, Catherine
Yes and run it twice. Once to close  and the second to  update HURBA. 

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Thu Feb 24 06:42:37 2011
Subject: Re: USERCAT QUESTION

Try an IDCAMS VERIFY DATASET(data.set.name).

On Thu, Feb 24, 2011 at 6:33 AM, willie bunter williebun...@yahoo.com wrote:
 Hallo All,
 Of late when I backup up a USERCAT - using DFDSS.  I receive the message;
 ADR724E (001)-FMSCT(03), ERROR DURING LOCATE OF DATA SET INFORMATION FOR DATA 
 SET IN CATALOG TSTCAT.TSOI21, 01-AM-00012-00068
 CMI RETURN INFORMATION IS : FT-00186-0
 IGW01068T UNEXPECTED RESULTS FROM A CATALOG LOCATE REQUEST. RETURN CODE WAS 
 186
 . REASON CODE WAS X''
 ADR427E (001)-BLDCN(07), ERROR IN VVDS ON VOLUME SYSIU2 WHILE ACCESSING 
 COMPONETS OF CLUSTER TSTCAT.TSOI21 IN CATALOG
 SYS1.UIC.MCAT
 I did a DIAGNOSE/EXAMINE of the USERCAT and NO ERRORS DETECTED 
 I did a DIAGNOSE/EXAMINE of the MCAT and NO ERRORS DETECTED
 I did a LISTC CAT(TSTCAT.TSOI21) ALL  and I noticed the following message:
 IDC11441I ENTRY WAS INTERRUPTED DURING A PREVIOUS PROCESS
 IDC2954I  STATIC TEXT ENTRY REQUESTED NOT IN MODULE
 There are 0 records in the REC-TOTAL
 I also noticed the following :
 IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS IGG0CLE0-6
 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE NOT LISTED
 IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS IGG0CLE0-6
 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE.DATA NOT LISTED
 IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS IGG0CLE0-6
 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE.INDEX NOT LISTED
 CLUSTER --- SYS1.VVDS.VAIGI22

 I did a LISTCAT of the CLUSTER and I noticed that it exists in another 
 USERCAT.  I think the only way to fix this problem is delete the these 
 entries in this trouble USERCAT.  If so, how do I go about it?
 If not, could you suggest something I could try.  We do not have any CATALOG 
 SCRUB installed on this LPAR.

 Thanks in advance.









 --
 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




-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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


Re: USERCAT QUESTION - CORRECTION

2011-02-24 Thread McBride, Catherine
This may be worth a call to the IBM support center if you are on a supported 
release.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Thursday, February 24, 2011 8:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: USERCAT QUESTION - CORRECTION

A correction to my earlier post when I said that the DIAGNOSE had no errors.  I 
stand corrected.  I misread the message - it was generated from the EXAMINE.
The DIAGNOSE did have the following error :
 DIAGNOSE ICFCATALOG INFILE(DIAGDD) IDC21364I ERROR DETECTED BY DIAGNOSE:
  ICFCAT ENTRY: TSTCAT.TSOI21 (D)
  RECORD:  /00
  OFFSET: X'004A'
  REASON: 11 - UNCOMPLETED DELETE DETECTED IDC21365I ICFCAT RECORD DISPLAY:
  RECORD:  /00  

IDC21363I THE FOLLOWING ENTRIES HAD ERRORS:
  TSTCAT.TSOI21 (D) - REASON CODE: 11 IDC0001I FUNCTION COMPLETED, HIGHEST 
CONDITION CODE WAS 8    
 
Sorry.  

--- On Thu, 2/24/11, McBride, Catherine cmcbr...@kable.com wrote:


From: McBride, Catherine cmcbr...@kable.com
Subject: Re: USERCAT QUESTION
To: IBM-MAIN@bama.ua.edu
Received: Thursday, February 24, 2011, 4:49 AM


Yes and run it twice. Once to close  and the second to  update HURBA. 

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Thu Feb 24 06:42:37 2011
Subject: Re: USERCAT QUESTION

Try an IDCAMS VERIFY DATASET(data.set.name).

On Thu, Feb 24, 2011 at 6:33 AM, willie bunter williebun...@yahoo.com wrote:
 Hallo All,
 Of late when I backup up a USERCAT - using DFDSS.  I receive the 
 message; ADR724E (001)-FMSCT(03), ERROR DURING LOCATE OF DATA SET 
 INFORMATION FOR DATA SET IN CATALOG TSTCAT.TSOI21, 01-AM-00012-00068 
 CMI RETURN INFORMATION IS : FT-00186-0 IGW01068T UNEXPECTED 
 RESULTS FROM A CATALOG LOCATE REQUEST. RETURN CODE WAS 186 . REASON CODE WAS 
 X''
 ADR427E (001)-BLDCN(07), ERROR IN VVDS ON VOLUME SYSIU2 WHILE 
 ACCESSING COMPONETS OF CLUSTER TSTCAT.TSOI21 IN CATALOG SYS1.UIC.MCAT 
 I did a DIAGNOSE/EXAMINE of the USERCAT and NO ERRORS DETECTED 
 I did a DIAGNOSE/EXAMINE of the MCAT and NO ERRORS DETECTED
 I did a LISTC CAT(TSTCAT.TSOI21) ALL  and I noticed the following message:
 IDC11441I ENTRY WAS INTERRUPTED DURING A PREVIOUS PROCESS IDC2954I  
 STATIC TEXT ENTRY REQUESTED NOT IN MODULE There are 0 records in the 
 REC-TOTAL I also noticed the following :
 IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS IGG0CLE0-6 
 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE NOT LISTED IDC3014I CATALOG 
 ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS 
 IGG0CLE0-6 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE.DATA NOT LISTED 
 IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 50- 
 REASON CODE IS IGG0CLE0-6 IDC1566I ** 
 LIVDC.ISI.DOCUTEXT.XREF.FILE.INDEX NOT LISTED CLUSTER --- 
 SYS1.VVDS.VAIGI22

 I did a LISTCAT of the CLUSTER and I noticed that it exists in another 
 USERCAT.  I think the only way to fix this problem is delete the these 
 entries in this trouble USERCAT.  If so, how do I go about it?
 If not, could you suggest something I could try.  We do not have any CATALOG 
 SCRUB installed on this LPAR.

 Thanks in advance.









 --
 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




--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 




--
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

--
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


Re: USERCAT QUESTION - CORRECTION

2011-02-24 Thread McBride, Catherine
If I were you at this point and had IBM support, I'd be placing a call.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Thursday, February 24, 2011 8:26 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: USERCAT QUESTION - CORRECTION

I rechecked the DIAGNOSE job.  It did run okay the first time.  However when I 
reran it after the VERIFY jobs the DIAGNOSE put out the error message.  Maybe, 
the VERIFY may have had something to do with triggering the error message on 
the second time the DIAGNOSE was run.

--- On Thu, 2/24/11, McBride, Catherine cmcbr...@kable.com wrote:


From: McBride, Catherine cmcbr...@kable.com
Subject: Re: USERCAT QUESTION - CORRECTION
To: IBM-MAIN@bama.ua.edu
Received: Thursday, February 24, 2011, 6:21 AM


This may be worth a call to the IBM support center if you are on a supported 
release.  

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
willie bunter
Sent: Thursday, February 24, 2011 8:13 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: USERCAT QUESTION - CORRECTION

A correction to my earlier post when I said that the DIAGNOSE had no errors.  I 
stand corrected.  I misread the message - it was generated from the EXAMINE.
The DIAGNOSE did have the following error :
 DIAGNOSE ICFCATALOG INFILE(DIAGDD) IDC21364I ERROR DETECTED BY DIAGNOSE:
  ICFCAT ENTRY: TSTCAT.TSOI21 (D)
  RECORD:  /00
  OFFSET: X'004A'
  REASON: 11 - UNCOMPLETED DELETE DETECTED IDC21365I ICFCAT RECORD DISPLAY:
  RECORD:  /00  

IDC21363I THE FOLLOWING ENTRIES HAD ERRORS:
  TSTCAT.TSOI21 (D) - REASON CODE: 11 IDC0001I FUNCTION COMPLETED, HIGHEST 
CONDITION CODE WAS 8    
 
Sorry.  

--- On Thu, 2/24/11, McBride, Catherine cmcbr...@kable.com wrote:


From: McBride, Catherine cmcbr...@kable.com
Subject: Re: USERCAT QUESTION
To: IBM-MAIN@bama.ua.edu
Received: Thursday, February 24, 2011, 4:49 AM


Yes and run it twice. Once to close  and the second to  update HURBA. 

- Original Message -
From: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu
To: IBM-MAIN@bama.ua.edu IBM-MAIN@bama.ua.edu
Sent: Thu Feb 24 06:42:37 2011
Subject: Re: USERCAT QUESTION

Try an IDCAMS VERIFY DATASET(data.set.name).

On Thu, Feb 24, 2011 at 6:33 AM, willie bunter williebun...@yahoo.com wrote:
 Hallo All,
 Of late when I backup up a USERCAT - using DFDSS.  I receive the 
 message; ADR724E (001)-FMSCT(03), ERROR DURING LOCATE OF DATA SET 
 INFORMATION FOR DATA SET IN CATALOG TSTCAT.TSOI21, 01-AM-00012-00068 
 CMI RETURN INFORMATION IS : FT-00186-0 IGW01068T UNEXPECTED 
 RESULTS FROM A CATALOG LOCATE REQUEST. RETURN CODE WAS 186 . REASON CODE WAS 
 X''
 ADR427E (001)-BLDCN(07), ERROR IN VVDS ON VOLUME SYSIU2 WHILE 
 ACCESSING COMPONETS OF CLUSTER TSTCAT.TSOI21 IN CATALOG SYS1.UIC.MCAT 
 I did a DIAGNOSE/EXAMINE of the USERCAT and NO ERRORS DETECTED 
 I did a DIAGNOSE/EXAMINE of the MCAT and NO ERRORS DETECTED
 I did a LISTC CAT(TSTCAT.TSOI21) ALL  and I noticed the following message:
 IDC11441I ENTRY WAS INTERRUPTED DURING A PREVIOUS PROCESS IDC2954I 
 STATIC TEXT ENTRY REQUESTED NOT IN MODULE There are 0 records in the 
 REC-TOTAL I also noticed the following :
 IDC3014I CATALOG ERROR
 IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS IGG0CLE0-6 
 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE NOT LISTED IDC3014I CATALOG 
 ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 50- REASON CODE IS
 IGG0CLE0-6 IDC1566I ** LIVDC.ISI.DOCUTEXT.XREF.FILE.DATA NOT LISTED 
 IDC3014I CATALOG ERROR IDC3009I ** VSAM CATALOG RETURN CODE IS 50- 
 REASON CODE IS IGG0CLE0-6 IDC1566I ** 
 LIVDC.ISI.DOCUTEXT.XREF.FILE.INDEX NOT LISTED CLUSTER ---
 SYS1.VVDS.VAIGI22

 I did a LISTCAT of the CLUSTER and I noticed that it exists in another 
 USERCAT.  I think the only way to fix this problem is delete the these 
 entries in this trouble USERCAT.  If so, how do I go about it?
 If not, could you suggest something I could try.  We do not have any CATALOG 
 SCRUB installed on this LPAR.

 Thanks in advance.









 --
 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




--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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 




--
For IBM-MAIN subscribe / signoff

Re: Question about wiping a DS8100

2011-02-24 Thread McBride, Catherine
Yes, using the web-based Storage Manager application to change the ranks
from one format to another will certainly work.
I was told that changing from one format to the other 3 times would be
best.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Matthew Stitt
Sent: Thursday, February 24, 2011 2:26 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about wiping a DS8100

You should be able to access the user interface through a browser and
delete the volumes, extent pools, ranks, etc.  When you perform those
operations the machine will format the disk drives.  As was suggested
early on, you also could change the extent pools, ranks, arrays from one
format to the other (Open to CKD).  That will most definitely cause a
disk format and the data will be gone.

On Thu, 24 Feb 2011 11:19:44 -0700, Nancy R. Brizuela
brizu...@uwyo.edu wrote:

Hi Catherine,

I wish our 3rd party provider had their act together like yours.  I've
asked him several times for suggestions or approaches--he says he'll
research it, but then I never hear back!  Thanks for the thought,
though--you have a very helpful group here!

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
Of McBride, Catherine
Sent: Wednesday, February 23, 2011 2:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about wiping a DS8100

You may want to check with your 3rd party maintenance provider as well.
We are in a similar situation as yours, and our 3rd party provider 
presented a few options.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On 
Behalf
Of Nancy R. Brizuela
Sent: Wednesday, February 23, 2011 3:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about wiping a DS8100

Thanks for such prompt responses, David, Claude, Mark, Ed, and Hal.   I
neglected to mention that the DS8100 is no longer attached to a 
mainframe
and that we no longer have a CE.  Alas, our mainframe was shipped off in
a truck four or five years ago and a couple years ago our managers
discovered they could save a lot of money by gong with a 3rd party
maintenance provider, so we are no longer with IBM.  Nevertheless, this
gives me some good leads.  I'll contact my former CE and investigate
some of the other options.  Thanks so much!

From: Nancy R. Brizuela
Sent: Wednesday, February 23, 2011 10:50 AM
To: 'IBM-MAIN@BAMA.UA.EDU'
Subject: Question about wiping a DS8100

Hi All,

I am new to this list.  I have a DS8100 that we are decommissioning and
using as a trade-in.  We need to make sure that all the data on this
system is erased before we ship it off.  Do any of you have any thoughts
on how to accomplish this at little or no expense?  Has anyone already
dealt with this issue?  Thanks!

Nancy Brizuela
Systems Programmer, Senior
University of Wyoming
IBM/Unix Systems Group


--
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

--
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


Re: Question about wiping a DS8100

2011-02-23 Thread McBride, Catherine
You may want to check with your 3rd party maintenance provider as well.
We are in a similar situation as yours, and our 3rd party provider
presented a few options.

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Nancy R. Brizuela
Sent: Wednesday, February 23, 2011 3:34 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about wiping a DS8100

Thanks for such prompt responses, David, Claude, Mark, Ed, and Hal.   I
neglected to mention that the DS8100 is no longer attached to a
mainframe and that we no longer have a CE.  Alas, our mainframe was
shipped off in a truck four or five years ago and a couple years ago our
managers discovered they could save a lot of money by gong with a 3rd
party maintenance provider, so we are no longer with IBM.  Nevertheless,
this gives me some good leads.  I'll contact my former CE and
investigate some of the other options.  Thanks so much!

From: Nancy R. Brizuela
Sent: Wednesday, February 23, 2011 10:50 AM
To: 'IBM-MAIN@BAMA.UA.EDU'
Subject: Question about wiping a DS8100

Hi All,

I am new to this list.  I have a DS8100 that we are decommissioning and
using as a trade-in.  We need to make sure that all the data on this
system is erased before we ship it off.  Do any of you have any thoughts
on how to accomplish this at little or no expense?  Has anyone already
dealt with this issue?  Thanks!

Nancy Brizuela
Systems Programmer, Senior
University of Wyoming
IBM/Unix Systems Group


--
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

--
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


Re: Question about COBOL Program

2011-02-21 Thread McBride, Catherine
Hi Kriss,

I have no experience with your scenario, but in the reverse scenario
(Z/OS to VSE) we always had to recompile before the programs would run
on the Z-VSE systems.  Not sure if there's any kind of a transparency
available or not.
Good luck.

(Go ISU!)

Kind regards,

Cathy   

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Davis, Kriss
Sent: Monday, February 21, 2011 8:36 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Question about COBOL Program

I have been following this thread for a bit.  Maybe I missed where the
has been answered.

Are COBOL LOAD modules incompatible between VSE and Z/os?  (specifically
regarding file handling?)  If not, is there an option to delay or stage
the changing and recompiling/binding of the COBOL SOURCE code until
after the conversion.  The programs could be changed as they come up for
maintenance or encounter a problem?  If the old ones can continue to
run,  you could use historical data to determine if certain programs are
often maintained or fails frequently, and work on those programs first?

Kriss



Kriss Davis
Project Manager, CIRBN
ITDC Room 122C, Mail Code 6370
Illinois State University

--
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

--
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


Re: Anyone here also do IBM I Series work too?

2011-02-16 Thread McBride, Catherine
Yup.  Many hats.
MIDRANGE-L is a pretty good mailing list. 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Dana Mitchell
Sent: Wednesday, February 16, 2011 9:30 AM
To: IBM-MAIN@bama.ua.edu
Subject: Anyone here also do IBM I Series work too?

Our company recently acquired one that is IBM i Series based.  So we
(z/OS 
guys)  are going to become primary support for several IBM i Systems.
Just 
curious if others wear these multiple hats, and I'm curious of good
sources of info for i  that are comparable to IBM-MAIN that we all
enjoy.

thanks
Dana

--
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

--
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


Re: IBM 2105 Shark decommissioning

2011-02-10 Thread McBride, Catherine
HOW TRUE!
Thanks to all who took the time to reply 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Chase, John
Sent: Thursday, February 10, 2011 7:43 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM 2105 Shark decommissioning

 -Original Message-
 From: IBM Mainframe Discussion List On Behalf Of McBride, Catherine
 
 At long last we're taking down our IBM 2105.  My question has to do
with
 the fact that the 2105 shares a McData switch with another SAN, and
that
 other SAN is live production. Powering down the 2105 and carefully 
 removing the cables and electrical power source should have no
negative
 effect on the McData switch or second SAN, correct?  All cables and 
 power feeds are clearly marked, and we readily know which cables are
the
 correct ones. Anything else we need to be concerned about?

Murphy's Law has not yet been successfully repealed. . . .

-jc-

--
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

--
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


Re: IBM 2105 Shark decommissioning

2011-02-10 Thread McBride, Catherine
Our mainframe was connected point-to-point via dedicated ESCON to this
old SAN, it didn't route through the McData so doubt the fabric was even
aware of the mainframe's existence. 
Thanks 

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Karl Huf
Sent: Thursday, February 10, 2011 10:31 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: IBM 2105 Shark decommissioning

OK, now that I've (kind of) caught up over on the VM list I see you
already had disconnected the other ends of the cables from your
mainframe(s).  When that loss of light took place if nothing happened
then your worst case at this point in disconnecting the cables is a
clumsy technician.  Still wouldn't hurt to block the ports (and drop
them from whatever zones they are in).

--
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


IBM 2105 Shark decommissioning

2011-02-09 Thread McBride, Catherine
At long last we're taking down our IBM 2105.  My question has to do with
the fact that the 2105 shares a McData switch with another SAN, and that
other SAN is live production. Powering down the 2105 and carefully
removing the cables and electrical power source should have no negative
effect on the McData switch or second SAN, correct?  All cables and
power feeds are clearly marked, and we readily know which cables are the
correct ones. Anything else we need to be concerned about?

--
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