× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Peter

I have a couple of suggestions that you might like to try.

The fact that you have at least one user which doesn't have an AS/400
profile is interesting as this implies to me that a guest profile has been
created. Since access to the shares behaves slightly differently based on a
combination of the client OS and whether the Windows profile exists on the
AS/400 or not and whether there is a guest profile, this would be where I
would start.

If the Windows user ID exists on the AS/400 it will try and log on as that
user with the windows password. If the passwords are different then you
should get a password prompt. I don't recall whether you get an opportunity
to specify the user profile or not - I seem to remember it depends on your
windows version and some other voodoo :)

The password will need to match the password for the AS/400 profile which
matches the name of the windows profile. If you have a situation where the
Windows profile happens to exists on the AS/400 but is not the Users actual
AS/400 profile they can get slightly confused as to what password is
actually required.

Go back and read that again - it may not be exactly obvious :) I had a
situation where a windows logon happened to match an old disabled profile
and prevented the user from logging onto Netserver successfully because
they didn't the users password and tried the password for their own profile
thinking incorrectly that this was the password required.

Once there is a profile match - regardless of the password situation -
guest access cannot be used for that Windows user. If the profile doesn't
match then the guest profiles is used and no further problems are encountered.

If the passwords get messed when attempting a netserver connection, then
the profile can become disabled for Netserver, but will otherwise continue
to operate normally on the AS/400. Making any change at all to the profile
will reset the profile to enabled for netserver use. I think even just
CHGUSRPRF, prompting and hit enter will fix this situation - you may want
to try this in a few cases to see whether this is the problem. I can't
remember whether there is another way to see this or not.

I did find it useful to use Ops navigator and click on TCPIP->SERVERS and
then explore the netserver server. There is a tab or tree that allows you
to view the shares and who is logged on to them. This might allow you to
get a handle on whether the guest profile is used extensively or not. The
configuration entry from here will also tell you if a guest user is
enabled, but your advice that a win95 user with no profile logged on says
to me that there is.

Lastly, one of the things I recall fooling with to try and make Netserver
work was setting up an LMHOSTS file - perhaps you could check whether the
working PC's have this and the others don't (I have a feeling this is
related to your reference to WINS but can't remember off hand whether they
are different implementations of the same sort of thing)

One of the symptoms I found useful to evaluate in this case was whether the
user could see the AS/400 in the network neighbourhood or had to search for
a computer to access the shares by name.

The Advantage NetServer redbook is hugely useful for this stuff in my
opinion and is worth getting for the troubleshooting bits alone.

Hope this helps

Hi Everyone,

There's tons on this subject in the archive, and I gleaned a couple of work
arounds, but nothing that explains the problem.  A client of mine has a
VRM510 AS400 on which they're sharing a folder from the IFS, (/SMART), over
their LAN (their LAN actually covers several geographically separate sites).
The permissions on the share grant everything to everyone, i.e. *PUBLIC is
*RWX.

At one of these sites, they have no problem mapping to the share.  At two
other sites, some PC's work, some don't.  All the users attempting this also
use CAE to access the AS400 with no problem.  Userid doesn't appear to be
the problem -- one Win95 user whose PC userid does not exist on the AS400
has no problem mapping the drive.

My contact said they use WINS for name resolution, but that he's also tried
using the IP address of the AS400 from a failing PC, e.g.
\\10.10.10.10\SMART, and that didn't work either.  None of the PC's use
ZoneAlarm or any other personal firewall software.  I asked if perhaps some
router was filtering the SMB traffic, and he said no -- they had a working
and failing PC's side-by-side, so they took the LAN cable from the working
PC and connected it to the failing PC, and no change.  They took a brand new
PC, scratch installed Win2K Pro on it, and it failed.  They are using
backslashes in the UNC.

His theory is that there's a limit to how many share names Windows can
handle, something like 64KB worth, and when it's doing its discovery
process, it blows the table and reports that it can't find the server.  I
would've thought any limitiation like that would have been taken care of in
W2K, but possibly not.  They do have a lot of machines on their LAN,
although I'm not certain of the exact number.

I found a suggestion in the archives about having a working PC share the
mapped drive and passed that along -- I've never tried it, but sounds like
it might work.  I apologize for the lack of attribution, but you know who
you are <grin>!

Does anyone have any other ideas?  I've run out of questions to ask.

Peter Dow
Dow Software Services, Inc.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.