Gord, I can supply more details later, (running off to play golf....), but
wanted to give you some ideas.
I am sure there are ways to extract the status of MQ using API, but I didn't
want to go down that route. Our box that runs MQ is very old (3.7), but
due to the cost of adding that to any larger systems we own, we have decided
to just leave it be. MQ is about all that happens on that box and it runs
flawlessly.
Our activity is very high with USCS. It is very rare that we would go more
than a few minutes without receiving data during the week and an hour on the
weekends.
I have separated our MQ processing into two jobs that run in a subsystem. A
"receiver" job, just waits for data to hit the queue, and then uses the MQ
API to pick the data off and write the data to a PF. This job sits in a
DEQW status and its only function is to take the data from the MQ queue and
add data to the PF. The other job is the "processor". It runs in a 100
second interval. It copies the data from the PF the listener gathers into a
file in QTEMP (of course the proper locking is done to prevent data loss),
and then runs it thru the translation process and database update on the
iSeries boxes that run the applications.
In the receiver job, I write to a data area every time I get data from
customs.
For sending data, I basically just drop the data onto the queue and it goes,
but I wrote a command that extracts the queue depth.
Then I have a monitor job (and screen) that checks to be sure the outbound
queue depth is 0 (if it not, then after 20 minutes it runs thru an automated
process of ending the MQ channel and restarting, and after 30 min if the
queue does not clear, I get a text message). For the receive side, my
monitor checks the last receive date/time in the data area and if it is over
the threshold parameter (currently 60 min during the week and 4 hours on the
weekend), I get a text message. The monitor does not run after 10pm or
before 6am.
The monitor also pings the IP address of the MQ channel to check to see if
the connection is up or down, and reports that to me immediately as well. I
can not tell you how many times I have called USCS to tell them their
network went down. This is a far cry from how we did it 5 years ago when we
used dialup MSRJE. It was nothing but constant babysitting and very poor
performance. Our MQ system is bulletproof, and I never, ever think about it
any more. I think we went to MQ over frame about 3 years ago.
Below is a snapshot of our AMS system monitor:
4/27/07 Display AMS Status
VAN400
9:49:46 Alert pages are send to . .: PAGECARL@xxxxxxxxxxxxxxxxx
Current AMS mode . . . . . .: *MQ
Last dial up time . . . . .:
Last dialup event date/time :
MQ processing delay (secs) .: 000100
Monitor Alert Status . . . .: *ON
Monitor Processing Delay(sec) 000600
Snooze wake up time . . . .:
Last MQ Receive date/time .: 4/27/2007 9:49:37
Current Receive Queue Depth.: 0
No receive data wait (sec) .: 000060
MQ Link status . . . . . . .: UP
Last MQ Processing date/time: 4/27/2007 9:48:01
MQ Receive *ON/*OFF . . . .: *ON
Received records waiting . .: 48 in file: EDIMQIN
Last send queue status = 0 .: 4/27/2007 9:46:23
No send auto-recovery (sec).: 0020
No send alert (sec) . . . .: 0030
Current Send Queue Depth . .: 0
Last Monitor post date/time.: 4/27/2007 9:46:35
F3-Exit F5-Refresh F8-Display Received data F12-Cancel
F15-Snooze
F17-Toggle Monitor ON/OFF F18-Chg MQ Proc delay F19-Chg Monitor
Delay
When an item is an issue, the color of that item turns red. It has worked
great for us. Let me know if you have any other questions.
Carl J. Galgano
EDI Consulting Services, Inc.
770-422-2995
www.ediconsulting.com
600 Kennesaw Avenue
Suite 400
Marietta, GA 30060
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Gord Hutchinson
Sent: Friday, April 27, 2007 8:10 AM
To: Midrange Systems Technical Discussion
Subject: Re: MQ Newbie Question - Msgs To Receive??
Carl thanks for your response.
We are setup now for internet VPN. We set the original connection up about
a year ago and I wasn't directly involved in getting it set up (that's what
network guys are for!) but I don't recall them offering any other option
than VPN.
I knew you had mentioned your US Customs set up before and I was going to
email you off-line because a) they didn't seem to be getting our data and b)
we weren't receiving anything from them. After about 40 minutes we got
email confirmation that they did get our file but we never received any 997s
or 355s (We were expecting the 997 not the 355 because our 309 inadvertently
got sent twice and on their end it apparently looked like all the segments
were duplicated).
Talking to their network people, they showed the data coming in at pretty
much the exact time I sent it. Why it took 40 minutes to get into the
application I don't know. Turns out we didn't receive a response because
someone <cough, cough> had typed the wrong port number on the start of the
listener. Fixed that and got the 997s.
I know I've got a lot to learn about this MQ stuff. I need to figure out a
way to determine which jobs need to be running and capture when anything
isn't. I'd love to know how you are monitoring the channels. I'm not an
RPG expert. We're using Gentran's MQ commands as a cop out so we didn't
have to do anything in our application. I can control the mapping and send
in a CL external to our dispatching application.
In a way I'm concerned than MQ appears to be so stable and reliable. If
something just runs in the background and you don't work with it
consistently, it's hard to retain knowledge.
Thanks again for your pointers.
Gord
On Fri, 27 Apr 2007 07:16:14 -0400, "Carl Galgano"
<cgalgano2@xxxxxxxxxxxxxxxxx> wrote:
Gord,
I run a service bureau for several ship lines. We support trade AMS
applications with US Customs for the ocean standard. For our
application, when we send a 309 document (manifest), USCS only sends
back a 997 FA if there is a problem with the data. In our case, when
we send a 309, they return a 355 document with the disposition of the
manifest to let us know what B/Ls in the manifest were accepted.
Michael is correct, use the WRKMQMQ command to look at all the queues
on your system. Your receiver queue will be defined as *LCL.
You can also look at the MQ channels (WRKMQMCHL). You can try to start
your receiver channel as well (option 14). I have written an MQ
monitoring system that keeps track of when we last received data from
Customs and if too much time has past, it initiates auto recovery.
Sometimes programmatically, especially when sending data, our outbound
Queue will stop, and the solution has been to stop and restart the channel.
FWIW, our MQ connection to USCS has been VERY reliable, and much better
than the old dial up MSRJE connection we had 5 years ago. We just
received work that USCS is dropping MQ over frame relay support, and we
need to convert to MPLS or internet VPN. Have you guys done this yet?
We are opting for the internet-VPN option. While the physical
connection will change, as far as I can tell, we wont have to touch our
middleware or applications.
Regards,
cjg
Carl J. Galgano
--
Gord Hutchinson
Database Administrator, IT
TST Overland Express
ghutchinson@xxxxxxxxxxxxxxx
905-212-6330
fax: 905-602-8895
--
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.
midrange.com
