Re: Replacing HSM exits
Are you doing this in TSO like HRECALL type commands or is it through the F HSM,RECALL type commands? Maybe if you are testing under TSO you need to add a STEPLIB to your LOGON PROC? That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Tuesday, December 11, 2012 11:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Replacing HSM exits In the DFSMS exits book, there is a sentence: Link-edit the replacement exit code into the proper library in the LNKLST concatenation (job or step libraries). , but seems to me STEPLIB is ignored somehow. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Replacing HSM exits
Hi This are the standard HSM exits as (ARCMMEXT, ARCMDEXT ARCRDEXT) they are called by the HSM address space, Seems to me here the DFSMSHSM STEPLIB is ignored, and the DFSMS exits book have a mysterious sentence: Link-edit the replacement exit code into the proper library in the LNKLST concatenation (job or step libraries). P.S: Where are you Lizette ? On 12.12.2012 11:16, Lizette Koehler wrote: Are you doing this in TSO like HRECALL type commands or is it through the F HSM,RECALL type commands? Maybe if you are testing under TSO you need to add a STEPLIB to your LOGON PROC? That is just a guess. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Miklos Szigetvari Sent: Tuesday, December 11, 2012 11:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Replacing HSM exits In the DFSMS exits book, there is a sentence: Link-edit the replacement exit code into the proper library in the LNKLST concatenation (job or step libraries). , but seems to me STEPLIB is ignored somehow. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
I broke it - programcontrolled programs
I managed to break it. :-( Whenever someone tries to ftp into our 1.13 adcd system, we get (after typing in the password): ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED. BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR DAEMON (BPX.DAEMON) PROCESSING. CSV042I REQUESTED MODULE DFSMRCL0 NOT ACCESSED. THE MODULE IS NOT PROGRAM CONTROLLED CSV028I ABEND306-42 JOBNAME=FTPD2 STEPNAME=*OMVSEX I took a dump, and yes, there is an entry for DFSMRCL0 (IMS task/asid termination resource manager?, installed via usermod into ieavtrml) in the JPA. Never mind that IMS is NOT running. Apparently this module resides in IM1110.sdreslib, which is neither in LPA nor in linklist, so I don't see that the system can even access it. No, it isn't program controled. FTPD*.* should be assigned userid omvsus2 via class started, but I don't see any IRR812 message telling me so, so I guess that profile isn't even used. OMVSUS2 has alter to BPX.DAEMON in class FACILITY (as does my own userid that I use for ftp). These libraries are covered under the * profile in class PROGRAM: PROGRAM CEE.SCEERUN2 PROGRAM TCPIP.SEZALOAD PROGRAM SYS1.SIEALNKE PROGRAM SYS1.CSSLIB PROGRAM TCPIP.SEZALPA PROGRAM TCPIP.SEZALINK PROGRAM SYS1.LINKLIB PROGRAM CBC.SCLBDLL PROGRAM CEE.SCEERUN PROGRAM SYS1.SCEERUN I tested changing the bpx.daemon profile (facility) to warning, same result. What do I need to define to allow ftp login? Or to turn off program control, if that is even possible, so I can migrate to 1.13 as scheduled? At his point, I am afraid to IPL the system, for fear of not coming back up. Help Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Replacing HSM exits
Miklos Szigetvari wrote: Seems to me here the DFSMSHSM STEPLIB is ignored, and the DFSMS exits book have a mysterious sentence: Link-edit the replacement exit code into the proper library in the LNKLST concatenation (job or step libraries). Not mysterious. It is WAD. Did you do ALL these steps?: SETSYS EXITOFF, do above link-edit step (and as AC(1)), F LLA,REFRESH and then SETSYS EXITON Did you also considered the other special considerations for these exits? Otherwise, please show IBM-MAIN your link-edit attempts and any DFHSM message(s). Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Replacing HSM exits
Hi I tried all I think, the intention would be to take from STEPLIB, but EXITOFF EXITON has no effect, it takes from the LNKLST On 12.12.2012 12:10, Elardus Engelbrecht wrote: Miklos Szigetvari wrote: Seems to me here the DFSMSHSM STEPLIB is ignored, and the DFSMS exits book have a mysterious sentence: Link-edit the replacement exit code into the proper library in the LNKLST concatenation (job or step libraries). Not mysterious. It is WAD. Did you do ALL these steps?: SETSYS EXITOFF, do above link-edit step (and as AC(1)), F LLA,REFRESH and then SETSYS EXITON Did you also considered the other special considerations for these exits? Otherwise, please show IBM-MAIN your link-edit attempts and any DFHSM message(s). Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: I broke it - programcontrolled programs
What happens if you define DFSMRCL0 as program controlled although it is not loadable at all? I had the same problem in another ADCD system from a customer and solved this issue with a RACF definition as far as I can remember. Gruß Uwe -Ursprüngliche Nachricht- Von: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] Im Auftrag von ibmmain Gesendet: Mittwoch, 12. Dezember 2012 12:01 An: IBM-MAIN@LISTSERV.UA.EDU Betreff: I broke it - programcontrolled programs I managed to break it. :-( Whenever someone tries to ftp into our 1.13 adcd system, we get (after typing in the password): ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED. BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR DAEMON (BPX.DAEMON) PROCESSING. CSV042I REQUESTED MODULE DFSMRCL0 NOT ACCESSED. THE MODULE IS NOT PROGRAM CONTROLLED CSV028I ABEND306-42 JOBNAME=FTPD2 STEPNAME=*OMVSEX I took a dump, and yes, there is an entry for DFSMRCL0 (IMS task/asid termination resource manager?, installed via usermod into ieavtrml) in the JPA. Never mind that IMS is NOT running. Apparently this module resides in IM1110.sdreslib, which is neither in LPA nor in linklist, so I don't see that the system can even access it. No, it isn't program controled. FTPD*.* should be assigned userid omvsus2 via class started, but I don't see any IRR812 message telling me so, so I guess that profile isn't even used. OMVSUS2 has alter to BPX.DAEMON in class FACILITY (as does my own userid that I use for ftp). These libraries are covered under the * profile in class PROGRAM: PROGRAM CEE.SCEERUN2 PROGRAM TCPIP.SEZALOAD PROGRAM SYS1.SIEALNKE PROGRAM SYS1.CSSLIB PROGRAM TCPIP.SEZALPA PROGRAM TCPIP.SEZALINK PROGRAM SYS1.LINKLIB PROGRAM CBC.SCLBDLL PROGRAM CEE.SCEERUN PROGRAM SYS1.SCEERUN I tested changing the bpx.daemon profile (facility) to warning, same result. What do I need to define to allow ftp login? Or to turn off program control, if that is even possible, so I can migrate to 1.13 as scheduled? At his point, I am afraid to IPL the system, for fear of not coming back up. Help Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parked Processors
Gadi, planning considerations for HiperDispatch mode white paper is a good start... www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101229 Oz Evren Ozan Baran IBM LCST/e zPET Base Team Leader -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parked Processors
Note that IBM suggests there are circumstances where you should consider disabling it: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TD105930 Bart -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Wednesday, December 12, 2012 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parked Processors ... But don't turn off hiperdispatch unless you have a real reason too -- such as you don't like to get as much work done as you could. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
And now I have managed to make it work again: I deleted the BPX.DAEMON profile, which makes the need for a program controlled environment go away. I think. Did I mention that I hate USS? Now, if anyone has any insight what I missed defining while still having the bpx.daemon profile - I would very much appreciate that insight. At least now I can migrate. And yes, I know that this means less security than with the BPX.DAEMON profile. I am pretty sure that it is something completely unrelated that made things break. Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
What is the DSN containing DFSMRCL0? We don't have IMS, so I don't know. But
you basically do:
RALTER PROGRAM * ADDMEM('ims-loadlib'//NOPADCHK)
Pretty much any time you see that message, find the load library containing the
module (usually on the LNKLST), and do the above. Or simply do the above on
every DSN in the LNKLST.
I usually use ** instead of *, but six-of-one on that, IMO.
If you want to be really strict, then do:
RALTER PROGRAM DFSMRCL0 ADDMEM('ims-loadlib'//NOPADCHK)
to only program control DFSMRCL0 and nothing else in ims-loadlib. Personally,
I rarely bother since all these libraries are under RACF control so only
sysprogs can update them.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of ibmmain
Sent: Wednesday, December 12, 2012 5:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: I broke it - programcontrolled programs
I managed to break it. :-(
Whenever someone tries to ftp into our 1.13 adcd system, we get (after
typing in the password):
ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED.
BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR DAEMON (BPX.DAEMON)
PROCESSING.
CSV042I REQUESTED MODULE DFSMRCL0 NOT ACCESSED. THE MODULE IS NOT
PROGRAM CONTROLLED
CSV028I ABEND306-42 JOBNAME=FTPD2 STEPNAME=*OMVSEX
I took a dump, and yes, there is an entry for DFSMRCL0 (IMS task/asid
termination resource manager?, installed via usermod into ieavtrml) in
the JPA. Never mind that IMS is NOT running. Apparently this module
resides in IM1110.sdreslib, which is neither in LPA nor in linklist, so
I don't see that the system can even access it. No, it isn't program
controled.
FTPD*.* should be assigned userid omvsus2 via class started, but I
don't see any IRR812 message telling me so, so I guess that profile
isn't even used.
OMVSUS2 has alter to BPX.DAEMON in class FACILITY (as does my own
userid that I use for ftp).
These libraries are covered under the * profile in class PROGRAM:
PROGRAM CEE.SCEERUN2
PROGRAM TCPIP.SEZALOAD
PROGRAM SYS1.SIEALNKE
PROGRAM SYS1.CSSLIB
PROGRAM TCPIP.SEZALPA
PROGRAM TCPIP.SEZALINK
PROGRAM SYS1.LINKLIB
PROGRAM CBC.SCLBDLL
PROGRAM CEE.SCEERUN
PROGRAM SYS1.SCEERUN
I tested changing the bpx.daemon profile (facility) to warning, same
result.
What do I need to define to allow ftp login? Or to turn off program
control, if that is even possible, so I can migrate to 1.13 as
scheduled? At his point, I am afraid to IPL the system, for fear of not
coming back up.
Help
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
What is the DSN containing DFSMRCL0?
IMS1110.SDFSRESL or something.
RALTER PROGRAM * ADDMEM('ims-loadlib'//NOPADCHK)
I did. I also refreshed PROGRAM. Same error. Besides, that IMS library is not
anywhere in LPA or linklist. As far as I can see, the usermod that puts it into
ieavtrml does not name a library where it should be loaded from.
Unfortunately, I had not tested ftp before doing my RACF cleanup. All I can say
is that on a vanilla ADCD RACF database ftp works (for other customers). But
that vanilla RACF database has only a very passing resemblance to mine after
cleanup. I am trying to find the definition that broke it, and I assume that it
doesn't have anything to do with that module.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Barbara, What version of IMS are you running? AFAIK DFSMRCL0 is not used by IMS Version 9 or later. Second, this might be better posted on the RACF or IMS Newsgroups. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of ibmmain Sent: Wednesday, December 12, 2012 4:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: I broke it - programcontrolled programs I managed to break it. :-( Whenever someone tries to ftp into our 1.13 adcd system, we get (after typing in the password): ICH422I THE ENVIRONMENT CANNOT BECOME UNCONTROLLED. BPXP014I ENVIRONMENT MUST REMAIN CONTROLLED FOR DAEMON (BPX.DAEMON) PROCESSING. CSV042I REQUESTED MODULE DFSMRCL0 NOT ACCESSED. THE MODULE IS NOT PROGRAM CONTROLLED CSV028I ABEND306-42 JOBNAME=FTPD2 STEPNAME=*OMVSEX I took a dump, and yes, there is an entry for DFSMRCL0 (IMS task/asid termination resource manager?, installed via usermod into ieavtrml) in the JPA. Never mind that IMS is NOT running. Apparently this module resides in IM1110.sdreslib, which is neither in LPA nor in linklist, so I don't see that the system can even access it. No, it isn't program controled. FTPD*.* should be assigned userid omvsus2 via class started, but I don't see any IRR812 message telling me so, so I guess that profile isn't even used. OMVSUS2 has alter to BPX.DAEMON in class FACILITY (as does my own userid that I use for ftp). These libraries are covered under the * profile in class PROGRAM: PROGRAM CEE.SCEERUN2 PROGRAM TCPIP.SEZALOAD PROGRAM SYS1.SIEALNKE PROGRAM SYS1.CSSLIB PROGRAM TCPIP.SEZALPA PROGRAM TCPIP.SEZALINK PROGRAM SYS1.LINKLIB PROGRAM CBC.SCLBDLL PROGRAM CEE.SCEERUN PROGRAM SYS1.SCEERUN I tested changing the bpx.daemon profile (facility) to warning, same result. What do I need to define to allow ftp login? Or to turn off program control, if that is even possible, so I can migrate to 1.13 as scheduled? At his point, I am afraid to IPL the system, for fear of not coming back up. Help Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Ah, you don't refresh the PROGRAM class by doing a refresh of the PROGRAM
class. You do it with
SETROPTS WHEN(PROGRAM) REFRESH
What? You wanted consistency?
Everything must be loaded from a library. If none is specified, then it is
implicitly on the LNKLST or in the LPALST. If it is in the LNKLST, then program
management still knows the name of the DSN from which it was loaded and uses it
in its RACF check. At least, as I understand it. I am always capable of error.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of nitz-...@gmx.net
Sent: Wednesday, December 12, 2012 8:26 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: I broke it - programcontrolled programs
What is the DSN containing DFSMRCL0?
IMS1110.SDFSRESL or something.
RALTER PROGRAM * ADDMEM('ims-loadlib'//NOPADCHK)
I did. I also refreshed PROGRAM. Same error. Besides, that IMS library
is not anywhere in LPA or linklist. As far as I can see, the usermod
that puts it into ieavtrml does not name a library where it should be
loaded from.
Unfortunately, I had not tested ftp before doing my RACF cleanup. All I
can say is that on a vanilla ADCD RACF database ftp works (for other
customers). But that vanilla RACF database has only a very passing
resemblance to mine after cleanup. I am trying to find the definition
that broke it, and I assume that it doesn't have anything to do with
that module.
Barbara
--
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
On Wed, 12 Dec 2012 15:26:08 +0100, nitz-...@gmx.net nitz-...@gmx.net wrote:
What is the DSN containing DFSMRCL0?
IMS1110.SDFSRESL or something.
RALTER PROGRAM * ADDMEM('ims-loadlib'//NOPADCHK)
I did. I also refreshed PROGRAM. Same error. Besides, that IMS library is not
anywhere in LPA or linklist. As far as I can see, the usermod that puts it
into ieavtrml does not name a library where it should be loaded from.
Hi Barbara,
That makes no sense. Try using ISRDDN to see if it is somewhere you
don't expect it. If it is in the table and doesn't exist in LPA/LNKLST you
would be seeing
some nasty abends. BTW, Mr. Clean hasn't been required to be defined
in IEAVTRML since IMS V9 since it uses RESMGR.However, you still need it
or you will orphan CSA (it is just loaded dynamically now). If you
still have BNJMTERM (Netview) in there that can be removed
also (since OS/390 1.2)
Unfortunately, I had not tested ftp before doing my RACF cleanup. All I can
say is that on a vanilla ADCD RACF database ftp works (for other customers).
But that vanilla RACF database has only a very passing resemblance to mine
after cleanup. I am trying to find the definition that broke it, and I assume
that it doesn't have anything to do with that module.
Besides fixing up pads, here are some of the permissions on my system
to BPX.DAEMON I see that should apply to your system when you try to add
it back, there are others here that wouldn't apply to a generic system.
USER ACCESS
--
FTP READ
IMWEBSRV READ
OMVSKERN READ
REXEC READ
RSHD READ
OREXECD READ
BPXOINIT READ
LDAPSRV READ
stc_grpREAD (this is a group that all STCs are connected to)
Best Regards / Mit freundlichen Grüßen,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://expertanswercenter.techtarget.com/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Lizette, What version of IMS are you running? AFAIK DFSMRCL0 is not used by IMS Version 9 or later. Well, then someone should have told that to the people who deliver the ADCD system. We are NOT running any IMS version, and that module name most probably comes from IEAVTRML, that the ADCD deliverer put a usermod on naming this as a resource manager. Second, this might be better posted on the RACF or IMS Newsgroups. No. Most probably it should be posted to a USS newsgroup. The BPX.DAEMON class is best understood by the USS people. And the definitions listed in the IP config guide were either there or not necessary at all (because the classes aren't active), according to the book(s). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Common Data Space Basics
I am sorry but I just don't understand why the Extended Addressability Guide does not discuss the usage of IARST64. This looks to be what I want to use but do I need to issue IARV64 first to get the memory object or the IARV64 SHAREMEMOBJ to access these cells from other address spaces? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Common Data Space Basics
Read the prologue, the comments prefixed to the IARST64 macro definition itself. Doing so will, I suspect, answer most or all of your questions. Try to get into the habit of reading these prologues. They treat topics in a more advanced fashion and they assume more knowledgeability than do some of the manuals, which are preoccupied with brevity; but they are more current and reliable. I should guess---an outsider can never be sure---that there is now more internal IBM attention being given to keeping them comprehensive and current than there once was. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
dsf to write over entire volume
What ICKDSF command can overwrite an entire volume. We want to make sure that disks that are being replaced are wiped. Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.commailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
The following is suitable for a 3390 MOD-3. TRKFMT UNIT(10FF) VFY(OL10FF) ERASE CYL(11,3339) CYCLES(1) -Original Message- From: Tim Brown [mailto:tbr...@cenhud.com] Sent: Wednesday, December 12, 2012 11:47 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: dsf to write over entire volume What ICKDSF command can overwrite an entire volume. We want to make sure that disks that are being replaced are wiped. Thanks, Tim Brown Supervisor Computer Operations Central Hudson Gas Electric 284 South Ave Poughkeepsie, NY 12601 Email: tbr...@cenhud.commailto:tbr...@cenhud.com mailto:tbr...@cenhud.com Phone: 845-486-5643 Fax: 845-486-5921 Cell: 845-235-4255 This message contains confidential information and is only for the intended recipient. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please notify the sender immediately by replying to this note and deleting all copies and attachments. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 Coexistence Maint. and PDISC (Was: ... and DLSW)
APAR OA32369 fixed our issue, and we were able to apply our co-existence maintenance. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Meehan, Cheryl Sent: Monday, December 10, 2012 8:02 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: z/OS 1.13 Coexistence Maint. and PDISC (Was: ... and DLSW) Chris- Thank you for sending your response. We should be in a position tomorrow evening to test to see if this APAR fixes our issue. I'll post when we have completed testing. Cheryl -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Mason Sent: Sunday, December 09, 2012 3:12 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: z/OS 1.13 Coexistence Maint. and PDISC (Was: ... and DLSW) Cheryl Has anyone else seen this problem? Yes - based on my having found two APAR documents which fit your description - once it has been degaussed! 1. OA32797: ACTPU FOR SWITCHED PU REMAINS IN PDISC STATE, FAILS TO ACTIVATE WITH IST380I ACTPU REQUEST ERROR MESSAGE AND SENSE 0801 2. OA32369: ACTPU FOR SWITCHED PU REMAINS IN PDISC STATE, FAILS TO ACTIVATE WITH IST380I ACTPU REQUEST ERROR MESSAGE AND SENSE 0801 Without checking in detail, these two look identical except for the APAR numbers! How did I find these APAR documents? Well, I used the following tokens in the IBM web site main page search function: APAR PDISC VTAM This produced HIPER Fix List for VTAM in the z/OS Communications Server which listed the two APARs. QED! http://www-01.ibm.com/support/docview.wss?uid=swg21316934 I guess you should examine the maintenance package and take the matter up with your IBM support. Incidentally, the fact that backing off the maintenance package restored the configuration back to a working status helped in knowing to check for possible APARs, don't you think? - Why did your post need degaussing? The primary reason is that you did not assign one of your local VTAM specialists to present the problem. From the way you presented the problem it is clear you are not such a specialist. For example, you set great store by the fact that your distributed SNA nodes are supported by DLSw - which is irrelevant.[1] I expect you would have insisted on DLSw being one of your search tokens - and this does not yield any actual APARs. - The DLSW Controllers are at various locations across the country. There is no such thing as a DLSw controller. I imagine what you really mean - but have got into the habit as describing as these fictitious DLSw controllers between you and your colleagues in your installation - are SNA controllers, workstations of some sort, more precisely implemented as SNA type 2.1 nodes[2]. They the SNA Controllers connect using DLSW Peering over a Cisco Network to one of our OSA3 assumed OSA-Express3 features using Ethernet adapters[3] at our Data Center. The above is an improved description. When the coexistence maintenance was put on the system, ALL SNA controllers came up with a PDISC status, and the controllers failed to connect with an 0801 sense code. One small change might have permitted you to find APARs describing the problem. Incidentally, I'm guessing that the coexistence maintenance introduced the problem as maybe a faulty APAR not - as far I could see - admitted in the text of the APARs I found. I displayed the Subchannel address for the Switched major node, ... A switched major node does not have a subchannel address! Here's the sample output from the z/OS Communications Server SNA Operations manual: quote d net,id=a04smnc,scope=all IST097I DISPLAY ACCEPTED IST075I NAME = A04SMNC, TYPE = SW SNA MAJ NODE IST486I STATUS= ACTIV , DESIRED STATE= ACTIV IST1656I VTAMTOPO = REPORT, NODE REPORTED - YES IST084I NETWORK NODES: IST089I A04P882 TYPE = PU_T2, ACTIV--L-- IST089I A04P883 TYPE = PU_T2, ACTIV--L-- IST089I A04D8831 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8832 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8833 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8834 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8835 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8836 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8837 TYPE = LOGICAL UNIT , ACT/S IST089I A04P885 TYPE = PU_T2, ACTIV--L-- IST089I A04P886 TYPE = PU_T2, ACTIV--L-- IST089I A04D8861 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8862 TYPE = LOGICAL UNIT , ACT/S IST089I A04D8863 TYPE = LOGICAL UNIT , ACTIV IST089I A04D8864 TYPE = LOGICAL UNIT , ACTIV IST314I END /quote I expect you mean the XCA major node. Note that an XCA major node is a bit special in that it is permitted to contain only one PORT statement. Other major nodes tend not to be sensitive to how many of the only or top
Re: SMP/E Panels and Mixed Case
I would expect this problem to be APARable. Open an SR. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 12/11/2012 11:09 PM Subject:SMP/E Panels and Mixed Case Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU (Does this belong in ISPF-L or IBM-MAIN?) I have some CSECTS with mixed case names, so declared in ++ MOD CSECT() parameters. I notice that in the ISPF SMP/E panels their names are converted to UPPER CASE. I'm trying to track down a problem where RESTORE is not generating REPLACE statements for such CSECTs. Such behavior adds to the confusion. I'll next try a batch listing to see what it tells me. But needlessly modifying data in such manner is a disservice to the customer; the days of upper-case only output devices are deservedly past. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E Panels and Mixed Case
On Wed, 12 Dec 2012 09:14:14 -0800, Skip Robinson wrote: I would expect this problem to be APARable. Open an SR. . Thanks for your concurrence. But SMP/E nowadays is extremely permissive about what characters may appear in a CSECT() parameter of a ++MOD MCS. Some of these may reasonably be expected to be nondisplayable on typical terminals (but lower case alphabetics should not be deemed nondisplayable; at worst they are Katakana in some code pages). But what should be done with seriously nondisplayable characters? Is it the application's responsibility or ISPF's to filter or translate them? Which component is aware of terminal capabilities. SR is a good suggestion, but I got bigger fish to fry. Stay tuned. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
SMP/E RESTORE Misbehavior
I'm assisting in developing a PTF which for a certain load module (LMOD) replaces 45 MOD elements and adds one. One of the replacing MODs contains a new external reference to the added MOD. The PTF appears to APPLY fine and generate the LMOD with RC=0. (I haven't tried a power-on test; that's my colleague's responsibility.) Now I try a RESTORE. SMP/E generates Binder commands: REPLACE csect1 REPLACE csect2 REPLACE csect3 * for the 3 CSECTs in the added MOD element. INCLUDE syslmod(LMOD) NAME LMOD(R) ... but no INCLUDEs for the DLIB versions of the 45 MOD elements replaced by the PTF. Binder now gets RC=8 because of the dangling external reference from the MOD that should have been reverted to the MOD that was (properly) removed by the REPLACE commands. Has anyone seen anything like this? I don't know how to trim this to a reasonable example to report. Should I AMATERSE my entire CSI and data sets and attach to the SR? SMP/E 3.5, if it matters. Thanks, gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using SyncSort to deblock records in a file
Those of us who received unlabeled tapes in the good old days lived by this technique. The only down side was when there were one or more blocks not a multiple of the override LRECL. Then things got interesting. IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU wrote on 12/11/2012 04:08:42 PM: From: Bill Ashton bill00ash...@gmail.com Gerhard, I just tried this - what a hoot! I never would have thought of it...Thanks for such a simple suggestion - I will keep this JCL around! Billy On Tue, Dec 11, 2012 at 3:55 PM, Gerhard Postpischil gerh...@valley.netwrote: On 12/11/2012 3:44 PM, Gibney, Dave wrote: I've never used it, but this seems to be a basic function of IEBGENER(and therefore SYNC/ICE GENER) .8.2.5 RECORD Statement All this is overkill. A simple gener will do: // EXEC PGM=IEBGENER //SYSPRINT DD SYSOUT=* //SYSIN DD DUMMY //SYSUT1 DD DSN=old.ds,DISP=SHR, // DCB=(RECFM=FB,LRECL=82) //SYSUT2 DD DSN=new.ds,DISP=(,CATLG)...**etc. // DCB=(RECFM=FB,LRECL=82,**BLKSIZE=0) Gerhard Postpischil Bradford, Vermont - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
Lizette is correct. The module affectionately known as Mr. Clean, is no longer needed after V9. MA http://publib.boulder.ibm.com/infocenter/eiic/v1r1/index.jsp?topic=%2Fcom.ibm.ims9.doc.iiv%2Fip0i13901003254.htm Uninstalling DFSMRCL0 When you have completely migrated to IMS™ Version 9 or later and there is no possibility of running an earlier release of IMS (both IMS control and IMS batch jobs), you can remove DFSMRCL0 from the host z/OS® system by performing the following steps: Remove the name DFSMRCL0 from the IEAVTRML CSECT of module IGC0001C in SYS1.LPALIB. Removing this name prevents the operating system from installing DFSMRCL0 as a Static Resource Cleanup routine at the next IPL. Remove module DFSMRCL0 from SYS1.LPALIB or the MLPA library where DFSMRCL0 was bound. Start of changeRestart with CLPA to enable these changes.End of change On Wed, 12 Dec 2012 15:58:46 +0100, nitz-...@gmx.net nitz-...@gmx.net wrote: Lizette, What version of IMS are you running? AFAIK DFSMRCL0 is not used by IMS Version 9 or later. Well, then someone should have told that to the people who deliver the ADCD system. We are NOT running any IMS version, and that module name most probably comes from IEAVTRML, that the ADCD deliverer put a usermod on naming this as a resource manager. Second, this might be better posted on the RACF or IMS Newsgroups. No. Most probably it should be posted to a USS newsgroup. The BPX.DAEMON class is best understood by the USS people. And the definitions listed in the IP config guide were either there or not necessary at all (because the classes aren't active), according to the book(s). Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
TRKFMT ERASEDATA HEADRANGE(0,15) CYCLES(1) UNIT(380F) VERIFY(*NONE*) Works for any 3390. On Wed, Dec 12, 2012 at 11:03 AM, O'Brien, David W. (NIH/CIT) [C] obrie...@mail.nih.gov wrote: The following is suitable for a 3390 MOD-3. TRKFMT UNIT(10FF) VFY(OL10FF) ERASE CYL(11,3339) CYCLES(1) -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: I broke it - programcontrolled programs
On Wed, 12 Dec 2012 13:41:19 -0600, Mary Anne Matyaz maryanne4...@gmail.com wrote: Lizette is correct. The module affectionately known as Mr. Clean, is no longer needed after V9. (nit pick at V9, not after V9 or after migration to V9) MA http://publib.boulder.ibm.com/infocenter/eiic/v1r1/index.jsp?topic=%2Fcom.ibm.ims9.doc.iiv%2Fip0i13901003254.htm Uninstalling DFSMRCL0 When you have completely migrated to IMS™ Version 9 or later and there is no possibility of running an earlier release of IMS (both IMS control and IMS batch jobs), you can remove DFSMRCL0 from the host z/OS® system by performing the following steps: Remove the name DFSMRCL0 from the IEAVTRML CSECT of module IGC0001C in SYS1.LPALIB. Removing this name prevents the operating system from installing DFSMRCL0 as a Static Resource Cleanup routine at the next IPL. Remove module DFSMRCL0 from SYS1.LPALIB or the MLPA library where DFSMRCL0 was bound. Start of changeRestart with CLPA to enable these changes.End of change After looking at the link Mary Anne posted (thanks) and an install manual, I have to correct a couple of things I wrote earlier. The dynamic cleanup module (at least in IMS V9) is DFSMRC20. So Mr. Clean can go away forever provided you remove the entry from IEAVTRML. The other thing I have to correct is the nasty abends statement. It had been so long since I ran into this that I forgot that the consequences were much worse: If you do not remove the name DFSMRCL0 from IEAVTRML before you delete module DFSMRCL0 from SYS1.LPALIB, your z/OS system will not start. So that tells me for sure it is somewhere in Barbara's system search order or she is not using the IGC0001C/IEAVTRML she thought she was using. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
W dniu 2012-12-12 18:04, Don Williams pisze: ICKDSF is not intended to erase volumes. But it can erase the volumes, can't it? Now days, DASD volumes tend to be virtual. Virtual volume still contain real data. Excluding passing away structured log file technology (RVA, SVA), when you erase the logical (virtual) volume, you overwrite the real data. Only the DASD controller may know on which real hard drives your logical volumes are actually located and spread across. Not only controller. Sometimes smart folks also know that. I'm not so smart, but I can tell you what is the relationship between physical discs and logical volumes in my array. I have it documented, and it can be checked/confirmed. To be sure that your data is actually erased, you may need to consult with the vendor or other expert of your particular type of DASD. It need not to be an expert. Last but not least: when you are going to dispose whole array, the choice is obvious: erase all logical volumes, isn't it? If the DASD is encrypted, you may be able to erase the encryption keys making the DASD effectively unreadable. Good assumption, unfortunately bad implementation. There are errors in secure erase implementation, at least for some disks, AFAIK. There nothing worse than false certainty in such area. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Adding SCRATCH tapes to DFRMM
I am going batsh*t crazy trying to add tapes to the RMM scratch tape list. I use the panel to add a scratch tape and it shows in INIT status. I can't change it to scratch status cause the panels work against me. Is there a STRAIGHFORWARD way to just add VOLSERS that are immediately ready to be SCRATCH status. I'm no CA fanboy but boy was it easy to add scratches to TMS. Thanks in advance -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding SCRATCH tapes to DFRMM
On 12/12/2012 7:52 PM, Mike Wojtukiewicz wrote: I am going batsh*t crazy trying to add tapes to the RMM scratch tape list. I use the panel to add a scratch tape and it shows in INIT status. I can't change it to scratch status cause the panels work against me. Is there a STRAIGHFORWARD way to just add VOLSERS that are immediately ready to be SCRATCH status. I'm no CA fanboy but boy was it easy to add scratches to TMS. Thanks in advance -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Mike, At the bottom of the panel is a field for Initialize. The default is YES, so go Nancy Reagan. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OOCoD Question
If I turn on Capacity on Demand (i.e. make our 507 look like a 509 say) will our software that looks at CPU model recognise the change? I seem to recall that in a past life it didn't, unless you IPL while CoD is turned on. Thanks Alan Field Technical Engineer Principal BCBS Minnesota Phone: 651.662.3546 Mobile: 651.428.8826 The information contained in this communication may be confidential, and is intended only for the use of the recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please return it to the sender immediately and delete the original message and any copy of it from your computer system. If you have any questions concerning this message, please contact the sender. Unencrypted, unauthenticated Internet e-mail is inherently insecure. Internet messages may be corrupted or incomplete, or may incorrectly identify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
I mostly agree. I've been in shops with 10+ year old DASD, so they might still customers using structured log file DASD. You need to how your DASD works, in order to develop a reliable erasure plan. However, I had a teammate delete the virtual volumes on old shark prior to erasing the data. Would simply reallocating the volumes (assuming it would put them back in the same spot) and erasing them, reliably remove all of the data? I'm not smart enough to know for sure. Then you have to know how the DASD handles bad tracks/sectors. There could be residual data in bad tracks/sectors that have been replaced. How do you erase the no longer used bad tracks? I know that most DASD has spare sectors on each track, so erasing the track probably erases the bad sectors as well. But I'm not smart enough to know for sure. Whether or not you consult an expert depends on how sure you need to be that the every last bit of your data has been completely and throughly erased or made unreadable. Where I currently work, I don't have to worry about erasing DASD. They require that all of the old DASD be crushed and shreaded. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, December 12, 2012 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dsf to write over entire volume W dniu 2012-12-12 18:04, Don Williams pisze: ICKDSF is not intended to erase volumes. But it can erase the volumes, can't it? Now days, DASD volumes tend to be virtual. Virtual volume still contain real data. Excluding passing away structured log file technology (RVA, SVA), when you erase the logical (virtual) volume, you overwrite the real data. Only the DASD controller may know on which real hard drives your logical volumes are actually located and spread across. Not only controller. Sometimes smart folks also know that. I'm not so smart, but I can tell you what is the relationship between physical discs and logical volumes in my array. I have it documented, and it can be checked/confirmed. To be sure that your data is actually erased, you may need to consult with the vendor or other expert of your particular type of DASD. It need not to be an expert. Last but not least: when you are going to dispose whole array, the choice is obvious: erase all logical volumes, isn't it? If the DASD is encrypted, you may be able to erase the encryption keys making the DASD effectively unreadable. Good assumption, unfortunately bad implementation. There are errors in secure erase implementation, at least for some disks, AFAIK. There nothing worse than false certainty in such area. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
Yes, ICKDSF can erase volumes, but I don't think IBM guarantees that it is a secure erase function. There might be situation where residual data is still readable. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, December 12, 2012 5:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dsf to write over entire volume W dniu 2012-12-12 18:04, Don Williams pisze: ICKDSF is not intended to erase volumes. But it can erase the volumes, can't it? Now days, DASD volumes tend to be virtual. Virtual volume still contain real data. Excluding passing away structured log file technology (RVA, SVA), when you erase the logical (virtual) volume, you overwrite the real data. Only the DASD controller may know on which real hard drives your logical volumes are actually located and spread across. Not only controller. Sometimes smart folks also know that. I'm not so smart, but I can tell you what is the relationship between physical discs and logical volumes in my array. I have it documented, and it can be checked/confirmed. To be sure that your data is actually erased, you may need to consult with the vendor or other expert of your particular type of DASD. It need not to be an expert. Last but not least: when you are going to dispose whole array, the choice is obvious: erase all logical volumes, isn't it? If the DASD is encrypted, you may be able to erase the encryption keys making the DASD effectively unreadable. Good assumption, unfortunately bad implementation. There are errors in secure erase implementation, at least for some disks, AFAIK. There nothing worse than false certainty in such area. My €0.02 -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2012 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.410.984 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dsf to write over entire volume
I think what is being overlooked in this discussion is what is the corporate policy regarding the erasing of disk media. In planning to erase disk media it's important to seek the advice of the corporate IT Security advisor or IT auditor and get sign-off as to what is the approved methodology for erasing disk media. For a government entity there is more than likely to be a much more stringent requirement than a straight forward ICKDSF volume erase. Stephen Mednick Computer Supervisory Services Sydney, Australia Asia/Pacific representatives for: Innovation Data Processing, Inc. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Don Williams Sent: Thursday, 13 December 2012 4:05 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: dsf to write over entire volume Yes, ICKDSF can erase volumes, but I don't think IBM guarantees that it is a secure erase function. There might be situation where residual data is still readable. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OOCoD Question
On 12/12/2012 5:58 PM, Alan Field wrote: If I turn on Capacity on Demand (i.e. make our 507 look like a 509 say) will our software that looks at CPU model recognise the change? Software will obtain the configuration information on its own schedule. Some will get your configuration at startup. Some will listen for ENFs to detect increases and decreases and get your configuration dynamically. Some will check periodically or when someone uses the product interactively. All should see current model=509, permanent model=507, and temporary model=509 but only enlightened software will care about or do anything with the second two values. For example, (E)JES compares your license against your permanent model only, so you get to run temporarily upgraded mode with no warnings, messages, or other encumbrances and best of all--for free. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
