[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 44.370::system_management

Title:system management communications forum
Moderator:CHEST::THOMPSON
Created:Fri Mar 21 1986
Last Modified:Thu Jul 08 1993
Last Successful Update:Fri Jun 06 1997
Number of topics:490
Total number of notes:2018

53.0. "I thought IT was Information Technology" by RDGE00::MCNEILL (Bene agere et laetare) Fri Jun 26 1987 15:20

	Anyone out there know why the queue for FTSV no longer points at
the logical FTSV$BATCH which used in turn to point to the generic batch 
queue? FTSV now points to RDGE00_BATCH directly which means that 
reassigning the logical in your process table, in order to assure that FTSV 
runs on the same node, does not work. We do this to enable our programs to 
talk to FTSV via mailboxes.

	Consequently we have wasted a considerable amount of time looking 
for a problem caused by minor amendments to our code when really the system 
management team have cocked us up.

	WHY ARE WE NOT AT LEAST TOLD THAT SUCH A CHANGE IS BEING MADE? WE 
READ THIS NOTES FILE TO FIND OUT WHAT IS HAPPENING ON THE SYSTEMS. WHY DOES 
NOBODY ACTUALLY TAKE THE TROUBLE TO TELL US?

	IS THERE ANYTHING ELSE THAT WE SHOULD BE TOLD?

Angry of Acre Rd.

Peter
T.RTitleUserPersonal
Name		DateLines
53.1Oh no not again!.RDGE00::MCNEILLBene agere et laetareFri Jun 26 1987 15:252
	Oh look it's back but with a new name. Is this an advertising ploy 
or FTSV$QUEUE no longer fashionable and we've a new name FTSV$BATCH?
53.2What's your problem ?VULCAN::HAYWARDConcerned of TilehurstFri Jun 26 1987 16:5226
		
		Peter, I don't understand your problem.  Surely
	your application shouldn't care what node your FTSV job 
	runs on ?

	If it does then why ?

		Please remember, FTSV always used to actually queue
	to SYS$BATCH, which as we all know would use RDGE00_BATCH OR
	RDGE28_BATCH.

		As for the reason for changing the queue, thats
	another question !!!

		But for the record I asked for it to be changed, my
	reason was simple.  If System management insist that RDGE28
	network database does not have ALL nodes defined then whats
	the point of of using that node to copy files around ? It
	only proves frustrating if you are on U9, where you can see 
	the file you want to copy, so you set off and FTSV copy to
	go and get it, only to find that the job ran on RDGE28
	which didn't know about the node :-(


		Iain..
53.3RDGE00::MCNEILLBene agere et laetareFri Jun 26 1987 17:1437
RE .2 
		
>		Peter, I don't understand your problem.  Surely
>	your application shouldn't care what node your FTSV job 
>	runs on ?

>	If it does then why ?

	Simple answer is that it uses a mailbox to communicate with FTSV. 
That mailbox must be on the same node as the FTSV process that wants to 
write to it otherwise, unsurprisingly it is "not found" and then the 
mailbox process sits there for ever waiting to be told what happened.

>		Please remember, FTSV always used to actually queue
>	to SYS$BATCH, which as we all know would use RDGE00_BATCH OR
>	RDGE28_BATCH.

	If you look back at my note you will see that we reassign the 
logical in our process table which causes FTSV to use OUR assigned queue. 
The value in the process table is set up automatically in a LOGIN.COM by 
looking at the nodename.

>		But for the record I asked for it to be changed, my
>	reason was simple.  If System management insist that RDGE28
>	network database does not have ALL nodes defined then whats
>	the point of of using that node to copy files around ? It
>	only proves frustrating if you are on U9, where you can see 
>	the file you want to copy, so you set off and FTSV copy to
>	go and get it, only to find that the job ran on RDGE28
>	which didn't know about the node :-(

	I couldn't agree more, however wouldn't it have been more sensible 
and no more difficult to have simply changed the value of the logical 
FTSV$QUEUE ? This would have been totally transparent to everyone. 

Peter