Now, here is a technical one...

When doing a *read* from a terminal device using QIOW, one
can use IO$M_TIMED and supply a timeout value in P3. That
works perfectly and we use that a lot.

Now, we are having issues with an application when *writing*
to a terminal (TNA) device using QUIW that points to a small
label printer. If the printer is offline or not accessable on
the network, the application just hangs.

As far as I can see, QIO/QIOW does not support a timeout value
when used for writing, is that correct?

I was hoping that one could add a timeout value just as in the
read case, but it doesn't look so. So I do not see how to get
out of the hanging call to QIOW. Maybe using QIO, and doing
some extra coding to check the I/O, I guess.

So, is there a way to get out of this state, still using QIOW?

These are new printers where they decided to use Wifi
instead of wired connection. We do not see these issues
on our older label printers which are all hard wired...

I will of course again suggest that they do take the cost to
ask for wired network connections instead of using Wifi...

I also fixed a COM file that pings these 7 printers once each
10 seconds, and it clearly shows that the connections comes
and goes more or less all the time. And when that happens to
be the same time as they try to print a label, it just hangs...

Regards,
Jan-Eik.

On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
> When doing a *read* from a terminal device using QIOW, one
> can use IO$M_TIMED and supply a timeout value in P3. That
> works perfectly and we use that a lot.
>
> Now, we are having issues with an application when *writing*
> to a terminal (TNA) device using QUIW that points to a small
> label printer. If the printer is offline or not accessable on
> the network, the application just hangs.
>
> As far as I can see, QIO/QIOW does not support a timeout value
> when used for writing, is that correct?

Yes.

https://vmssoftware.com/docs/VSI_IO_REF.pdf

Table 5.6 lists IO$M_TIMED for IO$_READ* while table 5.8
does not list it for IO$_WRITE*.

> I was hoping that one could add a timeout value just as in the
> read case, but it doesn't look so. So I do not see how to get
> out of the hanging call to QIOW. Maybe using QIO, and doing
> some extra coding to check the I/O, I guess.
>
> So, is there a way to get out of this state, still using QIOW?

Totally untested idea:

SYS$SETIMR with an AST routine that calls SYS$CANCEL

Arne

On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:

> Now, here is a technical one...
>
> When doing a *read* from a terminal device using QIOW, one
> can use IO$M_TIMED and supply a timeout value in P3. That
> works perfectly and we use that a lot...

I've never had great success with $QIO and $IO_PERFORM timeouts,
generally or particularly with network devices.

It's all gotten better by appearances, but it was long a source of app
races and of occasional app bugs.

I usually use a timer AST and a $CANCEL for the async read and write
I/O, and a $WAKE.

The AST sets an interlocked "cancel in progress" bitlock in the read or
write $HIBER loop to avoid races, and with a $SCHDWK running to clean
up any lingering $HIBER/$WAKE races lurking.

Threads would be workable here, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
> On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:
>
>> Now, here is a technical one...
>>
>> When doing a *read* from a terminal device using QIOW, one
>> can use IO$M_TIMED and supply a timeout value in P3. That
>> works perfectly and we use that a lot...
>
> I've never had great success...

I'm sorry about that. As I wrote, it works perfectly. In the
case of reads, of course, where it is supported.

My question was about writes, and it has been confirmed that
timeout paramaters are not supported there. Thanks Arne.

Now we need to weight the coding work against getting
network cables installed to the printers. Wired printers
will also "solve" the issue with the current code. We have
15-20 older similar Zebra label printers, all wired, and
we do not see these error scenarios with those.
All using the same C routine for the QIOW calls.

Jan-Erik.

Den 2023-06-21 kl. 23:17, skrev Arne Vajhøj:
> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>> When doing a *read* from a terminal device using QIOW, one
>> can use IO$M_TIMED and supply a timeout value in P3. That
>> works perfectly and we use that a lot.
>>
>> Now, we are having issues with an application when *writing*
>> to a terminal (TNA) device using QUIW that points to a small
>> label printer. If the printer is offline or not accessable on
>> the network, the application just hangs.
>>
>> As far as I can see, QIO/QIOW does not support a timeout value
>> when used for writing, is that correct?
>
> Yes.
>
> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>
> Table 5.6 lists IO$M_TIMED for IO$_READ* while table 5.8
> does not list it for IO$_WRITE*.
>
>> I was hoping that one could add a timeout value just as in the
>> read case, but it doesn't look so. So I do not see how to get
>> out of the hanging call to QIOW. Maybe using QIO, and doing
>> some extra coding to check the I/O, I guess.
>>
>> So, is there a way to get out of this state, still using QIOW?
>
> Totally untested idea:
>
> SYS$SETIMR with an AST routine that calls SYS$CANCEL
>
> Arne
>
>

My thought was to just queue the I/O, wait a sec or two
using $WAIT and then check the IOSB. If not completed OK,
CANCEL and return an error to the application...

We'll see. Hopefully we can convince them to install
wired connections instead of using Wifi...

Jan-Erik.

On 2023-06-21 21:39:19 +0000, Jan-Erik Sderholm said:
>
> My thought was to just queue the I/O, wait a sec or two using $WAIT and
> then check the IOSB. If not completed OK, CANCEL and return an error to
> the application...
>
> We'll see. Hopefully we can convince them to install wired connections
> instead of using Wifi...

Yeah. I tried that in the 1980s. Learned that ASTs and threads and
completion routines avoided a whole lot of the mess that the inevitable
errors within sync I/O and networking involves. You're headed for some
races here, too.

--
Pure Personal Opinion | HoffmanLabs LLC

On 6/21/2023 5:17 PM, Arne Vajhøj wrote:
> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>> When doing a *read* from a terminal device using QIOW, one
>> can use IO$M_TIMED and supply a timeout value in P3. That
>> works perfectly and we use that a lot.
>>
>> Now, we are having issues with an application when *writing*
>> to a terminal (TNA) device using QUIW that points to a small
>> label printer. If the printer is offline or not accessable on
>> the network, the application just hangs.
>>
>> As far as I can see, QIO/QIOW does not support a timeout value
>> when used for writing, is that correct?
>
> Yes.
>
> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>
> Table 5.6 lists IO$M_TIMED for IO$_READ* while table 5.8
> does not list it for IO$_WRITE*.
>
>> I was hoping that one could add a timeout value just as in the
>> read case, but it doesn't look so. So I do not see how to get
>> out of the hanging call to QIOW. Maybe using QIO, and doing
>> some extra coding to check the I/O, I guess.
>>
>> So, is there a way to get out of this state, still using QIOW?
>
> Totally untested idea:
>
> SYS$SETIMR with an AST routine that calls SYS$CANCEL
>
> Arne
>
>

