Re: Fw: Should this be blocked ?
On Tue, 17 Feb 2009 23:35:57 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I'm impressed. I'm not sure what your point is, but you've made it! --Original Message-- From: Ted Mac Neil To: m...@yahoo What I meant to explain is that when we use a solution to filter mail in a company,the solution cannot rely on address of origin, because it is so easy to spoof and make believe you are from IBM or Cisco or GM or whatever. In this example ( if I remember what i did) the header shows US.IBM.COM And indeed this domain will let the mail go through the antispam list. And the spammers know that and use it extensively. So one of the method used is to calculate on the net how many similar mail content are travelling on the net. If the number is high ( thousands or millions ) then this is potentially spam, so a include/exclude list is being updated globally ( the daily or weekly provided subscribed list from the antispam solution vendor). But then as the solution could block mail by mistake, some adjustment needs to be done locally and this is where massmail parms come into account. You may adjust with the content filter ( a bit like websense) , and volume. For example here in France if 500 identical mails from IBM with the english word discount are coming in, then this has to be spam and we stop it. But then if there is no suspicious word it becomes slightly trickier. But then out of 4000 employees working in Insurance, Bank or whatever, it is not logical 500 of them receive the same mail from a computer company. I have been looking at different solutions in the past and not one is perfect. It is not a simple matter. Bruno Sugliani zxnetconsult(at)free(dot)fr http://zxnetconsult.free.fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
MQ question
Hello there!! I would like to know if anyone knows about any Forums for discussing Websphere MQ on ZOS platform. I am a CICS systems Programmer and would want to extend my knowledge on MQ as well. Taking a new role :) Can someone guide me please ?? Regards, Yogeetha CSC - Computer Science Corporation CICS Systems Programmer -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New CICS XCF Group
Roland: It's right!!!. The module version in LPA was 2.2. We have done IPL with the new module in LPA (ver 3.2) and now works. Thanks a lot Jorge -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Tuesday, February 17, 2009 6:45 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Automove vs Noautomove in BPXPRMxx I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 I am thinking that I should add NOAUTOMOVE to the MOUNT statement in BPXPRMxx for these files - because they truely cannot move. Am I correct in this thought? If I could get to a SYSPLEX ROOT, then I would be using a different approach. However, it is not there yet. Since you are not using a shared file system, automove is not relevant. Are you saying you have the same data set name but 2 physically different file systems mounted, but they are in the same sysplex / grsplex? That would be a problem - unless you excluded SYSZDSN - which is there to protect you from mounting the same file system R/W on 2 LPARs in the plex when you aren't using a shared file system. Or do I not understand the issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mcat MCNVTCAT type services
I guess I missed what this is in reply to...are we looking for catalog services? Mary Anne On Tue, Feb 17, 2009 at 8:34 PM, Mainframe Guy1 sysprog...@yahoo.comwrote: For what is worth I did see there's a company which provides master catalog mcnvtcat type services. http://www.systemsprogramminginc.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mcat MCNVTCAT type services
On Wed, 2009-02-18 at 07:47 -0500, Mary Anne Matyaz wrote: I guess I missed what this is in reply to...are we looking for catalog services? Ditto - I am also somewhat mystified. Not to mention the freely available rcnvtcat on the cbt site. Written by one of our own - in REXX. It works just like the old mcnvtcat, and it you don't like what it does, you can fix it. Excellent value for money ... Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
Basically these are system specific OMVS data sets. They would not be mounted on any other system because that system already has these files. I will look at UNMOUNT, however, there is no one trying to move these files. It looks to me to be the system trying to do this. I get an IGW026I indicating the system tried to mount LPAR1 dataset on LPAR2 but could not because it was already in use. It is just strange to me that the system is trying to mount a file it should not care about. From my SMPE environment I have the ZOS19.OMVS.JV390 dataset. I then copy it as SYS1.OMVS.JV390.LPAR1 and SYS1.OMVS.JV390.LPAR2 and so forth. So I have 5 copies of the smpe JV390 dataset. For some reason during its run time, the operating system seems to feel the need to mount this dataset (say SYS1.OMVS.JV390.LPAR1) on LPAR2. But LPAR2 already has this data set mounted as SYS.OMVS.JV390.LPAR2, and LPAR1 is not down and still has SYS1.OMVS.JV390.LPAR1 mounted. It is then I see the IGW026I message. Lizette If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 I am thinking that I should add NOAUTOMOVE to the MOUNT statement in BPXPRMxx for these files - because they truely cannot move. Am I correct in this thought? If I could get to a SYSPLEX ROOT, then I would be using a different approach. However, it is not there yet. Since you are not using a shared file system, automove is not relevant. Are you saying you have the same data set name but 2 physically different file systems mounted, but they are in the same sysplex / grsplex? That would be a problem - unless you excluded SYSZDSN - which is there to protect you from mounting the same file system R/W on 2 LPARs in the plex when you aren't using a shared file system. Or do I not understand the issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
Mark, I have them defined in BPXPRMxx. They are all defined as RW. I have taken all defaults. So are you saying that unless needed all OMVS datasets should have R rather than RW when they are not being updated? Does this account for the operating system thinking it needs to automount or automove to another system? Lizette How / why is LPAR2 trying to mount LPAR1's files? Do you have them defined in BPXPRMxx? That is allowed if they are mounted read only on both LPARs (which would create a SHR ENQ in SYSZDSN and not EXCL). Or is someone manually trying to mount them? If they are cross defined as R/W, then it's a good thing the SYSZDSN ENQ is there to protect you, otherwise you would end up with a sync error and the HFS would be unusable until it was unmounted / remounted (not to mention possible corruption). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html On Tue, 17 Feb 2009 18:45:06 -0500, Lizette Koehler stars...@mindspring.com wrote: I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 I am thinking that I should add NOAUTOMOVE to the MOUNT statement in BPXPRMxx for these files - because they truely cannot move. Am I correct in this thought? If I could get to a SYSPLEX ROOT, then I would be using a different approach. However, it is not there yet. Since you are not using a shared file system, automove is not relevant. Are you saying you have the same data set name but 2 physically different file systems mounted, but they are in the same sysplex / grsplex? That would be a problem - unless you excluded SYSZDSN - which is there to protect you from mounting the same file system R/W on 2 LPARs in the plex when you aren't using a shared file system. Or do I not understand the issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
The only time that BPXPRMxx is used to mount a filesystem is at IPL time, so unless the system that is trying to perform the mount is IPLing then someone is trying to manually mount this filesystem. If it is at IPL time you should be getting an 'BPXF237I FILE SYSTEM.Already mounted' message, not the IGW026I. Are you sharing one BPXPRMxx member within the SYSPLEX? We have two members for every system, a SYSPLEX BPXPRMxx for filessytems that should be shared and a System-specific BPXPRMxx for system-specific filesystems. All of the filesytems in the system-specific BPXPRMxx are defined with 'unmount'. Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 8:29 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Automove vs Noautomove in BPXPRMxx Basically these are system specific OMVS data sets. They would not be mounted on any other system because that system already has these files. I will look at UNMOUNT, however, there is no one trying to move these files. It looks to me to be the system trying to do this. I get an IGW026I indicating the system tried to mount LPAR1 dataset on LPAR2 but could not because it was already in use. It is just strange to me that the system is trying to mount a file it should not care about. From my SMPE environment I have the ZOS19.OMVS.JV390 dataset. I then copy it as SYS1.OMVS.JV390.LPAR1 and SYS1.OMVS.JV390.LPAR2 and so forth. So I have 5 copies of the smpe JV390 dataset. For some reason during its run time, the operating system seems to feel the need to mount this dataset (say SYS1.OMVS.JV390.LPAR1) on LPAR2. But LPAR2 already has this data set mounted as SYS.OMVS.JV390.LPAR2, and LPAR1 is not down and still has SYS1.OMVS.JV390.LPAR1 mounted. It is then I see the IGW026I message. Lizette If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 I am thinking that I should add NOAUTOMOVE to the MOUNT statement in BPXPRMxx for these files - because they truely cannot move. Am I correct in this thought? If I could get to a SYSPLEX ROOT, then I would be using a different approach. However, it is not there yet. Since you are not using a shared file system, automove is not relevant. Are you saying you have the same data set name but 2 physically different file systems mounted, but they are in the same sysplex / grsplex? That would be a problem - unless you excluded SYSZDSN - which is there to protect you from mounting the same file system R/W on 2 LPARs in the plex when you aren't using a shared file system. Or do I not understand the issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mcat MCNVTCAT type services
In a message dated 2/18/2009 6:47:50 A.M. Central Standard Time, maryanne4...@gmail.com writes: what this is in reply to...are we looking for catalog services? Likewise, maybe it's off newsgroups? Been using Alastair Gray's RCNVTCAT off file 542 CBT for years. **A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http://www.freecreditreport.com/pm/default.aspx?sc=668072%26hmpgID=62%26bcd=fe bemailfooterNO62) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
I have two BPXPRMxx members. One is system wide, the second it system specific. Because we define these files with SYS1.OMVS.JV390.SYSNAME we elected to put them in BPXPRM00. This contains the generic names along with the BPX options. When we have a unix file that is system specific, we code that in the BPXPRMxx where xx = last two chars of our LPARs. So - yes we code the file systems in BPXPRM00 where we use a SYMBOLIC in the data set name. For actual files that are only on one system, we code that in the lpar specific BPXPRM member. All defaults are taken and RW is the status in the parms for all files. Lizette The only time that BPXPRMxx is used to mount a filesystem is at IPL time, so unless the system that is trying to perform the mount is IPLing then someone is trying to manually mount this filesystem. If it is at IPL time you should be getting an 'BPXF237I FILE SYSTEM.Already mounted' message, not the IGW026I. Are you sharing one BPXPRMxx member within the SYSPLEX? We have two members for every system, a SYSPLEX BPXPRMxx for filessytems that should be shared and a System-specific BPXPRMxx for system-specific filesystems. All of the filesytems in the system-specific BPXPRMxx are defined with 'unmount'. Basically these are system specific OMVS data sets. They would not be mounted on any other system because that system already has these files. I will look at UNMOUNT, however, there is no one trying to move these files. It looks to me to be the system trying to do this. I get an IGW026I indicating the system tried to mount LPAR1 dataset on LPAR2 but could not because it was already in use. It is just strange to me that the system is trying to mount a file it should not care about. From my SMPE environment I have the ZOS19.OMVS.JV390 dataset. I then copy it as SYS1.OMVS.JV390.LPAR1 and SYS1.OMVS.JV390.LPAR2 and so forth. So I have 5 copies of the smpe JV390 dataset. For some reason during its run time, the operating system seems to feel the need to mount this dataset (say SYS1.OMVS.JV390.LPAR1) on LPAR2. But LPAR2 already has this data set mounted as SYS.OMVS.JV390.LPAR2, and LPAR1 is not down and still has SYS1.OMVS.JV390.LPAR1 mounted. It is then I see the IGW026I message. Lizette If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE HOLDER: OMVS ASID: X000E TCB: X009DB360 I am thinking that I should add NOAUTOMOVE to the MOUNT statement in BPXPRMxx for these files - because they truely cannot move. Am I correct in this thought? If I could get to a SYSPLEX ROOT, then I would be using a different approach. However, it is not there yet. Since you are not using a shared file system, automove is not relevant. Are you saying you have the same data set name but 2 physically different file systems mounted, but they are in the same sysplex / grsplex? That would be a problem - unless you excluded SYSZDSN - which is there to protect you from mounting the same file system R/W on 2 LPARs in the plex when you aren't using a shared file system. Or do I not understand the issue? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MQ question
a listserv, archives and subscription information are available at https://listserv.meduniwien.ac.at/archives/mqser-l.html a web board at http://mqseries.net/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MQ question
On Wed, 18 Feb 2009 14:36:25 +0530, Yogeetha balasubramanian sairamyog...@gmail.com wrote: Hello there!! I would like to know if anyone knows about any Forums for discussing Websphere MQ on ZOS platform. I am a CICS systems Programmer and would want to extend my knowledge on MQ as well. Taking a new role :) Can someone guide me please ?? Regards, Yogeetha CSC - Computer Science Corporation CICS Systems Programmer MQSERIES-L list http://listserv.meduniwien.ac.at/cgi-bin/wa?A0=mqseries Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
It looks like you have a good setup. I would agree with Mark that anything that doesn't get updated should be mounted read/only and any filesystems that contains executables should DEFINITELY be mounted read/only for security reasons (so no one could intentionally or accidentally update it). If a vendor ships executables and configuration files in the same filesystem, we manually separate them and use symbolic links to logically keep the same paths. The configuration files are in a read/write filesystem and the executables are in a separate, read/only filesystem pointed to by the symbolic links. As for the IGW026I messages, it would appear that either someone is trying to manually mount the filesystem or you have a corrupted mount table. IBM might be able to diagnose a corrupted mount table from a dump, but I would research the possiblity of a manual mount. Best of luck! Jon Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 9:03 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Automove vs Noautomove in BPXPRMxx I have two BPXPRMxx members. One is system wide, the second it system specific. Because we define these files with SYS1.OMVS.JV390.SYSNAME we elected to put them in BPXPRM00. This contains the generic names along with the BPX options. When we have a unix file that is system specific, we code that in the BPXPRMxx where xx = last two chars of our LPARs. So - yes we code the file systems in BPXPRM00 where we use a SYMBOLIC in the data set name. For actual files that are only on one system, we code that in the lpar specific BPXPRM member. All defaults are taken and RW is the status in the parms for all files. Lizette The only time that BPXPRMxx is used to mount a filesystem is at IPL time, so unless the system that is trying to perform the mount is IPLing then someone is trying to manually mount this filesystem. If it is at IPL time you should be getting an 'BPXF237I FILE SYSTEM.Already mounted' message, not the IGW026I. Are you sharing one BPXPRMxx member within the SYSPLEX? We have two members for every system, a SYSPLEX BPXPRMxx for filessytems that should be shared and a System-specific BPXPRMxx for system-specific filesystems. All of the filesytems in the system-specific BPXPRMxx are defined with 'unmount'. Basically these are system specific OMVS data sets. They would not be mounted on any other system because that system already has these files. I will look at UNMOUNT, however, there is no one trying to move these files. It looks to me to be the system trying to do this. I get an IGW026I indicating the system tried to mount LPAR1 dataset on LPAR2 but could not because it was already in use. It is just strange to me that the system is trying to mount a file it should not care about. From my SMPE environment I have the ZOS19.OMVS.JV390 dataset. I then copy it as SYS1.OMVS.JV390.LPAR1 and SYS1.OMVS.JV390.LPAR2 and so forth. So I have 5 copies of the smpe JV390 dataset. For some reason during its run time, the operating system seems to feel the need to mount this dataset (say SYS1.OMVS.JV390.LPAR1) on LPAR2. But LPAR2 already has this data set mounted as SYS.OMVS.JV390.LPAR2, and LPAR1 is not down and still has SYS1.OMVS.JV390.LPAR1 mounted. It is then I see the IGW026I message. Lizette If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). I have th 5 lpars. Each one has its own set of OMVS datasets. For example Lpar1 has SYS1.OMVS.ROOT.LPAR1, SYS1.OMVS.JV390.LPAR1, SYS1.OMVS.SGIYROOT.LPAR1 and so on. Lpar2 has a duplicate set of files that end with LPAR2 rather LPAR1 And so forth. I see in syslog that the LPAR2 gets an IGW026I message trying to mount the LPAR1 dataset. This is not needed nor required. Each system has its own set. I was thinking that setting the files to NOAUTOMOVE would prevent another system from trying to mount them. Lizette On Tue, 17 Feb 2009 11:20:11 -0500, Lizette Koehler stars...@mindspring.com wrote: I have read the manuals but I am still not clear on the use of automove vs. noautomove. My Unix envrionment on z/OS V1.9 is one system/one set of UNIX files. So, yes, I have a lot of duplicated files. However, from time to time I notice I will see the following message in SYSLOG IGW026I HFS FILE SYSTEM: SYS1.SPG7.OMVS.DB2V91.SDSNAHFS 202 MOUNT REQUEST FAILED, RESOURCE HELD EXCLUSIVE ON: SPG7 RESOURCE
Re: Mcat MCNVTCAT type services
Considering I had never seen this email address before, I thought it might be a lame attempt at stealth advertizing. Mary Anne Matyaz maryanne4...@gmail.com 2/18/2009 7:47 AM I guess I missed what this is in reply to...are we looking for catalog services? Mary Anne On Tue, Feb 17, 2009 at 8:34 PM, Mainframe Guy1 sysprog...@yahoo.comwrote: For what is worth I did see there's a company which provides master catalog mcnvtcat type services. http://www.systemsprogramminginc.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ADCD Load
Chuck, I was remiss in not thanking you for the information. I really appreciated it. Thanks again, Fred -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu]on Behalf Of Chuck Arney Sent: Friday, February 13, 2009 4:57 PM To: IBM-MAIN@bama.ua.edu Subject: Re: ADCD Load Fred, it looks like you need PTF UA37111. Check out this web page for a description: http://dtsc.dfw.ibm.com/MVSDS/'HTTPD2.adcd.global.html(readm19w)'#Header _09 Something to do with more than 64 device in your FLEX config. snip C Thanks. Fred Hoffman IGGN504 SPECIFY UNIT FOR CATALOG.Z19.MASTER ON Z9SYS1 00,0AC3 IEE600I REPLY TO 00 IS;0AC3 IGGN306I 0AC3, UNIT UNACCEPTABLE, 0004 IGGN504 SPECIFY UNIT FOR CATALOG.Z19.MASTER ON Z9SYS1 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Rexx / edit macro bug?
Hello. Can anyone explain why the following code snippet doesn't work as expected? (This has prev gone to Google Groups, was advised to wait until our z/OS upgrade from 1.7 to 1.9 had been completed - it has - but the same thing still happens.) I would expect it to leave the member with line 401 at the top, and the cursor on line 412, pos21. The FIND string is on line 412 - I want the cursor to stay with the FOUND string, but to change the line that appears at the top of the display. /* rexx */ address isredit macro FIND WS-MODULE-IDENTIFIER locate 401 cursor = 412 21 If I *remove* the FIND command, it correctly locates and positions the cursor. That is, line 401 is at the top of the display, the cursor appears on line 412. *With* the FIND command, it positions the display according to my EDITSETting Target Line for Find/etc, ignoring the LOCATE command. If I place the CURSOR command *before* the LOCATE command, it obeys the LOCATE but loses the cursor placement (cursor in command line). Same if I remove the CURSOR line completely. Is this a bug in ISPF, or an undocumented feature in the generally not-very-good IBM documentation, which I have explored in depth? http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ISPZEM40/3.3.31 Thank you, Clark. Clark Pearson Senior Analyst/Programmer (Oracle Mainframe) IT Systems, Ventura ( 0113 2073564 (x33564) 8 mailto:clark.pear...@ventura-uk.com ** The contents of this e-mail and its attachments are confidential and may be subject to legal privilege.The contents may not be disclosed, copied or distributed without our consent.It is intended for the use of the addressee(s) only.If you are not the intended recipient you must delete this message immediately and advise the sender that you received it in error. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of Ventura.Ventura does not accept any responsibility for the author's views. Whilst Ventura takes every effort to ensure this message is virus free it can not guarantee that this is the case.It is the recipients responsibility to carry out such virus checks as it deems necessary.Ventura can not accept any responsibility in this regard.Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium.We advise that you understand and observe this lack of security when e-mailing us. Ventura reserves the right to monitor emails in accordance with the Telecommunications (Lawful Business Practice) Interception of Communications) Regulations 2000. Club 24 Ltd trading as Ventura Registered Office: Hepworth House, Claypit Lane, Leeds LS2 8AE. Registered in England Number 1336850 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: WLM initiators
On Tue, 17 Feb 2009 16:19:29 -0600, Field, Alan C. wrote: We've tried to manage the number of inits manually to balance the utilization but it's not easy. We're wondering about WLM inits for this class. Early experience with WLM inits wasn't positive. I had great results with WLM initiators when I went to OS/390 2.4. I think it might have helped that all of my batch goals were response time goals. I made sure that none of my goals were too aggressive and for batch I used fairly low percentiles on my response time goals. At the time of the upgrade to 2.4, we were very far back level and were running at 100% all day. CICS response times were starting to suffer before going to 2.4 and goal mode. After the upgrade, we found that there were usually fewer initiatirs running and everything ran better, including test batch work. I'm not at that shop any more and am no longer doing WLM work as part of my regular responsibilities, so I can't give details. I did post them way back then so you could check the archives. This is what I remember. For our test job class, I had a goal of 50% complete in under 5 minutes. I had determined ahead of time that it was an easy goal to meet. For our production job classes I had a goal of something like 50% complete in less than 30 minutes. We did have a number of production jobs that ran for a lot longer than 30 minutes, but there were always enough fast running jobs in the system so that WLM was able to meet the goal. We had only one job class that couldn't use WLM initiators because of some automation that started and stopped the initiator and sometimes inserted a restore job to recover from abends. We tried to change the automation to set the maximum number of jobs in that class to zero and back to one rather than stop and start the init. It worked ok, but was too slow, so we put that job class back under JES control. You will find that with WLM managed inits, you can't see the initiators in an SDSF INIT display. You can, however see a lot of useful information in a JC display. Also, with WLM inits, when there is a job that needs to start now, you can simply use $S jobname. Of course, YMMV. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Rexx / edit macro bug?
Haven't tried that, but why not just doing: find xxx' locate 401 find xxx It will put the cursor on the start of the found string without changing the screen position as the find value is in the LVLINed area. ITschak On Wed, Feb 18, 2009 at 4:45 PM, Clark Pearson clark.pear...@ventura-uk.com wrote: Hello. Can anyone explain why the following code snippet doesn't work as expected? (This has prev gone to Google Groups, was advised to wait until our z/OS upgrade from 1.7 to 1.9 had been completed - it has - but the same thing still happens.) I would expect it to leave the member with line 401 at the top, and the cursor on line 412, pos21. The FIND string is on line 412 - I want the cursor to stay with the FOUND string, but to change the line that appears at the top of the display. /* rexx */ address isredit macro FIND WS-MODULE-IDENTIFIER locate 401 cursor = 412 21 If I *remove* the FIND command, it correctly locates and positions the cursor. That is, line 401 is at the top of the display, the cursor appears on line 412. *With* the FIND command, it positions the display according to my EDITSETting Target Line for Find/etc, ignoring the LOCATE command. If I place the CURSOR command *before* the LOCATE command, it obeys the LOCATE but loses the cursor placement (cursor in command line). Same if I remove the CURSOR line completely. Is this a bug in ISPF, or an undocumented feature in the generally not-very-good IBM documentation, which I have explored in depth? http://publibz.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/ISPZEM40/3.3.31 Thank you, Clark. Clark Pearson Senior Analyst/Programmer (Oracle Mainframe) IT Systems, Ventura ( 0113 2073564 (x33564) 8 mailto:clark.pear...@ventura-uk.com ** The contents of this e-mail and its attachments are confidential and may be subject to legal privilege.The contents may not be disclosed, copied or distributed without our consent.It is intended for the use of the addressee(s) only.If you are not the intended recipient you must delete this message immediately and advise the sender that you received it in error. The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of Ventura.Ventura does not accept any responsibility for the author's views. Whilst Ventura takes every effort to ensure this message is virus free it can not guarantee that this is the case.It is the recipients responsibility to carry out such virus checks as it deems necessary.Ventura can not accept any responsibility in this regard.Please note that this e-mail has been created in the knowledge that Internet e-mail is not a 100% secure communications medium.We advise that you understand and observe this lack of security when e-mailing us. Ventura reserves the right to monitor emails in accordance with the Telecommunications (Lawful Business Practice) Interception of Communications) Regulations 2000. Club 24 Ltd trading as Ventura Registered Office: Hepworth House, Claypit Lane, Leeds LS2 8AE. Registered in England Number 1336850 ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FTP Question
Since you are using Client FTP in TSO, you need the TSO MOUNT privilege and you need AUTOTAPEMOUNT specified in your FTP.DATA file. There are several places where the FTP.DATA file can be found, make sure you get the correct one. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
IBMLINK Issues?
I keep getting Data base errors trying to list ETRs. Is anyone else having this problem? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
Agreed, a 50% hit rate is pretty bad, but a heck of a lot better than zero. If you could somehow exclude the file from all caching, then I would expect a drastic degradation of I/O performance. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of jason to Sent: Tuesday, February 17, 2009 5:59 PM To: IBM-MAIN@bama.ua.edu Subject: High DASD disconnect time due to RANDOM READ I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. Regards, Jason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLINK Issues?
PS. 3270 works Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 10:46 AM To: IBM-MAIN@bama.ua.edu Subject: IBMLINK Issues? I keep getting Data base errors trying to list ETRs. Is anyone else having this problem? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLINK Issues?
Me too: An error has occurred: An error occurred accessing the database: SPR0 10008 Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 10:46 AM To: IBM-MAIN@bama.ua.edu Subject: IBMLINK Issues? I keep getting Data base errors trying to list ETRs. Is anyone else having this problem? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLINK Issues? - Yes it is broken
I just got off the phone with IBMLINK help desk. What an experience. Many users are getting SPR0 1008 on the LIST ETR screen as well as others. IBM is diligently working on this issue. Lizette Subject: IBMLINK Issues? I keep getting Data base errors trying to list ETRs. Is anyone else having this problem? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLINK Issues?
Same here. MA On Wed, Feb 18, 2009 at 10:48 AM, Veilleux, Jon L veilleu...@aetna.comwrote: Me too: An error has occurred: An error occurred accessing the database: SPR0 10008 Jon L. Veilleux veilleu...@aetna.com (860) 636-2683 -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Lizette Koehler Sent: Wednesday, February 18, 2009 10:46 AM To: IBM-MAIN@bama.ua.edu Subject: IBMLINK Issues? I keep getting Data base errors trying to list ETRs. Is anyone else having this problem? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This e-mail may contain confidential or privileged information. If you think you have received this e-mail in error, please advise the sender by reply e-mail and then delete this e-mail immediately. Thank you. Aetna -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: MQ question
Thanks Guys for your help IN google i found this http://www.mqseries.net/ . I think all these will help me a lot :) On Wed, Feb 18, 2009 at 7:36 PM, Scott Barry sba...@sbbworks.com wrote: On Wed, 18 Feb 2009 14:36:25 +0530, Yogeetha balasubramanian sairamyog...@gmail.com wrote: Hello there!! I would like to know if anyone knows about any Forums for discussing Websphere MQ on ZOS platform. I am a CICS systems Programmer and would want to extend my knowledge on MQ as well. Taking a new role :) Can someone guide me please ?? Regards, Yogeetha CSC - Computer Science Corporation CICS Systems Programmer MQSERIES-L list http://listserv.meduniwien.ac.at/cgi-bin/wa?A0=mqseries Scott Barry SBBWorks, Inc. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Stopping FTP
I need to bounce FTP. The P or C command does not stop the FTPD1 process. So how do I stop the FTPD1 ASID. I know it's some UNIX command, but I can't find it. Where is this stuff documented? Thanks from a non UNIX guy. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBMLINK Issues?
Not for me. When I tried to browse one of my ETR records using VM IBMLink, I receive error message: Your RETAIN user ID is invalid. . Please contact your RETAIN coordinator. . Hmmm Brian On Wed, 18 Feb 2009 10:50:09 -0500, Veilleux, Jon L wrote: PS. 3270 works Jon L. Veilleux -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How Official are Supplied Sample Exits? (was Assembler Question)
On Tue, 17 Feb 2009 23:14:07 -0500, Robert A. Rosenberg hal9...@panix.com wrote: There is also the issue of using a BALR (or BASR) in lieu of instructions that do not need Base Registers (ie: Not allowing the macro to be used in a BASELESS program). That's true. But BALR (as opposed to BAL) does not need a base register. If we're still talking about RACROUTE, I believe it should work just fine in a baseless program, assuming that (a) you write reentrant code and use L- and E-forms of the macro, and (b) you've included IEABRC to handle a few B and BNZ instructions that it generates. I can't comment on other system macros, though, as I haven't looked at them in this regard. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stopping FTP
John, The P command should do it. On my system, the D A,L command shows that the server is called FTPSERVE, so I use P FTPSERVE to shut it down. S FTPSERVE (the name of my FTP Server proc) starts it again. FTPD1 must not be the correct name. Gary DiPillo Axios Products, Inc. I need to bounce FTP. The P or C command does not stop the FTPD1 process. So how do I stop the FTPD1 ASID. I know it's some UNIX command, but I can't find it. Where is this stuff documented? Thanks from a non UNIX guy. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
snip-- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip- In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
On Wed, 18 Feb 2009 07:22:54 -0500, Veilleux, Jon L veilleu...@aetna.com wrote: If that is your scenario then you should be using 'unmount' for the automove parameter. Noautomove can still leave entries in the global mount table for these filesystems even though the system is down. That is usually not a big issue unless you have the need to mount them on another system for some reason (maintenance or problem determination, etc). Again... at least according to her, she is not using a shared file system configuration. No sysplex root etc. automove / unmount is irrelevant. When the system is shut down or OMVS is taken down, the file systems are unmounted. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
On Wed, 18 Feb 2009 08:28:44 -0500, Lizette Koehler stars...@mindspring.com wrote: Basically these are system specific OMVS data sets. They would not be mounted on any other system because that system already has these files. I will look at UNMOUNT, however, there is no one trying to move these files. It looks to me to be the system trying to do this. I get an IGW026I indicating the system tried to mount LPAR1 dataset on LPAR2 but could not because it was already in use. You are missing something here. The system only tryies to mount what *you* tell it. You are telling it to mount the in use file systems (erroneously). Each system needs it's own unique BPXPRMxx in this case... unless every single file system has a SYSNAME (or something unique that you can use system symbols for) in it or the ones that don't are mounted read only. So perhaps the problem is a shared BPXPRMxx and you should not be using a shared BPXPRMxx. Get it now? -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
On Wed, 18 Feb 2009 08:30:59 -0500, Lizette Koehler stars...@mindspring.com wrote: Mark, I have them defined in BPXPRMxx. They are all defined as RW. I have taken all defaults. So are you saying that unless needed all OMVS datasets should have R rather than RW when they are not being updated? You don't have to do this if they are unique, but it is a safe practice anyway. The sysres root should always be read only (although again, that is not required if each system has its own). Does this account for the operating system thinking it needs to automount or automove to another system? See my last post. What accounts for it is you telling it to mount it / them via BPXPRMxx. But if they were mounted READ only, then the ENQ is SHR and not EXCL and you wouldn't see those messages. I mount all root files as read only (java, cics, db2, mvs, mq, was, etc.). Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stopping FTP
Got it to work. Must have had a typo. John Norgauer Senior Systems Programmer Mainframe Technical Support Services University of California Davis Medical Center 2315 Stockton Blvd ASB 1300 Sacramento, Ca 95817 916-734-0536 SYSTEMS PROGRAMMING.. Guilty, until proven innocent !! JN 2004 Hardware eventually breaks - Software eventually works anon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
EXECIO
I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
try allocating with disp shr - default is old ALLOC F(INDD) da(dsnname) SHR -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Maria Brown Sent: Wednesday, February 18, 2009 1:13 PM To: IBM-MAIN@bama.ua.edu Subject: EXECIO I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
execio
You can try: ALLOC F(INDD) da(dsnname) shr reuse But if the other application has exclusive, there could still be a problem Lucy Arnold Storage Manager U.C. Davis Medical Center 916-734-5498 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? There is a reason to do this. It's called data integrity. You have been lucky with ISPF EDIT. With a PDS, you can destroy a member if two users are updating the same library and different members. Why do you need to do this? You're walking a tight-rope without a net. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Maria, You may need to add a DISP(SHR) to your ALLOC. I also do not see where you are updating a particular member, that could also be a problem. I do not know the exact syntax for updating a member, but would be worth you while to investigate it. Just my 2 cents worth. HTH Fletch snip I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
AUTO: Alan Brown is out of the office on personal business (returning 02/19/2009)
I am out of the office until 02/19/2009. I am attending to some personal matters today and will be unavailable. If you need immediate assistance, please contact Pete Kohler or Jimmy Wilson. You will receive this message only once. Note: This is an automated response to your message EXECIO sent on 2/18/09 13:13:08. This is the only notification you will receive while this person is away. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
when Alias was Created
This is a first for me.. so, I ask the Group if there is a way to know when a Alias was defined and/or any history of its last referenced date to more or less get an idea of when it was last allocated. any example would be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
OPS/MVS Rexx Question with SQL
I am trying to help a friend create some OPS/MVS Rule to read the STCTBL and retrieve only those entries that begin with CICS on LPARx. I know in SQL you can code Select * from STCBL Where name like 'CICS' However I am not finding something similar in OPS/MVS Rexx. Any body point me in the right direction? Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
Rick, You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. The best cache candidates I have found are actually random IO. The first controller I used was a 3880-23 with 8MB of cache and volumes like SYSRES, Checkpoint1, MIM and RACF improved throughput radically. 350 IOPS for a controller was unheard of at that time. The success of random IO depends on the locality of reference of the IO requests. I found VSAM files with clusters of IO around particular keys - new, active customers vs old, dormant customers or some company phone numbers - get excellent benefit from cache, while databases with hashed keys like IMS Fast Path and CA-IDMS were nasty cache polluters. YMMV. Back to the Jason's original idea of excluding some IO from cache; I'm afraid you're out of luck. At bests you can use DCME with MSR in SMS to influence how some controllers will retain or discard an IO once it is in cache, but in all vendor offerings - HDS, IBM, SUN and EMC - everything must go through cache. Inhibit Cache Load and Bypass Cache do not do what they say. Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. Ron snip-- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip- In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
I think the answer is NO. There is no date tracking on Alias that I am aware of. You could try to spin SMF data as far back as possible to see when the first dataset under that alias was created. However, the second part, an alias is only used to find the right catalog for a data set to be created. Say the HLQ is MYALIS I would use 3.4 in ISPF to display all datasets under MYALIS and then SORT REFERRED. The most recenttly created dataset would be at the top. Unless I am mis understanding your question. It might help if you could diagram an output listing your would like to see. Alias Name Create Date Last Used Date Or perhaps Dataset Name under ALIAS X Created on Date Last Used on Date or some similar diagram. Lizette This is a first for me.. so, I ask the Group if there is a way to know when a Alias was defined and/or any history of its last referenced date to more or less get an idea of when it was last allocated. any example would be appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Based on other posts and my RTFM, the DISP(SHR) is incorrect, you just need to add SHR to you ALLOC. I apologize for the faux paus in the syntax. Maria, You may need to add a DISP(SHR) to your ALLOC. I also do not see where you are updating a particular member, that could also be a problem. I do not know the exact syntax for updating a member, but would be worth you while to investigate it. Just my 2 cents worth. HTH Fletch snip I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
The only information that I have is the Alias. Nothing More.. tried smf and nothing. It looks that I will have to delete and see if anyone screams. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
The purpose behind cache is to reduce the amount of time elapsed between issuing a read request and having data to process. If the data to be read is in cache because someone just read or wrote it or the controller was doing sequential read ahead, I do not care. I did not have to wait on the slow DASD to position and transfer the data. That is a valid read hit in my book. Dennis Roach GHG Corporation Lockheed Marten Mission Services Flight Design and Operations Contract Address: 2100 Space Park Drive LM-15-4BH Houston, Texas 77058 Mail: P.O. Box 58487 Mail Code H4C Houston, Texas 77258 Phone: Voice: (281)336-5027 Cell: (713)591-1059 Fax:(281)336-5410 E-Mail: dennis.ro...@lmco.com All opinions expressed by me are mine and may not agree with my employer or any person, company, or thing, living or dead, on or near this or any other planet, moon, asteroid, or other spatial object, natural or manufactured, since the beginning of time. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ron Hawkins Sent: Wednesday, February 18, 2009 12:58 PM To: IBM-MAIN@bama.ua.edu Subject: Re: High DASD disconnect time due to RANDOM READ Rick, You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. The best cache candidates I have found are actually random IO. The first controller I used was a 3880-23 with 8MB of cache and volumes like SYSRES, Checkpoint1, MIM and RACF improved throughput radically. 350 IOPS for a controller was unheard of at that time. The success of random IO depends on the locality of reference of the IO requests. I found VSAM files with clusters of IO around particular keys - new, active customers vs old, dormant customers or some company phone numbers - get excellent benefit from cache, while databases with hashed keys like IMS Fast Path and CA-IDMS were nasty cache polluters. YMMV. Back to the Jason's original idea of excluding some IO from cache; I'm afraid you're out of luck. At bests you can use DCME with MSR in SMS to influence how some controllers will retain or discard an IO once it is in cache, but in all vendor offerings - HDS, IBM, SUN and EMC - everything must go through cache. Inhibit Cache Load and Bypass Cache do not do what they say. Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. Ron snip--- --- I have discovered we have been experiencing high disconnect time to most our LCUs/DASDs due to NORMAL/RANDOM read CACHE misses (only 50% hit ratio). I have read somewhere that NORMAL read normally is not recommended for CACHING and was suggested to be excluded. My question is have anyone here implemented this to exclude the NORMAL read thru SMS storage class? After the exclusion, does it really improve the IO performance? how to handle those files both have normal/sequential read? TIA. -unsnip - In my experience, sequential datasets get the MOST benefit from the use of cache, while randomly accessed files get the lowest benefit. When I first starting using cache, if I got a 50% cache hit ratio, I tended to add more cache, and watch the hit ratio rise. I most HIGHLY Reccomend that you use cache for ALL sequential read processing. LOW rates of random access might not suffer too much from being uncached, but medium to high rates of random access might be more adversely affected by not using cache. You could experiment, carefully, for the effects on your random access files, but I don't think there are ANY good grounds for not caching all sequential access datasets. Ditto for partitioned datasets. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search
Re: when Alias was Created
Never delete, just rename In case you really do need it. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Arturo Sent: Wednesday, February 18, 2009 2:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: when Alias was Created The only information that I have is the Alias. Nothing More.. tried smf and nothing. It looks that I will have to delete and see if anyone screams. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
If you are sure there are no datasets under the alias. And there are no jobs that try to create ALIAS.?? datasets that are temporary and are deleted just as quickly as they are created. I would do a LISTC ENT(alias) and print that off just incase I would have to recreate the alias back. Lizette The only information that I have is the Alias. Nothing More.. tried smf and nothing. It looks that I will have to delete and see if anyone screams. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
On Wed, 18 Feb 2009 13:12:15 -0600, Arturo wrote: The only information that I have is the Alias. Nothing More.. tried smf and nothing. It looks that I will have to delete and see if anyone screams. If it is an ordinary alias and there are no data sets cataloged, you might be safe to delete it. if there is a RACF profile for that HLQ, you might get a clue as to when the alias was created. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
On Wed, 18 Feb 2009 18:34:23 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? There is a reason to do this. It's called data integrity. You have been lucky with ISPF EDIT. With a PDS, you can destroy a member if two users are updating the same library and different members. I disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). I'm sure the archives are filled with information about this sort of thing. Besides the SHR recommendation, the OP may want to consider using ISPF services to write to the PDS. Then they will be playing by the same rules as everyone else. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Health Checker in z/OS 1.10 Memlimit
I don't have 1.10 running yet, but someone reported to me that my RXSTOR64 exec told them to call home. I have a check in there for in a subroutine that converts memory amounts to their largest possible unit. FORMAT_MEMSIZE: // /* The following code is used to display the storage size in*/ /* the largest possible unit. For example, 1023G and 1025G are */ /* displayed as 1023G and 1025G, but 1024G is displayed as 1T. */ /* The size passed to the routine must be in MB.*/ // Anyway, my check for displaying MEMLIMIT as NOLIMIT looks for RAXLVMEMLIM = 17592186040320 - 16 exabytes. However, the value reported for health checker in z/OS 1.10 (at least for this person) is 17592186048514. Did z/Architecture just grow? :-) The fix is easy enough... to check for = 17592186040320, but I am curious how this happened. Other than HC, all the other ASIDs with nolimit have 17592186040320 in the RAX. Regards, Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
You didn't specify disposition. it defaulted to OLD. Try 'SHR' at the end of the alloc statement. ITschak On Wed, Feb 18, 2009 at 8:13 PM, Maria Brown brown...@hotmail.com wrote: I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
As far as I know, the only date information you can get is to list the ALIAS entry in the catalog and see when it was defined. If you can find any datasets defined under that alias, you can use the Dataset Audit Facility from the CBT site to look through SMF for references. A VTOC list or similar list of datasets under that alias might tell you when they were last referenced. --snip-- This is a first for me.. so, I ask the Group if there is a way to know when a Alias was defined and/or any history of its last referenced date to more or less get an idea of when it was last allocated. any example would be appreciated. --unsnip-- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: when Alias was Created
Thank you all for your reply's.. I checked with the RACF group (as Tom mentioned) and they were able to tell me when they were created/given access. Again Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
I suppose so, but you really don't want to do that. You are being stopped from a very good likelihood of corrupting the file. DISP OLD is appropriate unless you have some other exclusivity mechanism to serialize updates. I'm not sure, but I think your REXX would completely destroy the target PDS by converting it to sequential unless 'dsanme' included a member name. As others note, ISPF edit is a very sophisticated file manager that protects down to the member level. I'd second the suggestions to use ISPF EDIT services to accomplish the mission. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Maria Brown Sent: Wednesday, February 18, 2009 12:13 PM To: IBM-MAIN@bama.ua.edu Subject: EXECIO I am writing to a partitioned dataset via the EXECIO command. The dataset is also currently in use by an active application, which causes my EXECIO command to fail with DATA SET IS ALLOCATED TO ANOTHER JOB OR USER. Is there anway to get around this with execio? I can manually edit and save the file without any problems while the dataset is in use by the app. ALLOC F(INDD) da(dsnname) execio * DISKW indd (STEM LINES. FINIS Free File(indd) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: rexx to get storgrp
Cool! Thanks for everyone help! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Stopping FTP
On Wed, 18 Feb 2009 11:38:33 -0500, Gary DiPillo gdipi...@axiosproducts.com wrote: John, The P command should do it. On my system, the D A,L command shows that the server is called FTPSERVE, so I use P FTPSERVE to shut it down. S FTPSERVE (the name of my FTP Server proc) starts it again. ... A side comment (since the original issue has gone away). The case mentioned above is a special case for 8-character proc names. For cases like the original poster's where the proc name is shorter than 8 characters the original program running under proc abcd will start another address space named abcd1 and terminate. Therefore, to stop the server you have to issue P abcd1. The OP's example of FTPD / FTPD1 is correct. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Interesting! Haven't seen or heard of this in years and years. I see a 'member in use' message just trying to open the member in a second instance of ISPF edit in the same session or different user. AFAIK, when you open a member in ISPF, it is with update intent and a sysplex wide exclusive enqueue goes up. I wonder if there is some issue with your GRS configuration? -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, February 18, 2009 2:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: High DASD disconnect time due to RANDOM READ
--snip- You may find that Sequential IO cache benefits are something of an illusion. While cache is involved, the benefit actually comes from the pre-fetch process, where the storage controller is fetching tracks asynchronous to the host requests and staying ahead of the next host request. Even though cache statistics show 100% cache hit you will find that almost every IO had to be read from the disk. Because sequential IO must always come from the disk, it will be one of the first things to suffer when there is sibling pend on an Array Group. -unsnip-- We tested with a pair of purpose-built programs, on a 3990-6 controller and again on RAMAC II and RAMAC III, and again on our SHARK box, with substantially the same kinds of results. The first program re-read the same sequential dataset, of 100 cylinders, over and over, for a total of 100 passes. While the RAMAC and SHARK tests weren't complete, 'cuz we couldn't turn off the cache, on the 3990 testing the results were stunning. Elapsed time was reduced by 65% when we enabled the cache in the 3990, and the device response time, as shown by RMF, was halved. The second program used a random-number generator to select records from a DIRECT dataset, using BDAM access. Improvement was noticeable with cache enabled, but not anywhere as surprising as the results from our sequential dataset tests. The datasets were preloaded with 100 cylinders of half-track records in both sets of tests. IEBDG was used to create records with a relative record number in the first 6 bytes, and random strings in the remainder of the record. Subsequent experience showed very good improvements in our IDMS database performance, but since we used several small areas for each database, spread across multiple volumes, locality of reference was fairly high. We actually reached a point where the IDMS CV was inhibited because it couldn't get LOG records written out fast enough. As you note, RACF and JES2 Checkpoint performance gained amazing improvements, again due to high locality of reference. -snip--- Jason, I'd be interested in the paper that says NORMAL Read IO is not recommended for cache, as in most shops I have analyzed random read IO represents greater than 80% of all cache hits - it is what cache was designed for. Your references may need updating. -unsnip--- I'd like to see that as well. -- Rick -- Remember that if you’re not the lead dog, the view never changes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Interesting! Haven't seen or heard of this in years and years. I see a 'member in use' message just trying to open the member in a second instance of ISPF edit in the same session or different user. The issue is if the member name is different. AFAIK, when you open a member in ISPF, it is with update intent and a sysplex wide exclusive enqueue goes up. Not until save/end. While you're editing, there is no update intent. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Sorry Ted, but I believe you are wrong again. I just did a test based on the exact situation you outlined, and had no problem whatsoever (as I expected). Ted MacNEIL eamacn...@yahoo.ca 2/18/2009 3:11 PM disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: OPS/MVS Rexx Question with SQL
You could probably use the below somehow. The manuals on the CA website are quite good, so I'd check those first. table = 'SWZ_STCTBL' ADDRESS SQL SELECT NAME INTO :TASK FROM table WHERE CURRENT_STATE = 'UP' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
On Wed, 18 Feb 2009 20:11:53 +, Ted MacNEIL eamacn...@yahoo.ca wrote: disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. Ted, you are completely wrong on this issue. Was your test done in a sysplex or MIMplex with the correct ENQ propagation? Or did you do it from two different environments that shouldn't have been sharing at the PDS level to begin with (it's okay to share if data sets are protected by RESERVE). I wish I had time to debate... but I'm off to a DR drill. I'm sure others who understand and live in environments with hundreds of ISPF users editing the same PDSes across systems in a sysplex and don't run into the problem you've described will chime in. Perhaps you should read the ISPF manuals also. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:mark.zel...@zurichna.com 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Sorry Ted, but I believe you are wrong again. I just did a test based on the exact situation you outlined, and had no problem whatsoever (as I expected). Fine. I did it with ISPF EDIT (1.4, two systems, two members, a single PDS) two users, one saved then the other did. This is not a memory thing. It failed, two years ago. If something has changed, I'd like to know what it was. I even remember the comment: Doug's member was corrupted!. We got a big laugh over that. I did say PDS, not PDSE. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
To be fair, I don't think Ted is 'wrong'. He is simply reporting observed behaviors of his system. Many of us seem to be of the opinion that Ted's system is malfunctioning or misconfigured. I believe Ted to be describing an environment where GRS (or equivalent) needs some attention. I suppose there might be some exits that could muddy the water. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Wednesday, February 18, 2009 2:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Sorry Ted, but I believe you are wrong again. I just did a test based on the exact situation you outlined, and had no problem whatsoever (as I expected). Ted MacNEIL eamacn...@yahoo.ca 2/18/2009 3:11 PM disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Thank you for that. What is missing? It was a 4000 MIPS 5-image SYSPLEX with two members running TSO. We had many PDS member issues. Plus, many SMSPDSE 'corrupt' messages issued. I'm more of a performance/capacity type, and haven't used SMP, since SMP4. I am not trying to mislead, but I've been able to re-create the (different) members update problem without even trying. - Too busy driving to stop for gas! -Original Message- From: Hal Merritt hmerr...@jackhenry.com Date: Wed, 18 Feb 2009 15:02:34 To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO To be fair, I don't think Ted is 'wrong'. He is simply reporting observed behaviors of his system. Many of us seem to be of the opinion that Ted's system is malfunctioning or misconfigured. I believe Ted to be describing an environment where GRS (or equivalent) needs some attention. I suppose there might be some exits that could muddy the water. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Wednesday, February 18, 2009 2:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Sorry Ted, but I believe you are wrong again. I just did a test based on the exact situation you outlined, and had no problem whatsoever (as I expected). Ted MacNEIL eamacn...@yahoo.ca 2/18/2009 3:11 PM disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
PDSE corruption is a different issue. Plenty on that in the archives. SMP/E is not relevant to this context AFAICT. To diagnose the PDS corruption issue, I'd start in my GRS parms. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, February 18, 2009 3:18 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Thank you for that. What is missing? It was a 4000 MIPS 5-image SYSPLEX with two members running TSO. We had many PDS member issues. Plus, many SMSPDSE 'corrupt' messages issued. I'm more of a performance/capacity type, and haven't used SMP, since SMP4. I am not trying to mislead, but I've been able to re-create the (different) members update problem without even trying. - Too busy driving to stop for gas! -Original Message- From: Hal Merritt hmerr...@jackhenry.com Date: Wed, 18 Feb 2009 15:02:34 To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO To be fair, I don't think Ted is 'wrong'. He is simply reporting observed behaviors of his system. Many of us seem to be of the opinion that Ted's system is malfunctioning or misconfigured. I believe Ted to be describing an environment where GRS (or equivalent) needs some attention. I suppose there might be some exits that could muddy the water. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Scott Rowe Sent: Wednesday, February 18, 2009 2:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Sorry Ted, but I believe you are wrong again. I just did a test based on the exact situation you outlined, and had no problem whatsoever (as I expected). Ted MacNEIL eamacn...@yahoo.ca 2/18/2009 3:11 PM disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. As recently as z/OS 1.4, I have seen two people corrupt members using ISPF with different member names. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html NOTICE: This electronic mail message and any files
Re: Rexx / edit macro bug?
snip I would expect it to leave the member with line 401 at the top, and the cursor on line 412, pos21. The FIND string is on line 412 - I want the cursor to stay with the FOUND string, but to change the line that appears at the top of the display. /* rexx */ address isredit macro FIND WS-MODULE-IDENTIFIER locate 401 cursor = 412 21 snip *With* the FIND command, it positions the display according to my EDITSETting Target Line for Find/etc, ignoring the LOCATE command. I created a test member in a COBOL source code PDS with a comment line 412 that has the string WS-MODULE-IDENTIFIER in column 21. I ran your macro while editing this member and I got the expected results exactly as you describe above. I tried several different permutations of this including altering my EDITSETing for the find position but was not able to reproduce your error. It always worked as expected here. We are on ISPF release 5.9 Bill Bass Senior Applications Developer United Health Care Greenville, SC This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
Agreed, if the proper QNAMES were not being propagated then this type of thing could occur, but that is a configuration problem, not a code problem. Hal Merritt hmerr...@jackhenry.com 2/18/2009 5:17 PM PDSE corruption is a different issue. Plenty on that in the archives. SMP/E is not relevant to this context AFAICT. To diagnose the PDS corruption issue, I'd start in my GRS parms. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
On Wed, 18 Feb 2009 20:11:53 +, Ted MacNEIL wrote: Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). When you edit a PDS member, the file is not open for output. The member is just a memory copy. It's opened for output, when you save it. ISPF keeps information in memory, but does not re-read the directory. So, if two people (or more) are editing members, directory already read, the last saver 'wins'. Ummm. If two users edit the same member of a Classic PDS (not PDSE), not concurrently but consecutively, with no overlap, it's got to re-read the directory (or at least do a BLDL) because the STOW associated with the SAVE changes the TTR. Otherwise the design is very wrong. With a PDSE, if the second user has done a BLDL, the directory change will not appear until he does a CLOSE. Then the BLDL result becomes invalid and another BLDL is needed. Try it! You won't like it. I did a test with some of our developers, just about two years ago. The data was corrupted. If by corrupted, you mean last person wins, that's WAD. When I update a shared PDS, even in batch, I use ISPF LM services. I've experienced one instance of corruption, when MIM had crashed on the system the other lady was using (ISPF EDIT of a different member; I found her member with my member name; identified her from the member content and asked our sysprog what might have failed.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
On Wed, 18 Feb 2009 13:33:07 -0600, Mark Zelden wrote: On Wed, 18 Feb 2009 18:34:23 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I disagree with Ted that you've been lucky with ISPF edit since it does use an ENQ to protect on a member level basis. But that only works if everyone plays by those rules. Also there has been some extra protection for a *long* time that keeps two tasks from opening a PDS for output (IEC143I 213-30 abend). I'm sure the archives are filled with information about this sort of thing. (Sorry I neglected to include this in my previous post). See: Link that you currently have selected Linkname: Appendix A. ISPF enqueue processing for data integrity URL: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ISPZPC70/A.0 -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
My test was: 1. Two users open the same PDS (note: no E). 2. Select X; Select Y (one for each user) 3. Type something. 4. One save; two save. Whomever saved second 'WON'. I have not tried since z/OS 1.4, two years ago. So, what ENQ's do I need? We tried on the same system, and on separate systems. This PDS 'corruption' has been around longer than I have. And, it's not the same member name. - Too busy driving to stop for gas! -Original Message- From: Scott Rowe scott.r...@joann.com Date: Wed, 18 Feb 2009 18:05:22 To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Agreed, if the proper QNAMES were not being propagated then this type of thing could occur, but that is a configuration problem, not a code problem. Hal Merritt hmerr...@jackhenry.com 2/18/2009 5:17 PM PDSE corruption is a different issue. Plenty on that in the archives. SMP/E is not relevant to this context AFAICT. To diagnose the PDS corruption issue, I'd start in my GRS parms. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, February 18, 2009 5:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO My test was: 1. Two users open the same PDS (note: no E). 2. Select X; Select Y (one for each user) 3. Type something. 4. One save; two save. Whomever saved second 'WON'. I have not tried since z/OS 1.4, two years ago. So, what ENQ's do I need? We tried on the same system, and on separate systems. This PDS 'corruption' has been around longer than I have. SNIP Ok, being a pilot and all, I've made a landing for fuel, so I've topped off my tanks (to comply with FAA regs concerning reserves and all that). Let's back up to the mid-'90s. I have run the test Ted describes across systems and in the same DOMAIN (hey it was an Amdahl shop). The test called for ACS/WYLBUR and TSO/ISPF using the documented ISPF ENQUEUES. This was a STANDARD TEST when I was an ACS/WYLBUR developer (MVS/SP4 through OS/390 V1R1) in the mid-'90s. TODAY, we run the same situation where I work, only we are all TSO/ISPF users. We have been running this way with z/OS 1.7 through and including z/OS 1.10. Prior to working here, I have been at customer sites running OS/390 V2R9 through z/OS 1.4. One customer site was running z/OS 1.1 with three LPARs all sharing DASD. We did not have MIM. We did not get crushed PDS members EXECPT for when I made the mistake of running multiple assemblies with LNKEDTs to the same load library. There we wound up with a screwed up directory and bad members. MY OWN FAULT for NOT using DISP=OLD. Today (actually, it was during summer 2008) I ran tests with some code that I wrote using the ISPF ENQUEUES. The only time we have had a problem is when simultaneous update of the DIRECTORY is attempted (and I did my best to make sure that two STOWs happening together was part of the testing). As someone else pointed out, you will get an ABEND for that one -- system protecting you from yourself. In fact, my attempting the same old thing of multiple assemblies/link jobs now will ABEND when one BINDER is attempting to write to the same load library as another BINDER at the same time (I knew about that protection and attempted to make use of it). Also, I can, between three TSO/ISPF sessions, edit a PDS, and get the LATEST copy of a member, even though the DIRECTORY hasn't been refreshed (from my perspective). By that I mean, I can list a PDS with one account (A) and edit the same PDS from (B) and once (B) saves and ends with the xyz member, (A) can now edit xyz w/o a manual refresh. I know that this works with 1.8 and up (because those are the levels I'm logged on to). Now, there may be something happening under the covers here, because we do have TRX (only for TSO sessions). But I thought that it only cached the BLDL info for load, CLIST/REXX and panel libraries. So, Ted, as a few others have pointed out, you must have something wrong with the configuration where you are. Regards, Steve Thompson -- Opinions expressed by poster may not be those of poster's employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
mmm. If two users edit the same member of a Classic PDS (not PDSE) Please NOTE! I NEVER said the same member! I went out of my way to say DIFFERENT members. My comments example were all about DIFFERENT!! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
I tried with two ids, same pds, different members, same monoplex with no surprising results. Both members were updated as expected. I tried with same id value, same pds on shared dasd, different members, different monplexes with no surprising results. Both members were updated as expected. z/OS 1.9 Dave Gibney Information Technology Services Washington State University -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Wednesday, February 18, 2009 3:29 PM To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO My test was: 1. Two users open the same PDS (note: no E). 2. Select X; Select Y (one for each user) 3. Type something. 4. One save; two save. Whomever saved second 'WON'. I have not tried since z/OS 1.4, two years ago. So, what ENQ's do I need? We tried on the same system, and on separate systems. This PDS 'corruption' has been around longer than I have. And, it's not the same member name. - Too busy driving to stop for gas! -Original Message- From: Scott Rowe scott.r...@joann.com Date: Wed, 18 Feb 2009 18:05:22 To: IBM-MAIN@bama.ua.edu Subject: Re: EXECIO Agreed, if the proper QNAMES were not being propagated then this type of thing could occur, but that is a configuration problem, not a code problem. Hal Merritt hmerr...@jackhenry.com 2/18/2009 5:17 PM PDSE corruption is a different issue. Plenty on that in the archives. SMP/E is not relevant to this context AFAICT. To diagnose the PDS corruption issue, I'd start in my GRS parms. CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
I tried with two ids, same pds, different members, same monoplex with no surprising results. Please tell me what's changed! I did this, and got bad results. I'm surprised, since on 1.4, I got what I said. What did I do wrong? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
is my job in input queue?
Hi I am looking for a program solution to check if a job is waiting in the input queue. Does any one have a programatic solution using rexx or assembler? Or any manual I can get the information ? Thanks in advance. Regards, Al -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: is my job in input queue?
Do you have JES2 or JES3? You can use the ST command in TSO to look though you may need to add a modification to see any job. Do you need something for batch and foreground? What will you do should you find a job waiting on the input queue? What is the over all intent of your process? Lizette Hi I am looking for a program solution to check if a job is waiting in the input queue. Does any one have a programatic solution using rexx or assembler? Or any manual I can get the information ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXECIO
On Thu, 19 Feb 2009 01:34:56 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I tried with two ids, same pds, different members, same monoplex with no surprising results. Please tell me what's changed! OPEN. I did this, and got bad results. I'm surprised, since on 1.4, I got what I said. What did I do wrong? - The change to add the SYSZDSCB ENQ was around the early to mid 90s IIRC. Long before anyone heard of OS/390 - let alone z/OS. Okay... it took me a while, but I found the apar that added the support. It was even earlier than I thought. DFP/XA 2.3 (HDP2230). APAR OY07766 and the PTF was available 12/14/1987 - UY15908. APAR Identifier .. OY07766 Last Changed 99/04/20 DSCB INTEGRITY SUBJECT TO EXPOSURE Symptom .. IN INCORROUT Status ... CLOSED PER Severity ... 3 Date Closed . 87/11/20 Component .. 566528413 Duplicate of Reported Release . 230 Fixed Release 999 Component Name DFP/XA O/C/EOV Special Notice Current Target Date .. Flags SCP ... Platform Status Detail: ASSIGNMENT - APAR has been assigned to a programmer. PE PTF List: PTF List: Release 230 : UY15908 available 87/12/14 (F802 ) Parent APAR: Child APAR list: ERROR DESCRIPTION: IN ORDER TO PROTECT THE INTEGRITY OF THE DSCB OF PDS'S FROM: 1. TWO OR MORE USERS OPEN TO DIFFERENT MEMBERS OF A PDS DATASET FOR OUTPUT WITH DISP=SHR *** DOES NOT APPLY TO OPEN FOR UPDAT ( UPDATE ) 2. UPDATING THE DATE LAST REFERENCED FIELD IN THE DSCB FOR THE FIRST ACCESS OF THE DAY WHEN THE FIRST ACCESS OF THE DAY IS FOR READ (DISP=SHR), ALSO KNOWN AS THE MIDNIGHT PROBLEM. NOTE: THIS APAR ADDS A RETURN CODE (RC30) TO THE ABEND213 MSGIEC143I ABEND213-30 ADDITIONAL SYMPTOMS: MSGIEB189I LOCAL FIX: PROBLEM SUMMARY: * USERS AFFECTED: ALL USERS USING PDS DATASETS * * PROBLEM DESCRIPTION: CORRUPTION OF A PARTIONED DATASET'S* * DIRECTORY WHICH THEN GIVES SYMPTOMS * * OF LOST MEMBERS, DUPLICATE TTRS, OR * * CORRUPTED MEMBERS OF THE PDS. * * RECOMMENDATION: INSTALL THE PTF * THIS APAR ADDRESSES TWO PROBLEMS. THE FIRST PROBLEM OCCURS WHEN A USER ALLOCATES A PDS WITH DISP = SHR AND THEN OPENS A MEMBER FOR OUTPUT. THE USER KEEPS THE PARTIONED DATASET OPEN THROUGH MIDNIGHT. ANYTIME AFTER MIDNIGHT, A SECOND USER OPENS THE SAME DATASET FOR INPUT. THE SECOND OPEN READS THE FMT1 DSCB TO UPDATE THE DATE-LAST-REFERENCED FIELD. AFTER THAT THE FIRST USER CLOSES THE DATASET AND CLOSE WRITES BACK THE FMT1 DSCB, THE DS1LSTAR AND DS1TRBAL FIELDS WOULD THEN GET UPDATED TO REFLECT THE NEW LOCATION OF THE MODIFIED MEMBER. WHEN THE SECOND OPEN WRITES BACK THE FMT1 DSCB, THE VALUES OF DS1LSTAR AND DS1TRBAL WILL NOW GET RESET WITH THEIR OLD VALUES WHICH WOULD, IN EFFECT, LOSE THE CHANGED MEMBER FROM THE FIRST OPEN. THE SECOND PROBLEM OCCURS WHEN TWO USERS HAVE ALLOCATED A PDS WITH DISP = SHR AND EACH ONE OPENS THE DATASET FOR OUTPUT TO WORK ON DIFFERENT MEMBERS. ONE OF THE USERS UPDATES MAY BE LOST BECAUSE THEY EACH HAVE THE SAME COPY OF THE DIRECTORY AND THE LAST ONE FINISHED WILL CAUSE THE DIRECTORY TO REFLECT ONLY HIS CHANGES. IF THE FIRST USER CAUSED A NEW MEMBER TO BE ADDED, THAT NEW MEMBER WOULD NO LONGER EXIST. IF THE FIRST USER HAD MODIFIED A MEMBER, ITS DIRECTORY ENTRY WILL NOW POINT TO THE SECOND USERS MEMBER (DUPLICATE TTR'S). PROBLEM CONCLUSION: THE PDS CORRUPTION WILL BE ELIMINATED BY USING TWO NEW RESOURCES THAT WILL BE ENQUEUED UPON DURING OPEN AND CLOSE PROCESSING. THESE NEW ENQUEUES WILL BE PERFORMED ONLY IN SOME CIRCUMSTANCES. MOST OF THE CHANGES ARE INTERNAL TO THE SYSTEM AND WILL NOT BE NOTICED BY THE END USER WITH ONE EXCEPTION. IF USERA ALLOCATES A PDS WITH DISP = SHR AND OPENS THE DATASET FOR OUTPUT AND USERB ALLOCATES THE SAME PDS WITH DISP = SHR AND ALSO ATTEMPTS TO OPEN THIS DATASET FOR OUTPUT, USERB'S OPEN WILL NOW FAIL WITH AN ABEND213-30. THIS WOULD HAVE SUCCEEDED PRIOR TO THE FIX AND ALMOST CERTAINLY WOULD HAVE CORRUPTED THE DIRECTORY. THE NEW RESOURCES BOTH HAVE THE SAME MAJOR NAME OF SYSZDSCB. THE MINOR NAMES (RNAME) ARE SIMILAR AND WORK TOGETHER TO SERIALIZE OUTPUT TO THE PARTITION DATASET. THE MINOR NAMES CONSIST OF: VOLSER+MODE+DSN WHERE THE MODE CAN EITHER BE AN A OR AN S. THE RESOURCE WITH MODE EQUAL TO S IS ENQUEUED UPON WHEN A PDS IS OPENED WITH A DISPOSITION = SHARE (EITHER
Re: EXECIO
Okay! I surrender! It wasn't there, at the time. We blew the files off the map! Sorry, but it happened! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Automove vs Noautomove in BPXPRMxx
Since nobody asked so far: You don't have SYSPLEX(YES) in your BPXPRMxx, do you? -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
