Try to push an integer into a Java String and you will be stopped at compilation time. Now try something like "MOVE 15 TO A" where A has been defined as PIC X(2) and not only the compiler will let you through but even at runtime, that will actually work. You end up with the EBCDIC representation of characters '1' and '5' as the content of A.
Actually, you can move pretty much anything into a COBOL PIC X. You commonly do things like "MOVE LOW-VALUES TO A" where you end up with A filled with binary zeros. This is particularly useful in CICS/BMS applications where a field filled with low values will result in no data sent to a screen while a field filled with space characters will increase the volume of data sent (and therefore use up the, once precious, network bandwidth).
This is always a source of problems with integration solutions because the most natural mapping to a COBOL PIC X is a Java String. So you actually map a COBOL type that is not limited to characters to a Java type that only accepts characters.
It is important that an alternative mapping be available. Typically it is sometimes necessary to map a PIC X to a Java byte[] because the content cannot predictably be converted to characters.
When mapping to a Java String is mandatory (it usually is), it is also important that low level conversion routines remove non character content coming from the COBOL program before the Java String is populated.
Conversely, it is important that non character content gets inserted in the COBOL data when needed. For instance, if a COBOL field needs to be filled with low values (as opposed to space characters) then the integration conversion routines should provide an option to do so.
Keep in mind that the mainframe program might react differently to a field filled with low values as opposed to one filled with characters!
I consider a "pic x's" as a "byte[]" plus a encoding rather than a "String".
ReplyDeleteAs COBOL 'pic x' fields are length delimited and often space terminated, conversion to a Java string needs to take into account is length.
All of this as you say makes it a bit of pain to use with COBOL.
When I have had to pass Strings between COBOL/Java I resorted to using java.nio.ByteBuffers to encapsulate the COBOL memory that contains the group item/PICX's etc.. and then let the Java code manipulate the memory directly via the nio library.
Anyway... I like the article and I too have started to write about COBOL, which may be interested to your goodself too..
My blog can be found @ http://www.gennard.net/blog/
--
Stephen@Gennard.net