Re: performance of dynamic memory allocation in linkage section

2010-07-30 Thread Jan MOEYERSONS
On Thu, 29 Jul 2010 09:44:59 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: Unless things have drastically changed, COBOL calls by address. Well... Things have changed... Nowadays, one can specify the way the arguments are to be passed in the CALL statement. The USING clause accepts

Re: performance of dynamic memory allocation in linkage section

2010-07-30 Thread William M Klein
Just to respond to Unless things have drastically changed, COBOL calls by address. No matter how big your linkage section is, COBOL does not allocate storage for it. COBOL has supported passing BY CONTENT (not BY REFERENCE) since about 1997 and BY VALUE for a decade and a half or so.

performance of dynamic memory allocation in linkage section

2010-07-29 Thread Amlan Prasad
We are developing a big batch COBOL program which uses lot of storage. There are many arrays which are loaded from DB2 tables. The number of occurrences for all these arrays which vary from run to run. Hence we thought instead of using working storage section for these arrays, we will use

Re: performance of dynamic memory allocation in linkage section

2010-07-29 Thread Binyamin Dissen
On Thu, 29 Jul 2010 01:02:28 -0500 Amlan Prasad amlan...@msn.com wrote: :We are developing a big batch COBOL program which uses lot of :storage. There are many arrays which are loaded from DB2 tables. The :number of occurrences for all these arrays which vary from run to run. :Hence we thought

Re: performance of dynamic memory allocation in linkage section

2010-07-29 Thread Hal Merritt
@bama.ua.edu Subject: performance of dynamic memory allocation in linkage section We are developing a big batch COBOL program which uses lot of storage. ..snip NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which

Re: performance of dynamic memory allocation in linkage section

2010-07-29 Thread Mohammad Khan
Unless you have to output all this data e.g. write it to a file, print it to a report etc. DO NOT move all this data to the program. The cross memory move from DBM1 to program address space can be prohibitive and that's not even accounting for the processing cost. If there is something to be

Re: Tracing above the bar memory allocation/deallocation

2010-03-25 Thread Dave Day
SNIP Does anyone know of a facility similar to GFS trace for tracing above the bar memory allocation/deallocation? I have a program that analyzes GFS trace output which makes short work of diagnosing memory leaks. It also reports storage usage by TCB and subpool. But I would like to be able

Tracing above the bar memory allocation/deallocation

2010-03-24 Thread Maxfield, John
Does anyone know of a facility similar to GFS trace for tracing above the bar memory allocation/deallocation? I have a program that analyzes GFS trace output which makes short work of diagnosing memory leaks. It also reports storage usage by TCB and subpool. But I would like to be able

Re: Memory allocation

2009-06-24 Thread carlos roberto visconde
Try modset key=0. 2009/6/23 Zahir Hemini zhem...@gmail.com Use Matrix from Exspans. On Thu, Jun 18, 2009 at 2:31 PM, Ward, Mike S mw...@ssfcu.org wrote: Hello all, I have written an mq security exit for z/os in assembler that works pretty well. What I would like to add is the capability

Re: Memory allocation

2009-06-23 Thread Zahir Hemini
Use Matrix from Exspans. On Thu, Jun 18, 2009 at 2:31 PM, Ward, Mike S mw...@ssfcu.org wrote: Hello all, I have written an mq security exit for z/os in assembler that works pretty well. What I would like to add is the capability to use persistent memory. I tried to allocate memory from

Memory allocation

2009-06-18 Thread Ward, Mike S
Hello all, I have written an mq security exit for z/os in assembler that works pretty well. What I would like to add is the capability to use persistent memory. I tried to allocate memory from SUBPool 131 and 132. I received a not authorized error. I have my module in an authorized loadlib and

Re: Memory allocation

2009-06-18 Thread esst...@juno.com
Mike As far as I remember MQ Security exits Do Not Run Authorized... Workers Compensation Legal Advice. Click here http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTOcqEaNBlz2GfLWbA9bVnWUZWK7CpLgX0CouRb16GWvPQpxaqyCBq/

Re: C/C++ malloc() memory allocation

2008-06-27 Thread Betsy Jeffery
I see, the LE manual I read it in was lying. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at

Re: C/C++ malloc() memory allocation

