Re: ANTP0102I ESTAB. PAIR FAILED- DEVICES NOT IN SUSPEND
What is the current state fo the devices? Issue a CQUERY. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heh. Speaking of Java
I'm thinking it is most likely either an installation or configuration problem. REGION size? Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SSL and IMS Connect
Hi, *** posted in the IMS-L listserver, but no reaction. Hence cross posted in IBM-MAIN RACF-L *** We are currently using IMS V9 and Web Application Servers on Unix that connect to IMS Connect. To ensure that only trusted WAS machines connect to IMS Connect, we have written a security exit in IMS Connect that basically just checks every incoming IP-address. The allowed IP-addresses are hardcoded in a table. We are now revaluating this security design and one of the things that come into scope is SSL for IMS Connect. SSL could be used to validate the client by exchanging certificates, public and private keys. These questions pop up: Are there people amongst you who already do SSL with IMS Connect? Experiences to share? Performance issues to look after? Gotchas? Any other special considerations we need to pay attention to? Other (better ?) alternatives? Jan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newbie Questions!
Through the ISPVCALL STATUS function, I found that the system I'm on is a zArch 2064 with 4 CPUs; however, is there a way I can retrieve [snip] All that being said it could be a 2064-104, 2064-1C4, or a 2064-2C4 depending on features. You can use the command D M=CPU to find your model number. The ISPVCALL command tells you the number of General Purpose processors (GCPs) the current LPAR (i.e. z/OS image) has. The machine itself might have more GCPs being used by other LPARs (z/OS or other operating system images). Also there are zAAP and zIIP processors which, while physically identical to GCPs, are only being used to execute certain types of threads (JAVA tasks and DB2 SRBs). Those processors do not appear in the model number. If you have access to RMF, a partition data report will give you more details about the physical machine. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe population
I don't suppose the attendants will carry their shops to Baltimore, that's what William asked... (could't resist). Kees. Tom Schmidt [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, 19 Jul 2006 09:54:59 -0700, George, William (DHS-ITSD) wrote: My wife and I are looking to spread our wings, move that is. Is there a site or information available listing metropolis' with the greatest mainframe shop populations? Yes, there is! It will be the City of Baltimore next month - at SHARE. Be there. (Couldn't resist!) -- Tom Schmidt Madison, WI (I plan to be there) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. ** -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG in deferred roll-in status
Thanks guys, I feel so much better. That's why i couldn't remember the command, there isn't one. There are tons of these at our site and they are all left over from many many moons ago. IE. The one in deferred rollin state is G0049V00 whereas the (say) 2 entries are G0934V00 and G0935V00 That seems to back up what all of you were saying and now I think (long and hard) about it, I used to do the same as John and rename them to .GooxxVoo o not 0 Figure i'll change to the Z000V00 format as it may save confusion for anyone that doesn't spot the oh instead of zero and spends hours listing the base and trying to find out what the problem is. On the other hand.it may be a good test of one's diagnostic skills (only kiddin' - I wouldn't do that to a brother dinosaur (well there are a couple of..)) Thanks all, JJ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3590E K.
Rugel José wrote: Hi: I have this problem with a new tape 3590E k ( green one ) : CBR4105I No MEDIA3 scratch volumes available in library LIB3494. CBR4196D Job ZAVAZ169, drive 0D02, volser SCRTCH, error code 140169. The code 69 indicates there is no scratch volume MEDIA3, but this new tape is MEDIA4 into Tape Library 3494: VOLUME STORAGE MEDIA SERIAL GRP NAME SHELF LOCATION TYPE -(2)-- --(7)--- --(19)-- -(8)-- MZ0169 *SCRTCH* MEDIA4 My question is : How can I tell to the system to use MEDIA4 istead of MEDIA3 ?. IMHO it is responsibility of your SMS ACS routines, DATACLASS routine. This is the place, where MEDIAx and drive (i.e. 256TRK) are selected. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES3 to JES2 Migration
- Original Message Hi, Would anyone have a project plan for doing the above or any pointers to documentation that I would find useful when embarking on such a task? Kind Regards Mark Mark, I found the 'JES3 White Paper' from E.Jaffe very useful to understand the functionalities of both JES, and to see if such migration is worth. I did a presentation some years ago at a customer site here in Germany who wanted to migrate to JES2, too. Eventually, they didn't do it. Once you see all the implications (time, money, operating education, automation update, etc), you just leave your good, old JES3 where it is. Maybe Edward can tell you the link where the paper is stored. Just my 2 Cents. Walter Marguccio z/OS Systems Programmer Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
It's an interpreted language. And its an OO language which has somewhat more overhead than traditional non-OO languages. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG in deferred roll-in status
Bruce Black wrote: Can't remember the command to remove the entry from the base but keep the dataset or, for another example get rid altogether. a DEFERRED generation is not really part of the base. In the catalog, there is a GDG sphere record for the base, with all the generations within it. A deferred gen is cataloged outside that sphere as a normal non-VSAM dataset. However, catalog knows that it is related to the base. If you want to unrelate it, I think you can just rename it to a non-GDG. However, there is a flag in the NVR that says I am a deferred generation (probably in the catalog as well) and I don't know what trouble that might cause later. AFAIK, deferred dataset can be tricky: // DD DSN=GDG.BASE(+1),DISP=(NEW,CATLG) will not create new dataset, existing deferred da=GDS will be used instead. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
Then the question becomes: Does the JVM tell the z/OS dispatcher move the work from the zAAP to a general CPU while doing a JNI call? Or does it leave it on the zAAP? The JVM marks the task as being zAAP eligible or non-eligible. The dispatcher puts zAAP eligible tasks on the zAAP work unit queue and dispatches tasks from there on zAAPs (or GCPs in some cases). Don't ask me *how* it marks the task, I have no idea. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES3 to JES2 Migration
Walter Marguccio wrote: I found the 'JES3 White Paper' from E.Jaffe very useful to understand the functionalities of both JES, and to see if such migration is worth. I did a presentation some years ago at a customer site here in Germany who wanted to migrate to JES2, too. Eventually, they didn't do it. Once you see all the implications (time, money, operating education, automation update, etc), you just leave your good, old JES3 where it is. Maybe Edward can tell you the link where the paper is stored. Glad you found it valuable Walter! You can find it at ftp://ftp.phoenixsoftware.com/pub/demo/JES3_White_Paper.pdf. Other (useful?) links: http://www.share.org/member_center/open_document.cfm?document=proceedings/SHARE_in_Boston/ACF1CDF.pdf http://www.share.org/member_center/open_document.cfm?document=proceedings/SHARE_in_Boston/s2735eja.pdf ftp://ftp.phoenixsoftware.com/pub/demo/JES3_to_JES2_User_Experience.pdf -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
RES: JES3 to JES2 Migration
Walter Marguccio wrote: I found the 'JES3 White Paper' from E.Jaffe very useful to understand the functionalities of both JES, and to see if such migration is worth. I did a presentation some years ago at a customer site here in Germany who wanted to migrate to JES2, too. Eventually, they didn't do it. Once you see all the implications (time, money, operating education, automation update, etc), you just leave your good, old JES3 where it is. Maybe Edward can tell you the link where the paper is stored. We have successfully migrated a 4 MIPS installation (+30 Lpars) in less than 1 year. No big issues. Atenciosamente / Regards / Saludos Ituriel do Nascimento Neto Banco Bradesco S/A 4254/DPCD Alphaville Suporte Técnico - Software Básico Mainframes Tel: 55 11 4197-2021 Fax: 55 11 4197-2814 AVISO LEGAL BR Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é dirigida, podendo conter informação confidencial e/ou legalmente privilegiada. Se você não for destinatário desta mensagem, desde já fica notificado de abster-se a divulgar, copiar, distribuir, examinar ou, de qualquer forma, utilizar a informação contida nesta mensagem, por ser ilegal. Caso você tenha recebido esta mensagem por engano, pedimos que nos retorne este E-Mail, promovendo, desde logo, a eliminação do seu conteúdo em sua base de dados, registros ou sistema de controle. Fica desprovida de eficácia e validade a mensagem que contiver vínculos obrigacionais, expedida por quem não detenha poderes de representação. +**+ LEGAL ADVICE BR This message is exclusively destined for the people to whom it is directed, and it can bear private and/or legally exceptional information. If you are not addressee of this message, since now you are advised to not release, copy, distribute, check or, otherwise, use the information contained in this message, because it is illegal. If you received this message by mistake, we ask you to return this email, making possible, as soon as possible, the elimination of its contents of your database, registrations or controls system. The message that bears any mandatory links, issued by someone who has no representation powers, shall be null or void. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
The 1% Rule
Interesting. IBM-MAIN postings probably follow this rule. http://technology.guardian.co.uk/weekly/story/0,,1823959,00.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ANTP0102I ESTAB. PAIR FAILED- DEVICES NOT IN SUSPEND
Hi, Peter Attached is the command output of CQUERY and D M=DEV(). Please take a look! Much appreciate it in advance. JC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 1READY CQUERY DEVN(X'D7FB') VOLUME CQUERY FORMATTED LVL 3 VOLUME REPORT ** PPRC REMOTE COPY CQUERY - VOLUME * (PRIMARY) (SECONDARY) * * SSID CCA LSS SSID CCA LSS* *DEVICE LEVEL STATE PATH STATUS SERIAL# SERIAL#* *-- - -- --- -- * * D7FB . SIMPLEX... INACTIVE D007 FB 17 .. * * ... ... 00011526 * * PATHS SAID DEST STATUS: DESCRIPTION * * - - -- --- * * 0 00NO PATH * * 00NO PATH * * 00NO PATH * * 00NO PATH * * SUBSYSTEM WWNN LIC LEVEL * * --- --- * * PRIMARY 80.5.70.0 * CQUERY COMMAND COMPLETED FOR DEVICE D7FB. COMPLETION CODE: 00 READY CQUERY DEVN(X'D7FB') PATHS CQUERY FORMATTED LVL 3 PATHS REPORT *** PPRC REMOTE COPY CQUERY - PATHS * PRIMARY UNIT: SERIAL#= 00011526 SSID= D007 SS= 2105 LSS= 17 * * FIRSTSECOND THIRD FOURTH* *SECONDARY SECONDARY SECONDARY SECONDARY * *SERIAL NO: 00011462 * * SSID LSS: D807 17 ... ... ...* *PATHS: 4 0 0 0 * * SAID DEST S* SAID DEST S* SAID DEST S* SAID DEST S* * * - -- - -- - -- - -- * *1: 4004 2617 01 00 00 00 * *2: 4014 3617 01 00 00 00 * *3: 4024 0617 01 00 00 00 * *4: 4034 1617 01 00 00 00 * * SUBSYSTEM WWNN LIC LEVEL * * --- --- * * PRIMARY 80.5.70.0 * * * * S* = PATH STATUS:* * 00=NO PATH 01=ESTABLISHED ESCON 02=INIT FAILED* * 03=TIME OUT 04=NO RESOURCES AT PRI 05=NO RESOURCES AT SEC* * 06=SERIAL# MISMATCH 07=SEC SSID MISMATCH 08=ESCON LINK OFFLINE * * 09=ESTABLISH RETRY 0A=PATH ACTIVE TO HOST 0B=PATH TO SAME CLUSTR* * 10=CONFIG ERROR FF=UNABLE TO DETERMINE * CQUERY COMMAND COMPLETED FOR DEVICE D7FB. COMPLETION CODE: 00 READY END D M=DEV(D7FB) IEE174I 11.47.01 DISPLAY M 532 DEVICE D7FB STATUS=ONLINE CHP DA DB DC DE ENTRY LINK ADDRESS14 14 1C 1C DEST LINK ADDRESS 2C 2C 34 34 PATH ONLINE YYYY CHP PHYSICALLY ONLINE YYYY PATH OPERATIONAL YYYY MANAGED NNNN CU NUMBER D007 D007 D007 D007 MAXIMUM MANAGED CHPID(S) ALLOWED: 0 DESTINATION CU LOGICAL ADDRESS = 17 SCP CU ND = 002105.000.HTC.55.00011526.0021 SCP TOKEN NED = 002105.000.HTC.55.00011526.1700 SCP DEVICE NED= 002105.000.HTC.55.00011526.17FB
Re: GDG in deferred roll-in status
Joe, IE. The one in deferred rollin state is G0049V00 whereas the (say) 2 entries are G0934V00 and G0935V00 This could happen if G0049V00 was restored by DFSMSdss after it had rolled out of the GDG and the number of generations was already at the limit or the TGTGDS parameter was set or allowed to default to DEFERRED. I remember the alter rollin command because DSS did not have TGTGDS parameter when SMS came out. I remember the TGTGDS parameter because I had to do alot of alter rollin commands. Two different scars that I have collected over the years. Figure i'll change to the Z000V00 format as it may save confusion for anyone that doesn't spot the oh instead of zero and spends hours listing the base and trying to find out what the problem is. On the other hand.it may be a good test of one's diagnostic skills (only kiddin' - I wouldn't do that to a brother dinosaur (well there are a couple of..)) I am the one in greatest need of protection from my own actions. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES3 to JES2 Migration
On 20 Jul 2006 01:38:32 -0700, in bit.listserv.ibm-main you wrote: - Original Message Hi, Would anyone have a project plan for doing the above or any pointers to documentation that I would find useful when embarking on such a task? Kind Regards Mark Mark, I found the 'JES3 White Paper' from E.Jaffe very useful to understand the functionalities of both JES, and to see if such migration is worth. I did a presentation some years ago at a customer site here in Germany who wanted to migrate to JES2, too. Eventually, they didn't do it. Once you see all the implications (time, money, operating education, automation update, etc), you just leave your good, old JES3 where it is. Maybe Edward can tell you the link where the paper is stored. Having done this migration 18 years ago, I can say that the things that enabled the migration to be fairly good one were: 1. The shop was just a JES3 global. 2. We were implementing CA-7 for jobs scheduling anyway. 3. We were implementing CA-Dispatch for report management and this probably forced doing a good job of that implementation. 4. We were able to pick up mods from the CBT tape that I upgraded to JES2 1.3.4 and was able to set jobclass based on time, number of tapes and TCAM queues. These mods were resubmitted as a part of the Philips Lighting mods by Laurel Yates. 5. Simple WTO exits took care of tape drive contention. The reason for the switch were: 1. The rest of Philips was JES2 (Lighting was sold by Westinghouse which was a JES3 company). 2. JES2 was cheaper. 3. SNA NJE was free in JES2 and an added cost in JES3 (Bulk Data Transfer was required). 4. Although we didn't take advantage of it you could have SMS in XA under JES2 but not JES3. Yesterday, I read that a new NJE function will be available only in JES2. The JES3 folks have yet to learn that if they are going to justify their higher cost, they have to provide virtually all of the function JES2 does plus the unique JES3 function. I like a lot of the things in JES3 but I didn't notice that much degradation in function after the switch. Just my 2 Cents. Walter Marguccio z/OS Systems Programmer Germany -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES3 to JES2 Migration
Clark Morris wrote: Yesterday, I read that a new NJE function will be available only in JES2. The JES3 folks have yet to learn that if they are going to justify their higher cost, they have to provide virtually all of the function JES2 does plus the unique JES3 function. I like a lot of the things in JES3 but I didn't notice that much degradation in function after the switch. Which new NJE function will be available in JES2 only? Where did you read this? -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG in deferred roll-in status
Tom, However, there is a flag in the NVR that says I am a deferred generation (probably in the catalog as well) and I don't know what trouble that might cause later. Wouldn't that be the same flag, Bruce? As I understand it, the BCS just points to the volume and everything else is kept in the VVDS. Active generations are kept in the B (GDG base) record in the BCS. Datasets that are deferred or rolled out have a type A (simple dataset) record. When you create a +1 SMS gds, it is cataloged with type A record until you roll it into the GDG base (type B) record. If the GDG is already at the limit, the oldest generation is rolled off the B record to make room for the +1. If the GDG has scratch, the rolled off generation is uncataloged and scratched. If the GDG has noscratch, the rolled off SMS-managed generation is recataloged in a type A record. I run scans every now and then looking for gdgs with noscratch and fix them. Since I use utilities to find deferred or rolled out GDS so I don't know what flag bits are used or where to find them. Regards, John -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
Radoslaw writes The memory is not unique design. There are regular DIMMs inside the book. High quality, ECC, good brand, but still same technology as in PC. Memory controllers are probably completely different, but the back-end (DIMMs) are not. The PARTS that are used in the box are pretty much the same as other commodity parts. True enough. The DESIGN of the way they are put together, the circuitry, EDC/ECC, page-modes etc. are predicated on the TSO (ie total store order not timesharing option) memory model and the z architecture storage consistency rules documented in PoPs. The DESIGN of the z memory subsystem (and caches) is only distantly related to the memory subsystem design in a commodity PC. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ANTP0102I ESTAB. PAIR FAILED- DEVICES NOT IN SUSPEND
JC, I may be missing something but your inital question was about device C5A9 and your CQUERY is for device D7FB. Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
Craddock, Chris wrote: Radoslaw writes The memory is not unique design. There are regular DIMMs inside the book. High quality, ECC, good brand, but still same technology as in PC. Memory controllers are probably completely different, but the back-end (DIMMs) are not. The PARTS that are used in the box are pretty much the same as other commodity parts. True enough. The DESIGN of the way they are put together, the circuitry, EDC/ECC, page-modes etc. are predicated on the TSO (ie total store order not timesharing option) memory model and the z architecture storage consistency rules documented in PoPs. The DESIGN of the z memory subsystem (and caches) is only distantly related to the memory subsystem design in a commodity PC. This is matter of meaning. The back-end is almost the same as in PC. This modules are NOT significantly faster than in regular PC. Probably overall memory solution is faster and more reliable than bunch of DIMMs - per analogia to disk systems. Single SCSI (or FC) drive in modern DASD box is the same as in (better) PC. However the disk system is significantly more reliable (RAID), faster (cache) and more featured (i.e. remote copy). From the other hand - is there so huge difference between DIMMs and zMemory ? Personally I doubt. AFAIR (I could be wrong) the number of DIMMs suggest the total memory is simply sum of DIMM capacities. In other words: no RAID-like solution, probably some cache-like solution, probably faster and wider memory bus. Regards -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is z series so CPU poor?
What follows is taken from discussion of the MVCL instruction in the current Principles of Operation: | | As part of the execution of the instruction, the values | of the two length fields are compared for the setting | of the condition code, and a check is made for | destructive overlap of the operands. Operands are | said to overlap destructively when the first-operand | ocation is used as a source after data has been | moved into it, assuming the inspection for overlap is | performed by the use of logical operand addresses. | When the operands overlap destructively, no movement | takes place, and condition code 3 is set. | Of chief interest here is the fact that execution of an MVCL is suppressed when destructive overlap would have occurred if it had been executed. It is possible to build machines that behave very differently. Many System/360 and System/370 clones were, for example, built not to suppress but to truncate such operations not just ast overlap but at storage-protection boundaries. Or again, z/Architecture machines and their predecessors can optionally detect FIXEDOVERFLOW. They do not do so in C because C was developed for a machine that could not do so. (As often, an ineluctable limitation was converted into a virtue.) Literally hundreds of similar points could be made. Architectures are extraordinarily difficult to compare unless one knows rather more about them than most of the contributors to this thread appear not just to know but even to know that they do not know. John Gilmore Ashland, MA 01721-1817 USA _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is z series so CPU poor?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Thursday, July 20, 2006 9:15 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Why is z series so CPU poor? snip Architectures are extraordinarily difficult to compare unless one knows rather more about them than most of the contributors to this thread appear not just to know but even to know that they do not know. Very true, at least for me. And that I why I ask questions here. To become more knowledgeable about the zSeries hardware. And to answer questions like: Why can't the zSeries do ... as cheaply as the xSeries? Remember that a large number of people in executive decision positions don't care about much but the bottom line. Why pay for x when y is so much less expensive? Especially if the decision makers cannot determine any real difference? You must tell them in answers that they understand. And, for me, just saying more reliable is not enough. I need to know more. That is likely a techie-geek failing of mine. John Gilmore Ashland, MA 01721-1817 USA -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This message (including any attachments) contains confidential information intended for a specific individual and purpose, and its content is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this transmission, or taking any action based on it, is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG in deferred roll-in status
Somethings, like the SMS classes are stored in BOTH the catalog and VVDS. I don't recall if the GDG flag is among them (I'm at home now, no references) now that I am at the office, I verified that there is an attribute byte that is both in the catalog and the NVR (if it is SMS) for GDGs. It contains H for active generation, N for deferred roll-in, and M for rolled off. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
There are quite a few reasons, rather than just one single one. The biggie IMO is that z architecture is demonically complex to implement in silicon. It has always amazed me that IBM is able to put out a new processor every year or two with little or no hardware logic errors. I know from articles in the technical journals that they do extensive testing, but heck, in the software industry, we do extensive testing and we STILL have to put out a significant number of fixes. Kudos to the hardware developers! -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ANTP0102I ESTAB. PAIR FAILED- DEVICES NOT IN SUSPEND
What is bizzare is that the ANTP0102I message is clearly documented to apply to MODE(RESYNC) which requires that the pair be in SUSPEND state, but you clearly specified MODE(COPY).Sounds like an IBM bug, either the message is issued incorrectly or it has another undocumented meaning. I can't find anything on IBMLINK, so I suggest you open a problem with IBM. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
How do we know the number of hardware design errors? With IA32, it's easier to discover these problems because the CPU is used by many people under many operating systems. IBM designs the OS and CPU, making it much easier to cover up any problems that do exist. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Bruce Black Sent: Thursday, July 20, 2006 10:46 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Why is zSeries so CPU poor? There are quite a few reasons, rather than just one single one. The biggie IMO is that z architecture is demonically complex to implement in silicon. It has always amazed me that IBM is able to put out a new processor every year or two with little or no hardware logic errors. I know from articles in the technical journals that they do extensive testing, but heck, in the software industry, we do extensive testing and we STILL have to put out a significant number of fixes. Kudos to the hardware developers! -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
LPALST, Duplicate Modules, and Alias Question
I have an LPALST concatenation PRODUCT.LPALIB SYS1.LPALIB In PRODUCT.LPALIB is MODULE1 (no alias) In SYS1.LPALIB is MODULE1 with alias ALIAS1 After IPL (with CLPA of course) I can get to MODULE1 but not to ALIAS1. Because MODULE1 is a duplicate I expect to get it from PRODUCT.LPALIB (which I do) because it is first in the concatenation. But because ALIAS1 is not a duplicate I would expect to still be able to get to it even if it is from SYS1.LPALIB. Can anyone confirm that ALIAS1 should be dropped because of the duplicate of MODULE1? Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FINDIMBD Tool (was Re: z/OS 1.7 VSAM)
I'm hoping Mark Thomen is monitoring the list this morning! :-) I need to resurrect an old post. I'm running FINDIMBD and am seeing something somewhat disturbing. I'm looking for catalogs that have the IMBED parameter on them. Here is the JCL I'm running. // EXEC PGM=FINDIMBD //STEPLIB DD DSN=WSC.TEST.LOADLIB,DISP=SHR //SYSOUT DD SYSOUT=H //SYSIN DD * CATALOG.** Here is the last line from the output: CATALOG.TSO.UCAT IMBED Here is a partial listing from the LISTCAT output for this catalog: LISTING FROM CATALOG -- CATALOG.TSO.UCAT CLUSTER --- ASSOCIATIONS DATA-CATALOG.TSO.UCAT INDEXCATALOG.TSO.UCAT.CATINDEX DATA --- CATALOG.TSO.UCAT SHROPTNS(3,4) SPEED UNIQUE NOERASE INDEXED NOWRITECHK NOIMBED NOREPLICAT UNORDEREDNOREUSE SPANNEDNOECSHARE ICFCATALOG INDEX -- CATALOG.TSO.UCAT.CATINDEX SHROPTNS(3,4) RECOVERY UNIQUE NOERASE NOWRITECHK NOIMBED NOREPLICAT UNORDERED NOREUSE ICFCATALOG Sorry about the line wrap and so on. The version of FINDIMBD I'm running is dated 9/2/04. I'm in the process of converting all my catalogs to remove the IMBED. I converted 4 of them yesterday and the other three no longer show up in the list, but this one still does. Is there a problem with FINDIMBD? Any other suggestions? Thanks. Rex -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
=== -Original Message- From: McKown, John [EMAIL PROTECTED] Sent: 7/20/2006 9:13 AM To: IBM-MAIN@BAMA.UA.EDU IBM-MAIN@BAMA.UA.EDU Subject: Re: Why is zSeries so CPU poor? -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kuredjian, Michael Sent: Thursday, July 20, 2006 9:59 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Why is zSeries so CPU poor? How do we know the number of hardware design errors? With IA32, it's easier to discover these problems because the CPU is used by many people under many operating systems. IBM designs the OS and CPU, making it much easier to cover up any problems that do exist. It depends on where the error is. If it is in some of the more exotic instructions or facilities not normally used by a standard application program, then you are likely correct. If the problem is that UNPK is broken, then everybody will notice. This was proven in the original CMOS processor where the mantra was don't use packed decimal, it performs very slowly! due to the fact that most of the packed decimal instructions went from hardware to millicode. -- John McKown === When TRAP2/TRAP4 was first released on the P390 (sometime around circa 1998-1999 IIRC), it was broken (storing into the TRAPSA in the primary space instead of the home space). We complained and IBM sent out a fix. The P390 apparently had some form of millicode that was easier to change compared to changing silicon (or whatever passes for silicon in a P390). Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
z/Architecture design errors
Michael Kuredjian writes | How do we know the number of hardware design errors? With IA32, it's easier to | discover these problems because the CPU is used by many people under many | operating systems. IBM designs the OS and CPU, making it much easier to cover up | any problems that do exist. IBM does design both, but many others write assembly-language code that exercises these instructions vigorously. Microprocessor assemblers are toys, designed (to quote myself) to discourage their use. The IBM HLASM is a very different, heavily used animal. Mr. Kuredjian's sophomore-cynical comment is, however, wide of the mark in another way. There are two ways to deal with errors in this business. One is to try to keep them secret, fixing them under the covers. The other is to call a shovel a spade as quickly as it has been identified in order to turn one's back upon it as quickly as possible. IBM does the second. The trouble with the first approach is that when, inevitably, dissimulation is detected, it becomes a cause celebre. Even Microsoft learned, after a time, that candor about the security deficiencies of Windows was the only feasible approach. It now has its hand held in the fire much more briefly than used to be the case. It is perhaps also worth noting that, while software errors are expensive, hardware errors are even more expensive and much more embarassing. It is much cheaper to find them before they get into silicon. John Gilmore Ashland, MA 01721-1817 USA _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPALST, Duplicate Modules, and Alias Question
But would the system even load MODULE1 from SYS1.LPALIB into the LPA being that the module is there from the PRODUCT library? My guess is no. If that is the case, no module, by extension, no alias to the module because there wouldn't be a module for it to alias to. Just a guess. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ken Porowski Sent: Thursday, July 20, 2006 10:26 AM To: IBM-MAIN@BAMA.UA.EDU Subject: LPALST, Duplicate Modules, and Alias Question I have an LPALST concatenation PRODUCT.LPALIB SYS1.LPALIB In PRODUCT.LPALIB is MODULE1 (no alias) In SYS1.LPALIB is MODULE1 with alias ALIAS1 After IPL (with CLPA of course) I can get to MODULE1 but not to ALIAS1. Because MODULE1 is a duplicate I expect to get it from PRODUCT.LPALIB (which I do) because it is first in the concatenation. But because ALIAS1 is not a duplicate I would expect to still be able to get to it even if it is from SYS1.LPALIB. Can anyone confirm that ALIAS1 should be dropped because of the duplicate of MODULE1? Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
How do we know the number of hardware design errors? With IA32, it's easier to discover these problems because the CPU is used by many people under many operating systems. IBM designs the OS and CPU, making it much easier to cover up any problems that do exist. IA32??? Nothing in the OS is going to cover up a CPU instruction which is malfunctioning. I suppose that if a bad instruction caused a program check they could add code to intercept and correct it, but if it just gives bad results, tough. I recently described in a posting a processor bug from some years back. They could not change the bad instruction in silicon but they put out a fix which replaced it with a millicode version that was MUCH slower than the silicon. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/990 and MP effect
I'm wondering if anyone has any insight into this issue of MP effect differences with the z/990 z/9 book designs. In particular, it is well known that there is a cost associated with adding CP's because of the additional communication/coordination overhead, however ... how has this changed (if it is known)? For example, PR/SM apparently attempts to maintain CP affinity to the home book if possible ... in addition, there are the cross book issues when addressing memory. It seems that the MP effect on a book is going to be substantially different than the MP effect of cross book references. Anyway ... any info would be appreciated Adam -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LPALST, Duplicate Modules, and Alias Question
I guess the question could be rephrased as Are the alias(s) only loaded with the base module and an alias entry itself ignored? -Original Message- Pommier, Rex R. But would the system even load MODULE1 from SYS1.LPALIB into the LPA being that the module is there from the PRODUCT library? My guess is no. If that is the case, no module, by extension, no alias to the module because there wouldn't be a module for it to alias to. Just a guess. Rex -Original Message- Ken Porowski I have an LPALST concatenation PRODUCT.LPALIB SYS1.LPALIB In PRODUCT.LPALIB is MODULE1 (no alias) In SYS1.LPALIB is MODULE1 with alias ALIAS1 After IPL (with CLPA of course) I can get to MODULE1 but not to ALIAS1. Because MODULE1 is a duplicate I expect to get it from PRODUCT.LPALIB (which I do) because it is first in the concatenation. But because ALIAS1 is not a duplicate I would expect to still be able to get to it even if it is from SYS1.LPALIB. Can anyone confirm that ALIAS1 should be dropped because of the duplicate of MODULE1? Thanks all Ken Porowski AVP Systems Software CIT Group E: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sort and dcollect
berwatt wrote: With idcams/dollect, i use : SORT FIELDS=COPY INCLUDE COND=(9,2,CH,EQ,C'D ') OUTREC IFTHEN=(WHEN=(79,1,BI,EQ,B'1...'), BUILD=(1,4,29,44,C'IS',121,6)), IFTHEN=(WHEN=(79,1,BI,EQ,B'.1..'), BUILD=(1,4,29,44,C'PS',121,6)), IFTHEN=(WHEN=(79,1,BI,EQ,B'..1.'), BUILD=(1,4,29,44,C'DA',121,6)), IFTHEN=(WHEN=(79,1,BI,EQ,B'..1.'), BUILD=(1,4,29,44,C'PO',121,6)), IFTHEN=(WHEN=(80,1,BI,EQ,B'1...'), BUILD=(1,4,29,44,C'VS',121,6)), IFTHEN=(WHEN=NONE, BUILD=(1,4,29,44,C'??',121,6)) question: Can I simplify? Since each of your DFSORT IFTHEN clauses builds essentially the same record with only one different field, you could build the entire record once with a WHEN=INIT clause instead of every time, and then just overlay the one field in the other IFTHEN clauses like this: SORT FIELDS=COPY INCLUDE COND=(9,2,CH,EQ,C'D ') OUTREC IFTHEN=(WHEN=INIT, BUILD=(1,4,5:29,44,49:79,2,51:121,6)), IFTHEN=(WHEN=(49,1,BI,EQ,B'1...'), OVERLAY=(49:C'IS')), IFTHEN=(WHEN=(49,1,BI,EQ,B'.1..'), OVERLAY=(49:C'PS')), IFTHEN=(WHEN=(49,1,BI,EQ,B'..1.'), OVERLAY=(49:C'DA')), IFTHEN=(WHEN=(49,1,BI,EQ,B'..1.'), OVERLAY=(49:C'PO')), IFTHEN=(WHEN=(80,1,BI,EQ,B'1...'), OVERLAY=(49:C'VS')), IFTHEN=(WHEN=NONE, OVERLAY=(49:C'??')) Note that I've copied positions 79-80 from your input record into positions 49-50 of the OUTREC record so we can test and overlay them. Frank Yaeger - DFSORT Team (IBM) - [EMAIL PROTECTED] Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ Frank Yaeger - DFSORT Team (IBM) Specialties: PARSE, JFY, SQZ, ICETOOL, IFTHEN, OVERLAY, Symbols, Migration = DFSORT/MVS is on the Web at http://www.ibm.com/storage/dfsort/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: GDG in deferred roll-in status
Where is the content of the BCS documented? Unfortunately, nowhere. There was the infamous Catalog Diagnosis Reference which had catalog and VVDS layouts but the last version was for MVS/XA many years ago, before SMS. I believe that the SMS class names and this SMS attribute byte are the only fields which are duplicated in the catalog and VVDS. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture design errors
I didn't see much cynicism in my comment, although that may be the result of being jaded by my experience with PC manufacturers and their reluctance to admit and correct problems. I'm very used to both hardware and software manufacturers ignoring obvious problems in their products. I may have mis-used the term cover-up. What I meant was that they[IBM] could release software patches that specifically avoid making use of broken circuits in silicon. However, I wasn't aware that mainframe developers routinely make use of micro-assembly instructions, thereby revealing hardware bugs quickly. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of john gilmore Sent: Thursday, July 20, 2006 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: z/Architecture design errors Michael Kuredjian writes | How do we know the number of hardware design errors? With IA32, it's easier to | discover these problems because the CPU is used by many people under many | operating systems. IBM designs the OS and CPU, making it much easier to cover up | any problems that do exist. IBM does design both, but many others write assembly-language code that exercises these instructions vigorously. Microprocessor assemblers are toys, designed (to quote myself) to discourage their use. The IBM HLASM is a very different, heavily used animal. Mr. Kuredjian's sophomore-cynical comment is, however, wide of the mark in another way. There are two ways to deal with errors in this business. One is to try to keep them secret, fixing them under the covers. The other is to call a shovel a spade as quickly as it has been identified in order to turn one's back upon it as quickly as possible. IBM does the second. The trouble with the first approach is that when, inevitably, dissimulation is detected, it becomes a cause celebre. Even Microsoft learned, after a time, that candor about the security deficiencies of Windows was the only feasible approach. It now has its hand held in the fire much more briefly than used to be the case. It is perhaps also worth noting that, while software errors are expensive, hardware errors are even more expensive and much more embarassing. It is much cheaper to find them before they get into silicon. John Gilmore Ashland, MA 01721-1817 USA _ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture design errors
Kuredjian, Michael wrote: I may have mis-used the term cover-up. What I meant was that they[IBM] could release software patches that specifically avoid making use of broken circuits in silicon. However, I wasn't aware that mainframe developers routinely make use of micro-assembly instructions, thereby revealing hardware bugs quickly. Fixing broken instructions is one potential use of millicode. If the broken instruction is already implemented in millicode, the millicode is simply corrected. If it's implemented in hardware, millicode can intercept its execution and make changes as appropriate. A millicode intercept will usually slow the instruction way down. Better it runs slowly and correctly than quickly and incorrectly. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Internet Service Retrieval
I have been using this for the last 4-5 weeks on 5 different z/OS 1.7 systems with no problems at all. I use to get all the service I want or just a PTF. Feel free to contact on the address below, but remember I am in the UK. Crispin Hugo Systems Programmer, Macro 4 http://www.macro4.com/ Macro 4 plc, The Orangery, Turners Hill Road, Worth, Crawley, RH10 4SS Direct Line: +44 (0)1293 872121 Switchboard: +44 (0) 1293 872000 Fax: +44 (0) 1293 872001 This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation, offer or acceptance of any offer. -Original Message- From: B Sysprog [mailto:[EMAIL PROTECTED] Sent: 20 July 2006 18:49 To: IBM-MAIN@BAMA.UA.EDU Subject: Internet Service Retrieval Has anyone successfully implemented internet service retrieval, IBM's replacement for ESO tape subscriptions with SMP 3.4, Receive Order function? I am continually getting GIM69209S ** RECEIVE PROCESSING HAS FAILED BECAUSE PROGRAM GIMJVCLT COULD NOT BE STARTED. I have a PMR open with IBM and am not getting anywhere. Please supply contact info and we can discuss offline. Thanks, BK Kosmach MVS System Programmer US Steel 412 433 1639 _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. This email has been scanned for all known viruses by the MessageLabs Email Security Service and the Macro 4 plc internal virus protection system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: [Fwd: 64-bits is a really big number! - was z/OS level for SETFRR for AMODE(64)]
Actually the terminology is much more ambiguous than that. Register size, address size, bus size within CPU, bus size to memory, bus size to peripherals, could all be different bit widths, and physical hardware register sizes don't have to match the register sizes of the hardware architecture visible to the user. I'm pretty sure larger IBM mainframes have had some internal bus sizes of 64 bits and larger for years, even though the architecture visible to the user only had 32 bit registers and and 31 bit addresses at the time. Since the introduction of IBM S/360 in the 1960's almost all processors have been implemented using microcoding techniques, which means that the choice of hardware physical bus and register sizes is a matter of cost-performance trade offs rather than something uniquely dictated by the logical architecture seen by the users. Leif Rundberget wrote: Be careful with like terms between the PC(intel) world and the mainframe world. When someone says they have a 64-bit Intel server (Intel, Solaris, AMD, etc.), it does not mean that the server can access an address 64-bits long, the 64-bits refers to the width of the bus. So it can transfer 64-bits in parallel. Leif John KcKown wrote: And, just for fun, Sun has implemented a 128-bit filesystem in Solaris! That means that a single filesystem can contain 2**128 bytes of data. Good heavens! I think that most UNIX filesystems are either 32 or 64 bit at present. But don't quote me on that. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
SMPE V3.3 GIMGTPKG
Has anyone used internet delivery for a zOS ServerPac? I've downloaded the CustomPac Dialog and am trying to receive my order. The GIMGTPKG will transfer a few datasets but croaks in the middle. I restart the job and it xfers a few more and croaks... Always croaks with TYPE I 200 Type set to I. Command: PORT 172,16,90,207,6,173 getNextReply error from recv = (1121.76650446) - EDC8121I Connection reset. Connection with inetsd01.boulder.ibm.com terminated *** I can't open a data-transfer connection: FTP Return Code = 16000, Error Code = 00010 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Internet Service Retrieval
Use BIG region, like 256M. Make sure your exits allow you to really get it. If you STEPLIB, make sure the HFS/ZFS parts are at the same SMP/E level, it won't run out of MIGLIB with mixed levels, but everything else I trided WILL run out of MIGLIB as before. Add a SYSPRINT DD and look for additional errors there. Just my recent scars -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
Leif Rundberget (as quoted by Joel C. Ewing) wrote: | Be careful with like terms between the PC(intel) world and the mainframe | world. When someone says they have a 64-bit Intel server (Intel, | Solaris, AMD, etc.), it does not mean that the server can access an | address 64-bits long, the 64-bits refers to the width of the bus. So it | can transfer 64-bits in parallel. There is once widely used IBM terminology for this quantity. As far back as the System/360, a model 30 had a FETCH WIDTH of one eight-bit byte and the fastest models, as they came along, had fetch widths of eight bytes. Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. John Gilmore Ashland, MA 01721-1817 USA _ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Internet Service Retrieval
What level of SMP are you using? I do not steplib. The region size did not help. Thanks, BK From: Rugen, Len [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Internet Service Retrieval Date: Thu, 20 Jul 2006 13:08:14 -0500 Use BIG region, like 256M. Make sure your exits allow you to really get it. If you STEPLIB, make sure the HFS/ZFS parts are at the same SMP/E level, it won't run out of MIGLIB with mixed levels, but everything else I trided WILL run out of MIGLIB as before. Add a SYSPRINT DD and look for additional errors there. Just my recent scars -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Internet Service Retrieval
34.07 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of B Sysprog Sent: Thursday, July 20, 2006 1:34 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Internet Service Retrieval What level of SMP are you using? I do not steplib. The region size did not help. Thanks, BK From: Rugen, Len [EMAIL PROTECTED] Reply-To: IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Internet Service Retrieval Date: Thu, 20 Jul 2006 13:08:14 -0500 Use BIG region, like 256M. Make sure your exits allow you to really get it. If you STEPLIB, make sure the HFS/ZFS parts are at the same SMP/E level, it won't run out of MIGLIB with mixed levels, but everything else I trided WILL run out of MIGLIB as before. Add a SYSPRINT DD and look for additional errors there. Just my recent scars -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Internet Service Retrieval
On Thu, 20 Jul 2006 14:33:34 -0400, B Sysprog [EMAIL PROTECTED] wrote: What level of SMP are you using? I do not steplib. The region size did not help. Thanks, BK I am at 34.10.Did you review the PSP buckets when you installed SMP/E 3.4? Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group mailto: [EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Abend -407 in Tivoli Decision Support Ver 1.6.0 data Collection Job
Hello List, My current environment is Z/OS V 1.7 and DB2 V 7.1 I am migrating from Tivoli Decision Support for Z/OS Version 1.5.1 to TDS 1.6.0. My problem is when I run data collection job I get a -407 abend . SQLSTATE is 23502 (An insert or update value is null, but the column cannot contain null values.) . I ran the collection program with SQL trace option which is ZZSQLSHOW=STMT. The trace shows the last call before abend -407 is insert to MVS_ACCNT23_PGM_T. I listed URLUPDATES table. The information from the table about MVS_ACCNT23_PGM_T is as follows: UPDATE NAME MVS_ACCNT23_PGM_T SOURCE SMF_030_2_3_X TARGET MVS_ACCNT23_PGM_T In this run of the collection program, this is the first insert to table MVS_ACCNT23_PGM_T. In one of my earlier run of the collection program, two inserts to the table were successful. The third insert abended. If I run the same job with version 1.5.1 libraries, the collection job runs successfully although I have migrated the tables to Version 1.6.1. Thanks for any feedback Ale - Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture design errors
The mainframe is very different from the PC in this regard. You might find the chapter on Machine Check Handling in the POO to be interesting. Mainframes are designed with extensive error detection and recovery capabilities. z/OS records error information to LOGREC to assist in fixing problems. For several years, every CPU chip has been designed with two processors. They both process the same instruction stream against the same data, and the results are compared. If there is a discrepency anywhere along the way, the instruction is aborted and retried. If it fails again, the CPU is switched out and a spare is switched in to restart the instruction stream. In a way, this could be considered a cover-up, but I think not the way you meant it. The program is protected from most hardware failures. Tom Marchant On Thu, 20 Jul 2006 13:11:38 -0400, Kuredjian, Michael [EMAIL PROTECTED] wrote: I didn't see much cynicism in my comment, although that may be the result of being jaded by my experience with PC manufacturers and their reluctance to admit and correct problems. I'm very used to both hardware and software manufacturers ignoring obvious problems in their products. I may have mis-used the term cover-up. What I meant was that they[IBM] could release software patches that specifically avoid making use of broken circuits in silicon. However, I wasn't aware that mainframe developers routinely make use of micro-assembly instructions, thereby revealing hardware bugs quickly. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of john gilmore Sent: Thursday, July 20, 2006 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: z/Architecture design errors Michael Kuredjian writes | How do we know the number of hardware design errors? With IA32, it's easier to | discover these problems because the CPU is used by many people under many | operating systems. IBM designs the OS and CPU, making it much easier to cover up | any problems that do exist. IBM does design both, but many others write assembly-language code that exercises these instructions vigorously. Microprocessor assemblers are toys, designed (to quote myself) to discourage their use. The IBM HLASM is a very different, heavily used animal. Mr. Kuredjian's sophomore-cynical comment is, however, wide of the mark in another way. There are two ways to deal with errors in this business. One is to try to keep them secret, fixing them under the covers. The other is to call a shovel a spade as quickly as it has been identified in order to turn one's back upon it as quickly as possible. IBM does the second. The trouble with the first approach is that when, inevitably, dissimulation is detected, it becomes a cause celebre. Even Microsoft learned, after a time, that candor about the security deficiencies of Windows was the only feasible approach. It now has its hand held in the fire much more briefly than used to be the case. It is perhaps also worth noting that, while software errors are expensive, hardware errors are even more expensive and much more embarassing. It is much cheaper to find them before they get into silicon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
On Thu, 20 Jul 2006 10:45:37 -0400, Bruce Black [EMAIL PROTECTED] wrote: There are quite a few reasons, rather than just one single one. The biggie IMO is that z architecture is demonically complex to implement in silicon. It has always amazed me that IBM is able to put out a new processor every year or two with little or no hardware logic errors. I know from articles in the technical journals that they do extensive testing, but heck, in the software industry, we do extensive testing and we STILL have to put out a significant number of fixes. Kudos to the hardware developers! I agree completely. With nearly 700 instructions defined in the POO, it's amazing that there are not more problems. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
On Thu, 20 Jul 2006 18:29:48 +, john gilmore [EMAIL PROTECTED] wrote: Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. Are you sure? Color me skeptical. Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heh. Speaking of Java
I don't think so, but I will probably try adjusting the REGION size to make sure. Jon snip I'm thinking it is most likely either an installation or configuration problem. REGION size? /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
The 1% Rule
Over 100,000 pageviews on my site in the last 12 months and just five emails about it. The lurker/poster ratio is well known to anyone who's been a sysop, moderator or administrator on a public forum. 100:1 is pretty good - it's usually worse than that. CompuServe was fun because you could download the forum log and see who'd visited. Gates used to visit the Canopus forum I was on back in 1994/5. Never posted. Ballmer did. -- Phil Payne http://www.isham-research.co.uk +44 7833 654 800 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bits is a really big number!
I clearly remember the first (L faster than LH on some machines) but can't comment on the second (64 v. 32). Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: Thursday, July 20, 2006 12:22 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: 64 bits is a really big number! On Thu, 20 Jul 2006 18:29:48 +, john gilmore [EMAIL PROTECTED] wrote: Higher fetch width is good, but it can have odd side effects. There were System/360 models for which Load Halfword (LH) was slower than Load (L) not just because of sign propagation but also because LH fetched four or eight bytes from storage two or six of which then had to be discarded. Analogously, there are z/Architecture situations in which eight-byte (64-bit) instructions are faster than their four-byte (32-bit) variants. Are you sure? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
ICSF Co-Processors
Hello all, I have a question. I have 2 lpars that are sharing the crypto processors in the cpu. Usage domain is 1 and 0 respectively. Is there any reason why only 3 come up on the z/os lpar and 4 come up on the z/OS.e lpar? There are no start up errors on either system that I can see and it has me stumped. z/OS COPROCESSORSERIAL NUMBER STATUS ---- -- . A02 ACTIVE . A03 ACTIVE . X01 94001416 ACTIVE z/OS.e COPROCESSORSERIAL NUMBER STATUS ---- -- . A02 ACTIVE . A03 ACTIVE . X00 94001413 ACTIVE . X01 94001416 ACTIVE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ICSF Co-Processors
Check the crypto config on the image profile. I would guess that you don't have 0 checked on the candidate list and/or online list. If the candidate list is not checked, I think you have to reactivate the LPAR to add it. Richard Ward, Mike S wrote: Hello all, I have a question. I have 2 lpars that are sharing the crypto processors in the cpu. Usage domain is 1 and 0 respectively. Is there any reason why only 3 come up on the z/os lpar and 4 come up on the z/OS.e lpar? There are no start up errors on either system that I can see and it has me stumped. z/OS COPROCESSORSERIAL NUMBER STATUS ---- -- . A02 ACTIVE . A03 ACTIVE . X01 94001416 ACTIVE z/OS.e COPROCESSORSERIAL NUMBER STATUS ---- -- . A02 ACTIVE . A03 ACTIVE . X00 94001413 ACTIVE . X01 94001416 ACTIVE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heh. Speaking of Java
On Wed, 19 Jul 2006 13:09:25 -0400, Jon Brock [EMAIL PROTECTED] wrote: I have a copy of the stack trace from the Tomcat issue, and I am taking it up with some people who should be able to point me in the right direction. I'm thinking it is most likely either an installation or configuration problem. Can you post the stack trace here? -Rob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Why is zSeries so CPU poor?
== -Original Message- From: Gerhard Postpischil [EMAIL PROTECTED] Sent: 7/20/2006 3:53 PM To: IBM-MAIN@BAMA.UA.EDU IBM-MAIN@BAMA.UA.EDU Subject: Re: Why is zSeries so CPU poor? Jeffrey D. Smith wrote: When TRAP2/TRAP4 was first released on the P390 (sometime around circa 1998-1999 IIRC), it was broken (storing into the TRAPSA in the primary space instead of the home space). And I still wonder why they defined the traps the way they did - for my use it would have been easier to treat them as NOPR/NOP when trapping is off. That would allow debugging of LPA resident routines that don't fail when in a steplib (and I've had some of those). Gerhard Postpischil Bradford. == The TRAP2/TRAP4/RP facility is flawed, but still usable in most cases. TRAP should have the option to turn off automatically the trap enablement bit and the option to store into the trapsa with a key in the duct (or trapcb). The resume program (RP) instruction should have a semi-privileged option to turn on trap enablement, as well as setting the key and state bits in the new psw. Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Info-zip on Z/OS 1.6 and up
Thanks, That was the original question. Most of our clients use PKZIP so (originally) it was a question of whether or not it was a problem with the INFO-ZIP software or the installation or the method of transfer. In this case, it turned out to be that we were trying to take a DASD volume that was built under a Hercules (MVS 3.8) system and after conversion and transmitting, load and use it on a Z/OS system. Normally that is not a problem, but (apparently) when you use Shadow volumes, you can't built the image the same way, (you end up with the problem that we ran into). (in retrospect) It would have probably saved a lot of time and effort to get new copies of INFO-ZIP, but there were a number of other datasets on that particular volume and the original XMIT format copy of INFO-ZIP that were also needed on the other end, so we thought things were safe. I have performed that type of transfer many times before, but never with volumes that were quite so heavily shadowed (there were 11 separate shadow files) In this case, saving time ended up costing more time. :( Some day, I hope there will be FTP for the Hercules based MVS system and this type of issue won't even be a bad memory any more. Brian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe population
John, Up there is probably Delaware.. the Credit card company(s) all seem to like the legal system there. Ed On Jul 20, 2006, at 7:20 AM, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Shane On Wed, 2006-07-19 at 09:54 -0700, George, William (DHS-ITSD) wrote: Is there a site or information available listing metropolis' with the greatest mainframe shop populations? A few of us might like to see a list like that. Bet it wouldn't include any Australian cities. Just a WAG, but I'd put NYC first on such a list (Wall Street, et al). No clue where or in what order the rest of the list would contain. Nowadays, one possible reason for entities to conceal such information is that large data centers might make inviting targets for terrorists. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: z/Architecture design errors
I think you mis-interpreted John's remarks. He didn't say anything about mainframe developers extensively writing and testing microcode instructions (which is not a documented user interface), but instead extensively writing and testing z-Architecture assembler code (with the High Level Assembler, which uses instructions documented in the z/OS Principles of Operation, which IS a documented user interface). Outside of IBM, microcode assemblers might be used in a limited educational setting in conjunction with emulated execution to demonstrate principles of microcode development - they would not be used to generate and modify microcode on an actual IBM mainframe processor. As for bypassing broken silicon, IBM over the years has put much effort into making their mainframe hardware able to detect and isolate failing hardware components. At least since introduction of 9672 CMOS mainframes, there are even spare processors that can be used to replace a failed processor. This diagnostic and sparing capability is built into the existing microcode. In the very unlikely event that some instructions documented in the PoOp are found not to perform as advertised, IBM would be compelled to fix the broken microcode so that they do. Eliminating a failing z-architecture instruction from software is not an option, because non-IBM software outside IBM's control could be dependent on any behavior that is documented in the PoOp. Users do not have access to IBM's architecture-defining microcode, and leasing/licensing agreements precludes user access to that microcode; but, IBM can download microcode fixes fairly easily for installation by a local IBM Customer Engineer. Mainframe processors load the defining microcode into the processors at every Power-on Reset, so updating the microcode for fixes or enhancements is not as drastic as on a PC, where the microcode is typically frozen into a physical chip. Software patches and enhancements to IBM's mainframe Operating System and support programs, which utilize the z-architecture machine instructions that are documented in the Principles of Operations, are installed by the installation's own System Programmers. These patches have nothing to do with bugs at the microcode or physical hardware level, which are fixed by IBM Customer Engineers. Over the last 25 years, many of the mainframe microcode patches I've seen have been for enhancements, and most of the remaining bug fixes were for failures that could only occur under an unlikely sequence of events. Over that same 25 years the number of mainframe system failures I've seen that directly relate to mainframe microcode bugs is less than five, and in such cases it was not uncommon that the bug exposure had been present for many months and kazillions of instruction executions before we just happened to hit a triggering sequence of events. I would agree with John about IBM's responsiveness to such issues. IBM regards any failure that takes down mainframe hardware or mainframe operating systems as a serious event and has effective procedures in place for reporting, diagnosing, and resolving such issues. This is one of those areas in which mainframe support is orders of magnitude better than what one finds in the PC world. To be fair to PCs, they do have a much more difficult problem - there is only marginal centralized control for hardware architecture; or, considering requirements for OEM device drivers, for even the core parts of the PC Operating Systems. With the relative chaos that reins in both of these areas, its amazing PCs run as well as they do. Kuredjian, Michael wrote: I didn't see much cynicism in my comment, although that may be the result of being jaded by my experience with PC manufacturers and their reluctance to admit and correct problems. I'm very used to both hardware and software manufacturers ignoring obvious problems in their products. I may have mis-used the term cover-up. What I meant was that they[IBM] could release software patches that specifically avoid making use of broken circuits in silicon. However, I wasn't aware that mainframe developers routinely make use of micro-assembly instructions, thereby revealing hardware bugs quickly. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of john gilmore Sent: Thursday, July 20, 2006 11:40 AM To: IBM-MAIN@BAMA.UA.EDU Subject: z/Architecture design errors Michael Kuredjian writes | How do we know the number of hardware design errors? With IA32, it's easier to | discover these problems because the CPU is used by many people under many | operating systems. IBM designs the OS and CPU, making it much easier to cover up | any problems that do exist. IBM does design both, but many others write assembly-language code that exercises these instructions vigorously. Microprocessor assemblers are toys, designed (to quote myself) to discourage their
Program Call (PC) routine in AMODE(64)
Greetings, What is the earliest z/OS level that will tolerate ETCRE (Entry Table Create) that has the extended addressing mode (ETDEAM) bit set? Thanks in advance Jeffrey D. Smith Farsight Systems Corporation 24 BURLINGTON DR LONGMONT, CO 80501 303-774-9381 direct 303-709-8153 cell 303-484-6170 fax -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe population
The greater Washington, D.C., area should probably get a nomination as well. Yes, many people include Baltimore in that equation. :-) - - - - - Timothy F. Sipples Consulting Enterprise Software Architect, z9/zSeries Tokyo (Serving IBM Japan and IBM Asia-Pacific) E-Mail: [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
