Still celebrating National IT Professionals Day with 3 months of free Premium Membership. Use Code ITDAY17


VB equivalents for Cobol computational declarations

Posted on 2003-11-18
Medium Priority
Last Modified: 2013-11-25
From within a VBA environment I need to produce a sequential file for subsequent processing on an IBM mainframe.
The sequential file record format consists of a header and segments of modca format images.  The header portion contains data required by the host application to insert the modca files into an IBM ImagePlus repository.  
The cobol declaration of the record header is below.  
In order to complete this task I will have to translate the ascii header field values to ebcdic and split the modca files in to segments then write each image segment as binary data to the segment portion of each record.
I have worked out the ascii to ebcdic translation and the image segmentation components.  I am having difficulty with the header fields that are declared as "Comp".  On the IBM host, the Comp declaration results in the fields being stored in packed decimal format.  As I understand it, a declaration of PIC 9(04) Comp will occupy only 2 bytes in the record header, PIC 9(09) Comp will be 4 bytes.  
My question is what data type do I use so that a value such as 32,715 is accurately represented by 2 bytes?

The Cobol record definitions are:
01 VALIN-RECORD.                              
   05 RECORD-ID                 PIC 9(06).           - sequence # : increments per record (000001, 000002, 000003 etc…)
   05 RECORD-TYPE               PIC 9(02).           - record type: value = 10
   05 SEGNUM                    PIC 9(04) COMP.      - segment number within the document: 01, 02, 03 etc….
   05 TOTAL-SEG                 PIC 9(04) COMP. - total number of segments in the document
   05 FOLDER-ID                 PIC X(15).           -  folder id: to be generated using index values (2 char tax_act, 9 digit client_num, 4 blanks)
   05 OBJSIZE                   PIC 9(09) COMP.      -  size (in bytes) of the entire document
   05 CMD-CODE                  PIC X(02).           - always 'ST' indicating a store operation
   05 OBJNAME                   PIC X(40).           - always blank
   05 OSYSID                    PIC X(04).       - always "ODM1"
   05 FORM-NUM                  PIC X(10).           - populated from an index field value
   05 FILE-TAB                  PIC X(03).           - always blank
   05 COLL-NAME                 PIC X(40).           - indicates ImagePlus collection name.  This will be known based on the batch being processed.
   05 STORAGE-CLASS             PIC X(08).     - blanks
   05 MGMT-CLASS                PIC X(08).           - blanks
   05 RECVD-DATE                PIC 9(06).           - MMDDYY format - populate with scan date
   05 FILED-DATE                PIC 9(06).           - '000000'
   05 PAPER-RET                 PIC X(01).           - 'Y'
   05 REGION-CODE               PIC X(03).           - blanks
   05 LOCATION-CODEX.                                
      10  LOCATION-CODE         PIC 9(03).       - blanks
   05 ROUTE-FLAG                PIC X(01).          - 'N'
   05 RLOB                      PIC X(05).                 - blanks
   05 TRAN-TYPE                 PIC X(05).           - blanks
   05 UNIT-CODEX.                                    
      10  UNIT-CODE             PIC 9(04).           - blanks
   05 ROUTE-CODE                PIC X(06).           - blanks
   05 PRIORITY                  PIC 9(03).           - '000'
   05 OBJTYPE                   PIC X(01).           - 'I'
   05 NUMPAGES                  PIC 9(04) COMP.       - Number of pages in document
   05 RETENTION-PD              PIC 9(08) COMP.               - constant  
   05 DESCR-LENGTH              PIC 9(04) COMP.              -
   05 DESCRIPTION               PIC X(60).                    
   05 NOTES-LENGTH              PIC 9(04) COMP.                
   05 NOTES                     PIC X(120).                    
   05 ERROR-MSG                 PIC X(80).                    
   05 USED-LENGTH               PIC 9(04) COMP.                
   05 OBJECT-DATA.                                            
      10 OBJ-DATA               PIC X  OCCURS 1 TO 32290 TIMES
                                DEPENDING ON USED-LENGTH.      

 01 VALIN-RECORD2.                                              
    05 RECORD-ID2                PIC 9(06).                    
    05 RECORD-TYPE2              PIC 9(02).                    
    05 SEGNUM2                   PIC 9(04) COMP.                
    05 TOTAL-SEG2                PIC 9(04) COMP.                
    05 FOLDER-ID2                PIC X(15).                    
    05 OBJSIZE2                  PIC 9(09) COMP.                
    05 CMD-CODE2                 PIC X(02).                    
    05 USED-LENGTH2              PIC 9(04) COMP.                
    05 OBJECT-DATA2.                                            
       10 OBJ-DATA2              PIC X  OCCURS 1 TO 32717 TIMES
                                 DEPENDING ON USED-LENGTH2.    
