Re: Service Programs / Binding Directories / *DUPPROC

... there are sometimes situations, binding by copy is the best solution!
- in an application like ArdGate you can’t controll the libl and you could need multiple installations working selfcontained in it’s install library. So I’m binding the module to load SRVPGMs out of a lib known only at runtime by copy.
- embedded SQL is another example! The precompiler is putting all its variables global so all programms in the same actgrp using a data access SRVPGM would share the same cursor!
- writing an OA handler to enhance RLA by the usage of embbedded SQL you would end up by binding the handler module by copy.

@ daves problem: first look I would have: is it possible to move static storage (global)to automatic storage (procedure local). Second look would be more difficult: move static storage to dynamic storage allocation, opening the possibility to free memory, if no longer needed, reallocate back if needed.
D*B

<Jon>
IBM may well have suggested that - but the proposed approach won't help.

It has always been one of the strengths of the S/38 - AS/400 - IBM i architectures that there is only ever one copy of program in memory.

This is one reason why I think it is a bad idea to copy modules into programs rather than use a service program - if you copy the module into two programs you have 2 x the memory footprint of that module.

Storage defined by the module is always per job. So if you had a program that used (say) 5Gb of instructions and defined variables that occupied 1Mb then running 50 concurrent instances would use 5Gb + 50Mb.

The approach you mentioned would have some effect, but only because temp storage in the job for a file buffer etc. would only be allocated when needed and delaying the SP load would achieve that. But frankly the architecture needs changing - this approach is not likely to offer real long-term relief and will be quite a lot of work.


Jon Paris
</Jon>