t: 25 November 2015 01:19
>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU<mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU>
>Subject: Re: Change in GETMAIN behavior
>
>I asked that SDSF be changed so the scroll field dynamically move to the right
>side of the screen based on the current screen width,
Regarding requirements:
As with any requirement, it needs to be evaluated both for technical
validity (the ones mentioned in this thread seem valid) and also for their
likelihood of bubbling to the top of a prioritized list given limited
resources. Surely this is the case for every company. A r
19
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Change in GETMAIN behavior
I asked that SDSF be changed so the scroll field dynamically move to the
right side of the screen based on the current screen width, which would have
given more room for stacked commands but that was also shot down.
I have a 142 c
Just another of life's minor annoyances!
Robert Ngan
CSC Financial Services Group
IBM Mainframe Assembler List wrote on
2015/11/24 21:31:16:
> From: David de Jongh
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 2015/11/24 21:32
> Subject: Re: Change in GETMAIN behavior
> Se
Jongh
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Robert Ngan
Sent: Tuesday, November 24, 2015 6:19 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Change in GETMAIN behavior
I asked that SDSF be changed so the scroll
Ngan
CSC Financial Services Group
IBM Mainframe Assembler List wrote on
2015/11/24 07:02:07:
> From: Elardus Engelbrecht
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Date: 2015/11/24 07:24
> Subject: Re: Change in GETMAIN behavior
> Sent by: IBM Mainframe Assembler List
>
> Tom Marc
Tom Marchant wrote:
>Paul Gilmartin wrote:
>>As a more applications-oriented programmer than systems-oriented, I find this
>>strengthens my wish for an IGVINITGETMAIN-like facility with ASID scope ...
>Did you submit a requirement?
For a 'one person, unfunded, spare time project'? Paul, you ma
On Mon, 23 Nov 2015 07:48:20 -0700, Paul Gilmartin wrote:
>As a more applications-oriented programmer than systems-oriented, I
>find this strengthens my wish for an IGVINITGETMAIN-like facility
>with ASID scope ...
Did you submit a requirement?
--
Tom Marchant
On 2015-11-23, at 03:40, Elardus Engelbrecht wrote:
> Jim Mulder wrote:
>
>> IGVINITGETMAIN is the TRAP name. It was designed and implemented as a one
>> person, unfunded, spare time project, by me, to meet some my needs for
>> testing purposes.
>
> Wow! That is a worthwhile achievement! You
Jim Mulder wrote:
> As the designer and implementer of the z/OS 1.10 change,
I, a novice Assembler programmer, will never argue with you. ;-)
> IGVINITGETMAIN is the TRAP name. It was designed and implemented as a one
> person, unfunded, spare time project, by me, to meet some my needs for
> > APAR OA27291 describes the change in GETMAIN that was introduced in
> > z/OS 2.1. It results in better performance of GETMAIN. A side
> effect is that is
> > that there is somewhat more chance that a request will be satisfied
from a
> > location that had been previously obtained and then f
Blaicher, Christopher Y. wrote:
>Wow, that didn't format correctly the first time.
Both your mails were formatted properly (Wow!) on the ASSEMBLER-L website.
>Here are all the documented and undocumented 'Dirty' parameters I know of.
>These go in the DIAGxx member of SYS1.PARMLIB.
>These ar
er 19, 2015 1:15 PM
To: MVS List Server 2
Subject: Re: Change in GETMAIN behavior
On 2015-11-19, at 11:03, Elardus Engelbrecht wrote:
Why does the option for "dirty" GETMAIN (I forget the correct name) remain
undocumented, despite its value for testing?
-- gil
: 512-627-3803
E: cblaic...@syncsort.com
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Paul Gilmartin
Sent: Thursday, November 19, 2015 1:15 PM
To: MVS List Server 2
Subject: Re: Change in GETMAIN behavior
On 2015-11-19, at
On 2015-11-19, at 11:03, Elardus Engelbrecht wrote:
> Tony Harminc wrote:
>
>> One slighly related point: It has been the case from day 1 of MVS (OS/VS2
>> R2) that even though GETMAIN can give out non-zeroed storage, that storage
>> will never contain data left over from another address space,
Tony Harminc wrote:
>One slighly related point: It has been the case from day 1 of MVS (OS/VS2 R2)
>that even though GETMAIN can give out non-zeroed storage, that storage will
>never contain data left over from another address space, or from a fetch
>protected subpool in the current or common s
On 19 November 2015 at 10:14, Gary Weinhold wrote:
> But you have a valid concern about vendors' assembler code. We should be
> asked whether we know about this.
When these changes were first brought up by IBM quite a few years ago
now, every even marginally competent ISV reviewed its use of GET
On Thu, 19 Nov 2015 14:52:33 +, Leonard.John.J wrote:
>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 descripti
So, if you were not aware, there is a CICS list that might help with your
question on CICS Getmains.
To join, if you have not done so, use this URL
CICShttp://www.listserv.uga.edu/archives/cics-l.html
Lizette
> -Original Message-
> From: IBM Mainframe Assembler List [mailto:ASSEMBL
On Thu, Nov 19, 2015 at 8:52 AM, Leonard.John.J <
johnleon...@westfieldgrp.com> wrote:
> 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
Walt, I think there was a change to GETMAIN behavior, but it's rather
subtle (low-end vs. high-end page-filling), and this part was merely to
reassure everyone that from a program's point-of-view, nothing was really
any different.
The key words are "remain unchanged". The behavior (which is the s
I would think it's up to CICS to initialize CICS acquired memory on your
behalf.
And if your applications (vendor or otherwise) run under LE, then LE
controls whether it will initialize the storage based on options you set.
But you have a valid concern about vendors' assembler code. We sho
On Thu, 19 Nov 2015 14:52:33 +, Leonard.John.J
wrote:
>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
23 matches
Mail list logo
