Re: [U2] UniVerse Internal Date Blackout
See http://www.pickwiki.com/cgi-bin/wiki.pl?Date_Conversion_With_ICONV for a discussion of how ICONV deals with wholly numeric external dates. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
Sounds like you have hit the problem where, depending on the UDT.OPTIONS 82 value, the system will evaluate to external format first. If you change the UDT.OPTIONS 82 value then you should find it will work. The manual states that this should only happen with dates starting 10, 11 or 12... But worth a look... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 09 Jun 2006 15:16 To: u2-users@listserver.u2ug.org Subject: [U2] UniVerse Internal Date Blackout We just ran into a strange issue where LIST/SELECT cannot resolve an internal date - and it's for a block of one full year. From May 1, 2006 (14001) through April 30, 2007 (14365), if you try to SELECT records in a file using the internal date value where the DICT item has a D2/ (or similar) conversion, it will simply report back 0 records selected even though records exist for the dates. The same SELECT using an internal date of 14000 or less, or 14366 or greater returns the correct records. Without the conversion code in the DICT, all the SELECTs work. A sample of what we're seeing is below. The first and last examples work fine, the middle examples fail. UniVerse release is 10.1.4 PICK Format on UNIX. Curious if anyone else is experiencing this 'blackout' year with these internal dates. Thanks! SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
It's simply because 14001 through 14365 will resolve in the D2 conversion. That is a bad programming practice to use a DICT item with D2 and force internal format data for the compare. Just to be clear, this is not a problem with the system as all, this is just someone using the system incorrectly. If you are selecting on a DICT item that has a conversion, you NEED to select using converted values!! If you need to select both ways, just create another DICT item without the conversion code, ie. A DATE.INTERNAL dict item... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 09, 2006 10:16 AM To: u2-users@listserver.u2ug.org Subject: [U2] UniVerse Internal Date Blackout We just ran into a strange issue where LIST/SELECT cannot resolve an internal date - and it's for a block of one full year. From May 1, 2006 (14001) through April 30, 2007 (14365), if you try to SELECT records in a file using the internal date value where the DICT item has a D2/ (or similar) conversion, it will simply report back 0 records selected even though records exist for the dates. The same SELECT using an internal date of 14000 or less, or 14366 or greater returns the correct records. Without the conversion code in the DICT, all the SELECTs work. A sample of what we're seeing is below. The first and last examples work fine, the middle examples fail. UniVerse release is 10.1.4 PICK Format on UNIX. Curious if anyone else is experiencing this 'blackout' year with these internal dates. Thanks! SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
Hmm 14001 through 14365 are a valid julian dates (14001 = 1 Jan 2014) So it is reading these as external dates in your selection. 14000 is not a valid julian date, so it is reading it as internal. Just why are you trying to force selection using an internal date when you have a date conversion? Brian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 09 June 2006 15:16 To: u2-users@listserver.u2ug.org Subject: [U2] UniVerse Internal Date Blackout We just ran into a strange issue where LIST/SELECT cannot resolve an internal date - and it's for a block of one full year. From May 1, 2006 (14001) through April 30, 2007 (14365), if you try to SELECT records in a file using the internal date value where the DICT item has a D2/ (or similar) conversion, it will simply report back 0 records selected even though records exist for the dates. The same SELECT using an internal date of 14000 or less, or 14366 or greater returns the correct records. Without the conversion code in the DICT, all the SELECTs work. A sample of what we're seeing is below. The first and last examples work fine, the middle examples fail. UniVerse release is 10.1.4 PICK Format on UNIX. Curious if anyone else is experiencing this 'blackout' year with these internal dates. Thanks! SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse Internal Date Blackout
[EMAIL PROTECTED] wrote: We just ran into a strange issue where LIST/SELECT cannot resolve an internal date - and it's for a block of one full year. SNIP SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. SNIP I can't replicate your problem, but a somewhat random thought occurs to me. Edit the DICT item DATE in TESTFILE and save it with another name, GARY.DATE perhaps. No other change. Then do the exact same queries as previously but using GARY.DATE instead of DATE. I'm wondering if perhaps it's a reserved word issue. Nothing to support this, but it shouldn't take you very long to try. -- Allen Egerton aegerton at pobox dot com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
You have found the bug We came across this just the other week. It is all to do with Juliann dates. Can't remember the exact detail but will try to find out and post. Cheers Les Sherlock Hewkin Senior Developer Core Systems - 9951 01604 592289 -Original Message- From: Timothy Snyder [mailto:[EMAIL PROTECTED] Sent: 09 June 2006 16:03 To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse Internal Date Blackout [EMAIL PROTECTED] wrote on 06/09/2006 10:16:08 AM: SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. So why are you using internal date values against a date-formatted dictionary item?!? If (for whatever bizarre reason) you want to do that, just use a dict item that specifies a straight numeric value. For the record, this is looking at 14001 as year 14, Julian date 001. 14365 is Julian date 365 in year 14. 14366 is day 366 in year 14. Oh, wait, there was no day 366 in year 14 - bad data. Hey, there was no day zero (14000) either! Make it easier on the humans and unambiguous for the computers. Use external dates. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ This message has been comprehensively scanned for viruses, please visit http://www.avg.power.net.uk/ for details. This e-mail and any attachments are confidential and intended solely for the use of the addressee only. If you have received this message in error, you must not copy, distribute or disclose the contents; please notify the sender immediately and delete the message. This message is attributed to the sender and may not necessarily reflect the view of Travis Perkins plc or its subsidiaries (Travis Perkins). Agreements binding Travis Perkins may not be concluded by means of e-mail communication. E-mail transmissions are not secure and Travis Perkins accepts no responsibility for changes made to this message after it was sent. Whilst steps have been taken to ensure that this message is virus free, Travis Perkins accepts no liability for infection and recommends that you scan this e-mail and any attachments. Part of Travis Perkins plc. Registered Office: Lodge Way House, Lodge Way, Harlestone Road, Northampton, NN5 7UG. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] UniVerse Internal Date Blackout
Pointing out the obvious was very helpful, thanks. Gives me great confidence in dealing with IBM on odd issues such as this. We're dealing with report code written by a vendor (who knows what bizarre reason they had), and found the issue when the report wasn't returning expected results. We know using external dates work. We know having a dict item without the conversion works. We also know that using the bizarre scenario of an internal date against an external field works. What we don't know, and hence the question being posted, is why only this date range of 14001 - 14365 does not work. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 Timothy Snyder [EMAIL PROTECTED] com To Sent by: u2-users@listserver.u2ug.org [EMAIL PROTECTED] cc stserver.u2ug.org Subject Re: [U2] UniVerse Internal Date 06/09/2006 11:02 Blackout AM Please respond to [EMAIL PROTECTED] er.u2ug.org [EMAIL PROTECTED] wrote on 06/09/2006 10:16:08 AM: SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. So why are you using internal date values against a date-formatted dictionary item?!? If (for whatever bizarre reason) you want to do that, just use a dict item that specifies a straight numeric value. For the record, this is looking at 14001 as year 14, Julian date 001. 14365 is Julian date 365 in year 14. 14366 is day 366 in year 14. Oh, wait, there was no day 366 in year 14 - bad data. Hey, there was no day zero (14000) either! Make it easier on the humans and unambiguous for the computers. Use external dates. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
Thanks. Same thing happens with 13001 - 13365, etc. Not sure why our vendor wrote it that way, but we added the internal DICT items to handle it. Even though it's bad practice (we scratched our heads too when we uncovered it this morning), we were still puzzled why it does actually work for internal dates outside of those 1 - 365 ranges. I'd think it would error out, not return correct results. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 Peter Veenhof [EMAIL PROTECTED] tra.com To Sent by: u2-users@listserver.u2ug.org [EMAIL PROTECTED] cc stserver.u2ug.org Subject RE: [U2] UniVerse Internal Date 06/09/2006 11:00 Blackout AM Please respond to [EMAIL PROTECTED] er.u2ug.org It's simply because 14001 through 14365 will resolve in the D2 conversion. That is a bad programming practice to use a DICT item with D2 and force internal format data for the compare. Just to be clear, this is not a problem with the system as all, this is just someone using the system incorrectly. If you are selecting on a DICT item that has a conversion, you NEED to select using converted values!! If you need to select both ways, just create another DICT item without the conversion code, ie. A DATE.INTERNAL dict item... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 09, 2006 10:16 AM To: u2-users@listserver.u2ug.org Subject: [U2] UniVerse Internal Date Blackout We just ran into a strange issue where LIST/SELECT cannot resolve an internal date - and it's for a block of one full year. From May 1, 2006 (14001) through April 30, 2007 (14365), if you try to SELECT records in a file using the internal date value where the DICT item has a D2/ (or similar) conversion, it will simply report back 0 records selected even though records exist for the dates. The same SELECT using an internal date of 14000 or less, or 14366 or greater returns the correct records. Without the conversion code in the DICT, all the SELECTs work. A sample of what we're seeing is below. The first and last examples work fine, the middle examples fail. UniVerse release is 10.1.4 PICK Format on UNIX. Curious if anyone else is experiencing this 'blackout' year with these internal dates. Thanks! SELECT TESTFILE WITH DATE 14000 Bad data 14000 for conversion D2/. Unconverted data used for selection. 8 record(s) selected to SELECT list #0. CLEARSELECT SELECT TESTFILE WITH DATE 14001 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14365 0 record(s) selected to SELECT list #0. SELECT TESTFILE WITH DATE 14366 Bad data 14366 for conversion D2/. Unconverted data used for selection. 2 record(s) selected to SELECT list #0. Gary P. Canedy Database Analyst ProMutual Group (617) 757-6775 --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and delete this email from your system. If you are not the named addressee, you should not disseminate, distribute, print, or copy the email, or take any action in reliance on its contents. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- This email and any files transmitted with it are intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this email in error, please contact the sender immediately and
Re: [U2] UniVerse Internal Date Blackout
[EMAIL PROTECTED] wrote on 06/09/2006 11:40:36 AM: Pointing out the obvious was very helpful, thanks. Gives me great confidence in dealing with IBM on odd issues such as this. We're dealing with report code written by a vendor (who knows what bizarre reason they had), and found the issue when the report wasn't returning expected results. We know using external dates work. We know having a dict item without the conversion works. We also know that using the bizarre scenario of an internal date against an external field works. What we don't know, and hence the question being posted, is why only this date range of 14001 - 14365 does not work. You are providing dates in external format. YYJJJ is a valid external format. Before you proclaim this as a bug in UniVerse, try it in other databases. I suspect that if you go to a legacy pick system and try this, you'll get the same results. This behavior is by design, and is in support of legacy systems. Try 10001, 18365, and other such ranges. I suspect you'll find that they behave similarly. Face it - you're supplying data that is not consistent with the intent of the dictionary item. Anything that doesn't resolve to an external date will just be passed through. Tim Snyder Consulting I/T Specialist , U2 Professional Services North American Lab Services DB2 Information Management, IBM Software Group 717-545-6403 [EMAIL PROTECTED] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] UniVerse Internal Date Blackout
Maybe it's just a bug in the application - I.e. should be doing OCONV() in Select. Have you checked with your Vendor? Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, June 09, 2006 8:41 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] UniVerse Internal Date Blackout Pointing out the obvious was very helpful, thanks. Gives me great confidence in dealing with IBM on odd issues such as this. We're dealing with report code written by a vendor (who knows what bizarre reason they had), and found the issue when the report wasn't returning expected results. We know using external dates work. We know having a dict item without the conversion works. We also know that using the bizarre scenario of an internal date against an external field works. What we don't know, and hence the question being posted, is why only this date range of 14001 - 14365 does not work. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
