Can new version of HTTPAPI happily co-exist with an old version?

[blueivy2025]

We are:

- running v7r4 - not sure when this will be upgraded.

- running a (very?) old version of HTTPAPI which is supporting a vendor well

- new business requirements REQUIRE OAuth2, which installed version of HTTPAPI doesn't support

- want to install NEW version HTTPAPI (in different library, etc.) and test with new process without impacting current production

- once everything is good, we probably decommission old version of HTTPAPI

So we need to have two versions of HTTPAPI on the system while we transition to our new application.

Thanks!

[Scott Klement]

There is no version of HTTPAPI that "doesn't support OAUTH2". HTTPAPI supports HTTPS, with which you can authenticate to an OAUTH2 server.

That said, when you run software that communicates over the Internet, you should ALWAYS keep it up to date to ensure you have the latest bug and security features, otherwise you are putting your business at risk!

HTTPAPI is always backward compatible (unless you've made your own changes to it.) So replacing it never breaks old applications that use it.

[blueivy2025]

Thanks Scott!

Based on at least one of the installation methods, it appears a non-default library can be used to install HTTPAPI. Does this mean a newer (new) version of HTTPAPI can co-exist with an older version?

Thanks again-

[Scott Klement]

Yes, that's no problem.

[emaxt6]

If you want to be sure or do testing you can DSPPGM the program you want to test, this will show to which SRVPGM is bound.

If they are *LIBL bound (and not hardwired) you can test the program putting the new libraries on top on a test session...