RE: [SPAM?] Re: Service Pgm -- RPG400-L

IMO, before using service programs, you need to get your hands around the concept of activation groups. Once you do that, using service programs will be easy. At that point, it's up to you how you wish to organize your code in service programs.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Vern Hamberg
Sent: Wednesday, January 07, 2009 8:57 AM
To: RPG programming on the IBM i / System i
Subject: [SPAM?] Re: Service Pgm
Importance: Low

Creating a service program is done using the CRTSRVPGM command. You
first have to have modules, at least one, that will be linked together
into the service program.

For examples, the ILE Concepts manual has some - or go to RPGIV.com and
look around. Sorry to say, but this is really basic stuff - asking for
examples, well, it's kind of not something anyone can answer except to
point you back to the manuals.

The ILE RPG Programmer's manual might help.

But there is a whole conceptual thing you need to get clear on, and I
don't think you're there. I don't have it all down, either, by the way.
But go to infocenter under the programming item on the left and look for
the ILE Concepts section - or the printable version, so you can read it
in the "library" at work or at home.

Keep asking questions.

HTH
Vern

Adam West wrote:

Thank you for all the responses.

Is there a chance someone could send or post some code for creating such a Service Program?

Also if there is any further discussion about the problems of the call stack that was mentioned with using
Procedures that are used by other programs (as a separate module)?

________________________________
From: Chamara Withanachchi <chamaraw@xxxxxxxxxx>
To: RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>
Sent: Wednesday, January 7, 2009 3:08:35 AM
Subject: Re: Some ILE questions.

*Procedure*

Subprocedures are independently callable routines in a module. Here are some
of the characteristics of subprocedures:

- They can accept parameters and return values.
- They can have their own variables, separate from the rest of the
program.
- They can be called independently.
- They can return values to be used in expressions.

Many usersfind it easiest to think of subprocedures as "subroutines with
parameters." In other words, subprocedures are small pieces of code (like
subroutines), except that you can call them and pass parameters to them.

also procedures like functions in C/C++

*Prototyping Procedures*

Compiler can validate parameters pass to Procedures

*Export/Import*

EXPORT keyword allows a globally defined data structure or standalone field
defined within a module to be used by another module in the program. The
storage for the data item is allocated in the module containing the EXPORT
definition.. The external_name parameter, if specified, must be a character
literal or constant.

The EXPORT keyword on the definition specification is used to export data
items and cannot be used to export procedure names. To export a procedure
name, use the EXPORT keyword on the procedure specification

The following restrictions apply when EXPORT is specified:

- Only one module may define the data item as exported
- You cannot export a field that is specified in the Result-Field entry
of a PARM in the *ENTRY PLIST
- Unnamed data structures cannot be exported
- BASED data items cannot be exported
- The same external field name cannot be specified more than once per
module and also cannot be used as an external procedure name
- IMPORT and EXPORT cannot both be specified for the same data item.

IMPORT keyword specifies that storage for the data item being defined is
allocated in another module, but may be accessed in this module. The
external_name parameter, if specified, must be a character literal or
constant.

The following restrictions apply when IMPORT is specified:

- The data item may not be initialized (the INZ keyword is not allowed).
The exporting module manages all initialization for the data.
- An imported field cannot be defined as a compile-time or prerun-time
array or table, or as a data area. (Keywords CTDATA, FROMFILE, TOFILE,
EXTFMT, PERRCD, and DTAARA are not allowed.)
- An imported field may not be specified as an argument to the RESET
operation code since the initial value is defined in the exporting module.
- You cannot specify an imported field in the Result-Field entry of a
PARM in the *ENTRY PLIST.
- You cannot define an imported field as based (the keyword BASED is not
allowed).
- This keyword is not allowed for unnamed data structures.
- The only other keywords allowed are DIM, EXTNAME, LIKE, OCCURS, and
PREFIX.
- The same external field name cannot be specified more than once per
module and also cannot be used as an external procedure name.

On Wed, Jan 7, 2009 at 6:45 AM, Adam West <adamster@xxxxxxxxxx> wrote:

HI In ILE, I have had trouble understanding some of these concepts.

the Procedure, is the same as a subroutine? except for the fact that you
can pass parameters and have different data types?

What is the purpose of prototyping Procedures?

What does the Export and Import do?

Typically the Procedure is bound or is it brought in via a /Copy directive?

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.