Smoke Testing:

Smoke testing is a term used in plumbing, woodwind repair, electronics, and computer software development. It refers to the first test made after repairs or first assembly to provide some assurance that the system under test will not catastrophically fail. After a smoke test proves that the pipes will not leak, the keys seal properly, the circuit will not burn, or the software will not crash outright, the assembly is ready for more stressful testing.
In computer programming and software testing, smoke testing is a preliminary to further testing, which should reveal simple failures severe enough to reject a prospective software release.
Smoke testing is done by developers before the build is released or by testers before accepting a build for further testing.
In software engineering, a smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection. Next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software; some even believe that it is the most effective of all.
In software testing, a smoke test is a collection of written tests that are performed on a system prior to being accepted for further testing. This is also known as a build verification test. This is a "shallow and wide" approach to the application. The tester "touches" all areas of the application without getting too deep, looking for answers to basic questions like, "Can I launch the test item at all?", "Does it open to a window?", "Do the buttons on the window do things?". There is no need to get down to field validation or business flows. If you get a "No" answer to basic questions like these, then the application is so badly broken, there's effectively nothing there to allow further testing. These written tests can either be performed manually or using an automated tool. When automated tools are used, the tests are often initiated by the same process that generates the build itself.
This is sometimes referred to as 'rattle' testing - as in 'if I shake it does it rattle?'.

Add some colors to your source:

Here's a tip many people may not be aware of. When we are coding the programs we put a lot of comments to explain logic or functionality, instead of putting these comments in green color, generally we will prefer to put them in different colors. We can add some colors to our program by using simple Client Access keyboard mapping.
o Click on the "MAP" button.
o Click on any key, for example I want to map my ALT + R for red color.
o So click on R and type APL 28 in the box provided against Alt and save the settings.
o Now go to the source line, which you want to make in RED. Put your cursor just before the first word of the line and press ALT + R and enter, the source line will be displayed red in color.
By using this technique we can change the colors for member text too. Take option 13 and F4 for member you want to change the color first, then put your cursor just before the first letter in the text and press corresponding color key and press enter. Now you can see your member text will be displayed in different color.
For different colors follow this table:
APL 20 - Green
APL 21 - Green RI
APL 22 - White
APL 23 - White RI
APL 24 - Green UL
APL 25 - Green RI UL
APL 26 - White UL
APL 27 - ND
APL 28 - Red
APL 29 - Red RI
APL 30 - Turquoise
APL 31 - Turquoise RI
APL 32 - Yellow
APL 33 - Yellow RI
APL 34 - Turquoise UL
APL 35 - Turquoise UL RI
APL 36 - Yellow UL
APL 38 – Pink
APL 39 – Pink RI
APL 3a – Blue
APL 3b - Blue RI
APL 3c – Pink UL
APL 3d – Pink UL RI
APL 3e – Blue UL
APL 2a – Red Blinking
APL 2b – Red RI Blinking
APL 2c – Red UL
APL 2d – Red UL RI
APL 2e – Red UL Blinking

Useful TAATOOL Commands:

Some useful TATOOL commands:

DSPWINDOW:

The Display Window command displays a window over the current display. The intent of the command is to provide for a better informational display in exception conditions. Ten lines of text may be presented plus an error line. The command ends normally if the user presses Enter, F3, or F12. A single F key (such as F4 - F24) may be defined with user supplied text.

By default, the window will appear on the right side of the current display beginning in position 43 and extending to position 79. It starts on line 2 and ends on line 20.

Escape messages:

TAA9891 F key was pressed (based on FKEY parameter)

Restrictions

The display currently in use when DSPWINDOW is run must be specified as RSTDSP (*YES).

Example:

DSPWINDOW TITLE('Error Occurred')
LINE1('The record you want to delete')
LINE2(' no longer exists.')
LINE4('It has been deleted by another')
LINE5(' user.')
LINE7('Press Enter to continue to the') +
LINE8(' next record.')


PMTOPR:

The PMTOPR command places a prompt on the users display and allows validity checking of the response. This is useful in some environments where a specific input value is needed before proceeding into some further processing (e.g. some System Operator functions). The prompt is always made to the requester (the command must occur from an interactive program).