Damn, Arne beat me to it. However while I use that for reads, I've never used
it for a write. Don't know what would happen. Best to test.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 6/21/2023 5:36 PM, Jan-Erik Söderholm wrote:
> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>> On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:
>>
>>> Now, here is a technical one...
>>>
>>> When doing a *read* from a terminal device using QIOW, one
>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>> works perfectly and we use that a lot...
>>
>> I've never had great success...
>
>
> I'm sorry about that. As I wrote, it works perfectly. In the
> case of reads, of course, where it is supported.
>
> My question was about writes, and it has been confirmed that
> timeout paramaters are not supported there. Thanks Arne.
>
> Now we need to weight the coding work against getting
> network cables installed to the printers. Wired printers
> will also "solve" the issue with the current code. We have
> 15-20 older similar Zebra label printers, all wired, and
> we do not see these error scenarios with those.
> All using the same C routine for the QIOW calls.
>
>
> Jan-Erik.

Well, if you have an AST routine such as:

1 !************************************************
! Timer AST Timeout Handler to Cancel I/O
!************************************************

SUB TCP_TIMER( LONG CH% , &
LONG Z2% , &
LONG Z3% , &
LONG Z4% , &
LONG Z5% )

CALL SYS$CANCEL( Loc(CH%) By Value )

SubEnd

And then in you program define the routine as external:

EXTERNAL LONG FUNCTION TCP_TIMER ! Timer AST routine

And then queue the timer routine:

!***************** Set timer AST *****************
Stat% = SYS$SETIMR( , WAIT.PRD , ! Delta time &
LOC(TCP_TIMER) By Value , &
CH% By Value , ) ! AST rtn and channel

Stat% = SYS$QIOW( , ! Event flag &
CH% By Value, ! VMS channel &
IO$_ACCESS By Value, ! Operation &
IOSB::Stat%, ! I/O status block &
, ! AST routine &
, ! AST parameter &
, ! P1 &
, ! P2 &
SERVER.ITEMLST::LEN%, ! P3 - remote socket n^
, ! P4 - &
, ! P5 &
) ! P6

If ( Stat% And SS$_NORMAL ) = 0%
Then Call VMSERR( Stat% , E$ )
E$ = "Unable to queue connect to host - " + E$
E% = -1%
SaveStat% = Stat%
GoTo Close_Socket
End If

If ( IOSB::Stat% And SS$_NORMAL ) = 0%
Then If IOSB::Stat% = SS$_ABORT &
OR IOSB::Stat% = SS$_CANCEL
Then E$ = "Timeout"
Else Call VMSERR( IOSB::Stat% , E$ )
End If
E$ = "Unable to connect to host - " + E$
E% = -1%
SaveStat% = IOSB::Stat%
GoTo Close_Socket
End If

Note, if the QIOW exits with the IOSB status of ABORT or CANCEL then you can
assume it was the cancel in the AST routine. However, I feel that some other
reason might set that status. Never bothered to look into it further.

My planning is that if this happens, then the QIOW failed, and it's time to move
on, regardless of why it failed.

Note, the wait period can be set up with:

WW% = W% ! Set delta time
Stat% = LIB$CVT_TO_INTERNAL_TIME( LIB$K_DELTA_SECONDS , WW% , WAIT.PRD )

Should be easy to figure out by reading the docs on the various system services
and LIB$ routines.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 6/21/2023 5:39 PM, Jan-Erik Söderholm wrote:
> Den 2023-06-21 kl. 23:17, skrev Arne Vajhøj:
>> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>>> I was hoping that one could add a timeout value just as in the
>>> read case, but it doesn't look so. So I do not see how to get
>>> out of the hanging call to QIOW. Maybe using QIO, and doing
>>> some extra coding to check the I/O, I guess.
>>>
>>> So, is there a way to get out of this state, still using QIOW?
>>
>> Totally untested idea:
>>
>> SYS$SETIMR with an AST routine that calls SYS$CANCEL
>
> My thought was to just queue the I/O, wait a sec or two
> using $WAIT and then check the IOSB. If not completed OK,
> CANCEL and return an error to the application...

That is always an option.

Just for fun I tried writing some code.

I tested with read, because it is easy to recreate timeout
for read.

First the standard IO$M_TIMED as baseline:

program r
implicit none
include '($ssdef)'
include '($iodef)'
integer*1 buf(1)
integer*2 chan, iosb(4)
integer*4 stat, tmo
integer*4 sys$assign, sys$qiow, sys$dassgn
external sys$assign, sys$qiow, sys$dassgn
stat = sys$assign('TT:', chan, , , )
if(stat.ne.SS$_NORMAL) call ooops(stat)
tmo = 10
write(*,*) 'Press a key within ', tmo, ' seconds'
stat = sys$qiow(, %val(chan), %val(IO$_READVBLK+IO$M_TIMED),
+ iosb, , ,
+ buf, %val(1), %val(tmo), , , )
if(stat.eq.SS$_NORMAL.and.iosb(1).eq.SS$_TIMEOUT) then
write(*,*) 'Arne you are too slow'
goto 100
end if
if(stat.ne.SS$_NORMAL) call ooops(stat)
if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
write(*,*) 'You entered code: ', buf
100 stat = sys$dassgn(%val(chan))
if(stat.ne.SS$_NORMAL) call ooops(stat)
end
c subroutine ooops(stat)
implicit none
integer*4 stat
write(*,*) 'status = ', stat
stop
end

Now an implementation of my idea:

program r1
implicit none
include '($ssdef)'
include '($iodef)'
integer*1 buf(1)
integer*2 chan, iosb(4)
integer*4 stat, tmo
integer*8 tmo2
integer*4 sys$assign, sys$qiow, sys$dassgn
external sys$assign, sys$qiow, sys$dassgn
external done
stat = sys$assign('TT:', chan, , , )
if(stat.ne.SS$_NORMAL) call ooops(stat)
tmo = 10
write(*,*) 'Press a key within ', tmo, ' seconds'
tmo2 = -tmo * 10000000
call sys$setimr(, tmo2, done, chan, )
stat = sys$qiow(, %val(chan), %val(IO$_READVBLK),
+ iosb, , ,
+ buf, %val(1), , , , )
if(stat.eq.SS$_NORMAL.and.iosb(1).eq.SS$_ABORT) then
write(*,*) 'Arne you are too slow'
goto 100
end if
if(stat.ne.SS$_NORMAL) call ooops(stat)
if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
call sys$cantim(0, )
write(*,*) 'You entered code: ', buf
100 stat = sys$dassgn(%val(chan))
if(stat.ne.SS$_NORMAL) call ooops(stat)
end
c subroutine ooops(stat)
implicit none
integer*4 stat
write(*,*) 'status = ', stat
stop
end
c subroutine done(chan)
implicit none
integer*2 chan
call sys$cancel(%val(chan))
return
end

