Not sure I understand the mixture of the concepts of justification and packed decimal here. I usually think of packed decimal as fixed length and without padding. Let me assume this example: 12345C is value 12345, 00000C is zero, and 00000F is the nil indicator. So, bigEndian byte order, I think dfdl:nilvalue="%#r00;%#r00;%#r0F;" is what I'd expect to see for a literalValue nilValue to match that. I'm guessing some assumption in the above doesn't match your use case, so please correct. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Tue, Apr 14, 2020 at 2:59 PM Bradd Kadlecik <braddk@us.ibm.com> wrote:
I think there is a problem when the literalValue is left-justified for binary data such as packed decimals. This seems problematic because a "0" value might be indicated by having the last byte be 0x0C for a signed numeric while a nil value might be desired to be understood by having the last byte be a 0x0F. In both cases, all preceding bytes are 0x00. In the case that the packed decimal is of variable length, there seems no way to represent this nil value unless it is understood that the fillByte is used for the area preceding the NilElementLiteralContent. Apologies if I might of missed some clarification made regarding this.
Regards,
*Bradd Kadlecik* z/TPF Development ------------------------------ *Phone:* 1-845-433-1573 *E-mail:* *braddk@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg