One of our clients had some problems with the Backup Service in their GIS system. They turned it off for about 2 months and at the end of this period there were about 4M records with ARCHIVE_FLAG = 0 in the ARCHIVE_INFO table. The DB size had increased to hundreds of GBs. I decided to change all of the records with ARCHIVE_FLAG = 0 to ARCHIVE_FLAG = 2 and ARCHIVE_DATE = “now() + 1 year” to make them “invisible” for both the Backup and Purge Services. Then I turned the Backup Service back (thus I stopped the DB growing) and started “returning” those changed records back day by day. So, the index/backup/purge services got back to the rut.
Important: it’s just an idea, not the direct instructions. You should understand how it works to make such changes… If you don’t understand the SI/GIS DB you mustn’t do anything with it except maybe select queries.
Here is the SQL query I used (I ran it several times, day by day to avoid excessive DB loading):
update ARCHIVE_INFO set ARCHIVE_FLAG = 2, ARCHIVE_DATE = ARCHIVE_DATE + 365
where TO_CHAR(ARCHIVE_DATE, 'yyyy-mm-dd') = '2014-01-01' and ARCHIVE_FLAG = 0;
I see a lot of requests about training/documentation/tutorials for Gentran/GIS/SI. Maybe, one day I post some basic things about SI/GIS administration and maps, but now I’d like to share some links to very useful documents from IBM. Now they have a very good online documentation, but I’m also using PDF files from FTP:
If you need to change a property file in your GIS/SI but you don’t want to restart the server (to apply the changes), you can create a simple business process for this particular file and run it every time you make changes:
<assign to="cache_type" from="'properties'"></assign>
<assign to="cache_name" from="'base_edi'"></assign>
- ‘base_edi’ is the property file name without extension (i.e. the full name is base_edi.properties)
- Don’t forget that you need to change both base_edi.properties and base_edi.properties.in
The other day I was working on an XSLT map for webMethods. In that map I needed to calculate a unit price using the gross price and the price basis. I.e. for example if the price is $1,250.00 per thousand, the unit price will be $1250/1000 – $1.25 per unit. Besides the map itself, the system used several pre and post processors for some additional data changes, and I was getting ‘NaN’ instead of expected $1.25. I’m not a big expert in webMethods, I was not sure about all the pre/post processors used, so I did the following: I changed the map to put both the price and the price basis into the text fields (in my case it was X12 810, IT1-04 so I used IT1-07 which is AN1..48). And I found that the price was “1250” (as expected) but the price basis was “TP” (X12 4010, 639 Basis of Unit Price Code, TP = Price per Thousand) instead of “1000”. I.e. the system converted my “1000” into “TP”, that’s why it was ‘NaN’ in the output (1250/TP = NaN). It became clear why I was getting this error and I was able to fix the map. So, often there is a way to make a “black box” a little bit clearer – you just need to redirect you questionable data into text elements.