The advantage of this command is:

• PMTOPR can simplify the amount of code needed to validate the entry of a parameter. The coding required to properly use SNDUSRMSG includes checking for a blank entry, additional processing for simple validations and looping back on an error etc. is not simple.

• PMTOPR can provide a standard means of communicating with the operator when a single value is needed.

For example, the programmer could specify in a CL Program:

DCL &RTNVAR *CHAR LEN(16)
.
.
PMTOPR RTNVAR(&RTNVAR) +
LEN(10) +
PROMPT('Enter the file name to be processed by the BILLING function') +
TYPE(*NAME)
OVRDBF INPUT TOFILE(&RTNVAR)
CALL ....


The PMTOPR command would ensure that an entry was made, that it was a valid name (e.g. Did not start with a digit) and that it did not exceed 10 characters. If an invalid entry is made, an appropriate error message is displayed. The operator must enter a valid name (i.e. A command key or a blank value will be rejected). Note that the operator must respond. The default is that F3=Exit is not allowed. It would also be possible to enter a list of values that the operator can enter and/or a default. For example, the command could have been entered as:

PMTOPR RTNVAR(&RTNVAR) +
LEN(10) +
PROMPT('Enter the file name to be processed +
by the BILLING function') +
TYPE(*NAME) +
DFT(NEWORDER) +
VALUES(NEWORDER OLDORDER PREBILL BACKORDER)

Handy Keyboard Shortcuts:

Everyone knows that Alt+Ctrl+Del interrupt the operating system, but most people don't know that many of the handy commands.
• Alt+F4 closes the current window.
• Ctrl+Esc will pop up the Start menu,
• Alt+Esc will bring the next window to the foreground,
• Alt+Tab or Alt+Shift+Tab will let you cycle through all available windows and jump to the one you select.
On keyboards that have the little "Windows" key down near the space bar, you probably know that you can press that key to open the Start menu. You can also use that key with other keys like you use the shift key. For example:
• Windows Logo: Start menu

• Windows Logo+R: Run dialog box

• Windows Logo+M: Minimize all

• SHIFT+Windows Logo+M: Undo minimize all

• Windows Logo+F1: Help

• Windows Logo+E: Windows Explorer

• Windows Logo+F: Find files or folders

• Windows Logo+D: Minimizes all open windows and displays the desktop

• CTRL+Windows Logo+F: Find computer

• CTRL+Windows Logo+TAB: Moves focus from Start, to the Quick Launch toolbar, to the system tray (use RIGHT ARROW or LEFT ARROW to move focus to items on the Quick Launch toolbar and the system tray)

• Windows Logo+TAB: Cycle through taskbar buttons

• Windows Logo+Break: System Properties dialog box

• Application key: Displays a shortcut menu for the selected item

Useful TAATOOL Commands:

Some CL commands that can be used in routine work. TAATOOL commands

Prerequisites

The following TAA Tools must be on your system

CHKOBJ2:

The Check Object 2 command is similar to the system command CHKOBJ except that CHKOBJ2 sends an escape message if the object 'is found'. The intent of the command is to simplify coding when it is considered an error if the object exists. CHKOBJ2 sends message ID TAA9891 as an escape message if the object exists. If the object does not exist, no message is sent.

Parameters required:

Object (OBJ)

The qualified object name. The library value defaults to *LIBL. *CURLIB may also be specified.

Object type (OBJTYPE)

The object type to be checked. Any value that is valid on CHKOBJ may be used.

CHKOBJ2 escape messages you can monitor for:

TAA9891 Object exists.


Example: CHKOBJ2 OBJ(Name) OBJTYPE(*PGM).


WRKF2:

The Work File 2 command provides a subfile with options to display the attributes, relations, format, and data of a file. In addition, there are options to change,edit, clear, and delete a file

Parameters required:

FILE : The qualified name of the file to be worked with. A generic name or *ALL may be entered. The library value defaults to *LIBL. *CURLIB, *ALL, or *ALLUSR may also be entered


Restrictions

Only a single member file may be deleted.

Example:

WRKF2 FILE(Filename)

The Different Views of Quality by Quality Gurus

Industry accepted definitions of quality are

a. “Conformance to Requirements” stated by Philip Crosby
b. “Fit for Use” stated by Dr. Joseph Juran and Dr. W. Edwards Deming

These two definitions are not inconsistent.

The Two Quality Gaps

Most Information Technology (IT) groups have two quality gaps: the Producer gap and the Customer gap.

The producer gap is the difference between what is specified (the documented requirements and internal standards) versus what is delivered (what is actually built).
The customer gap is the difference between what the producers actually delivered versus what the customer wanted.

Quality Control and Quality Assurance

How to recognize a control practice from an assurance practice?

Quality means meeting requirements and meeting customer needs, which means a defect-free product from both the producer’s and the customer’s viewpoint. Both quality control and quality assurance are used to make quality happen. Of the two, quality assurance is the more important.

Quality Assurance (QA) is associated with a process. Once processes are consistent, they can "assure" that the same level of quality will be incorporated into each product produced by that process.

QC is an activity that verifies whether or not the product produced meets standards.
QA is an activity that establishes and evaluates the processes that produce the products.

If there is no process, there is no role for QA. Assurance would determine the need for, and acquire or help install system development methodology, estimation processes, system maintenance processes, and so forth.
Once installed, QA would measure them to find weaknesses in the process and then correct those weaknesses to continually improve the processes.

It is possible to have quality control without quality assurance.

The following statements help differentiate QC from QA

QC relates to a specific product or service.
QC verifies whether particular attributes exist, or do not exist, in a specific product or service.
QC identifies defects for the primary purpose of correcting defects.
QC is the responsibility of the worker.

QA helps establish processes.
QA sets up measurement programs to evaluate processes.
QA identifies weaknesses in processes and improves them.
QA is a management responsibility, frequently performed by a staff function.
QA evaluates whether or not quality control is working for the primary purpose of determining whether or not there is a weakness in the process.
QA is concerned with all of the products that will ever be produced by a process.
QA is sometimes called quality control over quality control because it evaluates whether quality control is working.
QA personnel should not ever perform quality control unless doing it to validate quality control is working.

Constraints

There are three types of constraints: key constraints, foreign key constraints, and check constraints.
· A key constraint is used to prevent duplicate information on a table. This corresponds to first normal form for a relational database (define the key). Key constraints are a prerequisite for foreign key constraints.
· A foreign key constraint (also referred to as referential integrity) defines a relationship between two tables: a dependant and a parent. A foreign key constraint ensures that rows may not be inserted in the dependant table if there isn't a corresponding row in the parent table. It also defines what should be done if a row in the parent table is changed or deleted (more details in a moment).
· A check constraint defines the rules as to which values can be placed in a column.

There are commands available for dealing with constraints on AS/400 (ADDPFCST, CHGPFCST, DSPCPCST, EDTCPCST, RMVPFCST, WRKPFCST), or you can define them in SQL using the CREATE TABLE or ALTER TABLE commands.
But by far the easiest ways of handling constraints is using the Database function in iSeries Navigator.
You can define constraints by selecting Database > System > Schemas > Your Schema > Tables. (In case you are not yet familiar with SQL terminology, a schema is a library and a table is a physical file.) Right-click on a table name and select Definition; the resulting window contains a tab for each type of constraint. On each of these tabs, you have options for Add, Remove, and Definition. The Definition option simply shows you the definition of the constraint; in order to change the definition of a constraint, you must remove it and add it again.

Hidden Secrets of SBMJOB Command:

Most people use the OS/400 Submit Job (SBMJOB) command for batch processing. But SBMJOB has other powers that help to increase the capabilities of batch jobs.

SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB)
This way OS/400 submits the job for execution based on the configuration of the user running the command. The job runs under the user profile of the submitting user, it uses the job description assigned to the submitting user, it's submitted to the job queue associated with the assigned job description, and it uses the scheduling and output queue priorities assigned to its job description.
There are lots of times when you need to change the defaults and modify the operating parameters of a submitted job.

