Imported from previous forum
How can we differentiate SessionRejectReason = 17(Non ¡°data¡± value includes field delimiter (SOH character) from other reasons?
If I have, for example, following messages,
-
…<SOH>55=IBM<SOH>54=1<SOH>38=111<SOH>11<SOH>40=2<SOH>44=1000<SOH>…
-
…<SOH>55=CS<SOH>CO<SOH>54=1<SOH>38=111<SOH>11<SOH>40=2<SOH>44=1000<SOH>…
which reason should I specify in Reject message?
I think the error of 1) can be interpreted as 0(Invalid tag number) and 4(Tag specified without a value) as well as 17 and the error of 2) as both 0 and 17.
What do you think about this ambiguity?
As a general rule, Session-level rejects should be rare for fully tested, production sessions. I don’t think it matters which one you identify (how you interpret) so long as you catch one. There very well may be multiple problems. I would recommend simply reporting the first one your logic identifies.
In programming parlence, treat this as an assertion failure/exception vs. handling it like a compiler handles a syntax error in which it keeps on going/checking/reporting.
> How can we differentiate SessionRejectReason = 17(Non ¡°data¡± value includes field delimiter (SOH character) from other reasons?
>
> If I have, for example, following messages,
>
> 1) …<SOH>55=IBM<SOH>54=1<SOH>38=111<SOH>11<SOH>40=2<SOH>44=1000<SOH>…
>
> 2) …<SOH>55=CS<SOH>CO<SOH>54=1<SOH>38=111<SOH>11<SOH>40=2<SOH>44=1000<SOH>…
>
> which reason should I specify in Reject message?
>
> I think the error of 1) can be interpreted as 0(Invalid tag number) and 4(Tag specified without a value) as well as 17 and the error of 2) as both 0 and 17.
>
> What do you think about this ambiguity?
>