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: 00000011 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: 00000022
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: ANR9999D 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:
0x00000000
010515-114037: ANR7834S GPR 4: 0x5c2a72e8, 5: 0x00000008, 6: 0x00000003, 7:
0x00000000
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: 00000022
>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
> >
>
>