Question by:onthemark
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3

Expert Comment

ID: 9773390
    I have worked with a number of files passed between COBOL programs and VB6 programs. In every case we would reformat the records to avoid COMP and COMP-3 fields in the files being passed. In my situation, all the programs are in-house, so I had control over the record layouts. If you can't change the file, you may be able to alter it through a small COBOL program or Sync-Sort.

    I do remember seeing something on working with COMP or COMP-3 numbers a while ago, if you would like, I could see if I can find it.



Expert Comment

ID: 9773407
BTW . . .
    We use FTP to move the files between the mainframe and the servers. Without COMP and COMP-3 forcing the files to be binary, FTP does the ascii to ebcdic translation.

Author Comment

ID: 9773478
Hi Dang123,
Unfortunately I have no control over the file format and am mandated to produce the file in the exact format used today.
I'd be interested if you can find the articles.

The top UI technologies you need to be aware of

An important part of the job as a front-end developer is to stay up to date and in contact with new tools, trends and workflows. That’s why you cannot miss this upcoming webinar to explore the latest trends in UI technologies!


Author Comment

ID: 9773501
Hi Dang123,
As the file contains binary image data I can't allow ftp to do the ascii to ebcdic conversion.  Doing so would result in the image segments being corrupted.


Expert Comment

ID: 9773946
    I'm sorry, I can't find the page anymore (it was something I bumped into on yahoo a while ago).  Basically, you need to define a byte array to contain the comp data

Dim bytComp1To4(2) As Byte
Dim bytComp5To9(4) As Byte

  and fill in the bytes yourself as you convert them.

    Actually, you could define a byte array to represent the entire record. Since your records appear to be variable length, you will need to Redim the length of the array depending on the record you are working on.

Dim bytRecord() As Byte

    Each byte would correspond to a byte in the mainframe record. You could then safely place the EBCDIC characters in place and write the entire record at once to a binary file.



Author Comment

ID: 9821027
When a vb long or integer value is written to a binary file using the put function, the upper and lower bytes are reversed.  
For example:
is an integer
open "c:\test.bin" for binary access write as #ff
put #ff,,i
- two bytes are written to test.bin.  If viewed as a binary file, the two bytes are  01 00.

if i is a long then the result is 01 00 00 00
 I need to access the individual bytes and write themin reverse order to properly represent a PIC 9(2) Comp or PIC 9(8) Comp data types.

Another example:
i=9624 (hex value is 2598)
put #ff,,i results in 98 25

Any one know of an efficient way to access the hi and lo bytes of numeric data types?

Author Comment

ID: 10317756
The reversed representation (i.e. most significant byte first) of the individual bytes of numeric values in the output file was a result of the Little Endian encoding method on the Intel platform vs Big Endian encoding on the host system.  
The solution was to use the copymemory api function to place the numeric byte values into a byte array then output the array to the file in reverse order one byte at a time.  Although I figured this out on my own, Dang123 was on the right track with the suggestion of using a byte array.  

Accepted Solution

RomMod earned 0 total points
ID: 11001883
Question finalized per recommendation.
250 points refunded.

Community Support Moderator

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Although it can be difficult to imagine, someday your child will have a career of his or her own. He or she will likely start a family, buy a home and start having their own children. So, while being a kid is still extremely important, it’s also …
The SignAloud Glove is capable of translating American Sign Language signs into text and audio.
In this fourth video of the Xpdf series, we discuss and demonstrate the PDFinfo utility, which retrieves the contents of a PDF's Info Dictionary, as well as some other information, including the page count. We show how to isolate the page count in a…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question