× 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.


  • Subject: KTF file in Oracle - binary?
  • From: "Mike Hoffman" <mhoffman@xxxxxxxxxxxxxxx>
  • Date: Tue, 29 Aug 2000 12:54:20 -0400

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,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,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,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,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,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,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
+---

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.