And then how I interpret your suggestion:

program r2
implicit none
include '($ssdef)'
include '($iodef)'
integer*1 buf(1)
integer*2 chan, iosb(4)
integer*4 stat, tmo
integer*8 tmo2
integer*4 sys$assign, sys$qio, sys$dassgn
external sys$assign, sys$qio, sys$dassgn
external done
stat = sys$assign('TT:', chan, , , )
if(stat.ne.SS$_NORMAL) call ooops(stat)
tmo = 10
write(*,*) 'Press a key within ', tmo, ' seconds'
stat = sys$qio(, %val(chan), %val(IO$_READVBLK),
+ iosb, done, ,
+ buf, %val(1), , , , )
if(stat.ne.SS$_NORMAL) call ooops(stat)
tmo2 = -tmo * 10000000
call sys$schdwk(, , tmo2, )
call sys$hiber()
if(iosb(1).eq.0) then
write(*,*) 'Arne you are too slow'
goto 100
end if
if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
write(*,*) 'You entered code: ', buf
100 stat = sys$dassgn(%val(chan))
if(stat.ne.SS$_NORMAL) call ooops(stat)
end
c subroutine ooops(stat)
implicit none
integer*4 stat
write(*,*) 'status = ', stat
stop
end
c subroutine done
implicit none
call sys$wake(, )
return
end

And sorry for doing it in Fortran. But it would have taken me
way more time to do in Cobol. And translating from Fortran to
Cobol is probably easier than from C to Cobol. So Fortran
it is.

Arne

Den 2023-06-22 kl. 02:03, skrev Arne Vajhøj:
> On 6/21/2023 5:39 PM, Jan-Erik Söderholm wrote:
>> Den 2023-06-21 kl. 23:17, skrev Arne Vajhøj:
>>> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>>>> I was hoping that one could add a timeout value just as in the
>>>> read case, but it doesn't look so. So I do not see how to get
>>>> out of the hanging call to QIOW. Maybe using QIO, and doing
>>>> some extra coding to check the I/O, I guess.
>>>>
>>>> So, is there a way to get out of this state, still using QIOW?
>>>
>>> Totally untested idea:
>>>
>>> SYS$SETIMR with an AST routine that calls SYS$CANCEL
>>
>> My thought was to just queue the I/O, wait a sec or two
>> using $WAIT and then check the IOSB. If not completed OK,
>> CANCEL and return an error to the application...
>
> That is always an option.
>
> Just for fun I tried writing some code.
>
> I tested with read, because it is easy to recreate timeout
> for read.
>
> First the standard IO$M_TIMED as baseline:
>
>       program r
>       implicit none
>       include '($ssdef)'
>       include '($iodef)'
>       integer*1 buf(1)
>       integer*2 chan, iosb(4)
>       integer*4 stat, tmo
>       integer*4 sys$assign, sys$qiow, sys$dassgn
>       external sys$assign, sys$qiow, sys$dassgn
>       stat = sys$assign('TT:', chan, , , )
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       tmo = 10
>       write(*,*) 'Press a key within ', tmo, ' seconds'
>       stat = sys$qiow(, %val(chan), %val(IO$_READVBLK+IO$M_TIMED),
>      +                iosb, , ,
>      +                buf, %val(1), %val(tmo), , , )
>       if(stat.eq.SS$_NORMAL.and.iosb(1).eq.SS$_TIMEOUT) then
>         write(*,*) 'Arne you are too slow'
>         goto 100
>       end if
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
>       write(*,*) 'You entered code: ', buf
> 100   stat = sys$dassgn(%val(chan))
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       end
> c
>       subroutine ooops(stat)
>       implicit none
>       integer*4 stat
>       write(*,*) 'status = ', stat
>       stop
>       end
>
> Now an implementation of my idea:
>
>       program r1
>       implicit none
>       include '($ssdef)'
>       include '($iodef)'
>       integer*1 buf(1)
>       integer*2 chan, iosb(4)
>       integer*4 stat, tmo
>       integer*8 tmo2
>       integer*4 sys$assign, sys$qiow, sys$dassgn
>       external sys$assign, sys$qiow, sys$dassgn
>       external done
>       stat = sys$assign('TT:', chan, , , )
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       tmo = 10
>       write(*,*) 'Press a key within ', tmo, ' seconds'
>       tmo2 = -tmo * 10000000
>       call sys$setimr(, tmo2, done, chan, )
>       stat = sys$qiow(, %val(chan), %val(IO$_READVBLK),
>      +                iosb, , ,
>      +                buf, %val(1), , , , )
>       if(stat.eq.SS$_NORMAL.and.iosb(1).eq.SS$_ABORT) then
>         write(*,*) 'Arne you are too slow'
>         goto 100
>       end if
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
>       call sys$cantim(0, )
>       write(*,*) 'You entered code: ', buf
> 100   stat = sys$dassgn(%val(chan))
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       end
> c
>       subroutine ooops(stat)
>       implicit none
>       integer*4 stat
>       write(*,*) 'status = ', stat
>       stop
>       end
> c
>       subroutine done(chan)
>       implicit none
>       integer*2 chan
>       call sys$cancel(%val(chan))
>       return
>       end
>
> And then how I interpret your suggestion:
>
>       program r2
>       implicit none
>       include '($ssdef)'
>       include '($iodef)'
>       integer*1 buf(1)
>       integer*2 chan, iosb(4)
>       integer*4 stat, tmo
>       integer*8 tmo2
>       integer*4 sys$assign, sys$qio, sys$dassgn
>       external sys$assign, sys$qio, sys$dassgn
>       external done
>       stat = sys$assign('TT:', chan, , , )
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       tmo = 10
>       write(*,*) 'Press a key within ', tmo, ' seconds'
>       stat = sys$qio(, %val(chan), %val(IO$_READVBLK),
>      +               iosb, done, ,
>      +               buf, %val(1), , , , )
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       tmo2 = -tmo * 10000000
>       call sys$schdwk(, , tmo2, )
>       call sys$hiber()
>       if(iosb(1).eq.0) then
>         write(*,*) 'Arne you are too slow'
>         goto 100
>       end if
>       if(iosb(1).ne.SS$_NORMAL) call ooops(iosb(1))
>       write(*,*) 'You entered code: ', buf
> 100   stat = sys$dassgn(%val(chan))
>       if(stat.ne.SS$_NORMAL) call ooops(stat)
>       end
> c
>       subroutine ooops(stat)
>       implicit none
>       integer*4 stat
>       write(*,*) 'status = ', stat
>       stop
>       end
> c
>       subroutine done
>       implicit none
>       call sys$wake(, )
>       return
>       end
>
> And sorry for doing it in Fortran. But it would have taken me
> way more time to do in Cobol. And translating from Fortran to
> Cobol is probably easier than from C to Cobol. So Fortran
> it is.
>
> Arne
>
>
>

