Sample VB AS/400 Client/Server Programs

  Copyright  1995, 1996. Ron Jones.
  Genesis Software, Inc.  All Rights Reserved.

This Document

At the Chicago COMMON (IBM Midrange-Users Group) I was asked, at the last 
minute, to fill in for a missing presenter and give a session addressing using VB and 
the AS/400 to create client/server applications. Although I have given many 
presentations on the subject in the past; I was not scheduled to do so at Chicago. 
Since I had only an hour to prepare for a 2 and 1/2 hour presentation I wanted to offer 
every attendee a little something extra in case my presentation did not address some 
of the topics that the original session would. So I told the audience that anyone who 
dropped me an e-mail on Compuserve would receive information on how to get some 
of sample VB code that was reviewed at the session.

  Unfortunately I was very busy directly after the conference while I completed my 
book on the same subject. Since the book was released I had some time to fulfill my 
promise and have completed putting together a few sample programs and information 
and have uploaded them to various forums around CompuServe.

  If you like the sample programs included, you should buy a copy of the book. The 
title is "Using Visual Basic With Client Access APIs". This 650+ page guide includes 
two companion diskettes that contain over 35 projects and utilities. It covers topics 
such as APPC, data queues, ODBC, OLE, SQL, and many others. You can contact 
Duke Press (the NEWS/400 people) at 1-800-621-1544 for more information. If your 
in the UK; contact Debbie Thorton at 44 161 929 0777. If you leave "down under"; 
contact Melissa Hughes at 61 2891 9136. OK, enough with the sales pitch.

  If you are a COMMON member and want more of this kind of stuff (VB, Windows, 
etc.) at COMMON conferences start yelling at the board and project leaders. Because 
frankly I'm tired of trying to get sessions scheduled. Without exception every session 
that I have ever done on the subject has been a "blow-out" and the reviews I received 
later were outstanding. I'm not saying this to "bang" my own drum, but to point out 
that there is a tremendous need for this stuff and you'll only have more sessions if you 
scream and holler. OK, enough venting <g>.

  The remainder of this document contains information about the files that are 
included in the COMMONVB.ZIP archive and other stuff. Please forgive me for any 
spelling or grammar errors. I put these together at Christmas and was more 
concerned about getting it out than making sure everything was just right.

  The information within this document is in no particular order and was included as an 
aid to you in using the supplied sample programs and writing AS/400 CS applications 
in general.

Disclaimer

Any information and/or code included within this document and/or the associated zip 
archive are subject to change without notice. No warranty of any kind is made or 
implied. There shall be no liability for errors contained herein or for incidental, special, 
indirect, or consequential damages in connection with furnishing, performance, 
content, or use of this material. Some material could contain technical inaccuracies or 
typographical errors.

Required Files

The COMMONVB.ZIP does NOT contain the .VBX files (GRID, CMDIALOG) required 
by a few of the programs provided. Neither does it contain the JET engine DLLs 
required by the TRACKER application. If you have VB 3.0 you should already have 
those files installed on your PC. Although the projects include are saved with VB 3.0; 
they are completely compatible with VB 4.0.

How To Extract Files

The COMMONVB.ZIP was compressed using the 2.04 version of PKZIP and any 
compatible ZIP utility should be able to unzip the file. The following steps should be 
followed to replace and/or add the files to the directories.

1. Download the COMMONVB.ZIP file to your personal computer.

2. Create the directory to which you wish to install the files. The recommended name 
is \GENESIS\AS400API. Using this naming convention will match the default used 
with the book's companion diskettes.

2. Place COMMONVB.ZIP file in the directory created.

3. Use PKUNZIP (or some similar utility) to unzip the files as shown in the command 
below:

    PKUNZIP -d COMMONVB.ZIP

      The -d optional causes the files to be restored to their original locations.

Smaller VB Font (ZZSMALL.FON)

One of the utility files provided is ZZSMALL.FON.

  If you are still using Visual Basic Version 3.0 or lower, within Windows 3.1, you have 
no doubt been bothered by the font limitation in code editing windows. The 
ZZSMALL.FON file lets you to overcome this limitation by providing a smaller font.

  To accomplish this change, after unzipping the COMMONVB.ZIP file, copy the 
ZZSMALL.FON file found in the ..\ZZSMALL directory to your Windows system 
directory (normally, C:\WINDOWS\SYSTEM). Then change the fixedfon.fon entry in 
the [boot] section of your windows SYSTEM.INI file to the following value:

    fixedfon.fon=zzsmall.fon

  After saving the file and rebooting your system, both Visual Basic and the notepad 
