7.3.1 reliability?

Different ppl - different opinions. For enterprise level environment I would suggest to wait until 7.3.2 has been released and probed (or tested yourself). At customer site I'm currently in we will wait for 7.3.2 and forthcoming AlphaStor release to make major upgrade of existing environment (one site 7.1.x based and second one 7.2.x based). Also, by the time of that release a client for OpenVMS should be released supporting 7.3.x based servers.

I'm very clear to what we need and why, what to expect from 7.3.1 and 7.3.2 and make this decision. You should get yourself familar with 7.3.x before upgrade as things are different - from both sides of the hood.

09/05/06 20:57:00 savegrp: RPC error: Request failed
09/05/06 20:57:56 savegrp: RPC error: Connection lost with server

We are plagued with these types of errors on 7.3.1. I have a similar enviornment to yours, about 5tb of data to back up. Seems maybe once a week I have a nsrjobd.exe crash in x86 land. I am told to hang in tight for 7.3.2, but I heard the same thing about 7.3.1.

I upgraded because I needed a rpm that wasn't released for 7.2.x. Whoops.

exe is on Windows and rpm is on Linux - why simply not going with 7.3.1 on client and keep the old things with 7.2.2? Why not request a port? Nevertheless, it's too late now. I saw fix list for 7.3.2 and indeed it is impressive (if everything will get to GA release). I'm not sure if your error is caused by 7.3.1 so I would be careful here. If support told you that this problem is caused by 7.3.1 then ask them for LGTpa associated to that problem. If they don't have it - you are being framed I mean, if you have problem that is bug A then there must be id for that bug. Otherwise how do you know 7.3.2 is fixing it?

OK, that probably doens't make you feel better. Now, the error listed could be caused by software, but it could be also a network problem and usually it is. I would suggest you run some parallel tests to make sure nothing is wrong with RPC connection.

I have had all sorts of issues earlier this year but things are getting much better and more stable. I have some customers who have 7.2.2 and we are waiting until 7.3.2 is out and I can validate it for them.

I would read the release notes for 7.3.2 and do some prelim testing on your end. The major issues I had ealier this year are 95% gone though.

Yes, I had a hotfix on 7.3.1 that seemed to fix *most* of the RPC problems. They are investigating remaining RPC issues that are much less frequent. 7.3.2 is definitely much more stable for us with the inclusion of this hotfix.

I suspect installing 7.3.2 client on everything might smooth everything over too.

Anyhow, it was a known 7.3.1 bug plaguing us so I feel relatively safe with my earlier warning. I won't speak to 7.3.2 until I have it tested and if I have problems I'll wait for legato to confirm before giving my opinion on the stability of the product.

However, if somebody asks for the opinion of the stability, should we not give it to them? Perhaps I'll just add a disclaimer indicating the problem has not been resolved as a legato issue or a local environment issue...

Hi Stephen,

You didn't say your problem has been recognized by support and you were given patch. That does change things a bit, right? What was the LGTpa for your problem?

Hello,

We had a lot of issues and pain with 7.3.0.
With 7.3.1, near all problems have been fixed, excepted a major issue :

We have an open case since May, about nsrjobd crashes on windows.
When the crash happens, all running backups are aborted.
Nsrjobd crashes randomly with a frequency between one and five times a month.
The problem was in 7.3.0, and still here in 7.3.1.

I am disappointed because the emc support is very bad and doesn't want/be able to investigate seriously and quickly the problem.
Once month ago, support provided us a patch LGTpa89845, but it didn't fix the problem.
Now, after 3 months, support ask us to install debugging symbols on our networker server !

Keep your 7.2, and definitively flee 7.3 !

Well, it might be specific issue to your environment or even platform - ever thought of that? If specific I'm afraid that even 7.3.2 might not help you and only way to do analysis and see what is going on to use debugging. 7.2, as all intial versions, should only be used in case you desperetaelly need new funtionality - otherwise wait for next patch release (or use latest one; same rule applies to OS, actually any kind of software for decades).

Some other customers are still affected. Support has already released 2 patches about this issue :

LGTpa90756
LGTpa89845

I'm not alone in this thread to talk about nsrjobd x86 crashes.

So it is Wintel specific then (and further could be CPU specific or application specific). LGTpa89845 has been fixed by 7.3.2 meaning your issue is a bit different if you tried 7.3.2 or fix for it (having same symptoms is what led support believe 89845 should fix it for you). I hope with debugging binaries this is resolved for you.

Do you have Windows 2k or Windows 2003? Do you know if both OSes are affected? If you shut down all services not necessary for machine to be up and running (including any 3rd party applications), do you see the same issue? These and several other questions should lead to resolution, but with debugging engineering should get that too.

We are in the same position and need the enhancements. We upgraded to 7.3.2 and it was quite literally unusable. We had to revert back to 7.2.2. I won't be loading 7.3.anything for quite awhile. Your milage may very

Hi Kevin,

Perhaps it would be interesting to hear what issues you had and what was the response from support on this issues?

I wonder if keeping very small or very big retention for nsrjobd would change a thing.

Hello,

Just to say that the bug is always here in 7.3.2.
Support says that others wintel customer are affected and doesn't provide a definitive fix.
Apparently, Dr Watson appends randomly when nsrjobd purges automatically jobsdb.
We suffer from this bug since 7.3.0, call open since May and support doesn't succeed to fix this issue until now.