Will check, but yes, it sounds as we are on the same track.
And our I/O routines are in C and called from Cobol. But yes,
as far as I know, one could also write it in pure Cobol. :-)

The benefit with your timer/ast based solution is of course that,
when everything works fine (as it does in most cases), there is
no added delay in the routine. AS I thought, there would always
be the same delay no matter if it works or not.

Most doc examples are in C, so that is probably why the I/O
routine was written in C (in 1993 in this case).

We'll have a discussion. Now, even with wired connections, there
can be cases with powered off printers and such, so a better
error handling could be good apart from the Wifi issues.

Jan-Erik.

Den 2023-06-22 kl. 01:16, skrev Dave Froble:
> On 6/21/2023 5:17 PM, Arne Vajhøj wrote:
>> On 6/21/2023 4:45 PM, Jan-Erik Söderholm wrote:
>>> When doing a *read* from a terminal device using QIOW, one
>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>> works perfectly and we use that a lot.
>>>
>>> Now, we are having issues with an application when *writing*
>>> to a terminal (TNA) device using QUIW that points to a small
>>> label printer. If the printer is offline or not accessable on
>>> the network, the application just hangs.
>>>
>>> As far as I can see, QIO/QIOW does not support a timeout value
>>> when used for writing, is that correct?
>>
>> Yes.
>>
>> https://vmssoftware.com/docs/VSI_IO_REF.pdf
>>
>> Table 5.6 lists IO$M_TIMED for IO$_READ* while table 5.8
>> does not list it for IO$_WRITE*.
>>
>>> I was hoping that one could add a timeout value just as in the
>>> read case, but it doesn't look so. So I do not see how to get
>>> out of the hanging call to QIOW. Maybe using QIO, and doing
>>> some extra coding to check the I/O, I guess.
>>>
>>> So, is there a way to get out of this state, still using QIOW?
>>
>> Totally untested idea:
>>
>> SYS$SETIMR with an AST routine that calls SYS$CANCEL
>>
>> Arne
>>
>>
>
> Damn, Arne beat me to it.  However while I use that for reads, I've never
> used it for a write.  Don't know what would happen.  Best to test.
>

But for reads, it is easier to just add the timeout to the QIOW
call directly. No added code.

And thanks for you input!

Jan-Erik.

Den 2023-06-22 kl. 00:19, skrev Stephen Hoffman:
> On 2023-06-21 21:39:19 +0000, Jan-Erik Sderholm said:
>>
>> My thought was to just queue the I/O, wait a sec or two using $WAIT and
>> then check the IOSB. If not completed OK, CANCEL and return an error to
>> the application...
>>
>> We'll see. Hopefully we can convince them to install wired connections
>> instead of using Wifi...
>
> Yeah. I tried that in the 1980s. Learned that ASTs and threads and
> completion routines avoided a whole lot of the mess that the inevitable
> errors within sync I/O and networking involves. You're headed for some
> races here, too.
>
>

Yes, there are some "unknowns" in this. :-)
Equipment gets restarted or powered off. Network is "flaky".

Most of the reconnect issues are handled by the telnet driver
by creating TNA devices that are used for the communication.

The connections are reconnected after a equipment restart or
network autage automatically with no application involvment.

And the programming is easier by just pretending that all network
equipment are "terminals" having a TNA device.

Thanks for your input!

Jan-Erik.

On Thursday, June 22, 2023 at 2:54:18 AM UTC-4, Jan-Erik Söderholm wrote:
> Den 2023-06-22 kl. 00:19, skrev Stephen Hoffman:
> > On 2023-06-21 21:39:19 +0000, Jan-Erik S derholm said:
> >>
> >> My thought was to just queue the I/O, wait a sec or two using $WAIT and
> >> then check the IOSB. If not completed OK, CANCEL and return an error to
> >> the application...
> >>
> >> We'll see. Hopefully we can convince them to install wired connections
> >> instead of using Wifi...
> >
> > Yeah. I tried that in the 1980s. Learned that ASTs and threads and
> > completion routines avoided a whole lot of the mess that the inevitable
> > errors within sync I/O and networking involves. You're headed for some
> > races here, too.
> >
> >
> Yes, there are some "unknowns" in this. :-)
> Equipment gets restarted or powered off. Network is "flaky".
>
> Most of the reconnect issues are handled by the telnet driver
> by creating TNA devices that are used for the communication.
>
> The connections are reconnected after a equipment restart or
> network autage automatically with no application involvment.
>
> And the programming is easier by just pretending that all network
> equipment are "terminals" having a TNA device.
>
> Thanks for your input!
>
> Jan-Erik.
Jan-Erik,

Definition of "network": Connections are subject to random/non-random interference.

Otherwise, I concur with Hoff. Use a Timer AST and cancel; with the "cancel pending" bit to avoid race conditions. The IO completion will occur, with the appropriate IO completion code in the IOSB.

- Bob Gezelter, http://www.rlgsc.com

On 2023-06-21 23:36, Jan-Erik Söderholm wrote:
> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>> On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:
>>
>>> Now, here is a technical one...
>>>
>>> When doing a *read* from a terminal device using QIOW, one
>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>> works perfectly and we use that a lot...
>>
>> I've never had great success...
>
>
> I'm sorry about that. As I wrote, it works perfectly. In the
> case of reads, of course, where it is supported.
>
> My question was about writes, and it has been confirmed that
> timeout paramaters are not supported there. Thanks Arne.
>
> Now we need to weight the coding work against getting
> network cables installed to the printers. Wired printers
> will also "solve" the issue with the current code. We have
> 15-20 older similar Zebra label printers, all wired, and
> we do not see these error scenarios with those.
> All using the same C routine for the QIOW calls.

I would think/hope the following works in VMS. It's a fairly common
trick in RSX anyway.

