[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ftpapi] Two Versions of expat
The last version of HTTPAPI that worked with the old UTF-8 compile of
Expat was version 1.16. The UTF-16 version of Expat has been used since
1.17 was released, which was in late 2006. Has their been any
modifications since then? Absolutely. But, nothing since late 2006
that would require you to do anything to your existing programs.
I do not know what version you are running. The fact that you
*compiled* it in 2008 does not necessarily mean that you were compiling
the latest version that was available at the time. (But, it seems likely?)
At any rate, why not install the latest HTTPAPI and Expat into a
separate library just as a test and see if it works?
If you still have the source code for HTTPAPI, you might be able to
glean a bit more about what's going on by:
1) Look at the HTTPAPI_H member and see if there's an HTTPAPI_VERSION
defined in it. If it's there, it'll tell you the version of HTTPAPI.
Very old versions of HTTPAPI might not have this, but you can also look
at the CHANGELOG source member which shows all the changes made. The
topmost entry in there will tell you the version at the time it was
2) Look at the bindings in your programs (DSPPGM or DSPSRVPGM commands)
and see if they use an explicit library or *LIBL.
DSPPGM PGM(MY-PROGRAM-THAT-CALLS-HTTPAPI) DETAIL(*SRVPGM)
If it is using *LIBL, then you can install HTTPAPI and EXPAT in a
different library, and test it out simply by using a different library
list. Again, unless the version of HTTPAPI is older than 1.17, it
should "just work" no need to compile or bind or change anything.
Of course, if nothing else, you could back up your existing HTTPAPI and
EXPAT, then rename the original library and install the new version in a
library of the same name. Then try your existing programs, and if they
work, great... if not, you could restore the old copy to get back
online. This method would require a short downtime window to backup,
install the new one, and test it. But it should be short.
Same with your question when you say "It looks like if I just copy the
expat service program into the new HTTPAPI library, all expat function
will pick up the new expat in the new HTTPAPI library. Is that a correct
assumption?" I'm not totally sure that I follow you. Yes, you should
restore Expat into the same library with HTTPAPI. Whether "everything"
will pick up that change depends on how you bound your programs to it,
did you use *LIBL or a fixed library? Are you restoring to the same
library name, or is your library list updated to point to the new one?
None of this really has anything to do with Expat or HTTPAPI -- it's
just the basic way that the IBM i operating system works. If something
is called explicitly by library, it uses that library. If something is
called via *LIBL it searches the library list...
On 2/2/2018 2:39 PM, Dan A. Nelson wrote:
The version of expat we have installed was installed in 2008, as was
HTTPAPI. HTTPAPI was installed without SSL support. Was expat modified
I’m trying to avoid having to find and recompile all the programs that
use either expat or httpapi by installing both into alternate
libraries. It looks like if I just copy the expat service program into
the new HTTPAPI library, all expat function will pick up the new expat
in the new HTTPAPI library. Is that a correct assumption?
COKeM International LTD
Senior Programmer Analyst
This email has been checked for viruses by AVG.
Ftpapi mailing list