Showing results for 
Search instead for 
Did you mean: 

Java console in multi-admin environment


When we are making a change on the backup system (usually daily), we tend to ask all other admins/operators to restart their Java console so that they have the changed information/data loaded on the console and no one has stale data. This was from experience when someone changed a policy and the change didn't take effect because consoles were not restarted (change was visible on the console on which it was performed but never made it to the database).

My question is:

1. Have you experienced this in your environment?

2. How do you manage several people using the console at the same time?

3. I use bpps and then parse it out* to find bpjava-susvc processes to see who has the console open. Do you have a better way?

It is a one liner - I can paste it here if others wants to use it.


Level 4

If I understand correctly you are talking about chance in job policy?If so please try to click on the refresh button on top of job policy after making the change for making the policy changes effective.There will be a green refresh signature.


Arkya, I know about the green refresh button and often use it when changing anything under policies. However, the refresh is only on my console and not on other consoles which are open. I have experienced this myself: when I made a change in a policy and refreshed the console pane to confirm the change - but the job never started after that because another console was open and was never refreshed/reopened after I made the change.

Partner    VIP   

That issues was know in NBU 6.5, especially when using the Windows Admin GUI. Same issue could take place using the Jva GUI but much less frequent. 

In NBU 7.5/7.6/7.7 is doesn't look to be a issue. A locking system has been implemented.



The policies are re-read only about every 10 minutes.

If you make changes to a policy and you want them to take effect immediately run "nbpemreq -updatepolicies"

There is another one "bprdreq -rereadconfig" for NB changes.

have these aliased for my admin user:

rereadnb='bprdreq -rereadconfig '
rereadpolicy='nbpemreq -updatepolicies'


You should get everyone in the habit of refreshing before editing, since if policies have had changes made, the locking "feature" will force you to abandon any changes until you refresh first...


NetBackup on Solaris 11, writing to Data Domain 9800
duplicating via SLP to LTO5<O8 in SL8500 via ACSLS

"Too many cooks" 


Just one admin at a time, please.  Man Happy