EDIT & TEDIT difference.

[Vijay Muralidharan]

Hi. I saw in some of the discussions that EDIT & TEDIT files are differentiated. Can anyone tell me wot is the difference.

[Robert Hutchings]

TEDIT is more screen-oriented but EDIT is very powerful as a command line tool. You can use the "EDIT file;XVS" option which will go to screen mode. Download the TEDIT manual and try to learn that first, then you can try EDIT later. This is my opinion...

[Doug Miller]

Vijay Muralidharan <vijay....@gmail.com> wrote in
news:1aeb8e00-33c7-42a7...@googlegroups.com:

> Hi. I saw in some of the discussions that EDIT & TEDIT files are
> differentiated. Can anyone tell me wot is the difference.

There is no difference at all between the files.

[wbreidbach]

EDIT is the older tool and TEDIT is the newer one and both are still supported.
The very "old" Tandem guys use EDIT, the newer ones (like me who started with Tandem in 1988) use TEDIT. EDIT can be used with command line and can even be used to convert an Enscribe to an EDIT file.
TEDIT only works in blockmode and supports different screensizes up to 132/54. I do not know if EDIT supports the bigger screensizes. TEDIT is also rather powerful if you know the capabilities but most people only know its standard functions. Especially the Search function has a "When found" parameter allowing you to define what TEDIT has to do when the searchcriteria is found.

[Doug Miller]

wbreidbach <wolfgang....@bv-zahlungssysteme.de> wrote in
news:4332b19e-0e83-4bfa...@googlegroups.com:

> TEDIT only works in blockmode and supports different screensizes
> up to 132/54. I do not know if EDIT supports the bigger
> screensizes.

AFAIK, EDIT-VS supports 80x24 and 132x24 only.

[Keith Dick]

All the talk in this thread about the differences between EDIT and TEDIT tends to obscure the answer to the original question about the file format.

Doug got it right: there is no difference in the file format. An Edit file -- a Guardian unstructured code 101 file -- is what both EDIT and TEDIT work with.

This is not to argue with anything anyone has said about the differences between the two programs, just to reemphasize that the original question was about the file format, not the programs, and the file format is exactly the same.

[wbreidbach]

Your are right, Keith. Using EDIT or TEDIT is just a question of personal preferences, nothing else.

[Vijay Muralidharan]

On Saturday, May 25, 2013 9:01:46 AM UTC+5:30, Vijay Muralidharan wrote:
> Hi. I saw in some of the discussions that EDIT & TEDIT files are differentiated. Can anyone tell me wot is the difference.

@wbreidbach :

How to convert enscribe to edit file?

[Randall]

Simple command using EDIT to create "newfile" from many types of ENSCRIBE files.

EDIT newfile !;get enscrfil tl

[Keith Dick]

For someone not familiar with EDIT, we probably should add the exit command to the string:

EDIT newfile !;get enscrfil tl;e

Also, in the "t1" part, that is the number 1, not lowercase L, in case there is any confusion.

As long as the data in the Enscribe file is all ASCII characters (no binary numeric fields), and the amount of the data in the Enscribe file is small enough not to exceed any of the Edit file limits, that command should transfer the data properly from any type of Enscribe file (entry-sequenced, relative, or key-sequenced). If there are more than 100,000 records in the Enscribe file, the transfer attempt would reach the Edit line number limit, so in that case, it would help to specify a line number increment:

EDIT newfile !;get enscrfil t 1 by .01; e

If any of the records are longer than 239 characters after trimming trailing blanks, that will be too long for an Edit file. I don't remember whether that stops the transfer, skips the record, or truncates the record, but it definitely will not get all of the data into the Edit file.

If the Enscribe file does contain some binary fields, they will be interpreted as ASCII characters, and any non-printable characters will be dropped during the transfer, probably making data beyond that point in the records not line up nicely from one record to the next. That might not cause any problem, but I wanted to mention it in case it would be a problem.

[Doug Miller]

Keith Dick <kd...@acm.org> wrote in
news:z8OdncTv4LDrbjnM...@giganews.com:

