Mark Johnson wrote on 10/21/2006 09:43:13 PM:
> Keep in mind that 16MB for 32 users is 250 times the memory available
circa
> late 1970s' with the Microdata Royale series.
>
> There's something to be said for programming on an older system that
gives
> you respect for todays horsepower.
I agr
On Fri, 20 Oct 2006, Anthony W. Youngman wrote:
Our system was short of RAM - 16 meg for 32 users (PI/Open on an EXL 7330).
It thrashed enough under normal load, even before you started to try and
build large (and I mean LARGE) strings in BASIC...
We don't have this issue - we have 16Gig for
On Fri, 20 Oct 2006, Kevin King wrote:
Jeff, why WRITESEQF instead of WRITESEQ? You're completely
undermining write buffering with WRITESEQF are you not?
I think this may be from an example where I was debugging code and used
WRITESEQF to ensure that all I/O was written before the program c
The c/r delay may have had something to do with it. "PRINT expression:" ran
faster than "PRINT expression" and If you had lots of PRINTs
Does anyone out there remember the "Newt", the Visa" and also (perchance)
where the MV file transfer protocol based on "More Tea Vicar" got it's name?
McD
Well said, Mark.
My opportunity to really learn about Pick performance was circa 1985 on
an ADDS 1500, a PC XT clone with 256K RAM, a 10MB hard drive and a port
of the ADDS Mentor Pick O/S.
We ported some code from an ADDS 4000 to it and I was shocked to see how
slowly a 3-column screen of multiv
1 cent.
Mark Johnson
- Original Message -
From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
To:
Sent: Saturday, October 21, 2006 6:29 PM
Subject: Re: [U2] Slow ascii output
> In message <[EMAIL PROTECTED]>,
> Claus Derlien <[EMAIL PROTECTED]> writes
> >no one and
In message <[EMAIL PROTECTED]>,
Claus Derlien <[EMAIL PROTECTED]> writes
no one and I mean NO ONE uses a system with 16 MB ram today!
we have 65 users on 2 gig ram, and when we do payments of unemployment
salaries to our members we do everything in memory, and just write the
edi file to a reco
no one and I mean NO ONE uses a system with 16 MB ram today!
we have 65 users on 2 gig ram, and when we do payments of unemployment salaries
to our members we do everything in memory, and just write the edi file to a
record a large batch takes less than two minutes and it also generates payment
I use writeseq. Yesterday I ran a process that selects a number of
files, parses them into special formats, and writes them out.
I created 65 files, 106 MB. Total time: 4 minutes.
UD 5.1.27, Windows 2003
However, if you are writing to a "dir" file then you can use either a
dynamic array or dime
In message <[EMAIL PROTECTED]>, Jeffrey Butera
<[EMAIL PROTECTED]> writes
I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to
be 7.1.x).
I'm selecting a bunch of records and then outputting data from them into an
ascii file in _HOLD_. If I open a sequential file, writ
Jeff, why WRITESEQF instead of WRITESEQ? You're completely
undermining write buffering with WRITESEQF are you not?
-Kevin
[EMAIL PROTECTED]
http://www.PrecisOnline.com
** Check out scheduled Connect! training courses at
http://www.PrecisOnline.com/train.html.
---
u2-users mailing list
u2-u
Hi Jeff,
Couple of ideas:
-1-
Try WRITESEQ instead of WRITESEQF so the system will buffer your output
in memory and write it to disk in more efficient chunks. According to
"HELP WRITESEQF", your command "forces UniData to immediately write the
data to the disk" so you're taking an I/O hit.
-2-
W
I'm going to ask yet another dumb question - Unidata 6.1.4 on Solaris (soon to
be 7.1.x).
I'm selecting a bunch of records and then outputting data from them into an
ascii file in _HOLD_. If I open a sequential file, write the data
line-by-line (WRITESEQF) and close the file, it takes about 5
13 matches
Mail list logo
