Wednesday, April 30, 2008

Call of the Prototype:

A lot of RPG programmers are under the misconception that the CALLP operation means Call Procedure. That is because most of them come across it when they start using subprocedures. But CALLP means Call a Prototyped Procedure or Program, and it can be used in place of the CALL operation, as well as CALLB.
What's wrong with CALL and PARM?
In RPG all parameters are passed by reference. That means a pointer to the parameter is passed, not the actual value of the parameter. That, in turn, means both the passed and receiving parameter fields share the same memory location, and that is where the potential problem lies.
Figure 1 shows the code of a calling program. It calls PGMB passing Parm1, a 10 character field, as a parameter.
D TestParm DS
D Parm1 10 Inz('XXXXXXXXXX')
D Parm2 10 Inz('YYYYYYYYYY')

C Call 'PGMB'
C Parm Parm1
Figure 1: A program call with a parameter field in a data structure
Figure 2 shows the code of the called program. It has an incorrect length of 15 for Parm1.
Will the compiler tell us that it is invalid? No.
Will the program fail at run time? No.
What will happen? When control returns to the calling program, Parm1 will have a value of 'ZZZZZZZZZZ' and Parm2 will have a value of 'ZZZZZYYYYY'.
When the compiler sees a CALLP operation, it will validate to ensure that all the parameters are correct. But how does it know that the parameters are correct? You provide a prototype. A prototype is the format, or the template, or the rules, for the call operation. It is not a parameter list.
Prototypes are defined on the D specifications, as shown in Figure 3. The format of a prototype is very similar to a data structure, except that the type is PR as opposed to DS. You can provide your own name for the CALLP (PromptProduct). The EXTPGM keyword indicates that this is the equivalent of a CALL operation, and it identifies the name of the called program (PRP01R). The names of the subfields in the prototype are irrelevant, what are important are the number of subfields (i.e. parameters) and the definition of each. In the example in Figure 3 the compiler will ensure that two parameters are passed, that Parm1 is a 30 character field and that Parm2 is a 1 character field.
D PromptProduct PR ExtPgm('PRP001R')
D FirstParm 30
D SecondParm 1

C CallP PromptProduct(Parm1:Parm2)

Other features of prototype like ‘CONST’, ‘*OMIT’, ‘*NOPASS’ easy the coding process.

Monday, April 28, 2008

IP Address:

An IP address (or Internet Protocol address) is a unique address that certain electronic devices use in order to identify and communicate with each other on a computer network utilizing the Internet Protocol standard (IP)—in simpler terms, a computer address. Any participating network device—including routers, switches, computers, infrastructure servers (e.g., NTP, DNS, DHCP, SNMP, etc.), printers, Internet fax machines, and some telephones—can have its own address that is unique within the scope of the specific network. Some IP addresses are intended to be unique within the scope of the global Internet, while others need to be unique only within the scope of an enterprise.
IP addresses are managed and created by the Internet Assigned Numbers Authority (IANA). The IANA generally allocates super-blocks to Regional Internet Registries, who in turn allocate smaller blocks to Internet service providers and enterprises.
The Internet Protocol (IP) has two versions currently in use (IPv4 and IPv6). Each version has its own definition of an IP address. Because of its prevalence, "IP address" typically refers to those defined by IPv4. IPv4 only uses 32-bit (4-byte) addresses, which limits the address space to 4,294,967,296 (232) possible unique addresses. IPv6 is a new standard protocol intended to replace IPv4 for the Internet. Addresses are 128 bits (16 bytes) wide, which, even with a generous assignment of net blocks, will more than suffice for the foreseeable future. In theory, there would be exactly 2128, or about 3.403 × 1038 unique host interface addresses.
When a computer uses the same IP address every time it connects to the network, it is known as a Static IP address. In contrast, in situations when the computer's IP address changes frequently (such as when a user logs on to a network through dialup or through shared residential cable) it is called a Dynamic IP address.
IP addresses can appear to be shared by multiple client devices either because they are part of a shared hosting web server environment or because an IPv4 network address translator (NAT) or proxy server acts as an intermediary agent on behalf of its customers, in which case the real originating IP addresses might be hidden from the server receiving a request.

Selective Prompting for CL Commands:

You can request to prompt for selected parameters within a command. This is especially helpful when you are using some of the longer commands and do not want to be prompted for certain parameters.

