Doyle Banks/Mainline is out until 04/07/2008.
I will be out of the office starting 03/27/2008 and will not return until 04/07/2008. If you need immediate assistance, please contact Jim Cudworth (1-630-371-4911) or [EMAIL PROTECTED]) or Sheila Bratton (1-317-443-2142, [EMAIL PROTECTED]). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Clock Change
I'm almost ashamed to raise it, but my excuse is that I'm new to the box. Is my Z9BC going to change the clock automatically on me? No ETR. The way I read the HMC manual, it will automatically update for Time Zone changes on the HMC, then at 11:00 pm on Sunday it will re-synchronise with the TOD clock. Meanwhile I have IPL'ed with an hour offset, so Monday morning is going to come an hour earlier than it oughta. Do I have to add manually add one minute to the HMC clock to disable this surprising feature? (Well, it's gonna surprise the Operators). A reply before the event would be appreciated, my reseller couldn't manage it. Dave * This email is intended solely for the use of the individual to whom it is addressed and may contain confidential and/or privileged material. Any views or opinions presented are solely those of the author and do not necessarily represent those of AGCO. If you are not the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. Neither AGCO nor the sender accepts any responsibility for viruses and it is your responsibility to scan and virus check the e-mail and its attachment(s) (if any). * AGCO Limited, a limited company, registered in England (registered no.509133) with its registered office at Abbey Park Stoneleigh, Kenilworth CV8 2TQ, England. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
I keep my z9BC's HMC on GMT all the time (I would probably do that even if I was in New Zealand or Australia, regardless of being in the UK). I don't recall it adjusting time last March or last October, but then I probably wasn't paying particular attention anyway. I don't IPL for time changes any more, I just use a Netview timer event (or even the ops) to issue a SET TIMEZONE=E.01.00 to change to BST in March and a SET RESET to go back to GMT in October. If we have to IPL for some reason, we just manually issue the appropriate command if necessary, but I've almost finished a Netview startup Rexx exec to determine if it should be BST or not and absolve us of that particular chore as well. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
I like the sound of that, but have a question. Do you not have any DB's affected by slamming back an hour instead of shutting down for one hour and then doing an IPL? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/28/2008 07:00:20 AM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: [EMAIL PROTECTED] Subject: Re: Clock Change --- I keep my z9BC's HMC on GMT all the time (I would probably do that even if I was in New Zealand or Australia, regardless of being in the UK). I don't recall it adjusting time last March or last October, but then I probably wasn't paying particular attention anyway. I don't IPL for time changes any more, I just use a Netview timer event (or even the ops) to issue a SET TIMEZONE=E.01.00 to change to BST in March and a SET RESET to go back to GMT in October. If we have to IPL for some reason, we just manually issue the appropriate command if necessary, but I've almost finished a Netview startup Rexx exec to determine if it should be BST or not and absolve us of that particular chore as well. Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
We don't have any databases, no. It's several years now since I was at a DB2 shop but I think that it doesn't actually use timestamps on the logs anyway, it uses its own sequencing independent of a time source, if I remember correctly. To be honest, in this day and age, I'd have to question whether I wanted a db that would require a one-hour outage just because the clocks changed anyway, if you see what I mean. Our main problem is that most of our work runs overnight and on one particular LPAR is very tightly organised into scheduling 'windows'. Our OPC setup runs on local time - I'm not an OPC expert so I don't know off the top of my head if that can be changed, and never bothered enough to look it up - but what happens at when you jump forward an hour is that any jobs that should have been submitted in the interim will immediately be submitted, so there's the potential for additional resource contention, or maybe missed files if dependent files haven't been created yet. So we delay it a couple of hours on that LPAR, for when it's more convenient. There's a PCI compliance issue to consider as well, which I can't seem to get a sensible answer out of any of the auditors on, that states that all servers must be set to use similar time sources or kept reasonably synchronised with each other (for log comparisons etc). Brian - Email sent from www.virginmedia.com/email Virus-checked using McAfee(R) Software and scanned for spam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gary Hussong is out of the office.
Gary, What is a louts note text page? Regards, John Gary Hussong/CIMG/CVG@ CVGTo Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List [EMAIL PROTECTED] Subject .edu Gary Hussong is out of the office. 03/28/2008 12:25 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .edu I will be out of the office starting 03/28/2008 and will not return until 04/01/2008. I will respond to your message when I return. If this is an emergency you can try send me a louts note text page. -- NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
We have ANCIENT DB2. We use CA-Scheduler. We've always done the wait thing, thus my comments. As for coordinated time in the server world...we have 500 servers in the chicken farm and I doubt they are very aligned on the time. If we forget to pop SMTP it messes one of them up. Thanks. (Omitted last Clock Change text for brevity). Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gary Hussong is out of the office.
Lout - one considered large, slow, and cumbersome. Louts notes! Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 03/28/2008 07:27:20 AM: -- Information from the mail header --- Sender: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU Poster: John Kington [EMAIL PROTECTED] Subject: Re: Gary Hussong is out of the office. --- Gary, What is a louts note text page? Regards, John Gary Hussong/CIMG/CVG@ CVG To Sent by: IBM IBM-MAIN@bama.ua.edu Mainframe cc Discussion List [EMAIL PROTECTED] Subject .edu Gary Hussong is out of the office. 03/28/2008 12:25 AM Please respond to IBM Mainframe Discussion List [EMAIL PROTECTED] .edu I will be out of the office starting 03/28/2008 and will not return until 04/01/2008. I will respond to your message when I return. If this is an emergency you can try send me a louts note text page. -- NOTICE: The information contained in this electronic mail transmission is intended by Convergys Corporation for the use of the named individual or entity to which it is directed and may contain information that is privileged or otherwise confidential. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email or by telephone (collect), so that the sender's address records can be corrected. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
On Fri, 28 Mar 2008 11:00:20 +, [EMAIL PROTECTED] wrote: I keep my z9BC's HMC on GMT all the time (I would probably do that even if I was in New Zealand or Australia, regardless of being in the UK). I don't recall it adjusting time last March or last October, but then I probably wasn't paying particular attention anyway. Thanks Brian, you prompted me to investigate further. The HMC was set to Local and Europe/London. I changed it to UTC with Not Specified and the HMC rebooted OK. I hope it will now stay constant. Cheers Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enhanced PSP Compare Program
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Cyrus Goodriver wrote: A question for IBMers who posted on this subject: Why the nice feature of informing PARM=* to PSP tool to screen all target zones defined to the Global CSI has been dropped from the new version ? (it ends in error). Weird! It appears I received this same message exactly 7 hours and 40 minutes ago. Is there something going on with a mail and.or list server? Something's weird. I've seen whole threads arrive in reverse chronological order. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Enhanced PSP Compare Program
The chickens are restless. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Something's weird. I've seen whole threads arrive in reverse chronological order. Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Gary Hussong is out of the office.
My apologies for the pollution. I thought it was internal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of O'Brien, David W. You missed the point. The previous post to mine mentioned that's it's easier to say 'Sorry' than get permission. My post was meant to warn of the possible ramifications of taking that approach. If I tried to describe the change control approach at my former shop, you most likely would not believe it. Some jobs are not worth having. This was one of them. Sounds like commentary I've heard about the U.S. legal system: Truth and justice are irrelevant, so long as procedure is followed precisely. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
JES2 DD Concatenation issue
Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
On Thu, Mar 27, 2008 at 2:15 PM, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 03/26/2008 at 08:13 AM, Steve Comstock [EMAIL PROTECTED] said: I know the feeling. But we gotta' learn how to do the new stuff on the mainframe, and let management see it. First you have to get management's permission. -- IMO, you don't need permission to *learn* stuff. Implementing what you've learned is another matter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Check the DNSTYPE (PDS or PDSE), and check the DSCB information (LRECL and BLKSIZE). -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jacky Bright Sent: Friday, March 28, 2008 8:51 AM To: IBM-MAIN@bama.ua.edu Subject: JES2 DD Concatenation issue Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Jacky Bright wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. Once another job gets converted using the default concatenation JES2 should reopen the proclib datasets which will then find the new location of the dataset. -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. snippage Did the pointer get lost? Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EMC Dasd and Performance Issues
No, we share the frame with the mid range (Unix) side of the shop. However, we do not use the same disks in the box, Mainframe dasd is mapped on separate volumes from the Mid range dasd; I am told there is no intermingling... Lizette Not sure of our microcode level,.. But is your DMX used only for Mainframe storage? We had an instance where our P Series processors effected our mainframe storage performance. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Depending on your level of JES2 you may want to look at using PROCLIB statements in JES2 rather than coding DD statements. Or have the users start using JCLLIBs. Lizette In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. snippage -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
I am getting following erros in SYSLOG IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB JAcky On 3/28/08, Mark Jacobs [EMAIL PROTECTED] wrote: Jacky Bright wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIBare not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. Once another job gets converted using the default concatenation JES2 should reopen the proclib datasets which will then find the new location of the dataset. -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Jacky Bright wrote: I am getting following erros in SYSLOG IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB JAcky Is dataset SCLM1.PROCLIB actually on volume RBI031 after it was recreated? If it moved was the catalog entry changed to match its new location? On 3/28/08, Mark Jacobs [EMAIL PROTECTED] wrote: Jacky Bright wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIBare not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. Once another job gets converted using the default concatenation JES2 should reopen the proclib datasets which will then find the new location of the dataset. -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Try running any job with a /*JOBPARM PROCLIB=PROC13 in the jcl Alan Schwartz Infrastructure Management Sr Analyst -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jacky Bright Sent: Friday, March 28, 2008 8:43 AM To: IBM-MAIN@bama.ua.edu Subject: Re: JES2 DD Concatenation issue I am getting following erros in SYSLOG IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB JAcky On 3/28/08, Mark Jacobs [EMAIL PROTECTED] wrote: Jacky Bright wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIBare not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. Once another job gets converted using the default concatenation JES2 should reopen the proclib datasets which will then find the new location of the dataset. -- Mark Jacobs Time Customer Service Tampa, FL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
You need to open and close your JES2 concatention. Do you have a PROC00 and a PROC01 in your JES2 Proc? It could be any PROCxx number other than PROC00. If so, all you need to do is run the following JCL //JOB Card /*JOBPARM PROC=PROC?? -- Make the ?? whatever your Alternate PROC dd statement is in JES2 PROC. // EXEC PROC IEFBR14 (Do not need to exist) This will close PROC00 and open PROC??. Then the next Proc expansion will open PROC00 by default. Lizette I am getting following erros in SYSLOG IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
SCLM1.PROCLIB is on RBI035 but I want it on RBI031. Since it is SMS Managed how can I move it to RBI031. How can I change the Catalog Entry ? JAcky On 3/28/08, Mark Jacobs [EMAIL PROTECTED] wrote: Jacky Bright wrote: I am getting following erros in SYSLOG IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB JAcky Is dataset SCLM1.PROCLIB actually on volume RBI031 after it was recreated? If it moved was the catalog entry changed to match its new location? On 3/28/08, Mark Jacobs [EMAIL PROTECTED] wrote: Jacky Bright wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIBare not getting invoked. What could be the problem ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. Once another job gets converted using the default concatenation JES2 should reopen the proclib datasets which will then find the new location of the dataset. -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 12:51:26 +, Jacky Bright [EMAIL PROTECTED] wrote: Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? That RBI1.PROCLIB was deleted! ;-) Even though the library is not ENQed by JES2 (due to the NODSI entry in the PPT) the library is still in use. If the proclib is defined in the JES2 JCL you'll have to $PJES2,ABEND and restart JES2. If you are using dynamic proclibs, just issue $TPROCLIB(*) and that should fix it. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 09:01:06 -0400, Mark Jacobs [EMAIL PROTECTED] wrote: Most likely due to the old proclib being in a different physical location on the volume or even on a new volume than the newly allocated dataset. Yes. If you have an alternate jes2 proclib concatenation defined you can force a reopen of the proclib concatenation by submitting a job with a jobparm requesting that alternate proclib concatenation which should force a close of the primary concatenation and an open of the concatenation that you requested. That trick won't work for this situation. Since the extents are know already, it would only works if the proclib was allocated in the exact same place it originally existed (doubtful). That was what we would do when someone needed to compress a JES2 JCL defined proclib and we weren't about to IPL. See the archives for plenty more on that subject. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Clock Change
It's several years now since I was at a DB2 shop but I think that it doesn't actually use timestamps on the logs anyway, it uses its own sequencing independent of a time source, if I remember correctly. That's true, unless you're in a DB2 sharing group in a parallel SYSPLEX. Then, the DB2's do use timestamps, since the logs are independent. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 09:31:51 -0400, Lizette Koehler [EMAIL PROTECTED] wrote: Depending on your level of JES2 you may want to look at using PROCLIB statements in JES2 rather than coding DD statements. Or have the users start using JCLLIBs. I hope they are running at least z/OS 1.2 by now! But I agree that it should be done to help recover from a problem like this or prevent it entirely by using JCLLIB. RACF (or other) should be used to protect JES2 defined proclibs (either dynamic or JCL defined) by only allowing ALTER authority to a select few who understand that JES2 proclibs aren't ENQed. If shop standards or politics won't allow that, then I have seen shops define the proclibs to an arbitrary long running STC with DISP=SHR so they would get ENQed. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Jacky, You cannot move a JES2 JCL defined PROCLIB while JES2 is up. If it is in an SMS Managed pool, you probably need to look at coding PROCLIB statements in JES2 rather than the JCL. Mark makes a valid point. When JES2 had JCL coded PROCLIBs they are not ENQUEUED so if your security product does not have the general access of READ and only a few groups that have ALTER, you can have these types of issues. I would recommend that your security product specify a UACC of READ (if you are a RACF Shop) and only the group responsible to support JES2 have ALTER. When a JES2 JCL defined proclib is delete JES2 does not care. Once JES2 has opened the PROCLIB data set it builds a TTR list and uses that rather than going back to the dataset. It just reads the TTR pointers it built for that data sets. I do not have the in depth details on how that works, but if you are interested, I am sure there are several on this list (like Mark Z) who can provide that. Once the TTRs are built, if the data set is deleted, JES2 just goes on using those TTRs to access the procs. Should you compress JES2 JCL defined proclib you can run into similar issues, though I think you the a HASP message that states an I/O error has occurred. My preference has always been for the use of JCLLIB statements in Application JCL, and PROCLIB statements to reduce these types of errors in JES2. Should the recommended actions not correct the problem, you will most likely need to bounce JES2 so it can find the new home of the proclib data set and rebuild its TTRs. If you do need to abend JES2 you do not need to stop work. However, I think things that use the SAPI interface may abend with JES2. This is like VPS or similar products. IIRC, I have abended JES2 and not really seen any issues with currently running work. Lizette Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? That RBI1.PROCLIB was deleted! ;-) Even though the library is not ENQed by JES2 (due to the NODSI entry in the PPT) the library is still in use. If the proclib is defined in the JES2 JCL you'll have to $PJES2,ABEND and restart JES2. If you are using dynamic proclibs, just issue $TPROCLIB(*) and that should fix it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
My point is why CATALOG address space is not considering the new volume RBI035 why is it that still expecting RBI031 even though I have recreated the SCLM1.PROCLIB with catalog option and it got created in RBI035. If I see the LISTC for SCLM1.PROCLIB it shows the volume as RBI035 Error as : IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB Why the catalog is still expecting the dataset from RBI031 itself ? JAcky On 3/28/08, Lizette Koehler [EMAIL PROTECTED] wrote: Jacky, You cannot move a JES2 JCL defined PROCLIB while JES2 is up. If it is in an SMS Managed pool, you probably need to look at coding PROCLIB statements in JES2 rather than the JCL. Mark makes a valid point. When JES2 had JCL coded PROCLIBs they are not ENQUEUED so if your security product does not have the general access of READ and only a few groups that have ALTER, you can have these types of issues. I would recommend that your security product specify a UACC of READ (if you are a RACF Shop) and only the group responsible to support JES2 have ALTER. When a JES2 JCL defined proclib is delete JES2 does not care. Once JES2 has opened the PROCLIB data set it builds a TTR list and uses that rather than going back to the dataset. It just reads the TTR pointers it built for that data sets. I do not have the in depth details on how that works, but if you are interested, I am sure there are several on this list (like Mark Z) who can provide that. Once the TTRs are built, if the data set is deleted, JES2 just goes on using those TTRs to access the procs. Should you compress JES2 JCL defined proclib you can run into similar issues, though I think you the a HASP message that states an I/O error has occurred. My preference has always been for the use of JCLLIB statements in Application JCL, and PROCLIB statements to reduce these types of errors in JES2. Should the recommended actions not correct the problem, you will most likely need to bounce JES2 so it can find the new home of the proclib data set and rebuild its TTRs. If you do need to abend JES2 you do not need to stop work. However, I think things that use the SAPI interface may abend with JES2. This is like VPS or similar products. IIRC, I have abended JES2 and not really seen any issues with currently running work. Lizette Hi, In our system for JES2 RBI1.PROCLIB and RBI2.PROCLIB were defined in sequence resp. Later due to some reason RBI1.PROCLIB was deleted and recreated. But after that we are facing problem that PROCs from the RBI1.PROCLIB are not getting invoked. What could be the problem ? That RBI1.PROCLIB was deleted! ;-) Even though the library is not ENQed by JES2 (due to the NODSI entry in the PPT) the library is still in use. If the proclib is defined in the JES2 JCL you'll have to $PJES2,ABEND and restart JES2. If you are using dynamic proclibs, just issue $TPROCLIB(*) and that should fix it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF System Logger - limitations of MANx
I don't think anyone has mentioned the white paper from Riaz Ahmad (IBM) WSC that detailed a customer situation with problems dealing with current volumes using MANx data sets and some WSC testing that emulated it. http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101130 or http://tinyurl.com/2gnojb z/OS System Management Facilities (SMF) Recording with MVS Logger WP101130 Abstract: The SMF (System Management Facilities) Recording to MVS Logger describes the z/OS 1.9 facility which allows recording of the SMF data to MVS Logger Logstream. The paper documents a case study for a customer environment which has difficult time keeping up with the SMF data recording to MANx data sets. This new facility provides a solution where SMF data can be recorded to the MVS Logger logstream instead of MANx data sets. List of white papers... http://www-03.ibm.com/support/techdocs/atsmastr.nsf/Web/WP-ByProduct?Ope nDocumentStart=1Count=1000Expand=23 Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 14:17:47 +, Jacky Bright [EMAIL PROTECTED] wrote: My point is why CATALOG address space is not considering the new volume RBI035 why is it that still expecting RBI031 even though I have recreated the SCLM1.PROCLIB with catalog option and it got created in RBI035. If I see the LISTC for SCLM1.PROCLIB it shows the volume as RBI035 Error as : IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB Why the catalog is still expecting the dataset from RBI031 itself ? JAcky The catalog has nothing to do with it. Despite the fact that someone deleted the data set, it is still ALLOCATED to JES2 and the original extents are in the DEB. You can rename the new one, re-allocate it to its original volume and copy it back or just leave it where it is. Either way you have to recycle JES2 to pick up the new extents. Capiche? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SMF System Logger - limitations of MANx
On Fri, 28 Mar 2008 10:39:52 -0400, Knutson, Sam [EMAIL PROTECTED] wrote: I don't think anyone has mentioned the white paper from Riaz Ahmad (IBM) WSC that detailed a customer situation with problems dealing with current volumes using MANx data sets and some WSC testing that emulated it. http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101130 or http://tinyurl.com/2gnojb z/OS System Management Facilities (SMF) Recording with MVS Logger WP101130 Abstract: The SMF (System Management Facilities) Recording to MVS Logger describes the z/OS 1.9 facility which allows recording of the SMF data to MVS Logger Logstream. The paper documents a case study for a customer environment which has difficult time keeping up with the SMF data recording to MANx data sets. This new facility provides a solution where SMF data can be recorded to the MVS Logger logstream instead of MANx data sets. Thanks. The paper says this about the customer situation: During the peak hours of this interactive workload the customer has experienced long intervals when SMF data was produced at a rate exceeding the capacity to offload. In reality, there are limits placed on the offload process by the customers SMF data collection design, which involves collecting data offloaded from the SMF MANx datasets into a single daily collection dataset. Each offload is appended to the end of the collection dataset (using DISP=MOD processing) and this effectively limits the offload processes to dump the MANx datasets one at a time, due to the enqueue on the daily collection dataset. This supports what I have been saying about being able to keep up if you use IEFU29, run dumps to FICON DASD / virtual tape and run your dump STC in a high enough service class (SYSSTC if required). Other than a problem situation (looping transaction etc.) does anyone know of any shops where data is written so fast that the SMF address space (writes to MANx) can't keep up as opposed to the offload process not being able to keep up? Kees mentioned it and I have seen it happen, but only as a result of a problem - not a normal thing. I know the logger can handle much higher logging rates. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
---snip- Sounds like commentary I've heard about the U.S. legal system: Truth and justice are irrelevant, so long as procedure is followed precisely. -jc- unsnip--- And the lawyers get their (obscene) fees! :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Jacky - Once JES2 has started the CATALOG is no longer part of JES2's process to find its JCL defined Proclibs. JES2 builds an internal table that probably holds information like the data set name, the volser and the TTR locations in that dataset for the PROCs. You can with the appropriate ALTER authority go out and delete - define - catalog the JES2 PROCLIB anywhere. JES2 does not enqueue this data set. Therefore the CATALOG and JES2 can disagree on where the proclib actually lives. The only way to get this correct is to reallocate the proclib back on the original volume in the original location and pray that no one has already overlaid the TTRs where the JES2 Proclib use to live. Otherwise, if the proclib on the new volumes is good, you will need to bounce JES2 (HOT START) This is done with a $PJES2,ABEND. You will need to reply with the appropriate response. JES2 will then find the new home for this JCL defined Proclib. Lizette My point is why CATALOG address space is not considering the new volume RBI035 why is it that still expecting RBI031 even though I have recreated the SCLM1.PROCLIB with catalog option and it got created in RBI035. If I see the LISTC for SCLM1.PROCLIB it shows the volume as RBI035 Error as : IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB Why the catalog is still expecting the dataset from RBI031 itself ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
On 28 Mar 2008 08:17:13 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: Sounds like commentary I've heard about the U.S. legal system: Truth and justice are irrelevant, so long as procedure is followed precisely. -jc- unsnip--- And the lawyers get their (obscene) fees! :-) I think due process is the goal of judicial systems most everywhere. And people want predictability more than Truth and Justice. Predictability allows plans to function.Justice might bite us. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Howard Brazee On 28 Mar 2008 08:17:13 -0700, [EMAIL PROTECTED] (Rick Fochtman) wrote: Sounds like commentary I've heard about the U.S. legal system: Truth and justice are irrelevant, so long as procedure is followed precisely. unsnip--- And the lawyers get their (obscene) fees! :-) I think due process is the goal of judicial systems most everywhere. And people want predictability more than Truth and Justice. Predictability allows plans to function.Justice might bite us. Perhaps, to a point. But if you have a program that predictably abends with, say, S913-xx, wouldn't you prefer justice in the form of diagnosing and fixing the cause, rather than get so-and-so to run it? Due process should be a means, not an end. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Liz, Thanks but this is like IPLing the system itself which involves outage which many not be possible in our system So I was just looking for alternatives... JAcky On 3/28/08, Lizette Koehler [EMAIL PROTECTED] wrote: Jacky - Once JES2 has started the CATALOG is no longer part of JES2's process to find its JCL defined Proclibs. JES2 builds an internal table that probably holds information like the data set name, the volser and the TTR locations in that dataset for the PROCs. You can with the appropriate ALTER authority go out and delete - define - catalog the JES2 PROCLIB anywhere. JES2 does not enqueue this data set. Therefore the CATALOG and JES2 can disagree on where the proclib actually lives. The only way to get this correct is to reallocate the proclib back on the original volume in the original location and pray that no one has already overlaid the TTRs where the JES2 Proclib use to live. Otherwise, if the proclib on the new volumes is good, you will need to bounce JES2 (HOT START) This is done with a $PJES2,ABEND. You will need to reply with the appropriate response. JES2 will then find the new home for this JCL defined Proclib. Lizette My point is why CATALOG address space is not considering the new volume RBI035 why is it that still expecting RBI031 even though I have recreated the SCLM1.PROCLIB with catalog option and it got created in RBI035. If I see the LISTC for SCLM1.PROCLIB it shows the volume as RBI035 Error as : IEC143I 213-04,IFG0194D,JES2,JES2,PROC13-0003,9800,RBI031,SCLM1.PROCLIB Why the catalog is still expecting the dataset from RBI031 itself ? JAcky -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 16:02:28 +, Jacky Bright [EMAIL PROTECTED] wrote: Liz, Thanks but this is like IPLing the system itself which involves outage which many not be possible in our system So I was just looking for alternatives... There is really not much harm in doing $PJES2,ABEND and replying END to not take a dump and restarting it. It will interrupt printing, NJE and remotes if you have them. So other than draining printers you usually can just restart your lines / NJE connections after a JES2 bounce. Much less disruptive than an IPL. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Is IT becoming extinct?
On 28 Mar 2008 09:08:48 -0700, [EMAIL PROTECTED] (Chase, John) wrote: I think due process is the goal of judicial systems most everywhere. And people want predictability more than Truth and Justice. Predictability allows plans to function.Justice might bite us. Perhaps, to a point. But if you have a program that predictably abends with, say, S913-xx, wouldn't you prefer justice in the form of diagnosing and fixing the cause, rather than get so-and-so to run it? Due process should be a means, not an end. I know users who seem more happy with the predictability of knowing how things work - than with the idea of changing to a better way. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLink, again
On 27/03/2008, Bruce Hewson [EMAIL PROTECTED] wrote: I would assume, like on some web screens we use here, that the text input fields are not transparent. By that I mean the characters entered are treated as HTTP control characters, or something like that. I am trying to convince some of our local system builders that text input fields should allow ANY character to be enteredbut they keep saying cannot. I see that IBM have said they would correct the problem. But that wont help my local code problem. This sort of behaviour on a web page is a great place to look for security holes like code injection. Maybe that would help IBM see the light. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 09:44:20 -0500, Mark Zelden wrote: The catalog has nothing to do with it. Despite the fact that someone deleted the data set, it is still ALLOCATED to JES2 and the original extents are in the DEB. You can rename the new one, re-allocate it to its original volume and copy it back or just leave it where it is. Either way you have to recycle JES2 to pick up the new extents. Are DEBs created by ALLOCATE? I had imagined it was OPEN. In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? Just curious: can the PROCLIB concatenation contain PDSEs? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Paul Gilmartin wrote: On Fri, 28 Mar 2008 09:44:20 -0500, Mark Zelden wrote: The catalog has nothing to do with it. Despite the fact that someone deleted the data set, it is still ALLOCATED to JES2 and the original extents are in the DEB. You can rename the new one, re-allocate it to its original volume and copy it back or just leave it where it is. Either way you have to recycle JES2 to pick up the new extents. Are DEBs created by ALLOCATE? I had imagined it was OPEN. In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? I would guess that the thought process was not to prevent JES2 from starting if another system had an exclusive enqueue on a proclib dataset. Just curious: can the PROCLIB concatenation contain PDSEs? It shouldn't be a problem since PDSE support is active well before JES2 starts up. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Mark Jacobs Time Customer Service Tampa, FL In accordance to the principles of Doublethink, it does not matter if the war is not real, or when it is, that victory is not possible. The war is not meant to be won. It is meant to be continuous. The essential act of modern warfare is the destruction of the produce of human labor. A hierarchical society is only possible on the basis of poverty and ignorance. In principle, the war effort is always planned to keep society on the brink of starvation. The war is waged by the ruling group against its own subjects. And its object is not victory over Eurasia or Eastasia, but to keep the very structure of society intact. George Orwell - 1984 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Thanks but this is like IPLing the system itself which involves outage which many not be possible in our system So I was just looking for alternatives... A dynamic PROCLIB concatenation can be repaired via a series of $DEL/$ADD/$T PROCLIB JES2 commands. A static //PROCnn concatenation can be replaced/ overridden via a new dynamic one using /$ADD/$T PROCLIB JES2 commands. ...hth -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Paul Gilmartin wrote: Are DEBs created by ALLOCATE? I had imagined it was OPEN. Indeed. In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? MVS programs honor the settings in the PPT. HASJES20 and IATINTK have NODSI on their PPT entries. This can be changed if desired. Just curious: can the PROCLIB concatenation contain PDSEs? Silly question. BPAM is BPAM. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EMC Dasd and Performance Issues
Yes,.. That's what we were told also,.. But Cache is shared and I believe internal processors supporting the spinning disk whether Mainframe or Open Systems is shared. .. The Unix Side of the DMX-3 'DID' effect the mainframe storage. Soon after, there was a 'fix' applied to the EMC Code. (not complaining about EMC Disk. It has serviced us well) gabe -Original Message- Subject: Re: EMC Dasd and Performance Issues No, we share the frame with the mid range (Unix) side of the shop. However, we do not use the same disks in the box, Mainframe dasd is mapped on separate volumes from the Mid range dasd; I am told there is no intermingling... Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 11:35:54 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: On Fri, 28 Mar 2008 09:44:20 -0500, Mark Zelden wrote: The catalog has nothing to do with it. Despite the fact that someone deleted the data set, it is still ALLOCATED to JES2 and the original extents are in the DEB. You can rename the new one, re-allocate it to its original volume and copy it back or just leave it where it is. Either way you have to recycle JES2 to pick up the new extents. Are DEBs created by ALLOCATE? I had imagined it was OPEN. The DD associated with the proclib concatenation was previously opened. And by multiple converter subtasks depending on PCEDEF CNVTNUM. In my case CNVTNUM=10. In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? How would you ever re-allocate a proclib if it was ENQed? At least before TSO. Shutdown JES2, then run a batch job to do the rename. Wait... you can't run a batch job, JES2 is down! Just curious: can the PROCLIB concatenation contain PDSEs? Yes. That eliminates the COMPRESS issue or the problem you might run into if the library takes an additional extent. The second problem was fixed about 15 years ago in MVS/ESA V4. JES2 recognizes this condition via I/O error and then will close and reopen the DD for all converter tasks.Actually, knowing this works makes me think that the trick mentioned an an earlier post (running jobs that point to a nonexistent or another PROCxx DD) could work to fix the problem without having to bounce JES2. But I don't know if there is some extra code in the fix from 15 years ago that handles that situation differently. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ESQA allocation question
Hello, I've seen earlier items about Healthchecker and its ESQA checking, but I have a general question to which I haven't been able to find the information in the manuals. Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Dow Benelux B.V. Mailto:[EMAIL PROTECTED] Inkoop Gbw (427) H. H. Dowweg 5 4542NM Hoek The Netherlands Handelsregisternr. 24104547 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. I have always been of the opinion that a little SQA/ESQA conversion is okay, but not a lot. IBM (I believe) used recommend as little as possible. But, now with 64-bit addressing, and no expanded storage I think you cannot get away with it. IIRC, IPL-processing needs more ESQA to build page tables, and that will not be allowed to overflow into CSA, since the entire system is not up yet. There's a paper on the WTC site explaining this. And, as my faded memory recalls, it might have been written by Kathy Welsh/Walsh (?). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CSP/AD and zOS 1.8
We have a site still using CSP/AD (unsupported). The product failed in the BUILD function under under z/OS 1.8. We received word from IBM that they had customers running CSP/AD with Z/OS 1.8 reporting similiar problems. They believe the problem is in the runtime libraries for Z/OS 1.8, but they will not address as CSP/AD is no longer supported. Has anyone dealt with this issue? If yes, how did you address it short-term? I would like a short-term solution so I can implement z/OS 1.8. Then we look for a long-term solution. Thank you. Rose -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 12:03:54 -0500, Mark Zelden wrote: Yes. That eliminates the COMPRESS issue or the problem you might run into if the library takes an additional extent. The second problem was fixed about 15 years ago in MVS/ESA V4. JES2 recognizes this condition via I/O error and then will close and reopen the DD for all converter tasks.Actually, knowing this works makes me think that the trick mentioned an an earlier post (running jobs that point to a nonexistent or another PROCxx DD) could work to fix the problem without having to bounce JES2. But I don't know if there is some extra code in the fix from 15 years ago that handles that situation differently. Mark -- I was going to contribute to this before, to correct this statement you made, Mark. Having had the actual hands-on experience of a JES2 proclib going away in anger, I know that the trick of running a job pointing to a non- existing JES2 PROCxx DD actually works - IF THE PROCLIB DATA SETS ARE ON THE SAME VOLUME AS BEFORE. JES2 will CLOSE and reOPEN the PROCnn concatenation, and so long as the proclib data sets are on the exact same VOLUME, new extent information is built and JES2 is happy. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Just curious: can the PROCLIB concatenation contain PDSEs? Yes. That eliminates the COMPRESS issue or the problem you might run into if the library takes an additional extent. Yes, you can use PDSEs in the JES2 PROCLIB concatenation. LINKLIST too. But, not such a great idea, IMHO. Maybe I'm wrong here (and I could be), but I somehow remember that the empty space in a PDSE is not reclaimed until the dataset is closed. Now, you can't easily close a LINKLIST dataset; system shutdown doesn't quite do it. Removing it from the active LINKLIST probably will. A JES2 PROCLIB is easier to close; a temporary switch to a new concatenation usually works. However, the caveat here is that it must be closed on ALL systems sharing it, AT THE SAME TIME! Otherwise, the free space clean operation will not take place. I don't think that this has (yet) been addressed by IBM development. Additional extents are not as large of a problem with PDSEs and they are with PDSs. If a PDS (in a PROCLIB or a LINKLIST) takes a new extent, the only address space to know about it is the initiator in which the copy job executed (or the TSO user that took the new extent). Neither JES2 nor the LINKLIST will be aware. With a PDSE, all of this activity takes place within the PDSE address space. This address space can communicate this information to other images within the same SYSPLEX. All JES2s and LINKLISTs become aware. Corrections, if necessary, to the above are welcome! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSP/AD and zOS 1.8
They believe the problem is in the runtime libraries for Z/OS 1.8, but they will not address as CSP/AD is no longer supported. Has anyone dealt with this issue? If yes, how did you address it short-term? I would like a short-term solution so I can implement z/OS 1.8. I think the licensing agreement will allow my suggestion; you'd better check into it. Copy the old run-times somewhere and steplib/joblib to them. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
It's not too faded Ted. And yes, Walsh. ftp://ftp.software.ibm.com/software/mktsupport/techdocs/allreal_v11.pdf Ted MacNEIL [EMAIL PROTECTED] wrote: Given that ESQA will just overflow into ECSA is there any real reason not to allocate ESQA fairly low so that it is always at 100%, and then size/monitor ECSA for the combined requirements? I am aware that that would not be a good thing below the line, but I haven't read of any clear reason to 'tune' ESQA rather than ESQA/ECSA as a combined area. I have always been of the opinion that a little SQA/ESQA conversion is okay, but not a lot. IBM (I believe) used recommend as little as possible. But, now with 64-bit addressing, and no expanded storage I think you cannot get away with it. IIRC, IPL-processing needs more ESQA to build page tables, and that will not be allowed to overflow into CSA, since the entire system is not up yet. There's a paper on the WTC site explaining this. And, as my faded memory recalls, it might have been written by Kathy Welsh/Walsh (?). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 11:35:54 -0500, Paul Gilmartin wrote: In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? Yes, I believe it is very dangerous for JES2 to not hold an ENQ for its data sets. Some months ago, I submitted the following requirement to JES2 through my marketing rep, and a similar one through the JES2 Project at SHARE. To the best of my knowlege, there has been no formal response to this requirement, but from conversations at SHARE on this issue, I believe the requirement is understood (which is always a good first step). Here's how I phrased my requirement to JES2 regarding this issue: Today by default, JES2 does not participate in standard z/OS data set serialization (an ENQ on MAJOR SYSDSN, MINOR data.set.name). As a result, by default, it is possible for a user to delete an in-use JES2 PROCLIB data set without notification that the data set is in use. If the user codes JES2 PROCLIBs in JES2's JCL, the next start of JES2 will fail with a JCL error. Today, JES2 depends only upon knowledgeable users to avoid inadvertent deletion of data sets critical to the operation of JES2. To protect customers from an inadvertent error causing a system outage, JES2 should use standard z/OS facilities to protect via ENQ its PROCLIB data sets. Because of the value NODSI in the IBM default PPT entry for program HASJES20, any DD statement coded in the SYS1.PROCLIB(JES2) JCL is unprotected by ENQ. NODSI is defined as follows: If NODSI is specified, the system still issues an ENQ for all data sets requested by the program. However, the ENQ is released before the problem program is started. So, the protection exists as the system starts JES2, but is released after step initiation and before control is passed to HASJES20. Further, JES2 extends its no ENQ philosophy by specifying S99NORES for Dynamic PROCLIB data sets JES2 allocates via SVC 99. Because of the use of S99NORES, even if the customer overrides the PPT entry for HASJES20 to specify DSI, JES2 does not hold an ENQ for any of these data sets. The z/OS Allocation component describes the responsibilities for the use of S99NORES as follows: Note: Data sets being allocated are normally serialized via ENQ with MAJOR name SYSDSN, MINOR name -data set name-. When S99NORES is set, there is NO data set serialization and multiple tasks may reference or update the data set simultaneously, resulting in unpredictable effects. It is the responsibility of the authorized program setting S99NORES to provide the necessary serialization. It is the opinion of the author of this requirement that JES2 provides no facility to provide the necessary serialization, as specified by the documentation for S99NORES. Originally, OS/390 and MVS did not hold an ENQ for system link list data sets. More than ten years ago, IBM added such ENQ protection for system link list data sets. IBM also, in 1997, added the SETPROG LNKLST,UNALLOCATE command to allow the user to release this ENQ protection in the event a same- named data set required some sort of maintenance. Further, about seven years ago (in the OS/390 2.10 timeframe) IBM enhanced DFP to add support for the authorized rename of apparently in-use data sets. This authorization is based upon FACILITY class STGADMIN.DPDSRN.nnn and allows a user who presumably knows what he is doing to rename a data set otherwise protected by an ENQ. This capability is documented in manual 'z/OS Using Data Sets'. More than a decade ago, IBM decided that it was important to protect the system link list data sets with an ENQ. It is time for JES2 to do the same. Doing so would help customers avoid outages which are caused by the deletion of non serialized but critical and in-use data sets needed by JES2. Twenty years ago, JES2 systems programmers were god at most shops. Today, in light of HIPPA, SOX, and other government regulations, the author of this requirement has only READ authority to several JES2 PROCLIB data sets, while other non-systems programmer staff have ALTER authority. It is no longer sufficient to rely upon knowlegable sysprogs to protect JES2 - ENQ is required. This exposure has resulted in a multi-system outage for the author of this requirement. A JES2 PROCLIB data set, shared by every JES2 in the sysplex, was deleted by an individual RACF-authorized to do so. Some hours later, after the DASD extent containing the deleted PROCLIB's directory was reused by another data set, every batch job and TSO Logon attempt within the entire sysplex failed due to I/O Error in BLDL. A Hot Start of JES2 failed with a JCL error due to the missing data set. It was only pure chance that the JES2 sysprog was still logged on to TSO prior to the I/O Errors starting which allowed for a relatively non-disruptive recovery from this problem - the JES2 JCL was changed to remove the deleted
Re: CSP/AD and zOS 1.8
Rose Meininger wrote: We have a site still using CSP/AD (unsupported). The product failed in the BUILD function under under z/OS 1.8. We received word from IBM that they had customers running CSP/AD with Z/OS 1.8 reporting similiar problems. They believe the problem is in the runtime libraries for Z/OS 1.8, but they will not address as CSP/AD is no longer supported. Has anyone dealt with this issue? If yes, how did you address it short-term? I would like a short-term solution so I can implement z/OS 1.8. Then we look for a long-term solution. Thank you. Rose Have you tried using a STEPLIB to point to the runtime libraries on the older system? -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
NJE TCPIP and NJE SNA
Trying to connect two 1.7 lpars using TCPIP non-secure NJE. Able to start NETSRV1 on both lpars but starting the link receive msg IAZ0522I on the initiating lpar and msg IAZ0520I on receiving lpar. Configuration and errors are below. Traced tcpip during the $S N,S=JITST and see what we think is the control record and it has a RHOST value in the OPEN not of JISYS as in the SOCKET definition but ETRSJES, which is the name for the initiating lpar's OWNNODE. This would appear to be a problem (though a bit confused why 520 messages says the OHOST value is wrong when it appears to be right). Didn't see anything specific in the documents or in previous IBM-MAIN postings about having both NJE SNA and NJE TCPIP links active (which is what we would like to do). Can this be done? Or any suggestions on how to make this work? Initiating lpar (socket JISYS) -- NJEDEF OWNNODE=05, NODE(5) NAME=ETRSJES /* SNA */ NODE(10) NAME=JISYS,AUTH=(NET=YES) NODE(8) NAME=JITST,AUTH=(NET=YES) SOCKET(JISYS) IPADDR=*LOCAL,NODE=10,PORT=175 SOCKET(JITST) IPADDR=xx.xx.35.xx,NODE=8,PORT=175 NETSRV1SOCKET=LOCAL LINE(6) UNIT=TCP $S LNE6 $S NETSRV1 IAZ0511I NETSRV1 Server Port number could not be resolved, DEFAULT assumed: 175 $HASP5091 NETSRV1 IS ACTIVE IAZ0537I NETSRV1 NJETCP SERVER WAITING FOR WORK $S N,S=JITST $HASP000 OK IAZ0543I NETSRV1 TCP/IP connection with IP Addr: xx.xx.35.xx Port: 175 Initiated IAZ0543I NETSRV1 TCP/IP connection with IP Addr: xx.xx.35.xx Port: 175 Successful IAZ0522I NETSRV1 NJETCP Signon error: NAK received for OPEN, rsn: 1 Receiving lpar (socket JITST) - NODE(8) NAME=JITST,AUTH=(NET=YES) NODE(10) NAME=JISYS,AUTH=(NET=YES) SOCKET(JITST) IPADDR=*LOCAL,NODE=8,PORT=175 SOCKET(JISYS) IPADDR=xx.xx.4.xx,NODE=10,PORT=175 NETSRV1 SOCKET=JITST LINE(6)UNIT=TCP $S LNE6 $S NETSRV1 $HASP5091 NETSRV1 IS ACTIVE IAZ0537I NETSRV1 NJETCP SERVER WAITING FOR WORK IAZ0543I NETSRV1 TCP/IP connection with IP Addr: ETRSYS.407etr.com Port: 1039 Successful IAZ0520I NETSRV1 NJETCP Signon error: OHOST value not valid in OPEN IAZ1501I NETSRV1 S1: Exiting IAZNJSTK subtask IAZ0537I NETSRV1 NJETCP SERVER WAITING FOR WORK Trace - 17:36:18.204 (3) 10.0.35.100 10.0.4.100 TCP 1751046 JES2S001 85 TCP Data: 33 SEQ=2913612523 NXT=2913612556 ACK=3521531818 (ACK,PSH) IP HEADER : ID=48705 Time to Live=64 Type of Service=Routine-Normal Delay-Normal Throughput-Normal Reliability TCP HEADER : ACK PSH SEQ=2913612523 ACK=3521531818 WINDOW=32768 SESSION=D DATA (HEXA/EBCDIC/ASCII) : Length=33 00 *D6D7C5D5 40404040 C5E3D9E2 D1C5E240* *OPENETRSJES * 16 * D1C9E3E2 E3404040 0A002364* *JITST * 32 *00 * *. * Thanks, Lorne -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Mark Jacobs wrote: Paul Gilmartin wrote: On Fri, 28 Mar 2008 09:44:20 -0500, Mark Zelden wrote: In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? I would guess that the thought process was not to prevent JES2 from starting if another system had an exclusive enqueue on a proclib dataset. I don't think this is it. If I remember correctly, if NODSI is specified in the PPT the enq is still acquired at allocation, and then freed. So JES would still wait if some task had an exclusive enq on a proclib. I would guess the thinking might have been to allow the use of DISP=OLD by jobs that were updating or compressing a proclib (or other JES owned dataset). -- Richard -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
It's not too faded Ted. And yes, Walsh. Thanks. I converted to 64-bit so long ago, that I had forgotten all the details. But, I remember we had to increase our ESQA allocation in order to be able to IPL. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
Ted MacNEIL wrote: I converted to 64-bit so long ago, that I had forgotten all the details. But, I remember we had to increase our ESQA allocation in order to be able to IPL. In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
snip In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! snip Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 12:53:04 -0400, Jakubek, Jan [EMAIL PROTECTED] wrote: A static //PROCnn concatenation can be replaced/ overridden via a new dynamic one using /$ADD/$T PROCLIB JES2 commands. According to the manual: Dynamic PROCLIB can override PROCxx DDs in the JES2 start PROC but cannot alter nor delete them. So I decided to try this on a sandbox. It does work and I guess is the best solution since you don't have to bounce JES2 at all or worry about the number of converter subtasks etc. But in playing with it, I found something really interesting (at least to me). After I was done adding the dynamic proclib I then deleted the definition to put me back in a broken state. This sandbox JES2 has 2 converter subtasks and right now one is broke and the other one is still finding the PROC I am referencing from the proclib I deleted on the original volume (I allocated one with the same name on another volume). The interesting thing is that JES2 alternates between the 2 subtasks, so JES2's usage of them is round robin. Every other job I submit works or gets a IEC143I 213-04 on the proclib and a IEFC612I PROCEDURE xxx WAS NOT FOUND error message. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 12:56:12 -0500, Brian Peterson [EMAIL PROTECTED] wrote: On Fri, 28 Mar 2008 12:03:54 -0500, Mark Zelden wrote: Yes. That eliminates the COMPRESS issue or the problem you might run into if the library takes an additional extent. The second problem was fixed about 15 years ago in MVS/ESA V4. JES2 recognizes this condition via I/O error and then will close and reopen the DD for all converter tasks.Actually, knowing this works makes me think that the trick mentioned an an earlier post (running jobs that point to a nonexistent or another PROCxx DD) could work to fix the problem without having to bounce JES2. But I don't know if there is some extra code in the fix from 15 years ago that handles that situation differently. Mark -- I was going to contribute to this before, to correct this statement you made, Mark. Having had the actual hands-on experience of a JES2 proclib going away in anger, I know that the trick of running a job pointing to a non- existing JES2 PROCxx DD actually works - IF THE PROCLIB DATA SETS ARE ON THE SAME VOLUME AS BEFORE. JES2 will CLOSE and reOPEN the PROCnn concatenation, and so long as the proclib data sets are on the exact same VOLUME, new extent information is built and JES2 is happy. Makes sense. I was going to write this: The problem is, just like with the COMPRESS issue, you have to flood the system with enough jobs that every converter task gets used at the same time so it is closed and re-opened in all of them. In my case, that would probably be difficult given the speed of todays machines and the fact that I have 10 of them. The flooding part is always how I thought it worked (and maybe it did but has changed). See my last post: http://bama.ua.edu/cgi-bin/wa?A2=ind0803L=ibm-mainD=1amp;O=DT=0P=214254 Maybe it would be fixed after 10 jobs where submitted in a row with the non-existing JES2 PROCxx DD. Anyway... any time this has ever happened in a shop I was at (which has probably been no more than 5 times in the past 15-20 years) I have always just bounced JES2 (after making sure the PROCLIB existed and / or was moved back to its proper location). It's quick enough and always fixes the problem. BTW, I like your requirement. 5 times was 5 times too many. No reason the ENQ can't be there and removed with an operator command when needed. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 12:03:54 -0500, Mark Zelden wrote: In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? How would you ever re-allocate a proclib if it was ENQed? At least before TSO. Shutdown JES2, then run a batch job to do the rename. Wait... you can't run a batch job, JES2 is down! To my meager understanding, if JES2 is down you're SOL, whether or not it ENQs (but is there a special case in which JES2 might crash but fail to free the ENQS?) By my ancient experience, if JES2 is down, TSO is likewise SOL (or was it Roscoe, then?) If JES2 is up, then: o Submit a job with: - STEP1 IDCAMS ALTER NAME - STEP2 IEFBR14 with DISP=OLD on the PROCLIB catenands. o The job waits on PROCLIB ENQ o Stop JES2 o Start JES2 o JES2 waits on PROCLIB ENQ o The RENAME job completes freeing the ENQs o JES2 allocates PROCLIB and continues. Hmmm. This requires JES2 stopped and started on all systems in the GRSplex. But the timing isn't entirely critical; ENQ helps. It would help if there were a JES2 command to close, free, allocate, and open PROCLIB; even better if it did some thorough verification of PROCLIB validity and required operator confirmation before proceeding if it detected any anomaly ( CANCEL | RETRY | CONTINUE :-) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
Jack Kelly wrote: Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? I honesty don't remember the specifics after so many years (we upgraded to ESS (2105-800) from RVA in 2002). But, the phenomenon is documented in APAR II12396: OS/390 V2 R6 and above: SQA Space Shortage During NIP: During NIP processing, it is possible that the system's minimum allocation for SQA and extended SQA might be depleted before NIP processes the SQA parameter. To avoid this situation, you can increase the minimum SQA and/or extended SQA allocations, using the INITSQA parameter in LOADxx. (See OS/390 MVS Initialization Tuning Reference for information on the INITSQA parameter.) --- This type of storage exhaustion has been seen when adding ESS d/t2105 subsystems, since this subsystem typically requires the addition of many devices. FWIW, our LOADxx contains the following: INITSQA K 1536K -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Email blacklist
A few nights ago we started getting this message when we tried to send emails from the mainframe to our Outlook email server: EZA5198I 03/25/08 23:25:23 2 550 Denied by policy: Sender is listed on DNS-based RBL. The Outlook admin explained that we use several outside services to identify email from SPAM sites and, for whatever reason, one of those sites had identified the mainframe's IP as a SPAM'er. He said we should also be getting a message or email identifying the IP address of the service that had blacklisted us. The problem cleared by itself, presumably when the service corrected the problem, but I have not been able to find anything in the Communications Server manuals that talks about this. Has anyone else had the honor of being blacklisted and, if so, did they receive anything to tell them who had blacklisted them? Thanks, Carey Morris City of Fort Worth -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
If JES2 is up, then: o Submit a job with: - STEP1 IDCAMS ALTER NAME - STEP2 IEFBR14 with DISP=OLD on the PROCLIB catenands. o The job waits on PROCLIB ENQ o Stop JES2 o Start JES2 o JES2 waits on PROCLIB ENQ o The RENAME job completes freeing the ENQs o JES2 allocates PROCLIB and continues. In the above scenario, you would never get JES2 to shut down cleanly while a job is still executing. (It would need to be an STC running SUBSYS=MASTER.) And, even if this did work, you better hope that the job is successful; else, you are left without the PROCLIB and JES2 won't start! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM C/C++ compiler cost?
I might have said something incorrect on this topic earlier, although I don't think it applies to John's situation. Parallel Sysplex pricing is better than I implied previously. If you've got Parallel Sysplex, and you only license the C/C++ compiler to one physical machine, then you'll only be charged on that machine (based on total regular z/OS MSUs or total zNALC z/OS MSUs, depending on which side of that fence you've installed the compiler). For some reason I was thinking of DFSMStvs (another z/OS element) which, presumably, you'd be installing on both machines in a Parallel Sysplex for functional reasons. I think I implied that both machines would get charged if you only have the compiler on one, and that's not correct. Sorry for the confusion. As a tip, if you don't put the C/C++ compiler on both machines you'll likely want to put the compiler on the smaller machine in a Parallel Sysplex. Smaller is defined as the machine which typically clocks lower total z/OS MSUs (regular or zNALC, as appropriate) each month. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Servicelink User's Guide?
How can this possibly be as difficult as it has turned out to be? Can anyone provide a link to the Servicelink User's Guide? Sean Smith Bank of America -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Email blacklist
I create reports via SAS every night and then send an email from the mainframe to several techies and managers to tell them the reports are available for review. I've never run into anything like this yet. Then again my company might not be checking the same services yours does. Tom Kelman Commerce Bank of Kansas City (816) 760-7632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Morris, Carey Sent: Friday, March 28, 2008 2:31 PM To: IBM-MAIN@bama.ua.edu Subject: Email blacklist A few nights ago we started getting this message when we tried to send emails from the mainframe to our Outlook email server: EZA5198I 03/25/08 23:25:23 2 550 Denied by policy: Sender is listed on DNS-based RBL. The Outlook admin explained that we use several outside services to identify email from SPAM sites and, for whatever reason, one of those sites had identified the mainframe's IP as a SPAM'er. He said we should also be getting a message or email identifying the IP address of the service that had blacklisted us. The problem cleared by itself, presumably when the service corrected the problem, but I have not been able to find anything in the Communications Server manuals that talks about this. Has anyone else had the honor of being blacklisted and, if so, did they receive anything to tell them who had blacklisted them? Thanks, Carey Morris City of Fort Worth -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html * If you wish to communicate securely with Commerce Bank and its affiliates, you must log into your account under Online Services at http://www.commercebank.com or use the Commerce Bank Secure Email Message Center at https://securemail.commercebank.com NOTICE: This electronic mail message and any attached files are confidential. The information is exclusively for the use of the individual or entity intended as the recipient. If you are not the intended recipient, any use, copying, printing, reviewing, retention, disclosure, distribution or forwarding of the message or any attached file is not authorized and is strictly prohibited. If you have received this electronic mail message in error, please advise the sender by reply electronic mail immediately and permanently delete the original transmission, any attachments and any copies of this message from your computer system. * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Paul Gilmartin wrote: To my meager understanding, if JES2 is down you're SOL, whether or not it ENQs (but is there a special case in which JES2 might crash but fail to free the ENQS?) By my ancient experience, if JES2 is down, TSO is likewise SOL (or was it Roscoe, then?) We run TCAS under MSTR and allow TSO/E users to logon under MSTR. This can come in handy if JES is down. We also found that being able to issue arbitrary TSO/E commands from MCS consoles using System REXX provides some nice capabilities under similar circumstances. (One of my contributions to the Bit Bucket @ SHARE in Orlando.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
On Fri, 28 Mar 2008 15:04:34 -0400, Jack Kelly [EMAIL PROTECTED] wrote: snip In our case, z/Architecture was not the culprit. It was PAVs that blew INITSQA out of the water! snip Ed, Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? More UCBs = more ESQA. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Email blacklist
We use a mail filter product that determines if an e-mail is (a) spam or (b) contains something malicious and then blocks them. It has both a vendor provided blacklist and a local blacklist and can, based upon trends, classify a sender to the blacklist. It sounds like your mainframe is probably using a non-public IP address and somehow your vendors blacklist picked up that address from a collection of blacklisted addresses that they probably collect from their customers to improve their list. It is not something you'll find in the communications server pubs. Lionel B. Dyck, Consultant/Specialist Enterprise Platform Services, Mainframe Engineering KP-IT Enterprise Engineering 925-926-5332 (8-473-5332) | E-Mail: [EMAIL PROTECTED] AIM: lbdyck | Yahoo IM: lbdyck Kaiser Service Credo: Our cause is health. Our passion is service. We're here to make lives better. I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts. - Sir Arthur Conan Doyle NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. From: Morris, Carey [EMAIL PROTECTED] To: IBM-MAIN@bama.ua.edu Date: 03/28/2008 12:44 PM Subject: Email blacklist A few nights ago we started getting this message when we tried to send emails from the mainframe to our Outlook email server: EZA5198I 03/25/08 23:25:23 2 550 Denied by policy: Sender is listed on DNS-based RBL. The Outlook admin explained that we use several outside services to identify email from SPAM sites and, for whatever reason, one of those sites had identified the mainframe's IP as a SPAM'er. He said we should also be getting a message or email identifying the IP address of the service that had blacklisted us. The problem cleared by itself, presumably when the service corrected the problem, but I have not been able to find anything in the Communications Server manuals that talks about this. Has anyone else had the honor of being blacklisted and, if so, did they receive anything to tell them who had blacklisted them? Thanks, Carey Morris City of Fort Worth -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 14:35:42 -0500, Paul Gilmartin [EMAIL PROTECTED] wrote: On Fri, 28 Mar 2008 12:03:54 -0500, Mark Zelden wrote: In an earlier contribution, you mentioned that JES holds no ENQ on the PROCLIBs. That sounds terribly dangerous. Why would they design it that way? How would you ever re-allocate a proclib if it was ENQed? At least before TSO. Shutdown JES2, then run a batch job to do the rename. Wait... you can't run a batch job, JES2 is down! To my meager understanding, if JES2 is down you're SOL, whether or not it ENQs (but is there a special case in which JES2 might crash but fail to free the ENQS?) By my ancient experience, if JES2 is down, TSO is likewise SOL (or was it Roscoe, then?) Exactly. So with no ENQ the procedure would usually be to reallocate the PROCLIB just before a planned IPL. Allocate under a new name, rename the existing one to a backup name, rename the new one to the original name, then IPL. Note the rename as opposed to delete. Even though the PROCLIB is renamed while open to JES2, it is still accessible and usable. The same thing was done with LNKLST libs and still can be done if you release the ENQ. If JES2 is up, then: o Submit a job with: - STEP1 IDCAMS ALTER NAME - STEP2 IEFBR14 with DISP=OLD on the PROCLIB catenands. o The job waits on PROCLIB ENQ o Stop JES2 o Start JES2 o JES2 waits on PROCLIB ENQ o The RENAME job completes freeing the ENQs o JES2 allocates PROCLIB and continues. Hmmm. This requires JES2 stopped and started on all systems in the GRSplex. But the timing isn't entirely critical; ENQ helps. And all that doesn't sound terribly dangerous too? :-) Think back to the days when you had a single system. I'll take the old way with RACF protection to keep someone who didn't know what they were doing from deleting or moving the proclib. As I mentioned... if that wasn't good enough you could easily add the PROCLIBs with DISP=SHR to some arbitrary long running STC to get the ENQ. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Servicelink User's Guide?
On Fri, 28 Mar 2008 12:47:38 -0700, Smith, Sean M wrote: Can anyone provide a link to the Servicelink User's Guide? Sean Smith Each application within web IBMLink ServiceLink includes a HELP button on the left side of the screen which describes that application within ServiceLink. I've just read through the HELP information for SIS and ETR, and both are quite extensive - lots of good information about how the application works. If the question is instead about the VM IBMLink ServiceLink, fastpath SVCGUIDE brings up the VM IBMLink ServiceLink User's Guide SH52-0300-10 from September 1996. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
On Fri, 28 Mar 2008 14:32:48 -0500, Mark Zelden [EMAIL PROTECTED] wrote: The flooding part is always how I thought it worked (and maybe it did but has changed). See my last post: http://bama.ua.edu/cgi-bin/wa?A2=ind0803L=ibm-mainD=1amp;amp;O=DT=0P=214254 Maybe it would be fixed after 10 jobs where submitted in a row with the non-existing JES2 PROCxx DD. Anyway... any time this has ever happened in a shop I was at (which has probably been no more than 5 times in the past 15-20 years) I have always just bounced JES2 (after making sure the PROCLIB existed and / or was moved back to its proper location). It's quick enough and always fixes the problem. Lots more of this in a few IBM APARs. OY45900, OW51308 and II07133. You need IBMLINK to look at OY45900 and OW51308 as I can't find a docview link to them. OY45900 doesn't mention anything about round robin usage of the converter tasks: Thus, if there are multiple Converter PCEs / tasks it will be necessary to abend JES2 and restart it to guarantee that all proclibs are freshly opened ($P JES2,ABEND .. HOTSTART). And here in II07133 (from 1993) there is more... http://www-1.ibm.com/support/docview.wss?uid=isg1II07133 However, II07133 says: Note: It is NOT necessary to force a close and open of a Proclib after it's been compressed. Any I/O errors resulting from a compress would have occurred while the compress was in progress, and THAT would have forced a close and open of the proclib. If no I/O errors occurred while the compress was in progress, then no I/O errors would be expected after the compress had completed, and thus it is NOT necessary to perform the close and open. In my experience, the statement above is not true. I have seen problems caused by compress when no I/O errors occurred. OW51308 is more recent and mentions using the dynamic proclib facility in z/OS 1.2 instead of bouncing JES2. But it doesn't mention anything about a COMPRESS. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Servicelink User's Guide?
There is a help menu item to the left on each application page. It provides a extensive page of information on how to use the application. As far as a separate manual, I have not seen one for service link yet. -- Ian http://www.cicsworld.com On Fri, Mar 28, 2008 at 2:47 PM, Smith, Sean M [EMAIL PROTECTED] wrote: How can this possibly be as difficult as it has turned out to be? Can anyone provide a link to the Servicelink User's Guide? Sean Smith Bank of America -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Ian http://cics.pcs305.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 DD Concatenation issue
Paul Gilmartin wrote: To my meager understanding, if JES2 is down you're SOL, whether or not it ENQs (but is there a special case in which JES2 might crash but fail to free the ENQS?) By my ancient experience, if JES2 is down, TSO is likewise SOL (or was it Roscoe, then?) I'm a bit surprised that no one appears to be using the JES2 backup proc. S JES2BKUP,JOBNAME=JES2,SUB=MSTR (Where the name of the proc is whatever you'd like it to be). A stripped down version that allows you to bring up JES2 regardless of the state of PROCLIBs would seem a reasonable action. Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Email blacklist
On Fri, Mar 28, 2008 at 3:30 PM, in message [EMAIL PROTECTED], Morris, Carey [EMAIL PROTECTED] wrote: -snip- Has anyone else had the honor of being blacklisted and, if so, did they receive anything to tell them who had blacklisted them? A client I was working with a few years ago had one of their Exchange servers mistakenly set up as an open relay. They were spewing spam at a tremendous rate, and got blacklisted. No one told us. I think what your Exchange admin was trying to tell you is that in the actual SMTP reject message you got from the Exchange server should have been something like 550 5.7.1 Email rejected because 1.2.3.4 is listed by zen.spamhaus.org, as an example. There are other possibilities besides spamhaus.org. Mark POst -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: upgrading z?OS 1.4 to 1.8 or 1.9
Hi Ron, Can you share some details about the problem you ran into that is not fixed? Which ULTRAOPT flavor? We run BMC ULTRAOPT/IMS but have been bitten by bugs in some of the common code pieces . BMC support has nothing in the database we can find. We recently applied 2 PTFs for ULTRAOPT/IMS. BPB1303 to resolve a recurring ABEND 0D6-27 in a BMC SSI EOT routine causing random batch jobs to fail here and BPN1173 which is needed for the z/OS 1.9 upgrade. We thought that took care of any service we needed for z/OS 1.9. Best Regards, Sam Knutson, GEICO System z Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ron Wells Sent: Tuesday, March 11, 2008 9:38 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: upgrading z?OS 1.4 to 1.8 or 1.9 only problem we had was with BMC Ultraopt...just incase your running it... FYI--still not fixed This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ESQA allocation question
Hi all, Thanks for the responses and pointer to Kathy's White Paper. It is true that we have INITSQA coded, and that was for IPL failures which we thought were related to additions/changes to the storage configuration. However it did seem that INITSQA did not actually help much - just the action of a second IPL was enough to avoid the shortage then, and anyway that is due to requirements before the IEASYS parameter is handled by the system. I say that because we have had failures even with INITSQA coded, and reIPLing without changes appears to resolve things. These were new systems - we haven't actually had the failures that recently, so I hope my memory isn't tricking me. As far as I understand from the White Paper, as long as you can comfortably support an IPL, there is no real reason to worry about ESQA filling and overflowing during the life of the system. She does mention that some installations do follow a policy of minimal allocation (though she doesn't recommend this). I think my likely conclusion is to check our systems needs after they are fully IPLed, and aim to cover that comfortably, but not to tune for the Healthchecker 80% recommendation. Ideally we would not have any spare ESQA by the next IPL, allowing us to manage ECSA and ESQA as a combined pool. Best regards, David Tidy Tel:(31)115-67-1745 IS Technical Management/SAP-Mf Fax:(31)115-67-1762 Dow Benelux B.V.Mailto:[EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: 28 March 2008 20:58 To: IBM-MAIN@bama.ua.edu Subject: Re: ESQA allocation question Since we're finally getting to PAV, would you please expand on the problem/issue, e.g. how many PAVs and how much of an increase to the initial SQA? More UCBs = more ESQA. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
