Re: CPYTOIMPF - different issue

["Steve Landess" <sjl_abc@xxxxxxxxxxx>]

Brian -
Are you setting on LR in the RPG program?

Steve

----- Original Message ----- 
From: "Brian Schween" <>
To: <midrange-l@xxxxxxxxxxxx>
Sent: Monday, December 13, 2004 11:45 PM
Subject: CPYTOIMPF - different issue


> Any good suggestions on the following issue ?  I have some web pages
providing
> content using RPG-CGI programs and net.data (for some stored procedure
calls).
> On several pages I planned to provide a 'download' button that would
recreate
> the data shown on the page to a file in qtemp, use CPYTOIMPF to get it up
to
> the IFS in .csv format, and then provide a hyperlink where the user clicks
to
> initiate the standard browser 'download' screen (save, open, punt, etc..).
>
> My problem is this;  Apparently, using net.data to call a stored procedure
(RPG
> w/embedded SQL program) on the AS/400 initiates a 'connection' to the
local
> RDB, that remains open.  If you subsequently attempt to execute the
CPYTOSTMF
> command from the same job, you get error SQL0842 - CONNECT to a relational
> database when the connection is active.  It's run by the same job because
the
> http server jobs run all requests.
>
> I tried using commit and disconnect before the command was executed, but
then
> when I returned to the application and tried to use the stored procedure
> function again, it didn't work anymore because the connection was closed
(catch
> 22).
>
> IBM's recommendation was to run the CPYTOIMPF in batch (submit it), but I
have
> a user clicking a button to build a hyperlink to download a file... not
exactly
> the type of thing I want to submit to batch.  Anyone heard of this issue ?
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>