× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Simon,

<snip>
Not true. You can't get protected semantics but you can simulate package behaviour.


Specifying EXPORT will always export the variable or procedure from the module but it is only available to other modules that directly bind to it. If the module containing EXPORT is bound into a service program then EXPORT means it is a candidate for export. Whether it is visible by consumers of the service program depends on the the setting of EXPORT on CRTSRVPGM. If you use EXPORT(*ALL)--really dumb for reasons explained in the archives--then any candidate export will be visible. If you use binding source then you can omit the candidate variable or function from the public interface. It will still be available to other modules bound directly into the service program but will not be accessible by consumers of the service program.
</snip>


The problem with simulating "package behaviour" is that the "package" is a single program object. What I would like for Christmas is to be able to allow only selected (service) program object to be able to bind to selected exported procedures from another service program object.

For example, say I am writing a service program that uses several of my utility service programs and I want to access some data items within the utility service programs from within my service program.

Now, I could set the data items as exported - but that will only allow the data items to be imported by other modules within the same service program - as far as I'm aware it is not possible to export a data item outside a (service) program object. So my only alternative is to create getter methods to allow my service program access to the utililty service programs' data items. This would be my preferred approach to access data items.

Here's the rub - to export the getter method I would flag it as EXPORTable and compile the module. I'd then explicitly export the getter method from the service program object using binder language. BUT this is now available to ANY program that binds to the utility service program. There is no way (that I know of) that the utility service program can determine whether it should export or not.

This is pretty much what I meant by not having "package" access to data. To me the collection of bound service programs form the package.

Having said that, as we can only perform early binding, it isn't as much of an issue as it would be if we could perform late binding.

Cheers, and Happy Christmas

Larry Ducie



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.