× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Neal:

This might be better addressed on the COBOL list, but it has aspects that make 
it general for the whole group.

  211         09 PRRS-S1C-EDITION-NUMBER        PIC  S9(08) COMP.

My understanding of the COBOL standard is that USAGE COMP kind of translates to 
"the internal representation that is best suited for computation ON THIS 
MACHINE". On an AS/400, the best computation was packed-decimal, so COMP was 
equivalent to the IBM COBOL extension COMP-3, or PACKED-DECIMAL.

However, the machine that this came from might have a different meaning for 
COMP. My first guess would be that your equivalent should be COMP-4 on your 
system rather than COMP-3. I.e., you're receiving a 4-byte binary field. I.e., 
the best computation on the sending machine might be binary rather than packed. 
The same external USAGE definition covers two different internal definitions.

The next question I have is around Client Access. When I run Query, there are 
no errors shown in the file. However, when I try to use the "Receive File From 
Host" facility in Client Access, I get the error "CWBDB0052 - Error occurred 
during data conversion", but all records transfer successfully.


As I understand Client Access, it's trying to make sense of the bytes that 
you're saying are packed. But because they're binary, the attempted conversion 
isn't successful. Hence, the error message.

Tom Liotta

Tom Liotta

midrange-l-request@xxxxxxxxxxxx wrote:

  7. Help with converting Mainframe file on iSeries (Neal Hudson)

I'm looking for some advice/help on a file that I'm having some trouble with. 
The file originates from a mainframe, and is sent over to our iSeries (V5R2M0) 
via Connect:Direct. The file is 3680 Bytes long, comprising of string and 
compressed numeric data. I have the layout of the file, although it's in a 
notation I'm not familiar with, Cobol I think it is, which gives me the start 
and end position of all the fields, and what type they are.

What I've done is set up a physical file, defining all 300 or so fields in the 
file. I then copy the file received in the Connect:Direct library into my own 
file using the CPYF command with a *NOCHK option. This works fine, all the 
records are copied, but when I query the file 1 of the fields is unreadable 
and I get the message "Column B9012 contains replacement character +".

This field is defined in the layout file I have as:
  211         09 PRRS-S1C-EDITION-NUMBER        PIC  S9(08) COMP.
This means that the field starts at position 211 in the file. The next field 
starts at position 215, so I've defined my field in the physical file as:
A            B9012          7P 0       TEXT('S1C-EDITION-NUMBER') 
All the other compressed numeric fields have the notation COMP-3., whereas 
this one is only COMP. - I'm not sure what the difference is there. 
It would seem that the field is a compressed or packed numeric field, of 8, 
but for it to start at 211 and end at 215 I have to define it as 7 in the 
physical file. Do you have an idea of what I can do here?

At the moment, seeing this field is not essential, after the copy file command 
I'm just running through the file and setting the value to 0.

The next question I have is around Client Access. When I run Query, there are 
no errors shown in the file. However, when I try to use the "Receive File From 
Host" facility in Client Access, I get the error "CWBDB0052 - Error occurred 
during data conversion", but all records transfer successfully. I can't figure 
out which fields are in error, although from reading on the internet it would 
appear there may be null values that are causing this. I've switched off the 
option to display warnings during data transfer, which stops the message 
occurring. Would there be a problem I'm masking by doing this?



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.