RE: Data Transfer Tool -- MIDRANGE-L

Whoever set this up did a fine job.  I can see a good case for a setup 
like this.  If the iSeries is doing a critical backup, period end 
processing, or some such thing, then the PC continues to load the stuff 
into the data queue.  When the backup is done it fires back up the data 
queue job.  It catches up and waits on the next data queue entry.  By 
replicating the data on the PC production can continue during these times 
of data outages.  A reasonable data queue program is very close to 'real 
time'.  I've written some myself.  We used to have such a setup when we 
did wire manufacturing and had shop floor computers that fed constant 
information to the AS/400.

As far as not seeing the job associated with the user...   There will 2 or 
3 jobs.  One job will be the data queue processor.  That will run under 
one user.  And not necessarily the user associated with the PC.  Then 
there will be the job that communicates with the PC.  This may be running 
under some IBM type user.  However if you do a WRKOBJLCK OBJ(ROB) 
OBJTYPE(*USRPRF) you will see some jobs that do not have that users name. 
Like the following
Job          User 
QZLSFILE     QUSER
ROBS1        ROB 
Looking further at the first job you will see something in it's joblog 
like
Servicing user profile ROB from client xxx.xxx.xxx.xxx.
This is how you find the job associated with the PC user.
Finding it, and getting any useful information out of it, are two 
different things.
Now, the third job is an optional job that may happen if the data queue 
processor submits another job to actually post the data queue entry versus 
doing the posting within the data queue processor itself.  You could go 
either way depending on your unique business needs.

Now, back to jobs that run automatically, do you mean that when data is 
updated on your 400 you want it to automatically feed down to your PC or 
do you want to automatically submit the data queue processor that posts 
the data from the pc to the 400?

If you are thinking the former, you could be a trigger on the data bases 
on the 400.  When a record is updated it could automatically post the 
change to the data queue.  And when your PC checks the data queue it's 
ready to post.  As far as the latter, I don't think that's a good idea. 
The data queue processor on the 400 might be down because of a critical 
backup, etc.  Instead of looking for it by user id, try looking for it by 
job.  Like WRKJOB DATAQP or whatever the job name is.  On certain critical 
never ending jobs we've been known to put out other job monitors that will 
alert people when they are not running.  We 'rolled our own'.  But if you 
have a tool like ROBOT they might have something like this.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





Tena Hewes <THewes@xxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
10/12/2004 06:43 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
"'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
cc

Fax to

Subject
RE: Data Transfer Tool






Phew! Ok, let me see if I can clarify...
We have an application that runs on SQL server (An SQL database w/ an 
Access
user interface). 
Currently, we have a program running in Access (VBA) on our SQL server 
that
"looks" at the AS400 DQ (out) every minute to determine if there is any 
data
needing to be transferred. When there is, it is imported in to a "holding"
table, where a stored procedure processes it. We also need to do the same
thing backwards. There is another holding table in our SQL application 
that
stores the data waiting to be transmitted back to the AS400 and sends it 
to
another AS400 DQ (in) where the AS400 takes over. 
This whole process is in place to make sure data (Inventory, PO's, Orders,
etc.) is synced up on an ongoing basis. Timed data feeds going from the
AS400 to our SQL app. are reasonable, but coming from the app. to the 
AS400
need to be "real-time".
Ok, the problem is this interface program between the AS400 and the SQL
server does not make me feel "warm and fuzzy". It has to always be 
running,
and if you happen to log on to the server as another user, you may not see
it running on your session. I really want something "hands-off". I want to
be able to set up 'jobs' on my SQL server (or AS400, if I know what I am
doing) that run automatically, so these data queues are populated behind 
the
scenes.

In answer to the following:
"Do you have iSeries Access?"
I am assuming you mean can I get my hands on it? Yes.

"One possibility is to export the data from Access into a different file
format."
Like Excel?

"Judging by what I perceive your background to be, you might find it 
easier
to create this intermediate file in DB2 using iSeries Access Navigator
Database tool."
Where would I find this? My background (other than an AS400 user) is
completely PC based. I like pictures!!! I try to navigate in the AS400 by
clicking...:( )

"There's other little tricks, like CCSID but that's one general path to
walk."



I hope this explains some things?
Thanks so much for the responses!
Tena

"-----Original Message-----
From: michael@xxxxxxxxxxxxxxxxxx [mailto:michael@xxxxxxxxxxxxxxxxxx] 
Sent: Monday, October 11, 2004 3:49 PM
To: Midrange Systems Technical Discussion
Subject: RE: Data Transfer Tool

Hi Tena...we were all newbies once...welcome! Make sure you drop by the
Midrange-L table at CUDS Sunday night at COMMON and you'll be able to
meet some of the folks that frequent this place."


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