Re: CSI Interface wron entry
IDCNOGFL putput listing is similar to IDCAMS is. Since 70's we don't investigate in listings produced by utilities or programs. We had a big problem in our shop because a production JCL made a wrong decission as result of investigated output lines from a utility. Since that, we obtain info directly from the source producing a formated lines with no changes from release to releaes or even from PTF to PTF. Due to this, we use CSI Catalog interface to recover info from the catalogs and generate a formated line for each entry. IDCNOGFL is not a solution for us nut could be to avoid problems by changes in the output lines from utilities. Angel Luis Domínguez z/OS sysprog -- 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
List parent columns in foreign keys.
Hello - I am trying to write an SQL that will create a list of foreign keys in this manner. 1) Clild_Table_Name 2) Child_Column_Name 3) Parent_Table_Name 4) Parent_Column_Name I am able to get the first three data items by joining SYSIBM.SYSRELS and SYSIBM.SYSFOREIGNKEYS. But I am unable to figure from where I could pull the fourth column - Parent_Column_Name. I would appreciate any direction that you can provide. Thank you. Arka. -- 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: Encryption software?
Scott T. Harder wrote: I'm not trying to be a jerk here, but does this mean that all someone needs is your product and knowledge of the id used, in order to generate the key(s) to decrypt data encrypted with that id??? I am probably missing something here, but it sounds like there is something intrinsically wrong with that premise. You aren't being a jerk, you're asking a great question, because I failed to explain how key access is controlled. Any key server has some sort of authentication: ours ships with several (password-based, user/password, LDAP, Active Directory, etc.), and is built so it's trivial to add more -- based on phase of the moon or stock prices or whatever you can program. So no, knowing the identity used doesn't help a cracker break into Voltage SecureData, any more than knowing the key name helps with any other key management system. Knowing the identity and even the key generation algorithm wouldn't help you create keys on your own, either. Remember, there's root key material configured in the key server (as is something similar in all key servers, whether it's explicit or just entropy). This root key material is what needs to be backed up with Voltage SecureData: when you instantiate a key server, you create a one-time backup (or hopefully several copies of it!) and put THAT in your safe. Then you can ALWAYS recreate a key server and your keys, by firing up a hot/warm/cold spare and restoring that configuration. Hey presto, it can serve the keys you need. With most key servers you have to back up keys constantly -- which means those key backups are now a target. They also generate the key names with the keys, so the data flow is all from the key server to the application. And now there are TWO critical, dynamic pieces of data to back up: the key AND the key name. If you lose either, your data is gone. Most key servers pre-generate groups of keys, so they can do a backup before the keys are needed -- but the key name must still be matched to the data (and they better generate ENOUGH keys for a day's requirements, eh?). If the data store is DB2 or equivalent, that's not too bad: you add a column containing the key name used to encrypt a given row, and in a DR scenario, you restore your encrypted database and your key database and life goes on. It's a bit harder with most other datastores, as you have to store the key name somewhere. (Oh, and you DID take as much care backing up the key database as you do the data, right? And yo! u protected the key database somehow, presumably NOT storing it with the data backups? So you have two sets of daily data that must be kept separate: key and data backups. Hmm.) With Voltage SecureData, your daily backups are just as they were before encryption: data. Your key server-related backups (the configuration) are infrequent, and are thus easy to manage. These configurations (we call them districts) are small and easy to back up, and the key server can support an essentially unlimited number of them (presumably limited only by disk space). To (perhaps) anticipate your follow-on question, the next nightmare of encryption is rolling keys. Rolling keys means changing keys periodically as required by many regulations (PCI et al). You can roll keys within a district, so most customers do not tend to have many separate districts, just generations of keys within a district. With Voltage SecureData, an identity can be fully qualified, specifying more than just an email address, but it's all human-readable and thus easy to specify in an application. There are thus several ways to roll keys, depending on how your applications want to work. You can roll the identity -- payroll2...@company.com rolled to payroll2...@company.com; payr...@company.com#1255619218 rolled to payr...@company.com#13921939133 (that's a serial number in the district); varying the timestamp in the key (payr...@company.com:09072000Z rolled to payr...@company.com:10072001Z; or even changing the root key material. And of course combinations of these also work. Various of our customers have chosen different schemes based on their needs. We also offer what we called Embedded Format-Preserving Encryption, or EFPE. This violates the basic tenet of FPE by producing output that isn't quite the same format, but is the same length, by using a larger output alphabet than input. So a 9-digit SSN might encrypt as 13A4498B2 instead of all numeric. Now, in some cases, that's impossible due to storage schemes (SSN as 5-byte packed decimal, for example), but a surprising number of customers have embraced it because it makes key rollover trivial: the extra addressability offered by the extended alphabet allows storing a key number in the data. So if today your social encrypts to 13A4498B2, tomorrow it might encrypt to something different, if the key has been rolled in the meantime. On decryption, there is no requirement for your
Re: Mainframe Executive article on the death of tape
Pinnacle pisze: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Explanatory question: what does he sell now? BTW: My experience is much closer to your than presented in article (that means: MUCH LESS than 1%). However I use tape mirroring for production data. Did he mention such possibility? vbg What about disk based solutions - don't they require any redundancy? BTW: tape mirroring solves both problems: media failure and DR. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Mainframe Executive article on the death of tape
It's not what this guy is smoking, but what he is eating. We have a saying in Dutch: who's bread one eats, who's word one speaks (I hope I have the genetives correct). He clearly speaks the word of the company that feeds him. Kees. Rick Fochtman rfocht...@ync.net wrote in message news:4ba969df.9010...@ync.net... I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick --- Pinnacle wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- 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 information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ** -- 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: Any tools for managing z/OS system software products inventory?
Hi guys, Not a tool, but I know of a company, based in the UK, that will audit your zSeries estate, compare what they find against the licenses you hold, and tell you what they found depolyed (as opposed to installed), and where you are over or under licensed. They came into our shop, and whilst it took a couple of months (our fault, not theirs) they saved us @£200k PA on our software licenses, by finding stuff we were not aware of! They offer the service as a one-off, or as an annual health check. I think it cost us about £15k for the one-off service, but we're a small shop (sub 800 mips). If anyone would like more details, please contact me off list. -- 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
Link edit question
Hi List, I have a question about a link edit job. What should we do, not to replace a module in a load library, if that module already exits. We have many INCLUDE SEGMENT(pgmname) statements in the member that we use to compile so sometimes there can be duplicate statements that includes the same programs. If we get an error during the link-edit process that this module already exits in the load library, we would recognize the problem and delete that statement. If we cant recognize it, the module which was previously link-edited is replaced by the new version which has the same name. Thank you very much. -- 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: Any tools for managing z/OS system software products inventory?
Vince Getgood pisze: Hi guys, Not a tool, but I know of a company, based in the UK, that will audit your zSeries estate, compare what they find against the licenses you hold, and tell you what they found depolyed (as opposed to installed), and where you are over or under licensed. They came into our shop, and whilst it took a couple of months (our fault, not theirs) they saved us @£200k PA on our software licenses, by finding stuff we were not aware of! They offer the service as a one-off, or as an annual health check. I think it cost us about £15k for the one-off service, but we're a small shop (sub 800 mips). 15k pounds??? Me! Me! Take me! Shrek, I know the way! Seriously: I wish I would get such a job for that money. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Any tools for managing z/OS system software products inventory?
When saving £200k per annum £15k is a small price to pay and if it took them two months I doubt their day rate is very high! Mark On 24/03/2010 09:26, R.S. r.skoru...@bremultibank.com.pl wrote: Vince Getgood pisze: Hi guys, Not a tool, but I know of a company, based in the UK, that will audit your zSeries estate, compare what they find against the licenses you hold, and tell you what they found depolyed (as opposed to installed), and where you are over or under licensed. They came into our shop, and whilst it took a couple of months (our fault, not theirs) they saved us @£200k PA on our software licenses, by finding stuff we were not aware of! They offer the service as a one-off, or as an annual health check. I think it cost us about £15k for the one-off service, but we're a small shop (sub 800 mips). 15k pounds??? Me! Me! Take me! Shrek, I know the way! Seriously: I wish I would get such a job for that money. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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 Regards Mark Mark Wilson Work: GSE: Technical Director Chairman Large Systems Group RSM Partners : www.lsx.gse.org.uk Greenhill Industrial Estate Birmingham Road GSE UK Conference Manager Kidderminster : www.gse.org.uk/tyc DY10 2RN +: ma...@rsmpartners.com +: mark.wil...@gse.org.uk : www.rsmpartners.com : www.gse.org.uk È: +44 (0) 7768 617006 ( +44 (0) 870 050 1004 -- 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: Mainframe Executive article on the death of tape
snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- 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: Mainframe Executive article on the death of tape
I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- 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: Encryption software?
Phil, Thanks very much for the detailed explanation. Impressive. My interest is based on my involvement, not too long ago, with a commercial z/OS crypto product where I had been looking at creating a key server to be stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.), providing the kind of unique and value-add management features such that you have described with your product; but also wanted to stay inside the lines with our crayon when it came to compatibility with existing key management methodologies (ICSF); and use those for all that is the best of the breed (no need to re-invent the wheel, right?). This, for both symmetric and asymmetric keys, as well. Not a simple project and mine never got off the ground (won't go into it); but I admire someone (an entire team, I'm sure) that was able to take this on and have some level of success. All the best, Scott T. harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Phil Smith III Sent: Tuesday, March 23, 2010 11:50 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Encryption software? Scott T. Harder wrote: I'm not trying to be a jerk here, but does this mean that all someone needs is your product and knowledge of the id used, in order to generate the key(s) to decrypt data encrypted with that id??? I am probably missing something here, but it sounds like there is something intrinsically wrong with that premise. You aren't being a jerk, you're asking a great question, because I failed to explain how key access is controlled. Any key server has some sort of authentication: ours ships with several (password-based, user/password, LDAP, Active Directory, etc.), and is built so it's trivial to add more -- based on phase of the moon or stock prices or whatever you can program. So no, knowing the identity used doesn't help a cracker break into Voltage SecureData, any more than knowing the key name helps with any other key management system. Knowing the identity and even the key generation algorithm wouldn't help you create keys on your own, either. Remember, there's root key material configured in the key server (as is something similar in all key servers, whether it's explicit or just entropy). This root key material is what needs to be backed up with Voltage SecureData: when you instantiate a key server, you create a one-time backup (or hopefully several copies of it!) and put THAT in your safe. Then you can ALWAYS recreate a key server and your keys, by firing up a hot/warm/cold spare and restoring that configuration. Hey presto, it can serve the keys you need. With most key servers you have to back up keys constantly -- which means those key backups are now a target. They also generate the key names with the keys, so the data flow is all from the key server to the application. And now there are TWO critical, dynamic pieces of data to back up: the key AND the key name. If you lose either, your data is gone. Most key servers pre-generate groups of keys, so they can do a backup before the keys are needed -- but the key name must still be matched to the data (and they better generate ENOUGH keys for a day's requirements, eh?). If the data store is DB2 or equivalent, that's not too bad: you add a column containing the key name used to encrypt a given row, and in a DR scenario, you restore your encrypted database and your key database and life goes on. It's a bit harder with most other datastores, as you have to store the key name somewhere. (Oh, and you DID take as much care backing up the key database as you do the data, right? And yo! u protected the key database somehow, presumably NOT storing it with the data backups? So you have two sets of daily data that must be kept separate: key and data backups. Hmm.) With Voltage SecureData, your daily backups are just as they were before encryption: data. Your key server-related backups (the configuration) are infrequent, and are thus easy to manage. These configurations (we call them districts) are small and easy to back up, and the key server can support an essentially unlimited number of them (presumably limited only by disk space). To (perhaps) anticipate your follow-on question, the next nightmare of encryption is rolling keys. Rolling keys means changing keys periodically as required by many regulations (PCI et al). You can roll keys within a district, so most customers do not tend to have many separate districts, just generations of keys within a district. With Voltage SecureData, an identity can be fully qualified, specifying more than just an email address, but it's all human-readable and thus easy to specify in an application. There are thus several ways to roll keys, depending on how your applications want to work. You can roll the identity -- payroll2...@company.com rolled to
Re: Mainframe Executive article on the death of tape
Good memory on the 3480 media. Many, many years ago, BASF had a problem with 3480 Tape Media cartridges. The company that I worked for at that time received a large batch of bad tapes in a shipment, causing us quite a few headaches. This was back around 1997/1998. Since then, I've used cartridge media of all densities and vendors, without experiencing any significant problems. Mike Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott T. Harder Sent: Wednesday, March 24, 2010 7:08 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Fletcher, Kevin Sent: Wednesday, March 24, 2010 6:54 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick /snip I have to agree with the list, the last error on a tape (MF) was a duplex tape where the physical tape was dropped and the case cracked. No big deal since it was a duplex tape. On the other hand, tapes on the open systems side do have some failures. The failures are not even close to what the article specified though. If he is smoking something, he should at least share with the list :-). Thanks, Kevin Fletcher (317) 817-3545 Transition Coordinator z/OS, DB2, AS400 support Conseco, LLC -- 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: Link edit question
On Wed, 24 Mar 2010 03:58:03 -0500, Supra Uche wrote: What should we do, not to replace a module in a load library, if that module already exits. Maybe I don't understand your question. If you don't specify replace, the load module won't be replaced. -- Tom Marchant -- 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: Mainframe Executive article on the death of tape
Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- 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: z/os V1.11 PFAPATH
The PFA directory structure created by the PFA install script is expected to be in the home directory of the pfauser that owns the PFA started task. For example, if your pfauser is pfauser, it should be in /u/pfauser If you are using PFA in a sysplex that shares file systems for z/OS UNIX, use a unique directory for each LPAR so that the event data that PFA writes to the file system is stored separately for each system. For example, /u/pfauser/LPAR1/pfa /u/pfauser/LPAR2/pfa More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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: Mainframe Executive article on the death of tape
The bad tapes would literally spew black dust. We had to have all of our 3480s cleaned thoroughly, and rotate out all of the bad tapes as quickly as possible. On Wed, Mar 24, 2010 at 8:06 AM, John Kington john.king...@convergys.comwrote: Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- 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 Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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: Mainframe Executive article on the death of tape
Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Even on 3420's, of which I have seen a few snapped tapes, error rates were much lower than these ones. I would be curious as to where he came up with these numbers. Given the thousands of 3420's I used, the error rate on those was below 1%, and on 3480, 3490, 3490E and 3590 tapes the rates have been far below 1%. On various tape systems I've used to back up PC workstations and network servers, on the other hand, I have definitely seen high error rates, although probably much closer to 15-20% at the highest than the up to 50% he reports. -- 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: z/os V1.11 PFAPATH
uh, not trying to give you a hard time here, Miss, but íve got a pdf of the z/os Problem management guide (G325-2564-01) and íve run a search on installing pfa and come up empty is this the correct book? thanks /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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: Mainframe Executive article on the death of tape
The only tape media I have worked with that had that sort of error rate was 8mm DAT. That was very unreliable. In 20+ years of 34xx/3590 experience I've never seen that sort of error rate. I don't think even the cassette tape used with the TRS-80 was as bad as the DAT tape. On Wed, Mar 24, 2010 at 8:18 AM, Dave Reinken da...@reinken.us wrote: Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Even on 3420's, of which I have seen a few snapped tapes, error rates were much lower than these ones. I would be curious as to where he came up with these numbers. Given the thousands of 3420's I used, the error rate on those was below 1%, and on 3480, 3490, 3490E and 3590 tapes the rates have been far below 1%. On various tape systems I've used to back up PC workstations and network servers, on the other hand, I have definitely seen high error rates, although probably much closer to 15-20% at the highest than the up to 50% he reports. -- 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 Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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: z/os V1.11 PFAPATH
z/OS V1R11.0 Problem Management (G325-2564-05) Has information about installing PFA Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bonno, Tuco Sent: Wednesday, March 24, 2010 2:20 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/os V1.11 PFAPATH uh, not trying to give you a hard time here, Miss, but íve got a pdf of the z/os Problem management guide (G325-2564-01) and íve run a search on installing pfa and come up empty is this the correct book? thanks /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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: z/os V1.11 PFAPATH
For all of our system specific directories we use a structure like this so that we can have separate physical files but only one directory in the JCL or in the configuration files. In the system root we have a symbolic link, in this case '/pfa' that points to '/$SYSNAME/pfa'. Then in each system specific directory (/SYS1.../SYS2) we have a mountpoint for the product where we mount a separate zFS (/SYS1/pfa ... /SYS2/pfa). We can also have subdirectories under these for each upgrade of the product. We have found this method to be extremely flexible. It allows us to upgrade by only having to change the symbolic link to point to the subdirectory that has the current upgrade (/$SYSNAME/pfa/V1R1 ... /$sYSNAME/pfa/V1R2 ...etc) Jon L. Veilleux veilleu...@aetna.com (860) 636-9179 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Zelden Sent: Tuesday, March 23, 2010 9:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/os V1.11 PFAPATH On Tue, 23 Mar 2010 17:17:45 -0500, Mark Steely mark.ste...@wnco.com wrote: During installation of z/os V1.11 it needs a directory of pfapath. Where did you create this directory (root or create it own file directory ?). Thank You Someone just asked this a few weeks ago. This was my response (the archives and Google are your friends): I'm sure it can be changed later, but I pointed it to a local directory where we install software: PFA PFA OWNER USERID D PFAUSER PFA STG LOCATION D /mylcldir/pfapath PFA USER PASSWORDD http://bama.ua.edu/cgi-bin/wa?A2=ind1002L=ibm-mainD=1amp;T=0O=DP=241223 And mount a file system there. But I would think you could also have one automounted at /u/pfauser depending on how you set it up. I have not played with it yet. I thought there was some stuff in the bit bucket from SHARE in Denver from Sam Knutson who had it set up. I was waiting for him to respond last time. Maybe he'll let us know what he did (or someone else will). I just asked one of my co-workers to start setting it up last week, so I'll probably have something to share soon also. -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- 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 This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- 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: Mainframe Executive article on the death of tape
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Pinnacle Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? I can recall seeing only one bum tape in the past decade, and that was a product tape, not a backup tape. -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
Re: link edit question
Supra, Your question does need clarification. If it is about not replacing an entire load module or program object Tom Marchant has answered it. Avoid (R). If on the other hand it is about not replacing a CSECT/RSECT that is already present in a loadable object I am not sure that I understand it. The only circumstances in which I can imagine such a problem arising involve WXTRNs that may or may not have been resolved by the presence of an appropriately named object in the SYSLIN input to a preceding link/bind operation. Tell us, in more circumstantial detail, just what your problem is. John Gilmore Ashland, MA 01721-1817 USA _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID27925::T:WLMTAGL:ON:WL:en-US:WM_HMP:032010_3 -- 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: z/os V1.11 PFAPATH
VERY INTERESTING . and íd downloaded my version (the -01 ) from ibm site YESTERDAY . where did you get your -05 version ?? /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! z/OS V1R11.0 Problem Management (G325-2564-05) Has information about installing PFA Gadi uh, not trying to give you a hard time here, Miss, but íve got a pdf of the z/os Problem management guide (G325-2564-01) and íve run a search on installing pfa and come up empty is this the correct book? thanks /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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 -- 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: Mainframe Executive article on the death of tape
Thanks, John. I wasn't sure of the circumstances; just a somewhat clear memory of DCK's on 3480's. Everyone else was so clear to the contrary that I just had to do a sanity check. It's good to know that I'm still somewhat sane. My best to you, John. Good to hear from you ;-) Scott T. Harder Mainframe Services, Inc. Naples, FL -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of John Kington Sent: Wednesday, March 24, 2010 8:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Scott, I have to chime in to the contrary. I seem to remember many data check errors on 3480 cart media. Am I the only one? Spencer hit it on the head. The only significant problem with 3480 tapes was due to faulty media produced by BASF. Regards, John -- 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: z/os V1.11 PFAPATH
I searched for pfa here http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r11books.html, and that was the version that came up Gadi -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Bonno, Tuco Sent: Wednesday, March 24, 2010 2:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: z/os V1.11 PFAPATH VERY INTERESTING . and íd downloaded my version (the -01 ) from ibm site YESTERDAY . where did you get your -05 version ?? /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! z/OS V1R11.0 Problem Management (G325-2564-05) Has information about installing PFA Gadi uh, not trying to give you a hard time here, Miss, but íve got a pdf of the z/os Problem management guide (G325-2564-01) and íve run a search on installing pfa and come up empty is this the correct book? thanks /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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 -- 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: z/os V1.11 PFAPATH
I googled z/OS Problem Management Guide which gave me a link to http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.e0zk100/e0z1k11023.htm from which I downloaded the pdf. it was the only version available there. I searched for pfa here http://www-03.ibm.com/systems/z/os/zos/bkserv/v1r11books.html, and that was the version that came up VERY INTERESTING . and íd downloaded my version (the -01 ) from ibm site YESTERDAY . where did you get your -05 version ?? /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; z/OS V1R11.0 Problem Management (G325-2564-05) Has information about installing PFA Gadi uh, not trying to give you a hard time here, Miss, but íve got a pdf of the z/os Problem management guide (G325-2564-01) and íve run a search on installing pfa and come up empty is this the correct book? thanks /s/ tuco bonno; Graduate, College of Conflict Management; University of SouthEast Asia; I partied on the Ho Chi Minh Trail - tiến lên !! More details on installing PFA are in the section Installing PFA in the z/OS Problem Management Guide. Karla Arndt z/OS Predictive Failure Analysis -- 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 -- 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: password management from a USS otelnetd session
On Tue, 23 Mar 2010 10:52:10 -0500, Ray Prevott ray.prev...@wnco.com wrote: Out security department is looking at Cyber-Ark to manage passwords for some robot userids. I have set up the inetd daemon to start up otelnetd for access to USS from a standard telnet session. When I try to change a password from that interface, it looks like it works, but it really does not. Not sure where to look for the problem at. Anybody out there done something like this before? Without knowing what their product is actually doing it's hard to say. Do you get any error messages in the telnet session or in the system log or on the operator console? -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- 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: Mainframe Executive article on the death of tape
The only significant problem with 3480 tapes was due to faulty media produced by BASF. I was a customer of them, back then. I remember the pain. But, back to the article. Tape is NOT going to go away. It's still the cheapest backup media. It used to be the fastest for sequential processing, but I don't know if it still is. The last place I worked at just used it for backups. - Too busy driving to stop for gas! -- 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: Any tools for managing z/OS system software products inventory?
15k pounds??? Me! Me! Take me! Shrek, I know the way! Seriously: I wish I would get such a job for that money. Have you ever undertaken such an excercise? If so, you'd know it's not as simple as you keep claiming! - Too busy driving to stop for gas! -- 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
PAGE/FORMDEF
Anyone here can help on a form/page definition...? The first pagedef looks at a field in the record and determines what pagedef it should use to produce the needed letter. This lets us put multiple letters in the same output file to get a volume discount for mailing. problem is there is always a blank(last page) being printed?? see code below thanks for any help ideas... maybe making this more difficult then it should be .. /*---*/ /* FOMRDEF RESCH3 - DEFINE WHAT OVERLAYS ARE IN EACH GROUP */ /* THIS GROUP IS FOR SINGLE SHEET - FRONT BACK OF 1 SHEET */ /*---*/ SETUNITS 1 IN 1 IN; FORMDEF RESCH3 REPLACE YES; /*---*/ /* CGUNBK 1 2 - BANKRUPT GENERAL ADD-ON*/ /*---*/ COPYGROUP CGUNBK1 PRESENT PORTRAIT DIRECTION ACROSS; OVERLAY UNBK11; SUBGROUP OVERLAY UNBK11; COPYGROUP CGUNBK2 PRESENT PORTRAIT DIRECTION ACROSS; OVERLAY UNBK12; SUBGROUP OVERLAY UNBK12; /*---*/ /* CGUNBL 1 2 - BANKRUPT GENERAL REFUND*/ /*---*/ COPYGROUP CGUNBL1 PRESENT PORTRAIT DIRECTION ACROSS; OVERLAY UNBL11; SUBGROUP OVERLAY UNBL11; COPYGROUP CGUNBL2 PRESENT PORTRAIT DIRECTION ACROSS; OVERLAY VAL411; SUBGROUP OVERLAY VAL411; /*---*/ /* PAGEDEF WILL DEFINE WHAT COPYGROUP WILL PRINT WHEN */ /*---*/ PAGEDEF RESCH3 WIDTH 8.5 HEIGHT 11 DIRECTION ACROSS REPLACE YES; FONT GT10 GT10; /* GENERAL FONT 10 points */ /**/ /* PAGEFORMAT PF0003 - USES INPUT CODE TO DETERMINE WHICH */ /* PAGE TO PRINT - COPYGROUP DETERMINES THE OVERLAY AND */ /* THE PAGEFORMAT DETERMINES WHAT VARIABLES TO PRINT */ /**/ PAGEFORMAT PF0003; PRINTLINE; /*-- BKGNA01 - BANKRUPT GENERAL ADD-ON PAGE ONE --*/ CONDITION COND01 START 19 LENGTH 7 WHEN EQ C'BKGNA01' BEFORE SUBPAGE COPYGROUP CGUNBK1 PAGEFORMAT PFBKGN1; /*-- BKGNA02 - BANKRUPT GENERAL ADD-ON PAGE TWO --*/ CONDITION COND02 START 19 LENGTH 7 WHEN EQ C'BKGNA02' BEFORE SUBPAGE COPYGROUP CGUNBK2 PAGEFORMAT PFBKGN2; /*-- BKGNR01 - BANKRUPT GENERAL REFUND PAGE ONE --*/ CONDITION COND03 START 19 LENGTH 7 WHEN EQ C'BKGNR01' BEFORE SUBPAGE COPYGROUP CGUNBL1 PAGEFORMAT PFBKGR1; /*-- BKGNR02 - BANKRUPT GENERAL REFUND PAGE TWO --*/ CONDITION COND04 START 19 LENGTH 7 WHEN EQ C'BKGNR02' BEFORE SUBPAGE COPYGROUP CGUNBL2 PAGEFORMAT PFBKGR2; ENDSUBPAGE; /**/ /* PFBKGN1 - BANKRUPT GENERAL ADD-ON PAGE ONE */ /* WHEN DONE RETURN TO FIRST PAGEFORMAT - THE BEGINNING */ /**/ PAGEFORMAT PFBKGN1; PRINTLINE; FIELD START026 LENGTH 10 FONT GT10 POSITION 0.94 IN 1.50 IN; /* DATE OF LETTER */ FIELD START181 LENGTH 08 FONT GT10 POSITION 0.94 IN 2.00 IN; /* BRANCH NUMBER */ FIELD TEXT'RE: Customer:' FONT GT10 POSITION 0.94 IN 3.34 IN; FIELD START 239 LENGTH 25 FONT GT10 POSITION 2.95 IN 3.34 IN; /* CUSTOMER NAME */ FIELD TEXT'Account Number:' FONT GT10 POSITION 0.94 IN 3.58 IN; FIELD START 001 LENGTH 08 FONT GT10 POSITION 2.95 IN 3.58 IN; /* ACCOUNT */ FIELD TEXT'Policy Number:' FONT GT10 POSITION 0.94 IN 3.80 IN; FIELD START 009 LENGTH 10 FONT GT10 POSITION 2.95 IN 3.80 IN; /* POLICY */ FIELD START 395 LENGTH 60 FONT GT10 POSITION 1.14 IN 5.12 IN;/* COLLATERAL LINE 1 */ FIELD START 455
Re: Mainframe Executive article on the death of tape
Ted MacNEIL pisze: Tape is NOT going to go away. Agreed. It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. It used to be the fastest for sequential processing, but I don't know if it still is. It's still is, however it strongly depens on the data compression ratio and speed of the source (it shouldn't be irregular). -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Any tools for managing z/OS system software products inventory?
Ted MacNEIL pisze: 15k pounds??? Me! Me! Take me! Shrek, I know the way! Seriously: I wish I would get such a job for that money. Have you ever undertaken such an excercise? If so, you'd know it's not as simple as you keep claiming! Yes. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- 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: Any tools for managing z/OS system software products inventory?
On Tue, 23 Mar 2010 14:03:05 +, Ted MacNEIL eamacn...@yahoo.ca wrote: In either case there are DOCUMENTS. The documents are not retired, fired, died. But, they are lost, incomplete, or misunderstood. We're not talikng about group of PFCSK and bunch of PCs for gaming, we're talking about professional team. Mainframe specialists! Who, unfortunately, are only human. Sh*t happens! People, docs, source code, contracts, libraries, etc., are lost, misplaced, or (in some cases) destroyed, all the time. I have been involved in a situation where my employer purchased a company whose data processing was being performed by a third party, and the decision had been made to bring the data processsing in-house to our data center. We brought over whatever software they thought they needed from their previous processor. In some cases, they owned a license but were no longer paying maintenance, so no documention was available. It was never clear that all of the installed software was actually required. In some cases, we had good reason to believe that some of the software was not really needed, but we could never get the business unit to agree to remove it from the system, and to stop paying for it. So: People - original installers were long gone Docs - unavailable Source code - what source code? Contracts - proves it's legal, but not that it's used. Libraries - proves it's there, but not that it's used. Jeff Holst Fiserv Philadelphia, PA -- 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: Encryption software?
Scott T. Harder wrote: My interest is based on my involvement, not too long ago, with a commercial z/OS crypto product where I had been looking at creating a key server to be stored on z/OS (for all the usual and (I feel) proper reasons... RAS, etc.), providing the kind of unique and value-add management features such that you have described with your product; but also wanted to stay inside the lines with our crayon when it came to compatibility with existing key management methodologies (ICSF); and use those for all that is the best of the breed (no need to re-invent the wheel, right?). This, for both symmetric and asymmetric keys, as well. Not a simple project and mine never got off the ground (won't go into it); but I admire someone (an entire team, I'm sure) that was able to take this on and have some level of success. Sounds like an interesting project, but, as (I hope) I've shown, a tough nut to crack. Voltage has been doing this for eight years, has over 800 customers, so I think we've pretty well got the entire shell removed :-) One more feature of Format-Preserving Encryption that I should have mentioned: since it's using the same character set, you can encrypt on z/OS and decrypt on an ASCII machine (and vice versa). That's another bugaboo of many encryption schemes: having to either decrypt before sending over the network, or change processes to send as binary so the data isn't destroyed by the EBCDIC-ASCII translation process. Cheers, -- ...phsiii Phil Smith III p...@voltage.com Voltage Security, Inc. www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- 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: Mainframe Executive article on the death of tape
No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: link edit question
Hello, Thank you for your responses, i could not ask the question properly maybe. I will give you more information. My job is : USER1.PROD.LINK(TEST1) : //TEST1 JOB CLASS=A,MSGLEVEL=(1,1), MSGCLASS=X // JCLLIB ORDER=(USER1.PROD.LINK) //TST1EXEC TLINK,MEMBER=TST1 * USER1.PROD.LINK(TLINK) procedure: //ZLINK PROC MEMBER=UNKNOWN, // LIB=USER1.PROD, // HEADER=LINKHED //ZLINK EXEC PGM=HEWL,PARM='MAP,LIST,LET,NORENT,NCAL' //SYSPRINT DD SYSOUT=* //SYSLIN DD DISP=SHR,DSN=LIB..LINK(HEADER) // DD DISP=SHR,DSN=LIB..LINK(MEMBER) //SYSLMOD DD DISP=SHR,DSN=LIB..LOAD(MEMBER) //SYSTEM DD DISP=SHR,DSN=DXC.V2R3M1.DXCMOD1 //SEGMENT DD DISP=SHR,DSN=LIB..RESA.NCAL // DD DISP=SHR,DSN=LIB..DCSH.NCAL // DD DISP=SHR,DSN=LIB..RESP.NCAL // DD DISP=SHR,DSN=LIB..DCSY.NCAL // PEND * USER1.PROD.LINK (TST1): INCLUDE SEGMENT(YBY402) INCLUDE SEGMENT(YEA102) INCLUDE SEGMENT(YBY402) For example If i write the YBY402 twice it does not give any error in the TEST1 job. I want to get a jcl error if i write a record twice in TST1 member. Because there are thousands of lines in the TST1 member, some segments can be entered multiple times accidentaly. I hope i can explain the problem this time. Thank you very much. Regards, Supra -- 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: z/os V1.11 PFAPATH
Mark Steely During installation of z/os V1.11 it needs a directory of pfapath. Where did you create this directory (root or create it own file directory ?). Mark, My ServerPac Variables setup: PFAUSER = PFA PFAPATH = /u/pfa The directory, as I understand it, should be a separate file system (FS). I do not use sysplex FS sharing so I do not know how I'd handle it in such a case. Karla Arndt makes a suggestion for this (every z/OS image should have its own, non-shared PFAPATH). ServerPac dialog seems to have an underlying assumption that the directory is both: - Home directory of the PFAUSER - Data repository (persistent, across z/OS upgrades?) for the PFA STC I found two ServerPac install jobs in SCPPBENU that refer to PFAPATH/ PFAUSER: - HBB7760I - seems to initialize the PFAPATH - RACFTGT - RACF define of the PFAUSER Hth.. -- 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: Link edit question
I'm not familiar with the INCLUDE SEGMENT statement, so I could be totally wrong. The Binder (linkage editor) does not replace CSECT's unless specifically told to do so. You can code DELETE statements to cause the binder to do that. For example: Member ABC has three CSECTS: A, B, and C. We want to replace CSECTS B and C: DELETE B DELETE C INCLUDE ABC NAME ABC(R) The binder should fetch ABC, delete B and C, then fetch fresh versions of B and C to create a new ABC. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Supra Uche Sent: Wednesday, March 24, 2010 3:58 AM To: IBM-MAIN@bama.ua.edu Subject: Link edit question Hi List, I have a question about a link edit job. What should we do, not to replace a module in a load library, if that module already exits. We have many INCLUDE SEGMENT(pgmname) statements in the member that we use to compile so sometimes there can be duplicate statements that includes the same programs. If we get an error during the link-edit process that this module already exits in the load library, we would recognize the problem and delete that statement. If we cant recognize it, the module which was previously link-edited is replaced by the new version which has the same name. Thank you very much. NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Mainframe Executive article on the death of tape
Could someone provide a link to this article. Looking through I see articles by Fred Moore and Jon Toigo (I know both and would consider them to be my friends). But, I could not find the article being referenced (more coffee will probably help me with that). I also spent 20 years at STK and then Sun so I would like to see who this person is and what they are posting, then I can comment on it. As another history note STK also had some media problmes with 9840's when a batch from Imation was bad but it was taken care of. There was also a problem with 9840c drives reading 9840a media but that was a drive issue that was fixed. Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 9:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Alter JES Exit #? to write NOOP (x'03') recs with data to OUTPUT Spool/Queue
Is anyone familiar with the SET NOPDATA[ON,OFF] command? Is it possible that this is all I need to use to begin having my my NOOP CCW (x'03') records, and the data I have within them, begin to write out to the OUTPUT JES Spool? http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp? topic=/com.ibm.zvm.v53.hcpa5/dspool.htm -- 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
Trying to understand ALLOWUSERKEYCSA and subpool storage
Please bear with me. I'm primarily a CICS system programmer. I posted something similar to the CICS List but now I really need to understand it from the z/OS or MVS side of things. We have multiple CICS regions (address spaces) in an LPAR and they all currently share a piece of MVS storage. This area holds common information that all regions access. Only 2 regions actually update the information - all the others just read. Our program acquired the area using the following: LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE The new default of ALLOWUSERKEYCSA of NO of course makes this fail. We did set it to YES since this is necessary for our CICS to run. However, I've been given the task to see if we can have a shared area and run with the default of NO. Subpool 241 is CSA, system, not fetch proteced, pageable storage. The closest I can find is 228 - which is CSA, system, not fetch protected but FIXED. However, will that still cause me issues since it is CSA? What about subpool 226 - says it is SQA, system, not fetch protected but FIXED? Might I be able to use that? The size of this area is not that large - 20,480 bytes. I'd be grateful for any light and wisdom you can shed on this subject for me. thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance -- 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: Mainframe Executive article on the death of tape
Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. Mike Spencer -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Carl Swanson Sent: Wednesday, March 24, 2010 10:13 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Could someone provide a link to this article. Looking through I see articles by Fred Moore and Jon Toigo (I know both and would consider them to be my friends). But, I could not find the article being referenced (more coffee will probably help me with that). I also spent 20 years at STK and then Sun so I would like to see who this person is and what they are posting, then I can comment on it. As another history note STK also had some media problmes with 9840's when a batch from Imation was bad but it was taken care of. There was also a problem with 9840c drives reading 9840a media but that was a drive issue that was fixed. Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Wednesday, March 24, 2010 9:55 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape No, I haven't seen a tape failure yet. Except way back when we had a 3490 cartridge smashed and broken in places and the tape was hanging out of it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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
Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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: Mainframe Executive article on the death of tape
Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. As to tape reliability, I can remember DR drills from long ago where a bad or lost tape was almost a sure bet. Although it was only one out of hundreds (less then 1%), it was critical and caused serious delays. So, from that perspective, the failure rate of the tape -solution- was upwards of 90%. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. My $0.02. YMMV. It depends. In some cases. IMHO. IMNSHO. (Please sprinkle in the above to suit.) -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, March 24, 2010 8:06 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape ..snip It's still the cheapest backup media. ..snip NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Any tools for managing z/OS system software products inventory?
Jeff Holst wrote: Contracts - proves it's legal, but not that it's used. Libraries - proves it's there, but not that it's used. Easy - Use a Security package, RACF for example to do the proving. Lock up those datasets with profiles and wait for the first cry from someone... You can move the load modules into a new linklist or Lpalib and see what happens. Of course this area is full of tank landmines ... ;-D Same for proclibs, move the members somewhere and wait for a JCL error. Here you will get some limpetmines ... ;-D For 'illegal' compilers, you can lockup the modules in RACF with a profile in PROGRAM class. Hopefully you will get complaints in office hours only... Anyway, software license management is already explosive enough... Groete / Greetings Elardus Engelbrecht -- 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: Mainframe Executive article on the death of tape
From: Spencer, Mike mike_spen...@bmc.com Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. http://chalfant.wordpress.com/ He cites Gartner and Storage Magazine as the sources for his statistics. -- 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: Deactivate/inactivate LPAR DEV cause TCPIP PROD hang
Try configuring the OSA adapter off line to the test LPAR before deactivation. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mohd Shahrifuddin Sent: Tuesday, March 23, 2010 6:20 PM To: IBM-MAIN@bama.ua.edu Subject: Deactivate/inactivate LPAR DEV cause TCPIP PROD hang Dear All, Operating System OS390 2.10 machine type 9672-R16 define 2 LPAR one production and one development Share OSA card different IP address During Deactivation and Activation the development system and IPL we found the TCPIP in Production is hang. No connection between our production system and our Unix system. The problem no message in SYSLOG, TCPIP address space or Unix system. Please help if anybody have same problem before. Thanks and appreciated so much. Mohd Shahrifuddin ShenZhen, China NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Deactivate/inactivate LPAR DEV cause TCPIP PROD hang
Which LPAR owns the OSA card. I have all of the cards owned/managed by the production system and have not experienced any IP hangs. Pat Mihalec Rush University Medical Center Senior System Programmer (312) 942-8386 pat_miha...@rush.edu P Please consider the environment before printing this email. From: Hal Merritt hmerr...@jackhenry.com To: IBM-MAIN@bama.ua.edu Date: 03/24/2010 09:35 AM Subject: Re: Deactivate/inactivate LPAR DEV cause TCPIP PROD hang Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Try configuring the OSA adapter off line to the test LPAR before deactivation. HTH -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mohd Shahrifuddin Sent: Tuesday, March 23, 2010 6:20 PM To: IBM-MAIN@bama.ua.edu Subject: Deactivate/inactivate LPAR DEV cause TCPIP PROD hang Dear All, Operating System OS390 2.10 machine type 9672-R16 define 2 LPAR one production and one development Share OSA card different IP address During Deactivation and Activation the development system and IPL we found the TCPIP in Production is hang. No connection between our production system and our Unix system. The problem no message in SYSLOG, TCPIP address space or Unix system. Please help if anybody have same problem before. Thanks and appreciated so much. Mohd Shahrifuddin ShenZhen, China NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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: link edit question
Supra Uche wrote: For example If i write the YBY402 twice it does not give any error in the TEST1 job. I want to get a jcl error if i write a record twice in TST1 member. I'm still not with you ... You don't get any error when writing a thing twice, but you want an error if you write it twice? Because there are thousands of lines in the TST1 member, some segments can be entered multiple times accidentaly. Copy all those lines and do a sort dropping the duplicates. Like this: //SELECT EXEC PGM=ICETOOL //TOOLMSG DD SYSOUT=* //DFSMSG DD SYSOUT=* //PRINT DD SYSOUT=* //IN DISP=SHR,DSN=??? //TOOLIN DD * SELECT FROM(INDD) TO(PRINT) ON(1,20,CH) NODUPS Groete / Greetings Elardus Engelbrecht -- 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: Mainframe Executive article on the death of tape
On Wed, 24 Mar 2010 07:33:46 -0700, daver wrote: http://chalfant.wordpress.com/ He lost me with the first sentence. When a star is born, the mass of the star determines how long it will live, ranging from millions of years to trillions of years. Considering that the universe is only about 15 billion years old, he has put us on notice that he really likes to exaggerate. -- Tom Marchant -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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: How to recatalog to a different master catalog?
Were you aware that the SMS control datasets do not need to be catalogued in the master catalog? Ours start with SYS3 and are in a user catalog. We've had it this way since z/OS 1.6(?) and have not had any problems. -- John McKown Systems Engineer IV How can you have an SHCDS that has a HLQ other than SYS1? The VARY SMS,SHCDS syntax uses an implicit HLQ of SYS1.DFPSHCDS. How can you use a different HLQ and get around this issue? -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Diane, Does anybody need to update this storage area? If this is read-only, you can obtain the storage in Key 0 for everyones reading enjoyment. Maybe the list of things that actually update this storage area is significantly smaller and therefore, changes can be made to them only?? Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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 -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 9:59 AM, GOODWIN, DIANE M. dgood...@amica.comwrote: I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. That won't work. You would not (in general) be able to access dataspace storage from applications programs. The real question is what functionality are you trying to provide/maintain? There is no simple way to avoid the STORAGE OBTAIN failure since you are obtaining common storage with a user key. If your application programs are directly accessing a key 9 common storage area, you won't be able to magically fix the problem without changing the programs that allocate or alter that data. However, any programs that only reference the data will not notice if you put it in a non-fetch protected system key area. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
There are a couple of programs that do update the area - I'm 95% they only run out of one region. But I need an area that can be referenced by an address and the accessed by all the regions. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Lubrano Sent: Wednesday, March 24, 2010 11:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Diane, Does anybody need to update this storage area? If this is read-only, you can obtain the storage in Key 0 for everyones reading enjoyment. Maybe the list of things that actually update this storage area is significantly smaller and therefore, changes can be made to them only?? Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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 -- For IBM-MAIN
LinkedIn Poll: Are you considering Linux on z?
If you have a LinkedIn account, please participate in my poll to determine Linux on z penetration. Feel free to comment here or on LinkedIn also. http://polls.linkedin.com/p/81429/kyqic Thanks Alan Harrison http://practicallysecure.blogspot.com -- 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: Mainframe Executive article on the death of tape
Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: Mainframe Executive article on the death of tape
I found the article useless. Especially having just completed another successful Disaster Recovery test using tape. Brought up both z/os and windows using the same tape media without a single error. Maybe he was referring to paper tape? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Pinnacle Sent: Tuesday, March 23, 2010 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe Executive article on the death of tape Anybody read the Mainframe Executive article on the death of tape as a backup media? The guy writing it used to work for STK and Sun, and now works for disk-based backup vendors. He says the following: - 15% of all backups fail (my experience 1%) - 10-50% of all restores from tape fail (my experience 1%) - 40-50% failure when restoring data from tape 5 years (my experience again is 1%) So what are you guys seeing out there? Do we really have mainframe tape failure rates in the double-digits percentwise? If we do, then the guy is right and tape is dead, but I just don't buy those figures. What say you? Regards, Tom Conley -- 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: Mainframe Executive article on the death of tape
I had a tape error just last week. Tapes and drives are about 5 years old. 10079 08:52:11.45 STC06292 0080 IOS000I 0121,2C,IOE,01,0600,,**,A00298,EXHPDM 504 504 0080 0A4410D050405050 0001FF00 030C003117335490 4B04E8205C5B2011 504 0080 WRITE ERROR DETECTED Cliff McNeill Good memory on the 3480 media. Many, many years ago, BASF had a problem with 3480 Tape Media cartridges. The company that I worked for at that time received a large batch of bad tapes in a shipment, causing us quite a few headaches. This was back around 1997/1998. Since then, I've used cartridge media of all densities and vendors, without experiencing any significant problems. Mike Spencer snip I haven't seen a bona-fide tape I/O error since my shop installed 3480 drives, lo these many years ago. What's this guy smoking? Whatever it is, I'm sure it's illegal! :-) Rick _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/210850553/direct/01/ -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Hi To use the Data Space the program that creates it (the owner) will get an ALET back from the create. You need to save this in common storage (now key 7 or below). All the applications can read the common but you are going to need an authorized application to write to it. Then when a program wants to access shared data in the data space you will need to load the address of the data into a register , then load the ALET of the dataspace into the AR for that register (say R2 and AR2). Then SAC 512 to turn on AR mode. Now the program can access the data just as it was in private. I few things I have run into is 1.) Clear all the AR's before you SAC, 2.) When issuing EXEC CICS commands always clear and re-load your access registers after CICS returns to you. If there is anything specific I can help with let me know. Kevin Cogley On Mar 24, 2010, at 9:59 AM, GOODWIN, DIANE M. wrote: I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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 Kevin Cogley kcog...@pobox.com -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
So is my problem the subpool or the key 9? This is one thing that I'm unclear about. The area has to be obtained and then altered from one region. This region I do have a lot of the control of the programs in it. Then the area needs to be able to be referenced by a pass address for read only purposes. Any ideas on how you might handle something like this? Diane -Original Message- That won't work. You would not (in general) be able to access dataspace storage from applications programs. The real question is what functionality are you trying to provide/maintain? There is no simple way to avoid the STORAGE OBTAIN failure since you are obtaining common storage with a user key. If your application programs are directly accessing a key 9 common storage area, you won't be able to magically fix the problem without changing the programs that allocate or alter that data. However, any programs that only reference the data will not notice if you put it in a non-fetch protected system key area. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 3:20 PM, GOODWIN, DIANE M. dgood...@amica.comwrote: There are a couple of programs that do update the area - I'm 95% they only run out of one region. But I need an area that can be referenced by an address and the accessed by all the regions. Diane Are programs accessing the memory directly? Or though an in-house API or program? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Lubrano Sent: Wednesday, March 24, 2010 11:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Diane, Does anybody need to update this storage area? If this is read-only, you can obtain the storage in Key 0 for everyones reading enjoyment. Maybe the list of things that actually update this storage area is significantly smaller and therefore, changes can be made to them only?? Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm I was just going through the book on what and how dataspaces work. The other issue is that we save the address of this shared storage in a common area. Then all application programs have the address in common, will load it to a register in order to access the shared information (we have a copy member with all the fields). I wasn't clear on how I could do this with the dataspace. I have to be able to just pass the address to the application programs. We have way to many to try to change. Diane -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 10:40 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote: Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Hi Diane, This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? Regards, Sam Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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
Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
This may not fit the bill for you, but have you considered using a SCOPE=COMMON dataspace? I would strongly recommend against using a user key SCOPE=COMMON data space. It would have a security exposure which is similar to user key CSA. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Directly - because the address of the area is passed. So we just do a L R15,address and the programs are good to go -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 11:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Are programs accessing the memory directly? Or though an in-house API or program? -- 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: Link edit question
On Wed, 24 Mar 2010 09:01:46 -0500, Hal Merritt wrote: I'm not familiar with the INCLUDE SEGMENT statement, so I could be totally wrong. Have you INCLUDEd only sequential data sets, never PDS members? The Binder (linkage editor) does not replace CSECT's unless specifically told to do so. You can code DELETE statements to cause the binder to do that. DELETE Isn't that REPLACE? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Supra Uche Sent: Wednesday, March 24, 2010 3:58 AM INCLUDE SEGMENT(pgmname) statements in the member that we use to compile -- gil -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
Diane, Based on the below code snip segment, your installation has a magic SVC to get into SUP STATE KEY 0. which is also an integrity exposure, but that is another topic. If the code that acquires the code is able to get into SUP STATE KEY 0 to do the STORAGE OBTAIN, simply get the storage in KEY 0, and change the updating code to get into sup state around the updates. Subpool 241 is non-fetch protected, which means that any key can reference the storage, so as has been mentioned, readers won't care a bit, just the updating programs need to be modified. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Diane Goodwin dgood...@amica.com To: IBM-MAIN@bama.ua.edu Date: 03/24/2010 09:18 AM Subject: Trying to understand ALLOWUSERKEYCSA and subpool storage Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Please bear with me. I'm primarily a CICS system programmer. I posted something similar to the CICS List but now I really need to understand it from the z/OS or MVS side of things. We have multiple CICS regions (address spaces) in an LPAR and they all currently share a piece of MVS storage. This area holds common information that all regions access. Only 2 regions actually update the information - all the others just read. Our program acquired the area using the following: LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE The new default of ALLOWUSERKEYCSA of NO of course makes this fail. We did set it to YES since this is necessary for our CICS to run. However, I've been given the task to see if we can have a shared area and run with the default of NO. Subpool 241 is CSA, system, not fetch proteced, pageable storage. The closest I can find is 228 - which is CSA, system, not fetch protected but FIXED. However, will that still cause me issues since it is CSA? What about subpool 226 - says it is SQA, system, not fetch protected but FIXED? Might I be able to use that? The size of this area is not that large - 20,480 bytes. I'd be grateful for any light and wisdom you can shed on this subject for me. thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
On Wed, 24 Mar 2010 11:25:28 -0400, GOODWIN, DIANE M. wrote: So is my problem the subpool or the key 9? This is one thing that I'm unclear about. The problem is that you are trying to allocate user key common storage. For your purposes, you need it to be common, but you need to get it with a system key. The integrity problem that was closed has to do with the area being modified by unauthorized programs. You want your applications to be able to read the data, but not change it. The solution is to obtain storage from a CSA subpool that is not fetch protected and in storage protect key 0. The program that needs to alter it will have to be authorized so that it can alter the key zero storage. All of the other programs will be able to read it. -- Tom Marchant -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Diane, Yes, when ALLOWUSERKEYCSA(NO) is specified, all CSA allocations must be made in key 0-7. Otherwise, you abend with an SB78 or SB0A RSN=5C. Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm So is my problem the subpool or the key 9? This is one thing that I'm unclear about. The area has to be obtained and then altered from one region. This region I do have a lot of the control of the programs in it. Then the area needs to be able to be referenced by a pass address for read only purposes. Any ideas on how you might handle something like this? Diane -Original Message- That won't work. You would not (in general) be able to access dataspace storage from applications programs. The real question is what functionality are you trying to provide/maintain? There is no simple way to avoid the STORAGE OBTAIN failure since you are obtaining common storage with a user key. If your application programs are directly accessing a key 9 common storage area, you won't be able to magically fix the problem without changing the programs that allocate or alter that data. However, any programs that only reference the data will not notice if you put it in a non-fetch protected system key area. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
So I really just need to change the key? I can still use the same subpool? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Lubrano Sent: Wednesday, March 24, 2010 11:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Diane, Yes, when ALLOWUSERKEYCSA(NO) is specified, all CSA allocations must be made in key 0-7. Otherwise, you abend with an SB78 or SB0A RSN=5C. Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm So is my problem the subpool or the key 9? This is one thing that I'm unclear about. The area has to be obtained and then altered from one region. This region I do have a lot of the control of the programs in it. Then the area needs to be able to be referenced by a pass address for read only purposes. Any ideas on how you might handle something like this? Diane -Original Message- That won't work. You would not (in general) be able to access dataspace storage from applications programs. The real question is what functionality are you trying to provide/maintain? There is no simple way to avoid the STORAGE OBTAIN failure since you are obtaining common storage with a user key. If your application programs are directly accessing a key 9 common storage area, you won't be able to magically fix the problem without changing the programs that allocate or alter that data. However, any programs that only reference the data will not notice if you put it in a non-fetch protected system key area. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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 -- 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 Tivoli Asset Discovery for z/OS
I've been following the thread on tools for managing z/OS system software products inventory? Lots of good reasons (many I can relate to) that explain why our simple s/w lists are in error. Or as I like to say, to the best of our knowledge, they're accurate until the next error is found. So, what about IBM's Tivoli Asset Discovery for z/OS; any users out there with first-hand experience? ... Bill -- 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: Mainframe Executive article on the death of tape
Thanks, I am looking at the article now and will comment on specifics later. Randy and I go way back even prior to STK days, so I know him well and he is a friend. A quick review of the article (detailed review later), it is obvious to me that Randy is speaking about Open Systems Backup. While at STK both he and I would see a large number of customers go for the cheapest option available and then wonder why they had troubles. Another telling point in the article is he is speaking about streams to tape to gain operational improvements (performance), while this will make backups run much quicker they will make restores more painful (slower). It is these points that make me believe that the article is Open Systems focused. I will go through the artile later today in greater detail Carl Swanson carl.swans...@verizon.net Mobile: 215.688.1459 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of daver++ Sent: Wednesday, March 24, 2010 10:34 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape From: Spencer, Mike mike_spen...@bmc.com Randy Chalfant was the author. Sorry, but my electronic copy is gone. I looked it up in my hardcopy on my desk. http://chalfant.wordpress.com/ He cites Gartner and Storage Magazine as the sources for his statistics. -- 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: Mainframe Executive article on the death of tape
No assumptions. This is all experience/observations from several iterations of DR plans and differing management objectives. In many (most?) tape solutions (to include ATL), tapes are physically ejected, manually boxed, manually transported (via PTAM), manually stored, manually retrieved, manually received and inventoried, and manually reloaded into the ATL. That's a lot of human interventions. The ATL in the DR center is not capable of mounting a tape from a shipping box. A human has to load the tapes into the ATL. True, an ATL in the DR center could be used as offsite backup. And that reduces the MTR somewhat by eliminating the PTAM step in the recovery script. But you still have to get the tape to the DR site. Since our subspace transporter is on backorder, we have to transport tapes by truck. Your point contrasting backup and replication is well taken. However, in a DR context, a 'backup' is just as critical as primary data and should be replicated. You are also correct in that I may not have used the acronyms correctly. But you got the ideas. I should also point out a new idea: networked VTS. The IBM TS7740 (and I'm sure some others) has the ability to be networked with other TS7740's to automatically replicate virtual tapes. Unlike the DASD XRC/PPRC solutions, the network pipe can be sized on average loads and be a bit smaller (less expensive). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, March 24, 2010 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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 NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please
Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
If you have key 8 storage in CSA, then any address space, not just the CICS regions can access and update that storage. Having no control over who has access to that storage should be viewed as a potential Reliability, Availability, and Security (RAS) issue. By changing the default for ALLOWUSERKEYCSA to NO, IBM is forcing users to intentionally change the setting to allow key 8 (i.e., uncontrolled access) storage in CSA. In order to exchange data between address spaces with some type of access control is likely to require significant changes to those applications. If you want to continue to exchange data without access control, you might as well use your current method and change ALLOWUSERKEYCSA back to YES. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Diane Goodwin Sent: Wednesday, March 24, 2010 10:23 AM To: IBM-MAIN@bama.ua.edu Subject: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Hello, Please bear with me. I'm normally a CICS System programmer. We all know the default setting for ALLOWUSERKEYCSA was changed to NO from yes. This causes a problem for our CICS regions (address spaces). We have a storage area that we obtain at the first CICS address space start up. The area is referenced by all CICS regions - but only a couple do any actual updating. The code we use for this is -- LAR1,SVCSAVE HOLD AREA FOR SVC 255 SVC 255 GET INTO SUP. STATE WITH KEY 0 STORAGE OBTAIN,LENGTH=20480,SP=241,KEY=9 STR1,MVSCSADR STORE AREA ADDR. IN CSAEXT ICR11,=X'80' SPKA 0(R11) CHANGE TO KEY 8 CICS MODESET MODE=PROB SWITCH TO PROBLEM STATE It appears to fail on the STORAGE OBTAIN when we tried using the default setting. We have since changed it to YES I get to figure out the best way to change this because higher-ups want us to be able to run with the default. Subpool 241 is common csa, not fetch protected, pageable and system owned. I cannot find a subpool that is common, not fetched protected, pageable and system owned. I found a couple that are FIXED type. Since this area is not that large (20,480 bytes) I was thinking I could just use one of these. Subpool 228 also says it is common CSA - I figure that will still cause a problem with the ALLOWUSERKEYCSA parm. There's a subpool 226 that says it is common SQA, not fetched protected, system owned but is FIXED Do you think that might work? Or do you have any suggestions as to the best way to have an area available to multiple CICS address spaces, that is system owned, can be updatable by only a couple of regions? Any insight or suggestions would be greatly appreciated. Thanks in advance for your time, Diane Goodwin IT Systems Programmer Amica Insurance Company -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 3:35 PM, GOODWIN, DIANE M. dgood...@amica.comwrote: Directly - because the address of the area is passed. So we just do a L R15,address and the programs are good to go In that case, using a data space will be difficult as it requires setting up access registers and switch to AR mode. Probably more changes than you want to make in all of the application code that uses the data. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Sam Siegel Sent: Wednesday, March 24, 2010 11:27 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Are programs accessing the memory directly? Or though an in-house API or program? -- 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: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm
Diane, Yes, SP=241,KEY=0 is possible... You can check the z/OS Diagnosis Reference for the various storage subpools and their characteristics. As long as you don't select a fetch protected key 0 CSA subpool, you can access key 0 storage from any other key... however, you must be in key 0 to modify the storage. Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:53 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm So I really just need to change the key? I can still use the same subpool? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Lubrano Sent: Wednesday, March 24, 2010 11:50 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm Diane, Yes, when ALLOWUSERKEYCSA(NO) is specified, all CSA allocations must be made in key 0-7. Otherwise, you abend with an SB78 or SB0A RSN=5C. Tony Lubrano Product Author NEON Enterprise Software, LLC. p: 281 207 4922 f: 281 207 4973 tony.lubr...@neon.com What is zPrime? Find out at www.zprime.com or just ask us! -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of GOODWIN, DIANE M. Sent: Wednesday, March 24, 2010 10:25 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Need to find alternative to shared storage because of ALLOWUSERKEYCSA parm So is my problem the subpool or the key 9? This is one thing that I'm unclear about. The area has to be obtained and then altered from one region. This region I do have a lot of the control of the programs in it. Then the area needs to be able to be referenced by a pass address for read only purposes. Any ideas on how you might handle something like this? Diane -Original Message- That won't work. You would not (in general) be able to access dataspace storage from applications programs. The real question is what functionality are you trying to provide/maintain? There is no simple way to avoid the STORAGE OBTAIN failure since you are obtaining common storage with a user key. If your application programs are directly accessing a key 9 common storage area, you won't be able to magically fix the problem without changing the programs that allocate or alter that data. However, any programs that only reference the data will not notice if you put it in a non-fetch protected system key area. -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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 -- 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
VSAM index trap
In reviewing our health checks the VSAM index trap was set to inactive. I found the VSAM index trap feature is turned off on our system. Looking to use as many health checker checks as possible I'd like to turn this feature on and activate the check. In checking the ibm-main archives there was a thread on this check back in 2007, nothing since. Any system issues turning the VSAM index trap on? Any vsam performance problems? Thanks Matt -- 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: Mainframe Executive article on the death of tape
On Wed, 24 Mar 2010 09:58:46 -0500, Tom Marchant wrote: On Wed, 24 Mar 2010 07:33:46 -0700, daver wrote: http://chalfant.wordpress.com/ He lost me with the first sentence. When a star is born, the mass of the star determines how long it will live, ranging from millions of years to trillions of years. Considering that the universe is only about 15 billion years old, he has put us on notice that he really likes to exaggerate. Can you say extrapolate? A Google search for stellar lifetime finds articles estimating the upper bound for the lifetime of a low-mass star up to 100 trillion years. I deem Chalfant's science good; his showmanship Saganesque. -- gil -- 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: Mainframe Executive article on the death of tape
It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). - Too busy driving to stop for gas! -- 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: Mainframe Executive article on the death of tape
On 24 March 2010 04:25, Vernooij, CP - SPLXM kees.vern...@klm.com wrote: It's not what this guy is smoking, but what he is eating. We have a saying in Dutch: who's bread one eats, who's word one speaks (I hope I have the genetives correct). That would be whose; who's is a contraction of who is or who has. He clearly speaks the word of the company that feeds him. I think the closest common English expression would be He who pays the piper calls the tune. Tony H. -- 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: Mainframe Executive article on the death of tape
Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Automatic tape libraries. Virtual tape. Where's the human interaction? Also, when I said backup, I did not mean apps copying single files, but the kind done for storage admin. Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. No they don't. We had a GDPS solution, at each site their was a duplicate library from the the other. No pickup trucks involved. This can push a MTR* out to a couple of days. Disaster recovery MTR is more dependent on procedures on how your backup/restore decisions are made, rather than whether or not it's tape. The more live (nearly live) data/systems you have, the smaller the MTR. A duplicate library, while adding cost, can go a long way in that direction. DR is an insurance policy. The bigger the premium, the bigger the dividend (if I may mix a metaphore). - Too busy driving to stop for gas! -- 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: Mainframe Executive article on the death of tape
On 24 Mar 2010 09:26:58 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). Some critical small files get backed up as soon as they are created, often moved off-site.But more and more these days those are handled via FTP instead of tape. -- 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: z/os V1.11 PFAPATH
We did almost exactly the same thing. Symbolic link at /pfa that points to $SYSNAME/pfa. That is backed by its own zfs, OMVS.sysname.PFA. I would be a little hesitant to put it in root in case it fills up, as it is sort of a repository type thing. Then again, I don't claim to be a Unix Systems Services Guru. (Note: Did not use USS!) FYI, we got a lot of false alarms on frames and slots usage, so I increased the check to STDDEV(7). I also changed the /usr/lpp/bcp/AIRSHREP.sh to have the following two lines at the beginning: cd /$SYSNAME/pfa echo $PWD That way, as I ran this job across the lpars, it created the appropriate directories. Mary Anne -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than allowing authorized code to GETMAIN Key 8 CSA. Brian On Wed, 24 Mar 2010 10:45:22 -0500, Wayne Driscoll wrote: Diane, Based on the below code snip segment, your installation has a magic SVC to get into SUP STATE KEY 0. which is also an integrity exposure, but that is another topic. -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
On Wed, Mar 24, 2010 at 11:56 AM, Brian Peterson brian.peterson.ibm.m...@comcast.net wrote: In my opinion, a magic SVC is a MUCH WORSE integrity exposure than allowing authorized code to GETMAIN Key 8 CSA. Indeed! -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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: Mainframe Executive article on the death of tape
We do a lot of performance and capacity studies for customers. We used to only accept SMF/RMF data on tapes. Once we setup to allow customers to FTP data to us the use of tapes fell off. At the peak I received over 500 tapes in one year. Last I received 98 tapes, all the rest were FTP. On Wed, Mar 24, 2010 at 12:45 PM, Howard Brazee howard.bra...@cusys.eduwrote: On 24 Mar 2010 09:26:58 -0700, eamacn...@yahoo.ca (Ted MacNEIL) wrote: It's still the cheapest backup media. I depends. Media itself is the cheapest one, but for small amounts of data total cost of the solution may not be the cheapest. Good tape drives are expensive. Who backs up small amounts of data at a time? When I said backup, I didn't mean users copying production fileds; I meant real backups run by storage admin types (human or automatic). Some critical small files get backed up as soon as they are created, often moved off-site.But more and more these days those are handled via FTP instead of tape. -- 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 Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Brian Peterson Sent: Wednesday, March 24, 2010 11:57 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Trying to understand ALLOWUSERKEYCSA and subpool storage In my opinion, a magic SVC is a MUCH WORSE integrity exposure than allowing authorized code to GETMAIN Key 8 CSA. Brian On Wed, 24 Mar 2010 10:45:22 -0500, Wayne Driscoll wrote: Diane, Based on the below code snip segment, your installation has a magic SVC to get into SUP STATE KEY 0. which is also an integrity exposure, but that is another topic. -- Suppose your magic SVC does nothing unless the caller is APF authorized? -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Williamson, James R -Original Message- From: IBM Mainframe Discussion List On Behalf Of Brian Peterson In my opinion, a magic SVC is a MUCH WORSE integrity exposure than allowing authorized code to GETMAIN Key 8 CSA. Brian On Wed, 24 Mar 2010 10:45:22 -0500, Wayne Driscoll wrote: Diane, Based on the below code snip segment, your installation has a magic SVC to get into SUP STATE KEY 0. which is also an integrity exposure, but that is another topic. -- Suppose your magic SVC does nothing unless the caller is APF authorized? In that case it wouldn't be sufficiently magic for use within CICS, which runs unauthorized. -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
Re: Trying to understand ALLOWUSERKEYCSA and subpool storage
Suppose your magic SVC does nothing unless the caller is APF authorized? In that case it wouldn't be sufficiently magic for use within CICS, which runs unauthorized. true. And what would be the point of a magic svc for an authorized caller anyway? They could just as easily use MODESET -- This email might be from the artist formerly known as CC (or not) You be the judge. -- 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
AMATERSE: AMA574I. Wrong message?
Hi, I have recieved some TERSED SMF records and am unable to UNPACK them. Without specifying DCB attributes for the output, the error message I get is: AMA574I RECORD FOUND IS LONGER THAN THE LRECL AMA555I THE VALUES ARE: BLKSIZE= 8760LRECL=8756PACKTYPE=PACK From System Messages: Explanation: For the UNPACK operation, the length of the record restored is longer than the record length of the output data set. Trying to overcome the error and assuming the LRECL=8756 is erroneous, I have specified LRECL=32767 for the output data set (SYSUT2), but still get the same error: AMA544I OUTPUT LRECL IS: 32756 ORIGINAL LRECL IS: 8756 AMA574I RECORD FOUND IS LONGER THAN THE LRECL AMA555I THE VALUES ARE: BLKSIZE= 32760 LRECL=32756 PACKTYPE=PACK I think AMATERSE is giving me the wrong error message, as it is not possible that it actually found a record longer than 32,756 (RECFM is VB, not spanned). Or am I missing something? Has anybody experienced such error when trying to UNPACK SMF data? Thanks, Yifat Oren -- 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: AMATERSE: AMA574I. Wrong message?
Did they possibly terse the data from a tape? On Wed, Mar 24, 2010 at 1:32 PM, Yifat Oren yi...@tmachine.com wrote: Hi, I have recieved some TERSED SMF records and am unable to UNPACK them. Without specifying DCB attributes for the output, the error message I get is: AMA574I RECORD FOUND IS LONGER THAN THE LRECL AMA555I THE VALUES ARE: BLKSIZE= 8760LRECL=8756PACKTYPE=PACK From System Messages: Explanation: For the UNPACK operation, the length of the record restored is longer than the record length of the output data set. Trying to overcome the error and assuming the LRECL=8756 is erroneous, I have specified LRECL=32767 for the output data set (SYSUT2), but still get the same error: AMA544I OUTPUT LRECL IS: 32756 ORIGINAL LRECL IS: 8756 AMA574I RECORD FOUND IS LONGER THAN THE LRECL AMA555I THE VALUES ARE: BLKSIZE= 32760 LRECL=32756 PACKTYPE=PACK I think AMATERSE is giving me the wrong error message, as it is not possible that it actually found a record longer than 32,756 (RECFM is VB, not spanned). Or am I missing something? Has anybody experienced such error when trying to UNPACK SMF data? Thanks, Yifat Oren -- 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 Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- 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
SMF Question
We have z/OS 1.11 running on our DEVL system. We shut the system down using the same scripts that are used on the z/OS 1.9 system. We have something really unusual happening. In a D A,L there is nothing running. ACF2 is down, JES2 is down, OMVS filesystem and inits have been shutdown - everything is down. Something is trying to do a SAF call. We are getting ACF92CCC messages telling us security isn't available to reply u c or w. We think whatever it is is trying to write a record to the SMF datasets. Has anyone ever run across this before? Thank you, Mary Global IT Services Information Services Desk: 703-206-4201 -- 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: Mainframe Executive article on the death of tape
Hal, You talk about the cost of tape handling being high, and use that to justify remote disk??? Have you any idea what the true cost of remote disk is? The fiber bandwidth cost alone far outweighs the cost of tape handling for most smaller shops. Radoslaw was talking about remote tape. Some sites have a remote tape library that they can backup into, this eliminates almost all tape handling, and normally has lower bandwidth costs than remote disk. Hal Merritt hmerr...@jackhenry.com 3/24/2010 11:57 AM No assumptions. This is all experience/observations from several iterations of DR plans and differing management objectives. In many (most?) tape solutions (to include ATL), tapes are physically ejected, manually boxed, manually transported (via PTAM), manually stored, manually retrieved, manually received and inventoried, and manually reloaded into the ATL. That's a lot of human interventions. The ATL in the DR center is not capable of mounting a tape from a shipping box. A human has to load the tapes into the ATL. True, an ATL in the DR center could be used as offsite backup. And that reduces the MTR somewhat by eliminating the PTAM step in the recovery script. But you still have to get the tape to the DR site. Since our subspace transporter is on backorder, we have to transport tapes by truck. Your point contrasting backup and replication is well taken. However, in a DR context, a 'backup' is just as critical as primary data and should be replicated. You are also correct in that I may not have used the acronyms correctly. But you got the ideas. I should also point out a new idea: networked VTS. The IBM TS7740 (and I'm sure some others) has the ability to be networked with other TS7740's to automatically replicate virtual tapes. Unlike the DASD XRC/PPRC solutions, the network pipe can be sized on average loads and be a bit smaller (less expensive). -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, March 24, 2010 10:22 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe Executive article on the death of tape Hal Merritt pisze: Perhaps if you look only at the media proper, but perhaps not if you look at the TCO*. A tape based solution almost invariably includes many humans and physical activities in the process. That's expansive. Darned expensive. And slow. Very slow. Bad assumptions. No human interventions are necessary. Have you seen about ATL? Autmated Tape Library? Worse, in a DR scenario physical tapes are S-L-O-W because they have to be transported via PTAM* from the storage site to the DR site. This can push a MTR* out to a couple of days. Again, BAD ASSUMPTION. No need to PTAM. ATL can reside in DR datacentre. The second one. Forgive me malice: how fast are non-tape media when transported via PTAM? Are the disk any faster during transportation? These days, one can link a couple of DS8100's and have critical data redundancy for a very competitive TCO. Depending on your specific situation, you could set a realistic MTR objective of an hour or so. Don't confuse backup and replication. Even three-site solution does not protect you form human or application error. Mistakenly deleted dataset is deleted in both primary and secondary site. PiT copy is the solution but quite expensive for medium and large amounts of data. *TCO = Total Cost of Ownership. The total bottom line dollars involved. *PTAM = Pickup Truck Access Method. Physically moving a tape cartridge from site A to site B. (From an IBM Redbook on the subject.) *MTR = Mean Time to Recovery. The total clock time from the point where normal processing ends to the point where normal processing resumes as if nothing happened. MTR usually means time to REPAIR. Your descriptions regards RTO - Recovery Time Objective (Recovery Point Objective, Recovery Time Objective - crucial parameters for any DR and backup plans). Of course this is acronym, and by definition can be overloaded (have different meanings). I presented popular ones in this context. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- 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: SMF Question
System REXX termination? If you can't identify via manual means, try a SAF TRACE or SAD. snip We have z/OS 1.11 running on our DEVL system. We shut the system down using the same scripts that are used on the z/OS 1.9 system. We have something really unusual happening. In a D A,L there is nothing running. ACF2 is down, JES2 is down, OMVS filesystem and inits have been shutdown - everything is down. Something is trying to do a SAF call. We are getting ACF92CCC messages telling us security isn't available to reply u c or w. We think whatever it is is trying to write a record to the SMF datasets. /snip -- 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: SMF Question
snip Something is trying to do a SAF call. /snip MVS is still up and doing things after you do your 'shutdown', eg your D A command worked, etc. To stop MVS, do a QUIESCE, after it's 'down' and removed from whatever Jack Kelly 202-502-2390 (Office) From: Mary Elwood mary_elw...@navyfederal.org To: IBM-MAIN@bama.ua.edu Date: 03/24/2010 01:35 PM Subject: SMF Question Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu We have z/OS 1.11 running on our DEVL system. We shut the system down using the same scripts that are used on the z/OS 1.9 system. We have something really unusual happening. In a D A,L there is nothing running. ACF2 is down, JES2 is down, OMVS filesystem and inits have been shutdown - everything is down. Something is trying to do a SAF call. We are getting ACF92CCC messages telling us security isn't available to reply u c or w. We think whatever it is is trying to write a record to the SMF datasets. Has anyone ever run across this before? Thank you, Mary Global IT Services Information Services Desk: 703-206-4201 -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
Agreed. For that reason I usually call them rape SVCs. I certainly wouldn't publish that I had one, and show everyone what the number is. Brian Peterson brian.peterson.ibm.m...@comcast.net 3/24/2010 12:56 PM In my opinion, a magic SVC is a MUCH WORSE integrity exposure than allowing authorized code to GETMAIN Key 8 CSA. Brian On Wed, 24 Mar 2010 10:45:22 -0500, Wayne Driscoll wrote: Diane, Based on the below code snip segment, your installation has a magic SVC to get into SUP STATE KEY 0. which is also an integrity exposure, but that is another topic. -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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: SMF Question
If your shutdown process issues a Z EOD command, that may be the source of the SAF call. MVS will automatically switch to a different SMF dataset (i.e. issue OPEN) and that may cause a SAF call. Try removing the Z EOD from your shutdown process and see if the problem goes away. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mary Elwood Sent: Wednesday, March 24, 2010 10:35 To: IBM-MAIN@bama.ua.edu Subject: SMF Question We have z/OS 1.11 running on our DEVL system. We shut the system down using the same scripts that are used on the z/OS 1.9 system. We have something really unusual happening. In a D A,L there is nothing running. ACF2 is down, JES2 is down, OMVS filesystem and inits have been shutdown - everything is down. Something is trying to do a SAF call. We are getting ACF92CCC messages telling us security isn't available to reply u c or w. We think whatever it is is trying to write a record to the SMF datasets. Has anyone ever run across this before? Thank you, Mary Global IT Services Information Services Desk: 703-206-4201 -- 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: Trying to understand ALLOWUSERKEYCSA and subpool storage
Then what is the point? Williamson, James R james.r.william...@uscg.mil 3/24/2010 1:01 PM ( mailto:james.r.william...@uscg.mil ) Suppose your magic SVC does nothing unless the caller is APF authorized? -- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- 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
