RE: Checking an AS/400 DTAARA from SQL Server

[Brad McDaniel <BMCDANIEL@xxxxxxxxx>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
--
[ Picked text/plain from multipart/alternative ]
I'm scrapping that CL idea (although I was deleting the spooled file after
every loop), but thanks for your advice.  I will just use a stored proc,
which will call a CL that will RTVDTAARA and return a result set.

Thanks to all.

Brad

-----Original Message-----
From: David.X.Kahn@gsk.com [mailto:David.X.Kahn@gsk.com]
Sent: Friday, September 14, 2001 8:41 AM
To: midrange-l@midrange.com
Subject: RE: Checking an AS/400 DTAARA from SQL Server



Brad wrote:

> In the meantime, I just created the following CL to run in a continuous
> loop, which creates a file that changes every thirty seconds which can be
> queried from SQL Server.

That will do the trick but one problem with this approach is that the
number of spooled files attached to your NEP will keep growing and
eventually max out, causing the job to crash. A simple alternative instead
of looping round after the delay is to have the job submit another copy of
itself, although you need to be sure that the next incarnation of the job
will become active immediately.

Perhaps a better method would be to have the looping CL repeatedly call an
RPG program which could retrieve the data area and update a single record
file.

If the data area is just a simple switch, yet another option might be to
have three versions of your single record file: an "off" version, an "on"
version and a "current" version. The CL NEP could then retrieve the data
area and depending on the value returned execute a CPYF with MBROPT
(*REPLACE) from either the "on" or "off" file to the "current". SQL Server
then simply queries the "current" version.

Dave...
-------------------------------------
Any opinions expressed are my own and not necessarily those of my employer.


_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
or email: MIDRANGE-L-request@midrange.com
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.