I just upgraded from NAT427 to NAT823 (z/OS). New v82 GBP is working fine for everything EXCEPT our Natural RPC Servers – they can’t find the GBP. Very strange…
Natural error NAT1074 occurred during Natural initialization. Substitutions for
placeholders in message text for NAT1074: NATURAL,NATBPN1
NAT9990 Natural initialization failed.
We took out the BPNAME=NATBPN1 and they come up normally – but we want to use the GBP. The 1074 error explicitly says: “If the buffer pool could not be found because the Natural subsystem does not exist, the name of the Natural subsystem is appended to the name of the global buffer pool, separated by a slash (/).”
The subsystem name is ‘NATL’, and it does exist, so I assume Natural is picking up the name from the NATBATCH natparms and verifying that the SUBSID exists, otherwise ‘/NATL’ would be in the error message. Anyone have any thoughts about this?
Is there a SUBSID=NATL in your RPC server NATPARMs ?
You can try adding a bogus SUBSID to your CMPRMIN and see if the message changes.
Wolfgang, SUBSID=NATL is in all of our NATPARM modules for batch (NATBATCH), TSO (NATTSO) and CICS front-ends; NATBATCH is the front end being executed by the RPC Server tasks. NATURAL sessions under TSO and CICS connect to the NATBPN1 buffer pool using the SUBSID – can’t figure out why NATBATCH can’t. I will try adding the SUBSID parm to CMPRMIN to see if anything changes.
Adding the SUBSID parm to the input parms to the batch RPC server did fix this issue. I’d still like to know why, though, since the SUBSID parm is included in the NATPARMs for the NATURAL batch front end. Thanks for the suggestion.
pure speculation, but any chance SUBSID has been added to your NATPARM
but it never actually got assembled / linked to the frontend as you assume ?
Browse the load module and you should see it there (or not).