ich have an Natural Service which takes about 4-5 Minutes to answer if i start it without using EntireX. I set up the TIMEOUT to enough time at SYSRPC / PM. The summary size of the Parameters are about 7kb. If i start the Service over EntireX i got an NAT6971 Level 3 after 60 Seconds. (Conversation Time Out)
The Service it self don’t make Problems with other Parameters so i could say that the whole Configuration is set up to work.
Does someone have a Tip which Configuration Parameter i have to change?
The Service is a Naturalprogram that starts an Cobol call. Service runs on Nat4.1.4@BS2000. We tried to set up service-nonact to 4M but if i look to Broker Control Center the change didn’t affect.
With an Natural Client i get NAT6971 Level 3. (Client is an other TIAM-Task without Steplib to the Serverprocess.) I also tried it out from the EntireX Workbench by “Generate and Run Test” but there i got an 0074 0074.
I think i’ll write an Javaclient myself and setup Clienttimeout to a higher value.
Without EntireX means that i write a Program at the same Naturalib where the Service is so Naturalclient finds the Programm at the same lib and don’t try it via RPC-Call.
I don’t have the BS2000 documentaion : For other platforms, you need to change the CLIENT-NONACT, CONV-NONACT and SERVER-NONACT parameters in the ETBATTR member.
We are on BROKER 7.2.1 on Z/OS, and the SERVICE-UPDATES = YES did not work when we tried it. We tried to change NUM-CLIENT, and were forced to restart BROKER to implement the change.
Thank you Michael we had played around with these Parameters without affect. But then our Systemadministrator one day changed anything i don’t know at the Broker Configuration and at the other day the made changes to SERVICE-NONACT would do all what i want. Seems like a Wizzard cast a Spell and BS2000 make all i want
In general, when SERVICE-UPDATES=YES, if Broker has read the attributes for a service already, it does not re-read the attribute file for that service. If it encounters a service request that it did not find in its previous read of the attribute file, it then re-reads the attribute file.
So, a trick that works often (sorry…not 100%): modify the attribute file, bring down all servers using the service. Then use SYSRPC SM to define a non-existant server on that Broker and use XC to PIng it. This should return a “service not active” or “attr - service not defined error” - which is ok, since it forced the Broker to re-read the attribute file. Restart your server - it should have the new values set. (If you use the * notation (eg CLASS=RPC,SERVER=*,SERVICE=CALLNAT), you may need to use something else other than RPC (eg a dummy ACI call) to force the re-read).
If not, you will indeed need to restart the Broker to have the new attributes take effect.
We had a new service defined, which we had not actually used yet (code not in production at this point). Writing a Q&D to register a program as that service didn’t cause the NUM-CLIENT value to change in BROKER. I tried de-registering one of the in-use services, which caused the servers to re-register and once again nothing changed. In the end, we bounced Broker.
Broker re-reads the attribute file only to find definitions of new services. If you want to change a parameter like NUM-CLIENT which is service independent you have to bounce Broker.
Hmmm… perhaps the doc should be updated to say something other than “This allows the Broker to honor modifications in the attribute file without a restart”.
