• Please review our updated Terms and Rules here

Running MTREK on the VAX

vaxorcist

vaxorcist

Experienced Member
Joined
Apr 26, 2012
Messages
97
Location
Germany
I got MTREK from here and succeeded in building it from the FORTRAN sources using VMS V3.5 AND VAX FORTRAN V2.4.
Everythings seems fine in the beginning:

$ RUN MTREKINI

WELCOME TO MULTI-TREK INITIALIZATION

DEFAULTS FOR THE FOLLOWING QUESTIONS MAY BE SELECTED BY TYPING CARRIAGE-RETURN.

ENTER A RANDOM INTEGER: 341
ENTER STAR DENSITY OF UNIVERSE PARTS PER 100:
ENTER APPROXIMATE NUMBER OF STAR BASES:
ENTER NUMBER OF RANDOM JUMP POINTS:
ENTER ENERGY DRAIN FOR CLOAKING:
ENTER ENERGY DRAIN FOR ENERGY NET:
ENTER ENERGY DRAIN FOR TRACTOR BEAM:
ENTER WARP SPEED OF "BLACK HOLE":

MULTI-TREK INITIALIZED

$ MCR MTREK

Welcome to MULTI-TREK.

The following vessels are available for use.
Ship 1
Ship 2
Ship 3
Ship 4
Ship 5
Ship 6
Ship 7
Ship 8
Enter the number of the vessel you wish to command:1

From now on no more keyboard input is accepted anymore except for [CTRL-C] or [CTRL-Y] which both abort the game.
The terminal type I use is VT100 via PuTTY.
What's going wrong - do I overlook something?
 
It looks like a straightforward ACCEPT statement is used to get user input.

Perhaps add a WRITE statement after the ACCEPT to see if it gets passed there?

Dave
 
I see you had a look at the sources:

1031 FORMAT('$Enter the number of the vessel you wish to command:')
ACCEPT*, IW
OK = .TRUE.
IF (.NOT.(IW .GT. 8 .OR. IW .LT. 1)) GOTO 2100
TYPE*, ' Number out of range'
OK = .FALSE.
2100 CONTINUE

When I enter e.g. "9" I get the "Number out of range" message, so my input is read.
And I get the message "This ship already has a commander" when I choose a vessel that's already been chosen by another gamer (me on another terminal session).
Sometimes I get after a short while:

*** BOOM ***

YOUR SHIP HAS BEEN DESTROYED
FORTUNATELY YOU ESCAPED WITH YOUR LIFE.
UNFORTUNATELY, YOU HAVE BEEN GIVEN A NEW COMMAND.

ARE YOU READY TO ACCEPT THIS ASSIGNMENT?

Again no chance of entering any further commands.
I looked for "ARE YOU READY TO ACCEPT THIS ASSIGNMENT?" in the sources and found:

