Link to home
Start Free TrialLog in
Avatar of bclogic
bclogic

asked on

DOS application not sharing. Uses XP and 3.12

We have a DOS app that worked fine until upgrading clients to Windows XP.

We are running Netware 3.12.
The DOS app relies on the share file attributes of the files on the server.
When the second user starts the app, he gets an OE error.

Checked all the file share attributes and they are SRW.

Another site using the app runs Netware 5.x and it works.

Any ideas on what's causing the problem?

Stephen Wood
Boston College
Avatar of PsiCop
PsiCop
Flag of United States of America image

OE = Outlook Express ????

What version of the NetWare Client is installed on the XP boxes?

NetWare v3.12 is a good 10 years old, and an IPX-only NOS. Is IPX the only protocol bound to NetWare Client 32 on the XP boxes, or is IP also bound?

Have you turned off client-side caching on the NetWare Client?

Have you considered that NetWare v3.12 is so old that its unsupported and thought about upgrading to at least NetWare v5 (the latest is v6.5)?
Avatar of bclogic
bclogic

ASKER

0E (zero E) is a fairly generic DOS/Windows error that generally is attributed to some software-related issue.  I don't think this is of particular help to us, but I included it anyway.

Our client is whatever gets installed with Windows XP.  (NWlink and IPX)

IP is also installed.  All client machines connect to the main network which is a Windows 2000 network.  The netware server and the DOS application are used by just one department.

I know nothing about turning off client-side caching.  

Should I be installing the netware client, rather than using the one supplied by Windows XP?  I believe the client I could get access to (from the Novell site) is version 4.9.

We are planning on replacing the application in about 6 months to a year, at which time we won't need the Netware server anymore.  If we have to we'll upgrade the server in the meantime, but this is a last resort.  What would be the benefits of upgrading to 5.x in this situation?
ASKER CERTIFIED SOLUTION
Avatar of NwDsk
NwDsk

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
There was a virus recently?

1 out of 5,000 WS' and it wasn't confirmed. In our NOC, we didn't even notice. We blocked at the top, management panicked as their friends and companies dropped off. My management just renewed our contract with Novell.

I wonder why,
ZENworker
The same client has NetWare 5.x at one site and 3.12 at another?

The client needs to get with the program.  3.12 is ancient  - rock solid, but ancient - and has not been a supported platform for several years now.

The analogy in the M$ world would be running NT 3.51 at one site and expecting it to work the same as the other site does running Windows 2000 Server with AD.

My $.02
Avatar of bclogic

ASKER

No, another user we are aware of (totally different company) uses the same DOS application with Netware 5.x...successfully.

We use the DOS application with 3.12.

btw, I'm proceeding with an installation of Novell client v4.9 on two machines, to see if that works.  I'll keep everyone posted as soon as I get some results.  

Thanks for everyone's help so far.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
My analogy still fits.  You are using last year's desktop technology to access technology that was current 10 years ago.  A lot of the issues with running DOS based apps is based in the changes M$ has done over the years.

Another analogy would be to expect a system written for CICS/VS in Cobol 370 on the DOS/VSE OS to function on an OS390 system running CICS4 and the latest version of COBOL.  It MIGHT work, but you're taking a big risk assuming it will.  If you have no Mainframe background, never mind.

Regardless, if your company is invested in a DOS app, run it on a DOS-compatible desktop AND server platform for best results.

It may be dumb luck that this other company can run it on WinXP, or maybe their NetAdmin knows how to work around the issues XP has with running DOS apps over a network.
If the issue is purely a matter of 5.x vs 3.12 on the back end, then, gee, maybe you should get your back-end current.  The latest NetWare is 6.5.  It's ridiculous to invest in the latest desktop technology without considering the age of the infrastructure.  

It would also be ridiculous to take that to mean you should convert your back-end to Windoze.  That would be taking one step sideways and two back.
Avatar of bclogic

ASKER

Well, things are mostly working.

I've installed the 4.9 client, the file share attribute is now being honored, and all the drive mappings are correct except for one.

The F drive is supposed to point to \\server\sys\reserve\system.  
Instead it points to \\system\sys\user\username

I've mapped it via the Novel client and via windows mapping.  I've told it to always map this drive, etc. No matter what, on a restart it reverts to pointing the F drive to the user area.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of bclogic

