On Mon, 7 Oct 2013, Cory Smelosky wrote:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the problem though as it's SYSTEM-ABORTing again...
Don't get why it works sometimes and sometimes not. I need Mark P's help for this.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
It's coming in on a serial line, actually. Apparently that's not the problem though as it's SYSTEM-ABORTing again...
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
yOn Mon, 7 Oct 2013, Tim Sneddon wrote:
On Mon, Oct 7, 2013 at 11:31 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=**IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
I've seen this screw lots of stuff. I have stuff in my personal
LOGIN.COMthat configures the terminal they way I like it. I just wrap
it in the
following:
$ interactive = (f$mode() .eqs. "INTERACTIVE")
$ network = (f$mode() .eqs. "NETWORK")
$ batch = (f$mode() .eqs. "BATCH")
...
$ if (interactive)
$ then
$ set terminal ...
$ endif
Regards, Tim.
WTF. And now UUCP isn't working again?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away
(ACCOUNTING didn't have anything useful to say). I know I can disable it
per-line/per-use but this was the quickest test.
Now we're getting somewhere.
Try putting:
$ IF "''F$mode()'".EQS."NETWORK" THEN $ EXIT
at the beginning of your SYLOGIN.COM and LOGIN.COM files.
You can not SET TERM/INQUIRE if there's no terminal. ;)
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Mon, Oct 7, 2013 at 11:31 PM, Cory Smelosky <b4 at gewt.net> wrote:
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away (ACCOUNTING didn't have anything useful to say). I know I can disable it per-line/per-use but this was the quickest test.
I've seen this screw lots of stuff. I have stuff in my personal LOGIN.COM that configures the terminal they way I like it. I just wrap it in the following:
$ interactive = (f$mode() .eqs. "INTERACTIVE")
$ network = (f$mode() .eqs. "NETWORK")
$ batch = (f$mode() .eqs. "BATCH")
...
$ if (interactive)
$ then
$ set terminal ...
$ endif
Regards, Tim.
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
The question then begs to be asked, why do you think your command
definitions are changing or being deleted.
Well, after the install, or random subsequent logins CC, COBOL, FORTRAN, or PASCAL all were valid commands. Now after subsequent reboots/logins they are not.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
The question then begs to be asked, why do you think your command
definitions are changing or being deleted.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
On Mon, 7 Oct 2013, Cory Smelosky wrote:
Let's assume you have no need for your prior accounting information...
$ SET ACCOUNTING/NEW_FILE/ENABLE=IMAGE
Execute the UUCP command(s) which fail.
$ ACCOUNTING/SINCE=TODAY
Post that output and let's see if there's anything revealing in there.
Also, you can $ SET ACCOUNTING/DISABLE=IMAGE because /ENABLE=IMAGE can
become a resource hog.
Doing so now.
I disabled TERM/INQ on login in SYLOGIN and the abort went away (ACCOUNTING didn't have anything useful to say). I know I can disable it per-line/per-use but this was the quickest test.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On Mon, 7 Oct 2013, Brian Schenkenberger, VAXman- wrote:
Cory Smelosky <b4 at gewt.net> writes:
On Mon, 7 Oct 2013, Jordi Guillaumes i Pons wrote:
Any chance you have got two different DCLTABLES in SYS$COMMON and SYS$SPECIFIC?
I'd answer if I could find where in sys$common and sys$specific they
are...
DCLTABLES is an executable. It's a mapped image section. It's name is
DCLTABLES.EXE and it should be in the common root of SYS$LIBRARY. Thus,
you should be looking in SYS$COMMON:[SYSLIB]. If you have DCLTABLES.EXE
in SYS$SPECIFIC:[SYSLIB], strange things (ie. unpredictable results) can
occur when products add their command definitions to DCLTABLES.EXE.
Looks like I don't have a DCLTABLES.EXE in SYS$SPECIFIC.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
