RE: Do you still use *MSGF exclusively? -- MIDRANGE-L

I am not proficient in the alternative programming environments evolution,just in a handful of "standards" I have encountered so far, when modifyingvarious package approaches.

I have found *MSGF a royal pain in the rear to work with. Both fromprogramming implementation perspective, modification perspective, andgeneral troubleshooting when users report problems.

I think application design needs to do a better job of recognizing the realworld of real users, Perhaps ap MSGF* interaction with the users should goto a special MSGQ, like 400 hardware "issues" goes to a configurationmessages Q, in which one of the parameters of invoking MSGF* could be tospecify which MSGQ gets the story. An ap could have different Qs fordifferent types of functions ... customer service, factory orders,engineering glitches, etc. This way, after the users have ended theirsession, without doing the joblog bit, we can see an error history bigpicture, the problems that were reported, and the problems that were notreported, whether the users are getting the same kinds of issues, what'sdifferent in info to them and their responses, are any problems occurringfor different people close in time proximity.

When users have problems that need resolution, the data they supply to ITin the first place can be extremely misleading and incomplete. I generallyask for screen prints of what they saw, including the errormessage. Occasionally I do get that.

When I have the specific error message they got, then I can read the 2ndlevel text that they probably did not. When we have a multitude ofprograms calling programs, which of them issued this message? It might benice if the ap had in the first place included program name as a standardparameter, and maybe even invocation level.

If I find out about their problem while they are still in the sign onsession that had it, then I can see the context of the error message theyasking about, and what response they gave to it, but this is extremely rarefor me.

I have provided my users a signoff menu where they can do normal defaultsignoff, or joblog generation, but it is a lost cause to get them to dojoblog generation when they have had a problem. Heck, 90% of the peopleuse the "X" without first going to the sign off screen. Plus we havenon-IBM hardware in our network that neglects to communicate the differencebetween a normal sign off and some problem with the equipment in between.

GO CMDREF does not seem to offer cross-index capabilities of what programscan call what message #s, so I have to do deeper source searching.


Also MSGF* does not seem to have the usual *LIBL rules.

Suppose I have two similar MSGF* in *LIBL and let's suppose message 1234 isin the first but not second object it gets to in *LIBL ... OS/400 gets tothe first MSGF* does not find message 1234 and stops, does not go lookingin any later MSGF* in the *LIBL.

I not complaining about what it does, only that it seems intuitivelydifferent from other *LIBL functionality.

If IBM ever does make improvements to MSGF* I hope and pray they arebackward compatible, because if we ever had to alter source code to becompatible with some new version, it could be a nightmare. This stuff'susage is systemic in some apps.

Al Mac