Passing Prototyped Parameters

Checking for the Number

of

Passed

 

Parameters

 

 

 

 

 

 

 

 

 

 

 

 

 

At

times

it

may

be necessary to check for the number of parameter

passed on a call. Depending

on

 

how the procedure has been

written,

may

allow

you

to

avoid references to parameters that are not passe

suppose that you want to write a procedure which will sometimes be

parameters and

sometimes

four parameters. This might arise when

a

ne

eter is required. You can write the called procedure to process

depending

on

the

value

that

is

 

returned by the built-in

function

%PARMS

may

pass

the

parameter.

Old calls can remain unchanged.

 

 

 

 

 

%PARMS does not take any

 

parameters.

The

value returned

by

%PARMS

also

includes

any

parameters

 

for which *OMIT has been passed. For

the ma

dure,

%PARMS

returns

the

same

value as contained

in

the

*PARMS field

in

PSDS,

although

to

use

the

*PARMS

field,

you must

also

code

the

PSDS.

For

both

*PARMS

and

%PARMS,

 

if the number of passed parameters

is

not

known, the

value -1

is

returned.

(In order to determine the

number

passed,

a

minimal

operational descriptor must be passed. ILE

RPG

alwa

one

on

a

call; however other ILE languages may not.) If the

main

pro

active, *PARMS is unreliable. It is not recommended to reference *PARMS

subprocedure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Using %PARMS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In

this

example,

a

procedure

FMTADDR

has

been

changed

several

times

for

a

change

in

the address information for the employees of a

co

FMTADDR

is

called by three different procedures. The procedures di

number of parameters they use to process the employee information.

requirements

for

the

FMTADDR

have

arisen, and to support them,

new

pa

have been added. However, old

procedures calling

FMTADDR are

still

su

and

do not

have

to

be

changed

or

recompiled.

 

 

 

 

 

 

 

The changes to the employee address can be summarized as follows:

¹Initially only the street name and number were required because

lived in the same city. Thus, the city and province could be su

¹At a later point, the company expanded, and so the city informati

variable for some company-wide applications.

¹Further expansion resulted in variable province information.

The procedure processes the information based

on the

number

of

para

passed. The

number

may

vary

from 3

to 5.

The

number

tells the

progr

to provide

default

city

or

province

values

or

both.

Figure 68

on

pag

the source for this procedure. Figure 69 on page 143

shows

the

sour

member containing the

prototype.

 

 

 

 

 

 

The main logic of FMTADDR is as follows:

1. Check

to see how many parameters

were

passed

by using

%PARMS. Thi

built-in

function

returns

the number

of

passed

parameters.

 

¹ If

the number is greater than

4,

then the

default

province

the

actual

province

supplied by

the

fifth

parameter

P_Province.

¹If the number is greater than 3, then the default city is actual city supplied by the fourth parameter P_City.

Chapter 10. Calling Programs and Procedures141

Page 164 Page 166
Page 165
Image 165
IBM AS/400 manual Passing Prototyped Parameters Checking for the Number, Psds
Page 164 Page 166

AS/400 specifications

The IBM AS/400, now known as the IBM iSeries, is a midrange computer system that has been a cornerstone of enterprise computing since its introduction in 1988. Designed to provide a robust platform for business applications, the AS/400 is celebrated for its reliability, scalability, and integrated database capabilities.

One of the key features of the AS/400 is its Integrated Operating Environment, which blends hardware and software resources seamlessly. This integration allows businesses to execute diverse workloads, ranging from traditional applications to modern web-based services, all on a single platform. The operating system, OS/400 (now IBM i), offers a rich set of APIs and tools for developers, simplifying application development and management.

Another standout characteristic of the AS/400 is its built-in database, DB2 for i. This powerful relational database management system allows for efficient data handling and provides advanced features such as support for SQL, XML, and JSON, making it easier for businesses to manage their data and integrate it with other systems. The database's tight integration with the operating system enables high performance and security.

In terms of scalability, the AS/400 can accommodate small businesses as well as large enterprises, with the ability to support hundreds of users simultaneously. Its architecture allows for easy upgrades in hardware, meaning that organizations can scale their systems without replacing the entire infrastructure.

Security is another critical attribute of the AS/400. With a sophisticated security model, it offers built-in user authentication, access control, encryption, and auditing capabilities to protect data and applications from unauthorized access.

The AS/400 also supports multiple programming languages, including RPG, COBOL, Java, and PHP, giving organizations the flexibility to choose the development tools that best fit their needs. This diversity helps maintain legacy applications while also developing new ones that leverage modern technologies.

Moreover, the platform supports both traditional green-screen interfaces and modern graphical user interfaces, allowing organizations to transition smoothly into contemporary user experience paradigms.

Overall, the IBM AS/400 stands out as a resilient, flexible, and secure computing platform that enables organizations to effectively manage their business operations, streamline processes, and adapt to changing market demands. Its unique combination of integrated features and capabilities ensures that it remains relevant in today's fast-paced technology landscape.
Top Page Image Contents