Re: Running SE with log files linked to /dev/null

Our (graphics) users typically use the db in a very "non interactive" mode: 1) Create large graphics files 2) Load to db (creates records for the "intelligent graphics") 3) Run reports (quantity take-offs) Step (2) is the gotcha - we do it by "submitting the load request to a batch queue (NQS). From this point, the user is divorced from what is going on with the database - the background process scans the graphics files, finds an element, then builds a db record for it. I have seen situations where the number and size of the graphics files are such that the log file will grow to consume all available space on the disk where the log file is. This results in lots of nasty errors, and as a side affect will CORRUPT the graphics file. If we first link the log file to /dev/null, then load the graphics files, we don;t have to worry about the log file getting so big that it uses all the disk. As an example - I do a "load project db" operation that results in a total db size of 70K blocks. After I "cat >> log.file" the total db size shrinks to 6K blocks. Why doesn't SE have a reusable log??? Is it a technological limitation or a marketing decision?? JJ -------- ^^^^^^^^^ Jack Jolly @ jjolly@jjolly.b24b.ingr.com (| 0 - |) | * | Intergraph Corporation, Huntsville AL \\_______/ AEC Project Management Support