|
View previous topic :: View next topic
|
| Author |
Message |
sree reddy
New User
Joined: 20 Jul 2007
Posts: 27
Location: bangalore
|
|
|
|
I have a file which i dont know the copybook
If we do Hex on, on the file the date is in the below format
1900
9955
We are making the copybook for this file ,
Could anyone suggest me what should be the pic in the copybook ? to read the value |
|
| Back to top |
|
 |
Peter Nancollis
New User
Joined: 15 Mar 2011
Posts: 47
Location: UK
|
|
|
|
| Depends how your code wants to see the value of those four bytes. |
|
| Back to top |
|
|
sree reddy
New User
Joined: 20 Jul 2007
Posts: 27
Location: bangalore
|
|
|
|
Best way to use How it ineeds to be defined in the Copy book
S9(8) Comp or ? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
what about reading the application specifications.
and rereading the cobol manual about the PICTURE clauses ???
the data posted is none of the recognized COBOL representations
its a <packed/squeezed/condensed> representation of something consisting only of decimal digits
since it represents a date the designers found no need to make it a signed <thing>
a true number would have been something like
pic 9(9) packed-decimal
which
transformed in a printable form would become
and dropping the last placeholder/padding would give you the date
the data You posted forces You to use some UNHEX coding to transform those four byte into a usable format |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Sree, is this anything to do with your ASCII to EBCDIC question earlier? If not, see below.
If yes, then you may be heading for some problems.
I'm thinking likely connected (you a "making" a copybook for a file, so sounds external, you have an ASCII file, so sounds external). Non-character data will cause problems doing ASCII-EBCDIC translation. For example, x'19' in ASCII will translate to something, if x'19' has a meaning. So would x'20'. In fact x'20' is an ASCII space, so would translate to x'40' in EBCDIC.
So, you'll have to do field-level translation. One lot to translate all the character data and the rest (non-character fields) to be left alone, untranslated.
Just in case. Define the field as PIC X(4). When you want to use it, define in a program W-S
| Code: |
01 W-TO-CONVERT-STUFFED-DATE-TO-PACKED.
05 W-TO-CONVERT-STUFFED-DATE PIC X(4).
05 FILLER COMP-3 PIC S9 VALUE ZERO.
01 W-CONVERTED-STUFFED-DATE
REDEFINES W-TO-CONVERT-STUFFED-DATE-TO-PACKED
COMP-3 PIC S9(8)V9.
|
Move the copybook date to W-TO-CONVERT-STUFFED-DATE. Then use W-CONVERTED-STUFFED-DATE as your source field to move to your permanent date field in your system.
This will pad your input data field with a trailing packed/COMP-3 zero, to make it a valid 5-byte packed number. Having defined a decimale place, the date should now be ready to use somewhere else, and the move statement will truncate the zero-value "decimal place" that was added to make the number valid. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Good day to all!
The pic should be 9(8) comp-3, just remember that the date format is YYYYMMDD or in the worst case YYYYDDMM. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
For packed-decimal fields, with an even PICTURE clause, except for 9(18), not counting (if applicable) the "ARITH(EXTEND)" compile option, bump it up by one. So, for example, 9(08) becomes 9(09), still occupying five-bytes, but allowing addressability to the high-order nibble.
Bill |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Jose Mateo wrote: |
Good day to all!
The pic should be 9(8) comp-3, just remember that the date format is YYYYMMDD or in the worst case YYYYDDMM. |
It isn't. The value shown is X'19990505'. That is not a comp-3, packed-decimal, number. Try it? S0C7.
X'199905050C' or X'019990505C' would be 5-bytes packed.
Plus, as Bill has indicated, if you define a comp-3 as an even number of digits, the compiler will generate code every time you change the value to ensure that the left-most "nibble" remains zero. If you define as an odd number of digits, no such code is needed, or generated. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Good day!
Bill Woodger said;
It isn't. The value shown is X'19990505'. That is not a comp-3, packed-decimal, number. Try it? S0C7.
X'199905050C' or X'019990505C' would be 5-bytes packed.
Bill, I tried it using Debug-tool with a simple program and didin't get a SOC7.
77 PACKD PIC 9(8) VALUE 19990505.
77 RECDATE PIC 9(9).
* MAIN.
MOVE PACKD TO RECDATE.
results are;
LIST PACKD ;
PACKD = 19990505
LIST RECDATE ;
RECDATE = 019990505 |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| Jose, if you look at the hexadecimal value for PACKD, you will find it is X'F1F9F9F9F0F5F0F5' -- which is a lot different than the value your first post described. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Robert, my mistake. I forgot to specify comp-3 for PACKD, thank you.
77 PACKD PIC 9(8) COMP-3 VALUE 19990505.
77 RECDATE PIC 9(9).
* MAIN.
MOVE PACKD TO RECDATE.
Results are:
LIST PACKD ;
PACKD = 19990505
LIST RECDATE ;
RECDATE = 019990505
LIST %HEX ( PACKD ) ;
%HEX ( PACKD ) = X'019990505F'
LIST %HEX ( RECDATE ) ;
%HEX ( RECDATE ) = X'F0F1F9F9F9F0F5F0F5'
Quote if I'm wrong, when you reference a input packed unsigned field the first thing that the compiler does is a ZAP of that field into a working field which then is asign a positve sign. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Jose,
You field looks like this X'019950505C'. So? No-one suggested that you could get an S0C7 by putting a value statemnet on the definition of a COMP-3 field. I'd guess not one single program in the world, almost, would work if that were to happen.
This is the value that is on the input file: X'19990505'. That is four bytes long. No sign of a sign. If you have that hexadecimal value in a packed field (remembering the COMP-3 this time) you will get an S0C7, because there is a numeric in the sign "nibble" (the last half-byte).
I'm sure there are lots of ways you can try to show different, but that is not relevant. You have to start with that hex value in a packed (COMP-3) field and then try to do something with it. If you manage that without an S0C7, (let's say MOVE it to your usage display field so you whole program isn't entirely wasted), you win a prize . If you try something irrelevant, for a third time, then I win a prize. How's that sound? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Jose Mateo wrote: |
| Quote if I'm wrong, when you reference a input packed unsigned field the first thing that the compiler does is a ZAP of that field into a working field which then is asign a positve sign. |
What is this supposed to mean?
Are you saying that if I reference an unsigned packed field with, say, an IF, the compiler is first going to generate a ZAP which by some magic generates a positive sign?
I know you are trying, Jose, but slow down. If you want to know what the compiler does, LIST the generated code. Then read the code. Then tell me. You get another prize if you are correct above. Generous aren't I? |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Bill Woodger wrote: |
I'm sure there are lots of ways you can try to show different, but that is not relevant. You have to start with that hex value in a packed (COMP-3) field and then try to do something with it. If you manage that without an S0C7, (let's say MOVE it to your usage display field so you whole program isn't entirely wasted), you win a prize . If you try something irrelevant, for a third time, then I win a prize. How's that sound? |
Of course, I'm thinking without NUMPROC(NOPFD). With that, you might avoid the S0C7, but if you do you lose some of your data. I think I still win that one.
I really am going to rant about that, soon. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Bill, you are partially right. After working with many languages, I just forget some details on COBOL.
NUMPROC(NOPFD)
01 YMD PIC X(4) VALUE X"19990505".
01 PACKD REDEFINES YMD PIC 9(8) COMP-3.
* MAIN.
IF PACKD GREATER THAN 19990000
MOVE PACKD TO RECDATE
END-IF
The object code for the above IF statement is the following;
(LIT+64) C5C5E3E6 D64040D6 D5C54040 01999000 0F2F1F00
BAL 14,310(0,13) TGT TEST INFORMATION AREA +10
EQU *
MVC 392(5,13),80(9) TS2=0 PACKD
OI 396(13),X'0F' TS2=4
CLC 392(5,13),80(10) TS2=0 PGMLIT AT +76
The compiler did add the nible byte for the sign with a low-value. On the IF, PACKD was move to a working field and the OI did convert the sign byte to '0F'. The IF was executed and the move took place with no exception. Congratulations Bill!!! |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
So, Jose, to get back to the first point, is X'19990505' packed? No.
By the time you do your IF (with NUMPROC(NOPFD) it looks like this, X'1999050F'. You now have a valid packed number, but have lost some of the data.
Going way back to what enrico correctly said, someone has put what looks like decimals into what is effectively just a binary format, or not a standard IBM Cobol numeric format. To use that field, without loosing any of the data, you have to get a sign onto it, or work out how to calculate from base 16 so that you get the digits which make up the numeric data.
If you (or the TS, actually) code it in the copybook (of an existing and possibly external file) as COMP-3, it will not work. Either S0C7, or data loss.
For the IF, the compiler has done the "sign-fix" in a work area. If you MOVE or do any calculation with it, the compiler will "fix" the sign and the receiving field will never have known that the original field has lost the X'x5'. Data loss will be permanent - and not reversible, as it is irrelevant which number has been lost to make space for the sign, all numeric digits (and zero, if not mathematically a digit :-) will be replaced by the generated sign. Many-to-one relationship. Notice it two weeks later and you are up the creek.
It is easier to "notice" it without NUMPROC(NOPFD), isn't it?
Note no ZAP is involved, either. And this from your last post
| Quote: |
| The compiler did add the nible byte for the sign with a low-value |
makes no sense to me, as there is not a "low-value" (X'00') in sight.
If I was "partially right" I'm also interested in the other bit, where I must have been "partially wrong".
Two earlier replies, one from someone highly credible (that's you, enrico), stated pretty clearly that it was not packed/COMP-3. You then balddly (and boldly) stated that it was. When contradicted, you then used a USAGE DISPLAY field to show it was packed. Then a VALUE clause on a packed field.
Slow down. When someone credible (you again enrico, just as an example) says something I think looks wrong, my starting point is "how is he right", not just to jump in with my first thoughts. I would have to be convinced of my point and be able to argue it lucidly before a full-on contradiction, and I'd still be able to accept that I was wrong if it turned out I was. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Good day, Bill!
Sorry, I didn't put the results of the fields but here's code with the results. I added a COMPUTE to see the generate code and it does a move to the working field then it does a move-numeric to asign a positive. If you could see that I redefined a PIC X(4) with a PIC 9(8) comp-3 and it added a one byte for the sign with low-value. Once you reference the pack field it moves it to a working field and it moves a sign to the added byte but you don't lose data instead you wind up with a extra digit of zero.
01 YMD PIC X(4) VALUE X"19990505".
01 PACKD REDEFINES YMD PIC 9(8) COMP-3.
01 PACKS PIC S9(8) COMP-3.
01 YMD . . . .. BLW=0000 050 DS 4C DISPLAY
01 PACKD . . BLW=0000 050 DS 5P PACKED-DEC R
01 PACKS . . .BLW=0000 058 DS 5P PACKED-DEC
000086 IF PACKD GREATER THAN 19990000
EQU *
MVC 392(5,13),80(9) TS2=0 PACKD
OI 396(13),X'0F' TS2=4
CLC 392(5,13),80(10) TS2=0 PGMLIT AT +76
000087 1 MOVE PACKD TO RECDATE
UNPK 24(9,9),80(5,9) RECDATE PACKD
OI 32(9),X'F0' RECDATE+8
000088 1 COMPUTE PACKS = PACKD
MVC 88(5,9),80(9) PACKS PACKD
MVN 92(1,9),0(12) PACKS+4 SYSLIT AT +0
LIST %HEX ( YMD ) ;
%HEX ( YMD ) = X'19990505'
LIST %HEX ( PACKD ) ;
%HEX ( PACKD ) = X'1999050500'
LIST %HEX ( PACKS ) ;
%HEX ( PACKS ) = X'199905050C'
LIST %HEX ( RECDATE ) ;
%HEX ( RECDATE ) = X'F1F9F9F9F0F5F0F5F0' |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Code: |
01 YMD PIC X(4) VALUE X"19990505".
01 PACKD REDEFINES YMD PIC 9(8) COMP-3.
|
by any standard the code is wrong!
it is generally not acceptable to redefine an item with a longer one
in this particular case it works because You ONLY read/fetch from PACKD
the proposed redefine construct is not valid for a general case!
but if You want to be right, I' ll make You happy!
you are right and we all are wrong  |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
enrico,
unfortunately, enterprise cobol allows you to redefine with a larger item,
the compiler just adds the necessary extra bytes to the original. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Going nowhere.
What you've done is a very sloppy equivalent to what I posted before you even intervened.
You don't address a single concrete question.
You said a ZAP. I said no. You showed code. I said no ZAP. You showed same code and some extra code. Still no ZAP. |
|
| Back to top |
|
|
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
Hey, Bill!
I was wrong on the ZAP instead it does MVC+OI for the MOVE or a MVC+MVN for the COMPUTE but no data is truncated instead the PIC 9(8) comp-3 is expanded one extra byte to acommdate the sign which includes a extra digit with a zero. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| Jose Mateo wrote: |
Hey, Bill!
I was wrong on the ZAP instead it does MVC+OI for the MOVE or a MVC+MVN for the COMPUTE but no data is truncated instead the PIC 9(8) comp-3 is expanded one extra byte to acommdate the sign which includes a extra digit with a zero. |
By including code you never mentioned. Goodness, how did I miss that?
You now have code which relies for initiliasation on what? To get your low-value. Tell me. I'm deeply interested.
You now have some "code" which "works" under NUMPROC(NOPFD), but under but not under the other two options.
I looked back through your other postings last night. I wish I'd done it before even replying the first time. |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
| Quote: |
I wish I'd done it before even replying the first time.
|
most of the time i try to do the same.
not being a moderator,
i really should not comment on other posts.
but sometimes the indignity inflicted on common sense and truth by some of the posts inspire me to say things that do not follow the politically correct course. |
|
| Back to top |
|
|
|
|
