Responsibility Assignment Matrix:

Responsibility assignment matrix (RAM) is typically used to link activities to resources to ensure that the scope's components are each assigned to an individual or team. One type of RAM is based on the RACI format (Responsible, Accountable, Consult and Inform). This type of RAM is called a RACI chart, because it assigns the role that the resource is to play for each given activity. These charts can be constructed at a high level (general areas) or at a detailed level (low level tasks). A table is drawn, usually with Activities on the vertical edge (Work Breakdown Structure or WBS) and Resources on the horizontal edge (Organization Breakdown Structure). Not every resource will have an entry for every activity. As an illustration, please consider this simple chart:

ACTIVITIES	George	Glenda	Tom	Susan	Mary	Craig
Investigate	R	A	I	C	C	-
Design SW	I	A	C	-	-	R
UAT Plan	R	A	I	-	-	C
Phase Signoff	R	A	I	C	C	C

Two other RAM versions are the RACI-VS format, adding the additional roles of Verifies and Signs, and the RASCI version, adding the additional Supportive role. The definition of each role is listed below:
Role Definition
Responsible This role conducts the actual work/owns the problem. There can be multiple Rs (this is called team working)
Accountable This role approves the completed work and is held fully accountable for it. There should be only one A
Supportive This role provides additional resources to conduct the work or plays a supportive role in implementation.
Consulted This role has the information and/or capability to complete the work. Two-way communication (typically between R and C).
Informed This role is to be informed of progress and results. One-way communication (typically from R to A).
Verifies This role checks the work to ensure that it meets all defined criteria and standards.
Signs This role signs off on the completed work.
A responsibility matrix can also be known as a linear responsibility chart and can be used to show who is responsible and at what level. For example each row could represent a task and each column a person, the boxes could then be completed with the letters P (Prime support), S (Support) and N (Notify).
LRC is often referred as the responsibility assignment matrix (RAM). It identifies the participants, and to which degree each activity will be performed and/or decisions will be made.

String Handling simplified with Variable Length Fields:

The varying-length character type (available in V4R2 and above) can simplify string-handling code as well as make it more efficient.

Use the Keyword “VARYING” on the declaration line (D-Spec) of the character variable.

Example:

Without variable length fields

C EVAL Name = %TRIMR(Lib) + '/' +
C %TRIMR(File) + '(' +
C %TRIMR(Mbr) + ')'


With variable length fields

C EVAL Name = Lib + '/' +
C File + '(' +
C Mbr + ')'

Preventing incoming Messages:

To prevent messages (inquiry and break) from interrupting you at your workstation, set your job's Break Message Handling attribute to value *NOTIFY or *HOLD.

To change the value, issue command CHGJOB BRKMSG(*NOTIFY) or CHGJOB BRKMSG(*HOLD) from the command line.

If you want to reinstate the interruptions, execute CHGJOB BRKMSG(*NORMAL).

Display the Command String:

When you use CL command prompter (F4) to enter a command, you don't need to exit and press F9 to retrieve the command to view the command string. You can simply press F14 while you're still in the command's prompt screen to display the command string.

Easy Field Search:

The next time you want to see where a field is used throughout your system, try this handy shortcut. Rather than search all your source members using option 25 (Find string) on Programming Development Manager's (PDM's) Work with Members display, use the FNDSTRPDM (Find String Using PDM) command.

FNDSTRPDM lets you search for a string in a specified source file in a library, and you can search all the members in the file. The command lets you display, print, and edit the matching members. You can also create a report of matching members.

Printing a List of all IBM installed Software:

One way is type GO LICPGM, press enter and select option 10. This will display a list of IBM software packages installed on your system. But this method might not display all software packages installed and doesn’t let you print the list.

Another way is using DSPSFWRSC (Display Software Resources) command. This not only prints all the software package names but also prints the library name in which each package is located.

Model Files:

Model files are little-known features of i5/OS. But with some basic knowledge, developers can use them to simplify some programming tasks.

Model files are physical files supplied by i5/OS commands and used to generate output to outfiles. They provide the model record format and fields needed to create the user-specified outfiles. Because they are used as models, they normally don't have any data themselves; they may not even have a member.

