Re: Newbie Question

A related issue in our environment is how some conflicts are resolved with 2
or more people trying to update the same record at the same time. Typically
they need into different fields of same item, customer, order, whatever.

For the batch job, there is an error message from the JOBQ where we can look
at the log of the job, and see the most appropriate response to take.

For the interactive user, there is an error message on the screen saying
something like

"Roger is updating the identical item right now ... you have to wait until
Roger gets done." except the error message is not quite that clear.

Experienced users think this is a good safety ... they get Roger on the
intercom & ask to be notified when he done, then if they find out that Roger
was in middle of update & went to the toilet or other interruption, Roger
gets a hard time. Inexperienced users don't understand how to read error
messages, they think their connection to the 400 is locked up again (problem
with PC or infrastructure) so they kill an update job which was working
fine, thank you very much.

A few years ago our situation was very different from today.
Some program would go into a MSGW, then some user would take an option that
was unhealthly, and make a minor problem 1,000 times worse, then we would
end up spending DAYS repairing errors that would have been avoided had
correct response to error message been taken.

We also had come from experience to know that if certain jobs were being
run, NO ONE ELSE should be running certain other jobs in a family of
jobs ... single threaded interactive environment. Many new users seemed
to "not get the message" about this need for personnel to intercommunicate
what we are doing.

I spent maybe 6 months re-writing the code where the application called for
MSGW to have the application intervene and take care of the problem that
formerly users were responding badly to. A great many repetitive problems
evaporated.

Some of our MSGW were native to the application.
Some were new problems added when we used consultants on a rush project.
The consultants used some programmers who were unfamiliar with the 400.

On Wed, 26 Nov 2008 13:06:21 -0800, Roger Harman wrote

It may not be an issue in your environment but applications can wait

(intentionally) on a message queue to perform some action. Most
would probably use data queues now but there are still apps out
there that rely on messaging.

stephen.a.cochran.lists@xxxxxxxxx 11/26/2008 12:17:18 PM >>>

Al,

Your last sentence stuck home. I took over the IT team here and general
operations were not stable. I've never worked with an application
that was so high maintenance/needy. I have talked to some other
customers but I'm not sure how "unique" our problems are yet.

We get MSGWs on some kind of job at least once a week. Most often on
jobs
that are communicating with other services (CC processing, etc), but
also a
decent amount of time on some of the async processing jobs that the
application always has running. These can hold up new orders being
processed
into the system and yet everything else still works so we never hear
a complaint about them.

I don't have enough experience with the as400 and other applications
to know how common MSGWs are, the feeling here has been that they
happen and you deal with them and move on. I came in with a very
different attitude and asked why the *ell they keep happening? That
shouldn't be the case.

Steve

On Wed, Nov 26, 2008 at 1:32 PM, Al Mac Wheel <macwheel99@xxxxxxxxxx>
wrote:

If the software is well written and managed, getting a MSGW on

something

other than an interactive job should be extremely rare ... like once

in a

blue year.

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

--
WOW! Homepage (http://www.wowway.com)