utility will use this smaller font, which will allow you to see more text within a single 
screen.

  VB 4.0 provides multipoint fonts as a new feature and does away with the need to 
use ZZSMALL.FON. ZZSMALL.FON does not work with Windows 95.

AS/400 Setup

The next few sections provide an overview of the steps required to create the AS/400 
library and the objects in it. The library and the objects are needed to run some of the 
programs provided. The books companion diskettes do all this stuff for you 
automatically.

  (Note: Lines beginning with an asterisk ("*") are commands which must be executed 
to properly setup the GENESIS library and other required objects.) 

Creating The Library

*   CRTLIB GENESIS _
*   TEXT('Genesis Software Library')

  (Note: The underscore ("_") character indicates the continuation of the same 
command on an additional line. Do not include the "_" character  when actually 
entering and executing the command on the AS/400.)

  All but two of the permanent objects and source code files will need to be installed in 
a single library on your AS/400. Try to use the library name GENESIS if possible. In 
the examples in this document, the library name GENESIS is used. If you decide to 
install to a different library, substitute the name you used were the GENESIS library is 
referenced.

Creating The QGPL REXX Source File

*   CRTSRCPF FILE(QGPL/SRCREX) _
*   SIZE(*NOMAX) _
*   TEXT('Genesis REXX Source Code')

*   COPY C:\GENESIS\AS400API\SOURCE\SROBJ.REX _
*   QGPL/SRCREX(SROBJREX)

  (Note: The COPY command is not actually an AS/400 command; it indicates that 
you must copy the source code referenced (in this case SROBJ.REX) from your 
personal computer to the AS/400 source file indicated -- in this case 
QGPL/SRCREX(SROBJREX).)

  You can use any file transfer product that supports uploading of source member 
records from your personal computer to the AS/400 to copy SROBJ.REX to the 
AS/400. If you do not have such a utility, you can always key the file in by hand using 
SEU (ouch!).

  This REXX source code is used by the SROBJ program to restore objects from your 
PC to the AS/400. Be sure that when you run SROBJ that it references the REXX 
option in the library QGPL.

Restoring AS/400 Objects

You can use the SROBJ.EXE utility program provided to restore the objects required. 
You can use his utility only if you have copied the REXX source code to 
QGPL/SRCREX, as described above. Be sure that the SROBJ settings point to the 
REXX option and the QGPL library is referenced as holding the source.
 
  Once you have restored SROBJRPG program (SROBJRPG.V23) you may change 
SROBJ to use the RPG server option, which is much faster. For more information 
about what each Save File Image (*.V23) contains, see the list below.

  SAVF Image, Description

  ECHOCBL.V23, ECHOCBL program required by ECHO
  PINGRPG.V23, PINGRPG program required by PING
  SROBJRPG.V23, SROBJRPG program required by SROBJ

  (Note: Genesis Software offers a product, Genesis Objex, which is a commercial 
quality version of SROBJ. It includes many enhancements such as file compression, 
drag and drop, faster processing, and no requirement for pre-existing source code or 
objects on the AS/400. It uses built-in CA/400 and DDM services found on all 
AS/400s.

  Genesis Objex also does not require the support of the remote command and file 
transfer API interfaces. All that is required is an APPC-complaint router that supports 
the EHNAPPC.DLL interface.)

  All the objects stored in the SAVF images referenced above were saved from the 
GENESIS library on an AS/400 at V2R3M2. When saved, the objects were assigned 
*ALL *PUBLIC authority and the owner was QUSER. After they are restored to your 
system you can change the security options as your installation needs warrant.

Creating Programs

If you are unable to restore the SAVF images to the GENESIS library with the SROBJ 
utility, you can create the required server programs required by using the standard 
AS/400 utilities. Of course, you must upload the source members beforehand or 
entered them in using SEU (ouch, again!). All the programs are listed below, along 
with the corresponding PC file (found in the ..\SOURCE directory) that contains the 
source code, and a description of the program.

  Program, Source Code, Description

  ECHOCBL,  ECHO.CBL,  Echo COBOL Program
  PINGRPG,  PING.RPG,  Ping RPG Program
  SROBJRPG,  SROBJ.RPG,  Save/Restore Server RPG Program

Creating The GENESIS Output Queue

*   CRTOUTQ OUTQ(GENESIS/GENESIS) _
*   TEXT('Genesis Output Queue')

  You can create the GENESIS output queue in the GENESIS library. This output 
