Hi Jason,
just to add some thoughts:
if your input record is indeed 80 bytes long (fixed length),
I have a problem to understand how the number of elements in a record in
this case
can be found out. Is there a sort of "terminating length field", for
example minus one?
This would make sense; a minus one length field (0xFFFF) could terminate
the sequence of elements
in an 80 byte record. A zero length doesn't do it, because - as we can
see from the example -
a zero length is used to transfer a blank field, for example.
Maybe you simply can show us from your example record what comes AFTER
the bytes that you showed us
(it has 80 bytes, doesn't it?)
If, OTOH, it is a record of variable length, you know its length, and
then you know when to stop processing.
Or: is the number of elements fixed (as 5, like in the example you
provided)? this would make sense, too.
The extracting procedure could simply count to 5.
Anyway:
if you could provide an answer to this crucial question, I could write a
sequence of COBOL statements
for you to solve your problem.
Kind regards
Bernd
Am 15.06.2024 um 11:38 schrieb Bernd Oppolzer:
Hi Jason,
some answers below
HTH, kind regards
Bernd
Am 14.06.2024 um 14:14 schrieb Jason Cai:
Bernd
Thank you for providing another approach to read and process the
file. I have a few questions to confirm my understanding:
Q1:
File Section Definition:
cobol
Copy code
FILE SECTION.
FD INPUT-FILE.
01 INPUT-RECORD PIC X(80).
Is it correct ?
this is correct, if the record length of the input file is indeed 80;
if not, you have to specify another length. It also depends, if the
input file
has fixed length or variable length. For your structure, with a
variable number of items
in a record, IMO an input file with a variable length would be more
natural. But this is
something that YOU should know ...
Q2:
Do hexadecimal lengths require special handling?
Only, as I already mentioned, the length field in this case has to be
defined as PIC S9(4) COMP.
There is no distinction between binary and hexadecimal. Hexadecimal is
only a more convenient
notation to show binary content.
Q3:
How do we identify which parts of the 80-column data represent the
length and which parts represent the content, given that the length
is a hexadecimal number?
This is easy: you start from left to right. The first two bytes is a
length field. Then you know how long the first element is
(2 for the length field plus the length, which is told by the length
field). After that the second element begins, and so on ...
in the example that you provided:
00F00C0000FFF00F
0110140003156011
0001 - length field one
F1 - content F1
0001 - length field one
C4 - content
0000 - length field zero, no content
0003 - length field three
F1F5F6 - content
0001 - length field one
F1 - content
That said: I don't believe that there are length fields of different
length; what you see is a sequence
of length fields, where some length fields are zero, as in the example
above. So here you have
5 Elements (which is the number of the length fields), and the 3rd
Element has a zero length.
Is there no description of this file format? It would be easier if we
wouldn't have to speculate about it.
This way it is much like a hacker's business :-)
Thank you for your assistance!
Best regards,
Jason Cai
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