To discuss model files, let's talk about one in particular: QADSPFFD. This model file is a physical file with an object of type *FILE and an attribute of PF-DTA. QADSPFFD is specifically used by the DSPFFD command. Consider the command:
DSPFFD FILE(MYFILE) OUTPUT(*OUTFILE) OUTFILE(FFDOUT)
When the command runs, it uses the model file QADSPFFD to create FFDOUT, which contains the same field layout, record format name, and field names as QADSPFFD.

So what does this mean to the developer? You can use model files to simplify some of your programming steps.

Consider the above command in a CL program, which also contains this:
DCLF FFDOUT
To compile this program, you would need to create a file called FFDOUT so that the CL compiler can find the description. The same is true if you call an HLL program that accesses FFDOUT and its description.

Now, consider the same CL program, with this:
PGM
|
|
DCLF QTEMP/QADSPFFD
|
|
DSPFFD FILE(MYFILE) OUTPUT(*OUTFILE) OUTFILE(QTEMP/QADSPFFD)
|
|
CALL MYHLLPGM
|
|
ENDPGM
Now, you don't need to create the file for compilation. QADSPFFD already exists as a model file. Your change management package will thank you.

Note the use of QTEMP. You cannot use the model file itself as your output file. i5/OS doesn't like that. The model files are in QSYS.

You still may need to do some database overriding when the program runs, but even that step can be eliminated. You may even be able to eliminate the CL driver program altogether. Consider this RPG F-spec that uses DSPOBJD's model file QADSPOBJ:
FQADSPOBJ IF E K disk extfile('QTEMP/QADSPOBJ') usropn
The RPG compiler will pull in the description for this file directly from the model file. At runtime, the file in QTEMP will be accessed. With USROPN, you can generate the file directly from the RPG program by issuing a DSPOBJD command with QCMDEXC or system() before opening the file.

Processing Files with multiple Members:

Stop using OVRDBF commands.

We are familiar with using the OVRDBF command to access a specific member in a file with multiple members. Or maybe we use it to access all the members by using the MBR(*ALL) parameter. But the same functionality is available directly in RPG by using the EXTMBR keyword on the file definition. Here's an example:

FSource if e disk extmbr('*ALL')

The EXTMBR keyword accepts *FIRST, *ALL, or specific member names. By utilizing this functionality, we can get around the need for using the OVRDBF command.

Also, if we are using the EXTMBR('*ALL') option, then we should be aware of how the SETGT and SETLL opcodes function when processing a file with more than one member. Using the SETGT opcode as shown below will read the first record of the next file member in the file.

c *hival setgt Source
c Read Source

Conversely, by using the SETLL opcode, we can return to the bottom (last record) of the previous member, as shown below.

c *loval setll Source
c Readp Source

Although using these techniques can make processing files with multiple members much easier, there are a couple of things to keep in mind. For example, we will not be able to use the *hival with SETGT and expect that the next READ will fail (to exit from a loop, for instance). Also, unless we use the file information data structure (INFDS), we will not know which specific member is being processed.

Debugging Pointers:

In the debugger, you can see the data that a pointer is pointing to even if you don't have a variable that is based on the pointer.

When debugging an RPG or COBOL program, if you display a pointer variable using :c or :x, the debugger will display the data that the pointer is pointing to rather than displaying the 16 bytes of the pointer variable itself.

D p S *
D packedVal S 5P 0 INZ(12345)
D charVal S 5A INZ('abcde')
/free
p = %addr(charVal);
p = %addr(packedVal);
return;

In the debugger, after the first assignment to p:

> EVAL p
P = SPP:DE60CDB47B069738
> EVAL p:c 5
P:C 5 = 'abcde'
> EVAL p:x 5
00000 81828384 85......

After the second assignment to p:

> EVAL p
P = SPP:DE60CDB47B06973D
> EVAL p:c 3
P:C 3 = ' ¬'
> EVAL p:x 3
00000 12345F..

Bluetooth:

Bluetooth is an industrial specification for wireless personal area networks (PANs). Bluetooth provides a way to connect and exchange information between devices such as mobile phones, laptops, PCs, printers, digital cameras, and video game consoles over a secure, globally unlicensed short-range radio frequency. The Bluetooth specifications are developed and licensed by the Bluetooth Special Interest Group.
Bluetooth is a standard and communications protocol primarily designed for low power consumption, with a short range (power-class-dependent: 1 meter, 10 meters, 100 meters) based on low-cost transceiver microchips in each device.
Bluetooth enables these devices to communicate with each other when they are in range. The devices use a radio communications system, so they do not have to be in line of sight of each other, and can even be in other rooms, as long as the received transmission is powerful enough.
Bluetooth and Wi-Fi have slightly different applications in today's offices, homes, and on the move: setting up networks, printing, or transferring presentations and files from PDAs to computers. Both are versions of unlicensed spread spectrum technology.
Bluetooth differs from Wi-Fi in that the latter provides higher throughput and covers greater distances, but requires more expensive hardware and higher power consumption. They use the same frequency range, but employ different multiplexing schemes. While Bluetooth is a cable replacement for a variety of applications, Wi-Fi is a cable replacement only for local area network access. Bluetooth is often thought of as wireless USB, whereas Wi-Fi is wireless Ethernet, both operating at much lower bandwidth than the cable systems they are trying to replace. However, this analogy is not entirely accurate since any Bluetooth device can, in theory, host any other Bluetooth device—something that is not universal to USB devices; therefore it would resemble more a wireless FireWire.
Bluetooth exists in many products, such as phones, printers, modems and headsets. The technology is useful when transferring information between two or more devices that are near each other in low-bandwidth situations. Bluetooth is commonly used to transfer sound data with phones (i.e. with a Bluetooth headset) or byte data with hand-held computers (transferring files).
Bluetooth simplifies the discovery and setup of services between devices. Bluetooth devices advertise all of the services they provide. This makes using services easier because there is no longer a need to setup network addresses or permissions as in many other networks.

Little Know Debugging Tricks:

%SUBSTR Built-In Function
This function is great when you're working with large strings. You can view a segment of a string as shown below (assume that StringFldA = 'abcdefghijklmnopqrstuvwxyz'):

Debug command: EVAL %SUBSTR(StringFldA 12 5)
Displayed result: %SUBSTR(StringFldA 12 5) = 'lmnop'

This is convenient when working with larger string fields. You can also use the %SUBSTR function to set the value of a specific portion of a string.
Debug command: EVAL %SUBSTR(StringFldA 12 5) = 'xxxxx'
Displayed result: %SUBSTR(StringFldA 12 5) = 'xxxxx'
Debug command: EVAL StringFldA
Displayed result: StringFldA = 'abcdefghijkxxxxxqrstuvwxyz'

You can also use %SUBSTR to set a conditional breakpoint or watch condition. For example, the following code would stop execution only when positions 12 thru 16 of StringFldA are 'xxxxx':

Debug command: BREAK 100 when %SUBSTR(StringFldA 12 5) = 'xxxxx'

Or you could watch for those same positions to change by using this watch condition:

Debug command: WATCH %SUBSTR(StringFldA 12 5)

This way, anytime the contents of positions 12 thru 16 change, program execution stops and you are notified.
%INDEX Built-In Function
The %INDEX function is handy when you're using multiple-occurrence data structures. It's also useful in combination with _QRNU_DSI_xxxx (where xxxx = the name of a multi-occurrence data structure). The command EVAL _QRNU_DSI_xxxx returns the current occurrence of a multiple-occurrence data structure. Using the %INDEX function will change the current occurrence. See the example below:
d WorkDS1 ds occurs(3)
d StringA 10a
d StringB 25a
Debug command: EVAL _QRNU_DSI_WorkDS1
Displayed result: 1 (or whatever the current occurrence of WorkDS1 is)

Debug command: WorkDS1 = %INDEX(3)
Displayed result: WorkDS1 = %INDEX(3) = 3
Interrogated subfields will now reflect the values the of third occurrence of the data structure.
Parting Shot
Sometimes many of the field names are really long, so if you don't type well (or just don't like to type), then using the EQUATE debug command can help you. This command allows you to define an "alias" for a field name, expression, or command. For instance...

Debug command: EQUATE SmName This_is_a_really_long_field_name

You can then find the value of "This_is_a_really_long_field_name" by keying the command shown below:

Debug command: EVAL SmName

The EQUATE command can also be used to create a macro of sorts. This is done by assigning an alias to a complete command. Here's an example:

Debug command: EQUATE SmCmd EVAL %substr(StringA,5,5)

By keying SmCmd and pressing Enter, you can display the value of positions 5 thru 9 of the StringA variable.

Benchmarking:

Benchmarking (also "best practice benchmarking" or "process benchmarking") is a process used in management and particularly strategic management, in which organizations evaluate various aspects of their processes in relation to best practice, usually within their own sector. This then allows organizations to develop plans on how to adopt such best practice, usually with the aim of increasing some aspect of performance. Benchmarking may be a one-off event, but is often treated as a continuous process in which organizations continually seek to challenge their practices.
Types of Benchmarking:
• Process benchmarking - the initiating firm focuses its observation and investigation of business processes with a goal of identifying and observing the best practices from one or more benchmark firms. Activity analysis will be required where the objective is to benchmark cost and efficiency; increasingly applied to back-office processes where outsourcing may be a consideration.
• Financial benchmarking - performing a financial analysis and comparing the results in an effort to assess your overall competitiveness.
• Performance benchmarking - allows the initiator firm to assess their competitive position by comparing products and services with those of target firms.
• Product benchmarking - the process of designing new products or upgrades to current ones. This process can sometimes involve reverse engineering which is taking apart competitors products to find strengths and weaknesses.
• Strategic benchmarking - involves observing how others compete. This type is usually not industry specific meaning it is best to look at other industries.
• Functional benchmarking - a company will focus its benchmarking on a single function in order to improve the operation of that particular function. Complex functions such as Human Resources, Finance and Accounting and Information and Communication Technology are unlikely to be directly comparable in cost and efficiency terms and may need to be disaggregated into processes to make valid comparison.
Procedure:
1. Identify your problem areas - Because benchmarking can be applied to any business process or function, a range of research techniques may be required. They include: informal conversations with customers, employees, or suppliers; exploratory research techniques such as focus groups; or in-depth marketing research, quantitative research, surveys, questionnaires, reengineering analysis, process mapping, quality control variance reports, or financial ratio analysis. Before embarking on comparison with other organizations it essential that you know your own organization’s function, process; base lining performance provides a point against which improvement effort can be measured.
2. Identify other industries that have similar processes - For instance if one were interested in reducing the defects in the product, look for industries that produce similar products that has minimum defects.
3. Identify organizations that are leaders in these areas - Look for the very best in any industry and in any country. Consult customers, suppliers, financial analysts, trade associations, and magazines to determine which companies are worthy of study.
4. Survey companies for measures and practices - Companies target specific business processes using detailed surveys of measures and practices used to identify business process alternatives and leading companies. Surveys are typically masked to protect confidential data by neutral associations and consultants.
5. Visit the "best practice" companies to identify leading edge practices - Companies typically agree to mutually exchange information beneficial to all parties in a benchmarking group and share the results within the group.
6. Implement new and improved business practices - Take the leading edge practices and develop implementation plans which include identification of specific opportunities, funding the project and selling the ideas to the organization for the purpose of gaining demonstrated value from the process.
Benchmarking opens organizations to new methods, ideas and tools to improve their effectiveness. It helps crack through resistance to change by demonstrating other methods of solving problems than the one currently employed, and demonstrating that they work, because they are being used by others.

Checking for user changed screen data:

In the world of green-screen programming, one basic function a program has is dealing with information that the user enters on the screen, including changes to data.

On a simple screen, processing user-entered changes can be straightforward--editing, validating, and then processing. On more sophisticated screens, it is not as straightforward.

Some times we have many fields in the screen and we need to validate all the fields before processing. So why should we check all the entries in the screen, If the data hasn't changed from the last time the user pressed Enter (or another function key), We really don't want to re-validate the data or rebuild the page. That would be redundant.

One way to check for changes in screen data is to use the CHANGE keyword for display file DDS. The syntax is CHANGE(nn), where nn is an indicator. This can be a record-level keyword to apply to all input-capable fields in the format, or it can be a field-level keyword. If the user types into a field that is affected by this keyword, then indicator nn is set on. All your program needs to do is check that indicator to see if the data in the field has changed and do the processing.

This helps to avoid the redundant checks performed for all the fields irrespective of its change.

Debug does not show values for all fields in the file:

Ex: Consider an RPG IV program that reads a physical file Customer and prints a report. This report uses 4 fields out of 20 fields from the Customer file. The remaining fields are not referenced in the program. Put this program in Debug. Place a break point in the program immediately after reading a record from the file Customer. Now try to display the value of the fields the file contains. Several of the fields appear as blank. The record did indeed contain data in the fields reported as blank by the debugger.

The debugger is not showing the value for the fields because the information is not available to the debugger.

The RPG compiler optimizes unreferenced fields out of the program. In other words, any field in the file Customer that is not specifically referenced by an RPG operation is not included in the program.

To make the unreferenced fields available to the debugger include an H-Spec with keyword Debug as shown below. This prevents the compiler from optimizing out unreferenced fields.

H DEBUG

Debug in 132 x 27 Mode:

Normally STRDBG starts in 80x24 mode. You can change this mode to 132x27 mode with the following environment variable:

AddEnvVar EnvVar('ILE_DEBUGGER_1') +
Value('ALLOW_WIDE_SCREEN') +
Level(*Job) Replace(*Yes)

To go back to 80x24 mode, you use:

RmvEnvVar EnvVar('ILE_DEBUGGER_1') Level(*Job)

Delay the Job inside RPGLE:

To delay an internal loop inside a RPG program, or to delay a call to another program, use 'Sleep' or ‘Usleep’

Sleep – To delay a job for one or more seconds
Usleep – To delay a job for less than one second
H BndDir('QC2LE')
D Sleep Pr 10I 0 ExtProc('sleep')
D Seconds 10U 0 Value

D Usleep Pr 10I 0 ExtProc('usleep')
D Microsecs 10U 0 Value

* Sleep for 30 seconds
C CallP Sleep(0030)
* Sleep for less than a second
C CallP Usleep(0000999999)
Note: For values <= 1,000,000, usleep sleeps that many microseconds. For values > 1,000,000, it sleeps 0 microseconds.

Overloading Indicators:

Use this technique to reduce the number of required screen indicators.
Attribute fields are one way to eliminate indicators, but are there any other ways? There are screen functions that require indicator usage, but can we at least reduce their usage? We can by doing what I like to think of as overloading indicator functionality.

Now, follow this scenario: You are coding a subfile. To do so, you need a SFLDSPCTL keyword, with an indicator, of course, to display the subfile control record. You also need SFLCLR (or SFLINZ) to clear the subfile. So you put indicator 92 on SFLDSPCTL and indicator 93 on SFLCLR.

In the program, in order to clear the subfile, you need to set 92 off and 93 on. You write the control record to clear. After loading the subfile, you need to display the control record. You set 92 on and 93 off. That's two indicators to keep track of.

Two of a control record's functions are displaying itself and clearing the subfile. These are mutually exclusive functions. So why use two indicators? This is a case where one indicator can serve both functions: It can be overloaded. Indicator 92 can be used to display the subfile, and N92 can be used to clear it.

So now, in order to clear the subfile, you set 92 off. To display the control record, you set 92 on. That's only one indicator to keep track of.

So, you can overload an indicator on mutually exclusive functions; the indicator is on for one function and off for the other.

Another use for overloading indicators is on related functions. For example, consider the SFLDSP keyword on your expanding subfile. This keyword displays the subfile, of course. You turn it on only if there are records in the subfile to display. If there are no records to display, why bother turning on PAGEDOWN? You can use the same indicator, with the same setting, to condition SFLDSP and PAGEDOWN.

Not only that, PAGEDOWN is mutually exclusive to SFLEND (why allow PAGEDOWN when the last page of the subfile is displayed?), so you can also condition PAGEDOWN with the opposite setting of SFLEND.

Here is a standard, basic coding for expanding subfiles:
A 91 SFLDSP
A N91 ERASE(SCRN1F)
A 92 SFLDSPCTL
A N92 SFLCLR
A 93 SFLEND(*MORE)
A N93 91 PAGEDOWN

Only three indicators are in use. Indicator 91 is used this way: If there are records in the subfile to display, then PAGEDOWN is active; otherwise, the area of the screen occupied by the subfile is cleared, and PAGEDOWN is inactive. Indicator 92: Either display the control record or clear the subfile. Indicator 93: If the last page of the subfile is displayed, show "Bottom" and deactivate PAGEDOWN; otherwise, show "More..." and turn on PAGEDOWN.

There are other times to overload indicators too. For example, if you are restricting certain functions of a program to certain users, you can use one indicator to protect screen fields, deactivate function keys, and hide the text for those function keys for unauthorized users. Those are related security functions. Likewise, you can use the opposite setting of that indicator to open the fields, activate the function keys, and display the text for authorized users.

In our quest to rid ourselves of indicators, we can use overloading to reduce the number of required screen indicators. We do this by using the same indicator for related functions and using opposite settings of one indicator for mutually exclusive functions. The fewer indicators we have, the better off the program can be.

Class Diagram:

In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.
Class:
An object is any person, place, thing, concept, event, screen, or report applicable to your system. Objects both know things (they have attributes) and they do things (they have methods). A class is a representation of an object.
Responsibilities:

Classes are typically modeled as rectangles with three sections: the top section for the name of the class, the middle section for the attributes of the class, and the bottom section for the methods of the class. Attributes are the information stored about an object (or at least information temporarily maintained about an object), while methods are the things an object or class do. For example, students have student numbers, names, addresses, and phone numbers. Those are all examples of the attributes of a student. Students also enroll in courses, drop courses, and request transcripts. Those are all examples of the things a student does, which get implemented (coded) as methods.


Associations:

Objects are often associated with, or related to, other objects. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship.


Multiplicity Indicators.
Indicator Meaning
0..1 Zero or one
1 One only
0..* Zero or more
1..* One or more
n Only n (where n > 1)
0..n Zero to n (where n > 1)
1..n One to n (where n > 1)
Inheritance Relationship:


Similarities often exist between different classes. Very often two or more classes will share the same attributes and/or the same methods. Inheritance Models “is a” and “is like” relationships, enabling to reuse existing data and code easily. The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.


Composition Association:

Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on. In UML 2, aggregation would be shown with an open diamond.

Use of Ampersand to extend prompted field lengths:

If you are filling out a command prompt screen and need more room in an input field, try putting an ampersand (&) in the first position followed by one or more blanks. This will expand the field to its next size increment. The increments are 25, 80, 132, 256, and 512 characters. This is handy when working with CL programs that have expressions longer than the standard-length input field.

Chaining in a CL Program:

Most AS/400 programmers are familiar with the Override Database File (OVRDBF) command for substituting one file for another, changing a file to share an open data path (ODP), and other common uses. But many may not be aware that it can also be used with the Receive File (RCVF) command to perform random record access, similar to CHAIN or SETLL operation codes in RPG.
The way to do this is to use the POSITION parameter of the OVRDBF command. It can be used to get a record with a certain key value. To do this, you must specify the name of a field and one of the following search values.
• KEY (Key Equal)-The record with the given key value will be retrieved.
• KEYA (Key After)-The record following the record with the given key value will be retrieved.
• KEYAE (Key After or Equal)-If a record with the given key value exists, it will be retrieved. If not, the record with the next higher value will be retrieved.
• KEYB (Key Before)-The record preceding the record with the given key value will be retrieved.
• KEYBE (Key Before or Equal)-If a record with the given key value exists, it will be retrieved. If not, the record with the next lower value will be retrieved.
The following code fragment demonstrates the use of the POSITION parameter of the OVRDBF command.

DCLF FILE(MYFILE)
OVRDBF FILE(MYFILE) +
POSITION(*KEY 1 MYFMT KEYFLD)
RCVF
This example will retrieve a record from file MYFILE (format MYFMT), which has a key value matching the value in the field KEYFLD. The other key search values work similarly.

PERT (Project Evaluation and Review Technique):

The Program (or Project) Evaluation and Review Technique, commonly abbreviated PERT, is a model for project management designed to analyze and represent the tasks involved in completing a given project.
PERT was developed primarily to simplify the planning and scheduling of large and complex projects. It was able to incorporate uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in R&D-type projects where time, rather than cost, is the major factor.


• A PERT chart is a tool that facilitates decision making; The first draft of a PERT chart will number its events sequentially in 10s (10, 20, 30, etc.) to allow the later insertion of additional events.
• Two consecutive events in a PERT chart are linked by activities, which are conventionally represented as arrows in the diagram above.
• The events are presented in a logical sequence and no activity can commence until its immediately preceding event is completed.
• The planner decides which milestones should be PERT events and also decides their “proper” sequence.
• A PERT chart may have multiple pages with many sub-tasks.
• Critical Path is the longest possible continuous pathway taken from the initial event to the terminal event. It determines the total calendar time required for the project; and, therefore, any time delays along the critical path will delay the reaching of the terminal event by at least the same amount.
Benefits:
PERT is useful as it provides the following information.
• Expected Project completion time.
• Probability of completion before a specified date.
• The Critical path activities that directly impacts the completion time.
• Activity Start and End dates.

Limitations:
• The activity estimates are somewhat subjective and depend on judgment.
• Under estimation of project completion time due to alternate paths becoming critical path.

Pre-allocating Storage in DB2 UDB Tables:

One of the attributes that has made DB2® UDB for iSeries® easy to use and manage over the years is that DB2 automatically handles all of the low-level storage allocation for the DB2 objects. All you have to do is create the table, and let DB2 automatically handle allocating disk storage and spreading the table data evenly over the disk drives. This automatic storage allocation and management works fine for the majority of iSeries and AS/400e® customers.

However, it improves performance when you have a table in which new rows are being inserted at high rates by multiples connections and jobs -- especially in batch processing environments.
Consider preallocating storage for the rows in that table when you have a rough idea on what the maximum row count for the table will be. The reason for preallocating the table storage is so that DB2 can insert new rows into the table during heavy, concurrent loads without having to periodically allocate storage for new rows, which interruprts the insertion process. If many connections and jobs are allocating new space for a DB2 table at the same time, then the queue for storage allocation can quickly become a bottleneck.


The Add_New_Rows stored procedure requires three input parameter names:
• Table_Name, which is the name of the table for which storage is to be allocated.
• Lib_Name, which is the schema or collection name.
• Row_Cnt, which is the number of rows for which storage is to be allocated.
The stored procedure uses these parameters to dynamically construct a CHGPF request for the specified tables. Here's an example of the command that is constructed:

CHGPF FILE(MYSCHEMA/MYTABLE) SIZE(50000 1000 3) ALLOCATE(*YES)


• This command allocates storage for 50000 rows in the specified table, MYTABLE. The SIZE parameter contains 3 different numeric values:
• The first numeric value (50000) is the number of rows initially allocated for the table.
• The second parameter contains the number of rows that will automatically be added to the table if the initial row allocation is exceeded.
• The third value is the number of times that additional rows will be allocated.
• In the example shown above, storage for 50000 rows is allocated initially, and the table can support a maximum of 53000 rows (50000 + (3 x 1000)), with 1000 rows being allocated each time the row allocation limit is reached, up to 3 times.

• The Add_New_Rows stored procedure uses a system-provided stored procedure, QCMDEXC, to execute the CHGPF system command from an SQL procedure.
After the CHGPF command has been executed via the QCMDEXC stored procedure, then further action is required to actually activate the specified change. The stored procedure uses either the RGZPFM or CLRPFM system command on the specified table, depending on whether the table already contains rows. The CLRPFM command deletes all of the rows in the specified table, which is why the stored procedure first runs a query to check if there are any rows in the input table. If the table already contains data, then the RGZPFM command is used to reorganize the table to activate the change in allocation. The RGZPFM command can take a very long time to run for an existing table with a large number of rows, so use this stored procedure carefully with tables that already contain large amounts of data.

CREATE PROCEDURE
Add_New_Rows (Table_Name varchar(256), Lib_Name char(10), rowcnt integer )

LANGUAGE SQL

BEGIN

DECLARE qualified_name VARCHAR(20);
DECLARE current_count INTEGER;
DECLARE count_stmt VARCHAR(64);
DECLARE change_cmd VARCHAR(128);
DECLARE activate_tblchg_cmd VARCHAR(64) ;
DECLARE cmd_length NUMERIC(15,5);
DECLARE c1 CURSOR FOR s1;

SELECT strip(system_table_schema) || '/' || strip(system_table_name)
INTO qualified_name
FROM qsys2.systables
WHERE table_name=Table_Name and table_schema=Lib_Name;

/* Execute the CHGPF command to change the table allocation */

SET change_cmd = 'CHGPF FILE('|| qualified_name || ') ' ||
'SIZE(' || CHAR(rowcnt) || '1000 3) ALLOCATE(*YES)';
SET cmd_length=LENGTH(change_cmd);
Call QSYS.QCMDEXC (change_cmd,cmd_length);

/* Need to determine the number of rows in the table to activate
this new table allocation */

SET count_stmt = 'SELECT COUNT(*) FROM ' || Lib_Name || '.' || Table_Name ;
PREPARE S1 FROM count_stmt;
OPEN c1;
FETCH c1 INTO current_count;
CLOSE c1;

