Virtual Storage Manager in z/OS 1.10 HBB7750 which results in different behavior when storage is Getmained We are trying to understand the ramifications of this change to the GETMAIN and I was wondering if anyone else has dealt with this. I have this document that says
“References to GETMAIN also apply to STORAGE OBTAIN. The description and behavior of the GETMAIN macro as documented in the z/OS MVS Assembler Services Reference remain unchanged by this APAR. With respect to whether or not the system zeroes the newly getmained storage, the guidelines remain as follows: When you obtain storage, the system clears the requested storage to zeros if you obtain either: o 8192 bytes or more from a pageable, private storage subpool. o 4096 bytes or more from a pageable, private storage subpool, with BNDRY=PAGE specified In all other cases you must NOT assume that the storage is cleared to zeros, unless indicated by the return code when CHECKZERO=YES is specified.” The way I read this is getmained storage may not be initialized in all cases. What if I do a CICS GETMAIN and specify INITIMG(BLANK) Even if I figure out what to do with every GETMAIN what do I do about vendor code I don’t have the source so I can’t tell if the code assumes the storage is initialized or not John J. Leonard Application Developer III SOA Team Westfield Group One Park Circle P.O. Box 5001 Westfield Center Ohio 44251-5001 Office (330) 887-8249 Toll Free 1-(800) 243-0210 ext 4308249 Email [email protected] Extension 430-8249 -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of ASSEMBLER-LIST automatic digest system Sent: Thursday, November 19, 2015 12:00 AM To: [email protected] Subject: ASSEMBLER-LIST Digest - 17 Nov 2015 to 18 Nov 2015 (#2015-128) There are 6 messages totaling 200 lines in this issue. Topics of the day: 1. TOD conversion to display (5) 2. Christian OBERLEITNER ist außer Haus. ---------------------------------------------------------------------- Date: Wed, 18 Nov 2015 10:19:18 -0500 From: Victor Gil <[email protected]> Subject: Re: TOD conversion to display We have rather high transaction volume, especially around the market open/close times, so, yes, we did have duplicates before and sometimes had to retry multiple times [based on the bumped sequence number] to provide for uniqueness. I can't go into specifics, but the whole idea was to spread the input queues, containing a dynamic mix of transactions, into logical sub-queues related to their "types", all of which are to be still processed in parallel. However, within a given "type" each distinct transaction "originator" has to be processed sequentially, so that a request to "cancel" an order is delayed until the original order has actually been seen and processed. -Victor- On 2015-11-17, at 10:04, Tony Harminc wrote: > > It seems to me that duplicates are extremely unlikely, given the > relative speed of CPUs and I/O devices these days. Sure, I realize > that each record doesn't imply an I/O operation; there will be > blocking going on. But how long does it take to write out a VSAM > block? Less than a microsecond? The clock values from STCKF on any > modern machine surely have much greater precision than that. > Birthday Paradox, given that the OP has multiple threads. > And in any case, doesn't it make sense to let VSAM catch the duplicate > key and obtain a new one only then? > But perhaps the OP envisions a performance advantage in not specifying the key as unique (does VSAM support that? SQL does, sorta) and guaranteeing uniqueness externally. Are the keys in the DB displayable or in STCK format? Is the performance bottleneck in inserting records or extracting them? -- gil ------------------------------ Date: Wed, 18 Nov 2015 16:23:48 +0100 From: Christian OBERLEITNER <[email protected]> Subject: Christian OBERLEITNER ist außer Haus. Ich werde ab 17.11.2015 nicht im Büro sein. Ich kehre zurück am 23.11.2015. Ich werde Ihre Nachricht nach meiner Rückkehr beantworten. Die Rückmeldung bezieht sich auf ein Mail mit folgendem Thema: Re: TOD conversion to display ____________________________________________________________________________________________ Gesendet (c) GRZ/RACON Linz 2015 Agent 'Abwesenheit' Der Austausch von Nachrichten mit o.a. Absender via e-mail dient ausschließlich Informationszwecken. Rechtsgeschäftliche Erklärungen dürfen über dieses Medium nicht ausgetauscht werden. Correspondence with a.m. sender via e-mail is only for information purposes. This medium is not to be used for the exchange of legally-binding communications. ------------------------------ Date: Wed, 18 Nov 2015 10:00:21 -0700 From: Paul Gilmartin <[email protected]> Subject: Re: TOD conversion to display On 2015-11-18, at 08:19, Victor Gil wrote: > We have rather high transaction volume, especially around the market > open/close times, so, yes, we did have duplicates before and sometimes had to > retry multiple times [based on the bumped sequence number] to provide for > uniqueness. > > I can't go into specifics, but the whole idea was to spread the input queues, > containing a dynamic mix of transactions, into logical sub-queues related to > their "types", all of which are to be still processed in parallel. However, > within a given "type" each distinct transaction "originator" has to be > processed sequentially, so that a request to "cancel" an order is delayed > until the original order has actually been seen and processed. > Ah, yes. The high-frequency trading wars. 60 Minutes had a story a few years ago mentioning how one institution overcame a disadvantage by introducing a wire(!) delay line to delay its competitor's transactions by a few milliseconds. -- gil ------------------------------ Date: Wed, 18 Nov 2015 12:08:22 -0500 From: Tom Marchant <[email protected]> Subject: Re: TOD conversion to display On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <[email protected]> wrote: >one institution overcame a disadvantage by introducing a wire(!) delay >line to delay its competitor's transactions by a few milliseconds. That would be a really long piece of wire. -- Tom Marchant ------------------------------ Date: Wed, 18 Nov 2015 17:18:26 +0000 From: "Hardee, Chuck" <[email protected]> Subject: Re: TOD conversion to display Or a huge resistor in series with it Charles (Chuck) Hardee Senior Systems Engineer/Database Administration EAS Information Technology Thermo Fisher Scientific 300 Industry Drive | Pittsburgh, PA 15275 Phone +1 (724) 517-2633 | Mobile +1 (412) 877-2809 | FAX: +1 (412) 490-9230 [email protected] | www.thermofisher.com WORLDWIDE CONFIDENTIALITY NOTE: Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee or agent of a system responsible for delivering the message to the intended recipient, is prohibited. If you are not the intended recipient, please inform the sender and delete all copies. -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Tom Marchant Sent: Wednesday, November 18, 2015 12:08 PM To: [email protected] Subject: Re: TOD conversion to display On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <[email protected]> wrote: >one institution overcame a disadvantage by introducing a wire(!) delay >line to delay its competitor's transactions by a few milliseconds. That would be a really long piece of wire. -- Tom Marchant ------------------------------ Date: Wed, 18 Nov 2015 10:44:27 -0700 From: Paul Gilmartin <[email protected]> Subject: Re: TOD conversion to display On 2015-11-18, at 10:08, Tom Marchant wrote: > On Wed, 18 Nov 2015 10:00:21 -0700, Paul Gilmartin <[email protected]> > wrote: > >> one institution overcame a disadvantage by introducing a wire(!) >> delay line to delay its competitor's transactions by a few >> milliseconds. > > That would be a really long piece of wire. > I stand corrected; I checked; it was 350 µsec. That one's prfoit may depend on that edge is ample reason for the OP to desire to shave a few instructions off time display conversion. http://www.bloomberg.com/news/articles/2014-03-30/high-frequency-traders-ripping-off-investors-michael-lewis-says -- gil ------------------------------ End of ASSEMBLER-LIST Digest - 17 Nov 2015 to 18 Nov 2015 (#2015-128) *********************************************************************