1141 FORMAT('0YOUR SHIP HAS BEEN DESTROYED'/, ' FORTUNATELY YOU E
*SCAPED WITH YOUR LIFE.'/, ' UNFORTUNATELY, YOU HAVE BEEN GIVEN A N
*EW COMMAND.'//, '$ARE YOU READY TO ACCEPT THIS ASSIGNMENT? ')
CALL YESNO(0, YES)
IF (.NOT.(YES)) GOTO 4330
WRITE(5, 1142)
1142 FORMAT(' GOOD!')

From there I followed the SUBROUTINE call "CALL YESNO(0, YES)" to its definition:

SUBROUTINE YESNO(PROMPT, FLAG)
LOGICAL*1FLAG, OK
BYTE PROMPT(1)
BYTE ANSWER(4)
C
OK = .FALSE.
ANSWER(1) = 0
CALL REDPMT(PROMPT, ANSWER, 4, NCHRS)
4920 CONTINUE
IF (.NOT.(NCHRS .LE. 0)) GOTO 4950
NCHRS = 1
ANSWER(1) = 0
4950 CONTINUE
IF (.NOT.(ANSWER(1) .GE. 'a' .AND. ANSWER(1) .LE. 'z')) GOTO 497
*0
ANSWER(1) = (ANSWER(1) - 'a') + 'A'
C * CHECK FOR YES
4970 CONTINUE
IF (.NOT.(ANSWER(1) .EQ. 'Y')) GOTO 4990
FLAG = .TRUE.
OK = .TRUE.
C * CHECK FOR A NO
GOTO 5000
4990 CONTINUE
IF (.NOT.(ANSWER(1) .EQ. 'N')) GOTO 5010
FLAG = .FALSE.
OK = .TRUE.
C * INCORRECT RESPONSE
GOTO 5000
5010 CONTINUE
IF (.NOT.(PROMPT(1) .EQ. 0)) GOTO 5030
CALL OUTCH(13, 1)
CALL OUTSTR(.TRUE., 'ANSWER YES OR NO? ', .FALSE.)
CALL INCHAR(ANSWER, 4, .TRUE., - 1, NCHRS, IER)
GOTO 5040
5030 CONTINUE
CALL REDPMT('ANSWER YES OR NO? ', ANSWER, 4, NCHRS)
5040 CONTINUE
5000 CONTINUE
4930 IF (.NOT.(OK)) GOTO 4920
RETURN
END

Here you see several calls to subroutines, whereof two are used for input:
- REDPMT ()
- INCHAR ()
and everything is far more complicated than a standard FORTRAN input :-((

How good are you at FORTRAN?
My FORTRAN knowledge is about 30 years old (that would not be too bad if my memory would serve me as well as 30 years ago ...)
I think I will have to use the VAX DEBUGGER to see where things go wrong.

Ulli
 
I was dabbling recently. I wrote a graphics/DMA driver for RT-11...

I have some work to do today, but will take a look at the sources when I am finished...

Dave
 
I have guess:
I'm not running from a real VT100 terminal (but from PuTTY), and there's are some obscure (at least to me) TERMINAL CONTROL ROUTINES in terminal.for.
Maybe they are (part of?) the problem?
Thanks for your kind offer to help!!!

Ulli
 
>>> Thanks for your kind offer to help!!!

No problem.. It would be good to get this going..

>>> Maybe they are (part of?) the problem?

My gut feeling is not.

Most of the subroutines in terminal.for would just output the odd 'random' character to the terminal if the control codes were not understood. The only one I was concerned about was GTCHAR - and (on inspection) most of this subroutine has been commented out (apart from hardcoding the terminal to a VT100 with TTYPE = VT100).

I think the 'black magic' (and your problms) are occurring within subroutines WAIT (wat.for) or INCHAR (inpout.for). Both of these subroutines invoke system routines (SYS$SETIMR and SYS$WAITFR in the case of WAIT and SYS$QIOW in the case of INCHAR).

My suggestion would be a WRITE statement before and after these to see which one is 'baulking' or 'locking up'. We can then concentrate on that little devil...

My VAXstation is in storage at the moment I am afraid...

Dave
 
So I have looked for the text string "SYS$" in all of the FORTRAN source files and identified the following as potential issues (i.e. not specifically related to FORTRAN but to the underlying operating system or system libraries):

INPOUT.FOR

Subroutines IOINIT, FLUSH and INCHAR.

RUNMTR.FOR

Subroutine RUNMTR.

TERMINAL.FOR

This file is benign, as all of the SYS$ calls have been commented out.

WAIT.FOR

Subroutine WAITFR.

I would suggest modifying the FORTRAN files INPOUT, RUNMTR and WAIT and adding debug WRITE statements either side of the system calls. This will give us a clue where the code is misbehaving (assuming it is related to a system call of course).

Dave
 
Thanks again!
Meanwhile I used the VAX DEBUGGER and found out that there is an endless loop between routines INCHAR and YESNO.
See the attached files for the details.
INCHAR is on your list of the suspect one - very interesting ...
I'll let you know when I try your proposals.
I run all test on a SIMH VAX-11/780 using VMS V3.5.
I chose VMS V3.5 because it's contemporary to the timestamp of BUILD.COM (and other files); the FORTRAN files are of a newer date.
And some details of the command procedures told me it must be pre VMs V4.x

Ulli
 

Attachments

  • Loop.txt
    1.5 KB · Views: 2
  • mtrek-list.txt
    90.1 KB · Views: 2
  • inpout-list.txt
    12.8 KB · Views: 1
I suspect your problem is in INCHAR.

I suspect that YESNO is looping because it is waiting for you to make a valid entry. I suspect (if INCHAR moans) you will get IERR set to -3 to signify that the human did not respond.

Yes, the value of variable IERR would be interesting.

I see the whole of the inpout file being riddled with system-specific 'stuff'. of course, the code could be stuck in a loop because you are running it under the debugger. The QIO will only return a valid (none error) code once you have poked a key...

Interestingly, subroutine IOINIT is not called. The call of this is commented out in terminal.for.

Dave
 
Last edited:
Here is the value of IERR (-3 as expected) while stepping through the loop:

DBG>STEP ; EXA INCHAR\IERR
start at YESNO\%LINE 28
stepped to YESNO\%LINE 29
%DEBUG-W-SYMNOTACT, symbol INCHAR\IERR not active or not in active scope
DBG>STEP ; EXA INCHAR\IERR
start at YESNO\%LINE 29
routine break at INCHAR
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
routine start at INCHAR
stepped to INCHAR\%LINE 13
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 13
stepped to INCHAR\%LINE 14
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 14
stepped to INCHAR\%LINE 15
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 15
stepped to INCHAR\%LABEL 2100
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LABEL 2100
stepped to INCHAR\%LABEL 2120
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LABEL 2120
stepped to INCHAR\%LABEL 2130
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LABEL 2130
stepped to INCHAR\%LINE 26
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 26
stepped to INCHAR\%LINE 27
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 27
stepped to INCHAR\%LINE 28
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 28
stepped to INCHAR\%LINE 29
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LINE 29
stepped to INCHAR\%LABEL 2150
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\IERR
start at INCHAR\%LABEL 2150
stepped to YESNO\%LINE 30
%DEBUG-W-SYMNOTACT, symbol INCHAR\IERR not active or not in active scope
DBG>STEP ; EXA INCHAR\IERR
start at YESNO\%LINE 30
stepped to YESNO\%LABEL 5000
%DEBUG-W-SYMNOTACT, symbol INCHAR\IERR not active or not in active scope
DBG>

I noticed that while the loop is running free (without the DEBUGGER active) the CPU usage is approx. 100%

Why does INCHAR consider all input "invalid"???
So the "bad code" is probably inside INCHAR ...

Could I possibly modify INCHAR to leave the checks out and accept whatever the keyboard sends?

A little offtopic:
What model of VAXstation do you own?

Ulli
 
I have a little 4000/96.

I was just looking at the RATFOR source, and it makes much more sense than the generated FORTRAN (especially in terms of the source code structure).

I would print the input parameters (on entry to INCHAR) and the resulting status at the end of it).

On entry, there are a number of interesting input parameters (including an echo flag and a timeout). I would be interested in what these are, and the resulting status from the QIO call.

On input: SIZE, ECHO, TIMOUT and COUNT.

On output: IERR.

I suspect a parameter to the QIO (or one of the flags) is not as expected and the QIO call is moaning at us).

There is some much more detailed stuff around the QIO call itself we can look at if the above doesn't solve our problem...

Dave
 
Last edited:
It's getting late - I'll get the values you want tomorrow.

Where did you get your programming skills from?

Thanks again!!!

Ulli
 
Self taught (largely).

I was into hardware, then started programming microprocessors in assembly, then moved onto Pascal then modula2, then C and Ada. I learned FORTRAN at University. I then got a job writing software in CORAL 66 and CUTLASS (a high-level language developed by the CEGB in the UK for use in power starions).

Dave
 
Good morning,

these are my results for INPUT, SIZE, ECHO, TIMOUT, COUNT, IERR, and ISW (result of SYS$QIOW):

DBG>EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 13
stepped to INCHAR\%LINE 14
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 14
stepped to INCHAR\%LINE 15
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 15
stepped to INCHAR\%LABEL 2100
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LABEL 2100
stepped to INCHAR\%LABEL 2120
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LABEL 2120
stepped to INCHAR\%LABEL 2130
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LABEL 2130
stepped to INCHAR\%LINE 26
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 26
stepped to INCHAR\%LINE 27
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 27
stepped to INCHAR\%LINE 28
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: 0
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 28
stepped to INCHAR\%LINE 29
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LINE 29
stepped to INCHAR\%LABEL 2150
INCHAR\INPUT(1): 0
INCHAR\SIZE: 4
INCHAR\ECHO: -1
INCHAR\TIMOUT: -1
INCHAR\COUNT: 0
INCHAR\IERR: -3
DBG>STEP ; EXA INCHAR\INPUT; EXA INCHAR\SIZE; EXA INCHAR\ECHO; EXA INCHAR\TIMOUT; EXA INCHAR\COUNT; EXA INCHAR\IERR
start at INCHAR\%LABEL 2150
stepped to 20785
INCHAR\INPUT(1): 0
%DEBUG-W-SYMNOTACT, symbol INCHAR\SIZE not active or not in active scope
DBG>

DBG>g
start at INCHAR\%LINE 13
write to INCHAR\ISW at PC INCHAR\%LINE 25 +35
old value = 0
new value = 316
DBG>

I hope you can make sense of it ...

I have / I had got some assumptions:
- Simulation - The SIMH VAX may not simulate the real VAX exactly enough to handle this code
- Timing - The SIMH VAX may be too fast (no, neither throttling nor a lower baud rate did change anything except execution speed)
- Wrong VMS version - QIO functions and returned condition values could have changed with VMS versions

I'm convinced the sources (as they are from a DECUS tape) are not at fault, but something with the way I'm using them.
I will try VMS V2 and V4 as well.

I'm looking forward to your considerations!

Ulli

Ulli
 
I have a bit of time before the hire car arrives...

On entry to subroutine INCHAR the following fields are of interest: SIZE, ECHO and TIMOUT.

Some of these parameters are used to calculate IOFC as an input parameter to SYS$QIOW. This is also of interest.

After SYS$QIOW has executed, the function return value (ISW) tells us whether the function call worked or not.

The return values COUNT and IERR are returned from subroutine INCHAR.

Between these, it may give us a clue as to what is going on.

EDIT: You just beat me to it! Let me have a look...

Dave
 
Citation from: AA-Z501B-TE VAX-VMS System Services Reference Manual V4.2
"Programs should not test for success by comparing the return status to
SS$_NORMAL. A future release of VAX/VMS might add new alternate
success codes to an existing service, causing programs that test for
SS$_NORMAL to fail."
 
Unfortunately, an IERR return of -3 is a 'catchall' error condition.

The input parameters look good. I can see why it loops, as there is no timeout! It just polls for a keypress or nothing (or an error of course).

Nonetheless, it would be interesting to see the actual values of IOFC before the QIO call, and ISW after.

It looks as though things are working 'normally' and then just decides to throw an error.

EDIT: Good find about SS$_NORMAL. That also ties in with my 'catchall' error return...

Dave
 
That's what the DEBUGGER tells me:

DBG>g
routine start at YESNO
routine break at INCHAR
DBG>g
routine start at INCHAR
write to INCHAR\IOFC at PC INCHAR\%LINE 14 +14
old value = 0
new value = 4145
DBG>g
start at INCHAR\%LINE 15
write to INCHAR\ISW at PC INCHAR\%LINE 25 +35
old value = 0
new value = 316
DBG>g
start at INCHAR\%LINE 26
routine break at INCHAR
DBG>g
routine start at INCHAR
write to INCHAR\IOFC at PC INCHAR\%LINE 14 +14
old value = 4145
new value = 4145
DBG>g
start at INCHAR\%LINE 15
write to INCHAR\ISW at PC INCHAR\%LINE 25 +35
old value = 316
new value = 316
DBG>g
start at INCHAR\%LINE 26
routine break at INCHAR
DBG>g
routine start at INCHAR
write to INCHAR\IOFC at PC INCHAR\%LINE 14 +14
old value = 4145
new value = 4145
DBG>g
start at INCHAR\%LINE 15
write to INCHAR\ISW at PC INCHAR\%LINE 25 +35
old value = 316
new value = 316
DBG>g
start at INCHAR\%LINE 26
routine break at INCHAR
DBG>g
routine start at INCHAR
write to INCHAR\IOFC at PC INCHAR\%LINE 14 +14
old value = 4145
new value = 4145
DBG>g
start at INCHAR\%LINE 15
write to INCHAR\ISW at PC INCHAR\%LINE 25 +35
old value = 316
new value = 316
DBG>

Ulli
 
We can work on that...

I suppose the next question is, what happens to the function return code when you press a key?

Dave
 
Next round:
I modified INPOUT.FOR so that:

...
EQUIVALENCE(TC, IOSB(3))

CV DEBUG
TYPE *,' IOFC BEFORE=',IOFC

CALL FLUSH(0)
IOFC = %LOC(IO$_READVBLK) .OR. %LOC(IO$M_TRMNOECHO)

CV DEBUG
TYPE *,' IOFC AFTER1=',IOFC

IF (.NOT.(.NOT.ECHO)) GOTO 2100
IOFC = IOFC .OR. %LOC(IO$M_NOECHO)

CV DEBUG
TYPE *,' IOFC AFTER2=',IOFC

2100 CONTINUE
IF (.NOT.(TIMOUT .GE. 0)) GOTO 2120
P3 = TIMOUT
IOFC = IOFC .OR. %LOC(IO$M_TIMED)

CV DEBUG
TYPE *,' IOFC AFTER3=',IOFC

GOTO 2130
2120 CONTINUE
P3 = 0
2130 CONTINUE
ISW = SYS$QIOW(, %VAL(ICHNL), %VAL(IOFC), IOSB, , , INPUT, %VAL(SI
*ZE), %VAL(P3), , , )

CV DEBUG
TYPE *,' ISW=',ISW
...

After compiling the debugging session shows me:

$ mc mtrek

VAX-11 DEBUG Version 3.4-2

%DEBUG-I-INITIAL, language is FORTRAN, module set to 'PLAYER'
DBG>g
routine start at PLAYER

Welcome to MULTI-TREK.

The following vessels are available for use.
Ship 5
Ship 6
Ship 7
Ship 8
Enter the number of the vessel you wish to command:5
IOFC BEFORE= 0
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
IOFC BEFORE= 4337
IOFC AFTER1= 4145
IOFC AFTER2= 4209
IOFC AFTER3= 4337
ISW= 316
...

I does not matter whether I type anything or not - always the same flow.

Ulli
 
You must log in or register to reply here.
Back
Top