RE: Creating a service program

So Brad, tell us what you really think!

"*all" depends on why you are creating the service program.

Case 1: many application programs will use one or more routines in a service
program.

Case 2: a few application programs were modularized and use a service
program.

In case 2, *all is fine.  If case 2 is a product, when you ship a new
program set, there is no pain associated with sending new service programs
either.  If case 2 isn't a product.  If you change the service program, you
can recompile the program set and it only takes extra compile time.

In case 1, *all is probably a bad idea.  If you are shipping programs as
part of a product then *all is a very bad idea.  When you compile a program
that uses a service program, the compiler stores a signature for the service
program in to the compiled object.  Very much in the style of storing
database format levels into a program.  If you change ANYTHING in the
service program, the service program acquires a new program signature.  The
new signature won't match to the one stored in the compiled programs so you
have to recompile all the application programs that uses the service
program.  In other words, you can't ship a new service program without also
shipping everything else with it.  This is highly annoying if one of your
customers modified one of your programs.

Brad, if your advise is followed, the inside of the service program is
controllable without forcing a recompile.  That is why it is a good idea -
the service program becomes a "black box" and that is very good for
maintenance.

disagreements?  blaze away :)

Richard Jackson
mailto:richardjackson@richardjackson.net
http://www.richardjacksonltd.com
Voice: 1 (303) 808-8058
Fax:   1 (303) 663-4325

-----Original Message-----
From: owner-rpg400-l@midrange.com [mailto:owner-rpg400-l@midrange.com]On
Behalf Of Stone, Brad V (TC)
Sent: Tuesday, August 22, 2000 12:42 PM
To: 'RPG400-L@midrange.com'
Subject: RE: Creating a service program


No no no!

Do not use *ALL for export.  I repeat, do NOT.  This takes away the reason
for using binder language in the first place, having multiple version of a
service program.

Sorry, but when I taught myself ILE, I learned the hard way that *ALL is a
no no when creating service programs.

Brad

> -----Original Message-----
> From: Paul Jackson [mailto:paulgjackson@yahoo.com]
> Sent: Tuesday, August 22, 2000 1:08 PM
> To: RPG400-L@midrange.com
> Subject: Re: Creating a service program
>
>
> Mike
>
> The source file you have specified is only used when
> specifying the exports to be used by the service
> program, this is not the source for the modules.
> The CRTSRVPGM command works on the module objects not
> the source.
>
> If you really want to make all the procedures
> available outside of the service program, specify
> EXPORT(*ALL) and you should have a working service
> program.
>
> Hope this helps,
> -Paul Jackson
> Costco Wholesale
> --- Mike Silvers <msilvers@hbs-inc.com> wrote:
> > I am trying to create my first service program.
> > This service program is a
> > group of procedures (NOMAIN) and I have successfully
> > created a module from
> > the source.  The source for the procedures is in a
> > library in the source
> > file QRPGLEPROC.  My problem is creating the service
> > program.  It will not
> > be created and there are errors.  The command and
> > errors are as follows:
> >
> > Command:
> >
> > CRTSRVPGM SRVPGM(EMLTOOL/EMLSERVC1)
> > MODULE(EMLTOOL/EMLSERVC1)
> > EXPORT(*SRCFILE) SRCFILE(EMLTOOL/QRPGLEPROC)
> > SRCMBR(EMLSERVC1)
> > ACTGRP(EMLTOOL)
> >
> > Errors:
> >
> > EMLTOOL/QRPGLEPROC.EMLSERVC1 line 1: ***ERROR Syntax
> > not valid.
> > EMLTOOL/QRPGLEPROC.EMLSERVC1 line 1: ***ERROR No
> > 'current' export block
> > Binder language compilation failed with 2 errors and
> > 0 warnings.
> > Service program EMLSERVC1 not created.
> >
> > Any help is appreciated....
> >
> > Thanks
> > Mike
> >
> >
> >
> >
> >
> >
> > Mike Silvers, IBM Certified Expert
> >
> > Hainey Business Systems
> > 8 E. Canal St
> > Dover, PA 17315
> > Branch Office:  (410) 397-8739
> > Phone:  (800) 932-3380
> > Fax:  (717) 292-9474
> > Web: http:\\www.hbs-inc.com
> > ________________________________
> > Providing E-Commerce, EDI, AS/400
> > Development and related services
> > nationwide.
> > ________________________________
> >
> > +---
> > | This is the RPG/400 Mailing List!
> > | To submit a new message, send your mail to
> > RPG400-L@midrange.com.
> > | To subscribe to this list send email to
> > RPG400-L-SUB@midrange.com.
> > | To unsubscribe from this list send email to
> > RPG400-L-UNSUB@midrange.com.
> > | Questions should be directed to the list
> > owner/operator: david@midrange.com
> > +---
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
> RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
> david@midrange.com
> +---
>
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---