Re: [Ftpapi] Two Versions of expat

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Dan,

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.

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

-SK


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.
http://www.avg.com

--
_______________________________________________
Ftpapi mailing list
Ftpapi@xxxxxxxxxxxxxxxxxxxxxx
http://scottklement.com/mailman/listinfo/ftpapi