I just saw this and for some reason .. I got the one where Oleg replied to it (I snipped it to make this post shorter).
--- Nick Kostirya <[EMAIL PROTECTED]> wrote: > > Hello All. > > > > To estimate the situations I can use J for, I am looking for the > > successful stories of processing data arrays with J. > > Huge data arrays are meant! :-) > > > > > First of all I am interested in learning the data levels, the space > > they occupied in the storage and the information regarding the > > hardware used for computing. Besides, the knowledge regarding the > > specificity of operations with those huge data arrays would be > > desirable. > > > > I’ll be much obliged for the detailed information. > > > > All the best, Nick So one of the use of J in our Supply-Chain System (for more info: http://www.luenthai.com/supplychain.htm ) is for the generation of data to create the Material Purchase Request. The material purchase request is a critical document because it has to be sent to the suppliers ASAP. The earlier the better since the supplier only have a finite capacity to produce your materials. So sending your request late would mean that other manufacturers doing the same products would get the materials first ... while you get it late thereby forcing you to ship your products late. Now each of the materials to be ordered are actually categorized by it usage: 1. By Article (AUV) 2. By Article and Size (ASUV) 3. By Article and Size and Destination (ASDUV) 4. By Article and Size and Customer (ASCUV) There ARE MORE ... I'll just stop here. ;) Your inputs are: 1. Bill Of Material - this is the list of all materials needed to create just 1 garment. You actually have a two dimensional matrix specifying the average quantity and the color of each items needed to produce an article for a certain garment. *Material *Usage *Consumption *UOM *Article1 *Article2 *Article3 *ArticleN COTTON AUV 0.75 yds RED BLUE GREEN BUTTONS ASUV 12 pcs WHITE CLEAR BLACK 2. Purchase Order - Here is the list of the actual items to be ordered and the some of the information will be: *Article *Customer *Size *QTY Article1 Japan Small 10 Article2 Japan Small 200 Article1 US Large 1000 NOTE: I'm being simplistic here, there are actually more information like Quantity Per Size override, destination or customer overrides and other inputs ... The original document was generated using an AS400 system and the generation of the MPR is an iterative process. This is because most of the time, the specification on how a garment must be made is revised by the client almost everyday. So whenever any of the information is changed, the MPR must be recalculated and sent back to the client by the factory for review until the client is satisfied. Unfortunately, there are hundreds of merchandisers who will be doing the same thing over and over everyday (they need it for costing and profitability). By the time the project was handed to me 3 years ago, some merchandisers took a week to return the MPR document to their respective clients. The mandate was to be able to return the document to the client in 24 hours. The first thing I did was redesign the process to using the minimal data that it need and converted all the string values to numbers (NO BOX ARRAYS). I then setup an application server that would do the calculation centrally, this is where J resides. The machine specs was: HP/Compaq Server 2 Separate Intel 2.8Ghz CPU's (I forgot what the "model" was) 4GB RAM 120 GB Raid Harddisk Windows 2000 Advance Server The data was retrieved and stored to a separate MS-SQL Server 2000 machine using direct ActiveX calls to ADODB protocols. So basically, each client, using Internet Explorer, would connect to the application server using sockets and requests a private J Session and calculates their MPR information. Suffice to say, we were successful and the system has been running for 3 years. Now, were actually in the process of implementing our next generation system and my new strategy was to decentralized processing to the clients. With our shift to AJAX technology and increase in our client system requirement ... we have already rolled-out the new system to 4 factories. My new client specs are now: 2.0Ghz or greater Intel CPU 512MB RAM 60GB Harddisk WindowsXP Professional Basically, what I did for our new implementation is that I redesigned our interface to be able to run our J scripts in either the Application Server or the Client machine. The slowest part of the previous version was writing the data generated by J back to the DB. In response to that, for client side runs, I wrapped the J scripts in .NET where J only needs to be sent and return the data in ARRAY format and left the MS-SQL retrieval and updates to ADO.NET. This actually optimized our code in a way that large data runs would finish in less than a minute. Regarding data space, I don’t actually have specific information but keep in mind that we really optimized on sending J the minimum data possible to calculate the values. So we basically average with J allocating around 60MB of data per calculation with a max of around 800MB (it was a really big order and brought the server to its knees - the server was swapping like crazy and we had to ask other users to NOT use the system while we rerun that order). So to summarized we have: 1. An application server which provides private J sessions per clients. 2. Our average concurrent J sessions (2 years ago during peak time) running on the server is around 20 session. 3. With the new decentralized system, our average concurrent users now is only 8. 4. Our average allocated memory to J is around 60MB. 5. Our current MS-SQL database is around 48GB. 6. The slowest part of the system is not during J calculation but during the time J calls ADO to retrieve and write to MS-SQL. We've proven this with the new version where J does not connect directly to the DB and instead expect array input and output. Hope this helps ... cause my break's almost over and I haven't had lunch. :) r/Alex
---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
