EDT Editor - Deletion of characters in a line

[Martin Bridgeman]

I have a COBOL program listing and no source. the retrieve the source file, I need to delete the first 9 characters. I used to know how to do this (ahem many years ago), and I would prefer to try using EDT rather than going through each line of 1600 to delete them manually.

Help!

[Jan van den Ende]

Martin,

if you accept going to TPU, you can :


^L (for LEARN)

(7 times)
^R (for Remember)
(Prompt: Key to remember)
(your favarite Control-key)


repeat 1600 (or a few less)
(Prompt: Press key to repeat)

(your favorite control ley)


hth,

Proost.

Have one on me.

jpe

[Dale A. Marcy]

Edit your file with EDT and enter the screen mode. Press K. Press the key that you want to define. Enter the following for the definition:

(9(D+C)L).

Press the enter key on the keypad. You can also add the D+C by typing the keypad comma and the L by typing keypad zero. The 9 is the number of times you want what is in the parenthesis repeated. The D+C deletes the current character on the line. The L moves you to the beginning of the next line. The outer paranthesis are so you can use the repeat function on your defined key. The period at the end tells EDT to execute the statements immediately upon pressing the key. When you are comfortable that this will work, you can press the Gold key and type the number of times you want the sequence to repeat and then press your defined key. Hope this helps.

[comarow]

If that seems complicated,
edit/tpu file
hit the do key
type erase line
do that 9 times.

The other solutions are more elegant.

[Hein van den Heuvel]

Are there not also page breaks and symbol tables to deal with? I would consider a little perl or gawk loop. If you attach a bit of a sample listing (with actual source obscured if you like) then I'm sure a reader can give you a one or two liner for this.

Cheers,
Hein.

[Robert Gezelter]

Martin,

I would concur with Hein's concerns. Albeit my preference would probably be DCL or a TECO macro.

There is a great danger in generating garbage by presuming that if there is a line, it MUST contain at least the expected number of characters.

A little code upfront will save a lot of pain later.

- Bob Gezelter, http://www.rlgsc.com

[Hein van den Heuvel]

In the mean time I found a cool listing.
Here is a simple perl commmand to solve your problem:

perl -ne "print $' if /\s+\d+\s/" x.lis > x.cob

-n = implied loop through input file
-e = perl script follows as text string

$' = everything to the right of the last match

\s+ = some whitespace (tab + spaces)
\d+ = some decimal numbers
\s = one more space

So this prints the remainder of those lines that start wih some spaces, a number and one more space.
This triggers on real source lines, but not on pagebreak data nor symbol table output and the likes.

hth,
Hein.

[John Gillings]

Please don't use the EDT editor.

EDT was made obselete by the introduction of TPU and EVE back in VMS V4 circa 1984. EDT has some serious limitations, and even a few outright bugs which will never be fixed. If you really can't teach yourself to use the EVE keypad (which is actually very simple... all the keys on a standard VT keypad do exactly what the label says!) then use EVE with the EDT kaypad.

Problems like this one are easily and intuitively solved using LEARN and REPEAT as described by Jan.

If we didn't have such a fanatical insistence on upwards compatibility, EDT would have long since been removed from the operating system Hey, we removed the dreaded SOS editor back in about V3, so I don't really see why we can't get rid of EDT more than 20 years after it was superceeded by MUCH better technology! If I had my way, the EDT image would issue a message:

"%DCL-I-JOIN_THE_21ST_CENTURY, use DEFINE EVE$KEYPAD EDT and EDIT/TPU or just learn to use EVE"

[Robert_Boyd]

John,

There is one situation where I think the TPU based editors fail. That's when you're logged in on a console where the VT support is not available or not properly configured to use it and you have to make changes to a startup procedure or control file.

Is there any way to use TPU/EVE in line mode in that scenario?

All I've ever been able to figure out in that situation is EDT.

Or is there a "standard" workaround for getting any console into a working VT setup after a minimum boot, or even a manual startup boot (set /startup=OPA0:)

Robert

[comarow]

I wish I remember how to use the line mode
in EDT, or if someone simply has a summary of simple commands,
so when a console isn't working you can fix
startup files.

[Ian Miller.]

I still use line mode in EDT for the situation previously described and when working on 20 year old MicroVAXes with little memory (I know teco is even more efficent than EDT for memory use but I remember very few teco commands now due to personal memory degredation :-)

I would use DCL for the original question in this thread.

[Uwe Zessin]

I use EDT for minimal changes on small files, because the startup time is much shorter than TPU and I use line-mode EDT, too.

Many years ago I used DCL to create EDT command files in a migration project that required changes to 300+ source files. That was much more efficient than trying to learn TPU again (I did a lot of TPU programming when VAX/VMS V4.x was current, but all that is gone now).

[Martin Vorlaender]

Robert,

>>>
Or is there a "standard" workaround for getting any console into a working VT setup after a minimum boot, or even a manual startup boot (set /startup=OPA0:)
<<<

...on a graphic terminal, I suppose.

