>   +826  + eval 'env $i  zin.gz < $tmp_in > $tmp_out'
>   +827  ++ env zless zin.gz
>   +828  /data/prj/gnu/gzip/gzip-1.9/tests/../zless[71]: less:  not found
>   +829  + echo FAIL: zless
>   +830  FAIL: zless
>   +831  + fail=1

Thanks for reporting that. As 'less' is not required by POSIX we 
shouldn't assume it's installed. I installed the first attached patch to 
fix that (by not installing zless when 'less' is absent), and the second 
attached patch to fix a bug I found in the test cases for 'zmore' when I 
ran it with PAGER='less'.


q>   +891  FAIL: timestamp
>   +892  ===============
> This is to be expected - I expect - with 32-bit timestamp (OBJECT_MODE=32)

Yes, we don't worry about people perversely building a 32-bit time_t 
gzip on platforms that support 64-bit timestamps.

Recent versions of GNU/Linux have added support for 64-bit time_t even 
to platforms where 'long' and pointers are 32 bits.[1] Do recent 
versions of AIX have something similar? If so, we should teach Gnulib's 
year2038 module[2] how to enable that. This would fix this AIX problem 
for several GNU programs, not just gzip.

[1]: 
https://www.gnu.org/software/libc/manual/html_node/64_002dbit-time-symbol-handling.html
[2]: 
https://www.gnu.org/software/gnulib/manual/html_node/Avoiding-the-year-2038-problem.html