#28 Merging multi copybooks issues

[Anonymous]

Hi Bruce,

I am working on project and trying to use Jrecord first time. I am having few difficulty currently in writing a text record file (which I will transfer to Mainframe through commarea in next step).
My record file will be a signle ascii line having this format - Header (200 bytes - through attached copybook) + opeartionId (4 bytes - need to append it to record file somehow ?) + requestdata (through attached copybook). I have few issues -

1) How to Merge and create record from two copybooks format i.e. (Message Header - LKCMAT02 & Opp101-LKSA310I - RequestFormat). Both the copybooks having differnet split levels and one is having comp fields also.
2) How to avoid entering bytes for the fields, for which there is no value i.e. if field ' LK310I-SWCNTR-AREA-ID-MDT', is not having any value to enter in record file than empty bites should not take and space there in record file for this field.
3) How to insert a extra field value, which is not there in any copy book i.e. want to enter operationId(4 bytes) after Header entries and before Request data entries.
4) For response , can we map it to a Java pojo directly i.e. any utility is avaialble for that ?

Here is sample as how I am trying to merge two copybooks and writing the record file (seems it is not able to merge well and overwriting the records (header & request data), in final record file)

public String write101(SARequest requestData) {

    String copyFileHeader = this.getClass().getResource(HEADER_CBL).getFile();

//*** String copyFileContractID = this.getClass().getResource(RECORD_A_CBL).getFile();
String copyFileReq = this.getClass().getResource(RECORD_A_CBL).getFile();

    String bytesString = null;
    try {
        ICobolIOBuilder iob = JRecordInterface1.COBOL.newMultiCopybookIOBuilder("Opp101")
                // .setFont(Conversion.) // Think about specifying an encoding !!!
  .setFileOrganization(Constants.IO_BIN_TEXT).setDialect(ICopybookDialects.FMT_MAINFRAME)
  .addCopyBook(copyFileHeader).setSplitCopybook(CopybookLoader.SPLIT_NONE)
.addCopyBook(copyFileReq).setSplitCopybook(CopybookLoader.SPLIT_NONE) ;

        AbstractLineWriter writer = iob.newWriter(outputFileName);

        writer.write(createOpp101Lksa310i(iob, requestData));

        bytesString = byteWriter.toString();
        byteWriter.close();
        writer.close();

    } catch (Exception e) {
        System.out.println();

        e.printStackTrace();
    }
    return bytesString;
}

[Bruce Martin]

Comp / Comp-3

The copybooks contain comp/comp-3 fields - binary fields. Do Not the data to
String as this could corrupt the comp/comp-3 fields, use byte arrays / streams.
If you use String's to store the mainframe you will end up with code that works
most of the time.

If the data is going to an IBM mainframe use the appropriate encoding (EBCDIC ???)
when creating the data. Do not run ASCII --> EBCDIC conversion when you have
comp/comkp-3 fields.

Code

I do not think newMultiCopybookIOBuilder - it is for dealling with multi record files with
seperate copybooks for thye different record Types.

What I have done is create 3 seperate IOBuilders for the 3 record types.
For the Request type, I have assumed it is a binary integer - change as required.

You should consider using thee RecordEditor
to generate Java interface code. You could use any of standaard, lineWrapper or pojo
Templates.

See

• https://stackoverflow.com/questions/46313332/how-do-you-generate-javajrecord-code-for-a-cobol-copybook

for details on generating sample JRecord code

[Anonymous]

Thanks Bruce. That helps a lot.

I have one another problem also, don't know, whether we can achieve this i.e.

In attached copybooks (Opp 112 - LKSA310O- ResponseFormat.txt, Opp101-LKSA310I - RequestFormat.txt), there are fields name Ending with MDT. These MDT fields are just before each field in the copybook and both are related with a logic.

i.e. if the data for the field (the field after each MDT field) is present than MDT field will have value 1 otherwise 0. And IF the value for the MDT field comes as 0, than next bytes for the related field, won't be written (in request or response data).
For eample, if the value for for 'LK310I-SWCNTR-AREA-ID-MDT' is 0 than the next bytes for 'LK310I-SWCNTR-AREA-ID' won't be there, instead value for the next 'LK310I-NPA-FNXX-MDT' will come and it continue like that...

