Re: more FTPAPI questions

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


> I guess you do not see the value because you know FTPAPI inside out. 
> Personally, I found it a bit of a bother to read through nearly 50% of 
> deprecated APIs in search of what can be done with this tool.

As I said -- I have no problem with moving the deprecated stuff to a 
different MODULE.   That's perfectly fine with me.  It's moving it to a 
different SERVICE PROGRAM that I have a problem with because it'll destroy 
backward compatibility.


> I'll change the order of the header file (and accordingly the SRVPGM). Will 
> put the current stuff at the front, make a Big and Clear enough separator 
> telling that what follows is there just for the historians and those who 
> never upgrade their programs in decades.

You can move the deprecated stuff to a separate /COPY member if you like, 
then just add some code like this to FTPAPI_H:

      /if not defined(NO_DEPRECATED)
      /include DEPREC_H
      /endif

That way, the deprecated stuff won't be in the same member.  If you put 
the deprecated subprocedures into a separate DEPRECR4 module, then they 
also won't be in the main FTPAPIR4 module, that'll simplify things as 
well.  But, still bind them into the service program, and keep them in the 
same place in the binder source so that existing programs will work 
without needing changes.


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------