Issue the QIOW, as usual. But before, issue a mark time for the timeout
you want. For both of these, use the same event flag. The QIOW will wake
up either because the QIO completed, or the mark time expired. Check the
IOSB to see if the QIO completed.
Cancel the mark time anyway, so you don't have one lingering around in
case you want to do the same again. And if the QIO hadn't completed,
cancel it.

Johnny

On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
> > On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
> >
> >> Now, here is a technical one...
> >>
> >> When doing a *read* from a terminal device using QIOW, one
> >> can use IO$M_TIMED and supply a timeout value in P3. That
> >> works perfectly and we use that a lot...
> >
> > I've never had great success...
>
>
> I'm sorry about that. As I wrote, it works perfectly. In the
> case of reads, of course, where it is supported.
>
> My question was about writes, and it has been confirmed that
> timeout paramaters are not supported there. Thanks Arne.
>
> Now we need to weight the coding work against getting
> network cables installed to the printers. Wired printers
> will also "solve" the issue with the current code. We have
> 15-20 older similar Zebra label printers, all wired, and
> we do not see these error scenarios with those.
> All using the same C routine for the QIOW calls.
>
>
> Jan-Erik.
While you cannot request a timeout on a WRITEVBLK
you may be able to workaround this by using READPROMPT
With this you get two i/o's in one call,
the first is a write of your "prompt" followed by a read on the same channel.
If you set up your "prompt" as the content of your label then do the qio call
it should write this to the device, then do the read, which you can check or ignore.
If you get a tt_timeout, then wait a bit and retry.
The most concise explanation of this is in wikipedia on the qio page.
The I/O user manual just goes on and on
You may have to increase the size of the typeahead buffer to cater for the size of your label
as well as managing all the usual qio stuff like buffer lengths, IOSBs, terminator masks, ASTs, etc.

If I was retiring in a couple of weeks I would recommend cabling up all the printers,
but it could be an interesting way of getting your successor to hate you?

Phil

Den 2023-06-22 kl. 13:25, skrev Phil Howell:
> On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
>>>
>>>> Now, here is a technical one...
>>>>
>>>> When doing a *read* from a terminal device using QIOW, one
>>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>>> works perfectly and we use that a lot...
>>>
>>> I've never had great success...
>>
>>
>> I'm sorry about that. As I wrote, it works perfectly. In the
>> case of reads, of course, where it is supported.
>>
>> My question was about writes, and it has been confirmed that
>> timeout paramaters are not supported there. Thanks Arne.
>>
>> Now we need to weight the coding work against getting
>> network cables installed to the printers. Wired printers
>> will also "solve" the issue with the current code. We have
>> 15-20 older similar Zebra label printers, all wired, and
>> we do not see these error scenarios with those.
>> All using the same C routine for the QIOW calls.
>>
>>
>> Jan-Erik.
> While you cannot request a timeout on a WRITEVBLK
> you may be able to workaround this by using READPROMPT
> With this you get two i/o's in one call,
> the first is a write of your "prompt" followed by a read on the same channel.
> If you set up your "prompt" as the content of your label then do the qio call
> it should write this to the device, then do the read, which you can check or ignore.
> If you get a tt_timeout, then wait a bit and retry.
> The most concise explanation of this is in wikipedia on the qio page.
> The I/O user manual just goes on and on
> You may have to increase the size of the typeahead buffer to cater for the size of your label
> as well as managing all the usual qio stuff like buffer lengths, IOSBs, terminator masks, ASTs, etc.
>
> If I was retiring in a couple of weeks I would recommend cabling up all the printers,
> but it could be an interesting way of getting your successor to hate you?
>
> Phil
>
>

Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
I'm actually leaving this place Friday next week, 30 June.

Right now, it seems as we'll simply get the printers hard-wired.
It is 6 printers that are on Wifi now, and our other 15-20 label
printers (all hard-wired) do not show the same error scenario.

Jan-Erik.

On 2023-06-22 14:05, Jan-Erik Söderholm wrote:
> Den 2023-06-22 kl. 13:25, skrev Phil Howell:
>> On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
>>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
>>>>
>>>>> Now, here is a technical one...
>>>>>
>>>>> When doing a *read* from a terminal device using QIOW, one
>>>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>>>> works perfectly and we use that a lot...
>>>>
>>>> I've never had great success...
>>>
>>>
>>> I'm sorry about that. As I wrote, it works perfectly. In the
>>> case of reads, of course, where it is supported.
>>>
>>> My question was about writes, and it has been confirmed that
>>> timeout paramaters are not supported there. Thanks Arne.
>>>
>>> Now we need to weight the coding work against getting
>>> network cables installed to the printers. Wired printers
>>> will also "solve" the issue with the current code. We have
>>> 15-20 older similar Zebra label printers, all wired, and
>>> we do not see these error scenarios with those.
>>> All using the same C routine for the QIOW calls.
>>>
>>>
>>> Jan-Erik.
>> While you cannot request a timeout on a WRITEVBLK
>> you may be able to workaround this by using READPROMPT
>> With this you get two i/o's in one call,
>> the first is a write of your "prompt" followed by a read on the same
>> channel.
>> If you set up your "prompt" as the content of your label then do the
>> qio call
>> it should write this to the device, then do the read, which you can
>> check or ignore.
>> If you get a tt_timeout, then wait a bit and retry.
>> The most concise explanation of this is in wikipedia on the qio page.
>> The I/O user manual just goes on and on
>> You may have to increase the size of the typeahead buffer to cater for
>> the size of your label
>> as well as managing all the usual qio stuff like buffer lengths,
>> IOSBs, terminator masks, ASTs, etc.
>>
>> If I was retiring in a couple of weeks I would recommend cabling up
>> all the printers,
>> but it could be an interesting way of getting your successor to hate you?
>>
>> Phil
>>
>
> Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
> I'm actually leaving this place Friday next week, 30 June.
>
> Right now, it seems as we'll simply get the printers hard-wired.
> It is 6 printers that are on Wifi now, and our other 15-20 label
> printers (all hard-wired) do not show the same error scenario.

Unless you are expecting some input, won't this mean you *always* get a
timeout. So even something that prints, and completes in no time, will
only return when the timeout happens.

Seems the wrong way to go about it. Not to mention you better be sure
the read timeout applies even if the write part haven't completed.

(I much prefer using the same EF for both mark time and read. :) )

Johnny

On 2023-06-21, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> Now, we are having issues with an application when *writing*
> to a terminal (TNA) device using QUIW that points to a small
> label printer. If the printer is offline or not accessable on
> the network, the application just hangs.
>

