peqs, hold files Options

[KaptnLafs]

Are there any settings that can be made to automatically save hold files to a folder in case you have to restore from a backup?

[Visage - Evoluti...]

Not that I'm aware of, BUT, nothing wrong with you copying out of PEQS :-) Or using SP-EDIT to out to a file in RUNOFF format

We have been doing this for around 20 years in our R5 application, automatically keeping copies of audit-trail documents, which are stored in a standard pick file.

In the interum, some of our clients used this for COLD storage (Computer Output to Laser Disk --> what we would now simply call a CD burner), though these days I'd be inclined to throw out to underlying host file system, or a mounted SAMBA share in your case.

Indeed, with our Visage R5 product, we now tend to generate PDF's of everything, including stuff like invoices, statements, remittances etc, which alleviates the storage requirement inside the database

[TonyG]

If you use the E option on the file-save, your PEQs file will get saved to the backup.

That doesn't help with transient jobs which go from program to spooler to printer, and then they're deleted. I don't believe you can put a trigger on the PEQS file, so you can't copy the item to another file in real time. You'll probably need to have all print jobs held (using option H or HP) in addition to printing, then use a phantom to find specific jobs to archive. Removing jobs afterward could be a hassle.

Personally I think this is an area where it would be nice to get more control over the processes, but I doubt it will ever happen.
- For example, it would be nice if we could have triggers on peqs.
- Or, it would be nice if we could overload the peqs OSFI driver to do what we wanted before or after specific events like New, BeforePrint, AfterPrint, or BeforeDelete, AfterDelete, or others.
- It would be nice if we could provide an alternate store location, so that for example we could put peqs under the /tmp/spooler file system and still make use of the hdr: driver that provides print job metadata as well as allowing all spooler operations to still make use of the jobs.

As always, this is a public forum and you will rarely get an official response here. And I don't think you will get a solid answer from our respected colleagues in the field because the answer may be too esoteric, probably even undocumented. My advice is to file a request through your VAR or with TL Support, see what they have to say, and then share the results with the rest of us here.

Good luck

[DvRa]

since this is fairly general and event based programming is something I have been thinking about I am making these comments.
I have never been kean on object languages purhaps that just laziness and because it is cosy for me to stick to databasic as usual but I think from what I know of them I have a case. Object languages are about being able to interveen into a large piece of existing software which nessesarily requires some compromise but to me they seem to follow a "referencial" model , one can interveen at various points or "events" but can one then link these events together to form a different flow of control?. Probably one must set flags to alter the flow of control. My thinking is that instead of surendering to flags one should surender to the goto and that the control program should be a speghetti into which one can place extra branching?.