Re: z/OS unsupported programming practice - Finding TSO ECT
I have used this for many many years L R9,PSATOLD-PSA -> TCB L R9,TCBJSCB-TCB(,R9) -> JSCB L R9,JSCBPSCB-IEZJSCB(,R9) -> PSCB USING PSCB,R9 L R8,PSCBRLGB -> RELOGON BUFFER L R8,RLGBECT-RLGB(,R8) -> ECT USING ECT,R8 IHAPSA , IKJTCB , IEZJSCB , IKJPSCB , IKJRLGB , IKJECT , On Thu, 25 Feb 2016 19:57:22 -0600 Anthony Fletcherwrote: :>When running a TSO program it requires a CPPL. When TSO is started by using the TMP, a CPPL is provided, and it can be accessed. :>One of the fields that is a supported programming interface is the ECT (Environment Control Table), and it can be updated. :> :>If a program or command is indirectly invoked eg from ISPF then the CPPL may not be directly available and so will have to be constructed. One of the fields required in the CPPL is the ECT. :> :>For many many years it so happened that the ECT pointer was 8 bytes back from the UPT, so code like the following could be used to find the ECT pointer and store it in the CPPLECT field. :> :>L R1,X'21C' POINT TO TCB :> :> ICM R1,7,X'0B5'(R1) POINT TO JSCB :> :> L R1,X'108'(,R1) POINT TO PSCB :> :> STR1,CPPLPSCB SAVE PSCB POINTER :> :> L R1,X'034'(,R1) POINT TO UPT :> :> STR1,CPPLUPT SAVE UPT POINTER :> :> LAR1,0(,R1) CLEAR HIGH ORDER BYTE :> :> SHR1,=H'8'ASSUME ECT POINTER AT UPT - 8 :> :> MVC CPPLECT,0(R1) PICK UP ECT POINTER :> :>With the application of the following PTFs, for the z/OS 2.1 system at least, this no longer works. :>UA80338 UA80339 UA80340 (which ever is appropriate for the z/OS version). :>For some reason it still works with the z/OS 1.13 version. :>These are security/integrity fixes, hence the APAR is not shown. :>These PTFs are unlikely to be marked PE, so users that have old assembler programs should check to see whether any of them use this method of locating the ECT. :>In the case of z/OS 1.13 which did not abend, it may have found storage that it wsa allowed to address but it may not be a real ECT, and so an overlay may occur. Future maintenance to TMP modules may well cause the ECT to be in a different location to what it has been in for 25-30 years so it is advisable to check any assembler programs that might be using this technique and change to using the correct method. :> :>Documented way is this: :> :>The URLs are not hyperlinks so they have to be pasted into a browser. The fact that the documents are for z/OS 2.2 does not matter the steps are applicable to z/OS 1.13 and z/OS 2.1. :> :>ECT: :> :>- :> :>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v :> :>2r2.ikjd200/ikjd200100.htm?lang=en :> :> :> :>Pointed to by: :> :>CPPLECT field of the CPPL :> :>TPLECT field of the TPL :> :>LWAPECT field of the LWA :> :> :> :>LWA: :> :>- :> :>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v :> :>2r2.ikjd200/ikjd200292.htm?lang=en :> :> :> :>Pointed to by: :> :>ASXBLWA field of the ASXB :> :>JSXL communication field of the JSXL :> :> :> :>ASXB: :> :>--- :> :>http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v :> :>2r2.iead100/iead10094.htm?lang=en
Re: Prefix save area - confused
Not confused. Just didn't remember the hardware correctly. But, I do remember the complaints for 4K out of an entire HIPERSPACE. -teD Original Message From: Jim Mulder Sent: Friday, February 26, 2016 02:15 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Prefix save area - confused > With ESA it was 'absolute' zero. > I remember because we had users complain about the unusable portion > of a HIPERSPACE which was the PSA. > > -teD You are indeed confused, teD. 3090E processors did not have the necessary hardware to implement the Private-Space Control(P) bit, which overrides low-address protection and fetch-protection override. For that reason, MVS/ESA did not map addresses 0-4095 in data spaces on 3090E processors. This had nothing to do with prefixing. The Private-Space Control(P) bit was implemented on 3090S and subsequent processors, so MVS/ESA did map addresses 0-4095 in data spaces on those processors. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN and what it is for
Peter Hunkeler wrote: > One of the unwritten rules, at least in my understanding: Tell who you are! Two ways to do this: Use an email address that shows your name, or, preferably, sign your post with your name, first name at least. > Very true! I tend to help people who are NOT anonymous. From: http://catb.org/esr/faqs/smart-questions.html this little gem to all these anonymous posters : "... don't expect to be treated like a fragile doll just because you're a newcomer with a theatrically hypersensitive soul and delusions of entitlement." ... 'nuff said! Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Prefix save area - confused
> With ESA it was 'absolute' zero. > I remember because we had users complain about the unusable portion > of a HIPERSPACE which was the PSA. > > -teD You are indeed confused, teD. 3090E processors did not have the necessary hardware to implement the Private-Space Control(P) bit, which overrides low-address protection and fetch-protection override. For that reason, MVS/ESA did not map addresses 0-4095 in data spaces on 3090E processors. This had nothing to do with prefixing. The Private-Space Control(P) bit was implemented on 3090S and subsequent processors, so MVS/ESA did map addresses 0-4095 in data spaces on those processors. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file not extending to new volume
This reminds me of an ISMF problem I has last year: did you do some updates to the dataclass definitions. Search the archives for: Heads up: ISMF error using the EOF key. It was solved by PTF UA77758, available in aug 2015. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Greg Shirey Sent: 25 February, 2016 18:50 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume Hmm, thanks for that. It looks like the EA value was NO instead of YES. I'll have to figure out how that happened. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 25, 2016 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume Check for this in your data class DATA CLASS DISPLAY Page 2 of 5 CDS Name . . . . . : ACTIVE Data Class Name . . : DIRECT Data Set Name Type . . . . . : EXTENDED If Extended . . . . . . . . : REQUIRED Extended Addressability . . : YES Record Access Bias . . . . : USER Space Constraint Relief . . . : NO -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Prefix save area - confused
With ESA it was 'absolute' zero. I remember because we had users complain about the unusable portion of a HIPERSPACE which was the PSA. -teD Original Message From: Robert Hahne Sent: Friday, February 26, 2016 01:36 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Prefix save area - confused In MVS/XA , with prefixing, the processors did not use absolute locations 0-4095. Rather, each processor had its own separate PSA and its own prefix register. When a processor is brought on line, the real starting address of its PSA is stored in its prefix register. Whenever the processor uses an address between 0 and 4095, the hardware adds the the contents of the prefix register to the address and uses the result. With prefixing, the address that normally would be the absolute address of the information in the first page of storage becomes an offset from the start of the real PSA. Because each processor's prefix register contains a different address, each processor can address locations 0 to 4095 and reference its own data. In Z/architecture , it used to fix the first 2 pages unlike MVS/XA and the concept did not change AFAIK ... Robert Hahne > Date: Thu, 25 Feb 2016 09:46:00 -0600 > From: 000a2a8c2020-dmarc-requ...@listserv.ua.edu > Subject: Re: Prefix save area - confused > To: IBM-MAIN@LISTSERV.UA.EDU > > On Thu, 25 Feb 2016 07:39:30 +0100, Peter Hunkeler wrote: > > >The 8 KiB area at absolute 0 is the place where the hardware writes > >status information as result of performing the "Store Status" operation. > > Among other things. Those Assigned Storage Locations are defined by > the architecture. Other areas within the PSA are defined by the > operating system. > > >It has existed for longer than PR/SM. I would say, it is owned by the > >hardware. > > >> There is Absolute addressing, real addressing, and virtual addressing. > > > >But wait a minute, isn't there on more level? Absolulte, real, and > >virtual are *within* an LPAR. It is required to support multi-CP > >operating system *instances*. Since PR/SM, each LPAR must have its > >own "absolute address 0", doesn't it? > > Yes. > > >Actually, the requirement has exited since physically partitionable CECs > >had been in place (can't remember exaxtly which were the first such > >machines, 3033, or 308x, or?). > > Probably System/360 model 65MP. For sure model 67. > > >The net would be: Some code is accessing virtual address 0. The DAT > >feature will (with the help of the DAT tables) translate virtual 0 to *a* > >real address (which just happens to always be real frame 0 in z/OS). > >The hardware will recognize an address within the "prefixing area" (8 KiB > >in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier > >architectures?), > > System/360 Principles of operation has described prefixing all the way > back to the -0 level of the manual. You can find it at > http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf > The description is on page 18, under "Multisystem Feature". It is > described there as a 4K area. > > Before the -4 level of the System/370 POO in 1974, the SET PREFIX > instruction was defined. It was not in the -0 edition. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Prefix save area - confused
In MVS/XA , with prefixing, the processors did not use absolute locations 0-4095. Rather, each processor had its own separate PSA and its own prefix register. When a processor is brought on line, the real starting address of its PSA is stored in its prefix register. Whenever the processor uses an address between 0 and 4095, the hardware adds the the contents of the prefix register to the address and uses the result. With prefixing, the address that normally would be the absolute address of the information in the first page of storage becomes an offset from the start of the real PSA. Because each processor's prefix register contains a different address, each processor can address locations 0 to 4095 and reference its own data. In Z/architecture , it used to fix the first 2 pages unlike MVS/XA and the concept did not change AFAIK ... Robert Hahne > Date: Thu, 25 Feb 2016 09:46:00 -0600 > From: 000a2a8c2020-dmarc-requ...@listserv.ua.edu > Subject: Re: Prefix save area - confused > To: IBM-MAIN@LISTSERV.UA.EDU > > On Thu, 25 Feb 2016 07:39:30 +0100, Peter Hunkeler wrote: > > >The 8 KiB area at absolute 0 is the place where the hardware writes > >status information as result of performing the "Store Status" operation. > > Among other things. Those Assigned Storage Locations are defined by > the architecture. Other areas within the PSA are defined by the > operating system. > > >It has existed for longer than PR/SM. I would say, it is owned by the > >hardware. > > >> There is Absolute addressing, real addressing, and virtual addressing. > > > >But wait a minute, isn't there on more level? Absolulte, real, and > >virtual are *within* an LPAR. It is required to support multi-CP > >operating system *instances*. Since PR/SM, each LPAR must have its > >own "absolute address 0", doesn't it? > > Yes. > > >Actually, the requirement has exited since physically partitionable CECs > >had been in place (can't remember exaxtly which were the first such > >machines, 3033, or 308x, or?). > > Probably System/360 model 65MP. For sure model 67. > > >The net would be: Some code is accessing virtual address 0. The DAT > >feature will (with the help of the DAT tables) translate virtual 0 to *a* > >real address (which just happens to always be real frame 0 in z/OS). > >The hardware will recognize an address within the "prefixing area" (8 KiB > >in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier > >architectures?), > > System/360 Principles of operation has described prefixing all the way > back to the -0 level of the manual. You can find it at > http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf > The description is on page 18, under "Multisystem Feature". It is > described there as a 4K area. > > Before the -4 level of the System/370 POO in 1974, the SET PREFIX > instruction was defined. It was not in the -0 edition. > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN and what it is for
To ibmmain.10.ats...@xoxy.net, and other anonymous posters One of the unwritten rules, at least in my understanding: Tell who you are! Two ways to do this: Use an email address that shows your name, or, preferably, sign your post with your name, first name at least. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM-MAIN and what it is for
On 25 Feb 2016 18:19:15 -0800, in bit.listserv.ibm-main (Message-ID:<8702884056351431.wa.fletchanz1.ibm@listserv.ua.edu>) flet...@nz1.ibm.com (Anthony Fletcher) wrote: Like all 'LISTS' the members are there to provide or solicit information, and it is like a club. I agree with much of what you wrote. One of the fundamental assumptions is that before posting a request for help the poster will have done as much as they possibly can to find the answer, and then post the question with documentation of what they have done and why they are in need of help. I think that's a bit strong. If you replace your "possibly can" with "reasonably can" I think it's closer to the truth. This was not written for mainframers, but almost everything in it is applicable to IBM-Main: How to ask questions the smart way: http://catb.org/esr/faqs/smart-questions.html Finally, there's one good way to get people to want to help you on this list: show that you're willing to help other people on this list. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS
On 2/25/2016 4:54 PM, Jesse 1 Robinson wrote: I'm getting into IPCS with no IPCSPARM DD allocated according to both ISRDDN and LISTALC. If you pre-allocate IPCSPARM, it will be used. If you don't, the system parmlib concatenation will be used. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM-MAIN and what it is for
Like all 'LISTS' the members are there to provide or solicit information, and it is like a club. Responding to posts to a list is seldom part of a job description. There are rules for membership of the club. They may not be written down, but they do exist, and some have to be discovered by trial and error. One of the fundamental assumptions is that before posting a request for help the poster will have done as much as they possibly can to find the answer, and then post the question with documentation of what they have done and why they are in need of help. Posting an error message and asking what it means without further investigation is vastly different from posting a message with all the fields and some information about what happened before the message appeared, Unfortunately, some of the people that have joined the list recently seem to think that it is a replacement for a vendor support channel, and they don't provide nearly enough information. This just wastes the time of the people who are prepared to respond, and in the end they will just not respond unless they know what what they advise or recommend will use that information, and inevitably posters will get to be known by name. Posting a question or request for help to any list, but in this case to IBM-MAIN, does not entitle the poster to a response. If a person's posts just cause irritation, then they will not get a response, or if they do get a response and they ignore that response and continue to come back with the same question or request. In other words, if someone wants to learn from the experience of other people then need to respect those other people and not waste their time. Its not a question of whether someone works for an outsourcer or not, its a question of professional integrity. Two sides to that, someone wanting to learn must use published documentation of it they are able, go to courses. The potential responder needs to recognise that there is a problem at the moment around the world where the number of professionally responsible people is dwindling, and the incomers can't instantly learn what has taken 25 years to accumulate. And I am not going to comment on the irresponsible management class that got things into this potential mess. End of rant! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS unsupported programming practice - Finding TSO ECT
When running a TSO program it requires a CPPL. When TSO is started by using the TMP, a CPPL is provided, and it can be accessed. One of the fields that is a supported programming interface is the ECT (Environment Control Table), and it can be updated. If a program or command is indirectly invoked eg from ISPF then the CPPL may not be directly available and so will have to be constructed. One of the fields required in the CPPL is the ECT. For many many years it so happened that the ECT pointer was 8 bytes back from the UPT, so code like the following could be used to find the ECT pointer and store it in the CPPLECT field. L R1,X'21C' POINT TO TCB ICM R1,7,X'0B5'(R1) POINT TO JSCB L R1,X'108'(,R1) POINT TO PSCB STR1,CPPLPSCB SAVE PSCB POINTER L R1,X'034'(,R1) POINT TO UPT STR1,CPPLUPT SAVE UPT POINTER LAR1,0(,R1) CLEAR HIGH ORDER BYTE SHR1,=H'8'ASSUME ECT POINTER AT UPT - 8 MVC CPPLECT,0(R1) PICK UP ECT POINTER With the application of the following PTFs, for the z/OS 2.1 system at least, this no longer works. UA80338 UA80339 UA80340 (which ever is appropriate for the z/OS version). For some reason it still works with the z/OS 1.13 version. These are security/integrity fixes, hence the APAR is not shown. These PTFs are unlikely to be marked PE, so users that have old assembler programs should check to see whether any of them use this method of locating the ECT. In the case of z/OS 1.13 which did not abend, it may have found storage that it wsa allowed to address but it may not be a real ECT, and so an overlay may occur. Future maintenance to TMP modules may well cause the ECT to be in a different location to what it has been in for 25-30 years so it is advisable to check any assembler programs that might be using this technique and change to using the correct method. Documented way is this: The URLs are not hyperlinks so they have to be pasted into a browser. The fact that the documents are for z/OS 2.2 does not matter the steps are applicable to z/OS 1.13 and z/OS 2.1. ECT: - http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 2r2.ikjd200/ikjd200100.htm?lang=en Pointed to by: CPPLECT field of the CPPL TPLECT field of the TPL LWAPECT field of the LWA LWA: - http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 2r2.ikjd200/ikjd200292.htm?lang=en Pointed to by: ASXBLWA field of the ASXB JSXL communication field of the JSXL ASXB: --- http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 2r2.iead100/iead10094.htm?lang=en Pointed to by: ASCBASXB ASCB: --- http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v 2r2.iead100/iead10059.htm?lang=en Pointed to by:
Re: Outsourcing Stories Good or Bad!
What he said! -teD Original Message From: Savor, Thomas (Alpharetta) Sent: Thursday, February 25, 2016 19:39 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: Outsourcing Stories Good or Bad! Vignesh, Until you have had your job (your way of life) ripped away from you, you cant get upset when folks get testy. Management loves to tell their bosses that we are going to Outsource ITsaving boat loads of money, but of course they will get a huge bonus once its Outsourced. Then they will disappear once there is a debris field of problems. Who's going to get them out of the ditch.well those same folks that you either laid-off, forced to retire or if you are lucky, still work there. We know that Outsourced folks aren't as good as local staffproblem is Management doesn't see it that way. They see a Cobol programmer is a Cobol programmernot a Cobol programmer with 40 years experience and 20-30 years on an application verses a Cobol programmer right out of school. Those 40 years of experience has shown me how to code a program or how to fix a problem.unfortunately many times it's because we know what will NOT work. So, once we find a way or method of doing things, we stick with itit's called experience. One of the reasons these guys and gals know s much about Z/oS Operating System is because they didn't start at Z/oS, many started back in the DOS/VS days. My opinion, Systems folks "had" to know a lot more about the Operating System then they do today. They didn't have all the fancy cool tools that say Candle or CA or BMC put out today. Many times, they had to roll up their sleeves and make Programming changes to the Operating System or to an Application in a ditch. >From an application side, there was no such thing as a job scheduler. >Scheduling jobs was a part of the Lead Operators job. Along with knowing what >jobs can run togetherenough memory or what disk packs were mounted. When >was the last time you mounted disk packs each night ?? I used to do it all the >timenow, no one does it. I personally don't like Outsourcing at all. The joke is that, this can be done and no one will notice or there wont be "much" of a cost. How much cost is the Business willing to take ?? How much control are you willing to give up ?? Is it good business to have business in one Country, IT in another ?? Could be HUGE Customer Privacy or Business interests when IT is in a different Country. As a vendor, how do I know that my code will be safe in another Country ?? Sorry guys, off my box nowback to work. Thanks, Tom Savor -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Thursday, February 25, 2016 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! >No one's forcing you to Ed. But I'm guessing you're helping around here >because you love what you do, not because you >want to help "your people" >alone. >One can't learn a lot from equals, and one certainly can't learn a lot from >those who are (for the lack of a more sensitive >phrase) below them. >Sure, if this community doesn't want to help, that means workload mounts for >IBM in the form of a trillion more service >requests lol. >But those who are here to learn will find a way. - Vignesh Mainframe Infrastructure -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
To me, the most important thing that is lost in outsourcing is the friendly call or deskside chat between a curious/puzzled application programmer and a cooperative/knowledgeable systems staff person. In my applications career I have always made it a particular point to be polite and friendly with the systems staff and to cultivate their good opinion of me, since they were usually far more senior in experience and knowledge than I was. I also tried to learn from them and not make the same dumb mistake more than once (OK, maybe twice . . . :). Outsourced systems staff means formal and tightly controlled contact procedures, prioritized question/research lists, where outsourced projects like hardware and software upgrades mean application questions and puzzles get very short shrift and low priority, if indeed they ever get answered at all. Eventually the questions are directed elsewhere (like to this list), or they just do not get answered at all because they are never asked. As a senior applications developer now I get some of the questions and puzzles from other application programmers, even from some of my peers in seniority and experience, because no one person knows it all. The loss of those informal communications channels with the systems staff is IMHO a serious loss to the corporation as well as to the individual programmers. But what do I know, I'm just a programmer, not a manager. The only time I count beans is for chile con carne. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mark Wilson Sent: Wednesday, February 24, 2016 5:31 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Outsourcing Stories Good or Bad! I am working with a client in Europe that is being requested by his senior management team to look at outsourcing their IT systems, including their system z platform. Would anyone be willing to share any war stories of their experiences with Outsourcing good or bad? Offline from the list via email or for anyone attending Share in Texas willing to have a coffee/beer and discuss face to face. Mark -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS
I'm getting into IPCS with no IPCSPARM DD allocated according to both ISRDDN and LISTALC. Maybe that was required for the ancient dump-management facility? . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-302-7535 Office jesse1.robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Thursday, February 25, 2016 11:05 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: IPCS > > What are the risks of giving [IPCS] access to developers? > > Mostly, you risk them learning and understanding more about our > platform > -- and post-mortem debugging -- than they did previously. > > IIRC, IPCS requires READ access to parmlib. If that's an issue, I > believe it might be possible to create a stand-alone parmlib just for > IPCS use. If the IPCSPARM ddname is allocated. that is what IPCS will use for accessing parmlib members. If IPCSPARM is not allocated, IPCS will use the system's parmlib concatenation. IPCS needs the parmlib members which IBM provides. Typically, these are found on the sysres volume in a data set named SYS1.IBM.PARMLIB (or some similar name chosen by the systems programmer). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
Vignesh, Until you have had your job (your way of life) ripped away from you, you cant get upset when folks get testy. Management loves to tell their bosses that we are going to Outsource ITsaving boat loads of money, but of course they will get a huge bonus once its Outsourced. Then they will disappear once there is a debris field of problems. Who's going to get them out of the ditch.well those same folks that you either laid-off, forced to retire or if you are lucky, still work there. We know that Outsourced folks aren't as good as local staffproblem is Management doesn't see it that way. They see a Cobol programmer is a Cobol programmernot a Cobol programmer with 40 years experience and 20-30 years on an application verses a Cobol programmer right out of school. Those 40 years of experience has shown me how to code a program or how to fix a problem.unfortunately many times it's because we know what will NOT work. So, once we find a way or method of doing things, we stick with itit's called experience. One of the reasons these guys and gals know s much about Z/oS Operating System is because they didn't start at Z/oS, many started back in the DOS/VS days. My opinion, Systems folks "had" to know a lot more about the Operating System then they do today. They didn't have all the fancy cool tools that say Candle or CA or BMC put out today. Many times, they had to roll up their sleeves and make Programming changes to the Operating System or to an Application in a ditch. >From an application side, there was no such thing as a job scheduler. >Scheduling jobs was a part of the Lead Operators job. Along with knowing what >jobs can run togetherenough memory or what disk packs were mounted. When >was the last time you mounted disk packs each night ?? I used to do it all >the timenow, no one does it. I personally don't like Outsourcing at all. The joke is that, this can be done and no one will notice or there wont be "much" of a cost. How much cost is the Business willing to take ?? How much control are you willing to give up ?? Is it good business to have business in one Country, IT in another ?? Could be HUGE Customer Privacy or Business interests when IT is in a different Country. As a vendor, how do I know that my code will be safe in another Country ?? Sorry guys, off my box nowback to work. Thanks, Tom Savor -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Thursday, February 25, 2016 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! >No one's forcing you to Ed. But I'm guessing you're helping around here >because you love what you do, not because you >want to help "your people" >alone. >One can't learn a lot from equals, and one certainly can't learn a lot from >those who are (for the lack of a more sensitive >phrase) below them. >Sure, if this community doesn't want to help, that means workload mounts for >IBM in the form of a trillion more service >requests lol. >But those who are here to learn will find a way. - Vignesh Mainframe Infrastructure -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
On Feb 25, 2016, at 2:51 PM, Sankaranarayanan, Vignesh wrote: No one's forcing you to Ed. But I'm guessing you're helping around here because you love what you do, not because you want to help "your people" alone. One can't learn a lot from equals, and one certainly can't learn a lot from those who are (for the lack of a more sensitive phrase) below them. Sure, if this community doesn't want to help, that means workload mounts for IBM in the form of a trillion more service requests lol. But those who are here to learn will find a way. - Vignesh Mainframe Infrastructure - SNIP--- Then have your employer pop for education because that is how *WE* did it. I don't have an issue of answering questions but it is NOT a one way street. Go to SHARE (or your area equivalence). In years past I have paid for my OWN trip to GUIDE/SHARE out of my own pocket. Have you done the same. It occurs to me that you see IBM-MAIN as a one way street, it isn't its a group and we all contribute not just ask questions. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tritus SPF again
Look for vDOS. It is based on DOSBOX and I think a better 16bit emulator, especially for something like this. https://www.vdos.info/ Alan Field Systems Engineer Principal Blue Cross Blue Shield of MN 651.662.3546 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Richard Pinion Sent: Thursday, February 25, 2016 4:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Tritus SPF again I received my USB 3.5 inch diskette drive today. I copied the contents of the diskette to my SSD, and tried to execute TSPF.EXE. It didn't work because it is a 16 bit application. Googled a little, and found DOSBOX. Downloaded and installed DOSBOX. Executed DOSBOX, and I am able to execute TSPF! I'm out $19 just for the sake of being able to do this. Still have those 5.25 diskettes. I'm not sure if they contain the same thing, lower level, or higher level of TSPF. I got a few offers from people to copy the 5.25 diskettes, but I didn't keep those emails. If you're one of them, please contact me offlist, rpinion at netscape dot com, if the offer is still open. Thanks in advance. _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you must not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Tritus SPF again
Nice! I ordered a 3.5 drive too and went through my pile of old disks looking for anything I should try to copy once it arrives. Thanks for the DOSBOX hint, maybe I can install my old Lemmings game disk and pick up where I left off in 1993. And I have a 1991 CTC SPF/2 3.5" disk which should be interesting. Don't know if that's related to TSPF. Richard Pinion wrote: I received my USB 3.5 inch diskette drive today. I copied the contents of the diskette to my SSD, and tried to execute TSPF.EXE. It didn't work because it is a 16 bit application. Googled a little, and found DOSBOX. Downloaded and installed DOSBOX. Executed DOSBOX, and I am able to execute TSPF! I'm out $19 just for the sake of being able to do this. Still have those 5.25 diskettes. I'm not sure if they contain the same thing, lower level, or higher level of TSPF. I got a few offers from people to copy the 5.25 diskettes, but I didn't keep those emails. If you're one of them, please contact me offlist, rpinion at netscape dot com, if the offer is still open. Thanks in advance. _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tritus SPF again
I received my USB 3.5 inch diskette drive today. I copied the contents of the diskette to my SSD, and tried to execute TSPF.EXE. It didn't work because it is a 16 bit application. Googled a little, and found DOSBOX. Downloaded and installed DOSBOX. Executed DOSBOX, and I am able to execute TSPF! I'm out $19 just for the sake of being able to do this. Still have those 5.25 diskettes. I'm not sure if they contain the same thing, lower level, or higher level of TSPF. I got a few offers from people to copy the 5.25 diskettes, but I didn't keep those emails. If you're one of them, please contact me offlist, rpinion at netscape dot com, if the offer is still open. Thanks in advance. _ Netscape. Just the Net You Need. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
An ISPF Editor RFE to vote for (or not...)
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe_ID=84517 Description: It is possible to limit both the "width" and "depth" of the ISPF editor F(ind), C(jange) and (e)X(clude) commands, by specifying bounds and labels. Of these two, the bounds ("width") can be set using the "BOUNDS" primary and/or "BNDS" line commands, and once set it will remain in force until changed. However, there is no mechanism to limit the operation of the above commands for a "depth" range, other than to specify the line-labels on which the commands need to operate again and again, or eXclude all lines not of interest and use the NX operand of the above commands. What is proposed is that an additional Edit/View command is added that allows the user to set the vertical bounds to two user-defined labels, as in "VB(ound) .a .b". All subsequent Find. Change. and eXclude commands would then be limited to operating on just the lines between inclusive the .A and .B labels, without the user having to respecify them over and over again. A "VB(ound) RES(et)" would reset this mode, as would the "RES(et) LAB(el)" command, or even the "RES(et)" command all by itself. Use case: = It's pretty common to perform a number of Find, Change and/or eXclude commands on a small set of lines in the editor. The addition of the proposed "VB(ound)" command would make it easier to perform these operations without having to respecify the range over and over again. Robert -- Robert AH Prins robert.ah.pr...@gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMP/E and STRIPSECT? (was: ... INCLUDE only when necessary)
On Thu, 25 Feb 2016 15:19:59 -0600, Barry Lichtenstein wrote: >> >> Does SMP/E respect STRIPSEC? Does it cause no problems, e.g. with >> RESTORE? How might it interact with the "++MOD(...) CSECT(...)" >> argument? > >Can't really blame SMP/E for accumulating them, that's the binders fault. For >a given section name, it quietly deletes same-named duplicates it finds (if >any), so for an unnamed section it has no handle. > >Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect >it would be ignored (you might get away with using SETOPT if you really had >some need for this). > >I would hope however that modules are not shipped which contain unnecessary >unnamed sections! Though sometimes unreferenced sections, named or not, are >there for a reason and should not be removed. > ISTR Pascal makes them. Hardly relevant nowadays. >That said I don't think SMP/E could care about unnamed sections, only ones >that it can have been told the names of. > And, now that I think about it, STRIPSEC is probably pernicious for SMP/E. SMP/E sometimes includes MOD elements from the target zone, and if they have been stripped desired results will not occur. In fact, for some searches the target zone is first in the search order. I consider this a bad design. SMP/E should search the DLIB zone and the GLOBAL zone and fail if the element is not found there; never search the target zone. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
I have always worked for the Outsourcerer-IBM (which is different than working for "the real" IBM), so I might have some points to bring in: - Best scenario I've worked was for a customer that kept 1 key-person for each area (z/OS, DB2, etc.). This person would bring historical knowledge, technical knowledge and sense of urgency depending on the situation. Weekly checkpoint meetings kept the teams aligned with what the customer desired; - SLAs MUST be carefully reviewed and agreed. Both sides could and WILL use it "against" the other side. If SLA is met, then no problem, no matter what's going on. Short-term contracts (3-5 years instead of 10-15 years) allow for a better SLA adjustment down the road; - There MUST be some sort of responsibility matrix with DETAILED activites (generic activites like "maintain systems" are too broad). Just by looking at this matrix, you should be able to tell: who's responsible for doing X? who's to be informed about X? who should be consulted if doing X?; - Outsourcers will probably request a lot of documentation (that in-house companies probably don't even have). This is vital! Part of the issues that might come could be avoided with a good documentation to start with; - Projects (processor upgrade, OS upgrade, router replacements, etc.) will most likely be treated like so (PROJECTS). Which means that probably a Project Manager will have to be involved to make teams talk to each other. Some overhead in these activities have to be considered; There are good and there are bad people working on outsourcerers, but I *guess* this is everywhere though, so no news. Where I worked, people tend to "standardize" the systems the most they can after transition has stabilized. This means the less exits, the better. Keep in mind the outsourcerer might have many clients and when someone gets called in the middle of the night it might be hard to remember the peculiarities of one of them. On the other hand teams are usually able to compare cross-customers solutions and propose enhancements should they apply. Hope this helps a bit. Regards, --- *Lucas Rosalen* Emails: rosalen.lu...@gmail.com / *lrosa...@pl.ibm.com* LinkedIn: http://br.linkedin.com/in/lrosalen Phone: +48 792 809 198 2016-02-25 18:00 GMT-03:00 Burrell, C. Todd (CDC/OCOO/OCIO/ITSO) (CTR) < z...@cdc.gov>: > I'm not going to judge anyone here - but I have always had the attitude > that if someone wants Mainframe help and I can help them - I am going to > help them. I would never have learned half of what I know after almost 30 > years in IT without others taking the time to answer a question or two (or > MANY) over the years. And I for one have learned a great deal just > monitoring these emails that come out on IBM-MAIN every day. I have a > folder of probably 500 emails I have kept over the years - and I still > access them occasionally to fix a problem, etc... There is a great deal of > knowledge on this forum and I for one am very appreciate of the help I have > received over the years - and I have also been glad to offer assistance > here and there where I can. > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Sankaranarayanan, Vignesh > Sent: Thursday, February 25, 2016 3:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Outsourcing Stories Good or Bad! > > No one's forcing you to Ed. But I'm guessing you're helping around here > because you love what you do, not because you want to help "your people" > alone. > One can't learn a lot from equals, and one certainly can't learn a lot > from those who are (for the lack of a more sensitive phrase) below them. > Sure, if this community doesn't want to help, that means workload mounts > for IBM in the form of a trillion more service requests lol. > But those who are here to learn will find a way. > > - Vignesh > Mainframe Infrastructure > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Ed Gould > Sent: Friday, Feb 26, 2016 1:57 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Outsourcing Stories Good or Bad! > > On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote: > > > Some thoughts from someone on the other side. > > > > What's the point of saying "Oh, I'm an outsourced nobody." in a post > > where one is asking for help. So you may choose to not answer or sit > > on your high horse and ridicule their incompetence when they're > > struggling? > > If you guys (actual mainframe folk with decades of background) are > > going to compare outsourced folk vs yourselves, you're doing it wrong. > > Most of your outsourced folk are younger than the total experience you > > may have. Of course they're going to be inferior. > > Do you call a baby rubbish because it can't write a
Re: SMP/E and STRIPSECT? (was: ... INCLUDE only when necessary)
On Tue, 23 Feb 2016 10:36:16 -0600 Paul Gilmartin wrote: > Oooh! Neat! Thanks. And I see: > > z/OS MVS Program Management: User's Guide and Reference > SA23-1393-00 > > STRIPSEC={PRIV|YES | NO} > STRIPSEC=PRIV > Specifies that unreferenced unnamed sections are to be removed. > > This addresses a misbehavior of SMP/E which secularly piles up private > sections (Which I think are something programmers should avoid anyway. > But Pascal reportedly dotes on them.) > > Note: For a section to be considered unreferenced, it must: > ... > Not be the target of a control statement > (Such as ORDER?) > > Does SMP/E respect STRIPSEC? Does it cause no problems, e.g. with > RESTORE? How might it interact with the "++MOD(...) CSECT(...)" > argument? > > Thanks again, > gil Can't really blame SMP/E for accumulating them, that's the binders fault. For a given section name, it quietly deletes same-named duplicates it finds (if any), so for an unnamed section it has no handle. Since SMP/E does not document recognizing STRIPSEC on the JCLIN PARM, I expect it would be ignored (you might get away with using SETOPT if you really had some need for this). I would hope however that modules are not shipped which contain unnecessary unnamed sections! Though sometimes unreferenced sections, named or not, are there for a reason and should not be removed. That said I don't think SMP/E could care about unnamed sections, only ones that it can have been told the names of. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
I'm not going to judge anyone here - but I have always had the attitude that if someone wants Mainframe help and I can help them - I am going to help them. I would never have learned half of what I know after almost 30 years in IT without others taking the time to answer a question or two (or MANY) over the years. And I for one have learned a great deal just monitoring these emails that come out on IBM-MAIN every day. I have a folder of probably 500 emails I have kept over the years - and I still access them occasionally to fix a problem, etc... There is a great deal of knowledge on this forum and I for one am very appreciate of the help I have received over the years - and I have also been glad to offer assistance here and there where I can. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Thursday, February 25, 2016 3:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! No one's forcing you to Ed. But I'm guessing you're helping around here because you love what you do, not because you want to help "your people" alone. One can't learn a lot from equals, and one certainly can't learn a lot from those who are (for the lack of a more sensitive phrase) below them. Sure, if this community doesn't want to help, that means workload mounts for IBM in the form of a trillion more service requests lol. But those who are here to learn will find a way. - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Friday, Feb 26, 2016 1:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote: > Some thoughts from someone on the other side. > > What's the point of saying "Oh, I'm an outsourced nobody." in a post > where one is asking for help. So you may choose to not answer or sit > on your high horse and ridicule their incompetence when they're > struggling? > If you guys (actual mainframe folk with decades of background) are > going to compare outsourced folk vs yourselves, you're doing it wrong. > Most of your outsourced folk are younger than the total experience you > may have. Of course they're going to be inferior. > Do you call a baby rubbish because it can't write a sonnet? Yes, the > baby has no business writing sonnets but welcome to the world of > outsourcing. > > When deciding to outsource, your employer has chosen money over the > people who have served him/her for a long time. > Don't take out your anger and disgust on people who are struggling to > better themselves because they have massive shoes to fill. > It's not his/her action that has led to you being laid off and being > forced to accept ridiculous things (train or you don't get your 401k > or whatever) in your last hours (on the job). > > That said, here's some actual feedback which may not be possible to > implement at all though: > 1. Exercise as many choices as you must to ensure you do not suffer. > Try as hard as you can to not accept people who can't speak basic > English. > The big man at the outsourcer may not leave that choice to you but > trust me, this is the root of all the abscess that you're > (employer) being charged for. > "This guy can't speak, so let's make him work under some 15,000 > managers who repeat the same thing without adding value." > Oh, and BTW, these managers are paid a f*k load more than the people > working, I would assume. > > 2. Offshoring development, IMHO, is the worst thing you can do. > You want your company to work on code that's written by someone who's > knowledge is extremely limited, and someone who would keep trying to > nail everything because he has a hammer? > > 3. If you are able to pick the right (technical) people, keep the > overhead (hey, if we're "resources", what's above us ought to be > "overhead" right?) to an extreme minimum. > > Who knows, some day Watson may make the whole industry go away and one > machine may manage the other. At that point, you get to say "Ha! No > more of these 'incompetent masses'". > > - Vignesh > Mainframe Infrastructure > --SNIP-- Then why should we provide expertise for free? We all learned the hard way with no IBM-MAIN at beck and call. We developed our own word of mouth partners. You should be doing the same. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422
Re: Outsourcing Stories Good or Bad!
No one's forcing you to Ed. But I'm guessing you're helping around here because you love what you do, not because you want to help "your people" alone. One can't learn a lot from equals, and one certainly can't learn a lot from those who are (for the lack of a more sensitive phrase) below them. Sure, if this community doesn't want to help, that means workload mounts for IBM in the form of a trillion more service requests lol. But those who are here to learn will find a way. - Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Friday, Feb 26, 2016 1:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote: > Some thoughts from someone on the other side. > > What's the point of saying "Oh, I'm an outsourced nobody." in a post > where one is asking for help. So you may choose to not answer or sit > on your high horse and ridicule their incompetence when they're > struggling? > If you guys (actual mainframe folk with decades of background) are > going to compare outsourced folk vs yourselves, you're doing it wrong. > Most of your outsourced folk are younger than the total experience you > may have. Of course they're going to be inferior. > Do you call a baby rubbish because it can't write a sonnet? Yes, the > baby has no business writing sonnets but welcome to the world of > outsourcing. > > When deciding to outsource, your employer has chosen money over the > people who have served him/her for a long time. > Don't take out your anger and disgust on people who are struggling to > better themselves because they have massive shoes to fill. > It's not his/her action that has led to you being laid off and being > forced to accept ridiculous things (train or you don't get your 401k > or whatever) in your last hours (on the job). > > That said, here's some actual feedback which may not be possible to > implement at all though: > 1. Exercise as many choices as you must to ensure you do not suffer. > Try as hard as you can to not accept people who can't speak basic > English. > The big man at the outsourcer may not leave that choice to you but > trust me, this is the root of all the abscess that you're > (employer) being charged for. > "This guy can't speak, so let's make him work under some 15,000 > managers who repeat the same thing without adding value." > Oh, and BTW, these managers are paid a f*k load more than the people > working, I would assume. > > 2. Offshoring development, IMHO, is the worst thing you can do. > You want your company to work on code that's written by someone who's > knowledge is extremely limited, and someone who would keep trying to > nail everything because he has a hammer? > > 3. If you are able to pick the right (technical) people, keep the > overhead (hey, if we're "resources", what's above us ought to be > "overhead" right?) to an extreme minimum. > > Who knows, some day Watson may make the whole industry go away and one > machine may manage the other. At that point, you get to say "Ha! No > more of these 'incompetent masses'". > > - Vignesh > Mainframe Infrastructure > --SNIP-- Then why should we provide expertise for free? We all learned the hard way with no IBM-MAIN at beck and call. We developed our own word of mouth partners. You should be doing the same. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
On Feb 25, 2016, at 12:54 PM, Sankaranarayanan, Vignesh wrote: Some thoughts from someone on the other side. What's the point of saying "Oh, I'm an outsourced nobody." in a post where one is asking for help. So you may choose to not answer or sit on your high horse and ridicule their incompetence when they're struggling? If you guys (actual mainframe folk with decades of background) are going to compare outsourced folk vs yourselves, you're doing it wrong. Most of your outsourced folk are younger than the total experience you may have. Of course they're going to be inferior. Do you call a baby rubbish because it can't write a sonnet? Yes, the baby has no business writing sonnets but welcome to the world of outsourcing. When deciding to outsource, your employer has chosen money over the people who have served him/her for a long time. Don't take out your anger and disgust on people who are struggling to better themselves because they have massive shoes to fill. It's not his/her action that has led to you being laid off and being forced to accept ridiculous things (train or you don't get your 401k or whatever) in your last hours (on the job). That said, here's some actual feedback which may not be possible to implement at all though: 1. Exercise as many choices as you must to ensure you do not suffer. Try as hard as you can to not accept people who can't speak basic English. The big man at the outsourcer may not leave that choice to you but trust me, this is the root of all the abscess that you're (employer) being charged for. "This guy can't speak, so let's make him work under some 15,000 managers who repeat the same thing without adding value." Oh, and BTW, these managers are paid a f*k load more than the people working, I would assume. 2. Offshoring development, IMHO, is the worst thing you can do. You want your company to work on code that's written by someone who's knowledge is extremely limited, and someone who would keep trying to nail everything because he has a hammer? 3. If you are able to pick the right (technical) people, keep the overhead (hey, if we're "resources", what's above us ought to be "overhead" right?) to an extreme minimum. Who knows, some day Watson may make the whole industry go away and one machine may manage the other. At that point, you get to say "Ha! No more of these 'incompetent masses'". – Vignesh Mainframe Infrastructure --SNIP-- Then why should we provide expertise for free? We all learned the hard way with no IBM-MAIN at beck and call. We developed our own word of mouth partners. You should be doing the same. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
Whatever outsourcer is selected - have your SLA be as detailed as possible and include major penalties for non-compliance ... A long long time ago in a data center far far away ... I was consulting to a outsourcing firm - they had control of a LARGE datacenter - at some point something happened (I honestly don’t remember what) - the clients were noticeably limping along - but at a level that met SLA - the outsourcer HAD a solution , but would have required an outage (IPL?) - which would have caused an SLA violation - so because degraded service was contractually acceptable, the clients limped along for some time ... The mantra we were told (in essence) was ... We don’t care if you NEVER do anything RIGHT, as long as you DON'T do anything WRONG It seemed the SLA was written that the benefits of success were far outweighed by the risks of failure So YOU, the client, make sure that YOU set the Service Level you expect nay DEMAND and don’t let the outsourcers off the hook with a substandard SLA Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services : humana.com 123 East Main Street Louisville, KY 40202 Humana.com (502) 714-8615, (502) 476-2538 The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Knowing GEN level
And keep in mind that what is in your TARGET zone is in no way (hopefully) tied to your runtime environment In the past - I have used different solutions for different products DB2 has a utility command MEPL to provide this information For other products I use AMBLIST with LISTIDR can return module information such as PTF# imbedded in the IDR space Other products may have other proprietary fix tracking tools ... (Lizette is correct as always) Chris Hoelscher Technology Architect, Database Infrastructure Services Technology Solution Services : humana.com 123 East Main Street Louisville, KY 40202 Humana.com (502) 714-8615, (502) 476-2538 N The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
Where’s the 'like' button? :-) s http://www.medmutual.com/ Visit http://www.medmutual.com/ CONFIDENTIALITY NOTICE: This message is intended only for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure by law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are strictly prohibited from printing, storing, disseminating, distributing or copying this message. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Neither this information block, the typed name of the sender, nor anything else in this message is intended to constitute an electronic signature, unless a specific statement to the contrary is included in this message. Thank you, Medical Mutual. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Sankaranarayanan, Vignesh Sent: Thursday, February 25, 2016 1:55 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! Some thoughts from someone on the other side. What's the point of saying "Oh, I'm an outsourced nobody." in a post where one is asking for help. So you may choose to not answer or sit on your high horse and ridicule their incompetence when they're struggling? If you guys (actual mainframe folk with decades of background) are going to compare outsourced folk vs yourselves, you're doing it wrong. Most of your outsourced folk are younger than the total experience you may have. Of course they're going to be inferior. Do you call a baby rubbish because it can't write a sonnet? Yes, the baby has no business writing sonnets but welcome to the world of outsourcing. When deciding to outsource, your employer has chosen money over the people who have served him/her for a long time. Don't take out your anger and disgust on people who are struggling to better themselves because they have massive shoes to fill. It's not his/her action that has led to you being laid off and being forced to accept ridiculous things (train or you don't get your 401k or whatever) in your last hours (on the job). That said, here's some actual feedback which may not be possible to implement at all though: 1. Exercise as many choices as you must to ensure you do not suffer. Try as hard as you can to not accept people who can't speak basic English. The big man at the outsourcer may not leave that choice to you but trust me, this is the root of all the abscess that you're (employer) being charged for. "This guy can't speak, so let's make him work under some 15,000 managers who repeat the same thing without adding value." Oh, and BTW, these managers are paid a f*k load more than the people working, I would assume. 2. Offshoring development, IMHO, is the worst thing you can do. You want your company to work on code that's written by someone who's knowledge is extremely limited, and someone who would keep trying to nail everything because he has a hammer? 3. If you are able to pick the right (technical) people, keep the overhead (hey, if we're "resources", what's above us ought to be "overhead" right?) to an extreme minimum. Who knows, some day Watson may make the whole industry go away and one machine may manage the other. At that point, you get to say "Ha! No more of these 'incompetent masses'". – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, Feb 25, 2016 12:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! On Wed, 24 Feb 2016 10:31:14 +, Mark Wilson wrote: >I am working with a client in Europe that is being requested by his >senior management team to look at outsourcing their IT systems, >including their system z platform. > >Would anyone be willing to share any war stories of their experiences >with Outsourcing good or bad? There has been considerable evidence of outsourcing to incompetent companies on IBM-Main lately. They don't say that they are outsourcers, but in the last few days there have been threads from people who hadn't a clue what they were doing. My guess is that they are outsourcers. Two that come to mind are the thread on a DASD device not going offline, and one about Applying a PTF to DB2 10. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in
Re: Issues with VSAM Enqueuers and Batch job with IDCAMS
Lizette, I've see the same type of problem with a VSAM file in our scheduler as well. It can be open to people looking at job history and thus, we have problems reloading it. We received an IEC161I message to SYSLOG - so, I wrote some automation to take the dataset name from the error message and issue a D GRS command against the dataset (d grs,res=(sysdsn,dsname.here)). Some of our applications have had similar issues with VSAM files - and this automation helped them determine who caused their abends. Robert DiBianca -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, February 15, 2016 11:52 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Issues with VSAM Enqueuers and Batch job with IDCAMS I have an issue where an STC holds a VSAM Dataset. The STC is a scheduling software that writes all of the info on jobs running/completed/failed and so forth, to this file. Once per day we close and free the VSAM file from the STC, run an archive process and then re-open then file to the STC. This works nearly all of the time. However, on occasion (a couple times a year) the job will fail in the IDCAMS Step with DATASET IN USE BY ANOTHER TASK message. The enq is so fast, I do not have any indication of what was holding it. The IDCAMS Step reloads the history file with the last 3 days' worth of information about jobs. It is a very simple REPO IFILE(x) OFILE(y) I opened an SR to IBM DFSMS and asked if they could add some checks in IDCAMS for the nonzero return code from the enq and let me know what job is using it. They indicated that extra code path to do that would not help. They felt that the enq is released so soon the extra test for the enqueue would not provide the name of the task. I have looked at RMF reports - I could see nothing. I have looked at DAF reports for the 5 min time frame - I could see nothing. When the step fails with RC12, I do the D GRS,C and nothing shows up. I am tempted to start the ISG Monitor for Enqueues for the 15 minute window when this job runs. If we rerun the job it is successful. Anyone have any other ideas to try and trap this rascally rabbit? Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information in this transmission may contain proprietary and non-public information of BB or its affiliates and may be subject to protection under the law. The message is intended for the sole use of the individual or entity to which it is addressed. If you are not the intended recipient, you are notified that any use, distribution or copying of the message is strictly prohibited. If you received this message in error, please delete the material from your system without reading the content and notify the sender immediately of the inadvertent transmission. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS
> > What are the risks of giving [IPCS] access to developers? > > Mostly, you risk them learning and understanding more about our platform > -- and post-mortem debugging -- than they did previously. > > IIRC, IPCS requires READ access to parmlib. If that's an issue, I > believe it might be possible to create a stand-alone parmlib just for > IPCS use. If the IPCSPARM ddname is allocated. that is what IPCS will use for accessing parmlib members. If IPCSPARM is not allocated, IPCS will use the system's parmlib concatenation. IPCS needs the parmlib members which IBM provides. Typically, these are found on the sysres volume in a data set named SYS1.IBM.PARMLIB (or some similar name chosen by the systems programmer). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Outsourcing Stories Good or Bad!
Some thoughts from someone on the other side. What's the point of saying "Oh, I'm an outsourced nobody." in a post where one is asking for help. So you may choose to not answer or sit on your high horse and ridicule their incompetence when they're struggling? If you guys (actual mainframe folk with decades of background) are going to compare outsourced folk vs yourselves, you're doing it wrong. Most of your outsourced folk are younger than the total experience you may have. Of course they're going to be inferior. Do you call a baby rubbish because it can't write a sonnet? Yes, the baby has no business writing sonnets but welcome to the world of outsourcing. When deciding to outsource, your employer has chosen money over the people who have served him/her for a long time. Don't take out your anger and disgust on people who are struggling to better themselves because they have massive shoes to fill. It's not his/her action that has led to you being laid off and being forced to accept ridiculous things (train or you don't get your 401k or whatever) in your last hours (on the job). That said, here's some actual feedback which may not be possible to implement at all though: 1. Exercise as many choices as you must to ensure you do not suffer. Try as hard as you can to not accept people who can't speak basic English. The big man at the outsourcer may not leave that choice to you but trust me, this is the root of all the abscess that you're (employer) being charged for. "This guy can't speak, so let's make him work under some 15,000 managers who repeat the same thing without adding value." Oh, and BTW, these managers are paid a f*k load more than the people working, I would assume. 2. Offshoring development, IMHO, is the worst thing you can do. You want your company to work on code that's written by someone who's knowledge is extremely limited, and someone who would keep trying to nail everything because he has a hammer? 3. If you are able to pick the right (technical) people, keep the overhead (hey, if we're "resources", what's above us ought to be "overhead" right?) to an extreme minimum. Who knows, some day Watson may make the whole industry go away and one machine may manage the other. At that point, you get to say "Ha! No more of these 'incompetent masses'". – Vignesh Mainframe Infrastructure -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, Feb 25, 2016 12:03 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Outsourcing Stories Good or Bad! On Wed, 24 Feb 2016 10:31:14 +, Mark Wilson wrote: >I am working with a client in Europe that is being requested by his >senior management team to look at outsourcing their IT systems, >including their system z platform. > >Would anyone be willing to share any war stories of their experiences >with Outsourcing good or bad? There has been considerable evidence of outsourcing to incompetent companies on IBM-Main lately. They don't say that they are outsourcers, but in the last few days there have been threads from people who hadn't a clue what they were doing. My guess is that they are outsourcers. Two that come to mind are the thread on a DASD device not going offline, and one about Applying a PTF to DB2 10. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN MARKSANDSPENCER.COM Unless otherwise stated above: Marks and Spencer plc Registered Office: Waterside House 35 North Wharf Road London W2 1NW Registered No. 214436 in England and Wales. Telephone (020) 7935 4422 Facsimile (020) 7487 2670 www.marksandspencer.com Please note that electronic mail may be monitored. This e-mail is confidential. If you received it by mistake, please let us know and then delete it from your system; you should not copy, disclose, or distribute its contents to anyone nor act in reliance on this e-mail, as this is prohibited and may be unlawful. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file not extending to new volume
Hmm, thanks for that. It looks like the EA value was NO instead of YES. I'll have to figure out how that happened. Greg -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Thursday, February 25, 2016 11:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: VSAM file not extending to new volume Check for this in your data class DATA CLASS DISPLAY Page 2 of 5 CDS Name . . . . . : ACTIVE Data Class Name . . : DIRECT Data Set Name Type . . . . . : EXTENDED If Extended . . . . . . . . : REQUIRED Extended Addressability . . : YES Record Access Bias . . . . : USER Space Constraint Relief . . . : NO -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Archive (was Re: Apply PTF on DB2 10 (z/os 1.12))
Tom Marchant wrote: On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote: Anyone know why I get this trying to follow the link? "Sorry, you are not authorized to search the archives of the IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you entered on the login screen." John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you subscribed to it as well? A while back, old messages for IBM-MAIN were split off into the IBM-MAIN-ARCHIVES list. IIRC it was to improve search time. Aha! Must have been asleep when that happened. Thanks so much to you and Elardus. -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: History of Computing 1944 and the evolution to the System/360
Additional memory was available from third party vendors. At Cornell in the early 1970s, the 360/65(?) had 1M. I don't recall if that was the total or the additional memory. On Thu, Feb 25, 2016 at 12:36 PM, Hobart Spitzwrote: > > > On Thu, Feb 25, 2016 at 12:11 PM, Mike Schwab > wrote: > >> https://en.wikipedia.org/wiki/IBM_700/7000_series >> Basically, the IBM 7xx and 7xxx had 4 branches in the family tree. >> Each incompatible with the other. The IBM 360 was a common design to >> satisfy all customers with one product. Businesses go the decimal >> instructions, science labs got the floating point instructions, time >> sharing sites got virtual memory (67). By the time 31 bit addressing >> came out, every machine had every instruction available for that >> model. >> >> On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehler >> wrote: >> > I was trolling for information on what the 360 indicated in the >> System/360 (yes >> > the old one) and came across this video >> > >> > >> > >> > Thought some might enjoy the walk down memory lane. The S/360 Model 30 >> had 1MB >> > of memory (I think) at the time. >> > >> > >> > >> > >> > >> > https://www.youtube.com/watch?v=V4kyTg9Cw8g >> > >> > >> > >> > Lizette Koehler >> > >> > statistics: A precise and logical method for stating a half-truth >> inaccurately >> > >> > >> > >> > >> > -- >> > For IBM-MAIN subscribe / signoff / archive access instructions, >> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> >> >> >> -- >> Mike A Schwab, Springfield IL USA >> Where do Forest Rangers go to get away from it all? >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > OREXXMan > -- OREXXMan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: History of Computing 1944 and the evolution to the System/360
On Thu, Feb 25, 2016 at 12:11 PM, Mike Schwabwrote: > https://en.wikipedia.org/wiki/IBM_700/7000_series > Basically, the IBM 7xx and 7xxx had 4 branches in the family tree. > Each incompatible with the other. The IBM 360 was a common design to > satisfy all customers with one product. Businesses go the decimal > instructions, science labs got the floating point instructions, time > sharing sites got virtual memory (67). By the time 31 bit addressing > came out, every machine had every instruction available for that > model. > > On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehler > wrote: > > I was trolling for information on what the 360 indicated in the > System/360 (yes > > the old one) and came across this video > > > > > > > > Thought some might enjoy the walk down memory lane. The S/360 Model 30 > had 1MB > > of memory (I think) at the time. > > > > > > > > > > > > https://www.youtube.com/watch?v=V4kyTg9Cw8g > > > > > > > > Lizette Koehler > > > > statistics: A precise and logical method for stating a half-truth > inaccurately > > > > > > > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- OREXXMan -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file not extending to new volume
Check for this in your data class DATA CLASS DISPLAY Page 2 of 5 CDS Name . . . . . : ACTIVE Data Class Name . . : DIRECT Data Set Name Type . . . . . : EXTENDED If Extended . . . . . . . . : REQUIRED Extended Addressability . . : YES Record Access Bias . . . . : USER Space Constraint Relief . . . : NO -- Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Lizette Koehler > Sent: Thursday, February 25, 2016 10:12 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: VSAM file not extending to new volume > > Did you check to see if the file is over 4GB in size? And if it is, does it > have EA/EF specified? > > Do a LISTC ALL and look at the options and HIURBA and HIARBA > > > Lizette > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Greg Shirey > > Sent: Thursday, February 25, 2016 9:35 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: VSAM file not extending to new volume > > > > We upgraded to z/OS 2.1 on the 13th and all seemed well until this > > morning when several jobs were trying to write to a VSAM file and > > received this > > message: > > > > IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33, > > IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx > > > > The message indicates the file could not extend - but it should have > > extended to a new volume. The DATACLAS for our VSAM files has a Dynamic > Volcount of > > 20.When we did a LISTCAT on the data set, it showed a second volume with > > VOLSER of * and VOLFLAG as CANDIDATE. (and Attribute of Extended) > > > > In order to recover the batch job, the applications group had to > > rebuild the VSAM file, so they did, then the sysprogs moved it to a > > volume with a lot of free space, and all the jobs ran fine. > > > > We generated a data set listing in ISMF and filtered on MULTIVOL = YES > > and our sequential data sets are successfully being extended to other > > volumes, but all of the VSAM files on the list only had CANDIDATE volumes > after the primary. > > > > We've opened a PMR and searched the database, but we keep thinking we > > must have missed a migration step or something because we aren't seeing > anyone else > > reporting anything like this. Any suggestions? > > > > Thanks, > > Greg Shirey > > Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply PTF on DB2 10 (z/os 1.12)
On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote: >Anyone know why I get this trying to follow the link? > >"Sorry, you are not authorized to search the archives of the >IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you >entered on the login screen." > Thanks, John, for your attention. Google Groups has it as: https://groups.google.com/d/topic/bit.listserv.ibm-main/kOCEy0DbOnM Perhaps the APAR IDs: SMP/E APARs IR44571/IR46256 (does sup have all elements?) -- Kurt Quackenbush >>> On Wed, 24 Feb 2016 19:51:07 -0600, Paul Gilmartin wrote: >>> >> http://bama.ua.edu/cgi-bin/wa?A2=ind0110=ibm-main-archives=R58709 >> And my ancient bookmark still works. Perhaps I'm grandfathered in. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Knowing GEN level
Jake, Are you asking how to know what level of service is on particular product? If so, you will need to find out how each vendor handles that. For IBM - RSU, for CA CARS, and so on. And then there are those cases where you want to know on specific module/src. Again, ask your vendor. Then you need to query your zones to see what is there. There is no magic. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Jake Anderson > Sent: Thursday, February 25, 2016 8:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Knowing GEN level > > Hi > > Is there a way to determine the GEN level from a product CSI ? > > Jake > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM file not extending to new volume
Did you check to see if the file is over 4GB in size? And if it is, does it have EA/EF specified? Do a LISTC ALL and look at the options and HIURBA and HIARBA Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Greg Shirey > Sent: Thursday, February 25, 2016 9:35 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: VSAM file not extending to new volume > > We upgraded to z/OS 2.1 on the 13th and all seemed well until this morning > when several jobs were trying to write to a VSAM file and received this > message: > > IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33, > IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx > > The message indicates the file could not extend - but it should have extended > to a new volume. The DATACLAS for our VSAM files has a Dynamic Volcount of > 20.When we did a LISTCAT on the data set, it showed a second volume with > VOLSER of * and VOLFLAG as CANDIDATE. (and Attribute of Extended) > > In order to recover the batch job, the applications group had to rebuild the > VSAM file, so they did, then the sysprogs moved it to a volume with a lot of > free space, and all the jobs ran fine. > > We generated a data set listing in ISMF and filtered on MULTIVOL = YES and our > sequential data sets are successfully being extended to other volumes, but all > of the VSAM files on the list only had CANDIDATE volumes after the primary. > > We've opened a PMR and searched the database, but we keep thinking we must > have missed a migration step or something because we aren't seeing anyone else > reporting anything like this. Any suggestions? > > Thanks, > Greg Shirey > Ben E. Keith Company > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: History of Computing 1944 and the evolution to the System/360
https://en.wikipedia.org/wiki/IBM_700/7000_series Basically, the IBM 7xx and 7xxx had 4 branches in the family tree. Each incompatible with the other. The IBM 360 was a common design to satisfy all customers with one product. Businesses go the decimal instructions, science labs got the floating point instructions, time sharing sites got virtual memory (67). By the time 31 bit addressing came out, every machine had every instruction available for that model. On Wed, Feb 24, 2016 at 9:34 PM, Lizette Koehlerwrote: > I was trolling for information on what the 360 indicated in the System/360 > (yes > the old one) and came across this video > > > > Thought some might enjoy the walk down memory lane. The S/360 Model 30 had 1MB > of memory (I think) at the time. > > > > > > https://www.youtube.com/watch?v=V4kyTg9Cw8g > > > > Lizette Koehler > > statistics: A precise and logical method for stating a half-truth inaccurately > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply PTF on DB2 10 (z/os 1.12)
Tom Marchant wrote: >John Eells wrote: >>Anyone know why I get this trying to follow the link? >>"Sorry, you are not authorized to search the archives of the >>IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you entered >>on the login screen." >John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you subscribed >to it as well? A while back, old messages for IBM-MAIN were split off into the >IBM-MAIN-ARCHIVES list. IIRC it was to improve search time. Tom, thanks for your kind help to John. Look at https://listserv.ua.edu/cgi-bin/wa?INDEX to see all list-servs hosted. Both IBM-MAIN and IBM-MAIN-ARCHIVES are listed there. You can use the web-pages of these to logon and get your password and searching fixed. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Digest oddity, item in Topics, but not in Body
John Mattson wrote: >Last couple of days I have noticed some occurrences of a subject being listed >in the Topics of the day, but not found in the body. Is there a problem? >Anyone else getting this? Not me, but there are 3 formats of digest e-mails: Digest (traditional) Digest (MIME format) Digest (HTML format) and two types of index: Index (traditional) Index (HTML format) Which of those are you using? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Digest oddity, item in Topics, but not in Body
Last couple of days I have noticed some occurrences of a subject being listed in the Topics of the day, but not found in the body. Is there a problem? Anyone else getting this? IBM-MAIN Digest - 23 Feb 2016 to 24 Feb 2016 (#2016-55) There are 78 messages totaling 4940 lines in this issue. Topics of the day: 13. Introducing Open Blockchain for IBM z Systems -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
VSAM file not extending to new volume
We upgraded to z/OS 2.1 on the 13th and all seemed well until this morning when several jobs were trying to write to a VSAM file and received this message: IEC070I 034(004)-220,GSFAQ200,GS200060GS200,VTSREG4,4621,PROD33, IEC070I SPP.ALL.SP013V,SPP.ALL.SP013V.DATA,CATALOG.x.xxx The message indicates the file could not extend - but it should have extended to a new volume. The DATACLAS for our VSAM files has a Dynamic Volcount of 20. When we did a LISTCAT on the data set, it showed a second volume with VOLSER of * and VOLFLAG as CANDIDATE. (and Attribute of Extended) In order to recover the batch job, the applications group had to rebuild the VSAM file, so they did, then the sysprogs moved it to a volume with a lot of free space, and all the jobs ran fine. We generated a data set listing in ISMF and filtered on MULTIVOL = YES and our sequential data sets are successfully being extended to other volumes, but all of the VSAM files on the list only had CANDIDATE volumes after the primary. We've opened a PMR and searched the database, but we keep thinking we must have missed a migration step or something because we aren't seeing anyone else reporting anything like this. Any suggestions? Thanks, Greg Shirey Ben E. Keith Company -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Knowing GEN level
On Thu, 25 Feb 2016 21:05:02 +0530, Jake Anderson wrote: >Is there a way to determine the GEN level from a product CSI ? GEN level? what do you mean by that? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply PTF on DB2 10 (z/os 1.12)
On Thu, 25 Feb 2016 10:25:56 -0500, John Eells wrote: >Anyone know why I get this trying to follow the link? > >"Sorry, you are not authorized to search the archives of the >IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you >entered on the login screen." John, IBM-MAIN-ARCHIVES is a different list than IBM-MAIN. Are you subscribed to it as well? A while back, old messages for IBM-MAIN were split off into the IBM-MAIN-ARCHIVES list. IIRC it was to improve search time. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Prefix save area - confused
On Thu, 25 Feb 2016 07:39:30 +0100, Peter Hunkeler wrote: >The 8 KiB area at absolute 0 is the place where the hardware writes >status information as result of performing the "Store Status" operation. Among other things. Those Assigned Storage Locations are defined by the architecture. Other areas within the PSA are defined by the operating system. >It has existed for longer than PR/SM. I would say, it is owned by the hardware. >> There is Absolute addressing, real addressing, and virtual addressing. > >But wait a minute, isn't there on more level? Absolulte, real, and >virtual are *within* an LPAR. It is required to support multi-CP >operating system *instances*. Since PR/SM, each LPAR must have its >own "absolute address 0", doesn't it? Yes. >Actually, the requirement has exited since physically partitionable CECs >had been in place (can't remember exaxtly which were the first such >machines, 3033, or 308x, or?). Probably System/360 model 65MP. For sure model 67. >The net would be: Some code is accessing virtual address 0. The DAT >feature will (with the help of the DAT tables) translate virtual 0 to *a* >real address (which just happens to always be real frame 0 in z/OS). >The hardware will recognize an address within the "prefixing area" (8 KiB >in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier >architectures?), System/360 Principles of operation has described prefixing all the way back to the -0 level of the manual. You can find it at http://bitsavers.trailing-edge.com/pdf/ibm/360/princOps/A22-6821-0_360PrincOps.pdf The description is on page 18, under "Multisystem Feature". It is described there as a 4K area. Before the -4 level of the System/370 POO in 1974, the SET PREFIX instruction was defined. It was not in the -0 edition. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Prefix save area - confused
Peter Hunkler: What I'm about to say does not contradict Peter Relson's post clarifying things relative to MVS -> z/OS. Unless IBM has done some interesting magic, the c-store of a z/Architecture box is "owned" by the Hypervisor, in this case PR/SM. There are no bare metal SCPs today because of how IBM does things. Now, going back > 20 years for an Amdahl 5990, MDF started at low storage, and self-relocated to high storage (HSA) -- very early in the process. Absolute 0 was still at absolute 0. Meanwhile the 580s' HSA was low storage if I remember correctly. Within the Hypervisor, once the MP init (Multi-Processor) was done, all the CPUs were prefixed into HSA (which belongs to the hypervisor). At some point, domain init gets run, and the domains get built (IBM's LPARs). They start off with a pseudo absolute 0 which is at the bottom of their storage block. So you do an IPL (for the SCP for that domain), and the SCP loads, and at some point (MVS or VM) MP INit is done, now the domain (again, LPAR in IBM parlance) "prefixes" all of the CPUs it knows about. After that SCP gets virtual storage controls initialized, DAT becomes is functional. Depends on the SCP as to how soon this is completed. So, here you are with VM and SIE. You now have virtual storage run by VM (CP) to the second level machine which may be REAL or may be a Virtual system as well. Eyes glazed over yet? To effect all of this, the CEC must implement some kind of Hypervisor Registers (probably at the CPU level) so that one can switch between DOMAIN/LPAR mode and Hypervisor mode and address storage accordingly. When VM/CP are functioning, it must do the same kind of tracking for each of its guests. Wanna have some more fun? The hardware has just detected a double-bit parity error. How will you reflect that MCK to the affected LPAR? The Hypervisor is the one that gets posted with that. And now it has to figure out where that CPU was in the grand scheme of things so that the MCK can be handled correctly. I used to do that level of programming at Amdahl. So, one finds what the domain registers contained, and then you do the MCK PSW swap after setting all the bits/etc. in that CPU's Prefix area in that domain (LPAR), and let that SCP figure it out -- depending on whether it was exigent or repressive and the CR bits were set... And we haven't even mentioned I/O in all of this other than to hint at it because of "IPL". It gets complicated. And when Amdahl started this (MDF) IBM's machines were still Base 370, and some engineers had to figure out how to float I/O 'rupts so they could be reflected to the correct CPU in the correct Domain. Plus, page fixing and getting I/O synced with the right channel Having X/A channels would have made this much easier I just wonder who came up with that idea. (If I'm a bit off, forgive me, it has been a bit over 20 years since I did this level of programming, and with CMOS a lot changed that I was never part of). Regards, Steve Thompson On 02/25/2016 01:39 AM, Peter Hunkeler wrote: Nevertheless, absolute 0 is owned by PR/SM, right? The 8 KiB area at absolute 0 is the place where the hardware writes status information as result of performing the "Store Status" operation. It has existed for longer than PR/SM. I would say, it is owned by the hardware. There is Absolute addressing, real addressing, and virtual addressing. ... and for practical purposes absolute and real addressing are the same, except when takling about the 8 KiB at real address 0 and the 8KiB point to by the prefix resigsters. But wait a minute, isn't there on more level? Absolulte, real, and virtual are *within* an LPAR. It is required to support multi-CP operating system *instances*. Since PR/SM, each LPAR must have its own "absolute address 0", doesn't it? Actually, the requirement has exited since physically partitionable CECs had been in place (can't remember exaxtly which were the first such machines, 3033, or 308x, or?). The net would be: Some code is accessing virtual address 0. The DAT feature will (with the help of the DAT tables) translate virtual 0 to *a* real address (which just happens to always be real frame 0 in z/OS). The hardware will recognize an address within the "prefixing area" (8 KiB in z/Architcture, 4 KiB in ESA/390 and predecessors, 2 KiB in even earlier architectures?), and will translate real 0 (with the help of the Prefix Register) to absolute 0 (for this LPAR). Some other part of the hardware needs to translate "absolute 0 of this LPAR" to a *physical* memory address (how this works in detail is far beyond my knowledge). -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Knowing GEN level
Hi Is there a way to determine the GEN level from a product CSI ? Jake -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Apply PTF on DB2 10 (z/os 1.12)
Anyone know why I get this trying to follow the link? "Sorry, you are not authorized to search the archives of the IBM-MAIN-ARCHIVES list from the email address (ee...@us.ibm.com) you entered on the login screen." I used to be able to look in the archives... Paul Gilmartin wrote: On Wed, 24 Feb 2016 21:28:05 -0600, Tom Marchantwrote: On Wed, 24 Feb 2016 19:51:07 -0600, Paul Gilmartin wrote: I suspect CA's shenanigans were a motivation for IBM's tightening the rules on SUPERSEDEs a few years prior to that. How were the rules for SUP tightened? http://bama.ua.edu/cgi-bin/wa?A2=ind0110=ibm-main-archives=R58709 -- John Eells IBM Poughkeepsie ee...@us.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Web Version
Gil wrote on a item and gave the web interface URL. I tried it and for after a lot of shenanigans I got this message: Confirmation Sent Your password registration request has been accepted. For your protection, the password will not be activated just yet (anyone could have completed this form using your email address). To activate your password, simply follow the instructions which have been sent to you at edgould1...@comcast.net. Please wait until you receive a message from LISTSERV saying "Your new password was registered successfully" before trying to use it with the Web interface. That was 8 hours ago and still nothing (and nothing in my junk folder either). Since Darren is lost who are we sup[posed to make inquiries to? Ed ps: Can Gil just report the original item, please? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parsing IEASYS00 entries
Thanks Peter. I resolved it by using Since isn't in my IEASYMxx I think it is being defined during the startup of some ISV software. Alan Field Systems Engineer Principal Blue Cross Blue Shield of MN 651.662.3546 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Peter Relson Sent: Thursday, February 25, 2016 6:48 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Parsing IEASYS00 entries In all symbol substitution situations you need to start by asking "what is the value of the symbol?", in this case, "what is the value of ?". Since z/OS does not create such a symbol, then if you don't have it in your IEASYMxx then it's very unlikely that it's available for usage during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you must not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: System Trace Table Size -- REDUX
On 2016-02-25 09:34, Ed Jaffe wrote: I brought this up on IBM-MAIN many years ago after noticing several system traces, from large customers, with less than one screen's worth of good trace data. At that time, the maximum trace table size was 999K and I recommended setting that size (if you could afford the real memory). 1M is now the default... Just last night I was asked to take a look at a dump -- from a large customer running on the newest, biggest "iron" -- that had only .045 seconds of good trace data: Trace data is not available from all processors before this time. 0008 0269 008C3448 I/O 02013 _0D91ABCA 10104007 6F932740 0C000100 0080 0009 0269 08:22:55.743019140 40 07544000 8000 024FE070 0010 . . (two measly pages of trace data) . 0012 0226 084B8B00 SSRV 118 A6476E64 01E6A110 8007611A 08245B88 Suspend 08:22:55.788338762 6E Trace data is not available from all processors after this time. Don't forget to re-visit your MVS trace table allocations whenever you upgrade your hardware. Luckily, major increases in processor speed and the number of logical processors have been accompanied by similar increases in LPAR real memory allocations, making larger trace tables possible. The TRACE ST command now supports up to 9G per processor! LOL! I'm not in any way suggesting that value be used, I'm just pointing out that it's possible. IMHO, trace tables should be sized to hold _at least_ one full clock second of data on your zIIPs or whatever your fastest processors might be. Others might have different ROTs. Just do it! Your debugging teams will thank you. :) Too bad listservs don't have "like" buttons! I can't count the number of times where key information was outside of the time range covered by system trace. On the other side of the coin, I can think of several cases where the trace table size was a generous size and information I needed was several seconds before the event causing the dump. Providing ample storage for system trace is a great way to help your vendors solve any problems you encounter, and in today's environment of cheap and plentiful storage the cost is minimal. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
System Trace Table Size -- REDUX
I brought this up on IBM-MAIN many years ago after noticing several system traces, from large customers, with less than one screen's worth of good trace data. At that time, the maximum trace table size was 999K and I recommended setting that size (if you could afford the real memory). 1M is now the default... Just last night I was asked to take a look at a dump -- from a large customer running on the newest, biggest "iron" -- that had only .045 seconds of good trace data: Trace data is not available from all processors before this time. 0008 0269 008C3448 I/O 02013 _0D91ABCA 10104007 6F932740 0C000100 0080 0009 0269 08:22:55.743019140 40 07544000 8000 024FE070 0010 . . (two measly pages of trace data) . 0012 0226 084B8B00 SSRV 118 A6476E64 01E6A110 8007611A 08245B88 Suspend 08:22:55.788338762 6E Trace data is not available from all processors after this time. Don't forget to re-visit your MVS trace table allocations whenever you upgrade your hardware. Luckily, major increases in processor speed and the number of logical processors have been accompanied by similar increases in LPAR real memory allocations, making larger trace tables possible. The TRACE ST command now supports up to 9G per processor! LOL! I'm not in any way suggesting that value be used, I'm just pointing out that it's possible. IMHO, trace tables should be sized to hold _at least_ one full clock second of data on your zIIPs or whatever your fastest processors might be. Others might have different ROTs. Just do it! Your debugging teams will thank you. :) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Novel Data Centers around the world
Lizette Koehler wrote: >I stumbled across this. It is photos of data centers that do not match the >old concrete concept of a DC. Some of these are actually incredible >repurposed buildings (like cathedrals). Interesting! Thanks for sharing these nice eye-candies. As a bonus, I followed some of the link and discovered a real bunker of a datacentre... Have fun reading this... http://www.cyberbunker.com/web/cityhall.php >Proving that Sweden can be not only cold but also cool, this hip underground >data bunker run by internet service provider looks like it could survive a >hydrogen bomb... And those Sweden people can build excellent cars too. Think Volvo, Saab and Scania amongst other... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Prefix save area - confused
>In what way do they say PSA is a common area of every address space when >there is a unique PSA for every processor ? "common area for every address space" has nothing to do with "processor". It says that no matter what address space you are in you can access fields in the PSA. And that is true. That is unlike "private area" where the private storage at address X in an address space has no necessary correlation to the private storage at address X in another address space. PSA is an MVS (probably older than that, actually) term. It has not to my knowledge ever varied from "prefixed save area". Within there you will also see "FLC" for "Fixed Low Core". Neither of these is an architectural term. As was mentioned, prefixing is a hardware function, provided so that programs could use the same address (e.g., 0) but get to a different area per processor. Many fields in the PSA are the same in every processor's PSA (e.g., the address of the CVT), but many are different (e.g, the address of the home TCB, the address of the home ASCB, the address of the LCCA). It is true that in between instructions (when not disabled for I/O and external interrupts) your work unit could be moved to another processor where it would then reference a different PSA. But for the most part the program is expected not to care -- for the things that the program needs, the PSA is expected to be "correct" on whichever processor the program is dispatched. When a work unit is undispatched from one processor and redispatched on another, about the only "normal" things updated in the PSA are the home TCB and home ASCB addresses. Another thing that is updated is the FRR stack. The FRR stack is saved upon undispatch and the "target PSA's" FRR stack is set up from that saved FRR stack to accompany the redispatch. There are some other things that are updated upon redispatch related to the status of the work unit; those are not used as frequently by applications. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Novel Data Centers around the world
I stumbled across this. It is photos of data centers that do not match the old concrete concept of a DC. Some of these are actually incredible repurposed buildings (like cathedrals). I found some of the ways companies (like Google) enhanced their employees experience quite unusual at times. http://www.techrepublic.com/pictures/these-data-centers-are-insanely-gorgeous/?f tag=ACQd47fd66 More than just row upon row of whirring information-storage obelisks, today's repositories of zeroes and ones take design to the next level. For example: Proving that Sweden can be not only cold but also cool, this hip underground data bunker run by internet service provider looks like it could survive a hydrogen bomb... Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DASD device not going offline
>Did it really say "HAS VOLUME ID DOESNT NOT MATCH WITH CATALOG"? The answer better be "no". That part of the message text is: HAS A VOLUME ID THAT DOES NOT MATCH CATALOG >It might not even say CSV540E. Due to customer request, it was changed from CSV540I to CSV540E in z/OS 2.1. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS
Is there really anything in PARMLIB that cannot be found in unprotected CSA? On Wed, 24 Feb 2016 20:16:57 -0600 Ed Gouldwrote: :>Binyamin: :> :>I agree but to a specific point disagree. :> :>I have been in several shops where read access was given to :>SYS1.PARMLIB . Every one of those shops at least one time a month we :>were called into a meeting to "discuss" contents of sys1.parmlib. :>Those meeting could last 2-5 hours arguing the contents of one member :>or another. It got so bad that I had to move the contents to another :>restricted library (in the concatenation) to stop such meetings(and :>leave dummy entries behind). It seems that every tom dick and harry :>*KNEW* what one parameter or another should be. On one occasion I :>changed a member because it was mandated and of course it did not do :>anything to solve the problem (was there really a problem?) :>Politics is a PITA time waster so keep everything in other libraries :>so you stop the politics before it happens. :> :>Ed :> :>On Feb 24, 2016, at 3:42 PM, Binyamin Dissen wrote: :> :>> None. :>> :>> You should protect your SYS1.DUMP dataset. :>> :>> In general, protect the data, not the program - unless the program :>> is APF and :>> bypasses OPEN without a security check. :>> :>> On Wed, 24 Feb 2016 20:46:34 + "Lopez, Sharon" :>> :>> wrote: :>> :>> :>Do others use IPCS instead of systems programmers? I always :>> thought of it as a system's programmers tool but now we have :>> application developers that want access to it. What are the risks :>> of giving access to developers? :>> :> :>> :>Thanks in advance. :>> :> :>> :> :>> :> :>> :> :>> :> :>> :>Email correspondence to and from this address may be subject to :>> the North Carolina Public Records Law and may be disclosed to third :>> parties by an authorized state official. :>> :> :>> :> :>> -- :>> :>For IBM-MAIN subscribe / signoff / archive access instructions, :>> :>send email to lists...@listserv.ua.edu with the message: INFO IBM- :>> MAIN :>> :>> -- :>> Binyamin Dissen :>> http://www.dissensoftware.com :>> :>> Director, Dissen Software, Bar & Grill - Israel :>> :>> :>> Should you use the mailblocks package and expect a response from me, :>> you should preauthorize the dissensoftware.com domain. :>> :>> I very rarely bother responding to challenge/response systems, :>> especially those from irresponsible companies. :>> :>> -- :>> For IBM-MAIN subscribe / signoff / archive access instructions, :>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IPCS
>There should be no risks at all to allowing application developers to >use IPCS. This is surely true. Applications may take SYSMDUMPs for example. If you want people to be able to debug their applications, they will need to be able to use dump reading tools to read their dumps. And many things in SYSMDUMPs are captured that are not captured in SYSABEND or SYSUDUMPs (think storage above 2G). As others have posted, what is also true is that it may be very important to protect the data. It is usually not appropriate to give everyone read access to system dumps. But if you have read access to the dump, then using IPCS is not exposing anything that you could not (with some difficulty, admittedly, but doable) determine yourself. And as Ed Jaffe mentioned, with the "ACTIVE" option, in the absence of security profiles that permit otherwise, the user cannot see anything that an unauthorized program in their address space could see. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Parsing IEASYS00 entries
In all symbol substitution situations you need to start by asking "what is the value of the symbol?", in this case, "what is the value of ?". Since z/OS does not create such a symbol, then if you don't have it in your IEASYMxx then it's very unlikely that it's available for usage during IPL. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: History of Computing 1944 and the evolution to the System/360
The 360-mod 40 in the Field Engineering Education Center in Poughkeepsie had 64K in 1968. We were using it to train PSRs for OS/360. Mike Myers Mentor Services Corporation On 02/24/2016 10:34 PM, Lizette Koehler wrote: I was trolling for information on what the 360 indicated in the System/360 (yes the old one) and came across this video Thought some might enjoy the walk down memory lane. The S/360 Model 30 had 1MB of memory (I think) at the time. https://www.youtube.com/watch?v=V4kyTg9Cw8g Lizette Koehler statistics: A precise and logical method for stating a half-truth inaccurately -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Introducing Open Blockchain for IBM z Systems
Fantastic thank you. > On Feb 25, 2016, at 3:36 AM, Timothy Sippleswrote: > > Yes, take a look here for source code (with more to come, including as I > understand it more details on building on z): > > https://github.com/IBM-Blockchain > https://github.com/openblockchain > > Although optional, IBM would very much like to stay in touch with those > working with Blockchain on z. Please visit this page: > > http://www.ibm.com/blockchain/z.html > > and click on "Contact an expert" to get in that loop. > > > Timothy Sipples > IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA > E-Mail: sipp...@sg.ibm.com > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Introducing Open Blockchain for IBM z Systems
Yes, take a look here for source code (with more to come, including as I understand it more details on building on z): https://github.com/IBM-Blockchain https://github.com/openblockchain Although optional, IBM would very much like to stay in touch with those working with Blockchain on z. Please visit this page: http://www.ibm.com/blockchain/z.html and click on "Contact an expert" to get in that loop. Timothy Sipples IT Architect Executive, Industry Solutions, IBM z Systems, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN