Rather than create multiple versions of code to do different things with data, this technique allows you to have only one copy of that logic.
As we try to develop more modular code, one of the problems that we encounter is how to integrate modules or procedures that need to process more than a single record or row of data. We already know that we can easily pass parameters or arguments between procedures that hold all the data we need if we are processing only a single row or record. But what if we want to call a process that processes all the records for a selected part, or all the records for a given PO, or any similar process? What if we want to pass an array or multiple-occurrence data structure? Those have some limitations that make them more difficult to implement.
An elegant solution to this type of situation is to use a procedure pointer. Figure 1 illustrates how an application program can dynamically integrate with a service program to process all the records for a given part.
Figure 1: An application program can dynamically integrate with a service program.
In this example, the application program is an interactive program that allows the user to select a part number and then prints a report listing all the data for that part. In this application, let's assume that collecting the data for that part is a complex process that has been encapsulated into its own service program. The application program will get a part number from the user and then pass it to the service program. The logic inside the service program will use that part number to build a list of records to process. For each record in that list, the service program will make a call back to the subprocedure in the application program. Once all the records are processed, control returns to the mainline in the application program. This lets the application program leverage modularized code in the service program that handles multiple records.
Below is the sample code for the application program. The GetParts subprocedure is a commonly used subprocedure deployed through a service program. That subprocedure receives three parameters: the part number being processed, the data structure to hold the data for each part being processed, and the procedure pointer for the MyProc subprocedure in this program. Note that the %ADDR function is used to get the address of the P_Data data structure, and the %PADDR function is used to get the procedure address of the MyProc subprocedure in this program. In this sample program, the MyProc subprocedure will display the description of each record processed by the GetParts subprocedure.
D GetParts PR
D P_Part 10
D P_Data_Ptr *
D P_Proc_Ptr * PROCPTR
D MyProc PR
D P_Data E DS EXTNAME(PartMast)
D Data_Ptr *
D Proc_Ptr * PROCPTR
/Free
DSPLY 'Part?' ' ' PartNo;
Data_Ptr = %ADDR(P_Data);
Proc_Ptr = %PADDR(MyProc);
CALLP GetParts(PartNo:Data_Ptr:Proc_Ptr);
*INLR = *ON;
Return;
/End-Free
P MyProc B EXPORT
D MyProc PI
/Free
DSPLY DESCRIPT ' ';
Return;
/End-Free
P MyProc E
Below is the sample code for the service program. This service program defines two procedures: Get Parts, which handles the process of selecting all the records for the given part, and ProcessRow, which is a surrogate or proxy for the MyProc subprocedure in the application program. The EXPROC keyword indicates that this procedure is identified by its address rather than its name. At run time, when this procedure is called, control is passed to the address specified by the Proc_Ptr variable.
This sample program uses relatively simple SQL processes to build a list of records to process and then loops through them one at a time. For each record read, the ProcessRow function is called, passing control back to the MyProc sub procedure in the application program. The data for each record is loaded into P_Data, which shares the same memory address as the P_Data in the application program, which means that it is available for use in MyProc. This eliminates the need to pass data into the subprocedure.
H NOMAIN
D ProcessRow PR EXTPROC(Proc_Ptr)
D Proc_Ptr S * PROCPTR INZ(*NULL)
D GetParts PR
D P_Part 10
D P_Data_Ptr *
D P_Proc_Ptr * PROCPTR
P GetParts B EXPORT
D GetParts PI
D P_Part 10
D P_Data_Ptr *
D P_Proc_Ptr * PROCPTR
D P_Data E DS EXTNAME(PartMast)
D BASED(P_Data_Ptr)
/Free
Proc_Ptr = P_Proc_PTr;
EXEC SQL DECLARE C1 CURSOR FOR
SELECT * FROM PARTMAST
WHERE PARTNO = :P_PART;
EXEC SQL OPEN C1;
EXEC SQL FETCH FROM C1 INTO :P_Data;
DOW SQLCODE = 0;
CALLP ProcessRow();
EXEC SQL FETCH FROM C1 INTO :P_Data;
ENDDO;
Return;
/End-Free
P GetParts E
The key thing to keep in mind is that, in this example, the service program includes an already-written subprocedure that performs the frequently required and relatively complex task of gathering all the records related to a given part. Rather than copying that code or creating multiple versions of it that do different things with the data, this technique allows you to have only one copy of that logic. That one well-written subprocedure can then call back to a given subprocedure in the application program that is driving this whole process and allow that subprocedure to determine what to do with the each record processed.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online