ASKER

I did, but I've changed it.  The first network drive setting had no effect.

I did solve the problem by turning off 'logon script'  I figured that some network script had to be running.

This worked.

I'm converting all the users (five) on Monday so I should know if this problem is definately resolved then.

Thanks
How did you do that? I assume you were getting nabbed by the default login script. Did you put a "NO_DEFAULT" statement in your login script? Or did you turn it off somewhere else?
Avatar of bclogic

ASKER

You have to dig a little...

Go to:
Network connection, properties, location profiles, default, Properties, Properties, Script, un-check run scripts
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
bclogic -

You should take PsiCop's advice and add the "NO_DEFAULT" statement to the container script.

I forgot all about the default script.  When you do this stuff for a while, you make assumptions...

You don't want to disable the ability to run ANY login script by doing what you said you did.  That limits you severely - you can't map a home directory, execute a program or run a client ACU if you disable login scripts altogether.  

If the problem was that you were getting the default login script, PsiCop's answer is the best one, for many reasons.
Avatar of bclogic

ASKER

Thanks for all the help from everyone.

fyi...I mostly appreciated when someone answered with just the facts.  The commentary about Netware vs Windows didn't find a home with me.  I've seen them come and go( Data General, Prime, Digital, Banyan, CP/M, etc.) so I don't get too hung up on what platform I'm working on.  However, I happen to have benefitted over the years from Microsoft's developer programs (free/low-cost software, training, support for my local user groups, etc.) which they put on the table when others did not.  So, while I understand that they frequently restrict the market and opportunities for smaller computer companies, I don't think they're all bad either.  However, I understand that people get passionate about these things, so no hard feelings.  Mostly I appreciate everyone's interest in helping me to solve this problem.  We solved a problem that others before me could not.
All bad, no.  Somewhat bad - that's a point for debate... Best solution  also open to debate ;)  Can do most of what you need - maybe.  Can do everything well - no.  That's the case for everyone in the industry.

The problem I see with Microsoft is that they want everyone to be all Microsoft all the time.  The idea of "best of breed" solutions is anathema to them.

I am much more comfortable with a multi-vendor solution in which the vendors work together to enhance each others' products, as opposed to the Microsoft model of breaking everything that doesn't directly benefit Microsoft Corp.

If you think that's out of line, that's your opinion, and you're entitled to it.
What I find to be the biggest problem with Micro$oft is that they lie. They lies about their own products:

   - Lie: NT v4 is C2 compliant
   + Truth: Only in a locked room with no NIC

   - Lie: AD is a multi-master replication model
   + Truth: Individual DCs can ignore/overwrite changes to multi-value attribute objects sent by other DCs - its really Master-slave model

   - Lie: AD is an enterprise-quality directory service
   + Truth: Limit of 5000 members in the group, having to reboot a DC to repair the directory, no timesync, no partitioning

   - Lie: Windows is just as stable and secure as NetWare and UNIX
   + Truth: NIMDA, CodeRed, C2MYASS, L0phtcrack and a lot more (what, 32 just this year, right?)

They lie about their competitors products:

   - Lie: NetWare v5 doesn't support RAID/disk mirroring
  + Truth: It was a lie and Redmond knew it and didn't care

And I could go on. My point being, why would you trust your business operations to a company that has largely gotten where it is by lying. Lying to its customers, to its business partners, and about its competitors. Some developer courses thrown your way just means you were bought cheap.
Avatar of bclogic

ASKER

1) I paid for this service because I was seeking technical assistance, not a lecture.

2) I'm a paid consultant hired by my client to help them with technical issues, not strategic decisions.  

3) I haven't been 'bought' by Microsoft.  I merely recognize that they have invested in the relationship when others have not.  That doesn't mean that I sold my soul to the devil.

4) Youve brought up some significant points that I was not aware of.  I'll consider them in the future.  
Stephen,

Sorry if I gave offence. Polemics aside, I think you did get what you paid for.

Your relationship with BC was not clear - yes, if you're a consultant you don't usually have input into strategic decisions.

If some of the information you've gleaned has caused you to re-evaluate products on the market other than those from Redmond, then I'm glad to hear that. If someone fully informed chooses Redmond's wares, so be it; I just don't want to see them triumph because of the FUD and deliberate lies they spread.