RE: KTF file in Oracle - binary? -- BPCS-L

HP Oracle should be in ASCII. Remember Octal?? Sometimes if the ASCII to
EBCDIC goes through more than one translation you get garbage (like the
Enigma Machine)...
Clare

-----Original Message-----
From: MacWheel99@aol.com [mailto:MacWheel99@aol.com]
Sent: 31 August 2000 20:19
To: BPCS-L@midrange.com
Subject: Re: KTF file in Oracle - binary?


From Al Macintyre 

Midrange_L has a thread which might have answers to help with a puzzle that 
was recently shared on BPCS_L.  I had not been previously aware of this byte

order topic.

Consider for example the HEX of 7F in AS/400 that was translated in Unix to 
74, now I happen to know from my days in punched cards that under EBCDIC the

F can be represented by digit 6 (ABCDEF numerical sequence) and the zone 12 
(punched card top slot) for positive, but F in hexadecimal is also the 
largest valid value for one bit.

Decimal # system goes 0123456789 in one bit
Hexadecimal # system per bit goes 0123456789ABCDEF

which means that while the AS/400 might be using the "F" to represent end of

packed field and some info about the sign of the field or type of field as I

suspect, when the data gets to the Unix platform, it might be interpreting 
the "F" somewhat differently.

Perhaps the 32 48 74 should also be "read" as 23 84 47 when trying to match 
up what these numbers represent & where they come from.

Computers have a choice of number systems, with the ones I am most familiar 
with seeing being decimal, binary, and hexadecimal, in which sometimes these

words are misused ... e.g. I have seen several artifacts on AS/400 which IBM

calls "binary" but by no stretch of my imagination are any of them using the

binary number system.

Eons ago when I was a math major, we played around with other number systems

& dimensions, many of which would be a poor fit to what computers are
capable 
of.

Is there somewhere it is documented what number systems are in use in any 
given system?

EBCDIC uses 4040 to represent packed blanks ... ie. an improperly defined 
field that was blank but not packed & is now being used as a packed field, 
with 0000 when correctly defined but not yet populated.

What does HP/Unix use for the same function?  
That might be another clue to unlocking this puzzle.

> Subj:  RE: Retrieving JPG and GIF file data in an AS/400 program
>  Date:    08/31/2000 1:03:54 PM Central Daylight Time
>  From:    bob@cstoneindy.com (Bob Crothers)
>  
>  Rob,
>  
>  Little/Big Endian refers to the byte ordering.
>  
>  In the AS/400 world (Aka: Big Endian), integer data is stored with the
high
>  order bytes first and low order bytes last.  As you would expect.
>  
>  In the Intel (and others) world, they use little endian.  Eg: the LOW
order
>  bytes come first followed by the high order bytes...in reverse order than
>  you would expect.
>  
>  The result is in the as/400 world, a integer (binary) 16 bit value of 1
>  looks like hexadecimal x'0001' in memory/disk.  In the Intel or little
>  endian world, the same data would be x'0100'.
>  
>  These issues become very important when doing cross platform stuff.
>  
>  Why is this done?  Beats me.  Has something to do with the hardware level
>  and efficiency.  I just know this is the way the world is.

You probably want to check out the archives since I not been following the 
whole thread & it only just now clicked in my brain that this might be an 
element of the BPCS_L puzzle.

>  I suspect doing this via RPG might be an "easier said then done" type
>  proposition.  I would recommend finding the C code to do it in the Unix
>  world, and then porting it to the AS/400.  NT/9x C can also be ported,
but
>  Unix tends to be easier.

>  -----Original Message-----
>  From: owner-midrange-l@midrange.com 
[mailto:owner-midrange-l@midrange.com]On
>  Behalf Of Rob Dixon
>  Sent: Wednesday, August 30, 2000 12:01 PM
>  To: MIDRANGE-L@midrange.com
>  Subject: Re: Retrieving JPG and GIF file data in an AS/400 program
>  
>  Bob
>  
>  
>  > And don't forget to pay attention to Little vs Big endian issues (Byte
>  > Ordering).  The AS/400 is Big endian,  Intel is little.  Unix is both
>  > depending on platform.
>  
>  Thank you for this but could you explain further please.  
>  
>  Best wishes
>  
>  Rob

Subj:    KTF file in Oracle - binary?
Date:   08/29/2000 1:25:50 PM Central Daylight Time
From:   mhoffman@crowechizek.com (Mike Hoffman)

I am trying to assist a company on BPCS v6.04 HP/Oracle. We are working on
a custom "Projected Available Report" where the user enters the preferred
time frame code to leverage the bucket days of  demand/supply. The KTF file
uses an array (at least on the AS/400). When running an SQL over the Oracle
database of the KTF file, we don't see values that mean much. After running
PL/SQL over the KTF file, we get values that are represented in the
attached e-mail. Does anybody have experience interpreting how 32,74 = 7
and 32,48 = 1? When we looked at the HEX/DEC on DB2400 it showed it like a
packed decimal with 0 on top, 0 underneath and then 7 up to the right and F
underneath that.

Mike Hoffman
Senior Manufacturing Specialist
Crowe, Chizek & Company, LLP
http://www.crowechizek.com/scg/
phone: 440.460.1318
fax:       440.460.1302

----- Forwarded by Mike Hoffman/CL/CroweChizek/US on 08/29/2000 12:45 PM
-----
 

                                     
                    rgravens@rumk

                                     
                    en.com               To:     mtardiff@crowe_chizek.com

                                     
                                         cc:     mhoffman@CroweChizek.Com

                                     
                    08/29/2000           Subject:

                                     
                    12:35 PM

                                     
 

                                     
 

                                     




Mark,

Here's the first record (M) that we understand:

32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,7
4,
32,74,

32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,7
4,
32,74,32,74,32,74,32,74,

32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74,32,74

This record represents a series of 7s which on the user screen might be
displayed as 007.

The second record (W) that we understand is

32,48,32,48,32,48,32,48,32,48,32,48,32,48,32,74,32,74,32,74,32,32,32,32,32,3
2,
32,32,

32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,3
2,
32,32,32,32,32,32,32,32,

32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32,32

This record represents
1,1,1,1,1,1,1,7,7,7

My thoughts on this so far are that:

1.  Two bytes (numbers in the sequence) represent a number.  Therefore,
32,74 represent 7 while 32,48 represent 1, and 32,32 represent nothing or
possibly 0.
2.  On the AS400, in DB2, Hex F is used to terminate the current number.
3.  On the AS400, in DB2, the binary was used to represent packed decimal
and each number field was restricted to 3 digits.  Thus the highest number
you needed to be able to represent is 999.
4.  Only integers are allowed

Thanks
Rumpi
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---