[snip]

>
> These are new printers where they decided to use Wifi
> instead of wired connection. We do not see these issues
> on our older label printers which are all hard wired...
>
> I will of course again suggest that they do take the cost to
> ask for wired network connections instead of using Wifi...
>
> I also fixed a COM file that pings these 7 printers once each
> 10 seconds, and it clearly shows that the connections comes
> and goes more or less all the time. And when that happens to
> be the same time as they try to print a label, it just hangs...
>

Others have given you some excellent workarounds, but I am more
interested in _why_ you have the problem in the first place.

First off, it's not fully clear, but are these label printers
directly on the network, with their own IP address, instead of
via a terminal server ? I am assuming they are directly on the
network for the rest of this post.

It sounds like you have a permanent TCP/IP connection to the
printers via reverse telnet. In that case, do you have keepalive
packets from VMS enabled on the connection ?

If you do, but the keepalive interval is 75 seconds or greater,
try reducing it to 30 seconds in case the printers are going into
some wireless low-power mode after a short period of time of network
inactivity.

(30 seconds is what I tell ssh to use for keepalive packets when
I use WAN connections, and it seems like a reasonable value to me.)

If that works, look to see if the printers have some low-power settings
that can be adjusted or disabled.

The keepalives should end up with the telnet connection being dropped
by VMS on failure, so that you can reconnect.

Is there anyway you can do the telnet connection on demand and then
tear it down again immediately afterwards, instead of keeping it open
all the time, even when you are not printing labels ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2023-06-22 kl. 14:18, skrev Johnny Billquist:
> On 2023-06-22 14:05, Jan-Erik Söderholm wrote:
>> Den 2023-06-22 kl. 13:25, skrev Phil Howell:
>>> On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
>>>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>>>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
>>>>>
>>>>>> Now, here is a technical one...
>>>>>>
>>>>>> When doing a *read* from a terminal device using QIOW, one
>>>>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>>>>> works perfectly and we use that a lot...
>>>>>
>>>>> I've never had great success...
>>>>
>>>>
>>>> I'm sorry about that. As I wrote, it works perfectly. In the
>>>> case of reads, of course, where it is supported.
>>>>
>>>> My question was about writes, and it has been confirmed that
>>>> timeout paramaters are not supported there. Thanks Arne.
>>>>
>>>> Now we need to weight the coding work against getting
>>>> network cables installed to the printers. Wired printers
>>>> will also "solve" the issue with the current code. We have
>>>> 15-20 older similar Zebra label printers, all wired, and
>>>> we do not see these error scenarios with those.
>>>> All using the same C routine for the QIOW calls.
>>>>
>>>>
>>>> Jan-Erik.
>>> While you cannot request a timeout on a WRITEVBLK
>>> you may be able to workaround this by using READPROMPT
>>> With this you get two i/o's in one call,
>>> the first is a write of your "prompt" followed by a read on the same
>>> channel.
>>> If you set up your "prompt" as the content of your label then do the qio
>>> call
>>> it should write this to the device, then do the read, which you can
>>> check or ignore.
>>> If you get a tt_timeout, then wait a bit and retry.
>>> The most concise explanation of this is in wikipedia on the qio page.
>>> The I/O user manual just goes on and on
>>> You may have to increase the size of the typeahead buffer to cater for
>>> the size of your label
>>> as well as managing all the usual qio stuff like buffer lengths, IOSBs,
>>> terminator masks, ASTs, etc.
>>>
>>> If I was retiring in a couple of weeks I would recommend cabling up all
>>> the printers,
>>> but it could be an interesting way of getting your successor to hate you?
>>>
>>> Phil
>>>
>>
>> Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
>> I'm actually leaving this place Friday next week, 30 June.
>>
>> Right now, it seems as we'll simply get the printers hard-wired.
>> It is 6 printers that are on Wifi now, and our other 15-20 label
>> printers (all hard-wired) do not show the same error scenario.
>
> Unless you are expecting some input, won't this mean you *always* get a
> timeout. So even something that prints, and completes in no time, will only
> return when the timeout happens.
>
> Seems the wrong way to go about it. Not to mention you better be sure the
> read timeout applies even if the write part haven't completed.
>
> (I much prefer using the same EF for both mark time and read. :) )
>
>   Johnny
>

Yes, right. That is a problem.
On the other hard wired printers we simply do a WRITEVBLK.
We have very few issues, since the network is always "up".

Den 2023-06-22 kl. 14:24, skrev Simon Clubley:
> On 2023-06-21, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> Now, we are having issues with an application when *writing*
>> to a terminal (TNA) device using QUIW that points to a small
>> label printer. If the printer is offline or not accessable on
>> the network, the application just hangs.
>>
>
> [snip]
>
>>
>> These are new printers where they decided to use Wifi
>> instead of wired connection. We do not see these issues
>> on our older label printers which are all hard wired...
>>
>> I will of course again suggest that they do take the cost to
>> ask for wired network connections instead of using Wifi...
>>
>> I also fixed a COM file that pings these 7 printers once each
>> 10 seconds, and it clearly shows that the connections comes
>> and goes more or less all the time. And when that happens to
>> be the same time as they try to print a label, it just hangs...
>>
>
> Others have given you some excellent workarounds, but I am more
> interested in _why_ you have the problem in the first place.
>
> First off, it's not fully clear, but are these label printers
> directly on the network, with their own IP address, instead of
> via a terminal server ? I am assuming they are directly on the
> network for the rest of this post.

Sure, there own IP addresses (on one of the Wifi subnets).

>
> It sounds like you have a permanent TCP/IP connection to the
> printers via reverse telnet. In that case, do you have keepalive
> packets from VMS enabled on the connection ?

We use the "reconnect" options when creating the TNA device. So that
(at least normally) any activity from VMS will init an automatic
re-connect, should the link have been disconnected.
But that of course depends on that the other end is available
at that point in time.

>
> If you do, but the keepalive interval is 75 seconds or greater,
> try reducing it to 30 seconds in case the printers are going into
> some wireless low-power mode after a short period of time of network
> inactivity.

I do not think it is that kind of issues. We have a ping routine
that is pinging these addresses in a loop each 10 seconds.
And that shows that they sometimes gets anavailable. No specific
pattern, just that it happens all over the day.

>
> (30 seconds is what I tell ssh to use for keepalive packets when
> I use WAN connections, and it seems like a reasonable value to me.)
>
> If that works, look to see if the printers have some low-power settings
> that can be adjusted or disabled.
>
> The keepalives should end up with the telnet connection being dropped
> by VMS on failure, so that you can reconnect.
>
> Is there anyway you can do the telnet connection on demand and then
> tear it down again immediately afterwards, instead of keeping it open
> all the time, even when you are not printing labels ?