queue is not required for any program to work, but is handy if you want to set up a 
user profile that references output queue. You might use this output queue to make it 
easier to locate spooled output that is generated while you are testing the programs 
provided.

Creating ICF Files AND Device Entries

*   CRTICFF FILE(GENESIS/ECHOICF) _
*   SRCFILE(GENESIS/SRCICF)

*   ADDICFDEVE FILE(GENESIS/ECHOICF) _
*   PGMDEV(ECHOICF) _
*   RMTLOCNAME(*REQUESTER) _
*   CNVTYPE(*USER)

*   CRTICFF FILE(GENESIS/PINGICF) _
*   SRCFILE(GENESIS/SRCICF)

*   ADDICFDEVE FILE(GENESIS/PINGICF) _
*   PGMDEV(PINGICF) _
*   RMTLOCNAME(*REQUESTER) _
*   CMNTYPE(*APPC)

  The APPC Basic Conversion Demonstration Program (ECHO) and the APPC 
Mapped Conversation Demonstration program (PING) require the existence of the 
ICF files and device entries shown above. To create these ICF files and device 
entries, enter the commands show above.

The GENESIS Library

  After you complete the setup process or the manual steps to create and set up the 
GENESIS library, you should find the following objects in GENESIS.

    Object, Type, Description

    ECHOCBL,  *PGM (CBL),  Echo Cobol Program
    PINGRPG,  *PGM (RPG),  Ping RPG Program
    SROBJRPG,  *PGM (RPG),  Save/Restore Server RPG Program
    GENESIS,  *OUTQ,  Genesis Output Queue
    ECHOICF,  *FILE (ICFF),  Echo ICF File
    PINGICF,  *FILE (ICFF),  Ping ICF File

Omitting The AS/400 Setup

Since you are manually setting up the client/server configuration, something that 
happens automatically if you purchase the book and it's companion diskettes, several 
INI files will not be properly built. These INI files need references to the AS/400 library 
and programs, which must be installed for them to execute properly.

  If you attempt to run a program and a message tells you that a certain INI file has 
not been set up, you need to manually place the proper entries into the INI file after 
you have installed the Server components on your AS/400. You must remember that 
many of the programs install on your PC rely on AS/400 counterparts to do their work; 
if they have not been installed, the programs cannot function!

  For example, the PING and ECHO programs found in the ..\APPC directory both use 
the APPC.INI file. Each section within the INI file has a System= and Library= entry. If 
you install the AS/400 objects during the setup process to an AS/400 named 
BIGBLUE in library GENESIS2, the following entries, along with others, would be 
found:

    [ECHO]
    System=BIGBLUE
    Library=GENESIS2

    [PING]
    System=BIGBLUE
    Library=GENESIS2

V3R1 Changes To Shared Folders

Beginning with V3R1, IBM has introduced a new file system known as the Integrated 
File System (IFS). This change has a direct effect on shared folder functionality. 
Before V3R1, all objects, including shared folders, originated from the QSYS OS/400 
library.

  The IFS introduces a layer on top of QSYS, making it just another entry in the "root". 
The propose of the IFS is too allow the AS/400 to service various file systems and 
prepare it for the future as IBM's "Server Of Choice". Hey, I'm excited! The IFS 
enables IBM to add new hardware and software, such as the FSIOP and UNIX 
compliant file systems. The IFS is intended to provide a common interface to all the 
objects on the AS/400.

  In many cases, if you are not aware of the IFS, you'd never miss it. In fact, if you 
have a CA/400 client that is running pre-V3R1 code, you will not be able to access 
any of the new V3R1 code and files that reside in the new IFS layer below QSYS. 
That is why IBM provided a migration aid that allows your pre-V3R1 client to access 
the required files and data found within the IFS by coping them to shared folders.

  With V3R1, the "root" shared folder is now designated as part of the QDLS 
(document and library services) file system (more on that in a minute); so the shared 
folder mappings shown below are equivalent.

  F: \\BIGBLUE\QIWSTOOL (Pre-V3R1)
  F: \\BIGBLUE\QDLS\QIWSTOOL (V3R1)

  Be aware that with V3R1, when IBM refers to a directory such as QPWXCWN (new 
CA/400 code), it is referencing the \QPWXCWN folder and not the 
\QDLS\QPWXCWM folder (used for PTFs and temporary code).

  IBM has provided new commands that allow you to work with the IFS from the 
