TRUNCATION OCCURRING
Suresh
I am trying to edit the enscribe file. So I tried to copy the file
content from entry sequenced to unstructured file. But, Fup doesnot
allow me to copy full size record length(450). I am getting truncation
warning. Please give me the solution to overcome this.
Thanks in advance,
Suresh.
Keith Dick
Doug Miller
> I am trying to edit the enscribe file. So I tried to copy the file
>content from entry sequenced to unstructured file. But, Fup doesnot
>allow me to copy full size record length(450). I am getting truncation
>warning. Please give me the solution to overcome this.
http://www.lmgtfy.com/?q=%22truncation+occurring%22+site%3Adocs.hp.com
Or simply RTFM (Read The FUP Manual, of course).
MicroTech
The only way to "edit" an Enscribe (ES) file with a record size
exceeding 256 bytes, is to write a program to do the job.
If your file had a record size of < 256 bytes (I think that is the max
EDIT file record length, look it up!), AND if the records contain only
ASCII printable characters, then you could have used the "get-put"
EDIT/VS feature: At the EDIT/VS prompt, enter:
GET <filename> PUT <new edit file name> !
Do whatever edits you need, and exit EDIT/VS, then in FUP:
COPY <new edit file name>, <new (empty!) enscribe (ES) file name>
But in your case, as have been suggested already, most important of
all READ THE F(UP) MANUAL!
Good Luck!
Henry Norman
MicroTech Consulting
http://groups.google.com/group/MicroTech_Software
Suresh
Thank you all
I could not copy file from unstructured enscribe to editable
enscribe , though I tried with fup copy recin, blockin, recout and
blockout option. since the record length of file is nearly 450 bytes.
It allows only upto 239 bytes. I will try to edit through program.
wbreidbach
The maximum record length of both EDIT and TEDIT is 239. This limit
originates from the very specific structure of type 101 files. What
you can do is:
copy the enscribe file info an oddunstructured file appending %H10 to
each record. Afterwards you can use to CTOEDIT program to convert it
to an EDIT file. But you should be aware that all data starting at
position 240 and beyond is lost!
How to copy the data either use the help function of FUP or the
manual, it is really easy.
Another problem might occur if your enscribe file contains non-
printable characters. If this is the case, forget about EDIT or TEDIT.
Another chance would be to create a sql table of the same structure as
the enscribe file, this would allow you to use SQLCI to change the
contents.
A while ago I offered our BROWSER to the community, a tool for viewing
every NonStop file in full-screen mode. There is an EDIT-version of
this tool, which is able to to an EDIT on every file except SQL-
tables. This tool has the state "unsupported" and has never been
finally tested, so we highly recommend to backup the file before
trying to change it. I would be able to support you with a trial
version, but this would take a while because I will be on holidays in
a few hours.
Wolfgang
Keith Dick
>
> Thank you all
>
> I could not copy file from unstructured enscribe to editable
> enscribe , though I tried with fup copy recin, blockin, recout and
> blockout option. since the record length of file is nearly 450 bytes.
> It allows only upto 239 bytes. I will try to edit through program.
If this really is a redescription of your earlier post, sorry, I was in a hurry and must not havet read your first post carefully enough, though your earlier post said you were trying to copy from entry-sequenced to unstructured, not unstructured to Edit. It really helps those of us trying to answer questions if you give a complete description of your problem in the first post. We aren't mind readers.
Without knowing more about the data in the files and what kind of editing needs to be done, it is hard to say what the best way to do it would be.
There is an old product named ENABLE that can generate a PATHWAY program that provides view, insert, update, and delete functions for Enscribe files. You might not have it in your system, since I believe it was not a standard product, but one that you had to pay extra for. I know it worked with key-sequenced files. I imagine it worked for entry-sequenced and relative files (though it probably did not allow delete from entry-sequenced files). I see the document index still has an ENABLE reference manual and an ENABLE user's guide, so perhaps the product is still available.
There also was a program named DBACCESS which wasn't officially supported, but did find its way to some customer sites. It didn't require PATHWAY to operate, so it was simpler to get working.
Both programs required an Enscribe DDL description of the record in the file, and I believe only worked well if all the records had the same layout.
If you can find either of those programs, it might save you time creating your own program.
If the editing job is simple, writing your own program might be quicker.
There might be third-party programs available that do something similar to ENABLE or DBACCESS, but I don't know what is available.
You might copy the entry-sequenced file into an entry-sequenced SQL table, then use SQLCI UPDATE commands to do the editing with appropriate WHERE clauses to pick out just the records you want to change, then copy from the SQL table back to an entry-sequenced file. Or use a PC application that can update SQL tables using ODBC access to update the SQL table.
Another approach could be to write a program that copies your 450-byte file to an OSS text file, then use vi to do the editing, then copy it back to an entry-sequenced file. I assume vi can handle 450-byte lines. I don't have any experience using it with such long lines. A very simple C program should be able to do the copying job. Use FILE_OPEN_ and READX to read the entry-sequenced file and normal C I/O to write the OSS file. To copy back, use C I/O to read the file and FILE_OPEN_ and WRITEX to write the entry-sequenced file. This assumes the file contains only character data, no binary fields.
Still another approach could be to write a program to copy the entry-sequenced file to an Edit file, but split the records roughly in half, at some convenient field boundary, so neither part is longer than 239 characters. Or even divide the records into three or more lines, depending on what seems suitable. Then you could edit with the editor, then copy from the Edit file back to the entry-sequenced file by combining the appropriate sets of lines into one output record. The copy from entry-sequenced to Edit could, I think, be done with FUP COPY using the appropriate RECOUT length and the FOLD option if the line size in the Edit file could be the same for each portion of the record, but I don't believe you could use FUP COPY to combine multiple Edit lines into one output record. Again, this approach requires that the record contain only character data, no binary fields. It might be a little awkward to edit the file when the records are divided into two or more lines, but
maybe that would be acceptable in your situation.
Doug Miller
>Still another approach could be to write a program to copy the entry-sequenced
> file to an Edit file, but split the records roughly in half, at some
> convenient field boundary, so neither part is longer than 239 characters. Or
> even divide the records into three or more lines, depending on what seems
> suitable. Then you could edit with the editor, then copy from the Edit file
> back to the entry-sequenced file by combining the appropriate sets of lines
> into one output record. The copy from entry-sequenced to Edit could, I think,
> be done with FUP COPY using the appropriate RECOUT length and the FOLD option
> if the line size in the Edit file could be the same for each portion of the
> record, but I don't believe you could use FUP COPY to combine multiple Edit
> lines into one output record. Again, this approach requires that the record
> contain only character data, no binary fields. It might be a little awkward
> to edit the file when the records are divided into two or more lines, but
> maybe that would be acceptable in your situation.
Yeeesh. Before doing that, I think I'd try doing the fixup with a TACL
routine. Open the file with #REQUESTER READ, retrieve one line at a time into
a STRUCT variable, make the necessary changes with VCHANGE, and write the
updated record to the new file. TACL STRUCTs support binary data, too.
Gerhard Huff
"Doug Miller" <spam...@milmac.com> schrieb im Newsbeitrag
news:Haq3m.2225$Wj7....@nlpi065.nbdc.sbc.com...
Hi all,
here is another, fairly unusual approach, which I just verified: Use FTP and
Notepad on Windows.
Assuming all (!) your data is in Ascii and the file is not too large (< 59
MB?) this will work.
I am using a small FTP Gui called "WS_FTP LE" (see
http://download.cnet.com/WS-FTP-LE/3000-2160_4-1572132.html)
which has an option for "Host type TANDEM"; using that type and "Transfer
Mode ASCII", you are able to
either do a direct "Edit" function on the file or transfer the file to the
PC, edit it and send it back. FTP_LE will use Notpad.exe
per default, but you can direct it to your favorite PC editor instead.
I just did such an Edit session, using an entry-seq and a key-seq file with
rec len 450. It does also work
if your lines are variable in length (not all of them exactly 450 chars). I
am not sure what happens if there
are any non-ascii (non-printable) chars in the file..
It does not work with FTPC32 (Tandems version of an FTP GUI) since that
refuses to
write into a structured Enscribe file.
I also tried the VI approach, but vi (under OSS) relies on some <NL>
characters
within the file to see the line ends; that may not be a problem if all your
lines are 450...
Regards,
Gerhard
PS: I could offer a copy of DBACCESS if you are interested.
Keith Dick
>
> Hi all,
>
> here is another, fairly unusual approach, which I just verified: Use FTP and
> Notepad on Windows.
> Assuming all (!) your data is in Ascii and the file is not too large (< 59
> MB?) this will work.
>
> I am using a small FTP Gui called "WS_FTP LE" (see
> http://download.cnet.com/WS-FTP-LE/3000-2160_4-1572132.html)
> which has an option for "Host type TANDEM"; using that type and "Transfer
> Mode ASCII", you are able to
> either do a direct "Edit" function on the file or transfer the file to the
> PC, edit it and send it back. FTP_LE will use Notpad.exe
> per default, but you can direct it to your favorite PC editor instead.
>
> I just did such an Edit session, using an entry-seq and a key-seq file with
> rec len 450. It does also work
> if your lines are variable in length (not all of them exactly 450 chars). I
> am not sure what happens if there
> are any non-ascii (non-printable) chars in the file..
I wasn't aware of this program. Thanks for mentioning it. Do you know any details of how it goes about arranging to do an update of the file on the Tandem system through the FTP protocol? I didn't have any idea that was possible.
>
> It does not work with FTPC32 (Tandems version of an FTP GUI) since that
> refuses to
> write into a structured Enscribe file.
>
> I also tried the VI approach, but vi (under OSS) relies on some <NL>
> characters
> within the file to see the line ends; that may not be a problem if all your
> lines are 450...
Did you try to get vi to open the entry-sequenced file directly, or did you copy the entry-sequenced file into an OSS text file, then try to use vi on the OSS text file? I believe the latter would work, unless vi has trouble with lines that are 450 characters long. I would not expect vi to work if you ask it to open the entry-sequenced file directly.
Gerhard Huff
"Keith Dick" <Keit...@earthlink.net> schrieb im Newsbeitrag
news:t5adnbo3ybQN-tPX...@giganews.com...
============================
>
> I wasn't aware of this program. Thanks for mentioning it. Do you know
> any details of how it goes about arranging to do an update of the file on
> the Tandem system through the FTP protocol? I didn't have any idea that
> was possible.
I do not "know" for sure, but I assume the Gui uses the regular Tandem
FTP Server ($system.ztcpip.ftpserv), which seems to be aware of
Enscribe structured files. At least, the standard FTP PUT command has some
extension to control file attributes, especially Extent Size and Max
extents.
The manual decribes these extenstions like this:
---------------
The syntax for transferring ASCII or binary files is:
put local-file [ remote-file ] [ ,attribute-list ]
where attribute-list is:
[ [filecode],[primary],[secondary],[maxextents] ]
The syntax for transferring structured files is:
put local-file [ remote-file ] [ ,attribute-list ]
where attribute-list is:
[[filetype],[filecode],[primary],[secondary],[maxextents],
[record-len],[pri-key-len],[key-offset],[index-blk-len ]]
---------------
You can use such a PUT even from the Windows "cmd" box and its
ftp client (which has no clue on NSK). The syntax is kind of awfull
since it does not allow "spaces" around the commas in the command.
The "Tandem Awarness" of the Gui seems to be in the correct way to display
the file names found; without "HostType Tandem" it shows you the security
strings ("AONO") as the names. It is for sure not able to use the Extent
size
options since it fails after 59 MB on upload.
However, you can transfer larger files if you connect with an OSS "alias"
user (or specify OSS as a connection-time option) and then switch
from your OSS directory to the Guardian name space /G/vol/subvol.
In other words, if the Gui asks for an Ascii-Mode transfer, FTPSERV
does the NSK File IO and handles the Padding and Trimming of newline
characters. That way, variable-length records get preserved. On a upload,
write operation, the NSK file gets overwritten completely.
The link to WS-FTP LE from yesterday talks about version 5.08 (and 6.0),
but I was not able to actually do a download; they always point you to
the commercial PRO version. I found version 6.0 at:
http://www.snapfiles.com/download/dlwsftple.html
===========================
> Did you try to get vi to open the entry-sequenced file directly, or did
> you copy the entry-sequenced file into an OSS text file, then try to use
> vi on the OSS text file? I believe the latter would work, unless vi has
> trouble with lines that are 450 characters long. I would not expect vi to
> work if you ask it to open the entry-sequenced file directly.
vi and other OSS tools like "more" and "cat" are unable to read an
entry-seq file directly; vi reports error 4022, which is:
$data01 ghuff 1> error 4022
4022 [EINVAL] Invalid function argument.
As you pointed out, you need to copy it to a Code 180 file, like this;
FUP
-create c180, code 180, oddunstr, ext 1000
CREATED - $DATA01.GHUFF.X180
-copy eseq, c180, recin 450, recout 450
5 RECORDS TRANSFERRED
You can then use c180 with VI, but it will not be aware of any
records or record length and shows you a blob of data; if any
of your records are shorter, that information is lost. You could
address that with the copy options PAD and TRIM, but then
you need to find a character which is not the trailing char on
any of your lines.
In fact (I just tested that), if vi does not see a <NL> for 2048
characters, it does not like the file; instead it gets this error:
"c180" A line cannot be longer than 2048 characters.
I think that is standard vi behavior.
Regards
Gerhard
Dave
>
>SNIP
>
Do you know any details of how it goes about arranging to do an
update of the file on the Tandem system through the FTP protocol? I
didn't have any idea that was possible.
>
> > It does not work with FTPC32 (Tandems version of an FTP GUI) since that
> > refuses to
> > write into a structured Enscribe file.
>
>
All of the FTP clients use the same server on the Tandem FTPSERV. I
think FTP32 detects the logon type and issues the QUOTE GUARDIAN
command to the server automatically if a Guardian logon is used (i.e
Initial-Directory not OSS).
Keith Dick
My question wasn't completely clear. I was aware of the extensions in the Tandem FTP server for allowing specification of various parameters for Enscribe files. The thing you mentioned that I was not aware of is the ability to do a direct edit of the file. I assumed that "direct edit" means the ability to update a record in the Enscribe file. The FTP server extensions I know about only provide a way to transfer a whole file, not update a record within an existing file. Did I misinterpret what you said? If "direct Edit" means something like transferring the whole Enscribe file to a text file on the PC, editing the copy on the PC with a PC-based text editor, then transferring the whole file back to the Tandem host, then that isn't much of a trick. But if "direct Edit" does mean updating a record within the Enscribe file, I'm interested in how that is done through the FTP server.
>
> The "Tandem Awarness" of the Gui seems to be in the correct way to display
> the file names found; without "HostType Tandem" it shows you the security
> strings ("AONO") as the names. It is for sure not able to use the Extent
> size
> options since it fails after 59 MB on upload.
This surprises me a little. I assumed that the FTP protocol had the server formatting the lines to respond to an ls or dir command, sending them to the client, and the client simply writes them to its output file. From what you've seen, I guess it doesn't work that way. I guess I should take some time to look up the FTP protocol description and see what it says.
I did not suggest copying to a code 180 file *with FUP*. I knew that wouldn't put the newline character into the file. What I suggested was writing a simple copy program that reads the Enscribe file with FILE_OPEN_ and READX, and writes the C file with fopen and fputs, or something like that. Something that results in newline characters being inserted between each of the lines written to the C file. Then I suppose vi could be used to edit it. Then another simple copy program that reads the file with fopen and fgets and writes the Enscribe file with FILE_OPEN_ and WRITEX would turn the C file back into an Enscribe file. Each of those copy programs would be very short and easy to write.
I didn't know how vi would deal with long lines, and you answered that: up to 2048 characters should work. It might be a bit awkward finding the right place to make changes with very long records, but it seems that it is at least potentially possible to edit it with vi. I think I wouldn't want to rely on it as a regular method of updating the data, but for a quick fix in a pinch, it might be workable.
I didn't think of it at the time, but if one is sure that the Enscribe file has fixed length records, one could use FUP COPY to copy to a code 180 file and insert a newline something like this:
create c180, code 180, oddunstr, ext 1000
copy eseq, c180, recin 450, recout 451, pad 10
(The newline character has the character code 10, I think.) Copying back to the Enscribe file could be done specifying recin 451 and recout 450. The default is to truncate, so the extra input character would be discarded.
Of course, I wouldn't recommend any of this if the file contains any binary fields.