The TCP connection as such is opened when VMS has anything to send and
disconnected aftarwards. So each label printout involves a full
connect/print/disconnect on the TCP level (as can be seen in OPERATOR.LOG).

The issue seems to be if one of the (short) Wifi outages happens to
be at the same time as VMS tries to print a label. Then it looks up.

Anyway, it seems as hard wiring these printers seems to be the
route forward right now.

Thanks for you points!

And as I said before, after Friday next week, this is not my problem
anymore... :-) And again, VMS was never replaced with anything, that
is not why I'm leaving. My contract was simply not renewed.

Jan-Erik.

>
> Simon.
>

On Thursday, 22 June 2023 at 10:06:02 pm UTC+10, Jan-Erik Söderholm wrote:
> Den 2023-06-22 kl. 13:25, skrev Phil Howell:
> > On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
> >> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
> >>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
> >>>
> >>>> Now, here is a technical one...
> >>>>
> >>>> When doing a *read* from a terminal device using QIOW, one
> >>>> can use IO$M_TIMED and supply a timeout value in P3. That
> >>>> works perfectly and we use that a lot...
> >>>
> >>> I've never had great success...
> >>
> >>
> >> I'm sorry about that. As I wrote, it works perfectly. In the
> >> case of reads, of course, where it is supported.
> >>
> >> My question was about writes, and it has been confirmed that
> >> timeout paramaters are not supported there. Thanks Arne.
> >>
> >> Now we need to weight the coding work against getting
> >> network cables installed to the printers. Wired printers
> >> will also "solve" the issue with the current code. We have
> >> 15-20 older similar Zebra label printers, all wired, and
> >> we do not see these error scenarios with those.
> >> All using the same C routine for the QIOW calls.
> >>
> >>
> >> Jan-Erik.
> > While you cannot request a timeout on a WRITEVBLK
> > you may be able to workaround this by using READPROMPT
> > With this you get two i/o's in one call,
> > the first is a write of your "prompt" followed by a read on the same channel.
> > If you set up your "prompt" as the content of your label then do the qio call
> > it should write this to the device, then do the read, which you can check or ignore.
> > If you get a tt_timeout, then wait a bit and retry.
> > The most concise explanation of this is in wikipedia on the qio page.
> > The I/O user manual just goes on and on
> > You may have to increase the size of the typeahead buffer to cater for the size of your label
> > as well as managing all the usual qio stuff like buffer lengths, IOSBs, terminator masks, ASTs, etc.
> >
> > If I was retiring in a couple of weeks I would recommend cabling up all the printers,
> > but it could be an interesting way of getting your successor to hate you?
> >
> > Phil
> >
> >
> Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
> I'm actually leaving this place Friday next week, 30 June.
>
> Right now, it seems as we'll simply get the printers hard-wired.
> It is 6 printers that are on Wifi now, and our other 15-20 label
> printers (all hard-wired) do not show the same error scenario.
>
> Jan-Erik.
That does seem the more expedient solution.
Of the regular posters here, you must be one of the few that has
a real live job running VMS, so I'm sorry to see another one go,
soon it will only be retirees, hobbyists, consultants and contractors here.
Funnily enough I have a long history with label printers,
firstly on VAX with LA75 used with VT. terminals as "slave" printers,
then high speed Zebra printers for long print runs.
On Alpha we used various brands with varying success but eventually
standardised on "Blaster Advantage" RJ45 networked printers.
These were expensive, but pretty rugged and reliable
These printers also were able to interpret the Zebra language (ZPL)
so our label print files were about 8 lines of ascii test sent via telnet.
Barcodes and QR codes were able to be added easily as the printer did all the work!
Phil

Den 2023-06-22 kl. 14:54, skrev Phil Howell:
> On Thursday, 22 June 2023 at 10:06:02 pm UTC+10, Jan-Erik Söderholm wrote:
>> Den 2023-06-22 kl. 13:25, skrev Phil Howell:
>>> On Thursday, 22 June 2023 at 7:36:54 am UTC+10, Jan-Erik Söderholm wrote:
>>>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>>>> On 2023-06-21 20:45:12 +0000, Jan-Erik S derholm said:
>>>>>
>>>>>> Now, here is a technical one...
>>>>>>
>>>>>> When doing a *read* from a terminal device using QIOW, one
>>>>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>>>>> works perfectly and we use that a lot...
>>>>>
>>>>> I've never had great success...
>>>>
>>>>
>>>> I'm sorry about that. As I wrote, it works perfectly. In the
>>>> case of reads, of course, where it is supported.
>>>>
>>>> My question was about writes, and it has been confirmed that
>>>> timeout paramaters are not supported there. Thanks Arne.
>>>>
>>>> Now we need to weight the coding work against getting
>>>> network cables installed to the printers. Wired printers
>>>> will also "solve" the issue with the current code. We have
>>>> 15-20 older similar Zebra label printers, all wired, and
>>>> we do not see these error scenarios with those.
>>>> All using the same C routine for the QIOW calls.
>>>>
>>>>
>>>> Jan-Erik.
>>> While you cannot request a timeout on a WRITEVBLK
>>> you may be able to workaround this by using READPROMPT
>>> With this you get two i/o's in one call,
>>> the first is a write of your "prompt" followed by a read on the same channel.
>>> If you set up your "prompt" as the content of your label then do the qio call
>>> it should write this to the device, then do the read, which you can check or ignore.
>>> If you get a tt_timeout, then wait a bit and retry.
>>> The most concise explanation of this is in wikipedia on the qio page.
>>> The I/O user manual just goes on and on
>>> You may have to increase the size of the typeahead buffer to cater for the size of your label
>>> as well as managing all the usual qio stuff like buffer lengths, IOSBs, terminator masks, ASTs, etc.
>>>
>>> If I was retiring in a couple of weeks I would recommend cabling up all the printers,
>>> but it could be an interesting way of getting your successor to hate you?
>>>
>>> Phil
>>>
>>>
>> Hi. That was a nice way of "using" (or "mis-using" ? ) QIOW!
>> I'm actually leaving this place Friday next week, 30 June.
>>
>> Right now, it seems as we'll simply get the printers hard-wired.
>> It is 6 printers that are on Wifi now, and our other 15-20 label
>> printers (all hard-wired) do not show the same error scenario.
>>
>> Jan-Erik.
> That does seem the more expedient solution.
> Of the regular posters here, you must be one of the few that has
> a real live job running VMS, so I'm sorry to see another one go,
> soon it will only be retirees, hobbyists, consultants and contractors here.
> Funnily enough I have a long history with label printers,
> firstly on VAX with LA75 used with VT. terminals as "slave" printers,
> then high speed Zebra printers for long print runs.
> On Alpha we used various brands with varying success but eventually
> standardised on "Blaster Advantage" RJ45 networked printers.
> These were expensive, but pretty rugged and reliable
> These printers also were able to interpret the Zebra language (ZPL)
> so our label print files were about 8 lines of ascii test sent via telnet.
> Barcodes and QR codes were able to be added easily as the printer did all the work!
> Phil
>

