Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Arcserve 7 for netware patch
- Thread starter LolaRed
- Start date
Don't forget, when Novell release a 'BETA' patch, CA don't usually take that into consideration.
If, for example, an IT tecchie has applied the beta patch and has had no issues after applying the CA patch, this is why they are recommending it.
The beta NLM's should not cause a problem on a live server, providing Novell say they have received no issues with them. If they do, they release a new version.
Anyway, as any good tecchie knows, any new patches/NLMs should be tested in your companies test environment before rolling to live servers anyway!
If, for example, an IT tecchie has applied the beta patch and has had no issues after applying the CA patch, this is why they are recommending it.
The beta NLM's should not cause a problem on a live server, providing Novell say they have received no issues with them. If they do, they release a new version.
Anyway, as any good tecchie knows, any new patches/NLMs should be tested in your companies test environment before rolling to live servers anyway!
- Thread starter
- #3
Hi TheLad.
I appreciate your response to my post. It was sensible and concise, if not a tiny bit chastising. My post was intended as a short warning. Now, here's my rant.
I can only say that my attitude towards CA lately has become less positive since I upgraded to Arcserve 7 (2-3 months ago) and still fail to get proper and/or timely responses from their tech support (or any responses at all). I'm continuing to experience annoying problems with their product without even slightly helpful suggestions pointing me in some direction to resolve my issues. The best tips I get are from right here on these forums. That's sad, since it's CA who is getting my money.
I've grown wary of their posted patches as well after I applied QO00946 (3 patches back) and could no longer drill down to a specific file for a restore (as if I had turned off Detail - which I hadn't). Needless to say, the patch came off because an accurate restore is more important to me than the ability to modify a job. (Should I really be forced to choose?). Meanwhile, still no response to my requests for support. I've e-mailed them the items they asked for on the phone and sent several follow-up reminders, and they just don't bother to reply back.
Currently, I'm getting backups that can be restored. The Arcserve manager still does not operate well, and Btrieve 7's handling of the AS database still needs some perfecting. Those are annoying, but I'm sticking with what works until CA can come up with some patches that I feel might be a little more reliable.
As for BETA files. I'm tired of being a guinea pig for the vendors. I have too much of my own work to do (which I am being paid for). They can hire someone to Beta test their products instead of expecting me to do it for them for free. Been there, done that. If it's BETA, I'm steering clear of it.
Perhaps I'm just a bad techie but I do feel better now...
Lola, Network Administrator (CNA, MCSE)
I appreciate your response to my post. It was sensible and concise, if not a tiny bit chastising. My post was intended as a short warning. Now, here's my rant.
I can only say that my attitude towards CA lately has become less positive since I upgraded to Arcserve 7 (2-3 months ago) and still fail to get proper and/or timely responses from their tech support (or any responses at all). I'm continuing to experience annoying problems with their product without even slightly helpful suggestions pointing me in some direction to resolve my issues. The best tips I get are from right here on these forums. That's sad, since it's CA who is getting my money.
I've grown wary of their posted patches as well after I applied QO00946 (3 patches back) and could no longer drill down to a specific file for a restore (as if I had turned off Detail - which I hadn't). Needless to say, the patch came off because an accurate restore is more important to me than the ability to modify a job. (Should I really be forced to choose?). Meanwhile, still no response to my requests for support. I've e-mailed them the items they asked for on the phone and sent several follow-up reminders, and they just don't bother to reply back.
Currently, I'm getting backups that can be restored. The Arcserve manager still does not operate well, and Btrieve 7's handling of the AS database still needs some perfecting. Those are annoying, but I'm sticking with what works until CA can come up with some patches that I feel might be a little more reliable.
As for BETA files. I'm tired of being a guinea pig for the vendors. I have too much of my own work to do (which I am being paid for). They can hire someone to Beta test their products instead of expecting me to do it for them for free. Been there, done that. If it's BETA, I'm steering clear of it.
Perhaps I'm just a bad techie but I do feel better now...
Lola, Network Administrator (CNA, MCSE)
No, I agree. Us loyal customers to Arcserve have had it all before with Arcserve 6.1 and the variations of 6.6 also.
Just a quick one, are your NW servers fully patched (latest SP, latest firmware etc...) as this can often help.
At my company, it took us 3 weeks to get Arcserve stable. In the end, we applied NW5.1 SP3, updated both LAN drivers and SCSI drivers from the vendors website, also did firmware on server and SCSi card, applied all of the CA patches, and we sort of have a stable system right now.
The only problem we have is that servers without replicas on drop the Arcserve queue from time to time. This requires a stop and start of Arcserve. If you get this problem, DO BE CAREFUL as stopping Arcserve using ASTOP can often abend the server. I manually deactivate and unload the scheduler, wait, manually unload the TAPESVR, wait for it to completely unload, then perform an ASTOP. Works for me.
If you have issues, post them here. You're bound to get a better response than from CA
Cheers
Just a quick one, are your NW servers fully patched (latest SP, latest firmware etc...) as this can often help.
At my company, it took us 3 weeks to get Arcserve stable. In the end, we applied NW5.1 SP3, updated both LAN drivers and SCSI drivers from the vendors website, also did firmware on server and SCSi card, applied all of the CA patches, and we sort of have a stable system right now.
The only problem we have is that servers without replicas on drop the Arcserve queue from time to time. This requires a stop and start of Arcserve. If you get this problem, DO BE CAREFUL as stopping Arcserve using ASTOP can often abend the server. I manually deactivate and unload the scheduler, wait, manually unload the TAPESVR, wait for it to completely unload, then perform an ASTOP. Works for me.
If you have issues, post them here. You're bound to get a better response than from CA
Cheers
- Thread starter
- #5
I used ArcServe 6.1 for 3 years before upgrading to version 7. There were issues with 6.1, but none were as long and tedious as this upgrade to 7 (and it ain't over yet). So you see, I also am a so-called loyal CA customer. I haven't switched to Backup Exec only because I don't think it's menu system is as extensive & user friendly as AS. I may change my mind soon.
I'm totally patched up with Netware (actually using 4.11 - planning to upgrade to 5.1 - thought upgrading Arcserve first would be prudent...). So I will probably go through a whole new set of issues with CA when the Netware upgrade occurs. I had no idea at the time that version 7 was so bug-ridden. My servers all replicate and I've never experienced the abend from executing ASTOP (knock on wood).
I am getting a new thing on my server console. At the server prompt (and in the console.log file) I've recently been noticing stuff like this:
coutn_1[2]
coutn_1[3]
coutn_1[4]
coutn_1[5]
coutn_1[6]
coutn_1[7]
coutn_1[8]
coutn_1[9]
coutn_1[10]
coutn_1[11]
coutn_1[12]
coutn_1[13]
coutn_1[14]
coutn_1[2]
coutn_1[3]
coutn_1[4]
Can't figure out where it's coming from. I don't know if the AS upgrade has caused it or not. I've been searching sites all over the Internet. So far, no hits.
How about you?
I'm totally patched up with Netware (actually using 4.11 - planning to upgrade to 5.1 - thought upgrading Arcserve first would be prudent...). So I will probably go through a whole new set of issues with CA when the Netware upgrade occurs. I had no idea at the time that version 7 was so bug-ridden. My servers all replicate and I've never experienced the abend from executing ASTOP (knock on wood).
I am getting a new thing on my server console. At the server prompt (and in the console.log file) I've recently been noticing stuff like this:
coutn_1[2]
coutn_1[3]
coutn_1[4]
coutn_1[5]
coutn_1[6]
coutn_1[7]
coutn_1[8]
coutn_1[9]
coutn_1[10]
coutn_1[11]
coutn_1[12]
coutn_1[13]
coutn_1[14]
coutn_1[2]
coutn_1[3]
coutn_1[4]
Can't figure out where it's coming from. I don't know if the AS upgrade has caused it or not. I've been searching sites all over the Internet. So far, no hits.
How about you?
- Thread starter
- #6
Well here I am, replying to my own thread. I found my answer to the coutn_1[xxx] countdown that occurs on my server console & log. It seems that Arcserve 7 (natch) is sending these random? posts to the server console whenever you browse through the AS database or use the Restore function. Imagine that.
Lola,
Yep, experiencing all the same sorts of problems NW5.1, ArcServe 6.1 upgrading to 7.0. We have about 150 backup servers and this is a real nightmare at the moment.
We have lots of problems with NDS and it is making me wonder why they didn't move over to the NT model of keeping the info in a file accessible by BTREIVE on the backup server itself. They can then use bindery or NDS to authenticate and manage the server. The BU server itself only needs to talk TCP/IP directly to the push agents. The phrase "over engineered" springs to mind. Keeping the old "print queue->print server" model is silly - its well outdated and causes huge problems as our NDS is UK-wide.
The trace screen (portal?) on the console looks like some programmers "debugging" code that he forgot to comment out. Its all written in C (I do a bit of C programming) and it all looks pretty much like the kind of balls-up I'd make!.
Our servers are having real problems talking to their Qs as they are preferring to talk to partitions/replicas that talk IP rather than local ones that talk IPX. This means that servers last about a week (on average) before they die. Having said that - there are quite a few that are okay. This problem is quoted to be "with Novell" at the moment so we await replies.
Push Agents seem to abend servers regularly. Either running or on unloading. Jobs get corrupted. It seems very sensitive to the version of the NW client the ASMGR is running on. 4.8 recommended (I use 4.71 but lots of wierd problems in Explorer etc.).
If there is anything that we may be able to contribute then please let me know. We are really "clutching at straws" with many problems.
Mark
Yep, experiencing all the same sorts of problems NW5.1, ArcServe 6.1 upgrading to 7.0. We have about 150 backup servers and this is a real nightmare at the moment.
We have lots of problems with NDS and it is making me wonder why they didn't move over to the NT model of keeping the info in a file accessible by BTREIVE on the backup server itself. They can then use bindery or NDS to authenticate and manage the server. The BU server itself only needs to talk TCP/IP directly to the push agents. The phrase "over engineered" springs to mind. Keeping the old "print queue->print server" model is silly - its well outdated and causes huge problems as our NDS is UK-wide.
The trace screen (portal?) on the console looks like some programmers "debugging" code that he forgot to comment out. Its all written in C (I do a bit of C programming) and it all looks pretty much like the kind of balls-up I'd make!.
Our servers are having real problems talking to their Qs as they are preferring to talk to partitions/replicas that talk IP rather than local ones that talk IPX. This means that servers last about a week (on average) before they die. Having said that - there are quite a few that are okay. This problem is quoted to be "with Novell" at the moment so we await replies.
Push Agents seem to abend servers regularly. Either running or on unloading. Jobs get corrupted. It seems very sensitive to the version of the NW client the ASMGR is running on. 4.8 recommended (I use 4.71 but lots of wierd problems in Explorer etc.).
If there is anything that we may be able to contribute then please let me know. We are really "clutching at straws" with many problems.
Mark
Dear All,
The coutn_1[x] is a cosmetic debug trace that (I guess) the programmer forgot (?) to take out of the final release code. It is traced in a separate console window.
It happens when you try to do a restore using a browse by session.
You will probably notice that the nubmber count seems to correspond with the directory tree count in the current level.
I believe that CA are addressing this but "can't comment" further.
Regards
Mark
The coutn_1[x] is a cosmetic debug trace that (I guess) the programmer forgot (?) to take out of the final release code. It is traced in a separate console window.
It happens when you try to do a restore using a browse by session.
You will probably notice that the nubmber count seems to correspond with the directory tree count in the current level.
I believe that CA are addressing this but "can't comment" further.
Regards
Mark
- Status
Similar threads
- Locked
- Question
- Locked
- Question