Just one more note on this...
I ran one last test this morning.
Instead of just changing the start-time of the schedule, this time I
deleted it from the server.
Client (SUMO):
05/15/2001 11:40:37.0635 : session.c (1525): sessRecvVerb(): length=000c, verb=11,
magic=a5
05/15/2001 11:40:37.0635 : session.c (1612): Length:12 Code: 0011 Type:
- AuthResult
05/15/2001 11:40:37.0636 : cusched.c ( 290): SendStartOp: Sending a CSStartOpVerb,
node: 'SUMO'
05/15/2001 11:40:37.0637 : cusched.c ( 291): scheduleName: 'TEST_2',
startDateToken: 05/15/2001 11:40:00
05/15/2001 11:40:37.0637 : session.c (1696): Send Verb: Length:29 Code: 0022
Type: CSStartOp
05/15/2001 11:40:37.0637 : session.c (1722): -
05/15/2001 11:40:37.0637 : session.c (1494): Recv Verb:
05/15/2001 11:44:50.0216 : session.c (1513): ...error-1
05/15/2001 11:44:50.0216 : session.c (1515): sessRecvVerb: Error -50 from call to
'readRtn'.
Server:
010515-114037: ANR0406I Session 1273 started for node SUMO (AIX) (Tcp/Ip
129.240.130.17(6307-6)).
010515-114037: ANRD pkthread.c(513): Run-time assertion failed:
txnP-txnInFlight,
010515-114037: Thread 100, File tmtxn.c, Line 833.
010515-114037: ANR7838S Server operation terminated.
010515-114037: ANR7837S Internal error TMTXN008 detected.
010515-114037: ANR7834S Thread 100 (tid 6409) terminating on signal 11 (Segmentation
violation).
010515-114037: ANR7834S GPR 0: 0xd0018f00, 1: 0x5c2a5ed0, 2: 0x301976a0, 3:
0x
010515-114037: ANR7834S GPR 4: 0x5c2a72e8, 5: 0x0008, 6: 0x0003, 7:
0x
010515-114037: ANR7834S GPR 8: 0x1000a817, 9: 0x1000a817, 10: 0xf0347e24,
.
.
.
.
On Mon, 14 May 2001, Tom Tann{s wrote:
Guess I'll submit an APAR tomorrow.
Did just run a trace on a client, and, as I thougt, the server sends wrong
information to the client.
05/14/2001 16:52:34.0790 : cusched.c ( 290): SendStartOp: Sending a CSStartOpVerb,
node: 'SUMO'
05/14/2001 16:52:34.0790 : cusched.c ( 291): scheduleName: 'TEST_2',
startDateToken: 05/14/2001 16:48:00
05/14/2001 16:52:34.0790 : session.c (1696): Send Verb: Length:29 Code: 0022
Type: CSStartOp
At 16:46 the schedule's startup-time was changed to 05/15/2001 16:48:00.
Anyway, thanks for suggestions.
On Mon, 14 May 2001, Michael Donabauer wrote:
Level 4.1.3.2 upgrade
[EMAIL PROTECTED] 14.05.2001 02.23 Uhr
Hello!
Whith server-level 3.7 and earlier, if a client-scheduler was scheduled to
do something whithin its queryschedperiod, and the schedule on the server
in the meantime was changed to run at a later time, the client scheduler
would report a ANS1814E and rescheduled itself.
I just upgraded to 4.1.3, and in this case, the client runs the original
scheduled task, just as if nothing was changed at the server.
Is this another case of buffers not cleared/updated on the server?
Anyone else seen this behaviour?
Tom
