Alpha and Beta Testing:

Typically, software goes through two stages of testing before it is considered finished. The first stage, called alpha testing, is often performed only by users within the organization developing the software. The second stage, called beta testing, generally involves a limited number of external users.

Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing.

Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.

Interesting V6R1 CL Enhancement:

Few interesting enhancements for CL in the V6R1 release.

Close a File:
CL includes a new Close Database File (CLOSE) command that we can use to close a file. This gives another way to process a file more than once in a CL procedure. The first Receive File (RCVF) command issued against a file opens that file and retrieves the first record. Each subsequent RCVF command retrieves another record, and when there are no more records to retrieve, RCVF issues escape message CPF0864. If we CLOSE a file, RCVF re-opens the file and begins the process anew. CLOSE has only one parameter, OPNID, which indicates the file to be closed.

Example:
DCLF FILE(*LIBL/MYFILE2) OPNID(FILE2)
:
RCVF OPNID(FILE2)
:
CLOSE OPNID(FILE2)
RCVF OPNID(FILE2)
:

Copy Source Code from Other Members:
The new Include CL Source (INCLUDE) command is similar in function to RPG's /COPY and /INCLUDE directives, COBOL's COPY command, and C's #INCLUDE preprocessor directive. To make the compiler a source member, fill in the SRCMBR and SRCFILE parameters.

This command copies member SUBR1, which is in source physical file COMMONSUBR in library MYLIB.

INCLUDE SRCMBR(SUBR1) SRCFILE(MYLIB/COMMONSUBR)

Store Compiler Options:
In CL procedures, we can use the Declare Processing Options (DCLPRCOPT) command to specify compiler options.

DCLPRCOPT DFTACTGRP(*NO) ACTGRP(MYAPP) +
BNDDIR(MYAPPLIB/MYBNDDIR)

Grey Box Testing:

Grey Box testing is technique that uses a combination of Black box and White box testing. Grey Box testing is not Black box testing, because the tester does know some of the internal workings of the software under test.

In Grey box testing, the tester applies a limited number of test cases to the internal workings of the software under test. In the remaining part of the Grey box testing, one take black box approach in applying inputs to the software under test and observing the outputs.

The typical gray box tester is permitted to set up his testing environment,
like seeding a database, and can view the state of the product after their
actions, like performing a SQL query on the database to be certain of the
values of columns. It is used almost exclusively of client-server testers or
others who use a database as a repository of information.

CL-Like Error Handling in RPG:

Most CL programs handle errors significantly better than RPG programs. CL handles errors better, because, it's extremely easy to trap and handle errors in CL through MONMSG. In RPG, the program and file information data structures provide error information, and the *PSSR subroutine and %STATUS built-in function can be used to trap and handle that information, but that isn't enough.

In V5R1, IBM has given RPG the capability to handle errors much the way CL does. Three new operation codes were added to RPG in V5R1 to perform kicked-up error handling: MONITOR, ON-ERROR, and ENDMON.

The MONITOR op code is used to begin error monitoring. Once the MONITOR operation is entered, the program monitors all C-specifications between it and the ENDMON operation. When a program or file exception is encountered on any statement within the monitor block, control is passed to the appropriate ON-ERROR operation, and the logic within that ON-ERROR section is performed. If all the statements within the monitor block complete successfully, control is then passed to the statement following the ENDMON operation.

The ON-ERROR operation acts much like the WHEN operation, Each ON-ERROR statement is followed by one or more statements that will execute when that specific ON-ERROR block is triggered. The block is ended when another ON-ERROR or the ENDMON statement is reached.

Any C-specifications coded after the ENDMON operation will not be trapped.

For each monitor block, at least one ON-ERROR operation must be present. The ON-ERROR operations must be coded in the same routine as the MONITOR and ENDMON operations. For example, we cannot code a MONITOR and ENDMON in the mainline and place the ON-ERROR statements in a subroutine that is called within the monitor block.

Experimental Software Engineering:

Experimental software engineering is a sub-domain of software engineering focusing on experiments on software systems (software products, processes, and resources). It is interested in devising experiments on software, in collecting data from these experiments, and in devising laws and theories from this data. Proponents of experimental software engineering advocate that experimentation is an important method in contributing to accumulation of knowledge in software engineering.
Empirical software engineering is a related concept, sometimes used synonymously with experimental software engineering. Empirical software engineering is a field of research that emphasizes the use of empirical studies of all kinds to accumulate knowledge. Methods used include experiments, variety of case studies, surveys, and statistical analyses.
The scientific method suggests a cycle of observations, laws, and theories to advance science. Experimental software engineering applies this method to software.

