[Info-vax] SFF problem with VSI on Integrity?

[Richard Jordan]

On 8/7/24 2:31 PM, Craig A. Berry wrote:
> 
> 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.

Thanks for following up; I didn't have time at work to do that but we 
have determined its not an SFF issue after all.  It might be related to 
the VSI upgrade (from HP) done last year.  I reviewed a system startup 
log from last year then the most recent one, and when the TCPIP START 
MAIL command is executed, the same error showed up in the log, followed 
by normal continuation messages.

I then stopped SMTP and got the same error (that was not verified so not 
sure which command tripped it), then ran the SMTP startup again with 
verification on and it produced the error in the same place.

So its definitely an issue in the configuration, either a DAT file or 
the SMTP config file.  Since the error did not cause any performance 
issues we didn't realize it was in the log or happening.  SFF popped it 
up in our faces.

We did not change anything in the mail config when VMS was upgraded so 
its still tied to the VSI installation somehow.  I updated the VSI 
ticket with the info and will try to do some more testing like yours 
tomorrow (tonight their batches are running and pumping out emails so I 
can't).

Thanks again.
Rich