[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 released.

2) Look at the bindings in your programs (DSPPGM or DSPSRVPGM commands) and see if they use an explicit library or *LIBL.


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 after 2008?

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?

/Dan Nelson/

COKeM International LTD

Senior Programmer Analyst

Office: 952-358-6069

Fax: 763-544-4100

dnelson@xxxxxxxxx <mailto:dnelson@xxxxxxxxx>

This email has been checked for viruses by AVG.

Ftpapi mailing list