How to avoid unforeseen name conflicts in service programs?

Question

Using concepts derived from the famous IBM Red Paper about RPG exception and error handling , I wrote the QGPL/ERRFUNC to implement reuse functions such as Assert , Throw , ThrowMsg , Rethrow and GetErrorMsg . I use them in several different programs, and they work well.

Just now, I used the Throw function in the RPG ILE program, which also statically calls the C-style access function, which is used with stream files in the IFS file system. This program will not compile with the mandatory error “Definition provided several times for the“ Throw ”symbol. As far as I know, you cannot get the binding details when compiling with the CRTBNDRPG , but I was able to comment on my H DFTACTGRP(*NO) , and then compile it using CRTRPGMOD , and then CRTPGM with an additional parameter DETAIL(*EXTENDED) . it provides an exhaustive list of all the procedure names, which looks a compiler, in determining to what procedures need static binding. it is revealed War definition of "Toss". Within the 72-page listing was specified service supplied by IBM program QJVAJNI (the Java the Native Interface) and it contains an exported procedure, also referred to as "the Throw."

Now, the easiest solution to my immediate problem was to simply rename my “Throw” procedure, review and recompile my utility program, and then review and recompile all the programs that link to it. I can follow this solution, but there are a few troubling questions raised by this behavior:

• Why does the C-style IFS function use its own Java interface to do its job? I see imports of QC2IFS such as QC2IFS and QC2POSIX that make sense in context. It seems like IBM introduced an unexpected addiction here that we need to live with. I am sure that this is one of the C QJVAJNI that references QJVAJNI , because when I comment on the call to the access function, QJVAJNI does not. It is possible that the link to the QJVAJNI service program has several levels, which means import import import.

• Why is the binder so carefully rewritten through the import of a service program? The binding looks like it goes through every import that each utility uses, regardless of whether the import is used by the program and related subprocedures. It's necessary? Would not only the import used at each level be recursively checked? Is there any way to change this behavior?

• If there is nothing that could be done on the above two questions, does this mean that to ensure that the binding will always work (especially for "general purposes" such as error handling), you need to be sure that there is no or another exported procedure anywhere on the machine with the same name? I do not know of any objects, such as namespaces, that would alleviate this problem. As far as I know, ILE compilers do not use any approaches, such as overloading or name manipulation, which other platforms can use in this situation. Would it be good practice to start an “unofficial namespace”, as I can see on some of the C exports (like _C_NEU_IFS_feof ) to prevent name conflicts? In addition, is there a way to search for all exported procedures on a machine to find the name you want before publishing a service program?

• The authors of IBM Red Paper are some of the heavyweights in the ILE programming world. They named one of their recommended exports “Throw,” as I did (albeit with a different list of options). Are they having similar problems? Did they have another way to resolve the name conflict?

I found that there is a *DUPPROC option that you can specify for CRTPGM , but I'm not sure if this is a good idea. The documentation says: "If multiple repeating procedures are allowed, the first exported procedure in the list of specified modules and service programs corresponding to the import request is the procedure that is selected." You can be sure which character will be the first in the list? Is the ordering strictly defined?

Answer 1

There is no place for names in RPG or C, if that matters. When you bind ILE programs, the bind directory controls which utilities (and modules) are used to resolve names. This is not every service program in the system. But there are also some utilities that are connected by default, and if you use a name that is exported by one of these automatically linked utilities, you will have problems with duplicate names. You are right, *DUPPROC is a bad idea. The only way to deal with names that duplicate procedures in automatically linked utilities is to not define new procedures with these names. Some names use pseudo- serviceprogramname_procedurename methods, such as serviceprogramname_procedurename or applicationprefix_procedurename when naming them. Others just make sure their procedures have unique names in other ways. But while the RPG does not support some form of namespace, you will need to use some kind of arbitrary naming scheme to ensure the uniqueness of procedure names.

By the way, there is RFE in developerworks to add namespaces to RPGs. You need to be logged in to work with developers so that you can work, but you can register for free. Then visit Radio Liberty and vote for it.