|
Does the SQL database support the concepts of Triggers? If so, then instead of a separate monitoring service couldn't a trigger run that would update the data queue on the 400? 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 09:47 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 Rob, The SQL app is supposed to actually be our new Inventory Management/Scheduling tool. It was purchased last year. It will do all of our inventory tracking, job scheduling, purchasing, and receiving. Users will scan on and off jobs; use the handhelds to receipt material to stock, etc. We also use handheld and truck-mounted LXE devices, which connect directly with the AS400. -----Original Message----- From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] Sent: Tuesday, October 12, 2004 10:26 AM To: Midrange Systems Technical Discussion Subject: RE: Data Transfer Tool What value add is the SQL server performing, other than reading the handheld devices on the shop floor? We are using wireless handheld devices to communicate directly to our i5. Been in place for a few years now. 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 09:00 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 Thanks Rob, Just to clarify: The "always running program" for data transfer runs on our SQL server (written in VBA with an Access front end). When you remotely log on to the SQL server that houses the "always running program", it becomes a mess. Some users can see it, some can't. It is set to automatically start under the administrator account when we reboot our server on a weekly basis, and if you happen to log on remotely as administrator while it is transferring data, another instance of it starts up and you have data issues while the war over which instance is going to handle the data occurs. It is an accident waiting to happen. The AS400 handles all of this beautifully, but I know there has to be an easier, less dangerous way to do this. It is really critical to have the "real-time" transfers from the SQL database to the AS400, as production data will be transmitted as users are using handheld devices continuously on the shop floor. Thank you, Tena -----Original Message----- From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] Sent: Tuesday, October 12, 2004 9:37 AM To: Midrange Systems Technical Discussion Subject: RE: Data Transfer Tool 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. -- 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. -- 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. -- 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. -- 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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.