Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

Here are all the documented and undocumented 'Dirty' parameters I know of. These go in the DIAGxx member of SYS1.PARMLIB. These are NOT recommended for production or even development environments. Try them on a TEST LPAR to shake out any problem areas. Traps Name(IeaCmSetV, /* Ensure

Re: Change in GETMAIN behavior

Wow, that didn't format correctly the first time. Hopefully this time is better. Here are all the documented and undocumented 'Dirty' parameters I know of. These go in the DIAGxx member of SYS1.PARMLIB. These are NOT recommended for production or even development environments. Try them on

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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

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: Change in GETMAIN behavior

Change in GETMAIN behavior

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

Re: Change in GETMAIN behavior

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