|
James, Have you verified your statement about triggering files in QTEMP? I've got a production FTP process that uses a trigger over STDOUT in QTEMP. This trigger is used to "echo" FTP messages to the JOBLOG and, since it's been running since V4Rx without issue, I'd have to say you can add a trigger to a file in QTEMP. Whether QTEMP is a real library or not is a topic for another post, but my point about 300+ QTEMP's was more about the number of trigger "objects" or "handles" that can be created. Again, I can have a predefined trigger in a qualified library. I suspect it is the trigger "object" that has the limitation of 300, not the physical file, regardless of where the file resides. Michael Rooney Citigroup International -----Original Message----- From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of James H H Lampert Sent: Wednesday, June 16, 2004 5:19 PM To: midrange-l@xxxxxxxxxxxx Subject: RE: Trigger library - how is this used? > Hypothetically, I could have an on-demand process that, with each call, > performs the ADDPFTRG command to a file. Now this may seem a little > extreme if we're talking about a file in a static library, but keep in > mind, this process could be adding a trigger to a file in QTEMP. If I > have 300 users executing this process, that would equate to 300 > triggers. 1. Unless something's changed in V5, you can't trigger files that are in QTEMP 2. Even if you could, QTEMP isn't a "real" library (as an MI programmer, I'm paid to know about these things), and besides, each of your hypothetical 300 users has his or her own QTEMP. And as to it being "so high as to be impractical to exceed, like 640k," well, 640k was never all that impractical to exceed, whereas 300 triggers on a single file, even if somebody did come up with a way to exceed it, would produce so much overhead that it would affect response times. Just allowing a fixed 10 of each type (60 in all) would be more than enough for any reasonable need, particularly since you can cascade triggers. -- JHHL -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.