Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Date in Copybook
Goto page 1, 2  Next
 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming
View previous topic :: :: View next topic  
Author Message
sree reddy

New User


Joined: 20 Jul 2007
Posts: 27
Location: bangalore

PostPosted: Tue Apr 19, 2011 2:07 am    Post subject: Date in Copybook
Reply with quote

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
View user's profile Send private message

Peter Nancollis

New User


Joined: 15 Mar 2011
Posts: 47
Location: UK

PostPosted: Tue Apr 19, 2011 2:11 am    Post subject:
Reply with quote

Depends how your code wants to see the value of those four bytes.
Back to top
View user's profile Send private message
sree reddy

New User


Joined: 20 Jul 2007
Posts: 27
Location: bangalore

PostPosted: Tue Apr 19, 2011 2:26 am    Post subject: Best Way to Use
Reply with quote

Best way to use How it ineeds to be defined in the Copy book

S9(8) Comp or ?
Back to top
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Tue Apr 19, 2011 2:44 am    Post subject: Reply to: Date in Copybook
Reply with quote

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

Code:
19000
9955C

pic 9(9) packed-decimal

which
transformed in a printable form would become
Code:
199905050


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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Tue Apr 19, 2011 4:35 am    Post subject: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Tue Apr 19, 2011 6:58 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2502
Location: Atlanta, Georgia, USA

PostPosted: Tue Apr 19, 2011 7:15 pm    Post subject: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Tue Apr 19, 2011 7:34 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Wed Apr 20, 2011 8:05 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 7913
Location: Bellevue, IA

PostPosted: Wed Apr 20, 2011 8:22 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Wed Apr 20, 2011 9:30 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Wed Apr 20, 2011 9:57 pm    Post subject: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Wed Apr 20, 2011 10:04 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Thu Apr 21, 2011 12:23 am    Post subject: Re: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Thu Apr 21, 2011 2:46 am    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Thu Apr 21, 2011 4:58 am    Post subject: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
Jose Mateo

Active User


Joined: 29 Oct 2010
Posts: 110
Location: Puerto Rico

PostPosted: Thu Apr 21, 2011 8:05 pm    Post subject:
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Global Moderator


Joined: 14 Mar 2007
Posts: 10202
Location: italy

PostPosted: Thu Apr 21, 2011 8:17 pm    Post subject: Reply to: Date in Copybook
Reply with quote

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 icon_evil.gif
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne

PostPosted: Thu Apr 21, 2011 8:57 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Bill Woodger

DFSORT Moderator


Joined: 09 Mar 2011
Posts: 7232

PostPosted: Thu Apr 21, 2011 9:16 pm    Post subject: Reply to: Date in Copybook
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> COBOL Programming All times are GMT + 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts TOT & DATE parameter in ICEMAN hemanthj642 DFSORT/ICETOOL 4 Mon Nov 14, 2016 5:19 am
This topic is locked: you cannot edit posts or make replies. How to pass the previous month date i... Suganya87 DFSORT/ICETOOL 5 Mon Oct 31, 2016 4:13 pm
This topic is locked: you cannot edit posts or make replies. Get correct date and time when curren... balaji81_k DB2 24 Fri Oct 14, 2016 10:40 pm
No new posts Copybook structure in Load module Vai123 COBOL Programming 7 Fri Sep 16, 2016 8:29 pm
No new posts Change date (DD/MM/YY) in 2nd record ... uday kiran DFSORT/ICETOOL 12 Wed Sep 07, 2016 10:57 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us