Hi,
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:
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
On 2019-08-13 11:47 PM, Charles
It may be fast, but it runs a long time. Talking about 'speed'!
Kees.
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Rick J. Valles
> Sent: 13 August, 2019 18:13
> 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
>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
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
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
[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.
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
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
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
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,
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
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
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
[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
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
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();
setenv("TZ","CST6CDT",1);
tzset();
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
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
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
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
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
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
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
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.
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
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
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, 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
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
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.
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
> 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?
>-
> 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,
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:
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,
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
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
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
40 matches
Mail list logo