I have used (written ZPL code to) Zebra printers since early 90s.
Quite nice printers. I have been in the manufacturing business,
first 20 years at an Ericsson factory as employed and the last
17 years as a contractor at another factory.

Always with production support incl. label printers, barcode
scanners, traceability, reporting from lines and so on.

When I started at this site in 2006, the VMS system was going
to be replaced “in 3-4 years”. That have stayed like that all up
to today when it now is “in 4-5 years”.

If we in 2006 had known that we would still be running the same
system, we might have taken some other decisions over the years, and
not still run the same (physically) servers that I installed in 2006.

They now have said that the VMS systems can be left to the Indian
company that they have an agreement with.
I’d say that “the jury is still out” on that one… 😊

I will not close my company yet, I’ll keep it “live” if something pops up.
First there is a summer vacation and after that we’ll see…

Jan-Erik.

On 2023-06-22, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> They now have said that the VMS systems can be left to the Indian
> company that they have an agreement with.
> I?d say that ?the jury is still out? on that one? ?
>

Hmmm. I would suggest you find some way to permanently document the
system and network configuration at the time you left, so that if they
screw it up, they can't try blaming it on you.

> I will not close my company yet, I?ll keep it ?live? if something pops up.
> First there is a summer vacation and after that we?ll see?
>

Whatever you do next, make sure you enjoy yourself. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 6/21/2023 7:38 PM, Dave Froble wrote:
> On 6/21/2023 5:36 PM, Jan-Erik Söderholm wrote:
>> Den 2023-06-21 kl. 23:25, skrev Stephen Hoffman:
>>> On 2023-06-21 20:45:12 +0000, Jan-Erik Sderholm said:
>>>
>>>> Now, here is a technical one...
>>>>
>>>> When doing a *read* from a terminal device using QIOW, one
>>>> can use IO$M_TIMED and supply a timeout value in P3. That
>>>> works perfectly and we use that a lot...
>>>
>>> I've never had great success...
>>
>>
>> I'm sorry about that. As I wrote, it works perfectly. In the
>> case of reads, of course, where it is supported.
>>
>> My question was about writes, and it has been confirmed that
>> timeout paramaters are not supported there. Thanks Arne.
>>
>> Now we need to weight the coding work against getting
>> network cables installed to the printers. Wired printers
>> will also "solve" the issue with the current code. We have
>> 15-20 older similar Zebra label printers, all wired, and
>> we do not see these error scenarios with those.
>> All using the same C routine for the QIOW calls.
>>
>>
>> Jan-Erik.
>
>
> Well, if you have an AST routine such as:
>
> 1 !************************************************
> ! Timer AST Timeout Handler to Cancel I/O
> !************************************************
>
> SUB TCP_TIMER( LONG CH% , &
> LONG Z2% , &
> LONG Z3% , &
> LONG Z4% , &
> LONG Z5% )
>
> CALL SYS$CANCEL( Loc(CH%) By Value )
>
> SubEnd
>
> And then in you program define the routine as external:
>
> EXTERNAL LONG FUNCTION TCP_TIMER ! Timer AST routine
>
> And then queue the timer routine:
>
> !***************** Set timer AST *****************
> Stat% = SYS$SETIMR( , WAIT.PRD , ! Delta time &
> LOC(TCP_TIMER) By Value , &
> CH% By Value , ) ! AST rtn and channel

This code has been working well for years, and I hadn't looked at it until
recently. I find the lack of testing the completion status of the system
service to be sloppy. One might ask, "what can go wrong?", and probably will
not, but it is possible, I think. So, a better practice would be to at least
test Stat% AND SS$_NORMAL. Just saying ...

> Stat% = SYS$QIOW( , ! Event flag &
> CH% By Value, ! VMS channel &
> IO$_ACCESS By Value, ! Operation &
> IOSB::Stat%, ! I/O status block &
> , ! AST routine &
> , ! AST parameter &
> , ! P1 &
> , ! P2 &
> SERVER.ITEMLST::LEN%, ! P3 - remote socket n^
> , ! P4 - &
> , ! P5 &
> ) ! P6
>
> If ( Stat% And SS$_NORMAL ) = 0%
> Then Call VMSERR( Stat% , E$ )
> E$ = "Unable to queue connect to host - " + E$
> E% = -1%
> SaveStat% = Stat%
> GoTo Close_Socket
> End If
>
> If ( IOSB::Stat% And SS$_NORMAL ) = 0%
> Then If IOSB::Stat% = SS$_ABORT &
> OR IOSB::Stat% = SS$_CANCEL
> Then E$ = "Timeout"
> Else Call VMSERR( IOSB::Stat% , E$ )
> End If
> E$ = "Unable to connect to host - " + E$
> E% = -1%
> SaveStat% = IOSB::Stat%
> GoTo Close_Socket
> End If
>
> Note, if the QIOW exits with the IOSB status of ABORT or CANCEL then you can
> assume it was the cancel in the AST routine. However, I feel that some other
> reason might set that status. Never bothered to look into it further.
>
> My planning is that if this happens, then the QIOW failed, and it's time to move
> on, regardless of why it failed.
>
> Note, the wait period can be set up with:
>
> WW% = W% ! Set delta time
> Stat% = LIB$CVT_TO_INTERNAL_TIME( LIB$K_DELTA_SECONDS , WW% , WAIT.PRD )
>
> Should be easy to figure out by reading the docs on the various system services
> and LIB$ routines.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 6/22/2023 9:09 AM, Jan-Erik Söderholm wrote:
> They now have said that the VMS systems can be left to the Indian
> company that they have an agreement with.
> I’d say that “the jury is still out” on that one… 😊

I predict problems.

Based on what you have posted over the years then they will
need people with skills in: VMS system management,
Cobol, Rdb, VMS programming (system services), Python,
WASD, message queues.

That means either a rare skill combo or a mid size team.

Arne