Selective Prompting Character Description
?? The parameter is displayed and input-capable.
?* The parameter is displayed but is not input-capable. Any user-specified value is passed to the command processing program.
?< The parameter is displayed and is input-capable, but the command default is sent to the CPP unless the value displayed on the parameter is changed.
?/ Reserved for IBM use.
?– The parameter is not displayed. The specified value (or default) is passed to the CPP. Not allowed in prompt override programs.
?& The parameter is not displayed until F9=All parameters is pressed. Once displayed, it is input-capable. The command default is sent to the CPP unless the value displayed on the parameter is changed.
?% The parameter is not displayed until F9=All parameters is pressed. Once displayed, it is not input-capable. The command default is sent to the CPP.


Example

OVRDBF ?*FILE(FILEA) ??TOFILE(&FILENAME) ??MBR(MBR1)

Above. You can see the FROM file name but cannot change it but both TO file and MEMBER may be changed.

Thursday, April 24, 2008

Failure Mode and Effects Analysis:

A Failure mode and effects analysis (FMEA) is a procedure for analysis of potential failure modes within a system for the classification by severity or determination of the failure's effect upon the system. It is widely used in the manufacturing industries in various phases of the product life cycle. Failure causes are any errors or defects in process, design, or item especially ones that affect the customer, and can be potential or actual. Effects analysis refers to studying the consequences of those failures.

Types of FMEA:
• Process: analysis of manufacturing and assembly processes
• Design: analysis of products prior to production
• Concept: analysis of systems or subsystems in the early design concept stages
• Equipment: analysis of machinery and equipment design before purchase
• Service: analysis of service industry processes before they are released to impact the customer
• System: analysis of the global system functions
• Software: analysis of the software functions

Implementation:
In FMEA, Failures are prioritized according to how serious their consequences are, how frequently they occur and how easily they can be detected. A FMEA also documents current knowledge and actions about the risks of failures, for use in continuous improvement. FMEA is used during the design stage with an aim to avoid future failures. Later it is used for process control, before and during ongoing operation of the process. Ideally, FMEA begins during the earliest conceptual stages of design and continues throughout the life of the product or service.
The purpose of the FMEA is to take actions to eliminate or reduce failures, starting with the highest-priority ones. It may be used to evaluate risk management priorities for mitigating known threat-vulnerabilities. FMEA helps select remedial actions that reduce cumulative impacts of life-cycle consequences (risks) from a systems failure (fault).
Advantages:
• Improve the quality, reliability and safety of a product/process
• Improve company image and competitiveness
• Increase user satisfaction
• Reduce system development timing and cost
• Collect information to reduce future failures, capture engineering knowledge
• Reduce the potential for warranty concerns
• Early identification and elimination of potential failure modes
• Emphasis problem prevention
• Minimize late changes and associated cost
• Catalyst for teamwork and idea exchange between functions

Wednesday, April 23, 2008

*PSSR:

In RPG, there are Program Exception/Errors (divide by zero, array index error, etc.)
and File Exception Errors (any file error). As with MONMSG in CL, you can trap errors
at the program level or the command level.

Program Exceptions:
If a program encounters a program error, it checks to see if there is a *PSSR subroutine coded in the program. If there is, it executes the subroutine. If there isn't, the program "fails" with an error message.
A *PSSR subroutines may be executed like any other subroutine (using ExSR or CASxx). The EndSR for a *PSSR subroutine can contain a return-point instruction.
The following return-point operands can be specified on the EndSR operation for a
*PSSR subroutine, but most of them apply only if you are using the RPG cycle.
• *DETL. Continue at the beginning of detail output lines
• *GETIN. Input Record Routine
• *TOTC. Total Time Calculations
• *TOTL. Continue at the beginning of total output lines
• *OFL. Continue at the beginning of overflow lines
• *DETC. Continue at the beginning of detail calculations.
• *CANCL. Cancel the Execution of the program
• Blank. Return control to the RPG default error handler. If the subroutine was
called by the EXSR operation and factor 2 is blank, control returns to the next
sequential instruction.
When *PSSR is invoked by an error, it does not return to the statement in error. It
should be used as an exit from the program.
File Exceptions:
Just as the program has an error handling subroutine in *PSSR, each file that you define on an F spec can also have its own error handling subroutine, identified by the INFSR keyword. Each file can have its own subroutine or a subroutine can be shared between different files.
These subroutines act in exactly the same way as *PSSR, so why not use the *PSSR
subroutine? Below is an example of INFSR being defined on the F specs.
FDisplay CF E WorkStn InfSR(*PSSR)