AS/400 command line. These include the CPY command, which functions like the 
PC's COPY or XCOPY command; and the MD command, which -- like its PC 
counterpart -- creates subdirectories.
  
  The commands shown below demonstrate the copying of Windows client files to 
shared folders which would be accessible by pre-V3R1 clients.

  MD DIR('/QDLS/CAMIGRAT')
  MD DIR('/QDLS/CAMIGRAT/MRI2924')
  CPY OBJ('/QPWXCWN/*') TODIR('/QDLS/CAMIGRAT')
  CPY OBJ('/QPWXCWN/MRI2924/*') TODIR('/QDLS/CAMIGRAT/MRI2924')

  With V3R1, the familar AS/400 library is just another entry in the IFS and you always 
have a current location (library) within the IFS structure. Your AS/400 user profile 
determines your default home location which will be your current library when you first 
signon.

  The IFS will eventually offer seven unique file systems; including the "root" system, 
the QLANSrv system, the QOpenSys system, the QSYS.LIB system, and the QDLS 
system. The QFileSvr.400 and QOPT (optical disk) file systems will not be available 
until V3R6. The "root" system supports directory and file names up to 256 characters 
in length and names are not case sensitive. The QOpenSys supports the same file 
name length as "root", but names are case sensitive. QSYS.LIB contains all the 
familiar OS/400 objects. Each library appears as a subdirectory under the QSYS.LIB 
object. QSYS.LIB supports a 10.6 naming convention. The QDLS file system 
supports DLO (document library objects) and shared folders. It supports a 8.3 naming 
convention. The QLANSrv system provides support for the new FSIOP offerings.

  New IFS APIs are available for working with the various file systems referenced 
above. "Using VB With CA/400 APIs" only deals with shared folders support (QDLS). 
Hey, I had to leave something for volume 2! Anyway, I was given a 700 page limit!

Confirm After Allocate Required

In some cases, it may be necessary to issue a call to the EHNAPPC_Confirm API 
directly after an allocation to insure that the APPC conversation is in "synch". Using 
the API addresses a problem you might encounter. After you allocated a conversation 
and attempt to send data to the AS/400 program, everything may appear to be OK but 
no data is received by the AS/400 program. If you run across this problem, calling the 
EHNAPPC_Confirm API, before sending the data, might help clear it up. See the 
zzCAConfirm wrapper in ZZPAPW2.BAS for an example of using 
EHNAPPC_Confirm.

ICF Entries For Basic And Mapped Conversations

One common error that people make when they are setting up the ICF device entry 
required to execute APPC conversation if the incorrect entry of parameters for the 
ADDICFDEVE command. Dependent on whether you are setting up support for a 
basic or mapped conversation the value will be different. Consider the examples 
below.

    ADDICFDEVE FILE(GENESIS/ECHOICF) PGMDEV(ECHOICF) _
    RMTLOCNAME(*REQUESTER) CNVTYPE(*USER)

    ADDICFDEVE FILE(GENESIS/PINGICF) PGMDEV(PINGICF) _
    RMTLOCNAME(*REQUESTER) CMNTYPE(*APPC)

  The first entry is for a basic conversion because the conversation type (CNVTYPE) 
parameter has been set to *USER. This means that the user-written program will 
have handle the header/error information. The second example shows the correct 
entry for an APPC conversation. Note that the CNVTYPE parameter is omitted and 
the communications type (CMNTYPE) parameter is specified as *APPC. This 
indicates that the "mapping" of the header/error information will be handled 
automatically by APPC support.

Close Before Ending Transfer Request

Although the IBM documentation would suggest that after you perform a transfer 
request you can end the conversation and any open files will be closed, I have found 
that this sometimes leads to errors. This is especially true when doing uploads. I 
recommend that after you complete a file transfer, you always close the file by calling 
the zzTFClose wrapper before calling the zzTFEndConversation wrapper.

Notes About Version Checking And Stamping

The ODVERCHK program allows you to address problems that can  occur when 
version stamping is not done properly and how it can make your life difficult. This 
section presents examples of some of the problems that might occur. This section will 
definitely put the "fear of software" into your heart.

  Suppose vendor A and B use a common DLL named COMMON.DLL in their 
products. Maybe its a DLL that contains great sort routines. Vendor A has been 
working on its product for three years (must be an IBM spin-off company) and is 
stilling using version 1.0 of COMMON.DLL.

  Vendor B has produced a product which also uses COMMON.DLL, but has kept up 
