More on the mechanics of jPOS’ FSDMsg facility

A jPOS Users list member asks:

“Does FSDMsg only supports fixed-length fields?  Can FSDMsg supports variable-length fields? Let’s say 2 bytes of length.”

You can do variable-length fields.  ‘FSD’ means “field separator delimited.”  Delimiters define the end of fields that can be variable in length.  Take a look at this schema definition from one of our jPOS implementations:

<schema>
<field id="magnetic-strip-info" type="AFS" length="80" />
<field id="expiration-date" type="NFS" length="4" />
<field id="pin-data-fs" type="A" length="1" />
<field id="flex-info" type="AFS" length="108" />
<field id="amount" type="AFS" length="14" />
<field id="additional-amount" type="AFS" length="14" />
<field id="register-number" type="A" length="2" />
<field id="tran-id" type="A" length="7" />
<field id="tender-attempt-indicator" type="A" length="1" />
<field id="tender-number" type="N" length="4" />
<field id="tender-attempt" type="A" length="4" />
</schema>

That's something we use to parse a portion of an incoming message, where:

• A = fixed-length alphanumeric field
• N = fixed-length numeric field
• AFS = variable-length alphanumeric field, terminated by a field separator ('1C)
• NFS = variable-length numeric field, terminated by a field separator ('1C)

Here's another example:

<schema id='S'> <!-- Special Condition Record-->
<field id='quasi-cash-indicator' type='K' length='1' >N</field>
<field id='special-condition-indicator' type='A' length='1' />
<field id='clearing-sequence' type='N' length='2' />
<field id='clearing-count' type='N' length='2' />
<field id='cust-svc-phone-flag' type='K' length='1' >N</field>
<field id='filler-1' type='A' length='34' />
<field id='seqno' type='N' length='6' />
<field id='special-use-fields' type='A' length='19' />
<field id='merchant-trans-indicator' type='A' length='1' />
<field id='cert-for-mc-advice-code' type='A' length='1' />
<field id='mc-trans-category-indicator' type='A' length='2' />
<field id='filler-2' type='A' length='9' />
</schema>

Where:

• K = Constant (you can see how I've specified the constant values).

Some other FSD behaviors to note...

If you're building a message via FSD and you *don't* specify a value for a particular field in your code, then what you get as a default is:

• For 'A': Filled with spaces
• For 'N': Filled with zeroes
• For 'AFS' and 'NFS': You'll get just the field separator

Also:

For 'A': If you populate a field with a value shorter than the length of the field, FSD will left-justify and space-fill to the right.  For example, if I were to populate this field...

...with "4433", I'd get:

"4433 "

For 'N': If you populate a field with a value shorter than the length of the field, FSD will right-justify and zero-fill to the left.  For example, if I were to populate this field...

...with 4433, I'd get:

004433

If, however, 'seqno' had been defined like so...

...and you placed '4433' in there, then FSD would build this in the construction of the message:

4433'1C

(where '1C indicates the presence of a hex field separator)

Additionally, when using or defining NFS or AFS you MUST use a length that is the maximum than any expected length you plan on receiving.  You see above:

If I were to get, say, 85 characters in from the origination point prior to a field separator, then I'm screwed and my FSD parse breaks down because I've blown past where my field separator ought to be.  We worked with the store system team in this case to determine the absolute maximum we would see coming in...then we set that value a few characters bigger for safety.

Another behavior to note:

Suppose in your program you use the wrong FSD field name.  For example, when populating this field...

...let's say that in your code, you did this:

m.set ("seq-no", Integer.toString(seqno));

(note incorrect field name used in set).

What would happen would be:

1. Your code would compile without error.
2. Your program would execute without error.
3. The records would be created with 'seqno' populated with 000000.

Double-check all your field references in your program to make sure you've got the names exactly right!

See my previous posts related to different FSDMsg usages here and here.