Although it can be done with APIs, the easiest configuration of Netserver is done through iSeries Navigator.
Drill down into your iNav connection into Network-> Servers-> TCP/IP. In the list of Servers, right-click iSeries Netserver and select Properties. The Properties are intended to tell Netserver how to become a part of your Windows domain (or workgroup).
I would start by setting values only on the General tab. Click the ‘Next start’ button to change the startup Properties<ul>
Start when TCP/IP starts: Yes Server name: NSmysystem (Allow access using system name: No) Domain name: windowsdomain (or workgroup) Description: AS/400 description Logon server role: None
Once the properties are set, right-click Netserver and select ‘Reset and Start’ or ‘Start’. If it’s already started, the Stop it before using ‘Reset and Start’.
I tend to use the system host name prefixed with “NS” for my Netserver names and to restrict access using just the system name. Mostly, that’s personal preference. All of my “NS” names tend to show up in a group in Windows Explorer.
The “windows domain (or workgroup)” name will be whatever name shows up in Windows Explorer under My Network Places-> Entire Network-> Microsoft Windows Network. That’s the name that you most likely want your Netserver to associate with. I’m looking at Windows Explorer under Windows XP, so Vista and Windows 7 might show a different path.
Once you have configured and started Netserver, you can try to access it through Windows Explorer. Open Explorer and type “\\NSmysystem” into the Explorer address bar, just as you might type any Windows server name. The server shares should be listed just like any other shares from Windows servers that you might have.
Two likely obstacles may become apparent. First, there might only be basic default shares. Second, you might have inappropriate authentication.
To create new shares or to modify existing ones, double-click (or ‘Open’) the Netserver server in iNav. Shares may be created by selecting ‘New >’ from the Shared Objects item in the Netserver window. How you choose your shares and the attributes you assign to them are individual choices.
To set authentication, choose the appropriate settings on the Security tab of the Netserver Properties. I can’t tell you what’s appropriate for your environment. “Authentication method: Encrypted passwords” is probably the most common choice.
Authentication is easiest when your Windows user and password simply match your AS/400 user and password. But there are general security issues with that. If you don’t have a match, it’s best not to have matching user IDs.
When your user IDs don’t match under the ‘Encrypted passwords’ configuration, you should be prompted to enter a user/password combination when you try to access AS/400 shares. (The user ID might need to be entered as “NSmysystem\userid” to notify that the userid should be found on system NSmysystem.)
Authentication might not be simplest but might be best for you when you use one of the “Authentication method: Network authentication” methods. However, the help for that will lead you into the additional configurations that must be done to tell Netserver how to communicate with the authentication used in your network. New questions should be opened to deal with specific issues.
Once you can start Netserver and communicate from your PC to shares in Windows Explorer, you can feel comfortable that the basic connections are established. Then you can start looking at the other half of Netserver — accessing Windows shares from your AS/400.
Use the WRKLNK ‘/QNTC/*’ command to see if the reverse access through the green-screen works. Depending on the size of your Windows network, the performance of your AS/400, the network response times, the Netserver PTFs on your AS/400, the version of i5/OS on your AS/400 and other factors, it might take quite a few minutes before /QNTC shows as being populated with remote names.
The most likely obstacle will be that your green-screen session isn’t running under a user who can authenticate to the Windows servers. The same ‘matching profile/password’ problem happens on outbound connections as in inbound.
You might have an AS/400 profile that you can sign on with that matches a Windows server user and password. If not, you might need to create a “Local” user on the Windows PC such that user and password can match. Use that user for basic testing. If necessary, you can also use the AS/400 profile-switching APIs (QSYGETPH, QWTSETP and QSYRLSPH) or others to switch your jobs to an appropriate current user.
Again, details of problems should probably be covered in new questions.
CL uses the same CPY, CPYTOSTMF, CPYTOIMPF, etc., and other commands for access to /QNTC streamfiles as to any other directory in the IFS. As far as CL is concerned, /QNTC is just another directory. If you want examples, describe a basic problem that CL should handle for streamfiles. Examples can probably be supplied.
That’s about as much of a general overview as can be given. Multiple OS versions, multiple Windows network configurations and plenty of details go into this. The basic story is that Netserver acts as a basic Windows server out to the Windows Network and acts as a basic client when trying to interact with the Network from the AS/400 side.
In both directions, Netserver runs between the network and your *FILE host server. So don’t forget that your *FILE host server also needs to running.
Some clarifications are possible if you want to continue in the discussion area below.