Message subfile using IBM api QMHSNDPM

1950 pts.
Tags:
AS/400
MSGF
QMHSNDPM
Am I seeing things ? I'm using the IBM api QMHSNDPM to populate my message subfile. I saw it working properly yesterday. After unrelated pgm changes today, it zaps the 1st 2 positions of the message ID (thus no longer finds matches in my MSGF). I verified (debug) that the ID is intact at the api call and is bad upon return. As usual, I'll continue to dig ... but any solutions or even partial ideas are welcome.

Software/Hardware used:
as400

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 20  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • philpl1jb
    two byes .. var char type?
    50,860 pointsBadges:
    report
  • aceofdelts
    msgId is a 7 byte character field not sure how to view "F11" result (Debug view of field value) in hex ... OK I guess I could force a write of the bad field to a data file but I didn't want to spend time on the bad msgId unless that helps us somehow. i found a lengthy article saying api bugs do happen - but I chose to skip it since it wasn't leading to a fix Right now my "Plan B" is to abandon the api even tho that feels the the right way to fill the message subfile
    1,950 pointsBadges:
    report
  • TomLiotta
    "Unrelated" program changes? I wouldn't expect many unknown bugs in QMHSNDPM, so I'd be very carefully checking all "unrelated" changes for parameter length mismatches and similar problems. It might even be that the changes exposed an even more unrelated problem that wasn't visible before in some other part of code. . For hex in debug, add [ :x ] after a variable, e.g.: . == > eval myvar:x . The EVAL command is generated by F11. It can be recalled from history with F9 (or simply typed). But I don't know what you might find available for debug viewing if the problem appears on a message line. . Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Wow. I wasn't expecting an emoticon to show up there. It's supposed to be [ colon-x ]. Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    [:x]
    50,860 pointsBadges:
    report
  • philpl1jb
    Well isn't that nothing.
    50,860 pointsBadges:
    report
  • TomLiotta
    I think you need a space before and after. -- Tom
    125,585 pointsBadges:
    report
  • philpl1jb
    [ :x ]
    50,860 pointsBadges:
    report
  • bvining
    "i found a lengthy article saying api bugs do happen" I would very much enjoy reading this article if you can provide a link. APIs are code, and code does usually come with bugs (even a simple program such as Pgm; Signoff; EndPgm has a potential bug) but I don't believe APIs have any more bugs than any other reasonably complex piece of code -- and IBM will correct reported defects just as it would with any other part of the operating system. Bruce Vining
    6,620 pointsBadges:
    report
  • aceofdelts
    Bruce - the 2007 article is at http://www.itjungle.com/fhg/fhg100307-story02.html Thanks for the replies. I tried a few things yesterday afternoon & finally gave up. Kept getting that same bad result. I called that same program today (NO changes - honest) and the messages once again appear correctly. We did not reboot that 400 (haven't since 2011) and the create date on the program object is at yesterday afternoon. So in the short run, I'm happy. In the long run, there is a threat that the problem will recur. Maybe I'll actually read that article now. [ :x ]
    1,950 pointsBadges:
    report
  • aceofdelts
    That was short-lived. Another unrelated change (developing pgm now so frequent changes) and api seems to fail again - in a different way. MSG subfile now begins with an informational message (about the DDM file-same one I've been using) and never changes (even tho I force errors which would normally populate the MSG subfile). I managed to get a partial field during debug and it mainly has 'CPF' where it stops. So my guess is I'm getting an execution error. So ... general advice might help, but any focus on the error itself seems unlikely to get us anywhere.
    1,950 pointsBadges:
    report
  • TomLiotta
    Is your use of QMHSNDPM new or is it using a more recent coding style? Please post the calling code including all related data definitions. . APIs do sometimes have bugs. But they don't show up often after early-release gets a workout, and they usually appear in APIs that are less commonly used. QMHSNDPM is so widely used in so many different ways that a bug in the API is an extremely unlikely cause for this problem. . Tom
    125,585 pointsBadges:
    report
  • bvining
    Is the code under development small enough to send me a copy (along with anything needed to run it)? The initial problem sounded like some routine in the code stomping on storage, the new problem sounds like the wrong call stack entry is being referenced. In any case, I'll try to take a look if you can send it to me at bvining@brucevining.com (though no promises on when I'll get to it) As Tom mentioned, QMHSNDPM is a very heavily used API. So I really doubt that you have found such a strange series of bugs in the API itself
    6,620 pointsBadges:
    report
  • bvining
    Also the article you reference is NOT saying APIs have bugs, rather that the API was reporting back an error in how the API was called (bad or inconsistent parameter values, the article didn't really say that I noticed). The bug was in the user code not checking if the API was reporting an error -- which is what the remainder of the article addressed (how to check for errors). An analogy would be a RPG program doing a CHAIN with indicator 99 specified for Record not found and then having the RPG program not check if *in99 was on after the chain operation. This would not be considered a RPG compiler or run-time defect
    6,620 pointsBadges:
    report
  • aceofdelts
    Tom - This is basically the first pgm here to use this technique for a msg subfile. I grabbed the parm info from something that calls the api but doesn't seem fully functional. Since it sometimes works, I assumed the parms are OK. Here's the detail on it ... Parm fields - D msgId s 7A D msgLoc s 20A inz('SHMSGF *LIBL ') D msgType s 10A inz('*DIAG') D msgKey s 4A inz(' ') D msgErr s 4B 0 inz(0) D msgrmv s 10A inz('*ALL') D msgData s 256A inz('General Error') D msgDlngth s 10i 0 inz(0) D msgCStk s 10a inz('*') D msgCStkcnt s 10i 0 inz(0) D sndpgmmsg pr extpgm('QMHSNDPM') api call - C MSFSnd Begsr C Eval msgDlngth = %len(%trim(msgdata)) c Call 'QMHSNDPM' c Parm msgId c Parm msgLoc c Parm msgData c Parm msgDlngth c Parm msgType c Parm msgCStk c Parm msgCStkcnt c Parm msgKey c Parm msgErr C Endsr The message file is standard. The screen setup is exactly what I've used many times (elsewhere). Bruce - I'll send you the whole thing via email.
    1,950 pointsBadges:
    report
  • aceofdelts
    Please ignore that sndpgmmsg D-spec. Left over from various experimenting and not used in current version.
    1,950 pointsBadges:
    report
  • TomLiotta
    Without actual testing, the msgerr variable is defined incorrectly and is liable to give very unpredictable results. It is not a [4B 0] field, but instead should be defined as a 4-byte integer, [10i 0] should work. With [4B 0], there's a good chance of the API believing that you are supplying an err code data structure. The API can then return any error in unpredictable memory instead of sending an *ESCAPE message. You probably wouldn't know that an error was reported. -- Tom
    125,585 pointsBadges:
    report
  • aceofdelts
    Yay ! It works & seems to stay "OK" even with updates now that the msgerr field definition is correct. Thanks for the help.
    1,950 pointsBadges:
    report
  • TomLiotta
    Best advice might be never to code a "B" data type in D-specs. Only reasonable time to use it is... ummm... well, I suppose if we really really need to store a whole bunch of values accurately in the absolute minimum of space and the values have decimal fractions, it might be useful. . If you code a test usage of a [4B 0] variable and display it in hex in debug, first thing you should notice is that it's only 2 bytes long (4 hex digits). I.e., it most definitely is not a BINARY(4). Now, since it's only 2 bytes of memory, and the API accesses 4 bytes of memory from that address, what do you suppose the length of your error structure was? (Hint: what was the binary value of the 2 bytes that followed your variable in memory?) So, even if you set your variable to (0), the API probably saw something else, possibly much larger.) . The 'B' data type is essentially a binary value, but it causes special code to be inserted to handle decimal fractions accurately. The number of digits in [4B 0] tells the range of decimal values, not the number of bytes. That variable will hold 9999, and no more. The decimal value (9999) can be stored in 2 bytes. But a true BINARY(4) is a 32-bit integer. . Tom
    125,585 pointsBadges:
    report
  • aceofdelts
    Tom - I bet you didn't think your extra tidbit of advice would be so useful so quickly. Thanks again ... now that I consistantly populate the message subfile I saw that it was not properly clearing. Focussing on the api parms, I tried many combinations. Nothing worked until I reread your "Binary" advice - so I switched that parm (silly me - taking the IBM site info literally) to a 10 digit integer and it finally seems to work perfectly. So you answered my next question before I even asked it. Have you ever thought of starting a "you want it yesterday - OK" service ? (like next day delivery only better)
    1,950 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following