For instance, you can submit your job to run under another user profile by modifying the USER parameter of a SMBJOB statement in the following manner:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TEST) USER(NEWUSER)
For this command to work, the submitting user must be authorized to the user profile assigned to the batch job. When submitted this way, the submitted job also uses the job description associated with the new user profile. The job queue, run priority, and output priority values then take their values from the new job description.
You can also submit the job to a job queue other than that associated with the job description.
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TEST)
JOBQ(QSYS/QSYSNOMAX) USER(NEWUSER)

Server jobs can be submitted to the QSYS/QSYSNOMAX job queue because it feeds into the QSYSWRK subsystem, which runs a lot of OS/400's server jobs, including many of its TCP/IP jobs. A second advantage to using QSYSNOMAX is that the QSYSWRK subsystem will accept and run an unlimited number of jobs originating from the QSYSNOMAX job queue (unlike the QBATCH subsystem, which typically runs only a few jobs at once). This means it's a great place to put any additional server jobs that you add to the system.

In addition to changing user profiles and job queues, you can set SBMJOB parameters to change the system library list for the job (the SYSLIBL parameter on the command), the current library for the job (the CURLIB parameter), and the job's initial library list (INLLIBL).

If you want to log all the CL commands that are executed in your batch job to the job's job log, set the Log CL program (LOGCLPGM) command parameter to *YES, like this:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) LOGCLPGM(*YES)
If you want to submit the job so that it is held on the job queue, use the Hold on job queue (HOLD) parameter:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) HOLD(*YES)
If you want to use SBMJOB to schedule a job to start at a certain date and time, use the Schedule date (SCDDATE) and Schedule time (SCDTIME) parameters.
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB)
SCDDATE('11/01/03') SCDTIME('10:00:00')
These jobs are placed on the job queue in a scheduled (Scd) status, and they will not run until the appointed time. If an unscheduled job is submitted to the same job queue, it will run ahead of the scheduled jobs.
Another neat trick is that you can hide submitted jobs from the Work with Submitted Jobs (WRKSBMJOB) command. To do this, set the Allow Display by WRKSBMJOB (DSPSBMJOB) parameter to *NO, and submit your job in the following manner:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) DSPSBMJOB(*NO)
If a user tries to view the progress of this job by using the WRKSBMJOB command, he won't be able to see it. Note, however, that users can still see the running job by finding it on the Work with Active Jobs (WRKACTJOB) command display or on the Work with Subsystem Jobs (WRKSBSJOB) command display.
If you don't want operators to answer predefined inquiry messages that appear during batch processing, you can set SBMJOB's Inquiry Message Reply (INQMSGRPY) parameter to tell the job how to answer messages. If you use the default, the job will use the inquiry message control value found in its corresponding job description. However, if you want your batch job to use default reply values for inquiry messages, you can submit the job with its INQMSGRPY value set to *DFT, like this:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) INQMSGRPY(*DFT)

