Re: Instruction speeds
Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit : And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. that's what they said in 1965 when they were storing years in dates on 2 digits... hilarity ensued in 1999 when they were all panicked that their 1964 vintage cobol code world would crumble... my 0.02€ Raphael -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
On 2019-08-14 8:40 PM, Raphaël Jacquot wrote: that's what they said in 1965 when they were storing years in dates on 2 digits... hilarity ensued in 1999 when they were all panicked that their 1964 vintage cobol code world would crumble... Yeah... Didn't Fred Brooks in "The Mythical Man Month" complain that OS/360 wasted 24 bytes by catering for a leap year changing from 28th Feb to 29th? The operator could manually fix that without OS help - after all, it only happened once every four years. So, you are updating your master file with millions of records and for each record you go through 5 excess instructions (say) to cater for the year 2100. How long extra will several lots of 5 million instructions take on today's BIPS engines? Less than a thousand I/O operations? It's nice to reduce path length overhead, but it's also nice to be future proof - or at least future tolerant. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
>JNE generates the same machine instruction as BNE, etc. Not true. BNE generates the same machine instruction as BC x (47xy). JNE generates the same machine instruction as BRC x (A7x4). 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: Instruction speeds
Hi Kees, I respectfully (somewhat) disagree with your leap year calculation assertion. I used to work for a Surety company and now work for a life insurance company. In both cases we have policies that can reach out 50-100 years. We definitely need the 100 year rule in some calculations. Yes, there are definitely areas where one could forget about using the 100 year rule in leap year calculations, but not always. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 14, 2019 1:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Instruction speeds And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: 13 August, 2019 19:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > Avoid processor-specific optimizations; what is millicode on one box > may not be on another. Worry first about getting your code correct and > maintainable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on > behalf of Christopher Y. Blaicher > Sent: Monday, August 12, 2019 9:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > There is no instruction cycle time table. There are some general > guidelines you can follow. > > Don't overload cache. Locality of reference for instructions and data > is important. > > The machine will do out-of-order instruction processing, but there are > limits. If you load a register don't use it as a base register in the > next instruction, if you can help it. > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up > to about 32K. > > JUMPs are faster than BRANCHes. > > Don't use instructions that set the condition code, unless you need it. > > Millicode instructions have startup and shutdown overheads. Many > times you can go faster using open code to do what a millicode instruction > does. > > Here is one that has nothing to do with an instruction - Don't assign > CPs from different drawers to an LPAR, that includes ZIIPs. Task > switching across drawers kills cache and kills performance. You will > lose hundreds, if not thousands, of cycles. > > There are some articles on the net that go over processor design and > cache design. The processor designs will give you a hint to the > number of stages an instruction goes through. Pipeline delays are > what you try to avoid. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 8:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did some searching, but I didn't find anything that really discussed > this on the topic that I'm interested. Is there anything published > that compares the cycle times of the most used instructions? > > For example; moving an address between areas of storage. I would > assume that executing a LOAD and STORE would be much quicker than > executing a MVC. > > Or executing a LOAD ADDRESS to increment a register instead of ADD > HALF WORD. > > Or does this really matter as much as ordering the instructions so > they are optimized for the pipeline? > > -- > 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 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
Re: Instruction speeds
On 8/14/19 5:29 AM, Raphaël Jacquot wrote: > Le 14/08/2019 à 08:18, Vernooij, Kees (ITOP NM) - KLM a écrit : >> And: don't write unnecessary code. >> A nice example is how to determine leap years: from as long as I >> program the flow is: >> - dividable by 4? >> - dividable by 100? >> - dividable by 400? >> >> The last 2 are completely unnecessary until the year 2100. >> How many useless instructions will have been executed for this reason >> in the 150 years until 2100? >> How much of our assembler code will live until 2100? Lots were not >> even prepared for 2000. >> >> Kees. >> > > that's what they said in 1965 when they were storing years in dates on > 2 digits... > hilarity ensued in 1999 when they were all panicked that their 1964 > vintage cobol code world would crumble... > > my 0.02€ > > Raphael > ... To be fair to history, in 1965 most had good reason to expect that assembly code would be short-lived. Prior to the announcement of S/360 in April 1964, almost every time you had to upgrade to a newer or faster processor the hardware architecture changed enough that you had to completely rewrite assemblly code every several years. S/360 guaranteed compatibility for performance upgrades within S/360, but didn't rule out incompatible future architectures. In 1965, even those exposed to S/360 would have had no experience yet to make them assume the architecture would be stable enough and kept as a subset of future architectures to allow running the same code decades later, much less have z-architecture hardware supporting the same instructions as a subset in 2019. Joel C Ewing -- Joel C. Ewing -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
I TOTALLY disagree (with Kees)! Number one, 2100 is only 80+ years away, not 150. Number two, who knows how long the code I write today will be running. The Y2K problem was precisely because people said "good grief -- 2000 is thirty years away -- why waste two bytes?" 2100 is less than three times as far away as 2000 was in 1970. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Pommier, Rex Sent: Wednesday, August 14, 2019 5:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds Hi Kees, I respectfully (somewhat) disagree with your leap year calculation assertion. I used to work for a Surety company and now work for a life insurance company. In both cases we have policies that can reach out 50-100 years. We definitely need the 100 year rule in some calculations. Yes, there are definitely areas where one could forget about using the 100 year rule in leap year calculations, but not always. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 14, 2019 1:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: Instruction speeds And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: 13 August, 2019 19:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > Avoid processor-specific optimizations; what is millicode on one box > may not be on another. Worry first about getting your code correct and > maintainable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on > behalf of Christopher Y. Blaicher > Sent: Monday, August 12, 2019 9:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > There is no instruction cycle time table. There are some general > guidelines you can follow. > > Don't overload cache. Locality of reference for instructions and data > is important. > > The machine will do out-of-order instruction processing, but there are > limits. If you load a register don't use it as a base register in the > next instruction, if you can help it. > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up > to about 32K. > > JUMPs are faster than BRANCHes. > > Don't use instructions that set the condition code, unless you need it. > > Millicode instructions have startup and shutdown overheads. Many > times you can go faster using open code to do what a millicode instruction does. > > Here is one that has nothing to do with an instruction - Don't assign > CPs from different drawers to an LPAR, that includes ZIIPs. Task > switching across drawers kills cache and kills performance. You will > lose hundreds, if not thousands, of cycles. > > There are some articles on the net that go over processor design and > cache design. The processor designs will give you a hint to the > number of stages an instruction goes through. Pipeline delays are > what you try to avoid. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 8:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did some searching, but I didn't find anything that really discussed > this on the topic that I'm interested. Is there anything published > that compares the cycle times of the most used instructions? > > For example; moving an address between areas of storage. I would > assume that executing a LOAD and STORE would be much quicker than > executing a MVC. > > Or executing a LOAD ADDRESS to increment a register instead of ADD > HALF WORD. > > Or does this really matter as much as ordering the instructions so > they are optimized for the pipeline? > > -- > 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 > > -- > F
Re: Instruction speeds
Heck, just 30 year mortgages required printing 2000 in 1970. On Wed, Aug 14, 2019 at 7:49 AM Pommier, Rex wrote: > > Hi Kees, > > I respectfully (somewhat) disagree with your leap year calculation assertion. > I used to work for a Surety company and now work for a life insurance > company. In both cases we have policies that can reach out 50-100 years. We > definitely need the 100 year rule in some calculations. Yes, there are > definitely areas where one could forget about using the 100 year rule in leap > year calculations, but not always. > > Rex > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Vernooij, Kees (ITOP NM) - KLM > Sent: Wednesday, August 14, 2019 1:19 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [External] Re: Instruction speeds > > And: don't write unnecessary code. > A nice example is how to determine leap years: from as long as I program the > flow is: > - dividable by 4? > - dividable by 100? > - dividable by 400? > > The last 2 are completely unnecessary until the year 2100. > How many useless instructions will have been executed for this reason in the > 150 years until 2100? > How much of our assembler code will live until 2100? Lots were not even > prepared for 2000. > > Kees. > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Seymour J Metz > > Sent: 13 August, 2019 19:23 > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Instruction speeds > > > > Avoid processor-specific optimizations; what is millicode on one box > > may not be on another. Worry first about getting your code correct and > > maintainable. > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Discussion List on > > behalf of Christopher Y. Blaicher > > Sent: Monday, August 12, 2019 9:32 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Instruction speeds > > > > There is no instruction cycle time table. There are some general > > guidelines you can follow. > > > > Don't overload cache. Locality of reference for instructions and data > > is important. > > > > The machine will do out-of-order instruction processing, but there are > > limits. If you load a register don't use it as a base register in the > > next instruction, if you can help it. > > > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up > > to about 32K. > > > > JUMPs are faster than BRANCHes. > > > > Don't use instructions that set the condition code, unless you need it. > > > > Millicode instructions have startup and shutdown overheads. Many > > times you can go faster using open code to do what a millicode instruction > > does. > > > > Here is one that has nothing to do with an instruction - Don't assign > > CPs from different drawers to an LPAR, that includes ZIIPs. Task > > switching across drawers kills cache and kills performance. You will > > lose hundreds, if not thousands, of cycles. > > > > There are some articles on the net that go over processor design and > > cache design. The processor designs will give you a hint to the > > number of stages an instruction goes through. Pipeline delays are > > what you try to avoid. > > > > Chris Blaicher > > Technical Architect > > Syncsort, Inc. > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Brian Chapman > > Sent: Monday, August 12, 2019 8:48 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Instruction speeds > > > > Hi everyone, > > > > I did some searching, but I didn't find anything that really discussed > > this on the topic that I'm interested. Is there anything published > > that compares the cycle times of the most used instructions? > > > > For example; moving an address between areas of storage. I would > > assume that executing a LOAD and STORE would be much quicker than > > executing a MVC. > > > > Or executing a LOAD ADDRESS to increment a register instead of ADD > > HALF WORD. > > > > Or does this really matter as much as ordering the instructions so > > they are optimized for the pipeline? > > > > -- > > 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 > > For information, services and offers, please visit our we
Re: Integrated 3270 Console in HMC 2.12 in web browser
On Aug 14, 2019, at 1:04 AM, Christian Svensson <022ad63487ef-dmarc-requ...@listserv.ua.edu> wrote: > > Is it possible to launch Integrated 3270 Console in HMC 2.12 when accessing > the HMC using a web browser? > > When I click on the LPAR and choose Integrated 3270 Console nothing happens > when using a remote web browser. It works locally on the HMC. The Chrome > network request is: > > Request URL: https:///hmc/ui/dnd2/launch > Request Method: POST > Status Code: 204 No Content > Remote Address: 10.114.2.10:443 > Referrer Policy: no-referrer-when-downgrade > Date: Wed, 14 Aug 2019 06:00:22 GMT > Server: zSeries management console embedded web server / 2.0 > > Nothing more. Am I missing something? Some other actions at least say "this > task cannot be used remotely" which makes me wonder if I'm doing something > wrong. It should work just as well remotely, but there are lots of things that could go wrong. > > Bonus question: Can I connect to the LPAR 3270 console remotely in some > other fashion? Maybe. Do you have one or more OSA-ICC features configured? Have you set up SMCS consoles? I can access an LPAR console by logging on to the HMC and opening the integrated 3270 console, or by connecting my tn3270E client to an OSA-ICC console LU, or by accessing an SMCS console from my VTAM session manager. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
> That assumes that you know what is unnecessary. The smart money says that the > unnecessary code will turn out to be necessary, at the least convenient time. > A nice example is how to determine leap years: from as long as I program the > flow is: >- dividable by 4? >- dividable by 100? >- dividable by 400? The last 2 are completely unnecessary until the year 2100. And in the year 2100 people will curse you for deciding that it's unnecessary. Après Moi Le Déluge (Après nous le deluge for purists.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 14, 2019 2:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Seymour J Metz > Sent: 13 August, 2019 19:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > Avoid processor-specific optimizations; what is millicode on one box may > not be on another. Worry first about getting your code correct and > maintainable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Christopher Y. Blaicher > Sent: Monday, August 12, 2019 9:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > There is no instruction cycle time table. There are some general > guidelines you can follow. > > Don't overload cache. Locality of reference for instructions and data is > important. > > The machine will do out-of-order instruction processing, but there are > limits. If you load a register don't use it as a base register in the > next instruction, if you can help it. > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up to > about 32K. > > JUMPs are faster than BRANCHes. > > Don't use instructions that set the condition code, unless you need it. > > Millicode instructions have startup and shutdown overheads. Many times > you can go faster using open code to do what a millicode instruction does. > > Here is one that has nothing to do with an instruction - Don't assign CPs > from different drawers to an LPAR, that includes ZIIPs. Task switching > across drawers kills cache and kills performance. You will lose hundreds, > if not thousands, of cycles. > > There are some articles on the net that go over processor design and cache > design. The processor designs will give you a hint to the number of > stages an instruction goes through. Pipeline delays are what you try to > avoid. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 8:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did some searching, but I didn't find anything that really discussed > this on the topic that I'm interested. Is there anything published that > compares the cycle times of the most used instructions? > > For example; moving an address between areas of storage. I would assume > that executing a LOAD and STORE would be much quicker than executing a > MVC. > > Or executing a LOAD ADDRESS to increment a register instead of ADD HALF > WORD. > > Or does this really matter as much as ordering the instructions so they > are optimized for the pipeline? > > -- > 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 For information, services and offers, please visit our web site: http://secure-web.cisco.com/1T5nXB8Bc0GfZhygQ3QL9m2Rqt8WrE_YyxT1MEa4iBF26maoZxLmm274HfBpvsXn1rz5y_Ns2rDdABsrMKkUbpT5gmhyoqUBNttoRDLe_YjDmxeQotvM27_m8mS9VChJ7dXF3IpnkUfr93tUP4KSi2GM0-Z6yQCT39TL8DVHgbmBRmR8teJY_y78IArdrlX
Re: ISPF Question - browsing variable length records
> No, I asked about adding a blank at the end of a line If you type a blank at the end of a line filled with nulls then on a 3270 or compliant 3270 simulator the nulls will not be read and ISPF will not be able to determine that the blank was at the end of the line. > No, if I do that now, Read Modified returns that blank to the host. On a 3270 it does not return the nulls preceding the blank. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, August 13, 2019 4:44 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Question - browsing variable length records On Tue, 13 Aug 2019 19:55:19 +, Seymour J Metz wrote: >> When I care, I set NULLS OFF, or use the spacebar. > >That's the right answer to the wrong question. You were asking about the >ability to insert a blank in the middle of a string of nulls. > No, I asked about adding a blank at the end of a line. >> Which is why I didn't suggest IBM change it, nor change the 3270 >> specification. > >You wrote "It should be intuitive: add blanks by positioning the cursor at the >end of the line and pressing the spacebar." That would require a change in the >3270 specifications. > No, if I do that now, Read Modified returns that blank to the host. ISPF Edit discards it. -- gil -- 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: Instruction speeds
A couple of observations on Y2K accommodation. -- As my shop was slogging through remediation required for year 2000, insurance companies apparently coasted along because they had ALWAYS needed to handle four-digit years from the inception of IT. For them it was business as usual. -- Can't cite attribution, but I remember the calculation that despite our late 1990s poignant misery, the ancient choice to represent dates with two digits was actually economically correct. The burdensome cost of both media and memory storage in, say, 1970, outweighed on balance the eventual cost of remediation. It's easy to ask what difference two bytes would have made, but the hard-money cost of billions and billions of 'extra' bytes would have been substantial. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Wednesday, August 14, 2019 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Instruction speeds > That assumes that you know what is unnecessary. The smart money says that the > unnecessary code will turn out to be necessary, at the least convenient time. > A nice example is how to determine leap years: from as long as I program the > flow is: >- dividable by 4? >- dividable by 100? >- dividable by 400? The last 2 are completely unnecessary until the year 2100. And in the year 2100 people will curse you for deciding that it's unnecessary. Après Moi Le Déluge (Après nous le deluge for purists.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 14, 2019 2:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: 13 August, 2019 19:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > Avoid processor-specific optimizations; what is millicode on one box > may not be on another. Worry first about getting your code correct and > maintainable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on > behalf of Christopher Y. Blaicher > Sent: Monday, August 12, 2019 9:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > There is no instruction cycle time table. There are some general > guidelines you can follow. > > Don't overload cache. Locality of reference for instructions and data > is important. > > The machine will do out-of-order instruction processing, but there are > limits. If you load a register don't use it as a base register in the > next instruction, if you can help it. > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up > to about 32K. > > JUMPs are faster than BRANCHes. > > Don't use instructions that set the condition code, unless you need it. > > Millicode instructions have startup and shutdown overheads. Many > times you can go faster using open code to do what a millicode instruction > does. > > Here is one that has nothing to do with an instruction - Don't assign > CPs from different drawers to an LPAR, that includes ZIIPs. Task > switching across drawers kills cache and kills performance. You will > lose hundreds, if not thousands, of cycles. > > There are some articles on the net that go over processor design and > cache design. The processor designs will give you a hint to the > number of stages an instruction goes through. Pipeline delays are > what you try to avoid. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 8:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did some searching, but I didn't find anything that really discussed > this on the topic that I'm interested. Is there anything published > that compares the cycle times of the most used instructions? > > For example; moving an address between areas of storage. I would > assume that executing a LOAD and STORE would be much quicker than > executing a MV
Re: ISPF Question - browsing variable length records
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54em00/nulls.htm ISPF edit option NULLS. Choose your poison as needed. NULLS OFF - end of field filled with blanks. NULLS ALL - end of field filled with nulls. NULLS STD - end of field gets 1 blank and the rest nulls. On Wed, Aug 14, 2019 at 10:04 AM Seymour J Metz wrote: > > > No, I asked about adding a blank at the end of a line > > If you type a blank at the end of a line filled with nulls then on a 3270 or > compliant 3270 simulator the nulls will not be read and ISPF will not be able > to determine that the blank was at the end of the line. > > > No, if I do that now, Read Modified returns that blank to the host. > > On a 3270 it does not return the nulls preceding the blank. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> > Sent: Tuesday, August 13, 2019 4:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Question - browsing variable length records > > On Tue, 13 Aug 2019 19:55:19 +, Seymour J Metz wrote: > > >> When I care, I set NULLS OFF, or use the spacebar. > > > >That's the right answer to the wrong question. You were asking about the > >ability to insert a blank in the middle of a string of nulls. > > > No, I asked about adding a blank at the end of a line. > > >> Which is why I didn't suggest IBM change it, nor change the 3270 > >> specification. > > > >You wrote "It should be intuitive: add blanks by positioning the cursor at > >the end of the line and pressing the spacebar." That would require a change > >in the 3270 specifications. > > > No, if I do that now, Read Modified returns that blank to the host. ISPF > Edit discards it. > > -- gil > > -- > 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 -- 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: ISPF Question - browsing variable length records
None of those will do what the OP asked for, although there are nonstandard 3270 simulators that will allow him to fake it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Mike Schwab Sent: Wednesday, August 14, 2019 12:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF Question - browsing variable length records https://secure-web.cisco.com/1Vdi35Xrq1vk2pXi0XGMY0t_9CfdL8t9vGkiy0t9rpr3M1BwwRibFt9w63EX6f2oULrnP5q9GIZkIfLk22Ow9EZjRaMBP7Pl_fFk5lir6CmMNdNP0pv12xgMTwHNxWfufQWqgx2e-nrk7ZUrglGzUON_zNm6oZ12cLTaeqFrYbIeJC_v18ABN-lRoNc0mrWGQhMb11t1AXq-U7sG4bf5M2Pu0kxaMNXYyUYSBL7qfePL8tTqQcOBDe0MP9GR2s1NYJnv72EqkRJUDQIHBKZevY5TP9OrDufmEzVRCL1lsz1UnlR59iwfu6M_SCAxVmRZgwpBqPVUHYR9Bv9s--xMxzAXF_9wGpi3TWrPT51ZyAbP5ln2RUf5IvLT5yLKcpxjc/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2Fen%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.f54em00%2Fnulls.htm ISPF edit option NULLS. Choose your poison as needed. NULLS OFF - end of field filled with blanks. NULLS ALL - end of field filled with nulls. NULLS STD - end of field gets 1 blank and the rest nulls. On Wed, Aug 14, 2019 at 10:04 AM Seymour J Metz wrote: > > > No, I asked about adding a blank at the end of a line > > If you type a blank at the end of a line filled with nulls then on a 3270 or > compliant 3270 simulator the nulls will not be read and ISPF will not be able > to determine that the blank was at the end of the line. > > > No, if I do that now, Read Modified returns that blank to the host. > > On a 3270 it does not return the nulls preceding the blank. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf of > Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> > Sent: Tuesday, August 13, 2019 4:44 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: ISPF Question - browsing variable length records > > On Tue, 13 Aug 2019 19:55:19 +, Seymour J Metz wrote: > > >> When I care, I set NULLS OFF, or use the spacebar. > > > >That's the right answer to the wrong question. You were asking about the > >ability to insert a blank in the middle of a string of nulls. > > > No, I asked about adding a blank at the end of a line. > > >> Which is why I didn't suggest IBM change it, nor change the 3270 > >> specification. > > > >You wrote "It should be intuitive: add blanks by positioning the cursor at > >the end of the line and pressing the spacebar." That would require a change > >in the 3270 specifications. > > > No, if I do that now, Read Modified returns that blank to the host. ISPF > Edit discards it. > > -- gil > > -- > 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 -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
There were other options to reduce the storage requirement of a date, e.g., store them in binary. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jesse 1 Robinson Sent: Wednesday, August 14, 2019 12:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds A couple of observations on Y2K accommodation. -- As my shop was slogging through remediation required for year 2000, insurance companies apparently coasted along because they had ALWAYS needed to handle four-digit years from the inception of IT. For them it was business as usual. -- Can't cite attribution, but I remember the calculation that despite our late 1990s poignant misery, the ancient choice to represent dates with two digits was actually economically correct. The burdensome cost of both media and memory storage in, say, 1970, outweighed on balance the eventual cost of remediation. It's easy to ask what difference two bytes would have made, but the hard-money cost of billions and billions of 'extra' bytes would have been substantial. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Seymour J Metz Sent: Wednesday, August 14, 2019 7:49 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Instruction speeds > That assumes that you know what is unnecessary. The smart money says that the > unnecessary code will turn out to be necessary, at the least convenient time. > A nice example is how to determine leap years: from as long as I program the > flow is: >- dividable by 4? >- dividable by 100? >- dividable by 400? The last 2 are completely unnecessary until the year 2100. And in the year 2100 people will curse you for deciding that it's unnecessary. Après Moi Le Déluge (Après nous le deluge for purists.) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Vernooij, Kees (ITOP NM) - KLM Sent: Wednesday, August 14, 2019 2:18 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds And: don't write unnecessary code. A nice example is how to determine leap years: from as long as I program the flow is: - dividable by 4? - dividable by 100? - dividable by 400? The last 2 are completely unnecessary until the year 2100. How many useless instructions will have been executed for this reason in the 150 years until 2100? How much of our assembler code will live until 2100? Lots were not even prepared for 2000. Kees. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Seymour J Metz > Sent: 13 August, 2019 19:23 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > Avoid processor-specific optimizations; what is millicode on one box > may not be on another. Worry first about getting your code correct and > maintainable. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on > behalf of Christopher Y. Blaicher > Sent: Monday, August 12, 2019 9:32 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Instruction speeds > > There is no instruction cycle time table. There are some general > guidelines you can follow. > > Don't overload cache. Locality of reference for instructions and data > is important. > > The machine will do out-of-order instruction processing, but there are > limits. If you load a register don't use it as a base register in the > next instruction, if you can help it. > > MVC is a lot faster than MVCL. A series of MVC's will beat a MVCL up > to about 32K. > > JUMPs are faster than BRANCHes. > > Don't use instructions that set the condition code, unless you need it. > > Millicode instructions have startup and shutdown overheads. Many > times you can go faster using open code to do what a millicode instruction > does. > > Here is one that has nothing to do with an instruction - Don't assign > CPs from different drawers to an LPAR, that includes ZIIPs. Task > switching across drawers kills cache and kills performance. You will > lose hundreds, if not thousands, of cycles. > > There are some articles on the net that go over processor design and > cache design. The processor designs will give you a hint to the > number of stages an instruction goes through. Pipeline delays are > what you try to avoid. > > Chris Blaicher > Technical Architect > Syncsort, Inc. > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Brian Chapman > Sent: Monday, August 12, 2019 8:48 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Instruction speeds > > Hi everyone, > > I did so
Re: ISPF Question - browsing variable length records
On Wed, 14 Aug 2019 17:17:01 +, Seymour J Metz wrote: >None of those will do what the OP asked for, although there are nonstandard >3270 simulators that will allow him to fake it. > Actually, no, because ISPF conceals from the emulator the number of characters counted by the RDW > >From: IBM Mainframe Discussion List Mike Schwab >Sent: Wednesday, August 14, 2019 12:20 PM > > https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.f54em00/nulls.htm >ISPF edit option NULLS. Choose your poison as needed. >NULLS OFF - end of field filled with blanks. >NULLS ALL - end of field filled with nulls. >NULLS STD - end of field gets 1 blank and the rest nulls. > Alas, it lacks: NULLS ??? End of field gets blanks counted by RDW and the rest nulls. (Blanks should be treated no different from any other valid characters; stripped neither on output nor on input.) >On Wed, Aug 14, 2019 at 10:04 AM Seymour J Metz wrote: >> >> > No, I asked about adding a blank at the end of a line >> >> If you type a blank at the end of a line filled with nulls then on a 3270 or >> compliant 3270 simulator the nulls will not be read and ISPF will not be >> able to determine that the blank was at the end of the line. >> >> > No, if I do that now, Read Modified returns that blank to the host. >> >> On a 3270 it does not return the nulls preceding the blank. >> And here, we've been in tediously intense agreement: https://www.ibm.com/support/knowledgecenter/SSGMCP_5.1.0/com.ibm.cics.ts.applicationprogramming.doc/topics/dfhp3c6.html -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
On Wed, 14 Aug 2019 17:21:06 +, Seymour J Metz wrote: >There were other options to reduce the storage requirement of a date, e.g., >store them in binary. > In some cases, dates have been stored in two-byte signed decimal, biased by -1900, supporting dates through 2899 with minimal code change. > >From: Jesse 1 Robinson >Sent: Wednesday, August 14, 2019 12:10 PM > >-- Can't cite attribution, but I remember the calculation that despite our >late 1990s poignant misery, the ancient choice to represent dates with two >digits was actually economically correct. The burdensome cost of both media >and memory storage in, say, 1970, outweighed on balance the eventual cost of >remediation. It's easy to ask what difference two bytes would have made, but >the hard-money cost of billions and billions of 'extra' bytes would have been >substantial. > Me, too. However I doubt that many organizations invested those savings in reliable securities to be redeemed for the eventual cost of remediation. In the mid 80s, I suggested that a product we were designing store 4-digit years in anticipation of Y2K. Overruled by manager: o No then available OS interface reported 4-digit years. o No need; who cares?! -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
Yes, I am sometimes amazed at the choices made, the contradiction between omitting data to save storage, while storing the remainder in an inefficient format. An example I dealt with a lot was the "SMF timestamp" format: eight bytes consisting of the time in hundredths of a second past midnight in binary followed by the date in "packed Julian": 00 yy dd dF. No century, even though there are two unused and one constant nibbles; and time in hundredths, even though milliseconds or ten-thousandths would have fit in a 32-bit integer. (And yes, I know they kludged the century for Y2K into one unused nibble.) Not to mention that time in microseconds since 1900 would have fit in a 64-bit integer. Of course, ease of conversion and formatting is/was also a factor. The year could have been stored in binary, but that might have required conversion from and to decimal as punched into Hollerith cards and printed on reports. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, August 14, 2019 10:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds There were other options to reduce the storage requirement of a date, e.g., store them in binary. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
On Wed, 14 Aug 2019 11:34:14 -0700, Charles Mills wrote: >... Not to mention that time in microseconds since 1900 would have fit in a >64-bit integer. > With a several thousand year range. And when another choice was made there were many extant birth dates and contract dates prior to 1900. I still feel that ETOD should be made signed to accommodate historic dates. >Of course, ease of conversion and formatting is/was also a factor. The year >could have been stored in binary, but that might have required conversion from >and to decimal as punched into Hollerith cards and printed on reports. > IBM, more than most other suppliers, was swayed by a desire that the storage format be human-readable. I suspect this was the motive for making packed decimal sign-magnitude rather than 10s-complement which would have provided 5 times the range in the same storage and avoided the need for a recomplement when the result has unexpected sign. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
Le 14/08/2019 à 18:10, Jesse 1 Robinson a écrit : A couple of observations on Y2K accommodation. -- As my shop was slogging through remediation required for year 2000, insurance companies apparently coasted along because they had ALWAYS needed to handle four-digit years from the inception of IT. For them it was business as usual. -- Can't cite attribution, but I remember the calculation that despite our late 1990s poignant misery, the ancient choice to represent dates with two digits was actually economically correct. The burdensome cost of both media and memory storage in, say, 1970, outweighed on balance the eventual cost of remediation. It's easy to ask what difference two bytes would have made, but the hard-money cost of billions and billions of 'extra' bytes would have been substantial. the smart solution would have been to store year as 2 bytes binary integer, they'd have been good for 65535 years... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPU time cost of dynamic allocation
In z/OS 1.12, the original CPITCBTM and CPISRBTM "Initiator" TOTAL CPU times were (finally!) separated into the Init-to-Load "INIT" CPU times (CPITCITM/CPISRITM) for the CPU times prior to LOADTIME, and into "TERM" CPU times (CPITCTTM/CPISRTTM) from the end of your program execution until the last SMF record is written (steps with MANY DD's write MANY SMF 30 subtype 4 records for a single step, and more records at job termination for the last step). This schematic maps the where the CP Engine CPU times in SMF 30-4 Step Termination Records are recorded: FIRST SMFLAST SMF INITTIME ALOCTIME LOADTIME TERMTIME TERMTIME 1->2--34www5 | | | | | |<-DSENQ-->|<-ALOCTM->|| | | | || | | | || | |I||TTT| | CPITCITM |CPUTCBTM| CPITCTTM | | CPISRITMCPUSRBTM| CPISRTTM | CPUHPTTM CPUIIPTM CPURCTTM Barry -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Tuesday, August 6, 2019 2:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation Can you please clarify? Your first sentence seems to say that SVC 99 (or do you mean Initiator) CPU time is in the SMF 30? Can you be more specific? Your last sentence seems to say the opposite? Or ... ? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Allan Staller Sent: Tuesday, August 6, 2019 12:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation This allocation time can be calculated from SMF type 30. I am sure time is tracked. I am not sure the associated CPU is tracked. -Original Message- From: IBM Mainframe Discussion List On Behalf Of Paul Gilmartin Sent: Tuesday, August 6, 2019 11:45 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPU time cost of dynamic allocation On Tue, 6 Aug 2019 12:25:05 -0400, Charles Mills wrote: > >OTOH I have an IEFBR14 batch job on the same machine that allocates 15 >temporary datasets in JCL. The entire job lock, stock and barrel uses >(according to IEF032I) .00 CPU seconds. Can anyone explain why JCL >allocation is apparently much more CPU efficient than SVC 99 allocation? -- 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
Check out Capital One hacker took data from more than 30 companies, new court docs reveal | ZDNet
Capital One hacker took data from more than 30 companies, new court docs reveal | ZDNet Probably just the tip of the iceberg. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
IBM has published the LSPR numbers for thirty years. They're a ballpark of what to expect.Each company should have a benchmark workload for capacity planning and growth. In 2017 WDC came out with MF counters to help measure the effects of different workloads.http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/TC66 There have been some whoppers in reporting. Like the 9672-n3 to n4 weren't adding up to expectations. Cheryl pointed out what had happened was they ran out of room on the chip and had to add an off-board processor for some of the instructions. It was really nasty in some of the COBOL programs with Indexed by usage was high. So in the LSPR numbers no COBOL pgms with Indexed-by were used. There were also a couple z9's sent back because they were slower than the predecessors with 'old COBOL'. Always something...In a message dated 8/14/2019 1:50:42 PM Central Standard Time, jcew...@acm.org writes: In 1965, even thoseexposed to S/360 would have had no experience yet to make them assumethe architecture would be stable enough and kept as a subset of futurearchitectures to allow running the same code decades later, much lesshave z-architecture hardware supporting the same instructions as asubset in 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Local time in C on z/OS
I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. Looking at the code, it's using ctime(). Ok, hey, localtime() should be gooderT! Nope, per IBM doc: * The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable. * In POSIX you can supply the necessary information by using environment variables. Gee, thanks (and what does "now" mean in that first sentence? As opposed to tomorrow?? Last week???). I'm not in a position to set environment variables for this. I know the hardware is set to UTC, but there's a system timezone offset at some level. Is there no simple way to just say "Gimme the same time as the operator's console would show"? Searching sure hasn't found one, hoping someone knows better! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Reason for 2 digit years was Re: Instruction speeds
[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >There were other options to reduce the storage requirement of a date, e.g., >store them in binary. > The conversion to and from binary would have been costly in CPU time and for dates stored as packed decimal 0yymmdds the use of the high order nibble would have worked at the cost of complexity. I suspect that the real saving was in data entry and the desire to fit as much information on one 80 byte punch card as well as on to a 132 character print line. I note that my credit cards still use 2 digit years. Clark Morris > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on behalf of >Jesse 1 Robinson >Sent: Wednesday, August 14, 2019 12:10 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Instruction speeds > >A couple of observations on Y2K accommodation. > >-- As my shop was slogging through remediation required for year 2000, >insurance companies apparently coasted along because they had ALWAYS needed to >handle four-digit years from the inception of IT. For them it was business as >usual. > >-- Can't cite attribution, but I remember the calculation that despite our >late 1990s poignant misery, the ancient choice to represent dates with two >digits was actually economically correct. The burdensome cost of both media >and memory storage in, say, 1970, outweighed on balance the eventual cost of >remediation. It's easy to ask what difference two bytes would have made, but >the hard-money cost of billions and billions of 'extra' bytes would have been >substantial. > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ?=== NEW >robin...@sce.com > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Seymour J Metz >Sent: Wednesday, August 14, 2019 7:49 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: Instruction speeds > >> That assumes that you know what is unnecessary. The smart money says that >> the unnecessary code will turn out to be necessary, at the least convenient >> time. > >> A nice example is how to determine leap years: from as long as I program the >> flow is: >>- dividable by 4? >>- dividable by 100? >>- dividable by 400? > >The last 2 are completely unnecessary until the year 2100. > >And in the year 2100 people will curse you for deciding that it's unnecessary. > >Après Moi Le Déluge (Après nous le deluge for purists.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
It's complicated. To the best of my grokking, z/OS maintains two totally independent time offsets. If the POSIX locale is not set, then any UNIX-ey type calls do not know the local time offset. You're free to call MVS TIME. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Wednesday, August 14, 2019 3:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Local time in C on z/OS I have a C POSIX application that writes timestamps on its output. It's always produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I thought maybe I could fix it. Looking at the code, it's using ctime(). Ok, hey, localtime() should be gooderT! Nope, per IBM doc: * The ctime(), localtime(), and mktime() functions now return Coordinated Universal Time (UTC) unless customized locale information is made available, which includes setting the timezone_name variable. * In POSIX you can supply the necessary information by using environment variables. Gee, thanks (and what does "now" mean in that first sentence? As opposed to tomorrow?? Last week???). I'm not in a position to set environment variables for this. I know the hardware is set to UTC, but there's a system timezone offset at some level. Is there no simple way to just say "Gimme the same time as the operator's console would show"? Searching sure hasn't found one, hoping someone knows better! -- 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: Local time in C on z/OS
On Wed, 14 Aug 2019 18:10:12 -0400, Phil Smith III wrote: >I have a C POSIX application that writes timestamps on its output. It's always >produced a GMT timestamp (pardon me, UTC), and that's sort of fugly, so I >thought maybe I could fix it. > >Looking at the code, it's using ctime(). Ok, hey, localtime() should be >gooderT! Nope, per IBM doc: > >* The ctime(), localtime(), and mktime() functions now return Coordinated >Universal Time (UTC) unless customized locale information is made available, >which includes setting the timezone_name variable. > >* In POSIX you can supply the necessary information by using environment >variables. > >Gee, thanks (and what does "now" mean in that first sentence? As opposed to >tomorrow?? Last week???). > >I'm not in a position to set environment variables for this. I know the >hardware is set to UTC, but there's a system timezone offset at some level. Is >there no simple way to just say "Gimme the same time as the operator's console >would show"? Searching sure hasn't found one, hoping someone knows better! > (Actually, the hardware is set, not to UTC, but to TAI - 10 seconds. See PoOp.) I believe "now" means "current release". They seem to be reserving the right to change. Is this for your own site, or distribution to customers? "environment" variables are local to your execution image. You can set and change them without affecting the outside world. Investigate tzset(). z/OS is woefully inconsistent intreatment of timezones. It seems compelled to regard Classic and UNIX as separate, noninteracting worlds. Other UNIX-like systems provide a sytem default timezone, e.g.: 580 $ ls -l /etc/localtime lrwxr-xr-x 1 root wheel 40 Jul 20 09:58 /etc/localtime -> /var/db/timezone/zoneinfo/America/Denver I tried to report this as a defect in an SR. WAD. It must remain broken for compatibility with AIX. You might be able to spawn() (BPX1SPN) a shell command to return what the site's shell sees as TZ. Java may do it better. And it uses the zoneinfo data base. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
Poked around some more, found https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J which looked promising, but this: time_t ltime; static char hhmmss[9]; struct tm *tmptr; char* timeptr; time(
Re: Reason for 2 digit years was Re: Instruction speeds
It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms and foredads for the reckless choice they made decades ago to store dates in two-digit format. Making our lives miserable in the process. OTOH I remember reading some diary excerpts from US Civil War soldiers who routinely recorded dates as 61, 63, and so on. Suppose you were an influencer in, say, 1975. Would you walk into an application design meeting and propose *any* change to date representation? There were already countless date fields stored in other intersecting applications. Those would have to change also or be interfaced only with conversion routines. I think the only point in IT history where a radical change actually made sense was just when it happened: right ahead of the wrecking ball. And rather than saturate the landscape with a gajillion *useless* year digits, many companies were content to implement sliding windows that permanently solved the problem with minimal extra storage space. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Clark Morris Sent: Wednesday, August 14, 2019 3:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Reason for 2 digit years was Re: Instruction speeds [Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main sme...@gmu.edu (Seymour J Metz) wrote: >There were other options to reduce the storage requirement of a date, e.g., >store them in binary. > The conversion to and from binary would have been costly in CPU time and for dates stored as packed decimal 0yymmdds the use of the high order nibble would have worked at the cost of complexity. I suspect that the real saving was in data entry and the desire to fit as much information on one 80 byte punch card as well as on to a 132 character print line. I note that my credit cards still use 2 digit years. Clark Morris > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > >From: IBM Mainframe Discussion List on >behalf of Jesse 1 Robinson >Sent: Wednesday, August 14, 2019 12:10 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Instruction speeds > >A couple of observations on Y2K accommodation. > >-- As my shop was slogging through remediation required for year 2000, >insurance companies apparently coasted along because they had ALWAYS needed to >handle four-digit years from the inception of IT. For them it was business as >usual. > >-- Can't cite attribution, but I remember the calculation that despite our >late 1990s poignant misery, the ancient choice to represent dates with two >digits was actually economically correct. The burdensome cost of both media >and memory storage in, say, 1970, outweighed on balance the eventual cost of >remediation. It's easy to ask what difference two bytes would have made, but >the hard-money cost of billions and billions of 'extra' bytes would have been >substantial. > >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ?=== NEW >robin...@sce.com > >-Original Message- >From: IBM Mainframe Discussion List On >Behalf Of Seymour J Metz >Sent: Wednesday, August 14, 2019 7:49 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Re: Instruction speeds > >> That assumes that you know what is unnecessary. The smart money says that >> the unnecessary code will turn out to be necessary, at the least convenient >> time. > >> A nice example is how to determine leap years: from as long as I program the >> flow is: >>- dividable by 4? >>- dividable by 100? >>- dividable by 400? > >The last 2 are completely unnecessary until the year 2100. > >And in the year 2100 people will curse you for deciding that it's unnecessary. > >Après Moi Le Déluge (Après nous le deluge for purists.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Wed, 14 Aug 2019 15:32:59 -0700, Charles Mills wrote: >It's complicated. To the best of my grokking, z/OS maintains two totally >independent time offsets. If the POSIX locale is not set, then any UNIX-ey >type calls do not know the local time offset. > More than two. There are multiple startup scripts which independently, not necessarily consistently, specify TZ. >You're free to call MVS TIME. > There are lots of other things I'd like to call MVS. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Instruction speeds
This is really interesting. For those put off by the "C++" note that the issue has nothing whatsoever to do with C++. It is a pure branch prediction issue. Picture a program that computes an array of pseudo-random 8-bit integers from 0 to 255. Then it solves the problem "what is the sum of all of the numbers in the table greater than or equal to 128?" It does that with the obvious loop, which then contains IC R0,next_table_byte CHI R0,128 JL *+6 AR R2,R0 The assertion of the thread -- and I don't doubt it -- is that the above code uses 1/6 the CPU time if you first sort the table. (Obviously, a stupid way of doing things: you could sort the table high to low and then exit once you got a value below 128; but that's not the point.) It illustrates the value of, or problem with, depending on your point of view, branch prediction. If the table is random then the outcome of the CHI/JL is unpredictable, and the branch prediction is at best useless and at worst counter-productive. But if the table is sorted, then the branch prediction has a chance to be right most of the time. There's a lot more than that in the thread, and it fundamentally has to do with modern CPU technology, not C++. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of David Crayford Sent: Tuesday, August 13, 2019 11:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Instruction speeds Some interesting information on branch prediction in that paper. If you've got a z/OS C++ compiler try this snippet out, it's fascinating: https://stackoverflow.com/questions/11227809/why-is-processing-a-sorted-array-faster-than-processing-an-unsorted-array -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Local time in C on z/OS
On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III wrote:
>Poked around some more, found
>
>https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
>
>which looked promising, but this:
> [ ... ]
A few suggestions:
Do you also need the date? That should be derived from the same
call to time(); lest midnight intrude.
615 $ cat when.c
#include
#include
#include
#include
time_t ltime;
static char hhmmss[9];
struct tm *tmptr;
int main( int argc, char **argv ) {
time(
Re: Reason for 2 digit years was Re: Instruction speeds
[Default] On 14 Aug 2019 15:50:58 -0700, in bit.listserv.ibm-main jesse1.robin...@sce.com (Jesse 1 Robinson) wrote: >It's a modern day cottage industry--or hobby maybe--to excoriate our foremoms >and foredads for the reckless choice they made decades ago to store dates in >two-digit format. Making our lives miserable in the process. OTOH I remember >reading some diary excerpts from US Civil War soldiers who routinely recorded >dates as 61, 63, and so on. > >Suppose you were an influencer in, say, 1975. Would you walk into an >application design meeting and propose *any* change to date representation? >There were already countless date fields stored in other intersecting >applications. Those would have to change also or be interfaced only with >conversion routines. > >I think the only point in IT history where a radical change actually made >sense was just when it happened: right ahead of the wrecking ball. And rather >than saturate the landscape with a gajillion *useless* year digits, many >companies were content to implement sliding windows that permanently solved >the problem with minimal extra storage space. > As someone involved in a Year 2000 project where I both validated the functioning of the windows used by one software vendor and wrote the date subroutine used for 4 digit year date handling, I guarantee sliding or fixed windows do not necessarily solve the problem for all time. The sliding window may well do it going forward depending on the data other than for year 00 and if keyed against a current 4 digit year handle that it might even do that. However, the window only works where the range of dates in the active data is 100 years or less and would fail on birth dates for all of the centenarians among us including a retired pastor of my church. Using sliding windows could be dicey when dealing with historic data. In general, each application should be reviewed to see if long term 2 digit years can lead to wrong results regardless of windowing provision chosen. Clark Morris >. >. >J.O.Skip Robinson >Southern California Edison Company >Electric Dragon Team Paddler >SHARE MVS Program Co-Manager >323-715-0595 Mobile >626-543-6132 Office ?=== NEW >robin...@sce.com > >-Original Message- >From: IBM Mainframe Discussion List On Behalf Of >Clark Morris >Sent: Wednesday, August 14, 2019 3:29 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: (External):Reason for 2 digit years was Re: Instruction speeds > >[Default] On 14 Aug 2019 10:21:17 -0700, in bit.listserv.ibm-main >sme...@gmu.edu (Seymour J Metz) wrote: > >>There were other options to reduce the storage requirement of a date, e.g., >>store them in binary. >> >The conversion to and from binary would have been costly in CPU time and for >dates stored as packed decimal 0yymmdds the use of the high order nibble would >have worked at the cost of complexity. I suspect that the real saving was in >data entry and the desire to fit as much information on one 80 byte punch card >as well as on to a 132 character print line. I note that my credit cards >still use 2 digit years. > >Clark Morris >> >>-- >>Shmuel (Seymour J.) Metz >>http://mason.gmu.edu/~smetz3 >> >> >>From: IBM Mainframe Discussion List on >>behalf of Jesse 1 Robinson >>Sent: Wednesday, August 14, 2019 12:10 PM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: Re: Instruction speeds >> >>A couple of observations on Y2K accommodation. >> >>-- As my shop was slogging through remediation required for year 2000, >>insurance companies apparently coasted along because they had ALWAYS needed >>to handle four-digit years from the inception of IT. For them it was business >>as usual. >> >>-- Can't cite attribution, but I remember the calculation that despite our >>late 1990s poignant misery, the ancient choice to represent dates with two >>digits was actually economically correct. The burdensome cost of both media >>and memory storage in, say, 1970, outweighed on balance the eventual cost of >>remediation. It's easy to ask what difference two bytes would have made, but >>the hard-money cost of billions and billions of 'extra' bytes would have been >>substantial. >> >>. >>. >>J.O.Skip Robinson >>Southern California Edison Company >>Electric Dragon Team Paddler >>SHARE MVS Program Co-Manager >>323-715-0595 Mobile >>626-543-6132 Office ?=== NEW >>robin...@sce.com >> >>-Original Message- >>From: IBM Mainframe Discussion List On >>Behalf Of Seymour J Metz >>Sent: Wednesday, August 14, 2019 7:49 AM >>To: IBM-MAIN@LISTSERV.UA.EDU >>Subject: (External):Re: Instruction speeds >> >>> That assumes that you know what is unnecessary. The smart money says that >>> the unnecessary code will turn out to be necessary, at the least convenient >>> time. >> >>> A nice example is how to determine leap years: from as long as I program >>> the flow is: >>>- dividable by 4? >>>- dividable by 100? >>>- dividable by 400? >> >>The last 2
Re: Local time in C on z/OS
IMO, the underlying problem with z/OS Unix localtime() is that environment
variable initialization is brain dead in z/OS. In other Unix/Posix
implementations, /etc/rc initializes environment variables for the "init"
process (usually pid=1). All other processes inherit from it.
In z/OS, along with /etc/rc there is /etc/init.options which initializes
the environment for the init process, but only *some* z/OS Unix processes
inherit from it.
z/OS Unix Processes that are "blind dubbed" do not. These include normal
batch jobs and started tasks that use z/OS Unix services.
What does this mean? Well, you should be able to set TZ in /etc/rc or
/etc/init.options and have *all* processes inherit it in their
environment. Then all of the localtime() calls get the same system
default timezone. from one place.
In z/OS however, you have to manually configure TZ for each job that
doesn't inherit its environment from the init process.This can cause
all sorts of problems in z/OS Unix, but TZ is an easy one to understand.
(BTW: You only need to call tzset() if you want to change the current
process' timezone after the process starts).
I submitted this RFE back in 2014, and it was marked "uncommitted
candidate" in 2016, but it doesn't look to me like it made it into V2R4.
So I'm not holding my breath.
https://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=59716
On Wed, Aug 14, 2019 at 8:06 PM Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Wed, 14 Aug 2019 18:48:22 -0400, Phil Smith III
> wrote:
>
> >Poked around some more, found
> >
> >
> https://groups.google.com/forum/#!msg/bit.listserv.ibm-main/mYYcbXg0lGY/hu0cNy5TO30J
> >
> >which looked promising, but this:
> > [ ... ]
> A few suggestions:
> Do you also need the date? That should be derived from the same
> call to time(); lest midnight intrude.
>
> 615 $ cat when.c
> #include
> #include
> #include
> #include
>
> time_t ltime;
>
> static char hhmmss[9];
>
> struct tm *tmptr;
>
> int main( int argc, char **argv ) {
>time(
>if ( ! getenv( "TZ" ) ) /* Support caller's setting of TZ. */
>setenv("TZ","CST6CDT",1);
>
>tzset();
>
>tmptr = localtime(
> /* timeptr = asctime(tmptr);
>memcpy(&hhmmss, timeptr+11, 8);
>hhmmss[8] = 0;
>Deprecated; see
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/asctime.html#tag_16_21_07
>So: */
>strftime( hhmmss, 9, "%H:%M:%s\0", tmptr );
>
>printf( "%s\n", hhmmss); /* show result. */
>return( 0 );
> }
> -- gil
>
> --
> 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: Mainframes testing
Lennie Dymoke-Bradshaw wrote: >The IBM paper reads as if it has been written by >someone with relatively little System z knowledge. You seem to be assuming that mainframes don't run Linux and aren't UNIX(TM) servers. If so, that's not a reasonable assumption. I agree with Charles Mills. As an analogy, it's still possible to find useful, basic (at least) information about cancer without reading a dozen peer reviewed articles published in the New England Journal of Medicine, The Lancet, and The Journal of the American Medical Association. Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE 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
Re: Mainframes testing
Let's quote the author directly, OK? I'm going to quote the whole second section since context is important: "2. Data Left Behind "Because mainframes were once typically set-up-and-forget systems, they often contain sensitive data files that should have been deleted after the deployment phase ended. Certain data should not be written to a space that just any user can access. "We had one mainframe hacker who logged into the mainframe as an unprivileged user and immediately saw a highly sensitive file that contained information she could have used to compromise high-privileged users in the company’s environment. Files, such as lists of usernames and passwords and confidential client information, should not remain on the mainframe, where they are exposed to any type of user who gains physical or remote access." I don't think this is a particularly well written (or well edited? editors can sometimes do damage) piece of text -- let me just say that up front. However, in context, it's not awful. Let's work through this together "Because mainframes were once typically set-up-and-forget systems" That's not the first description that comes to mind of classic mainframes running MVS, for example. However, that is an excellent description of IBM AS/400s, and I have seen more than a few references to AS/400s (and IBM i machines) as "mainframes." That said, the first sentence is my least favorite. Sentence #2 in this section is quite important for context. "Files, such as lists of usernames and passwords and confidential client information, should not remain on the mainframe, where they are exposed to any type of user who gains physical or remote access." I don't think we should automatically blame the author for a stray comma. Let me oh-so-slightly adjust this sentence, and I'm going to add three words just to emphasize the problem with that comma: "Files, such as lists of usernames and passwords and confidential client information, should not remain on the mainframe or anywhere else where they are exposed to any type of user who gains physical or remote access." It's a very, very reasonable interpretation in context that that's what the author meant, but the comma, in particular, wasn't at all helpful. No, that comma certainly shouldn't be there, but it's a comma, and editors (and sometimes authors) unfortunately make punctuation mistakes. Has anyone who doesn't like this article bothered to contact the author, or at least try, to suggest improvements? If not, why not? Timothy Sipples IT Architect Executive, Industry Solutions, IBM Z & LinuxONE 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
Re: Reason for 2 digit years was Re: Instruction speeds
2 digit years I recall a shop who throughout the 70's implemented 1 digit year dates across their files because of the precious cost and availability of DASD space. In 1979, someone there took are hard look at what the future held in store. So they did a full conversion project and changed all of their date fields to. 2 digit year dates! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
