VB equivalents for Cobol computational declarations

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.    
Mark SmithIT ConsultantAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

    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.


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.
Mark SmithIT ConsultantAuthor Commented:
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.

Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

Mark SmithIT ConsultantAuthor Commented:
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.

    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.


Mark SmithIT ConsultantAuthor Commented:
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?
Mark SmithIT ConsultantAuthor Commented:
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.  
Question finalized per recommendation.
250 points refunded.

Community Support Moderator

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Mainframe Languages

From novice to tech pro — start learning today.