I think Fred Kleinsorge mentioned in comp.os.vms that most graphics drivers have a crude VT52 emulation built in. I have no idea whether that would be enough for EVE.

cu,
Martin

[Uwe Zessin]

$ set terminal/vt52
$ edit/tpu login.com
%TPU-E-NONANSICRT, SYS$INPUT must be supported CRT

[Willem Grooters · Accepted solution]

Since it's a listing, it's a plain ASCII file.

You could consider using DCL:

$ open/read IN
$ open/write OUT (or .CBL?)
$loop:
$ SRCLINE=""
$ read/end=endloop IN LISLINE
$ if f$length(LISLINE) .gt. 9 then -
SRCLINE = f$extract (9, g$length(LISLINE), LISLINE)
$ write OUT SRCLINE
$ goto loop
$endloop:
$ close OUT
$ close IN
$ exit

Willem

[John Travell]

Another bullet point for EDT.
I once had a customer with an unrecoverable system hang. The real problem was that he had set his pagefile quota to more than half the size of the pagefile, but this would not have been an issue had he not tried to use TPU to edit some truly huge files. IIRC they were log files somewhere around 250,000 blocks.
The problem is that TPU reads the entire file into memory. Once the working set has grown as far as VMS will let it, the file content gets cycled through memory into the pagefile.
This would all have been OK if 'Mr Customer' had been more patient. TPU seemed to be taking a very long time to 'start up' (reading 200+k blocks and writing most of it back to the pagefile, which happened to be on the same disk, takes quite a while on the machine in use) so he started a new TPU edit in a new session. The machine hung, solid, with no free pages in memory and no free blocks in the pagefile...
Doing this with EDT may well have been less efficient, but it would not have taken VMS down !

JT:

[Jan van den Ende]

@John Travel:

1st: EDT would simply have halted, but indeed, it would NOT have hung the system
2nd: TPU/READ is MUCH better at "just scanning" such files! (but, yeah, you have to THINK beforehand, which tends to be quite hard).

fwiw,

Proost.

Have one on me.

jpe

[Antoniov.]

Hi,
I also use EDT just for memory degradation; I prefer to learn something other than another editor. However, sometimes, I have to use TPU when for file with line larger than 255 characters; I set key edt and continue.
For this question, I prefer a dcl procedure. Willem, I think there is a little bug in your example; if line is shorter than 9 character you write previous extracted line.
But your example is how I solve this problem.

Antonio Vigliotti

[Willem Grooters]

Antonio:
No, there isn't: SRCLINE is cleared at beginning of loop, befeore listing is read.

Yet, I agree it could well be enhanced (no error handling except EOF, for instance) and it might be optimezed. But I'd leave something for the user to do :-D

On EDT/EVE (EDT/TPU): It's a matter of personal taste. Of course, your primary choice will be the one you're most comfortable with.

being a developer, I normally use TPU and set keypad to EDT - even on an old, low-mem(64Mb) and low_disk (1Gb) DEC3000, since I'm used to it. It has rich features (causing a big memory footprint): uing a combination of an initialisation and section files has eanbled me (in the past) to incoprorate a rather big number of identical changes in a huge number of sources files - in batch. I couldn't have done this with good old EDT.

But it's good to know EDT in line mode as well. It's handy when you have an unsupported terminal type.

(Who would like a GUI-based editor on VMS? Would be fun on a character-cell terminal...)

Willem

[Uwe Zessin]

I've played a bit with
$ EDIT/TPU /INTERFACE=DECWINDOWS
but its overhead was even higher. Not fun on a small VAXstation.

[Martin Bridgeman]

Sorted. I have chickened out of learning new editors and stuck with DCL. It has done the spade work. I need only review and delete , and headings

Thanks for the efforts and the speed of response!!!

Go raibh mile maith agaibh go leir (Irish for a a thousand thanks to you all!)

[Bojan Nemec]

Martin,

If you go for a DCL procedure you can check the first 9 characters. If they are numeric (f$type().eqs."INTEGER") and not "0" or "" this is a source line otherwise this is a listing header.

And I also prefer EDT.

Bojan

[Lawrence Czlapinski]

John: Removing EDT would be a dangerous thing. I had problems with EVE on OPA0:. At the time I didn't know why the EVE editor wasn't editing the lines as they were on the screen. I had to use EDT for months till I finally figured out the cause. On VMS 7.3-2 and earlier, it turns out that for any account using OPA0:, a $SET TERMINAL/PAGE command to a size greater 24, doesn't change the window size but there is no error message. This is probably still true on VMS 8.X as well. This was probably a carry over from the days when OPA0: was a hard copy device. So there is a mismatch between DEC windows and EVE. So the edits you make on the screen don't match the actual changes being made.
To use EVE on OPA0:
1. The system must recognize the terminal as an ANSI terminal.
VT52 emulation is not an ANSI terminal. For OPA0:, I had to do a $SET TERM/INQUIRE to get the system to get the terminal type.
2. Second, the page length must be 24 lines or the editing gets all screwed up.
Lawrence