FCustomer UF E K Disk InfSR(*PSSR)
Now, if there is an I/O error with a file, the *PSSR subroutine will be executed.
Well, not quite. The INFSR subroutine will trap all I/O errors except file open errors.
The RPG cycle is automatically opening the files before the code is loaded, therefore it cannot execute *PSSR if there is a problem during file open (e.g., level check).
To trap file open errors, you need to perform an implicit open of the file by
specifying conditional open for the file (USROPN keyword on F Spec) and use the
OPEN operation to open the file (usually coded in the *INZSR subroutine).

Error Status Codes:

There are various ways to trap errors in a RPG program like, Operation code extender, MONITOR, INFDS and *PSSR. Once the program has trapped the error, but which error is it? The %STATUS BIF provides a five-digit status code that tells you what the error is. Program Status Codes are in the range 00100 to 00999 and File Status Codes are in the range 01000 to 01999. Status Codes in the range 00000 to 00050 are considered to be Normal (i.e. they are not set by an error condition).
Status codes correspond to RPG Run time messages file in QRNXMSG (e.g., Message RNQ0100 = Status Code 00100). You can view the messages using the command:
DSPMSGD RANGE(*FIRST *LAST) MSGF(QRNXMSG) DETAIL(*BASIC)
The below table lists some of the more commonly used Status Codes.
00100 Value out of range for string operation
00102 Divide by zero
00112 Invalid Date, Time or Timestamp value.
00121 Array index not valid
00122 OCCUR outside of range
00202 Called program or procedure failed
00211 Error calling program or procedure
00222 Pointer or parameter error
00401 Data area specified on IN/OUT not found
00413 Error on IN/OUT operation
00414 User not authorized to use data area
00415 User not authorized to change data area
00907 Decimal data error (digit or sign not valid)
01021 Tried to write a record that already exists (file being used has unique keys and key is duplicate, or attempted to write duplicate relative record number to a subfile).
01022 Referential constraint error detected on file member.
01023 Error in trigger program before file operation performed.
01024 Error in trigger program after file operation performed.
01211 File not open.
01218 Record already locked.
01221 Update operation attempted without a prior read.
01222 Record cannot be allocated due to referential constraint error
01331 Wait time exceeded for READ from WORKSTN file.

Monday, April 21, 2008

Kaizen:

Kaizen is Japanese for improvement. It is a Japanese philosophy that focuses on continuous improvement throughout all aspects of life. When applied to the workplace, Kaizen activities continually improve all functions of a business from manufacturing to management and from the CEO to the assembly line workers. By improving the standardized activities and processes, Kaizen aims to eliminate waste. Kaizen was first implemented in several Japanese businesses during the country's recovery after World War II, including Toyota, and has since spread to businesses throughout the world.
Kaizen is a daily activity whose purpose goes beyond simple productivity improvement. It is also a process that, when done correctly, humanizes the workplace, eliminates overly hard work (both mental and physical), and teaches people how to perform experiments on their work using the scientific method and how to learn to spot and eliminate waste in business processes.
To be most effective kaizen must operate with three principles in place:
• Consider the process and the results (not results-only) so that actions to achieve effects are surfaced;
• Systemic thinking of the whole process and not just that immediately in view (i.e. big picture, not solely the narrow view) in order to avoid creating problems elsewhere in the process; and
• A learning, non-judgmental, non-blaming (because blaming is wasteful) approach and intent will allow the re-examination of the assumptions that resulted in the current process.
People at all levels of an organization can participate in kaizen, from the CEO down, as well as external stakeholders when applicable. The format for kaizen can be individual, suggestion system, small group, or large group. At Toyota, it is usually a local improvement within a workstation or local area and involves a small group in improving their own work environment and productivity. This group is often guided through the kaizen process by a line supervisor; sometimes this is the line supervisor's key role.
While kaizen (at Toyota) usually delivers small improvements, the culture of continual aligned small improvements and standardization yields large results in the form of compound productivity improvement. Hence the English usage of "kaizen" can be: "continuous improvement" or "continual improvement."