Are there any limits to MVS system services available to an assembler subroutine called from a Natural program? For example, it would LOAD programs into memory and save their load point for subsequent use (using name/token), create and access dataspace(s), do I/O to sequential files, invoke a PC to set an MVS RESMGR end of task exit.
Well, Natural doesn’t limit you here, i.e. it doesn’t set up a FLIH / SVC screening or the like,
but as I guess you are aware most of the services you have in mind are authorized, which
isn’t an issue as long as you are running authorized.
Are we talking about plain Natural batch, or some sort of multi user environment ?
Actually I was think of the cases when it would be called from a Natural program in under a transaction manager. The code wouldn’t be authorized, but it would issue user PC’s (instead of user SVCs) to execute authorized services.
When under Com-plete, will I be able to rely on the entry point of my loaded modules staying the same (or does it do load module management like IMS/TM) ? Is there any technique to acquire memory that will last for the life of the transaction or will the calling Natural program have to manage that?
By coincidence I’ve done something along these lines around Natural under COM-PLETE a while ago 
What I’ve done is create a server used for authentication, it’s called via PC from within COM-PLETE,
so yes, that works.
The main question here is the scope of the storage you’d like to acquire, is it local to the session,
or global to the whole environment (read: COM-PLETE address space) ?
Re. “rely on the entry point to stay the same” - look at RESIDENTPAGE programs, they are loaded
into the COM-PLETE address space rather than the thread, and the EP will stay the same, but it’ll
have to be reentrant - any problem with this ?
Thanks, it sounds like this can work.
Most of the storage acquired is for the life of the address-space and would be anchored in the name/token, but some is local to the transaction/session (I assume a session is conceptually the same as a CICS transaction) since the subroutine can be called more than once per transaction and a scratchpad area is more efficient than acquiring storage each time (but there will have to be a mechanism to release it at end of session).
It sounds like RESIDENTPAGE is just what is needed for the programs (yes, all programs are/will be reentrant).
Well, there’s a “transaction” in COM-PLETE as well, there are differences as all transactions
in COM-PLETE are conversational, your application (e.g. Natural) runs in a thread, so any
storage acquired within the thread is there to stay, and you will not even have to release
it explicitly at “end of transaction”.
One thing to watch out, though - you mentioned “IO to sequential files”, remember you are
in a multi-user environment, if this is just to pick up control information at startup that shouldn’t
be a problem, but otherwise you’ll probably hit concurrency issues.