These days, a large proportion of development projects are done using object- oriented technology. Many AS/400 shops are converting their legacy applications to object- oriented applications to take advantage of the flexibility and robust-ness that object-oriented design offers. Arguably, the premier language for object-oriented programming is C++. The AS/400 now offers a native C++ application development environment in the form of IBM VisualAge C++ for OS/400.
IBM VisualAge C++ first became available for the AS/400 in V3R6 and is not available for non-RISC AS/400s. IBM VisualAge C++ for OS/400 is a cross-platform compiler that offers numerous application tools and libraries. It supports development of applications based on the ANSI C++ programming language. The VisualAge C++ compiler does have a major shortcoming: It is not able to compile C400 programs. This must be done using the AS/400 ILE-C compiler. For this reason, projects that utilize both C and C++ programs on the AS/400 require a slightly more elaborate development process.
Installing VisualAge C++
A certain amount of planning goes into the installation of VisualAge C++. There are both AS/400 host and PC workstation components to the installation process. The workstation can be running OS/2, Windows 95, or Windows NT. For purposes of this article, I will be working with an OS/2-based workstation, but the basics discussed apply to both Windows NT and Windows 95. Client Access Optimized for OS/2 must be installed on both the workstation and the AS/400 before you run the compile on the OS/2 platform. The VisualAge C++ for OS/400 package consists of the VisualAge C++ for OS/400 base
component, the VisualAge C++ for OS/400 workstation component, and VisualAge C++ for your OS/2 workstation.
The first step is to install VisualAge C++ for OS/400 on the AS/400. Next, install the VisualAge C++ product to the OS/2 workstation from an AS/400 folder. The installation process is fairly quick and painless. When the dual-step installation is complete, you will have two icons on your desktop: one for VisualAge C++ for OS/400 and the other for VisualAge C++ for OS/2. Online help for VisualAge can be invoked from the OS/2 command line using the VIEW command. For example, to explore the VisualAge C++ for OS/400 C++ Language Reference, go to the CTTASHELP directory and enter VIEW CTTLRM.INF. VisualAge also comes with the IBM Library Reader, so you can read the online BookManager documents.
Cross-platform Compiling
VisualAge C++ for OS/400 is a cross-platform compiler. This means that your source code and the source editing and debugging processes are contained on the workstation, while the actual module and program creation tasks are accomplished on the AS/400. The compiler front-end operates on your Windows or OS/2 workstation and generates an intermediate code *.qwo file that is transparently transferred to the AS/400, where the compiler back-end produces an OS/400 module object (*MODULE). Module objects can be bound into program objects (*PGM) or service program objects (*SRVPGM) that run in the Integrated Language Environment (ILE) on the AS/400. Using this method, OS/400 C++ applications can be developed on the desktop using GUI tools.
The transparent transfer of the intermediate C++ code to the AS/400 is accomplished using the services of a VisualAge/Client Access connection that is made via a Communications Manager session. If you want the intermediate compile to be transferred immediately to the AS/400 and a module object to be created in a single step, this connection must be established before invoking a VisualAge compile. Working without the Client Access connection allows you to edit, compile, and browse your C++ source code from your PC workstation alone. In this disconnected mode, a full compile- time error code listing can be generated. In addition, an intermediate code file can be saved that can later be transferred to the AS/400. Disconnected mode is a quick way to check the syntax of your code. When a Client Access connection is reestablished, the intermediate code file with the .qwo extension is recognized by VisualAge as the resulting file from the previous compile. By specifying an intermediate (*.qwo) file on a compiler invocation, VisualAge will not attempt to recompile this file. Instead, it will immediately transfer the file to the AS/400 and create module and program objects. For example, the following compiler invocation: iccas test1.cpp test2.qwo will first compile the C++ source file test1.cpp by creating the intermediate compiler file then transfer that object to the AS/400 for the creation of the *MODULE object. After the *MODULE object is successfully created, the compiler will then transfer the intermediate test2.qwo file to the AS/400 where the test2 *MODULE object will be created.
In order to debug and test your code, you must be connected to the AS/400. You have a choice of using either the OS/400 C++ cooperative debugger or the OS/400 ILE source-level debugger. The cooperative debugger is used from the OS/2 workstation and has a GUI look and feel. The ILE source level debugger, on the other hand, lets you debug your program from a nonprogrammable terminal and has the advantage of allowing you to debug any ILE program.
Utility Commands for VisualAge C++
VisualAge C++ for OS/400 has included a set of commands that allow you to create the VisualAge Client Access connection and to issue commands from the OS/2 desktop that can be executed on the AS/400. The first of these is the OS/2 CTTCONN command. CTTCONN allows you to establish multiple connections to a single AS/400 or multiple connections to multiple AS/400s. The CTTCONN command starts a QSRCSRVR host server job on the AS/400. You will see this job if you run the Work with Active Jobs command (WRKACTJOB) under the QCMN subsystem. By default, these prestarted server jobs are reused, so it is recommended that you start with a clean QTEMP file and job log for your server session. You should also set the MAXUSE parameter for this QSRCSRVR job to 1. (The normal default value is 255.) Setting the MAXUSE parameter ensures that only one prestart job can be active at any time for this prestart entry. These changes can be made with the CHGPJE (Change Prestart Job Entry) command. These settings help to ensure a consistent startup state. If these parameters are not set correctly, you can occasionally get communication errors that cause startup of the host server job to fail, thus preventing your connection from starting. The QSRCSRVR job logs are useful to watch during module and program creation for indication of errors during the building process.
To query the AS/400 connections that have been established, the OS/2 command called CTTQCONN is provided. This command returns connection names and the status for each established communication session. CTTQCONN runs from the PC command line and has no parameters.
Two other useful commands provided with VisualAge C++ are the CTTEND and CTTDIS. CTTEND ends all host server connections and has no parameters. The CTTDIS command disconnects a specific AS/400 server connection. Entering CTTDIS ? on the command line of your OS/2 workstation will reveal the command’s parameters.
After establishing a connection to the AS/400 using CTTCONN, you may also use the VisualAge command called CTTHCMD. This integrated command sends a remote command directly to the host. Keying in CTTHCMD ? will return the command syntax. With this command, you can invoke AS/400 commands from your workstation. This command also allows VisualAge to compile programs from VisualAge Make files. Any command that can be executed from an AS/400 command line can be sent from the workstation using the CTTHCMD command. If for any reason an AS/400 command sent with CTTHCMD fails on the AS/400, an AS/400 error message will be displayed on your workstation.
Working with the Make Utility
VisualAge C++ for OS/2 has included the ability to use Make files. Make files help to simplify the tasks of managing projects and compiling programs and service programs, especially when a large number of modules are involved. The Make process is familiar to programmers who have worked in the UNIX environment. Visual-Age C++ for AS/400’s version of the Make utility is invoked with the NMAKE command. This VisualAge version of Make has most of the functionality of the UNIX versions of Make. To get command-line help when working with NMAKE, enter NMAKE /? on the command line.
Make files simplify the task of compiling programs, especially those with multiple source files. Make files save time by only performing actions on those source files that have changed. They accomplish this feat by comparing the target file date with the time stamp of the source file. When a source file has a later date than its target file, Make will run through a predefined series of tasks. As you might imagine, this scheme works very well when the source and targets are on the same workstation, but in a distributed environment, system times are rarely synchronized. To remedy this situation, VisualAge
has provided the CTTTIME command. With this command, you can synchronize the time between the AS/400 and your OS/2 workstation. CTTTIME will change the OS/2 workstation time to match that of the AS/400. Keep in mind that if your OS/2 workstation and the AS/400 are in different time zones, CTTTIME is probably not a good option. Changing the OS/2 workstation time in this case could throw off the synchronization with your LAN, or create havoc with other workstation applications.
Compiling with VisualAge C++ Utilities
Compiling a simple program or doing AS/400 tasks is a quick and easy process with the VisualAge C++ utilities. I will put the utilities I have talked about in this article together in a simple Make file to automate the creation of a physical file on the AS/400 using C++ utility invocations from the PC. This example Make file will assign a network drive to the AS/400, change the AS/400 current library, then create a physical file on the AS/400. The Make file shows how simple it is to run commands on the AS/400 with the VisualAge C++ utilities and how versatile the VisualAge C++ Make process can be.
The Make file (shown in Figure 1) TEST.MAK is started from the command line as follows:
NMAKE /F TEST.MAK
The processing of this make file is driven by the dot all (.all:) statement:
.all: $(_ALL_DIRS) STARTCONN NETASGN SETUPENV CREATEFILES NETREL ENDCONN
This all statement functions as a main routine with the targets (you can think of them as subroutines) listed in the order that they are to be executed. Similar to BASIC or AS/400 CL, a target is labeled with the target name and a colon. The STARTCONN target runs first, and once STARTCONN completes successfully, NETASGN executes and so on. This cycle continues until the tasks for the .all: target statement are completed. When STARTCONN is executed, a CTTCONN command is invoked to create a VisualAge connection to the AS/400. The NETASGN task invokes the NET400 command to assigns the N: drive to the AS/400. When SETUPENV runs, it changes the current library to TMPLIB, and the CTTTIME command synchronizes the PC time with the attached AS/400. The CREATFILES target sets the TARGET_FILES variable to contain the list of files to create.
In this case, only TMPILE will be created in the current library TMPLIB.VisualAge C++: More than Just a Compiler
As you can see, a VisualAge C++ installation on your AS/400 gives you a great deal more than a C++ compiler. It also gives you a set of tools for handling a full range of project tasks, from the automation of simple AS/400 tasks to the management of complex code compiles.
# *********************************************************************
# Simple Make file that builds a file on the AS/400
# *********************************************************************
AS400_FTP_ADDR=999.999.999.999
_AS400_CA_DIR=N:
_AS400_SERVER_NAME=Server1
_AS400_HOSTNAME=APPN.AS400
_AS400_FLIB=TMPLIB
_AS400_CS_LIB_PATH=qsys.lib$(_AS400_FLIB).lib
all: $(_ALL_DIRS) STARTCONN NETASGN SETUPENV CREATEFILES NETREL
ENDCONN
STARTCONN:
@echo Connect To Host
@CTTCONN /H$(_AS400_HOSTNAME) / ASn$(_AS400_SERVER_NAME)
NETASGN:
@echo Assigning $(_AS400_CA_DIR) to $(_AS400_CS_LIB_PATH)
@NET400 ASSIGN $(_AS400_CA_DIR) /p=$(_AS400_CS_LIB_PATH)
/h=$(_AS400_HOSTNAME)
SETUPENV:
@echo Synchronizing Time Between Computer and AS400
@CTTTIME /ASN$(_AS400_SERVER_NAME) SYNC
@echo Changing Curlib to $(_AS400_FLIB)
@$(_CTTHCMD) CHGCURLIB $(_AS400_FLIB)
# create the file tmpfile according to the rule below
CREATEFILES: $(_AS400_CA_DIR) tmpfile.file
# release the network drive
NETREL:
@NET400 RELEASE $(_AS400_CA_DIR)
# terminate the connection
ENDCONN: @CTTDIS /ASn$(_AS400_SERVER_NAME)
#target and rule for the creation of a file on the AS/400
$(_AS400_CA_DIR)tmpfile.file: @echo $@
@$(_CTT_CRPF) FILE($(@B)) RCDLEN(130)
#end of TEST.MAK make file
Figure 1: A Make file like this one can easily automate project tasks on the AS/400.
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