|
View previous topic :: View next topic
|
| Author |
Message |
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
Does an INITIALIZE on a parent variable assure that the default values be moved to the child variables according to their datatypes ?. Eg. below
| Code: |
05 :TAG1:-TIME-STAMP.
10 :TAG1:-CURR-DTE-CCYYMMDD.
15 :TAG1:-CURR-DATE-CC PIC 9(2).
15 :TAG1:-CURR-DATE-YY PIC 9(2).
15 :TAG1:-CURR-DATE-MM PIC 9(2).
15 :TAG1:-CURR-DATE-DD PIC 9(2).
10 :TAG1:-CURR-TIME.
15 :TAG1:-CURR-TIME-HH PIC 9(2).
15 :TAG1:-CURR-TIME-MM PIC 9(2).
15 :TAG1:-CURR-TIME-SS PIC 9(2).
15 :TAG1:-CURR-TIME-HD PIC 9(2). |
If a command is issued as INITIALIZE :TAG1:-TIME-STAMP (please disregard the :TAG1: as already replaced).
After the above command is executed, is there a 100% possibility that the value of TAG1:-TIME-STAMP would be -
0000000000000000
or do I need to give the instructoin with REPLACING ALL ?
I think there is something going wrong with a program of mine where the DB gets updated with TS as NULL instead of ZEROES.
Regards,
Sumesh
Edited: Please use BBcode when You post some code/error, that's rather readable, Thanks... Anuj |
|
| Back to top |
|
 |
Bharath Bhat
Active User
Joined: 20 Mar 2008
Posts: 283
Location: chennai
|
|
|
|
| Quote: |
| I think there is something going wrong with a program of mine where the DB gets updated with TS as NULL instead of ZEROES |
Surely something is going wrong. I would suggest you to check the value of the null indicator during insert/update and make sure it does not have negative value. |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Quote: |
| Does an INITIALIZE on a parent variable assure that the default values be moved to the child variables according to their datatypes ? |
Too much of IMS these days,  ? COBOL variables does not follow this terminology - they have "labels" - in your case there is a group-variable at 05-level underneath you have two other group-level variables at level-10.
| Quote: |
| or do I need to give the instructoin with REPLACING ALL ? |
Did you try it, what happend?
| Quote: |
| I think there is something going wrong with a program of mine where the DB gets updated with TS as NULL instead of ZEROES. |
What is 'TS" here? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
| There is a link to manuals at the top of the page. You need to find the COBOL Language Reference and Programming Guide manuals and read the information in them about INITIALIZE. The manual is usually the best source of information about syntax, what actually happens when the COBOL statement is executed, and COBOL data values. |
|
| Back to top |
|
|
Ketan Varhade
Active User
Joined: 29 Jun 2009
Posts: 197
Location: Mumbai
|
|
|
|
| Check by displaying the value before inserting the values in the DB so that you get a clear picture that where the problem is ? |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
You could move ZERO to the TIME-STAMP '05' Group Level and all subordinates will be set to '0's. Providing they are always PIC 9, this is the most efficient method to clear these variables as internally, one (or possibly two) Assembler instructions are generated. With INITIALIZE, there will be 8 (or more) Assembler instructions generated. Also, a VALUE ZERO at the Group Level will clear all to '0's.
If in the future, these variables are redefined as COMP-3, then this method won't work and you'd be better off with INITIALIZE.
Bill |
|
| Back to top |
|
|
cybertaurean
New User
Joined: 22 Dec 2008
Posts: 87
Location: US
|
|
|
|
Hi All,
Thanks a lot for the replies!!!
@anuj - TS stands for timestamp which is same as the timestamp in picture.
@bill - i would try out the suggestion for sure. However, I would also like to state that this behaviour was noticed only once. The timestamp structure comes inside another 01 level variable which houses lots of other information. This 01 level is INITIALIZED everytime.
In 99.99% of the cases, we have all zero entries for TS in DB. It is just that we had this one-off case come up.
In case this comes up again, I would go with the option of having ZEROES moved explicity to the variables right before the DB ISRT.
Thanks once again.
Regards,
Sumesh |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
| Quote: |
| In 99.99% of the cases, we have all zero entries for TS in DB. |
How do colclude this, I'm clueless? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| In 99.99% of the cases, we have all zero entries for TS in DB. It is just that we had this one-off case come up. |
Suggest you look for something else that inserted/updated the row incorrectly. . . |
|
| Back to top |
|
|
Craq Giegerich
Senior Member
Joined: 19 May 2007
Posts: 1512
Location: Virginia, USA
|
|
|
|
| If the columns are defined as a timestamp in a DB2 database they could not be all zeros, that would be an invalid value for a timestamp. |
|
| Back to top |
|
|
The Dark Knight
New User
Joined: 16 Feb 2010
Posts: 3
Location: India
|
|
|
|
Always use
| Code: |
INITIALIZE VARIABLE REPLACING ALPHANUMERIC BY SPACES
NUMERIC BY ZEROES |
|
|
| Back to top |
|
|
|
|
