I get the funny feeling you haven't extensively used the Text field with
most API error situations :-)

Text should not be defined as varying as it would be the rare case for the
message to just happen to be returning one replacement variable with an
unsigned 2-byte integer representing the length of the replacement text.
The use of Varying in the D spec is saying all messages use one varying
length character replacement variable.

Bruce Vining




Tommy.Holden@xxxxxxxxxxxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/01/2007 11:33 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: API error data structure






here's the DS i use:
dErrorDS ds Qualified
d BytesProvided 10i 0 Inz(%Size(ErrorDS))
d BytesAvailable 10i 0
d MsgID 7a
d 1a
d Text 500a Varying

Thanks,
Tommy Holden




Bruce Vining <bvining@xxxxxxxxxx>
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/01/2007 11:28 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
cc

Subject
Re: API error data structure






The first example is wrong. The Bytes Provided field represents the total


length of the error code structure (as in the second example).

The first example, as it's using too small a value, won't cause any data
corruption. The downside is that if a given error message had greater
than 84 bytes of replacement data, the program would only receive the
first 84 bytes. In the second example it would get 100 bytes of
replacement data (but still not everything if the message replacement data


exceeded 100 bytes in length.

Bruce Vining




AGlauser@xxxxxxxxxxxx
Sent by: midrange-l-bounces@xxxxxxxxxxxx
05/01/2007 11:23 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
" Midrange technical discussions" <midrange-l@xxxxxxxxxxxx>
cc

Subject
API error data structure






I'm a bit confused and I'm hoping those here can help. I've been reading
API documentation and examples in the InfoCentre and various
publications/websites the last few days. I've seen the general API data
structure defined both like this:

d apierrds ds inz qualified
d bytesprov 9b 0 inz(%size(apierrds.msgdata))
d bytesaval 9b 0
d msgid 7a
d filler 1a
d msgdata 100a

and like this:

d apierrds ds inz qualified
d bytesprov 9b 0 inz(%size(apierrds))
d bytesaval 9b 0
d msgid 7a
d filler 1a
d msgdata 100a

In this case, I've taken the first from an IT Jungle article about user
indices (1) and modified the second to reflect the other method I've seen.



The relevant InfoCentre article (2) describes the bytesProv field as
"[t]he number of bytes that the calling application provides for the error



code" which leads me to believe that the second option is correct. Can
anyone confirm this?

TIA,
Adam


(1) http://www.itjungle.com/mpo/mpo112003-story01.html
(2)
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apiref/errorcodeformat.htm




Attention:

The information contained in this message and or attachments is
intended only for the person or entity to which it is addressed and may
contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this
information by persons or entities other than the intended recipient is
prohibited. If you received this message in error, please contact the
sender and
delete the material from any system and destroy any copies. Thank you for
your
time and consideration.

Attention:

Le contenu de ce message et(ou) les fichiers ci-joints s?adressent
exclusivement à la personne ou -entité à laquelle ils sont destinés. Ils
peuvent
contenir de l?information confidentielle, protégée et(ou) classifiée. Il
est
strictement interdit à toute personne ou entité autre que le(la)
destinataire
prévu(e) de ce message d?examiner, de réviser, de retransmettre ou de
diffuser
cette information, de prendre une quelconque action en fonction ou sur la
base
de celle-ci, ou d?en faire tout autre usage. Si vous avez reçu ce message
par
erreur, veuillez communiquer avec l?expéditeur(trice), supprimer ce
message et
les fichiers ci-inclus de tout système, et en détruire toutes copies,
qu?elles
soient électroniques ou imprimées. Nous vous remercions de votre entière
collaboration.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.