Converting Packed Decimal
Last Post 10 Jan 2013 04:51 AM by Terry Winchester. 14 Replies.
AddThis - Bookmarking and Sharing Button Printer Friendly
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
user400
New Member
New Member
Posts:15

--
28 Dec 2012 10:45 AM

I am new to technical documents describing field layouts. We currently are receiving a file from outside our system being sent FTP in Binary mode. From what I understand it is coming from IBM Mainframe than to us. Which is a Windows server than to our AS/400.

I just need a little help wrapping my brain around this in theroy I should be able to FTP from Our windows server to our AS/400 via Binary mode than for a lack of a better term "unpack" the packed feilds however this is where I am stuck I get the file over just fine however those fields are unreadable b/c they are still "packed"

The Tech document reads a position, length and "picture" (which I am not sure what this means) in the picture field they are described as a packed field S9(4)V C-3.

At this point I am just wondering if I am on the right track and would like some suggestions on how to write a CL to create a readable file from the file I have pulled down.

Gary Lavery
New Member
New Member
Posts:8

--
28 Dec 2012 12:04 PM
You could use SQL and substring the data to a new file.
To unpack packed decimal in SQL is a real PITA but there's examples/discussion online...for instance:
http://www.justskins.com/forums/con...23232.html
I had to do it once but it was so long ago I can't lay my hands on it.
If you want to try via SQL and you are stuck, write back and I'll see if I can come up with a practical example.
Gary
Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
28 Dec 2012 02:23 PM

"Picture" is a COBOL keyword used to describe a data item/structure. You can look at the ILE/Cobol manuals on IBM's website for more information. Regardless, if you have moved the file into a DDS described file, you could just as easily use RPG or COBOL to read the file and then edit the information and rewrite it in any form you wish. This is not something that is really suited for CL programming and as the other poster indicates, using SQL will also be cumbersome...

 

Terry

user400
New Member
New Member
Posts:15

--
02 Jan 2013 10:21 AM
This is kinda of what I thought and the information I was looking for Thank you! By chance do you have any reference materials or good places to start to do this sort of thing. While I am not new to the programing world I am new to RPG and COBOL. I would love some suggestions. I appreciate your help and insight on this.
Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
02 Jan 2013 10:49 AM
Posted By user400 on 02 Jan 2013 10:21 AM
This is kinda of what I thought and the information I was looking for Thank you! By chance do you have any reference materials or good places to start to do this sort of thing. While I am not new to the programing world I am new to RPG and COBOL. I would love some suggestions. I appreciate your help and insight on this.

You have FTP'd the file in binary mode from a Windows box, correct? How was the file defined on the iSeries? Did you use DDS or is it a fixed length file of  X  number of characters per record?  If it is fixed length and the records were transferred correctly you'll need to create a program that breaks down the fixed length record format into the various character/packed fields. In RPG you'll need a data structure and in COBOL you'll need a record layout in Working-Storage that is defined based on your "tech document". 

 Terry

Lynne Noll
Senior Member
Senior Member
Posts:6567

--
02 Jan 2013 01:03 PM
Packed shows the field as each decimal digit is in a separate consecutive half byte, with the final half byte being the sign (from mainframe, hex F and C are positive and D is negative; AS400 is the same, but no C sign.) The location of the decimal point is implied.


Using SQL for packed generally means using the hexadecimal function on the field. This lets you get at the actual numbers and the sign in separate bytes. It is not that difficult, but you have to get it lined up correctly; this code is untested and I may have screwed it up. If you like, you can set up a UDF in SQL or RPG that accepts a varchar string and returns a number. If the packed field is not separated out into a separate field, you need to do more substrings to get it, but the principle is the same. A 4 (or 5) position integer would be 3 bytes in packed; for a 4 position packed field, the leading half byte will be zero. If you are more comfortable with a RPG program-described file to translate, go ahead; it doesn't make much sense to waste time on this. However, if you use SQL, you can get it working with interactive SQL, which helps with the trial and error part.

General principle:

select case when substr(hex(mypacked),6,1)='D' then cast(substr(hex(mypacked),1,5) as numeric(5,0))*-1 else cast(substr(hex(mypacked),1,5) as numeric(5,0)) end
from myfile

user400
New Member
New Member
Posts:15

--
02 Jan 2013 05:17 PM
Posted By Terry Winchester on 02 Jan 2013 10:49 AM
Posted By user400 on 02 Jan 2013 10:21 AM
This is kinda of what I thought and the information I was looking for Thank you! By chance do you have any reference materials or good places to start to do this sort of thing. While I am not new to the programing world I am new to RPG and COBOL. I would love some suggestions. I appreciate your help and insight on this.

You have FTP'd the file in binary mode from a Windows box, correct? How was the file defined on the iSeries? Did you use DDS or is it a fixed length file of  X  number of characters per record?  If it is fixed length and the records were transferred correctly you'll need to create a program that breaks down the fixed length record format into the various character/packed fields. In RPG you'll need a data structure and in COBOL you'll need a record layout in Working-Storage that is defined based on your "tech document". 

 Terry

Yes I have transfered the File from Windows box Binary. I also verified that I am recieving the File from mainframe in Binary. So the Transfer has been completed from 3rd party to Windows Server than to AS400 all Binary.

The file is Fixed Lenght Record format. It seems like it might be easier to use DDS using the tech document I have?

Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
03 Jan 2013 05:04 AM

[quote]The file is Fixed Lenght Record format. It seems like it might be easier to use DDS using the tech document I have?[/quote]

Agreed. I would create a DDS described file based on the tech document and then create a program to read the fixed length file, move the data into the DDS described file and finally write it back out.

What does your tech document look like? I might be able to translate the field sizes into DDS...

