Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
VMS behaving like Windows ?
134 views
Skip to first unread message
Syltrem
May 15, 2013, 9:50:32 PM5/15/13
to
I mean... foolishly
I found that I could not logon on a DECWindows session on the console
with my account. So I went and checked all the .COMs that were called
upon login, and finally found the culprit.
The line of code that creates the problem is an IF statement, and the
condition is FALSE so the conditional statement NEVER executes.
Nevertheless.... if that statement is there, it makes the logon freeze
(stays on the screen forever with the message "Starting the New
Desktop for OpenVMS" and the hourglass).
The statement :
$ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
$ THEN a=1
$ DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
$ sh sym a
$ ELSE a=2
$ sh sym a
$ ENDIF
I added the "a=1" and "sh sym a", and the ELSE statement, to be 500%
certain the IF was false and it would not execute the DEASSIGN. It
does not.
The log file shows the ELSE statement is executed, and a=2.
$ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
$ ELSE a=2
$ sh sym a
A = 2 Hex = 00000002 Octal = 00000000002
$ ENDIF
If I leave everything but put a comment in front of the DEASSIGN verb,
the logon goes through without problems. A "Z" in front of DEASSIGN
(that makes ZDEASSIGN) also works. It just doesn't like to see the
DEASSIGN command in there, event if it's not executed.
I also *know* the LANG logical is not defined.
If I take the whole statement IF..ENDIF out of context and move it to
my LOGIN.COM, it does no harm and the logon goes through.
I don't get it.
Someone cares to explain ? Or do I report a bug to HP ?
Thanks
Syltrem
I found that I could not logon on a DECWindows session on the console
with my account. So I went and checked all the .COMs that were called
upon login, and finally found the culprit.
The line of code that creates the problem is an IF statement, and the
condition is FALSE so the conditional statement NEVER executes.
Nevertheless.... if that statement is there, it makes the logon freeze
(stays on the screen forever with the message "Starting the New
Desktop for OpenVMS" and the hourglass).
The statement :
$ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
$ THEN a=1
$ DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
$ sh sym a
$ ELSE a=2
$ sh sym a
$ ENDIF
I added the "a=1" and "sh sym a", and the ELSE statement, to be 500%
certain the IF was false and it would not execute the DEASSIGN. It
does not.
The log file shows the ELSE statement is executed, and a=2.
$ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
$ ELSE a=2
$ sh sym a
A = 2 Hex = 00000002 Octal = 00000000002
$ ENDIF
If I leave everything but put a comment in front of the DEASSIGN verb,
the logon goes through without problems. A "Z" in front of DEASSIGN
(that makes ZDEASSIGN) also works. It just doesn't like to see the
DEASSIGN command in there, event if it's not executed.
I also *know* the LANG logical is not defined.
If I take the whole statement IF..ENDIF out of context and move it to
my LOGIN.COM, it does no harm and the logon goes through.
I don't get it.
Someone cares to explain ? Or do I report a bug to HP ?
Thanks
Syltrem
Peter 'EPLAN' LANGSTOeGER
May 16, 2013, 2:33:17 AM5/16/13
to
In article <5oe8p8hvo4spcvauh...@4ax.com>, Syltrem <syltr...@videotron.ca> writes:
>If I leave everything but put a comment in front of the DEASSIGN verb,
>the logon goes through without problems. A "Z" in front of DEASSIGN
>(that makes ZDEASSIGN) also works. It just doesn't like to see the
>DEASSIGN command in there, event if it's not executed.
>I also *know* the LANG logical is not defined.
So, %SYSTEM-F-NOLOGNAM vs. %DCL-W-IVVERB vs. %SYSTEM-S-NORMAL
>If I leave everything but put a comment in front of the DEASSIGN verb,
>the logon goes through without problems. A "Z" in front of DEASSIGN
>(that makes ZDEASSIGN) also works. It just doesn't like to see the
>DEASSIGN command in there, event if it's not executed.
>I also *know* the LANG logical is not defined.
>If I take the whole statement IF..ENDIF out of context and move it to
>my LOGIN.COM, it does no harm and the logon goes through.
>I don't get it.
>Someone cares to explain ? Or do I report a bug to HP ?
--
Peter "EPLAN" LANGST�GER
Network and OpenVMS system specialist
E-mail Pe...@LANGSTOeGER.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
Stephen Hoffman
May 16, 2013, 1:54:32 PM5/16/13
to
On 2013-05-16 01:50:32 +0000, Syltrem said:
> I mean... foolishly
DECwindows version and patch? VMS version and patch? There've been
various fixes to DECwindows, DCL and other related hunks over the
years, and having a DECwindows login — CDE or Motif — tip over is not
particularly unusual.
>
> I found that I could not logon on a DECWindows session on the console
> with my account. So I went and checked all the .COMs that were called
> upon login, and finally found the culprit.
>
> The line of code ....
Presumably that is (was) DCL within either DECW$SYLOGIN.COM or
DECW$LOGIN.COM procedures, inferring from some of your phrasing.
IIRC, output generated from those DECW$*LOGIN.COM procedures could
interrupt processing, too. I don't know off-hand if that was a bug or
a feature, though. Or if I'm even remembering that stuff correctly, as
it's been a while since I've bothered to use DECW$*LOGIN.COM procedures
for much of anything.
> ... that creates the problem is an IF statement, and the
parts of DECwindows are known for creating log files or dump files,
even when things haven't gone sideways. Dig around in the DECwindows
server logs, for instance, and check the system directories for any
freshly-written .DMP or .LOG carcasses. Also see if the
SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM stuff that can generate
SYS$MANAGER:DECW$LOGIN.LOG via the DECW$LOGINLOG symbol shows any more
details of what happened; that's discussed in the DECwindows
troubleshooting documentation.
> The statement :
>
> $ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
> $ THEN a=1
> $ DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
> $ sh sym a
> $ ELSE a=2
> $ sh sym a
> $ ENDIF
> ...
I'm not a huge fan of putting commands onto the THEN and the ELSE lines
in an IF-THEN-ELSE-ENDIF block, as there've been occasional DCL bugs
with handling that syntax over the years.
DCL has had its share of bugs.
As has DECwindows.
As has the rest of VMS.
> If I leave everything but put a comment in front of the DEASSIGN verb,
> the logon goes through without problems. A "Z" in front of DEASSIGN
> (that makes ZDEASSIGN) also works. It just doesn't like to see the
> DEASSIGN command in there, event if it's not executed.
> I also *know* the LANG logical is not defined.
>
> If I take the whole statement IF..ENDIF out of context and move it to
> my LOGIN.COM, it does no harm and the logon goes through.
> I don't get it.
>
> Someone cares to explain ?
Um, "If it hurts, don't do that?" Slightly more seriously, something
blew up. See if there are logs or dumps.
> Or do I report a bug to HP ?
If you're patched to current and have a support contract and on a
supported version and need or want a fix for this then sure.
{But it's not like you need anybody's permission to do that, after all.}
The chances of getting a fix for this misbehavior otherwise will be
correspondingly, well, low.
--
Pure Personal Opinion | HoffmanLabs LLC
> I mean... foolishly
DECwindows version and patch? VMS version and patch? There've been
various fixes to DECwindows, DCL and other related hunks over the
years, and having a DECwindows login — CDE or Motif — tip over is not
particularly unusual.
>
> I found that I could not logon on a DECWindows session on the console
> with my account. So I went and checked all the .COMs that were called
> upon login, and finally found the culprit.
>
Presumably that is (was) DCL within either DECW$SYLOGIN.COM or
DECW$LOGIN.COM procedures, inferring from some of your phrasing.
IIRC, output generated from those DECW$*LOGIN.COM procedures could
interrupt processing, too. I don't know off-hand if that was a bug or
a feature, though. Or if I'm even remembering that stuff correctly, as
it's been a while since I've bothered to use DECW$*LOGIN.COM procedures
for much of anything.
> ... that creates the problem is an IF statement, and the
> condition is FALSE so the conditional statement NEVER executes.
> Nevertheless.... if that statement is there, it makes the logon freeze
> (stays on the screen forever with the message "Starting the New
> Desktop for OpenVMS" and the hourglass).
There's some troubleshooting information in the manuals, and various
> Nevertheless.... if that statement is there, it makes the logon freeze
> (stays on the screen forever with the message "Starting the New
> Desktop for OpenVMS" and the hourglass).
parts of DECwindows are known for creating log files or dump files,
even when things haven't gone sideways. Dig around in the DECwindows
server logs, for instance, and check the system directories for any
freshly-written .DMP or .LOG carcasses. Also see if the
SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM stuff that can generate
SYS$MANAGER:DECW$LOGIN.LOG via the DECW$LOGINLOG symbol shows any more
details of what happened; that's discussed in the DECwindows
troubleshooting documentation.
> The statement :
>
> $ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
> $ THEN a=1
> $ DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
> $ sh sym a
> $ ELSE a=2
> $ sh sym a
> $ ENDIF
I'm not a huge fan of putting commands onto the THEN and the ELSE lines
in an IF-THEN-ELSE-ENDIF block, as there've been occasional DCL bugs
with handling that syntax over the years.
DCL has had its share of bugs.
As has DECwindows.
As has the rest of VMS.
> If I leave everything but put a comment in front of the DEASSIGN verb,
> the logon goes through without problems. A "Z" in front of DEASSIGN
> (that makes ZDEASSIGN) also works. It just doesn't like to see the
> DEASSIGN command in there, event if it's not executed.
> I also *know* the LANG logical is not defined.
>
> If I take the whole statement IF..ENDIF out of context and move it to
> my LOGIN.COM, it does no harm and the logon goes through.
> I don't get it.
>
> Someone cares to explain ?
blew up. See if there are logs or dumps.
> Or do I report a bug to HP ?
supported version and need or want a fix for this then sure.
{But it's not like you need anybody's permission to do that, after all.}
The chances of getting a fix for this misbehavior otherwise will be
correspondingly, well, low.
--
Pure Personal Opinion | HoffmanLabs LLC
Syltrem
May 16, 2013, 8:58:06 PM5/16/13
to
On Thu, 16 May 2013 13:54:32 -0400, Stephen Hoffman
<seao...@hoffmanlabs.invalid> wrote:
>On 2013-05-16 01:50:32 +0000, Syltrem said:
>
>> I mean... foolishly
>
>DECwindows version and patch? VMS version and patch? There've been
>various fixes to DECwindows, DCL and other related hunks over the
>years, and having a DECwindows login � CDE or Motif � tip over is not
>particularly unusual.
>
I know - I had other problems long ago. Still have a few comments in
<seao...@hoffmanlabs.invalid> wrote:
>On 2013-05-16 01:50:32 +0000, Syltrem said:
>
>> I mean... foolishly
>
>DECwindows version and patch? VMS version and patch? There've been
>various fixes to DECwindows, DCL and other related hunks over the
>years, and having a DECwindows login � CDE or Motif � tip over is not
>particularly unusual.
>
my login.com.
This is now on OVMS 8.3
DEC AXPVMS DWMOTIF_ECO04 V1.6 Patch Install Val
01-MAR-2010
A bit old, certainly. I only ever use it (DEC$Windows) to install
Oracle and the way things have been going lately, this has not happen.
And may not again for a long time.
>>
>> I found that I could not logon on a DECWindows session on the console
>> with my account. So I went and checked all the .COMs that were called
>> upon login, and finally found the culprit.
>>
>> The line of code ....
>
>Presumably that is (was) DCL within either DECW$SYLOGIN.COM or
>DECW$LOGIN.COM procedures, inferring from some of your phrasing.
>
>IIRC, output generated from those DECW$*LOGIN.COM procedures could
>interrupt processing, too. I don't know off-hand if that was a bug or
>a feature, though. Or if I'm even remembering that stuff correctly, as
>it's been a while since I've bothered to use DECW$*LOGIN.COM procedures
>for much of anything.
>
statement though does nothing at all - so no output
It's called from my LOGIN.COM, and comes from PowerHouse (to setup its
symbols/logicals). The command : $SETPOWERHOUSE
The bit of code is specifically in SETPH.COM.
>> ... that creates the problem is an IF statement, and the
>> condition is FALSE so the conditional statement NEVER executes.
>> Nevertheless.... if that statement is there, it makes the logon freeze
>> (stays on the screen forever with the message "Starting the New
>> Desktop for OpenVMS" and the hourglass).
>
>There's some troubleshooting information in the manuals, and various
>parts of DECwindows are known for creating log files or dump files,
>even when things haven't gone sideways. Dig around in the DECwindows
>server logs, for instance, and check the system directories for any
>freshly-written .DMP or .LOG carcasses. Also see if the
>SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM stuff that can generate
>SYS$MANAGER:DECW$LOGIN.LOG via the DECW$LOGINLOG symbol shows any more
>details of what happened; that's discussed in the DECwindows
>troubleshooting documentation.
don't exist; DECW$LOGINLOG is not defined
>
>> The statement :
>>
>> $ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. ""
>> $ THEN a=1
>> $ DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
>> $ sh sym a
>> $ ELSE a=2
>> $ sh sym a
>> $ ENDIF
>> ...
>
>I'm not a huge fan of putting commands onto the THEN and the ELSE lines
>in an IF-THEN-ELSE-ENDIF block, as there've been occasional DCL bugs
>with handling that syntax over the years.
login.com) what was actually been executed - the THEN or the ELSE
The original statement is actually on a single line :
$ IF F$TRNLNM("LANG","LNM$PROCESS") .NES. "" THEN
DEASSIGN/TABLE=LNM$PROCESS_TABLE LANG
>
>DCL has had its share of bugs.
>
>As has DECwindows.
>
>As has the rest of VMS.
>
>
>> If I leave everything but put a comment in front of the DEASSIGN verb,
>> the logon goes through without problems. A "Z" in front of DEASSIGN
>> (that makes ZDEASSIGN) also works. It just doesn't like to see the
>> DEASSIGN command in there, event if it's not executed.
>> I also *know* the LANG logical is not defined.
>>
>> If I take the whole statement IF..ENDIF out of context and move it to
>> my LOGIN.COM, it does no harm and the logon goes through.
>> I don't get it.
>>
>> Someone cares to explain ?
>
>Um, "If it hurts, don't do that?" Slightly more seriously, something
>blew up. See if there are logs or dumps.
Only these 3 log files with nothing helpful (no errors) in them
DECW$SERVER_0_ERROR.LOG;279
decw$sm.log;79
DECW$STARTUP_0.LOG;32
>
>> Or do I report a bug to HP ?
>
>If you're patched to current and have a support contract and on a
>supported version and need or want a fix for this then sure.
>{But it's not like you need anybody's permission to do that, after all.}
>The chances of getting a fix for this misbehavior otherwise will be
>correspondingly, well, low.
I'll just wait and see what happens when I get there, and all patched
up.
I still find it very strange that it would act like this. Probably a
bug in DCL.
Thanks for your time
Syltrem
Stephen Hoffman
May 17, 2013, 8:11:19 AM5/17/13
to
On 2013-05-17 00:58:06 +0000, Syltrem said:
> On Thu, 16 May 2013 13:54:32 -0400, Stephen Hoffman
> <seao...@hoffmanlabs.invalid> wrote:
>>
>> DECwindows version and patch? VMS version and patch? There've been
>> various fixes to DECwindows, DCL and other related hunks over the
>> years, and having a DECwindows login — CDE or Motif — tip over is not
>> particularly unusual.
>
> I know - I had other problems long ago. Still have a few comments in
> my login.com.
> This is now on OVMS 8.3
> DEC AXPVMS DWMOTIF_ECO04 V1.6 Patch Install Val
> 01-MAR-2010
> A bit old, certainly.
Which VMS patches? A semi-recent UPDATE or the current UPDATE would be
> On Thu, 16 May 2013 13:54:32 -0400, Stephen Hoffman
> <seao...@hoffmanlabs.invalid> wrote:
>>
>> DECwindows version and patch? VMS version and patch? There've been
>> various fixes to DECwindows, DCL and other related hunks over the
>> years, and having a DECwindows login — CDE or Motif — tip over is not
>> particularly unusual.
>
> I know - I had other problems long ago. Still have a few comments in
> my login.com.
> This is now on OVMS 8.3
> DEC AXPVMS DWMOTIF_ECO04 V1.6 Patch Install Val
> 01-MAR-2010
> A bit old, certainly.
advisable, particularly if you're having issues.
Yes, V8.3 is comparatively ancient. It's most of seven years old.
Next month, V8.4 will have been available for three years. AFAIK,
that's the longest any VMS release has been the current release, going
back to V4.0 and quite possibly all the way to the beginning. There
are no new VMS releases on the roadmap past V8.4.[1]
VMS V8.4 — with UPDATE V5 or later — has been stable, from what I've
seen of it.
HP currently plans the have VMS Alpha V8.4 standard support available
through December 2016, with twenty-four month's notice. Possibly
longer.
>> There's some troubleshooting information in the manuals, and various
>> parts of DECwindows are known for creating log files or dump files,
>> even when things haven't gone sideways. Dig around in the DECwindows
>> server logs, for instance, and check the system directories for any
>> freshly-written .DMP or .LOG carcasses. Also see if the
>> SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM stuff that can generate
>> SYS$MANAGER:DECW$LOGIN.LOG via the DECW$LOGINLOG symbol shows any more
>> details of what happened; that's discussed in the DECwindows
>> troubleshooting documentation.
>
> SYS$MANAGER:DECW$PRIVATE_APPS_SETUP.COM and SYS$MANAGER:DECW$LOGIN.LOG
> don't exist; DECW$LOGINLOG is not defined
documentation and the referenced DCL symbol — DCL symbol, not VMS
logical name — to establish the logging, and look at the resulting logs?
————
[1]HP has been releasing a limited number of enhancements within V8.4
patch kits, but you might be hard-pressed to find details of those
changes anywhere other than in the patch release notes. There's also
no (documented) API to see what patch level you're at, so boot-time and
run-time checks for what features are available in the current
configuration can be... interesting.
David Froble
May 18, 2013, 11:55:20 AM5/18/13
to
Stephen Hoffman wrote:
> Yes, V8.3 is comparatively ancient. It's most of seven years old.
VMS isn't weendoze ....
> Yes, V8.3 is comparatively ancient. It's most of seven years old.
It ages much more gracefully.
Though, I do wish my old VAXs could sue S-ATA drives ....
Bart Zorn
May 19, 2013, 2:46:03 AM5/19/13
to
Bart
0 new messages