[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 16:40:43 -0500
Sorry, I should have been specific.  I am referring to the FTPAPI* stuff
I've been working on for the past however long.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
You can't have everything.  Where would you put it? 


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

-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
References:
- RE: Exit points and next version
  - From: Dennis Lovelady
Prev by Date: RE: Exit points and next version
Next by Date: RE: gsk_sec_soc_open: (GSKit) Handle is not valid.
Previous by thread: RE: Exit points and next version
Next by thread: Re: Exit points and next version
Index(es):
- Date
- Thread