Re: SFF problem with VSI on Integrity?

On 8/7/24 11:21 AM, Richard Jordan wrote:

On 8/7/24 6:59 AM, Craig A. Berry wrote:

Do you get anything interesting from:
>
$ MCR TCPIP$SYSTEM:TCPIP$SMTP_SFF.EXE sys$input: -log sys$error: -loglevel 1
...
^Z
>
?

 Yes and no.  Thanks for reminding that many of these utilities have those options!  I had forgotten; I rarely get to be in VMS anymore.
 I ran it with one of the temp files sendmail.com created, and with the -log and -loglevel options, as well as with SYS$INPUT.
 The one run with the sendmail temp file for input placed the %LIB-F-INVNBDS error as the first line in the error log, then a blank line, then SMTP configuration data, then the expected text from the input file appropriately escaped (munged).
 The run with SYS$INPUT did the same.  If I just hit return, SFF exits with an error and the error log shows the %LIB-F-INVNBDS error at the top.  If I enter a valid SMTP command (MAIL FROM:) then ctrl-z errorlog shows the same; the LIB error, followed by a blank line, the contents of the SMTP config file, my one line and an end of input file notice.  And same if I hit ctrl-z immediately after running SFF, I get the LIB error, a blank line, then the SMTP config dump.
 So the error is occurring 'early' and the cause is not logged.  Feels like a bug in the program.  Despite the fact that its listed as a 'fatal' error, the exit status from SFF on all of these tests was the same:
%0x00000001

I can't reproduce the INVNBDS error with TCP/IP Services 5.7 ECO 5 on
8.4-2L3 or 6.0 on 9.2-2.  So I don't think it is a simple HPE/VSI
difference that you're seeing.  I wouldn't rule out the possibility you
have bad data somewhere.  Based on SET WATCH FILE, the following data
files are accessed early by SFF, so something could be off in one of those:
TCPIP$SERVICE.DAT
TCPIP$HOST.DAT
VMSMAIL_PROFILE.DATA
and your timezone file.  I would check VMSMAIL_PROFILE.DATA first.  What
to check for?  Dunno, really.  Maybe a multibyte character in a personal
name or columns that don't line up because somebody edited the file or
something.  I don't think that the columns are documented anywhere, so a
robust validator for that file might be hard to come by.