2008-06-27 Thread Craddock, Chris
Betsy Jeffery said I see, the LE manual I read it in was lying. [CLC] if you saw it in an LE manual, then yep. LE has always been a problem state, non-authorized application. LE will never ask for anything other than low private subpools, i.e. task-owned, fetch protected storage in the task's

C/C++ malloc() memory allocation

2008-06-27 Thread Bill Klein
I just did a search of the LE 2.10 bookshelf at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/CEE1BK32 for malloc csa or malloc ecsa and found no hits. Betsy, Can you point me to the (LE) manual that you think said this? (I also searched the current V1.9 manuals

C/C++ malloc() memory allocation

2008-06-26 Thread Betsy Jeffery
Back in the OS390 2.10 days the malloc() command/function used to allocate the storage requested in CSA/ECSA. Does anyone know if this is still true under z/OS 1.7? TIA -- For IBM-MAIN subscribe / signoff / archive access

Re: C/C++ malloc() memory allocation

2008-06-26 Thread Wayne Driscoll
are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Betsy Jeffery Sent: Thursday, June 26, 2008 8:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: C/C++ malloc() memory allocation Back in the OS390 2.10 days the malloc() command

Re: C/C++ malloc() memory allocation

2008-06-26 Thread Miklos Szigetvari
Hi Never seen in CSA or ECSA currently in subpool 2 key 8 . Betsy Jeffery wrote: Back in the OS390 2.10 days the malloc() command/function used to allocate the storage requested in CSA/ECSA. Does anyone know if this is still true under z/OS 1.7? TIA

Re: C/C++ malloc() memory allocation

2008-06-26 Thread Craddock, Chris
Back in the OS390 2.10 days the malloc() command/function used to allocate the storage requested in CSA/ECSA. Does anyone know if this is still true under z/OS 1.7? [CLC] Eh? I don't believe that was ever true. CC -- For

Re: C/C++ malloc() memory allocation

2008-06-26 Thread Roland Schiradin
AFAIR LE use subpool 2 key 8. However it's possible to allocate CSA/ECSA while running in key8. Since z/OS R8 or R9 you can deny such kind of allocations. Before it was an undocumented option. Roland I don't recall this ever happening. In order to allocate storage out of CSA/ECSA the program

Re: C/C++ malloc() memory allocation

2008-06-26 Thread Wayne Driscoll
: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Roland Schiradin Sent: Thursday, June 26, 2008 3:17 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: C/C++ malloc() memory allocation AFAIR LE use subpool 2 key 8. However it's possible to allocate CSA/ECSA while running in key8. Since z

Memory Allocation for JAVA under USS

2007-02-27 Thread Betsy Jeffery
I've got a developer just starting to use JAVA 1.4 under USS (z/OS 1.4 soon to be z/OS 1.7). I'm wondering what people are using as a general rule for TSO initial region size for JAVA developers. I don't like the idea of 256M per session - which is what I had to give this guy just to get

Re: Memory Allocation for JAVA under USS

2007-02-27 Thread Bob Shannon
Unfortunately 256Mb for Java may be low. Configure real storage and aux appropriately and live with the new order. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to

Re: Memory Allocation for JAVA under USS

2007-02-27 Thread Big Iron
You can use the getrlimit service to increase the region limit up to the hard limit, which IIRC is set from BPXPRM00 or the user profile. There is an example of invoking this from REXX at http://members.tripod.com/billlalonde/rexx/setrlim.txt So you would invoke that with setrlim rlimit_as

Re: Memory Allocation for JAVA under USS

2007-02-27 Thread McKown, John
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Betsy Jeffery Sent: Tuesday, February 27, 2007 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Memory Allocation for JAVA under USS I've got a developer just starting to use JAVA 1.4 under

Re: Memory Allocation for JAVA under USS

2007-02-27 Thread Hal Merritt
luck. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Betsy Jeffery Sent: Tuesday, February 27, 2007 9:12 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Memory Allocation for JAVA under USS I've got a developer just starting to use JAVA 1.4 under USS (z

Re: Memory Allocation for JAVA under USS

2007-02-27 Thread Chase, John
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Betsy Jeffery I've got a developer just starting to use JAVA 1.4 under USS (z/OS 1.4 soon to be z/OS 1.7). I'm wondering what people are using as a general rule for TSO initial region size for JAVA developers.