Prev: IBM Mainframe - Batch Job to Generate Data Set List?
Next: How would you do this?
From: jacodeguy on 22 Feb 2007 10:12
Ok... that looks crappy... try this link instead:

http://camavision.com/dn/bsketchdump.txt

-Andy

From: Louis Krupp on 22 Feb 2007 13:29
jacodeguy(a)gmail.com wrote:
> Ok... that looks crappy... try this link instead:
>
> http://camavision.com/dn/bsketchdump.txt

It looks like there's a 128-byte header followed by the records. Each
826-byte record is preceded by a 2-byte prefix ("C:"). The first 21
bytes of each record do in fact look like an alpha key.

The rest of the record doesn't seem to match the layout. For one thing,
it's too short; 200 repetitions of pairs of S9(4) COMP should take 1200
bytes. And I don't think the all of the data looks like signed packed
decimal.

Any idea what the sending system thinks is in the first few records?

Louis
From: Richard on 22 Feb 2007 13:42
On Feb 23, 4:06 am, jacode...(a)gmail.com wrote:

> The program was written for windows/dos, I'm not sure of the version.
> from the rebuild util I get this header:
> XM V1.4.6 - The Micro Focus DOS Extender Copyright (c) 1987-1996 Micro
> Focus Ltd
> URN AXCPA/000000000 [Protocol:
> DPMI] Ref 022
> Micro Focus COBOL File Management Utility
> Version 3.4.23 Copyright (C) 1985-1996 Micro Focus Ltd.
>
> So does 3.4.23 sound right? I can run on windows or linux (I'd prefer
> linux) however.

3.4.xx is DOS compiler. It can do Windows 3.1 and OS/2
16 bit.

The first 128 bytes is a file header. This indicates C2 format which
is the default for version 3.4. This makes it harder to deal with in
other systems.

No problem for a Microfocus program, and I could send one that does
not require a runtime licence, but I doubt that other Cobol would
access it, not free ones anyway.


==========================================================================
> 0000: 30 7E 00 00 00 00 00 00 30 31 31 30 31 38 31 34 | 0~......
> 01101814
> 0010: 30 30 31 36 31 36 30 31 31 30 31 38 31 34 30 30 |
> 0016160110181400
> 0020: 31 36 31 36 00 3E 00 02 00 00 00 00 00 00 00 00 |
> 1616.>..........
[snip]
> 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> | ................

This is a data record. Two byte record header. Prop-No of
01-000-001-00, Seq A.

The record header needs to be interpreted. The first 4 bits give
record type (0100=user record). Then 12 bit length.

> 0080: 43 3A 30 31 2D 30 30 30 2D 30 30 31 2D 30 30 20 | C:
> 01-000-001-00
> 0090: 20 20 20 20 20 20 41 FF D8 00 10 00 01 00 09 00 |
> A.Ø.......
> 00A0: 21 00 0D 00 21 00 35 00 37 00 35 00 37 00 25 FF | !...!.
> 5.7.5.7.%.
[snip]

END is 2 bytes 0038 Scale 3 bytes 004E20. Two byte header, Prop-No
01-000-006-00 Seq A.

> 03B0: 00 00 00 00 00 00 00 00 38 00 4E 20 43 3A 30 31 | ........8.N
> C:01
> 03C0: 2D 30 30 30 2D 30 30 36 2D 30 30 20 20 20 20 20 |
> -000-006-00
> 03D0: 20 20 41 FF D8 00 10 00 01 00 0B 00 0D 00 21 00 |
> A.Ø.........!.

This could be relatively easy in C, at least it is fixed length and
uncompressed. Just byte switch the COMP fields.


From: Rick Smith on 22 Feb 2007 13:54

"Louis Krupp" <lkrupp(a)pssw.nospam.com.invalid> wrote in message
news:12tro992hdae6b8(a)corp.supernews.com...
> jacodeguy(a)gmail.com wrote:
> > Ok... that looks crappy... try this link instead:
> >
> > http://camavision.com/dn/bsketchdump.txt
>
> It looks like there's a 128-byte header followed by the records.

Typical of Mirco Focus Indexed Files and Variable
Lengrh Files.

> Each
> 826-byte record is preceded by a 2-byte prefix ("C:").

This a record descriptor which consists of a 4-bit type
followed by the 12-bit record length. (x"433A" means,
type "4" record with length 826 bytes.)

> The first 21
> bytes of each record do in fact look like an alpha key.
>
> The rest of the record doesn't seem to match the layout. For one thing,
> it's too short; 200 repetitions of pairs of S9(4) COMP should take 1200
> bytes. And I don't think the all of the data looks like signed packed
> decimal.

The record matches the layout perfectly!
Micro Focus S9(4) COMP is two bytes binary
and 9V9(4) COMP is three bytes binary.



From: Louis Krupp on 22 Feb 2007 14:51
Rick Smith wrote:
> "Louis Krupp" <lkrupp(a)pssw.nospam.com.invalid> wrote in message
> news:12tro992hdae6b8(a)corp.supernews.com...
>> jacodeguy(a)gmail.com wrote:
>>> Ok... that looks crappy... try this link instead:
>>>
>>> http://camavision.com/dn/bsketchdump.txt
>> It looks like there's a 128-byte header followed by the records.
>
> Typical of Mirco Focus Indexed Files and Variable
> Lengrh Files.
>
>> Each
>> 826-byte record is preceded by a 2-byte prefix ("C:").
>
> This a record descriptor which consists of a 4-bit type
> followed by the 12-bit record length. (x"433A" means,
> type "4" record with length 826 bytes.)
>
>> The first 21
>> bytes of each record do in fact look like an alpha key.
>>
>> The rest of the record doesn't seem to match the layout. For one thing,
>> it's too short; 200 repetitions of pairs of S9(4) COMP should take 1200
>> bytes. And I don't think the all of the data looks like signed packed
>> decimal.
>
> The record matches the layout perfectly!
> Micro Focus S9(4) COMP is two bytes binary
> and 9V9(4) COMP is three bytes binary.
>
>
>

How do you fit a sign and four digits into two bytes? (Or am I being
unusually dense today?)

Louis
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: IBM Mainframe - Batch Job to Generate Data Set List?
Next: How would you do this?