to date by developed their product using version 2.0 (the latest version). When you 
buy vendor B's product and when you run their setup/installation, COMMON.DLL 
(version 2.0) is installed in your Windows system (e.g., C:\WINDOWS\SYSTEM) 
directory. So far, everything is cool!

  Now you buy Vendor A's product and run the setup/installation for it. Some time 
during the setup/installation process, COMMON.DLL must be installed. Several 
scenarios are possible at this point -- most of them are bad!

  If Vendor A is a "responsible" vendor, its setup/installation program will be smart 
enough to recognize that a more recent version of COMMON.DLL is already installed 
in C:\WINDOWS, and it will do nothing. No problem here, maybe (see below). But the 
setup might be "stupid" and copy the older version of COMMON.DLL over the top of 
version 2. This causes no problems for Vendor A's product, it was designed to work 
with version 1.0. So Vendor A has nothing to worry about. But what happens when 
you try to run Vendor B's program? If your lucky, its program will also work with 
version 1.0. But if Vendor B's product requires an API or function that was introduced 
with version 2.0 of COMMON.DLL -- you guessed it -- Vendor B's product is dead in 
the water!

  Another possible scenario is that Vendor A's setup program installs version 1.0 of 
COMMON.DLL into another directory (e.g., C:\WINDOWS), or in the directory where 
the program is installed. Now you have two versions of the same DLL on your system 
and depending on how you have your PATH set up; the programs from vendor A and 
B may or may not work.

  Vendor A's setup program may be smart enough not to install version 1.0 of 
COMMON.DLL, because it sees a more recent version 2.0 of COMMON.DLL is 
already installed. Vendor A's setup program is saying "OK, I see a newer version 
(2.0) of COMMON.DLL, so I'll use it instead of my older 1.0 version". This is great if 
the developer of COMMON.DLL has not introduced any incompatibilities between 
version 1.0 and 2.0. Version 1.0 will be left on Vendor A's setup disk and only version 
2.0 will be on your hard drive. But what if COMMON.DLL version 2.0 does not support 
programs written to use COMMON.DLL version 1.0. Now we have real problems! 
Vendor B's program still works fine. Remember it was developed to use version 2.0 of 
COMMON.DLL, which was installed when you installed Vendor B's product. But 
Vendor A's program, that you just installed, won't work because it was designed to 
use version 1.0 of COMMON.DLL. Vendor A has followed all the rules (other than not 
keeping up with changing versions of COMMON.DLL) but now their program won't 
run. This scenario is rare, but not unknown. Have you had problems with 
THREED.VBX or GRID.VBX? Now you understand why developers are so concerned 
with maintaining backward compatibility of files such as our example COMMON.DLL.

  Another problem might occur if the different versions of COMMON.DLL have no 
version information. How do you know know version is which? You can't always go by 
the dates of files, because these can be easily changed. Basically, you're out of luck 
in this situation. Unfortunately, this situation happens much to often. For example, 
IBM doesn't even version stamp its CA/400 DLLs! Write your congress person now! 
Being able to keep files straight when they have no version information is a hit-or-
miss proposition.

  To add more fuel to the fire, what happens if another component provider decides to 
provide a great new DLL that does all kinds of neat things, and they decide to name 
their new component -- you guessed it -- COMMON.DLL! Then Vendor C develops a 
new product using this other COMMON.DLL component. The fun really begins when 
you install Vendor C's product!

  I warned you before you started reading this section! Don't worry, I'm sure your files 
are all correct, and your using the most up to date available!

Using the WPS.EXE Utility

In addition to the ODCHKVER.EXE, supplied with the companion diskettes, a VB 
utility that you might find very helpful is WPS.EXE. This program, installed with VB, 
can be found in the \VB\CDK directory. It displays a map of all programs and DLLs 
loaded into your PC's memory. This information is very useful in determining which 
DLLs are actually being used by Windows, and your programs.

Using Basic DOS Support With Windows 95

It is possible to use the basic (not extended) version of PCS/400 with Windows 95. 
Remember that you will be unable to use any of the APIs because they all require that 
the extended DOS router be running. If you have upgraded to V3R1M1, see "Using 
CA/400 With Windows 95" below.

  Here are the steps required to setup configuration diskettes that let you install DOS 
basic support on a Windows 95 PC. To perform the tasks outline, you must have a 
PC that is using PCS/400.

    Use the PC Support Administration Program (PCSWADM.EXE) to create a 
