VB equivalents for Cobol computational declarations

Posted on 2003-11-18
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.

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


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

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

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

Entering a date in Microsoft Access can be tricky. A typo can cause month and day to be shuffled, entering the day only causes an error, as does entering, say, day 31 in June. This article shows how an inputmask supported by code can help the user a…
Computer science students often experience many of the same frustrations when going through their engineering courses. This article presents seven tips I found useful when completing a bachelors and masters degree in computing which I believe may he…
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…

735 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