Do we have any functionality in Jrecord to deal such situation ? as what I am noticing that each byte will written/read to corresponding field, and that causing issue for me..

Thanks,
Gaurav

[Bruce Martin]

Clarification

For eample, if the value for for 'LK310I-SWCNTR-AREA-ID-MDT' is 0 than the next bytes for 'LK310I-SWCNTR-AREA-ID' won't be there, instead value for the next 'LK310I-NPA-FNXX-MDT' will come and it continue like that.

I presume the above means if the -MDT fild is 0, the normal field can be ignored; rather than the following fields are moved
i.e if you have

         20  AAA-MDT     PIC X(01).
         20  AAA         PIC X(03).
         20  BBB-MDT     PIC X(01).
         20  BBB         PIC X(03).

if AAA-MDT and BBB-MDT are zero it stored like

bytes: 0, ?, ?, ?, 0, ?, ?, ?

or is it compressed field is not represented, just the 2 flags:

bytes: 0, 0

If it is like this, it is not supported in JRecord but it would be easy
code using JRecord. - Every field is stored in the schema (Interface AbstractLayout). You could just
loop through the fields and expand/compress the data. You could also use a CodeGen solution (see below).

Implementation

The JRecord Library does not have any support for MDT type fields.

What might work is Code~Generation using a custom CodeGen Template + some user Interfaces/classes

What I was thinking was for

         20  AAA-MDT     PIC X(01).
         20  AAA         PIC X(03).
         20  BBB-MDT     PIC X(01).
         20  BBB         PIC X(03).

Generating

    class ... {
        public ICblField<String> getAAA() { ... }
        public ICblField<String> getBBB() { ... }


        public void  setLine(AbstractLine line) { ...} 
        public AbstractLine getLine() { ... }

Where ICblField is something like

    interface ICblField<Type> {

       public boolean isPresent();
       public void setPresent(boolean present);

       pulic Type get();
       public void set(Type value);
   }

I can help with this

[Anonymous]

Thankyou Bruce.

Yes, this is what required :
or is it compressed field is not represented, just the 2 flags:
bytes: 0, 0

and if if AAA-MDT and BBB-MDT are 1, than the next field just after them (AAA, BBB) will be read.

could you, please help me with the code-gen solution for this ?

[Bruce Martin]

I have written a

• CodeGen Template for the copybooks
• Support Java code. I have written the bare minimum to get it compile (e.g. there are interfaces but no implementing classes). The Code compiles but I have not tested it anyway.

The Template/ Java code can be downloaded from

• https://sourceforge.net/projects/jrecord/files/jrecord_CodeGen/CodeGen_Examples/

There is a writeup:

• https://sourceforge.net/p/jrecord/wiki/CodeGen%20Example%201/

---

One of the principles I used was to keep the template as simple / generic as possible with as much code in the Supporting Java code. With this aim:
* The generated class extends a support class BaseGeneratedLine
* A builder FieldBuilder is used to define the fields. I used Interfaces (with on example implementation MdfStringField).
* The class CompressedData shows how to decompress the data (compressing would be basically the same).

This is Idea's on how it could be implemented. There still a lot of work needed (I have done no testing). hopefully it is useful.

[Anonymous]

Thank you Bruce. Really appreciate your help on this.

I will look into this and try to implement your suggestions. will let you know, if any issue.

[Anonymous]

Hi Bruce,

your provided expend function doing good but with few issues. i.e.

1. Not able to handle comp/comp3 fields correctly - for this I built a workaround by checking the type of the field and if it is 140 or 142 than double the size. becuse it is taking only the half of the size of the field. Any suggestion from your side ?
2. Not able to handle occurs fields. If you see provided copybook - Opp 112 - LKSA310O- ResponseFormat.txt, there are occurs group there. Do we have any way to handle those groups through Jrecord ?

Also, one request - I didn't find a way to hide my provided files from this open forum, is there any way for the same ?

[Bruce Martin]

I have deleted the files and will bee looking at Arrays

[Bruce Martin]

I have updated the download for Arrays

• https://sourceforge.net/projects/jrecord/files/jrecord_CodeGen/CodeGen_Examples/?upload_just_completed=true

I will also attach the changes file - 1 support class + 1 velocity template

[Anonymous]

Thanks Bruce.

I couldn't check the solution for array fields due to some vacation time. I will start checking now.