The Client Access/400 for Windows client follows the Windows convention of storing program parameters in text files. These are known as INI or initialization parameter files. The files are easily recognized by the three character INI file name extension. Although there are many INI files used with the Windows client, we’ll look at the two main INI files: NSD.INI and PCS.INI. Those files contain parameters for starting the Windows-based router and parameters for CA/400 functions.
As with most INI files, there are several sections in each file. Each section is used to group parameters that have something in common. For example, Figure 1 shows a listing of the NSD.INI file, with sections for Configuration, MODES, TWINAX, and SIDEINFO. Sections are delimited by section headers enclosed in brackets, as shown in the figure. Within a section, certain keywords are recognized as valid for the section. The keywords are followed by the equals sign, then the parameters for the keyword.
As with most Windows programs, entries in an INI file are created and maintained with a configuration program. A popular alternative is to use a simple text editor, such as the DOS EDIT program, to manually change entries. The problem with the manual approach is that some of the INI file entries have dependencies on each other. The configuration program will take those dependencies into account, and make the required changes. When you manually edit the INI file, you might not realize that there are dependencies.
For the most part, the CA/400 for Windows configuration programs make all of the INI file changes that you’ll need. I’ll point out some of the settings that you may want to set manually. If you do manually edit the INI files, be sure that you can recover a working version of the file, if necessary.
The CA/400 for Windows INI file entries are not well documented. I was able to locate some information about some of the parameters. For other parameters, I simply changed configuration options, then examined the INI file.
The NSD.INI File
The NSD.INI file is located in your WINDOWS directory. NSD.INI contains settings to control the Windows router. When you start a session from your CA/400 PC to the AS/400, the settings in this file are used to establish the session. The settings describe the type of physical connection, the systems that you connect to, the mode names that are available to connect to the systems, and other identifiers used to establish the connection.
The file name NSD.INI is a holdover from an earlier IBM product, Networking Services/DOS (NS/DOS). That product provided a DOS-based router, similar to the PC Support router, and provided both APPC and CPI-C programming support. NS/DOS could be used to create an APPC connection between a PC and another system; the product was not limited to an AS/400 connection, as was PC Support. NS/DOS evolved into another product, APPC Networking Services for Windows (NS/Windows). The new Client Access/400 Windows-based router is derived from the NS/Windows package. To make it easier for NS/DOS users to convert to NS/Windows, IBM retained the NSD.INI file name and many of its parameters. That’s why we see it in our CA/400 configuration.
As far as we’re concerned, there are three sections to consider, and at least one optional section, depending upon your link type. The three sections are Configuration, MODES, and SIDEINFO. The optional section will be LAN, REMOTE, TWINAX, or MPTN (Multi-protocol Transport Network).
The Configuration Section
As shown in Figure 1, the Configuration section of NSD.INI contains some easily recognized parameters. All of these parameters can be set and maintained with CA/400 configuration programs.
The DLCTYPE parameter identifies the physical link type. The valid link types are shown at the bottom of Figure 1. The link type that you use is associated with a corresponding section in NSD.INI. In Figure 1, the DLCTYPE=TWINAX is associated with the TWINAX section, where the EMLI parameter provides additional information about the Twinax link. Each DLCTYPE will have one or more parameters specific to the link type in the corresponding section. For the most part, those parameters are similar to the parameters used in the PC Support CONFIG.PCS file.
The LANGUAGE identifier code is 2924 for English. The Configuration Parameters Reference states that this is the only value allowed.
The STARTPROGRAMLAUNCHER parameter refers to the list of programs in the DEFINETP (Define Transaction Program) section. One of the features of NS/ Windows is the ability to start programs on the PC when you start your connection. Those programs can then process incoming attaches from another system. That makes it possible for an AS/400 program to contact the program running on the PC. This capability was not available in PC Support. In PC Support, the PC program had to first contact the AS/400 program. I expect there to be more documentation on this capability with the CA/ 400 for Windows refresh, due any day.
The LOCALLUNAME parameter is used to identify the PC within the network. The LU (logical unit) name is given as network_ID.lu_name, using standard
APPN naming conventions. In this case, the network ID is APPN. You can determine your network ID by running the AS/400 Display Network Attributes (DSPNETA) command; the value is shown as the local network ID. Chances are, your network ID is APPN—the system-supplied default. The LU name must be separated from the network ID with a period. The LU name must be unique within the network, as it identifies your PC.
The NODEID is what we know on the AS/400 as the exchange ID. You don’t need to change the value from its default.
DIRECTORY is used to tell the router program the location of files that it needs. If you change the directory or drive where your CA/400 for Windows programs are located, you need to change this parameter to the new location.
The COMMONUSERID is used to provide a user ID when you’re connecting to multiple systems. If you don’t have a common user ID (i.e., you sign on to each system with a different user ID), then you might not need this parameter.
Finally, the RTDN parameter is used to identify the name of the default system to which you connect.
The MODES Section
The modes section defines APPC mode names that you can use to connect to the AS/400. The two modes that you will most commonly use for CA/400 connections are QPCSUPP and QSERVER. You select a mode in the System Configuration section of CA/400 for each system to which you configure a connection.
You should not select the SNASVCMG mode. That mode is used for internal APPC processing. When I tried to use that mode, I got the error message shown in Figure 2.
The mode used to connect to a system is shown in the SIDEINFO section of NSD.INI. I’ll describe the choice of a mode in detail when we review that section.
Within the MODES section, you define a mode on one line. In Figure 1, six modes are defined. The parameters are entered as shown at the bottom of the figure.
Although we don’t have enough room here to describe all of the factors you need to know when defining a new mode, there are two points you need to keep in mind. First, you must create a mode with the same name on the target system. For example, if you create a new mode named MYMODE in NSD.INI, you also have to create MYMODE on the AS/400 (with the Create Mode Description command, CRTMODD) in order to establish a connection using that mode. Second, mode limits are always negotiated to the lower of the two sides in the connection. If you create a mode, you’ll usually enter corresponding limits for each mode description.
When the Maximum RU (request/ response unit) Size parameter is not given (as in modes BLANK and #INTER), a default value is computed based on the link type. The Maximum RU Size parameter value of * (asterisk), as given for modes QPCSUPP and QSERVER, seems to be a special value for the CA/400 for Windows package. I was unable to find any documentation about the use of *. In my testing, I substituted a blank for * and got the same results.
The SIDEINFO Section
The SIDEINFO section is used in the CA/400 for Windows package to describe the systems to which you want to establish connections. In the NS/Windows package, SIDEINFO can be used to define the partner program that you want started on a remote
system. For CA/400, you don’t specify the program to start, just the name of the remote system.
The parameters used with SIDEINFO are shown at the bottom of Figure 1. The symbolic destination name is shown in the Connection dialog. A system that is accessed through another system, such as S1012063 in the figure, specifies the symbolic destination name of the first system in the link name parameter (the symbolic destination name AS400, as the next-to-last parameter on the S1012063 line, is the link name for system S1012063).
You have to specify one of the mode names from the MODES section for each SIDEINFO line. In the figure, each system is using mode QPCSUPP. There are three places where the mode name must agree: in the SIDEINFO line, in the MODES section, and on the AS/400. In all cases, when I tested without the mode specified correctly, I received the error message shown in Figure 2. If you make any changes to your modes and then get this message, check your NSD.INI file settings first, then check for a corresponding mode name on the AS/400.
Failing to set other parameters on a SIDEINFO line can cause other errors. If the link name parameter is incorrect, you’ll get the message shown in Figure 3. If the partner LU parameter is wrong, you’ll see the message in Figure 4.
Those errors should be easy to correct. For the link name, be sure that you’re using a name that is a symbolic destination on another SIDEINFO line (as in the example, symbolic destination S1012063 points to link name AS400). For the partner LU, you can get the required APPN network ID and location name from the DSPNETA display. For the location name part of the parameter, use the default local location from DSPNETA.
A technique that usually provokes a lot of interest is hard-coding the user ID and password into a SIDEINFO line. You simply enter the user ID in the conversation_security_user_ID field, and the password in the conversation_security_ password field. When you start the connection, those two values appear in the connection dialog (the password shown as asterisks). The obvious deficiency with this technique is that the user ID and password are sitting as plain text in the NSD.INI file, which is not secure.
The final parameter on a SIDEINFO line is used to indicate that a connection to the system should be started automatically. The “1” at the end of the line is used to indicate that. You can set and maintain this value in the system configuration program.
The PCS.INI File
The PCS.INI file is used to store configuration options for most of the CA/400 for Windows programs. PCS.INI is roughly equivalent to the PC Support CONFIG.PCS file. If you upgraded from PC Support and used the migration program (see PCSE March/April 1995, “From DOS to Windows: A Migration Story”), your CONFIG.PCS and STARTPCS.BAT files were used as the basis for the new PCS.INI file.
There are almost no changes that you need to make manually to PCS.INI, as the configuration programs for each function maintain their section of the file. A sample PCS.INI file is shown in Figure 5. In the figure, you’ll see that there are several sections, as in the NSD.INI file. Each configuration program is responsible for its section. The specific sections are referenced when you start the corresponding function.
The one section that you might want to change is the DIALOG section. The TYPE line specifies either BASIC or ADVANCED. If you specify ADVANCED, you
get the Advanced Connection dialog, shown in Figure 6, when you start CA/400. You might want to use the advanced dialog if you have more than one AS/400 to connect to, and you want to choose the AS/400s with which to start sessions.
If you’ve configured sessions to automatically start to one or more AS/400s, and you don’t need to choose the systems at connect time, you can use the basic setting. That setting simply presents the router sign-on dialog, after which it makes connections to all of the systems.
The BASIC and ADVANCED sections of PCS.INI contain parameters relating to the connection option. For each function, the ExtraFunction option is documented as being not supported by CA/400 for Windows 3.1.
There are additional options that you might see in the ADVANCED section. Those options can be configured from the Options menu on the Advanced Connection dialog, as shown in Figure 6.
The Autoselection dialog, shown in Figure 7, lets you choose which systems will be started. When you make a setting in this dialog, the AutoSelection option is added to the ADVANCED section. Values for this option are shown at the bottom of Figure 5.
The Confirmation dialog is shown in Figure 8. Setting those options adds the ConfirmOn option line to the ADVANCED section. Values for ConfirmOn are also shown at the bottom of Figure 5.
Other INIs
There are several other INI files associated with the CA/400 for Windows client. The emulator program INIs, for RUMBA/400 and PC5250, are located in the emulation program directories. Other INIs are in the WINDOWS directory, such as SQLIBM.INI (the Database Access GUI).
A important INI that you might want to get into is WINDOWSODBC.INI. The new V3R1 ODBC driver includes many additional performance-related parameters. Those parameters don’t seem to have a maintenance program, so it looks like you’ll need to edit them manually. Documentation for the ODBC- related parameters is in the Inside CA/400 for Windows Redbook.
References
For information about NSD.INI settings: APPC Networking Services for Windows: Configuration Parameters Reference (SC31-8138)
For information about PCS.INI and ODBC.INI settings: Inside Client Access/400 for Windows 3.1 (GG24-4429)
[Configuration]
DLCTYPE=TWINAX
LANGUAGE=2924
STARTPROGRAMLAUNCHER=TRUE
LOCALLUNAME=APPN.PC486
NODEID=07500000
DIRECTORY=C:CAWIN
COMMONUSERID=QPGMR
RTDN=AS400
[MODES]
SNASVCMG=256, 1, 2, 1
BLANK=,2, 8, 4
#BATCH=256, 3, 8, 4
#INTER=, 7, 8, 4
QPCSUPP=*, 7, 32, 16
QSERVER=*, 7, 32, 16
[TWINAX]
EMLI=AS400,1
[SIDEINFO]
AS400=APPN.AS400,QPCSUPP,*,SAME,,,AS400
S1012063=APPN.S1012063,QPCSUPP,*,SAME,,,AS400,1
Valid DLCTYPE (Data Link Control Type) values:
LAN Token-Ring, Ethernet, IBM PC Network
TWINAX Twinax (TDLC)
SDLC Synchronous Data Link Control communications
ASYNC SDLC over Asynchronous communications
MPTN Multi-protocol transport networking
Mode description parameters
MN = MRUS, RPW, MNS, MNCW
where
MN = mode name (1 - 8 characters)
MRUS = Maximum RU size (256 - 16,384)
RPW = Receive pacing window (1 - 63)
MNS = Maximum negotiable sessions (0 - 32,767)
MNCW = Minimum negotiable contention winners (0 - MNS value)
Sideinfo parameters
SD = PLU, MODE, TPN, CONVSEC, USERID, PWD, LINK, AUTO
where
SD = symbolic destination name (1 - 8 characters)
PLU = partner LU (net_ID.lu_name, where net_ID and lu_name
are each 1 - 8 characters)
MODE = mode name (from MODES section)
TPN = transaction program name to start (* for CA/400)
CONVSEC = conversation security (no apparent affect on CA/400)
NONE or PROGRAM or SAME
USERID = user ID to start router session (blank = prompt)
PWD = password for user ID (blank = prompt)
LINK = link name (SD of another system)
AUTO = if 1, autostart this system
Figure 1: Sample NSD.INI File, with Parameter Explanations Figure 2: Message Sent When Using Invalid Modes Figure 3: Message Sent When Using Invalid Link Name Figure 4: Message Sent When Using Invalid Partner LU
[BASIC]
ExtraFunction=Yes
[ADVANCED]
ExtraFunction=Yes
AutoSelection=8
ConfirmOn=7
[DIALOG]
TYPE=BASIC
[PCS/400]
INITCFG=NO
GROUP=INS
AddFunc=INS
ODBC=INS
Database=INS
SOF=INS
[UPDT]
UPDT01=I:QPWXCWN,C:CAWIN,S,,,Client Access/400
UPDT02=I:QRUMBA,D:QRUMBA,S,,1,RUMBA
AutoSelection parameter values:
1 - first system
2 - all systems
4 - user defined
8 - no systems
ConfirmOn parameter values:
0 - none
1 - link disconnect
2 - system disconnect
4 - adjacent systems disconnect
(3, 5, 6, 7) - additive combination of 1, 2, or 4
Figure 5: Sample PCS.INI File (Abridged), with Parameter Explanations Figure 6: The Advanced Connection Dialog, Options Menu Figure 7: The Autoselection Option Dialog
Figure 8: The Confirmation Options Dialog
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online