> Randall wrote:
>> On Tuesday, May 28, 2013 12:29:59 PM UTC-4, Vijay Muralidharan
>> wrote:
>>
>>>On Saturday, May 25, 2013 9:01:46 AM UTC+5:30, Vijay
>>>Muralidharan wrote:
>>>
>>>
>>>>Hi. I saw in some of the discussions that EDIT & TEDIT files
>>>>are differentiated. Can anyone tell me wot is the difference.
>>>
>>>
>>>
>>>@wbreidbach :
>>>
>>>
>>>
>>>How to convert enscribe to edit file?
>>
>>
>> Simple command using EDIT to create "newfile" from many types
>> of ENSCRIBE files.
>>
>> EDIT newfile !;get enscrfil tl
>>
>
> For someone not familiar with EDIT, we probably should add the
> exit command to the string:
>
> EDIT newfile !;get enscrfil tl;e
>
> Also, in the "t1" part, that is the number 1, not lowercase L,
> in case there is any confusion.

Actually, it doesn't matter: since 'newfile' didn't exist prior
to the execution of that command -- and is therefore empty --
GET ... TF, GET ... T1, and GET ... TL are functionally equivalent

>
> As long as the data in the Enscribe file is all ASCII characters
> (no binary numeric fields), and the amount of the data in the
> Enscribe file is small enough not to exceed any of the Edit file
> limits, that command should transfer the data properly from any
> type of Enscribe file (entry-sequenced, relative, or
> key-sequenced). If there are more than 100,000 records in the
> Enscribe file, the transfer attempt would reach the Edit line
> number limit, so in that case, it would help to specify a line
> number increment:
>
> EDIT newfile !;get enscrfil t 1 by .01; e

Better still is ... BY .001

[Keith Dick]

Actually, I think not.

Using .01 allows for about 10,000,000 lines, which would only fit within the 128 MB file size limit if the average line length were under 10 bytes (remember the 4-byte line number on each line plus a little other overhead), so even that .01 increment provides for more line numbers than are likely to be usable.

The other reason is that if the line number increment is .001, subsequent editing of the file, at least by EDIT, would not permit inserting any lines until the file were renumbered to open up some gaps in the line numbers. Since .01 increment provides more than enough line numbers, I chose that over .001 increment.

[Doug Miller]

Keith Dick <kd...@acm.org> wrote in

news:AuWdncW5bp_zuTjM...@giganews.com:

> Doug Miller wrote:
>> Better still is ... BY .001
>
> Actually, I think not.
>
> Using .01 allows for about 10,000,000 lines, which would only
> fit within the 128 MB file size limit if the average line length
> were under 10 bytes (remember the 4-byte line number on each
> line plus a little other overhead), so even that .01 increment
> provides for more line numbers than are likely to be usable.
>
> The other reason is that if the line number increment is .001,
> subsequent editing of the file, at least by EDIT, would not
> permit inserting any lines until the file were renumbered to
> open up some gaps in the line numbers. Since .01 increment
> provides more than enough line numbers, I chose that over .001
> increment.
>

Good points, Keith.

[Randall]

Once converted, you can always renumber the file to whatever increment you like. .001 is gives you the biggest possible file, in case you don't know how many lines are incoming. Or use TEDIT, which auto-renumbers to open holes for you (within limits).

[Keith Dick]

As I think I demonstrated a couple of posts above, an increment of .01 gives you so close to the biggest possible file as the difference is unlikely to matter.

For helping someone who doesn't seem to understand very much about Edit files, the choice between suggesting to use .01 and not having to explain about renumbering (and .01 should provide enough line numbers for all but the most unusual file) vs. suggesting to use .001 and having to explain about renumbering seems obvious to me. All the pluses are on the side of suggesting .01 not the other. You may see it otherwise, and you are free to suggest whatever you like. If the original poster is still following the discussion, we've probably already confused him as much as we could, so it probably doesn't matter any more what we say.

[wbreidbach]

As Randall already wrote this can be done using EDIT. Many years ago I created a very small program converting ENSCRIBE file to EDIT files replacing any hex 0 by a blank. It is so old, it es still using SIO procedures. If somone is interested in the source code, just drop me a mail.

[Narayan Shrawagi]

Hi,
I am new to TANDEM Can you please describe the syntax used above ? I am not getting why !; is used here and how get is used inside EDIT and what does tl means?

[Tom P]

The "!" forces EDIT to create or edit the file called newfile regardless
whether it exists or not. The semicolon simply separates multiple
commands on the same line. "Get" says open the file and read it. The tl
is an abbreviation for "to last line", if my memory is correct.

[Tom P]

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02129140/c02129140.pdf