Well the code's all re-entrant (or at least the attached part is). Leaving aside abend management, there's no inter or intra address space synchronization required here - each copy of the code has atomic queues, and they are self serializing (it's that or software polling). All this is is is a management of proliferation issue.
This app isn't particularly complicated, and we're only talking 15M or so messages an hour. All it's doing is a serialized get, put, filter, (maybe) put then back round for another get. Biggest memory requirement is the 16k for the message that we're passing around so should be able to get everything inside a single address space. I guess we're on the right track (at least for this limited subset of track). Now if I only had a better option than a posix queue... Actually if you want a really good laugh - we originally modelled it using MQ. The numbers were ~discouraging~. From: Rob Scott <[email protected]> To: [email protected] Date: 04/08/2011 10:29 AM Subject: Re: Address space proliferation Sent by: IBM Mainframe Assembler List <[email protected]> Agreed. There is also the issue that inter-ASID communication/synchronization/management is much harder to achieve in a reliable and secure fashion than inter-TCB within the same ASID. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected] ] On Behalf Of Blaicher, Chris Sent: 08 April 2011 15:11 To: [email protected] Subject: Re: Address space proliferation Multiple ATTACH's mean one copy of the programs in memory, at least of those routines written reentrant. Multiple address spaces means multiple copies in memory, unless you put the modules in LPA, and all the other overheads associated with an address space. I don't know the memory requirements of the application, but my first inclination is to run as many as you can in an address space and keep the number of address spaces to a minimum. In terms of dispatch processing, I don't think there is a significant difference. Reading that you need a 'couple of hundred' of these does frighten me. It is a question of scalability. Unless these things spend over 99% of the time in a wait, ... My 2 cents. Christopher Y. Blaicher Senior Software Developer Austin Development Lab phone: 512.340.6154 mobile: 512.627.3803 fax: 512.340.6647 10431 Morado Circle Austin, TX 78759 -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected] ] On Behalf Of Leona Baumgart Sent: Friday, April 08, 2011 8:34 AM To: [email protected] Subject: Address space proliferation This probably isn't the best place for this question, but I'll bet someone knows the answer... We have a process written in assembler that's acting as a man in the middle. It pulls messages off a posix queue, puts them on to another one and (optionally) depending on configuration parameters adds them to a third. It's working fine, so don't worry this isn't a USS question... Currently we have a single instance of this thing running. We need to roll it out and our production space will require a couple of hundred instances of this. It's on a somewhat busy TP system, so performance is an issue. The limitations of posix queues (no asynchronous wait) mean that I can't do it in a giant loop - shudder. So to roll this out, I can attachx multiple clones within a single address space or have multiple address spaces each with a single instance. >From a performance perspective my limited understanding is that each of the attached clones will have their own TCB in the list, so the only benefit to having multiple attaches is reduced memory footprint. The inner workings of PR/SM are a mystery to me and I'm speculating wildly at this point. Hence this somewhat wordy preamble. Is there any benefit to one approach over the other? Hopefully this will provide some light relief from the benefits of optimizing compilers, Metal C and LE... TIA, Alan
