LTT for OpenVMS STKOVF after "firmware download start"

[Lars Funck Jensen]

After upgrading a DS20E to 7.3-2 update 3 + all patches pr. 1-mar-2005 I downloaded and installed LTT 3.5 SR2. I downloaded the DAT72 frm file to the windows version of LTT and FTP'ed it to the LTT firmware directory.
( VMS session logout/login)

When i started LTT, scanned for devices and selected "firmware" the DAT72 v312 was shown and upon entering "start" CR. the following was shown on my screen.


-------------------------------------
%SYSTEM-F-STKOVF, stack overflow, PC=00000000012E5C58, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs
PC
HP_LTT oc_util l_FormattedString_ParseFormat
43828 000000000000B028 00000000012E5C58
HP_LTT oc_util g_VFormattedString 43602 000000000000A8A4 00000000012E54D4
HP_LTT oc_util g_FormattedString 43563 0000000000009EF8 00000000012E4B28
HP_LTT oc_events File_ToText 43505 0000000000006124 00000000012673A4
HP_LTT oc_events WriteEvent 44593 0000000000010BD8 0000000001271E58
HP_LTT oc_events OnEventNotification
44394 000000000000EA34 000000000126FCB4
HP_LTT oc_events ProcessEvent 43632 000000000000745C 00000000012686DC
HP_LTT oc_events PublishEvent 43807 0000000000007CEC 0000000001268F6C
HP_LTT oc_events PublishEvent 44016 00000000000093F4 000000000126A674
HP_LTT oc_logicaldevice SCSI_DownloadFirmware
39907 000000000000791C 0000000001050D3C
HP_LTT oc_dlg_cmdshell_firmware Download
56985 0000000000011314 0000000000C78324
HP_LTT oc_dlg_cmdshell_firmware Run 57143 00000000000147C4 0000000000C7B7D4
HP_LTT oc_threadimpl_posix ThreadProc
6797 00000000000002BC 000000000125FEBC
PTHREAD$RTL 0 0000000000055D7C 000000007BD35D7C
PTHREAD$RTL 0 0000000000042B90 000000007BD22B90
0 0000000000000000 0000000000000000
PTHREAD$RTL ?
?
Enter Command>
%CMA-F-EXIT_THREAD, current thread has been requested to exit

$ dir <...>*.frm/fu
LTT_HP_C7438A_V312.FRM;1 File ID: (15882,164,0)
Size: 665/700 Owner: [SYSTEM]
Created: 7-MAR-2005 15:17:44.76
Revised: 7-MAR-2005 15:17:44.82 (1)
Expires: 27-AUG-2010 15:17:44.82
Backup: 9-MAR-2005 02:06:12.14
Effective:
Recording:
Accessed:
Attributes:
Modified:
Linkcount: 1
File organization: Sequential
Shelved state: Online
Caching attribute: Writethrough
File attributes: Allocation: 700, Extend: 0, Global buffer count: 0
No version limit
Record format: Fixed length 512 byte records
Record attributes: None
RMS attributes: None
Journaling enabled: None
File protection: System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List: None
Client attributes: None

[Jan van den Ende]

Lars,

I know nothing about LTT, but sometimes the simple questions should be asked first.

Since you got your file via Windows, using ftp:
Did the file get across correct?
FTP using BINARY?
And after that, is your file header info correct? FTP (at least non-VMS_to_VMS) is too stupid to know about such important details.
This looks like one of the kinds of errors that COULD be caused by the file header describing an other format than the data actually has.
Obviously you have a prior version?
Do a DIR/FULL of that, and do a SET FILE/ATTRIBUTES=.

If this helps, great, if not, at least it was worth checking!

hth

Proost.

Have one on me.

Jan

[Lars Funck Jensen]

1. I do not think any program should dump with a STKOVF error.

2. FTP (binary) from a Windows firmware file
is the only path i have found to get the
firmware into the VMS systems.

[Jan van den Ende]

Lars,



2. FTP (binary) from a Windows firmware file
is the only path i have found to get the
firmware into the VMS systems.


Agreed, and just THAT is the reason that you need to find out what the file attributes are supposed to be, and then modify the file header (NOT the contents!) with SET FILE/ATTR.

And, look at your deepest (first) traceback statement line:

HP_LTT oc_util l_FormattedString_ParseFormat

So, that also suggests that trying to understand ("parse") how a certain string should be dealt with is failing.
And that is what you tend to get when you interpret data in one format, while it is in another format. Like reading a sentence in a foreign language you do not know: you can see (and if in a know "font", ie, ASCI, you can read it) the text, but you do not get
any meaning out of it.

In binary FTP, your contents (should) stay unchanged, but the info how to interpret it gets lost.

"learning the language" ie, tell your parsing what each syntax element means by giving it the correct file header, will bring you the meaning of the "text".

-- reading back, I hope the metaphores do give the intend, but they are just to demonstrate the idea, please do not view them too literal!

hth,

Proost.

Have one on me.

Jan

[Uwe Zessin · Accepted solution]

I suggest you send a mail with this information to the "ltt_team" AT "hp.com".

[Tom O'Toole]

We have encountered a similar (maybe exactly the same) problem here, and have a call into HP. I don't think it's a file transfer problem.

[Lars Funck Jensen]

Pleae note the DS20E 67667 has 2 CPU's.

I think it may have someting to do with
threads running in parrallel in realtime.

[Volker Halle]

Lars,

to rule out an SMP issue (multiple threads of this image running on multiple CPUs at the same time), just temporarily do a STOP/CPU/ALL before running LTT. If done, start the other CPU(s) again with START/CPU/ALL

If LTT still fails with STKOVF, then it's not an SMP/multi-threading issue.

Volker.

[Lars Funck Jensen]

>>do a STOP/CPU/ALL before running LTT

I will, but the CPU is 500 km from where I am now and it is a production system. I must coordinate with the production.
I think the tapedrive should be empty during FW update.

[Lars Funck Jensen]

I have sent information to the HP LTT team.