Operating System - OpenVMS
1753329 Members
5023 Online
108792 Solutions
New Discussion юеВ

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

 
SOLVED
Go to solution
Pradeep K P
Occasional Advisor

Looping processes with DCL.EXE and DCLTABLES.EXE

Hello,

I've two looping process with 5 open channels along with DCL.EXE and DCLTABLES.EXE. I checked with $MONITOR MODE, which shows me executive mode is using 97%-99%. Appreciate the guidance to proceed further to find out any reason for looping.

Thanks in advance.

SDA> show proc/channel

Process index: 02D5 Name: _TNA176: Extended PID: 22E01AD5
--------------------------------------------------------------------


Process active channels
-----------------------

Channel CCB Window Status Device/file accessed
------- --- ------ ------ --------------------
0010 7FF60000 00000000 DSA2:
0040 7FF60060 00000000 TNA176:
0060 7FF600A0 00000000 TNA176:
0090 7FF60100 83444580 DSA2:[VMS$COMMON.SYSEXE]DCL.EXE;1 (section file)
00A0 7FF60120 83437D40 DSA2:[VMS$COMMON.SYSLIB]DCLTABLES.EXE;480 (section file)

Total number of open channels : 5.
8 REPLIES 8
John Gillings
Honored Contributor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

Pradeep,

Any idea what events led up to this state?

The first channel is your default device, the next two are SYS$INPUT and SYS$OUTPUT (ie: you're logged in via telnet). DCL and DCLTABLES are normal for an interactive process. You're not actually running any image. So, those channels are quite normal.

Some DCL commands don't run images, but I can't think of any offhand that are likely to loop. I'd recommend checking where TNA176 is connected (or not!).

SET PROCESS/SUSPEND and SHOW CALLS in SDA may help pinpoint where it's looping.

Is your TCPIP version and patch level up to date?

To just clean up, if STOP/ID doesn't work (and I'd guess it might not), try finding the BG device attached to TNA176 and disconnect it.
A crucible of informative mistakes
Pradeep K P
Occasional Advisor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

Hello John,

I done a set proc/ide=xxx/prio=0 before starting the analysis. I collected some show call output as well. I'm providing herewith. Again TNA176: is a VT type device and i believe its not connected to any BG device(s).

SDA> show call

Possible Null Frame at 00000000.7B115C78
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.80345E10 RMS+B5E10

SDA> show call/next

Possible Null Frame at 00000000.7B115CD0
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.8030AC20 RMS+7AC20

SDA> show call/next

Possible Null Frame at 00000000.7B115CF8
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = SP, Jacket
Procedure Entry: FFFFFFFF.800D0CA0 EXCEPTION+24CA0

SDA> show call/next

Possible Null Frame at 00000000.7B115D10
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.802F41D0 RMS+641D0

SDA> show call/next

Possible Null Frame at 00000000.7B115D30
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.802F3FA0 RMS+63FA0

SDA> show call/next

Possible Null Frame at 00000000.7B115D40
----------------------------------------
Possible Null Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.802F3390 RMS+63390

SDA> show call/next

Memory Stack Frame at 00000000.7B115D68
---------------------------------------
Stack Frame Procedure Descriptor
Flags: Base Register = FP, No Jacket, Native
Procedure Entry: FFFFFFFF.802E9F00 RMS+59F00
Handler at FFFFFFFF.81D3AFF8
Return address on stack = FFFFFFFF.80083574 EXE$KP_START_C+002F4

Registers saved on stack
------------------------
7B115D88 FFFFFFFF.81D3AFC0 Saved R13 RMS+E77C0
7B115D90 00000000.00000000 Saved R29
SDA> show call/next
Cannot display further call frames (Bottom of stack)
Hein van den Heuvel
Honored Contributor
Solution

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

Well, exec mode is in fact RMS.

My best guess DCL is trying to call SYS$GET, being returned an error and retrying in a tight loop.