configuration using the basic DOS option. You will need 4 or 5 formatted diskettes 
(HD) to create a complete install set. Follow the instructions provided by 
PCSWADM.EXE.

    On the Windows 95 PC, access the Control Panel (available through the Start 
menu) and select the Network icon. Click the Add button under configuration. Choose 
protocol and once again click the Add button. Choose Microsoft and MSDLC. The 
MSDLC protocol will be loaded into Windows 95, but we still need to make changes to 
the AUTOEXEC.BAT file for basic DOS services.

    Open a DOS window and make a backup copy of AUTOEXEC.BAT, CONFIG.SYS, 
STARTPCS.BAT. Then run the CA/400 install from the diskettes that you created 
earlier. Normally, the install would go to the C:\PCS directory. Remove all changes 
made by the install (copy the backup versions of the files to the changed originals). 
You will need to make the changes shown below.

      Be sure that your CONFIG.SYS has, at a minimum, the following entries:

        DOS=HIGH
        DOS=UMB
        FILES=99
        DEVICE=C:\PCS\EIMPCS.SYS

      Be sure that your AUTOEXEC.BAT has, at a minimum, the following entries:

        PATH=...C:\PCS;
        C:\WINDOWS\MSDLC.EXE
        C:\PCS\STARTPCS

    C:\PCS must be somewhere within your path statement. MSDLC must be run after 
you have initialized your network connection but before you log on. Dependent on 
your network, you may need to play with this one to get it right.

    Be sure that your STARTPCS.BAT file has no reference to shared folders, the 
update function, virtual printing, or data queues. Sorry, they don't work. Basically, all 
you need is the STARTRTR command (which you may just move to the 
AUTOEXEC.BAT file if you wish).

  After restarting your computer the following functions should (notice I said should!) 
work:

    PC Support Administration (PCSWADM)
    PC Support Menu (PCSMENU)
    File Transfer (both ways)
    PC to AS/400 file transfer
    The workstation function
    Rumba terminal emulation
    Rumba printing.

    The workstation function (WSF.EXE) works, but if you end it and try to execute it 
again it will fail. Although Rumba will work, the fast path, auto connect, and session 
configuration options will not function.

    You'll need to install, set the connection type to "PC Support", and save the 
configuration. Use the saved configuration as a shortcut on the Windows 95 task bar. 
You'll have to click Session/Connect each time you start Rumba.

  Remember that IBM does not support this kludgy configuration, so don't expect any 
help from BIG BLUE. Whoops, I forgot; they can't use the BIG BLUE reference 
anymore<G>!

  Good luck and may the force be with you! Hey get to V3R1M1 as soon as possible!

Using CA/400 With Windows 95

As this book was being prepared for publication, I was attempting to get the CA/400 
V3R1M1 client code to work within the Windows 95 environment. Although my 
success has been mixed up, I thought I'd shared with you information provided to me 
by IBM. This information mighthelp you to use the CA/400 For Windows 3.1 client in 
Windows 95 successfully. 
  
  Remember that IBM does not support the use of its clients in the Windows 95 
environment. All the information below is strictly beta work. To have any hope of 
success, you must use the V3R1M1 CA/400 For Windows 3.1 client. DO NOT try this 
configuration within a production environment unless you are looking for a career 
change!

  The following PTFs need to be applied to your V3R1 system:

    APAR, PTF, File

    SA46324, SF25773, VREFLECT.386
    SA46342, SF25785, EHNSFW.DLL
    SA46100, SF25550, VNCD.386
    3600058, SF25251, NOFNSD.DLL
    3992942, SF25788, EHNEC.DLL
    GUI/400, SF26463

  After applying the PTFs, you need to copy the files listed above to your CA/400 
directory on your personal computer. If you are doing a new install of CA/400 For 
Windows 3.1 on your Windows 95 PC, you must first apply the PTFs to your AS/400 
and build a new set of install diskettes from the AS/400 that will automatically include 
the fixes. This can be done by running the CA/400 administration program on any 
currently functioning CA/400 For Windows 3.1 client PC.

  Another possibility is that you have already installed Windows 95 onto a PC that has 
CA/400 for Windows 3.1 installed on it, and the PC currently does not work. If this is 
the case, you can copy the fix files from the AS/400 using shared folders on a 
different PC where Windows 3.1 is installed, and then manually copy the files to the 
Windows 95 PC into the CA/400 directory (normally C:\CAWIN).

  For the LAN based router, you can use either the IBM LAN Support Program or the 