And the final SBMJOB trick is to change the message queue to which SBMJOB sends its job completion messages. You have three choices. By default, job messages are sent to the message queue that is specified in the user profile that the job runs under. If you want to do it manually, you change the Message Queue (MSGQ) parameter of the SBMJOB statement, as follows:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*USRPRF)
But if you want to change that message queue so that your messages go to the message queue of the workstation the job was submitted from, you set MSGQ to *WRKSTN and your SBMJOB statement would look like this:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*WRKSTN)
And if you want to suppress the completion message altogether, change MSGQ to *NONE and the job won't send out completion messages at all:
SBMJOB CMD(CALL PGM(PROGRAM)) JOB(TESTJOB) MSGQ(*NONE)

Cost of Quality:

It’s a term that’s widely used – and widely misunderstood.
The “cost of quality” isn’t the price of creating a quality product or service. It’s the cost of NOT creating a quality product or service.
Quality costs are the total of the cost incurred by:
• Investing in the prevention of nonconformance to requirements.
• Appraising a product or service for conformance to requirements.
• Failing to meet requirements.
Prevention Cost:
The costs of all activities specifically designed to prevent poor quality in products or services.
Examples are the costs of:
• New product review
• Quality planning
• Supplier capability surveys
• Process capability evaluations
• Quality improvement team meetings
• Quality improvement projects
• Quality education and training
Appraisal Costs
The costs associated with measuring, evaluating or auditing products or services to assure conformance to quality standards and performance requirements.
These include the costs of:
• Incoming and source inspection/test of purchased material
• In-process and final inspection/test
• Product, process or service audits
• Calibration of measuring and test equipment
• Associated supplies and materials
Failure Costs
The costs resulting from products or services not conforming to requirements or customer/user needs. Failure costs are divided into internal and external failure categories.
Internal Failure Costs
Failure costs occurring prior to delivery or shipment of the product, or the furnishing of a service, to the customer.
Examples are the costs of:
• Scrap
• Rework
• Re-inspection
• Re-testing
• Material review
• Downgrading
External Failure Costs
Failure costs occurring after delivery or shipment of the product -- and during or after furnishing of a service -- to the customer.
Examples are the costs of:
• Processing customer complaints
• Customer returns
• Warranty claims
• Product recalls
Total Quality Costs:
The sum of the above costs. This represents the difference between the actual cost of a product or service and what the reduced cost would be if there were no possibility of substandard service, failure of products or defects in their manufacture.