To verify this suggestion please use
ANALYZE/SYSTEM
SDA> SET PROC loopy
SDA> SHOW PROC/RMS=(PIO,RAB) ! ProcessIO

Pay close attention to the STS and STV fields.
I suspect they will flash error number.
You may have to try a few times.

The error would be the clue to the problem.

For example an attempt to do a keyed read from a terminal:
http://groups.google.com/group/comp.os.vms/search?hl=en&group=comp.os.vms&q=hein+dcl+kids+try+


If you look in the next rab (for sys$output, channel 90) you may see a last gasp message by doing on an examine for the string pointed to by RBF for a length of RSZ

You could also use the SDA PCS or PRF extentions to 'see the loop' if need be.

Sure this helps, ( :^)

Hein.





Pradeep K P
Occasional Advisor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

Hello Hein,

Thanks all for the valuable replies.

I got error code after tring few times. I'm not quite good to understand these codes, Please provide me some in-sight into this. Here i'm pasting the output of
SDA>Show proc/rms=(PIO,RAB)

Process index: 02D5 Name: _TNA176: Extended PID: 22E01AD5
--------------------------------------------------------------------
RAB Address: 7FFCEFCC
-----------

BID: 01 1. ISI: 8081
BLN: 44 68.
ROP: 50000000 ETO,PMT
ROP_2: 0000
CTX: 0C040007 RAC: 00 SEQ
STS: 00018272 RFA: 00000000,0000
STV: 00000084
TMO: 00 0. RHB: 00000000
USZ: 1000 4096. UBF: 7FF9FEA6
RSZ: 0000 0. RBF: 7FF9FEA6
KBF: 7FF9DEAD KSZ: 19 25.
PBF: 7FF9DEAD PSZ: 19 25.
KRF: 00 0. MBC: 01 1.
MBF: FF 255. BKT: 00000000
FAB: 7FFCEE84 DCT: 00000000
XAB: 7FFCF0EC

Press RETURN for more.
SDA>

Process index: 02D5 Name: _TNA176: Extended PID: 22E01AD5
--------------------------------------------------------------------
XABTRM Address: 7FFCF0EC
---------------

COD: 1F 31. BLN: 24 36.
NXT: 00000000 RVN: F114
ITMLST: 7FFCF114 ITMLST_LEN: 0018 24.

Thanks Once again for valuable comments.
David B Sneddon
Honored Contributor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

You don't mention what versions of anything
you are running... this reminds me of problems
in the past where users would just quit their
terminal emulator rather than logout then exit.
Don't recall which versions fixed it but it
might be worth an upgrade (for all the other
obvious reasons as well)

Dave
Pradeep K P
Occasional Advisor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

Thanks Dave,

We are using
HP TCP/IP Services for OpenVMS Alpha Version V5.6 - ECO 1
on an hp AlphaServer GS1280 7/1300 running OpenVMS V8.3

Cheers,
Pradeep
Hein van den Heuvel
Honored Contributor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

>> I'm not quite good to understand these codes, Please provide me some in-sight into this.

Hmmm, please drop those privileges and slowly step back from the machine!

Just ask SDA or DCL

SDA> eval/cond 84
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
SDA> eval/cond 00018272
%RMS-E-DNR, device not ready, not mounted, or unavailable


$ exit %x84
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
$ exit %x00018272
%RMS-E-DNR, device not ready, not mounted, or unavailable

So it looks like the input device just went away and DCL is retrying willy-nilly.

What OpenVMS version/platform/patches?

Please be sure to escalate to the next level of support if and when neeed.

Best regards,
Hein van den Heuvel

Wim Van den Wyngaert
Honored Contributor

Re: Looping processes with DCL.EXE and DCLTABLES.EXE

There is aa 5.6 eco 3. But again they require you to download it to obtain the release notes. So, I didn't read if your problem is in it.

http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=DEC-AXPVMS-TCPIP-V0505-11ECO3-1&sel={openvms:alpha:8.3,}&BC=main|search|

But be careful : installing the patch may also introduce new problems. Test it first.

Wim
Wim