Microsoft DLC (MSDLC is available on the NEWS/400 CompuServe Forum) and the 
following steps must be taken:

    Using the IBM LAN Support Program (not recommended)

      Disable all networking functions in Windows 95 by

        1. Select Start
        2. Select Settings
        3. Select Control Panel
        4. Select Network
        5. For all installed components select the component
            and select the REMOVE button.

    OR

    Using the Microsoft DLC driver (recommended) 
    
      1. Select Start
      2. Select Settings
      3. Select Control Panel
      4. Select Network
      5. Select Protocol
      6. Select ADD Button
      7. Select Microsoft
      8. Select Microsoft DLC and press OK
      9. On the main network control panel 
          dialog select Microsoft DLC

         With in Advanced tab window, select properties, and
         set the following parameters:
 
           SAPS=8
           STATIONS=20
           xsaps0=5
           xstations0=5

    If you are using the IBM Token-ring Adapter you must modify the default transmit 
buffer size as follows:

      1. Select Control Panel
      2. Select Network
      3. Select IBM Token-ring card Properties
      4. Select the advanced TAB
      5. Change the Transmit Buffer Size from 1024 to 2040

  A manual entry in your Windows WIN.INI configuration file is required. Open the file 
using any text editing utility, such as NOTEPAD, and add the following entry into the 
existing [ModuleCompatibility] section:

    LANNSD=0x0001

  With this configuration, certain restrictions do apply, including:

    1. The Graphical Access/400 function of Client Access/400 does not currently
        work. A PTF will be forth coming to correct this.

    2. If you Install Client Access/400 for Windows 3.1 to a new Windows 95 PC
        without the fixes on the install diskettes, the install will fail.

    3. When installing the Rumba/400 function from the Setup program, no icons will
        be created. This can be corrected by the following steps.

      a. Select Start/Settings/Taskbar
      b. Select Start Menu Programs / Advanced
      c. Select Programs
      d. Select menu item File/New/Folder
      e. Type "Client Access 400 Rumba" as the folder name
      f. Double click on "Client Access 400 Rumba"
      g. In the empty contents section click your right mouse button
      f. Select New/Shortcut from the menu bar
      h. Select Browse RUMBACAW
      i. Select RUMBAWSF.EXE for "Rumba - Terminal"
      g. Push the Next button
      h. Name the Icon "Rumba - Terminal" and push the finish button

      Repeat steps g-h for the following applications:
        RUMBAPRN.EXE for "Rumba - Print"
        RUMBA.EXE for "Rumba - Main"

      i. Select main menu option File/Close
      j. Push the OK button on the taskbar properties

    To run Rumba function from the main Start menu select the "Client Access 400
    Rumba" menu, and your desired icon.

    4. Microsoft's DLC does not function properly with certain Pentium machines. Do
        not assume that MSDLC is not the cause of any problem you might experience.

  (Note: I've had reports that Microsoft support is telling people all they need to run 
CA/400 within Windows 95 is an updated version of a file named NOFNSD.DLL. 
According to IBM this is not true and they are telling the truth. Microsoft is also 
claiming that Basic DOS PC Support will work under Windows 95. While this is true, 
IBM says they will not support it and that only the updated Windows V3R1M1 client 
(available 1996) will be officially supported.)

  (Note: One problem that you may encounter with Windows 95, if you are using 
Novell SAA, is a message that the IPX/SPX support is not started. If you are using the 
32-bit Novell client this is possible since it is loaded as a virtual device driver (VxD) 
after AUTOEXEC.BAT has been run. You can overcome this limitation by moving the 
AUTOEXEC.BAT code, related to start the router, to WINSTART.BAT in the 
WINDOWS directory. The commands in this file are executed after the VxDs are 
loaded; so IPX/SPX support will be "seen" by the STRNRTR.EXE and PCSWIN.)

  Good luck!

WWW Sites

The following list includes additional WWW sites that might be of interest to AS/400 
developers and users.

Duke Communications International
http://www.duke.com/

IBM AS/400 Home Page
http://as400.rochester.ibm.com/

IBM AS/400 Services
http://as400.rochester.ibm.com/QDLS/400home/service/serv_m.htm/

IBM Book Ordering
http://booksrv2.raleigh.ibm.com/

IBM Personal Software Services
http://ps.software.ibm.com/

IBM Global Network
http://www.ibm.net/

IBM Home Page
http://www.ibm.com/

IBM Networking Home Page
http://www.raleigh.ibm.com/

