[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: EXPORT, IMPORT and FTPAPI
Thanks, Charles.
That would seem cleaner - but the fact is, that?s what we have now, and as
Scott indicted in the comments, the module is larger than we might lock.
Maybe I'm missing something but I cannot envision a way to put all the
references to MODS subfields into one module without limiting ourselves to
only that one module, since the multi-occurrence variables are used all over
the place. (Consider, for example, wkErrNum, which is a subfield of MODS
wkSession...) So I'm interested - how would you pull this off? (It's a
serious question; maybe I'm missing something important.)
The only cleaner-looking way _I_ can come up with for this, is to use
pointers exclusively, especially if we're going to keep V4 compatibility.
But that would move the initialization of the variables away from their
definitions. Maybe that's not such a big deal, but I think there's value in
having the definition tied to the initial values. And I really like that
one RESET can set a slew of variables to their initialization values.
Apparently someone else liked that, too.
Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Always live within your income, even if you have to borrow money to do so."
-- Josh Billings
> Wouldn't it be easier, not to mention cleaner, to simply put the
> session stuff in it's own module?
>
> Then, both your FTPAPIINT and FTPAPIEXT modules would just make calls
> into it.
>
> Charles
>
> On Sun, Oct 17, 2010 at 8:21 AM, Dennis Lovelady <iseries@xxxxxxxxxxxx>
> wrote:
> > I realized after sending that last message that that solution won't
> work.
> > So here's what I came up with, using wkSession as an example:
> >
> > * Session. A session is used to store the attributes
> > * on a FTP connection .
> > D pWkSession S *
> > D/If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> > D Export Inz(%Addr(wkSession))
> > D/Else
> > D Import
> > D/EndIF
> > D wkSession DS
> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> > D Export occurs(MAX_SESSION)
> > /Else
> > D based(pWkSession)
> > /EndIF
> > D wkActive 1
> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> > D Inz(*OFF)
> > /EndIF
> >
> > .. and then in cmd_occurSession:
> >
> > c wkSessionIdx occur wkSession
> > c eval pWkSession = %addr(wkSession)
> >
> >
> > So when we're in the module with the un-exported data structure, we
> treat it
> > like a MODS. But when we're in the other module(s) it is a based
> data
> > structure. And when we set the occurrence of the structure (which
> > absolutely positively must be in the same module as the un-exported
> MODS),
> > we also set the basing pointer, so that all modules see the same
> thing.
> >
> > I had considered simplifying these definitions a bit, by removing the
> > INZ(...) values (they could be initialized in CreateSession), but
> decided in
> > favor of keeping the value with the definition. What do you think?
> >
> > This all seems to be working, but I welcome comments. How have
> others
> > addressed this? I *must* be missing some simple technique, since all
> this
> > /IFDEF ... /ELSE ... /ENDIF code is just ugly!
> >
> > Dennis Lovelady
> > http://www.linkedin.com/in/dennislovelady
> > --
> > "In times like these, it helps to recall that there have always been
> times
> > like these."
> > -- Paul Harvey
> >> -----Original Message-----
> >> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> >> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Dennis Lovelady
> >> Sent: Saturday, October 16, 2010 1:09 PM
> >> To: 'HTTPAPI and FTPAPI Projects'
> >> Subject: RE: EXPORT, IMPORT and FTPAPI
> >>
> >> Found it. Don't like it, but I found it.
> >>
> >> I don't know if this is a bug, or by design. Apparently the
> Occurrence
> >> of a
> >> MODS or variable is maintained at the module level.
> >>
> >> I've posted a sample 3-module program at <
> >> http://code.midrange.com/0078aaf460.html > to demonstrate, if you're
> >> interested.
> >>
> >> Actually, I'd like to know if that's still a true at i6.1 and/or at
> >> i7.1.
> >> Depending upon the results, I may bring this to the RPG400 list
> (though
> >> I
> >> suspect it may be by design).
> >>
> >> The obvious answer is to put an unexported cmd_occurSession into
> each
> >> module, but the maintenance of that could get messy. Maybe the meat
> of
> >> that
> >> routine needs to be /Copy? Any ideas?
> >>
> >> Dennis Lovelady
> >> http://www.linkedin.com/in/dennislovelady
> >> --
> >> CONGRESS.SYS corrupted. Reboot Washington DC <Y/N>?
> >>
> >>
> >> > I'm working on the task of separating FTPAPI into modules on a
> V5R3
> >> > machine.
> >> > (No promises yet; it's still early. ;) ) I got everything to
> compile
> >> > and it
> >> > looks well but I've run across an unexpected result.
> >> >
> >> > Basically, I had to create a new header file that's exclusive to
> the
> >> > internal operation (so that, for example, wkSession may be shared
> >> among
> >> > its
> >> > peers). When compiling one module, wkSession must be defined;
> when
> >> > compiling any others, it must be imported. And of course we
> cannot
> >> > specify
> >> > INZ on an imported field, so basically the definition looks like
> this:
> >> >
> >> > D wkSessionIdx S 10I 0
> >> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> >> > D Export Inz(INT_NULL)
> >> > /Else
> >> > D Import
> >> > /EndIF
> >> >
> >> > < ... >
> >> >
> >> > D wkSession DS occurs(MAX_SESSION)
> >> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> >> > D Export
> >> > /Else
> >> > D Import
> >> > /EndIF
> >> > D wkActive 1
> >> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> >> > D Inz(*OFF)
> >> > /EndIF
> >> > ------------- 8 data records excluded -------------------
> >> > D wkErrNum 10I 0
> >> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> >> > D Inz
> >> > /EndIF
> >> > D wkSocket 10I 0
> >> > /If DEFINED(FTPAPI_INTERNAL_FUNCTIONS)
> >> > D Inz(INT_NULL)
> >> > /EndIF
> >> >
> >> > The other thing you need to know for my question is that there's
> an
> >> > FTPAPIINT and an FTPAPIEXT module. It's not beautiful but it does
> >> > compile.
> >> > If you have other suggestions, I'm wide open. :) But the
> >> unexpected
> >> > effect is that within FTPAPIINT (which is compiled with
> >> > FTPAPI_INTERNAL_FUNCTIONS set) everything is fine. But it appears
> as
> >> > though
> >> > FTPAPIEXT (which lacks the DEFINE for FTPAPI_INTERNAL_FUNCTIONS)
> has
> >> > its own
> >> > copy, since changes to (in this case) wkSocket within FTPAPIINT
> don't
> >> > seem
> >> > to have an effect on wkSocket as referenced in FTPAPIEXT.
> >> >
> >> > So is my thinking off base here? Shouldn't there be exactly one
> copy
> >> > of
> >> > wkSession, and shouldn't it be shared? If there were two copies,
> >> then
> >> > the
> >> > CRTSRVPGM command would fail, right?
> >> >
> >> > When this code executes
> >> > c if selectSession(peSession) < 0
> >> > c callp SetSessionError
> >> > c return -1
> >> > c endif
> >> >
> >> > c if peNewDir = '..'
> >> > c if SendLine(wkSocket: 'CDUP') < 0
> >> > c return -1
> >> > c endif
> >> > c else
> >> > c if SendLine(wkSocket: 'CWD '+peNewDir)
> >> >
> >> > In debug mode, I can see that within selectSession(), wkSocket has
> a
> >> > value
> >> > of 4 upon its return. But FTP_chdir() disagrees, having a value
> of -
> >> 99
> >> > for
> >> > wkSocket, which we can see above should be an imported variable by
> >> > virtue of
> >> > the DS import.
> >> >
> >> > What might cause this effect?
> >> >
> >> > Dennis Lovelady
> >> > http://www.linkedin.com/in/dennislovelady
> >> > --
> >> > "Nature gave man two ends - one to sit on and one to think with.
> Ever
> >> > since
> >> > then man's success or failure has been dependent on the one he
> used
> >> > most."
> >> > -- George R. Kirkpatrick
> >> > ------------------------------------------------------------------
> ---
> >> --
> >>
> >> --------------------------------------------------------------------
> ---
> >> 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
-----------------------------------------------------------------------