Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
ASCII PACKED 4
- Thread starter fabiousa
- Start date
- Thread starter
- #3
-
1
- #4
- Thread starter
- #5
So, if I had pic s9(3) value +123 where leading sign is separeted, the contents in memory would be 31 32 33 ?? how the positive sign is represented in zonade mode in ASCII?
And if it was not leading sign separated? Would it be 31 32 F3??
Regards,
Fabio
And if it was not leading sign separated? Would it be 31 32 F3??
Regards,
Fabio
Look at this:
I guess this explains itself.... You could have done this yourself!
Regards,
Crox
Code:
SOURCE:
IDENTIFICATION DIVISION.
PROGRAM-ID. SCHERMTEST.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-PC.
OBJECT-COMPUTER. IBM-PC.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
DATA DIVISION.
FILE SECTION.
WORKING-STORAGE SECTION.
01 TEST-GROUP.
02 TEST1 PIC S9(3) COMP-3 VALUE +123.
02 TEST2 PIC 9(3) COMP-3 VALUE 123.
02 TEST3 PIC S9(3) COMP-3 VALUE -123.
PROCEDURE DIVISION.
0001.
EXHIBIT NAMED TEST1 TEST2 TEST3.
EXHIBIT NAMED TEST-GROUP.
9999.
STOP RUN.
OUTPUT in hex-mode:
TEST1 = 123 TEST2 = 123 TEST3 = 12L
54553232333254553232333254553232334222222
453410D01230453420D01230453430D012C000000
-----------------------------------------
TEST-GROUP = <?=
54552454552321313132222222222222222222222
4534D72F500D02C2F2D0000000000000000000000I guess this explains itself.... You could have done this yourself!
Regards,
Crox
-
1
- #7
How a Compiler converts a decimal number into a Packed number is determined by Compiler Specific Implementation. However, I think on mainframes there is an option to make ASCII files. A number, when packed, is getting into assembly in some cases. Basically you are stripping off the F of F9 so you can put two numerals in one byte. Once packed what you have is no longer EBCDIC. However, how it would be converted when you download is tricky. Different compilers use different Symbols for Positive, Negative, and the default value on an initial Pack.
From assembler, I remember you can not go directly from unpacking to displaying until you manipulate the last byte of a number. I think it might look like 1F, 1C, or 1D, which you would convert to F1. This can probably handled with a fancy macro in assembly, but there is a conversion process going on, even if you do not realize it. We used an assembler in school, designed for the PC, that fit on one floppy, and it regretably had no macro capabilities at all. It was a struggle to do anything with numbers. It took 5 commands to make a floating dollar sign.
In the end the packed number could be operating system dependent also. The conversion process doesn't always work. I know we never download packed numbers we always rewrite them as standard decimal numbers in the temporary file area (HTF), move them to the Transfer File Area, and then download them.
We use a product on the mainframe that lets us make download files that is a lot easier called Decision Analyzer, made by DTI in Princeton, NJ. It can read a file and do the selection read the packed numbers and download it all as ASCII. The Decision Analyzer uses Assembly and FORTRAN to accomplish this. It can look at half a bite at a time and just drop off the last letter and convert it to ASCII. It uses FORTRAN to read the files. As an application it is a bit expensive but you can view the mainframe data from a PC and print it out on a PC, make download files, Excel Spreadsheets or ".dbf" Database Files to import into Access.
Charles If you do not like my post feel free to point out your opinion or my errors.
From assembler, I remember you can not go directly from unpacking to displaying until you manipulate the last byte of a number. I think it might look like 1F, 1C, or 1D, which you would convert to F1. This can probably handled with a fancy macro in assembly, but there is a conversion process going on, even if you do not realize it. We used an assembler in school, designed for the PC, that fit on one floppy, and it regretably had no macro capabilities at all. It was a struggle to do anything with numbers. It took 5 commands to make a floating dollar sign.
In the end the packed number could be operating system dependent also. The conversion process doesn't always work. I know we never download packed numbers we always rewrite them as standard decimal numbers in the temporary file area (HTF), move them to the Transfer File Area, and then download them.
We use a product on the mainframe that lets us make download files that is a lot easier called Decision Analyzer, made by DTI in Princeton, NJ. It can read a file and do the selection read the packed numbers and download it all as ASCII. The Decision Analyzer uses Assembly and FORTRAN to accomplish this. It can look at half a bite at a time and just drop off the last letter and convert it to ASCII. It uses FORTRAN to read the files. As an application it is a bit expensive but you can view the mainframe data from a PC and print it out on a PC, make download files, Excel Spreadsheets or ".dbf" Database Files to import into Access.
Charles If you do not like my post feel free to point out your opinion or my errors.
- Thread starter
- #8
What have here for Pic S9(5) leading sign is sparated value -123 is 2D 30 30 31 32 33.
I am expecting someone to give me an input file using this field. If I tell the person the field is S9(5) leading is separated, is there any chance the person will give me something like 30 30 2D 31 32 33????
I just want to make sure I get the right content.
Crox thanks a lot for your reply.
Charles, in assembler for mainframe, you need to unpack the field and invert the zone and digit in the last field.
Thanks,
Fabio
I am expecting someone to give me an input file using this field. If I tell the person the field is S9(5) leading is separated, is there any chance the person will give me something like 30 30 2D 31 32 33????
I just want to make sure I get the right content.
Crox thanks a lot for your reply.
Charles, in assembler for mainframe, you need to unpack the field and invert the zone and digit in the last field.
Thanks,
Fabio
-
1
- #9
StephenJSpiro
Programmer
"Packed" format is always operating system dependent. The formats differ from manufacturer to manufacturer. Packed numbers on the IBM mainframe always have a sign as the last nibble (half-byte), even tho the "sign" may mean "unsigned" (F). NCR omits the sign entirely when it is packed unsigned. And, in fact, a packed number can end or start in the middle of a byte in NCR! Compilers are written for specific operating systems. ASCII or EBCDIC does not make the difference, the operating system does.
Stephen J Spiro
ANSI COBOL Standards Committee
Stephen J Spiro
ANSI COBOL Standards Committee
-
1
- #10
BettyScherber
Programmer
Fabio -
You may or may not get the format you want, depending on who is interpretting your instructions. Providing the person with examples, may help, but I have found it often doesn't. Some of these "newfangled" tools just don't handle numeric formats the same as good old COBOL. If the data doesn't show up the way you want it:
I don't think you'll get a 30 30 2D 31 32 33 which would by
00-123, but you might get a 20 20 2D 31 32 33 (spaces not zeros). This can easily be detected by checking to see if the first character is a blank. Easiest way to get around this would be to redefine the field with a PIC of -(5)9 and move the editted field to an uneditted field, thus forcing the de-edit.
A worse posibility is receiving 2D 31 32 33 20 20 (trailing spaces). This can be detected by checking to see if the last character is a blank. To get around this, you can use a perform to find the last non-space then use reference modification to move the significant part to a right justified field and process as above.
But maybe you'll get lucky and the data will show up the way you want it.
Good Luck
Betty Scherber
Brainbench MVP for COBOL II
You may or may not get the format you want, depending on who is interpretting your instructions. Providing the person with examples, may help, but I have found it often doesn't. Some of these "newfangled" tools just don't handle numeric formats the same as good old COBOL. If the data doesn't show up the way you want it:
I don't think you'll get a 30 30 2D 31 32 33 which would by
00-123, but you might get a 20 20 2D 31 32 33 (spaces not zeros). This can easily be detected by checking to see if the first character is a blank. Easiest way to get around this would be to redefine the field with a PIC of -(5)9 and move the editted field to an uneditted field, thus forcing the de-edit.
A worse posibility is receiving 2D 31 32 33 20 20 (trailing spaces). This can be detected by checking to see if the last character is a blank. To get around this, you can use a perform to find the last non-space then use reference modification to move the significant part to a right justified field and process as above.
But maybe you'll get lucky and the data will show up the way you want it.
Good Luck
Betty Scherber
Brainbench MVP for COBOL II
- Status
Similar threads