Re: Difference between DISP=NEW and MOD for a PDS member?
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?
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?
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
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
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
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
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
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
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
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?
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
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
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
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