[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EXPORT, IMPORT and FTPAPI
Dennis,
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
-----------------------------------------------------------------------