[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Exit points and next version

From: "Dennis Lovelady" <iseries@xxxxxxxxxxxx>
To: "'HTTPAPI and FTPAPI Projects'" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
Subject: RE: Exit points and next version
Date: Sun, 12 Dec 2010 15:24:29 -0500
Happy season, everyone!

At long last, the new API source is available - at least from my standpoint.

How should this be delivered?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"I have made this letter longer than usual, because I lack the time to make
it short."
        -- Blaise Pascal 


> So the challenge of adding exit program checking to FTPAPI, and of
> breaking
> the FTP API into smaller modules has borne fruit, and the new product
> is in
> testing phase.  It'll be a couple of weeks before the code is released,
> but
> I wanted to put out this request for comments so that if anything
> important
> has been overlooked, it can be addressed.
> 
> At present, here are the key changes.  I would greatly appreciate any
> comments / questions that come from this.
> 
> Also, I'd like to understand the approach/methodology used for
> submitting
> new versions...
> 
> ---
> 
> The API is now broken into these modules:
>    Externally-exposed routines (such as FTP_Open, FTP_Put, ...) are in
> FTPAPIEXT
>    Session management getters and setters are in FTPAPISSN
>    Internal workings (such as tcp_conn, data reformatters, translations,
> ...) are in FTPAPIINT
>    Exit Program checking is in FTPAPIXTP
>    All of these modules share a single FTPAPIINTH header (copybook)
> 
> ---
> 
> Where reasonable to do so, message constants have been removed,
> replaced by
> message IDs (and FTPAPIMSG message file has been added to the project).
> The
> 60-byte message retrieval mechanism remains in place, with a new
> optional
> parameter (default *Off) that allows longer text to be returned
> (varying
> length, up to 512 bytes.
> 
> ---
> 
> For backward compatibility, socket handle continues to be used for
> session
> selection by the externally-exposed routines. However, where reasonable
> to
> do so, "sessions" are internally managed through Session Index (named
> ssnIdx), and there is greater separation between the use of "socket"
> and
> "session" within the code.
> 
> ---
> 
> The use of MODS is removed, replaced by qualified, based data
> structures and
> on-the-fly memory de/allocation.  (Session management using MODS among
> more
> than one module proved to be far too cumbersome and error prone.)  This
> raises the OS requirement to (at least) V5R1.  The session attributes
> are
> wholly contained within the FTPAPISSN module, and are accessible only
> through setters and getters.
> 
> Emulation of the IBM-supplied FTP Client's usage of Exit points is
> controlled by calling setSysExitPtUsage(*On | *Off).  If this procedure
> is
> not called, this emulation does not occur.  Since IBM's implementation
> supports the rejection of activity at the session level, functions
> setGlobalAbort() and getGlobalAbort() have been introduced to provide
> similar control.  Present code includes code like this every time
> initFtpApi() is referenced:
>    initFtpApi() ;
>    if getGlobalAbort() ;
>       return -1 ;
>    endif ;
>    ...
> 
> Also, key points in the code attempt to ensure that nothing "useful" is
> done
> if Global Abort has been set.  To that end, the following procedures
> contain
> the same "if getGlobalAlert()" block at their tops:  opnFile()
> recvLine()
> sendLine()  sendLine2()  resolveIP()  tpc_conn()
> 
> I can envision other circumstances that would cause us to want to
> setGlobalAbort() but no others besides rejection of session
> initialization
> have been implemented at this time.
> 
> ---
> 
> Several of the procedures have been changed from CONST CHAR parameters
> to
> pointers with attributes VALUE OPTIONS(*STRING).  This eliminates the
> differences between certain functions (like FTP_Conn and FTP_ConnLong).
> 
> ---
> 
> Large sections of code have been converted to free-form.  I expect the
> remaining to be free-form before final release, in about two to three
> weeks
> or so.
> 
> Dennis Lovelady
> http://www.linkedin.com/in/dennislovelady
> --
> "A fashion ten years before its time is indecent. Ten years after its
> time
> it is hideous. After a century, it becomes romantic."
>         -- James Laver
> 
> 
> > Someone at IBM wrote an example retrieve and call exit program. So
> the
> > first step would be fairly simple
> >
> >
> http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic
> > =/apiref/ileRetrieveILERPG.htm
> >
> > Add this code into the ftp procedures. Ignore all results! And presto,
> > all is good. :)
> >
> > It appears that initFtpAPi is called from all exported procedures.
> With
> > a little bit of work to pass the appropriate functions, it might be
> > possible to add the check there. Since initFtpApi doesn't return any
> > parameters, error code would need to be added. Hmmmm, starting to get
> > to be a bit of fun!
> >
> > Good luck if take this on.
> >
> >
> > > -----Original Message-----
> > > From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> > > bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dennis Lovelady
> > > Sent: Thursday, September 30, 2010 4:07 AM
> > > To: 'HTTPAPI and FTPAPI Projects'
> > > Subject: RE: Exit points
> > >
> > > Scott, thanks for your reply, and I quite agree with you!  This is
> > road
> > > well
> > > traveled between me and the other team involved.  This is the same
> > > group
> > > that has completely disabled all CPYSRCF capability via public
> > > authority for
> > > God knows what reason, blind to the fact that CPYF can accomplish
> the
> > > same
> > > end.  I cannot use option 3 on a PDM screen to copy a source member,
> > > but I
> > > can create a new source member and then copy the original into that.
> > > This
> > > is just one clear example of the knowledge base and need for
> control
> > > from
> > > that group.
> > >
> > > They want their bankey.  If it makes them comfortable and makes
> them
> > > feel
> > > like they're in control, then so be it.  You are welcome to take
> that
> > > battle
> > > up with that team - I'll provide phone numbers.
> > >
> > > My goal was not to seek permission, it was to find out how to
> provide
> > > that
> > > bankey.  I will have a look at the easy400 suggestion later today.
> > >
> > > Dennis Lovelady
> > > http://www.linkedin.com/in/dennislovelady
> > > --
> > > "United Nations: Where America feeds the hands that bite it."
> > >         -- Gregory Nunn
> > >
> > > > Quite honestly, I don't see "securing" a client program to be a
> > means
> > > > of
> > > > providing security.  That goes double for one that's open source,
> > > where
> > > > the user can go in and change the way it calls the exit point!
> > > >
> > > > 1) What's to stop the user from downloading/installing another
> FTP
> > > > client program?  (None of the ones in PASE understand exit
> points!)
> > > >
> > > > 2) On your Windows or Linux box (where FTP software is easy to
> come
> > > by)
> > > > would you rely on an exit point if such a thing existed?   When
> the
> > > > user
> > > > can easily download and install another program?  Wouldn't you
> > think
> > > > the
> > > > whole idea of an exit point is kinda silly?
> > > >
> > > > 3) Unlike the IBM client, FTPAPI is designed for use only from a
> > > > computer program.  i.e., a user will never use it directly, and
> > it's
> > > > operation will always be automated by a programmer's RPG program.
> > > > Given
> > > > that, isn't the security supposed to be provided by the program
> > that
> > > > calls FTPAPI?  Rather than FTPAPI itself?
> > > >
> > > > 4) If you add exit point support to FTPAPI, what's to stop a
> > > programmer
> > > > from writing their own FTP client and bypassing the exit points
> > that
> > > > way?
> > > >
> > > > I guess, to me, there's a pretty big difference between a tool
> > > designed
> > > > for the user to use, and a tool designed only as an API to be
> > called
> > > > from programs.
> > > >
> > > > Having said all of that...  if you really want to integrate it
> with
> > > the
> > > > IBM exit point system, feel free to write the code and contribute
> > it
> > > > back to the project.
> > > >
> > > >
> > > > On 9/29/2010 6:56 PM, Dennis Lovelady wrote:
> > > > >
> > > > >     Hi, folks, this is my first post here.
> > > > >
> > > > >
> > > > > As a preface, I have searched the archives for "exit program"
> and
> > > for
> > > > QIBM_QTMF
> > > > > _CLIENT_REQ and for PowerLock with not much result.
> > > > >
> > > > > There was a question from someone in 2004 asking why settings
> in
> > > > PowerLock have
> > > > >   no apparent effect on FTPAPI.  Apparently the poster didn't
> > know
> > > > how PowerLock
> > > > >   works (or how it doesn't, in this case).  Answer: PowerLock
> > > control
> > > > is install
> > > > > ed at the QIBM_QTMF_CLIENT_REQ exit point.
> > > > >
> > > > > Until I started working with FTPAPI very recently, I had
> assumed
> > > that
> > > > IBM someh
> > > > > ow tied that exit point to the FTP ports. (Naive, now I think
> > about
> > > > it.)  Appar
> > > > > ently instead, the FTP client program itself makes the
> necessary
> > > > hooks.
> > > > >
> > > > > I mentioned on another list that our auditors wouldn't allow
> this
> > > > program on on
> > > > > e of the main systems I work with since it seems to lack the
> kind
> > > of
> > > > control th
> > > > > at they want (for example, some users can GET, some can PUT or
> > GET,
> > > > and some ca
> > > > > n only do DIR operations).  (This is all managed by PowerLock
> > > > controls at this
> > > > > point.)
> > > > >
> > > > > So my question is, Have any on this list made an attempt to fit
> > the
> > > > IBM exit po
> > > > > ints with FTPAPI? (I have no clue how that would be done, nor
> if
> > it
> > > > even *can*
> > > > > be done in a supported manner.)  I'd love to use this decidedly
> > > > better solution
> > > > >   but am stymied except on my development machines.
> > > > >
> > > > > I appreciate your responses.
> > > > >
> > > > >
> > > > >     Dennis E. Lovelady
> > > > >     AIM/Skype: delovelady      MSN: fastcounter@xxxxxxxxxxxx
> > > > >     [1]www.linkedin.com/in/dennislovelady --
> > > > >     "Since I moved to suburbia I found out the purpose of those
> > > > railroad
> > > > >     timetables.  Without them there would be no way of knowing
> > how
> > > > late
> > > > >     your train is."
> > > > >            -- Gregory Nunn
> > > > >
> > > > > References
> > > > >
> > > > >     1. http://www.linkedin.com/in/dennislovelady
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > > > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > > > > http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > > ---------------------------------------------------------------
> --
> > --
> > > --
> > > > --
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > > > http://www.scottklement.com/mailman/listinfo/ftpapi
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > > http://www.scottklement.com/mailman/listinfo/ftpapi
> > > -------------------------------------------------------------------
> --
> > --
> > ---------------------------------------------------------------------
> --
> > This is the FTPAPI mailing list.  To unsubscribe, please go to:
> > http://www.scottklement.com/mailman/listinfo/ftpapi
> > ---------------------------------------------------------------------
> --
> 
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list.  To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
Follow-Ups:
- RE: Exit points and next version
  - From: Dennis Lovelady
- Re: Exit points and next version
  - From: Scott Klement
Prev by Date: RE: HTTPAPI have you experienced issues with it leaving files open
Next by Date: RE: Exit points and next version
Previous by thread: RE: Parsing XML with a value that contains a double quote
Next by thread: RE: Exit points and next version
Index(es):
- Date
- Thread