Yep... this issue had a lllooonnnggg discussion thread back when it first occurred -- search on the APAR number for the gory details, and there are caveats about which 5.1.? level has the fix (last I saw it was 5.1.1.5, I think)... it's in the APAR.
Don France Technical Architect -- Tivoli Certified Consultant Tivoli Storage Manager, WinNT/2K, AIX/Unix, OS/390 San Jose, Ca (408) 257-3037 mailto:[EMAIL PROTECTED] Professional Association of Contract Employees (P.A.C.E. -- www.pacepros.com) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of L'Huillier, Denis Sent: Thursday, August 15, 2002 10:48 AM To: [EMAIL PROTECTED] Subject: Re: SQL timestamp not working when upgraded to 4.2.2 for summary tabl e Hey look what I found... ************************************************************************* $$4225 Interim fixes delivered by patch 4.2.2.5 $$ Patches are cumulative, just like PTFs. So Interim fixes $$ delivered as "4.2.2.5" include those delivered in previous patches ************************************************************************* <@> IC33455 SUMMARY TABLE NOT BEING FULLY UPDATED And I'm querying the summary table.. Thanks.. -----Original Message----- From: PAC Brion Arnaud [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 15, 2002 11:34 AM To: [EMAIL PROTECTED] Subject: Re: SQL timestamp not working when upgraded to 4.2.2 for summary tabl e Hi Denis, Just for information : I tested your query on my system (4.2.2.15) and it worked like a charm (except I had to modify "Node Name" to "Node_Name") Did you apply the latest PTF's to get 4.2.2.15 ? Maybe it could help ... Good luck anyway ! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Arnaud Brion, Panalpina Management Ltd., IT Group | | Viaduktstrasse 42, P.O. Box, 4002 Basel - Switzerland | | Phone: +41 61 226 19 78 / Fax: +41 61 226 17 01 | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- From: L'Huillier, Denis [mailto:[EMAIL PROTECTED]] Sent: Thursday, 15 August, 2002 15:39 To: [EMAIL PROTECTED] Subject: SQL timestamp not working when upgraded to 4.2.2 for summary tabl e Hello - Since I upgraded our 4.1 server to 4.2.2 my sql query against the summary table no longer works. Has anyone run into this problem before? Here's the query... /* --- Query Summary Table ---- */ /* --- Run as a macro ----- */ select cast(entity as varchar(12)) as "Node Name", \ cast(activity as varchar(10)) as Type, \ cast(number as varchar(8)) "Filespace", \ cast(failed as varchar(3)) "Stg", \ cast(affected as decimal(7,0)) as files, \ cast(bytes/1024/1024 as decimal(12,4)) as "Phy_MB", \ cast(bytes/1024/1024 as decimal(12,4)) as "Log_MB" \ from summary where end_time>=timestamp(current_date -1 days, '09:00:00') \ and end_time<=timestamp(current_date, '08:59:59') \ and (activity='BACKUP' or activity='ARCHIVE') \ order by "Node Name" Here's the output from a 4.1 server: Node Name TYPE Filespace Stg FILES Phy_MB Log_MB ------------ ---------- --------- --- --------- -------------- -------------- CENKRS BACKUP 649 0 26 0.0222 0.0222 CENNTNFS BACKUP 648 0 15 0.0072 0.0072 RSCH-AS1-P BACKUP 615 0 90 7.3412 7.3412 RSCH-DB2-P BACKUP 614 0 43 5.6337 5.6337 RSCH-DB3-P BACKUP 608 1 0 0.0000 0.0000 RSCH-DB3-P BACKUP 616 0 114 1477.5513 1477.5513 RSCH-FS1-P BACKUP 611 1 0 0.0000 0.0000 RSCH-FS1-P BACKUP 618 0 97 10.3834 10.3834 RSCH-WS5-P BACKUP 667 0 29 2.5706 2.5706 RSCH-WS6-P BACKUP 666 0 35 5.4812 5.4812 TPRSCHHOME01 BACKUP 624 2 0 0.0000 0.0000 TPRSCHHOME01 BACKUP 627 0 2467 16412.1675 16412.1675 TPRSCHHOME02 BACKUP 634 1 0 0.0000 0.0000 TPRSCHHOME02 BACKUP 637 0 3552 19135.1409 19135.1409 Here's the output from a 4.2 server: Node Name TYPE Filespace Stg FILES Phy_MB Log_MB ------------ ---------- --------- --- --------- -------------- -------------- REMEDY2W BACKUP 3896 0 64 0.0000 0.0000 I only get one line back.. There should be one for each node (about 100 nodes on this server) Now, for any of you who are wondering.. 'Filespace' and 'Stg' are columns put in just as place holders. We were using the 'q occu' to generate charge back info. I needed to generate an sql query would look Just like the q occu (same columns) so the data could be fed into an existing program which handled charge Back to the clients. Regards, Denis L. L'Huillier 212-647-2168