一 基本概念：
Service program是由module和其他Service program组成的，在系统中用*SRVPGM来表示（好像是废话- -!），其包含了很多可被其他程序调用的procedure。
Service program是用by reference方式绑定，功能类似于其他语言的函数库，提供了很多procedure供其他ILE program调用。
Service program中哪些procedure可以被其他program调用，哪些不可以呢？这就牵扯到了Service program中一个非常重要的概念：public interface。

二 公共接口（public interface）
Service program的public interface规定了哪些procedure和data item可以被外界使用，哪些不可。如果public interface设置的不合理，很容易产生program与Service program不兼容的问题，导致程序发生异常。那么如何定义Service program的public interface呢，如下：
CRTSRVPGM命令的EXPROT参数规定了Service program如何对外提供接口，并提供2个参数值：
1 EXPORT (*ALL)。选择*all的话，那么Service program里所有使用key word：EXPORT修饰的procedure和data item都可以被外界程序使用。
2 EXPROT(*SRCFILE)。*SRCFILE是默认的参数值。使用*SRCFILE的话，可以使用binder language（BND文件）来自定义public interface，自己选择哪些procedure和data item可以被外界使用（这些 procedure、data item也必须使用key word：EXPROT修饰）。
注：binder language的文件类型是BND，默认的SOURCE FILE是QSRVSRC，并且BND文件是不需要编译的。

下面说一下*ALL和*SRCFILE各自的优缺点:
*ALL的优点：使用起来非常方便，不需要额外的辅助文件，Service program中所有的export procedure 和data item就都可以被其他程序调用。
*ALL的缺点：兼容性太差，无论增加或者减少Service program的export procedure、data item，都会导致program与Service program的不兼容。那么所有用到此Service program的program都需要重新绑定(UPDPGM)或者重新编译（CRTPGM）才能正常使用。就算是这种变化并不会影响程序的正常运行（比如说你向Service program中追加了一个新的procedure，并且现程序并不使用此procedure，即增加procedure不影响现在的程序运行）那么所有用到此Service program的program也要重新绑定或编译。很麻烦吧。
*SRCFILE的缺点：*SRCFILE使用起来要比*ALL麻烦些，因为要使用binder language定义BND文件才能使用。
*SRCFILE的优点：提供了很好的兼容性。即增加或者减少Service program 的 export 的procedure、data item，程序仍然运行，不需要重新编译相关的program。

那到底是什么原因产生的兼容性问题？听我慢慢道来