mats@forbrk.UUCP (02/23/87)
(There seems to be no newsgroup dedicated to general UUCP discussion,
just mail via UUCP, so I arbitrarily picked this one. Please feel free
to redirect it if there is a better place that I missed).
The time has come for me to speak of many things, this time about
about teaching UUCP about different classes of jobs, so that I can
control what gets shipped when. The typical example is that if I
connect to machine 'X' to send a piece of mail which happens to be
high-priority, I may not want to dump all of the news that has batched
up at that same time - I may need to leave my phone line free for
other high-priority requests, and defer the news transfer until
some off-hours time when the phone line isn't needed for high-priority
stuff. Anybody have thoughts on how one might set this up? (I am
running HDB UUCP on a V.2 port at the moment, if anyone cares).
I have heard that 4.3BSD has some sort of job grading feature, but
I don't know anything about it, and (a) I don't have access to 4.3BSD
and am not likely to any time soon and (b) The person that originally
brought this problem up to me was Bob Kridle of Mt Xinu, which leads
me to believe that it doesn't solve the problem either. Perhaps a
short description from 4.3 might be appropriate anyway.
One of the big problems seems to me to be that both ends would have to
support any new protocol as to whether a particular job was eligible
for sending during a particular connection or not. So at the moment
I am not proposing to do anything at all except suffer with an
uncomfortable situation, and opening up the floor for discussion.
Thoughts? I promise to summarize anything interesting mailed to
me instead of posted to the world.
Mats Wichmann ... {ihnp4,hplabs}!fortune!forbrk!mats
Fortune Systems ... ucbvax!dual!forbrk!mats
(I don't think anyone has UUCP map data on us so you may have to try
to construct a path from the above)josh@hi.UUCP (02/24/87)
In article <192@forbrk.UUCP> mats@forbrk.UUCP (Mats Wichmann) writes: >(There seems to be no newsgroup dedicated to general UUCP discussion, > just mail via UUCP, so I arbitrarily picked this one. Please feel free > to redirect it if there is a better place that I missed). > >The time has come for me to speak of many things, this time about >about teaching UUCP about different classes of jobs, so that I can >control what gets shipped when. The typical example is that if I >connect to machine 'X' to send a piece of mail which happens to be >high-priority, I may not want to dump all of the news that has batched >up at that same time - I may need to leave my phone line free for >other high-priority requests, and defer the news transfer until >some off-hours time when the phone line isn't needed for high-priority >stuff. Anybody have thoughts on how one might set this up? (I am >running HDB UUCP on a V.2 port at the moment, if anyone cares). First, it is always possible to make news transfer at a different by batching it. Batching allows the machine to just make a list of articles it needs to transfer. Then late at night the Daemon will crawl out and send the news (while fixing any shoes that happen to be sitting around :-). If you don't have a version of news that does this I am sure you can get a copy of it from one of the archive sites. Currently the version I have is 2.11 and I love it. Another solution could be the following. Assuming you have two phone lines, put two entries into your uucp/L.sys file for a machine. One entry could be called X.slow and one could be called X. All news can be sent to X.slow and mail passed onto X. This means that even while transfering news, you can have your machine call up X again and transfer mail. This also means that people who are mail through your machine don't get high priority. They get struck in with the rest of the news. Also, users who use UUCP to pass stuff around get put into the high priority que for file transfers. I know when I am transfering via UUCP, I want it there fast! I am running off at the mouth? :-) > >Thoughts? I promise to summarize anything interesting mailed to >me instead of posted to the world. > >Mats Wichmann ... {ihnp4,hplabs}!fortune!forbrk!mats >Fortune Systems ... ucbvax!dual!forbrk!mats >(I don't think anyone has UUCP map data on us so you may have to try > to construct a path from the above) Josh Siegel ... ucbvax!unmvax!hi!josh josh@hi.unm%hc.dspo.gov ( By boss will post his own options )
uusgta@sw1e.UUCP (02/25/87)
In article <192@forbrk.UUCP>, mats@forbrk.UUCP writes: > I may not want to dump all of the news that has batched > up at that same time - I may need to leave my phone line free for > other high-priority requests, and defer the news transfer until > some off-hours time when the phone line isn't needed for high-priority Why not implement a separate spooling mechanism that only dumps into UUCP during off-hours. Something similar to the at q's, perhaps combined with changes to uucico (to get low priority stuff if no high priority stuff is queued) seems quick & dirty. I see the high kludge quotient but what else is wrong with this? -- # ---Tom Adams--- # {bellcore,ihnp4}!sw1e!uusgta St. Louis MO 314-235-4237 # Opinions expressed here are mine, not those of Southwestern Bell Telephone
ahby@meccts.UUCP (02/27/87)
In article <487@sw1e.UUCP> uusgta@sw1e.UUCP (uusgta) writes: >In article <192@forbrk.UUCP>, mats@forbrk.UUCP writes: >> I may not want to dump all of the news that has batched >> up at that same time - I may need to leave my phone line free for >> other high-priority requests, and defer the news transfer until >> some off-hours time when the phone line isn't needed for high-priority > >Why not implement a separate spooling mechanism that only dumps into UUCP >during off-hours. Something similar to the at q's, perhaps combined with >changes to uucico (to get low priority stuff if no high priority stuff is >queued) seems quick & dirty. I see the high kludge quotient but what else >is wrong with this? Actually, there is a really easy way to do this. If you think changing uucico is kludgy, just wait :-). You create a directory called /usr/spool/HOLDuucp. In crontab you have lines which call the scripts 'holdjobs' and 'releasejobs' at specific times. The script holdjobs looks at the jobs in /usr/spool/uucp, and any job with a grade less than or equal to X gets moved into /usr/spool/HOLDuucp. Note that you only move the C. files, not anything else. The script releasejobs just moves /usr/spool/HOLDuucp/C* back into /usr/spool/uucp - thus enabling the jobs once again. This is REALLY a kludge, but it will work - I think. Unless uuclean comes along and deletes old D. files while the C. files are in another directory. However, you could modify your uudemon.day to check HOLDuucp for old jobs as well. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.COM MECC Technical Services ATT (612) 481-3589 "Character is what you are in the dark!"
dave@lsuc.UUCP (03/02/87)
In article <899@sonne.hi.uucp> josh@hi.unm@hc.dspo.gov (Josh Siegel) writes: >Another solution could be the following. Assuming you have two phone >lines, put two entries into your uucp/L.sys file for a machine. One >entry could be called X.slow and one could be called X. All news can >be sent to X.slow and mail passed onto X. This means that even while >transfering news, you can have your machine call up X again and >transfer mail. Watch out for two problems if you try this: (a) if you don't change how your machine identifies itself when calling X while a call to X.slow is in progress, it will immediately run up against a LCK..yourname on the other side and exit. (b) if you have a version of UUCP which checks the remote site name on connection, and you call it as X.slow while it identifies itself as X, the call will fail. David Sherman The Law Society of Upper Canada Toronto -- { seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!dave
josh@hi.UUCP (03/04/87)
In article <1613@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: }In article <899@sonne.hi.uucp> josh@hi.unm@hc.dspo.gov (Josh Siegel) writes: }>Another solution could be the following. Assuming you have two phone }>lines, put two entries into your uucp/L.sys file for a machine. One }>entry could be called X.slow and one could be called X. All news can }>be sent to X.slow and mail passed onto X. This means that even while }>transfering news, you can have your machine call up X again and }>transfer mail. } }Watch out for two problems if you try this: }(a) if you don't change how your machine identifies itself when } calling X while a call to X.slow is in progress, it will immediately } run up against a LCK..yourname on the other side and exit. }(b) if you have a version of UUCP which checks the remote site name } on connection, and you call it as X.slow while it identifies } itself as X, the call will fail. } Good point. Even my software does this. Boy... don't I feel like a fool.. :-) --Josh Siegel -- Josh Siegel, Project Asst. | Internet: siegel@hc.dspo.gov Electrical and Computer Eng. | UUCP: hc!siegel University of New Mexico | (505) 277-1611 (Lab) Albuquerque, New Mexico 87131 | (505) 277-2497 (Home)