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

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"

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 ---

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. Ye

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 b

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

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

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 >

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? >- div

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

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 c

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. O

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: Wed

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, 20

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 >_

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 chang

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

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 st

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 I

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

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.

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/techdo

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 c

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

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

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,

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 routi

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 startu

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 o

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 fr

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. Maki

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 w

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 ana

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 end

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 a