Terry

 

 

 

 

 

 

 

 

Tommy Holden
Senior Member
Senior Member
Posts:2833
Avatar

--
03 Jan 2013 06:37 AM
if your DDS matches the data in the fixed length file being transferred you can do a FTP directly into the DDS described table with no intervention.
user400
New Member
New Member
Posts:15

--
03 Jan 2013 10:12 AM

The tech document looks like it is describing the file in COBOL?

Here is an example:

 

 From To Field Lenght Picture
 1 268  RECDETAIL 268 GROUP
 1 1 RECTYPE 1 X
 2 5 SYSNAME  4  9(4)
 6  10 EXPDATE 3 S9(4)VC-3
         

My guess is this is COBOL or something closely related? From what I've read and Correct me if I'm wrong. X = Character 9 = Numeric.

S9(4)VC-3 = Signed numeric Value with implied decimal point with comp-3 "packed decimal value"

The File is seperated into 3 Sections Header (268 bytes) Detail (268 bytes) and Footer (268 bytes) I am making the X and 9 fields a data type 5 (Binary Character) but I am not sure how I would handle the S9(4)VC-3 I was just going to make it a P (packed decimal data type). Since the File itself has 3 different sections would I define all 3 sections in my DDS or would I make 3 different DDS files to use?

If I were to transfer via ftp using DDS what command do you use?

Thanks again, This is my first time working with all this stuff and we are a pretty small shop, there is little help or expereince in the area I am in, so I have been doing searches and searches and have found very little so far this has been very informative and I must say I really apreciate your time.

Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
03 Jan 2013 10:34 AM

You'll be fine with X and 9 fields as character. Any field defined with "C-3" (Comp-3) should be  packed.

Do the header and trailer records exist only once -or- do they exist once for each "group" of detail records? 

If they exist multiple times (once for each group of records) then your problem is that this is a multi-record formatted file with the first byte of each record indicating the type of record layout. Ideally, you should create 3 different DDS files but you won't be able to use FTP because of its binary nature - it knows nothing about the structure of each record. Instead, you would have to extract each record type into its own DDS file. You may be able to do this with a CPYF but personally I would create a program to read the complete file and then write out the data to one of 3 different DDS-described files based on the RECTYPE field.

If there is only *one* header and detail entry for each file that is received, then these could be checked for validity and then tossed away if they're not needed. This layout reminds me of some older style interface files that look like this:

H999920130102.......

xxxxxxxxxxx999999xxxxxxxx9x999xxxxxxxx9999

T999920130102................

where the T and H entries are header/trailers for the file transmission and the detail records exist between them. In this scenario, they are not typically part of the data being sent but instead are used as markers for batch-oriented systems to know the beginning and end of the file. I'm not sure if this is true in your case without peeking at the file directly...  

Terry

 

 

user400
New Member
New Member
Posts:15

--
03 Jan 2013 10:40 AM
Posted By Terry Winchester on 03 Jan 2013 10:34 AM

You'll be fine with X and 9 fields as character. Any field defined with "C-3" (Comp-3) should be  packed.

Do the header and trailer records exist only once -or- do they exist once for each "group" of detail records? 

 

If they exist multiple times (once for each group of records) then your problem is that this is a multi-record formatted file with the first byte of each record indicating the type of record layout. Ideally, you should create 3 different DDS files but you won't be able to use FTP because of its binary nature - it knows nothing about the structure of each record. Instead, you would have to extract each record type into its own DDS file. You may be able to do this with a CPYF but personally I would create a program to read the complete file and then write out the data to one of 3 different DDS-described files based on the RECTYPE field.

If there is only *one* header and detail entry for each file that is received, then these could be checked for validity and then tossed away if they're not needed. This layout reminds me of some older style interface files that look like this:

H999920130102.......

xxxxxxxxxxx999999xxxxxxxx9x999xxxxxxxx9999

T999920130102................

where the T and H entries are header/trailers for the file transmission and the detail records exist between them. In this scenario, they are not typically part of the data being sent but instead are used as markers for batch-oriented systems to know the beginning and end of the file. I'm not sure if this is true in your case without peeking at the file directly...  

Terry

 

 

 

 


Hit the nail on the head. They only exist one tme where the T and H are just used for file transmission. So then you would suggest just striping the Header and The Trailer and use one DDS to create the file? In your experience which enivroment is easest to program this in? I don't have much experience in COBOL or RPG and I am going to start down one road or another it doesn't really matter to me, and wouldn't mind a season'd opinion on the matter.
Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
03 Jan 2013 01:32 PM

Agreed...you could strip the header and trailer records provided that you don't need the expdate or sysname values, then use a singe file for the detail records. You could try a direct FTP into a DDS-described physical file and see how that works. 

I would forego using FTP and read the fixed length file into a record layout and write it back out to a physical file. This method would also allow me to apply rudimentary editing logic and be able to generate a potential error report in the event that the data is incorrect/erroneous...

I'm a COBOL'er by trade so that would be my language of choice :)  Most of the other folks around here are RPG'ers.

Terry

 

 

 

 

 

user400
New Member
New Member
Posts:15

--
09 Jan 2013 06:15 PM
I Created the DDS file and would like to try FTP the File first, but not show how I would ignore the first 268 bytes? would this be part of the command?
Terry Winchester
Advanced Member
Advanced Member
Posts:406

--
10 Jan 2013 04:51 AM

No, FTP treats data in a binary form so it has no knowledge of records, lines, etc.  You'll have to find a method to strip the header and trailer records.

First try using Notepad or some other text editor to delete the header/trailer and then use FTP. If it works...you're halfway there ;-)

 Terry

You are not authorized to post a reply.

Acceptable Use Policy