We are doing xml to copybook and vice versa conversions in a middleware system, using IBM Websphere transformation extender. From this link Cobol to xsd mapping , we realised that
PIC X(03), in copybook, has to be converted to the below xml schema
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxlength value="3"/>
<xsd:whiteSpace value="preserve"/>
</xsd:restriction>
</xsd:simpletype>
PIC 9(03), in copybook, has to be converted to the below xml schema
<xsd:simpleType>
<xsd:restriction base="xsd:unsignedInt">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="999"/>
</xsd:restriction>
</xsd:simpletype>
However, not able to make out, directly, what xml schema to be used for the below copybook types. Could anyone please guide?
PIC S9(17) COMP-3
PIC S9(17)
PIC S9(03)
PIC S9(03) COMP-3
PIC +9(17)
PIC +9(03)
The best way to understand a PICTURE clause, is to consult your COBOL documentation. I'll follow with some "documentation".
One thing to note is that while I consider the XSD snippets below as correct, different tools may not match exactly mine; for sure, whatever you get from your tools, should not be more restrictive than mine.
PIC S9(17) COMP-3
PIC S9(17)
PIC +9(17)
Note: COMP-3 doesn't matter from an XSD perspective; it affects the encoding in the COBOL world.
<xsd:simpleType name="S9-17">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="-99999999999999999"/>
<xsd:maxInclusive value="99999999999999999"/>
</xsd:restriction>
</xsd:simpleType>
PIC S9(03)
PIC S9(03) COMP-3
PIC +9(03)
<xsd:simpleType name="S9-3">
<xsd:restriction base="xsd:int">
<xsd:minInclusive value="-999"/>
<xsd:maxInclusive value="999"/>
</xsd:restriction>
</xsd:simpleType>
Your PIC 9(03) means the number as unsigned, with an implied positive value.
A preceding S for a numeric value, S9(17) means "signed", with up to 17 decimal digits; the value may be positive or negative. Depending on other clauses, the sign could be separate, leading or trailing.
Things get tricky when a COMPutational clause is present, in which case data is encoded using a "binary" format (half the size, four bits per digit, the sign using the high order, left most bit) - in the COBOL world, not XML. The COMP clause (sometimes referred to as "packed") doesn't change the semantics of the value, it just describes the encoding mechanism, with direct impact on the size (in bytes) required to represent that particular number. For example, a PIC 9(17) will require 17 bytes, a PIC 9(17) COMP-3 will require 9 bytes. Clauses without a COMP are represented in DISPLAY format (basically one byte per decimal digit, plus one for sign, where applicable).
A preceding + sign is much like S; indicates that a number is signed, a + will be used for positive, a - will be used for negative numbers.
Because of this, when representing data in XML, what gets preserved is the data, not it's representation. Consider PIC 9(03) and a value of 1.
A COBOL to XML transform may preserve 001, or not (i.e. get 1). An XML to COBOL transform must be able to take 001 or 1 and correctly convert it to 001.