Gaaa! no...most of the files I've uploaded were measly little files. Tiny, little itty bitty files. Like specs on the wall small. Mostly forecast files where you just have 12 three to four char qty's for a couple thousand parts.
And you gotta realize that people get used to their graphs. In the corporate world people like "warm and fuzzies"....stuff that costs a lot of system resources and adds no value but makes them feel good. So they get to see that the upload is going to take ten minutes so off to the break room they go. And yes....I can guarantee that the files will be small because the company doesn't exist any more ;) Warm and fuzzies. I had a "morning report" that I spent probably close to 1000 hours on, that would break out projections for the end of the month and compare it to budget and do crazy stuff like show how much more warehouses had to ship, or how much less to make the projection for the EOM. Like, as if seeing the shortage at the end of the month would make the customers order more!!!! But....it made the guy setting in the top floor at the big desk feel good. Total waste of time, but he felt good. Company is gone now, but he felt good. * ============================================================================ == SCREEN.GRAPH: DONE.PCT=INT(((RECORDS.READ*100)/SELECTED)+.5) SMSG=DONE.PCT:' Percent Done, ':RECORDS.READ:' Records Read out of ':SELECTED:' selected' CC=40-(INT(LEN(SMSG)/2)) CRT L(10):C(CC):SMSG:EOL DONE.CNTR=INT((DONE.PCT*60+50)/100) CRT L(12):C(10):STR(LX,DONE.CNTR) CRT L(13):C(10):STR(LX,DONE.CNTR) SMSG='Projected Finish Time : ':OCONV((((TIME()-WAS)/DONE.PCT)*100)+WAS,'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(15):C(CC):SMSG:EOL SMSG='Current Time : ':OCONV(TIME(),'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(16):C(CC):SMSG:EOL CRT L(20):C(1): RETURN * ========================================================================= ACTUAL.FINISH.TIME: SMSG='Actual Finish Time : ':OCONV(TIME(),'MTHS') CC=40-(INT(LEN(SMSG)/2)) CRT L(17):C(CC):SMSG:EOL CRT L(20):C(1): RETURN * ============================================================================ == Allen E. Elwood www.tortillafc.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Timothy Snyder Sent: Wednesday, January 04, 2006 19:12 To: u2-users@listserver.u2ug.org Subject: RE: [U2] openseq question Allen E. Elwood wrote on 01/04/2006 01:29:47 PM: > I've always found it helpful to open the file/record in 'regular' mode first > to find out if the directory entry worked or possibly to write a null record > if it didn't. So, if the O/S-level file is multi-megabytes, you're reading the whole thing into memory? That could cause problems with shared memory and will certainly create a burden on the system. It also kind of defeats the purpose of using a sequential file, since you're reading the whole thing in, then opening it again and reading through the entire file a second time with READSEQ. Since you've incurred the memory and performance hit to pull the whole thing into a variable, you might as well waltz through that variable to extract the lines an attribute at a time with REMOVE or READNEXT. If you're following this practice only on small files, and only infrequently, it's probably OK, but how can you guarantee that will always be the case? 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/ ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