IBM Red Books
http://www-i.almaden.ibm.com/redbooks/

Netsoft
http://www.netsoft.com/

ShowCase
http://www.bismark.com/showcase/

Some Thoughts

First of all, if you've been waiting for this file since the Chicago COMMON -- my 
apologies. I have included a few personal thoughts about AS/400 client/server 
application development.

  In the world of AS/400 client/server computing there are many ways to "skin a cat". 
People are always asking me what the best solution is; or what is the best way to 
design an application. I tell them there are a number of ways most applications can be 
done -- this is always true. I have found; however, that the most robust, reliable 
applications that I have developed rely on APPC itself.

   The scenario of a developer written client program (that for me is almost always VB 
with a pinch of Visual C++ and Delphi) and a developer written server program (that 
for me is almost always RPG) communicating through APPC APIs can't be beat for 
performance and reliability. True, these solutions are generally more complicated to 
code and implement; but once you've got them working, they are very solid.

  Remember that almost all the other APIs use APPC to communicate and they rely 
on IBM provided utilities and servers to "ride the APPC wave". That convenience 
comes at a price -- less performance and lack of control over specific features of your 
application.

  ODBC is promising and you can do some great stuff with it. But the QSYS file 
system, at this point, just does not always match up well ODBC. With V3R1, IBM has 
done a lot to change that. But why do you think IBM is introducing all these new file 
systems into the AS/400? Think about it!

  Over the next year, I see myself continuing to write both the client and server 
components for new applications. I'll probably move toward CPI-C since it provides a 
slightly cleaner interface than APPC. TCP/IP will also be playing a greater role in what 
I do. The new object management APIs are neat and I've played with them some. But 
they really don't do much for normal applications that don't do much generic stuff with 
AS/400 objects but almost always deal with manipulating data. I'm doing more work 
with the built-in support provided by IBM's DDM servers and have managed to do 
some exciting stuff. A lot of the functionality of Genesis Objex relies on the 
capabilities within DDM.

  I'm anxious to look at the new 32-bit support IBM, and others, will provide for 
Windows. That's were the cooperate world will be heading -- none to slowly. I'm a big 
believer in Windows NT and IBM has got to get on the bandwagon with it. I've already 
seen some movement by IBM in that direction. 32 bit development is were it's at now, 
or will be very shortly. I'll be learning more about VB 4.0 over the next year. Borland 
will shortly be coming out with their 32-bit Delphi product. I plan to use Delphi more 
over the next year. Mainly in applications were I don't want the overhead of the OLE 
baggage that VB 4.0 carries.

  The AS/400 is a marvelous machine; rock solid. If the shops I do work for had 
AS/400s that were as unreliable as the LANs and WANs that surround them, then 
many an AS/400 professional would be "sleeping with the fishes" today. You can 
bellow all you want about this fact, say forget those PC toys, but the big picture is that 
LANs, WANs, and PCs are here to stay. Don't doubt that for a second. They will be 
the players; and if IBM can have the AS/400 become a valuable, stable, resource-
filled component in that world then they've got something.

  Today, I believe the future of the AS/400 in a client/server world is getting brighter. 
Anyone who knows me will tell you I didn't feel that way not to long ago. Good luck in 
your endeavors trying to make the AS/400 work for your client/server applications!

  I hope the sample programs provided you with some good basic (no pun intended) 
examples of AS/400 client/server programs. 

Ron Jones, CCP
Genesis Software

Genesis Software

  Feel free to distribute the COMMONVB.ZIP file to whomever. It's free for the using. 
Just remember that all the code comes with no guarantees; so check out your 
programs that use the code very carefully. By the way, we do sell code and programs 
that we guarantee will work. For more information about Genesis Software and the 
products and services we provide contact:

  Genesis Software, Inc.
  2709 Penny Lane
  McKinney, Texas 75070
  CompuServe: 75070,2615

..Ron Jones

Description For Forum Upload of COMMONVB.TXT

12/24/95 update to text file describing the purpose and contents of the 
COMMONVB.ZIP file. This file also contains information about the downloading and 
installation of the COMMONVB.ZIP file. Ron Jones.

VB CA400 APIS API AS400 CLIENT ACCESS GUI

Description For Forum Upload of COMMONVB.ZIP

12/24/95 update for zipped file containing sample programs and information about 
using VB to develop AS400 client/server applications. Enjoy! Ron Jones.

VB CA400 APIS API AS400 CLIENT ACCESS GUI