Five cool things you can do with OpsNav:

V5R1 of Client Access Express Operations Navigator allows you to perform so many functions. Few of the most important functions are discussed below.

1. Copy Spool file to your Desktop
Double-click on the Basic Operations tree, in the left-hand pane of the OpsNav GUI. Next, click on Printer Output. If the user profile with which you are logged on to OpsNav has any associated spool files on the iSeries, they will appear in the right-hand pane of the OpsNav GUI.
To copy the iSeries spool file to your PC's desktop, you can do one of two things:
• You can right-click on a spool file in the right-hand pane of the OpsNav GUI and select COPY from the pop-up menu. Next, right-click on your PC's desktop and select Paste from the pop-up menu. The spool file will be copied to your desktop.
• Your other option is to click once on the spool file in the right-hand pane of the OpsNav GUI to select a file. While holding the left mouse button down, drag the spool file to your PC's desktop. The spool file will be copied to your desktop.

2. Create an OpsNav Shortcut to frequently used item
You can create a shortcut to any OpsNav item and store it on your PC's desktop very easily. Then, each time you want to use a function, such as changing the properties of the Telnet server, all you'll need to do is click on the shortcut itself rather than drilling down through the OpsNav tree.
To create a shortcut, click on any OpsNav item, such as the TCP/IP tree item found under Network/Servers/, and drag that item to your PC's desktop. When you let go of the left mouse button, you will be prompted to create a shortcut. Select this menu item and a shortcut to the TCP/IP servers will now exist on your desktop.
3. Edit Privileges for FTP users
To edit FTP privileges for individual users
• In OpsNav, expand the Users and Groups tree item.
• Click on the All Users tree item.
• Right-click on a user profile whose FTP privileges you wish to edit, and select Properties from the pop- up menu.
• On the Properties panel for that user, click on the Capabilities button.
• Click on the Applications tab.
• Click on the down arrow next to Access for.
• Select Host Applications.
• Expand the AS/400 TCP/IP Utilities tree item.
• Expand File Transfer Protocol (FTP).
• Expand FTP Server.
• Expand Specific Operations.
Place a check mark in those FTP actions you want this user to be able to perform, and uncheck the ones you don't want the user to be able perform
4. Generate SQL from a Logical File
• Expand the Database tree item in OpsNav.
• Click on Database Navigator.
• In the taskpad, at the bottom of the OpsNav GUI, double-click the Map your Database wizard. (If you don't see the taskpad at the bottom of your OpsNav GUI, click on the OpsNav menu item View and select the TaskPad option.)
• In the Database Navigator Map wizard, you'll see a list of iSeries libraries. Expand this list until you find the library containing the physical or logical file you want to generate the SQL from.
• Expand Indexes and then Views, under the Tables tree item.
• Select the Index (logical file) you want to generate the SQL from.
• Right-click on that logical file and select Generate SQL from the pop-up menu

You can now view the SQL that will create that logical file, or even modify it and run it if you wish.

5. Configure iSeries security using the Security Wizard
• Expand the Security tree item in the OpsNav GUI.
• Double-click the Configure the Security of this Server wizard item in the taskpad.
The AS/400 Security wizard will appear. You can now step through a series of easy and understandable questions about how you use your iSeries. When you're finished, you will be presented with a set of recommendations you can use to best protect your system. Even better, if you so desire, you can immediately apply these changes to your system

SQL SET OPTION Statement:

SQL's SET OPTION statement is a powerful way to control the parameters of the DB2 execution environment in which an SQL program runs.

SET OPTION is a statement that is evaluated at "compile time." It never actually gets executed. Therefore SET OPTION can only be specified once in a program. In embedded SQL, it should be the first SQL statement in the program. (For ILE RPG programmers, this is similar to specifying compile time options in the H spec.) For SQL routines (triggers, functions and stored procedures) SET OPTION is actually implemented as a clause in the various CREATE statements.

Few important things that can be controlled by SET OPTION are,
• CLOSQLCSR (Close SQL Cursor)
• COMMIT
• DATFMT (Date Format)
• DBGVIEW (Debug View)
• DFTRDBCOL (Default Relational Database Collection)
• DLYPRP (Delay Prepare)
• DYNUSRPRF (Dynamic User Profile)
• USRPRF (User Profile)

Here is an example of how they are specified in an RPG embedded SQL program:

C/Exec SQL
C+ Set Option Commit=*NONE, DatFmt=*ISO, CloSqlCsr=*ENDMOD, DlyPrp=*YES
C/End-Exec