Start QINTER Remotely:

You must have the FTP server up and running on the iSeries.
From the start menu, follow these steps:
• Start
• run
• ftp
From FTP, follow these steps:
• open rmtsys
• user id
• password
• quote rcmd strsbs qinter
• quit
Or, if you have the host servers running on your iSeries system - STRHOSTSVR SERVER(*ALL), and have Client Access installed on your workstation you might try this approach:
• Start
• Run
• rmtcmd strsbs qinter //rmtsys
Where rmtsys is the IP address or name of your iSeries system.

Basic HTML Tags:

There are really only a few HTML tags (think DDS keyword) that are used over and over on 99 percent of all Web pages. Once we learn them we can do pretty much anything with a web page. Using this we can learn how to take the existing DDS screens and convert them so that they'll run in a Web browser, using the CGI APIs.

Creating a Static HTML Page with Text Formatting:
A basic HTML page consists of opening '(HTML)' and closing '(/HTML)' HTML tags. All the relevant contents need to be placed between these tags.

Adding Text:
Type the following text into Notepad document (or any other text you like):

I am a great HTML programmer!

Click on the Notepad menu item named File, then select Save. When the Save window appears, name your file MYHTML.htm and click on the OK button. This will save your file as an HTML file. You could also have chosen to save it with an HTML extension rather than HTM; most browsers can handle either one.
To view your HTML document, use Windows Explorer to navigate to the folder you saved the MYHTML.htm file into, find this file, and then double click on it. The default Windows browser should open, displaying your new HTML document.

Formatting Text:
Add the following tags:
I am a great HTML programmer!

The tags tell HTML to bold everything between the beginning () and ending () bold tags.
The tags tell HTML to underline everything between the beginning () and ending () underline tags.
The tags tell HTML to italicize everything between the beginning () and ending () italics tags.
The centertags tell HTML to center everything between the beginning ( ) and ending () center tags.

Creating Table:
HTML tables, at their most basic, are very simple to create. An HTML table consists of an opening ' 'tag and a closing ' 'tag. Within the tags, you will create table rows by using the ' and 'tags. To add data elements to a row, use the ' 'tags (which stand for table data). To add a border to your table, so that it appears as if it's in a box, use the'

and

'parameter on the ' 'tag. The format is border="x", where x is a numeric value that specifies the border width. If you make the width "0" or leave the border keyword off, the table will not have a border. And, finally, to add column headings to your table, use the table heading' ( )' tags.
Using Notepad, add the following HTML code to your document:

'

Item#	Quantity	Price
A56778	15	17.34
B65657	68	19.87

'
Adding an Image:
To tell a browser where to find a non-text item, such as an image, you have to include a special tag () that includes a parameter (src=) that tells the browser where the non- text item can be found. In other words, the tag tells the browser the HTTP address, or URL, of the image file.
''

Adding Hyperlinks:
Links allow you to provide a way for your users to jump from one Web page to another. Links, like all other HTML functions, have their own special tag. That tag is , which stands for "anchor." Every anchor tag contains a parameter that tells the browser where to take the user when he clicks on that link. The parameter "href=" points to the physical location (that is, the HTTP address, or URL) of the HTML page.
'The archival of AS/400 Team’s Concept for the Day!'

' '

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