/* Use the current number of rows to determine the "activation"command */

IF current_count=0 THEN

/* No rows in the table means a clear operation can be used to get the
new ALLOCATE settings to take effect */

SET activate_tblchg_cmd='CLRPFM ' || qualified_name;
ELSE
/* If there are rows, they cannot be deleted so reorganize instead */
SET activate_tblchg_cmd='RGZPFM ' || qualified_name;
END IF;
SET cmd_length = LENGTH (activate_tblchg_cmd);

/* Activate the new table allocation values by issuing a clear or reorganize */

Call QSYS.QCMDEXC (activate_tblchg_cmd,cmd_length);

END;

All about Indicators:

RPG IV has the introduction of the following indicators:
• Named Indicators
• Logical Expressions
• Built-In Functions (BIFs)
• The Indicator Data Structure (INDDS)
That means the only RPG indicator we may have to use is *INLR!
Named Indicators
Indicators are now a recognized data type in RPG, so we can define them in the D Specs, as shown below. Note that when testing an indicator you do not need to compare it against *ON or *OFF.
DName+++++++++++ETDsFrom+++To/L+++IDc.Keywords+++++
D BadStatus S N
D MonthEnd S N
The below code shows a named indicator being used for printer overflow. This is a simple example of the benefit of a named indicator; the name Overflow is more self-explanatory than *IN96 or *INOV. Also, you don't need to define the Overflow indicator in the D Specs; the compiler will define it for you.
FReport O E Printer OflInd(OverFlow)

Write Detail;
If OverFlow;
Write Header;
OverFlow = *Off;
EndIf;

Logical Expressions
The result of a logical expression is true or false, therefore it can be assigned directly to an indicator.
If MonthEnd;
BadStatus = (Status <> 'I' and Status <> 'C');
EndIf;

Built In-Functions
We no longer need to use resulting indicators on operation codes. Instead, we can use the relevant I/O BIF. The I/O BIFs are %OPEN, %FOUND, %EOF, %ERROR, %EQUAL and %STATUS. The code below shows an example of using the %OPEN, %ERROR and %FOUND BIFs. The %OPEN BIF indicates whether or not the file is open. The %ERROR BIF is set when the E extender is defined on an operation code (Chain in this case). We use the E extender in place of an error indicator in the low position. The %FOUND BIF is set automatically by the Chain operation.
If %Open(FileB);
Chain(E) Key FileB;
Select;
When %Error;
Dsply 'File Error';
When %Found(FileB);
Dsply 'Got It';
EndIf;
EndIf;
One of the nice things about %FOUND is that it reads the right way round, as opposed to the indicator on the CHAIN operation where the indicator is true if the record is NOT found.
Indicator Data Structure
By default, the indicators 01 to 99 on a display or print file are mapped to the indicators 01 to 99 in an RPG program. But when we use the file keyword INDDS (Indicator Data Structure), they are mapped to a data structure instead of the indicators. In other words, the 99 indicators used with the display or print file are now associated with the data structure instead of the indicators *IN01 to *IN99 in the program.
The code below shows an example of using the INDDS. The indicators for the display file are mapped to the data structure DspInd. DspInd is a 99 byte data structure, with each byte corresponding to one of the 99 indicators for the display file. This means that for the display file, we MUST use the indicators in the data structure and NOT the numbered indicators. For example, in this program, if we turned on indicator *IN31, it would have no impact on the display file. The program logic must refer to the indicator Error in order to have an impact on the display file. Named indicators are a lot easier to decipher!
FDisplay CF E WORKSTN INDDS(DspInd)

D DspInd DS
* Response indicators
D F3Exit 3 3N
D F12Cancel 12 12N
* Conditioning indicators
D AllErrors 31 33
D Error 31 31N
D StDateErr 32 32N
D EndDateErr 33 33N

Eval AllErrors = *Zeros;

StDateErr = StartDate < Today;
EndDateErr = EndDate < StartDate;
Error = StDateErr or EndDateErr;

ExFmt MyScreen;

If F3Exit or F12Cancel;
The use of INDDS requires the use of the file level keyword INDARA in the DDS for the display/print file. In most cases, changing a file to use INDARA will have no effect unless a RESET or CLEAR operation is used. In this case it will now be necessary to also RESET/CLEAR the associated indicators.