Tedit file limitations. 9,999,999
pku...@fnb.co.za
I was looking at aan earlier post made by Jim Kelly that appeared to
have a solution to my problem, unfortunately the e-mail is no longer
vaild.
Maybe someone else can help. Once a week I run a full backup on a
Tandem S series machine writting onto 3 x 400GIG tapes. Problems is
that the Tedit files reaches a max number of lines just a under a
million and the backup falls over. One solution was creating a enscibe
file, but this seems to be problematic writting to the SQL backup
database. Any other ideas would be much appreciated. Maybe if the file
can flow over into another file?
Any assitance will be appreciated,
Philip
pku...@fnb.co.za
Doug Miller
>Hi;
>
>I was looking at aan earlier post made by Jim Kelly that appeared to
>have a solution to my problem, unfortunately the e-mail is no longer
>vaild.
>
>Maybe someone else can help. Once a week I run a full backup on a
>Tandem S series machine writting onto 3 x 400GIG tapes. Problems is
>that the Tedit files reaches a max number of lines just a under a
>million and the backup falls over.
It's not immediately clear to me what TEdit files you're referring to, so I'm
going to assume that you're directing the output listing from the backup to a
TEdit file, and it overflows the maximum line number permitted -- which is, of
course, one reason that an Edit file isn't a good choice of file structure for
logging purposes.
Is there some reason you can't/don't send the output to a spooler job instead?
>One solution was creating a enscibe
>file, but this seems to be problematic writting to the SQL backup
>database.
By "SQL backup database" do you mean the DSM/TC media catalog? If so, please
describe what problems you encounter.
> Any other ideas would be much appreciated. Maybe if the file
>can flow over into another file?
Not in any way that I know of. Why not just use a spooler job?
Keith Dick
Assuming your spooler is running and has the capacity to hold your listing, Doug's suggestion seems quite reasonable to me. If, for some reason, you absolutely have to have the output in an Edit file, you can get PERUSE to convert the contents of a spooler job to an Edit file. If the spooler job is too long for one Edit file, you could extract the listing into several Edit files by giving page number ranges on the LIST command. The command you could use is something like:
LIST EDIT /OUT <edit filename>/ <first page>/<last page>
I do not understand what problem you are referring to about using an enscribe file causing trouble writing to the SQL backup database. I could make a lot of guesses, but that would probably be wasted time.
I cannot recall whether BACKUP follows the old rules that make it possible to have it write its OUT file to an unstructured disk file (NOT Edit file) or an entry-sequenced enscribe file. A quick look at the manual doesn't give an answer -- the answer might be somewhere where I did not look. If it does follow the old rules, you can create an unstructured or entry-sequenced file and specify it as the OUT file. Under the old rules, BACKUP would write 132-byte records to the file (so you should make the record length of an entry-sequenced file be 132). It is possible to convert both unstructured and entry-sequenced files to Edit files, using the EDIT program. It might be possible with TEDIT, but I never tried doing it with TEDIT.
It might be that BACKUP no longer supports this ability to write to unstructured or entry-sequenced files. Sometimes, the programmers who added the capability to write to Edit files to the utility programs short-sightedly elmininated the ability to write to the other kinds of files. As I said, I couldn't tell in a quick look at the BACKUP manual.
If you must have the output of the BACKUP directly to an Edit file (not using some intermediary file then converting), you could write a pretty simple program that you run as a named process and specify that process name as the OUT file for BACKUP. This program would read from $RECEIVE, write to an Edit file, and count lines so as to know when to switch to a fresh Edit file to avoid exceeding the line number limit. The program could also use the Edit-writing interface that allows you to specify the line number increment in the Edit file. If the program set the line number increment to .001, that would allow many more lines in a single Edit file, if it were important to keep the listing to one Edit file. I think the Edit file is limited to 2 GB in total size, so you'd probably run into that limit before you ran out of line numbers.
If none of those suggestions are suitable, please explain your problem and constraints in more detail, especially what you mean about using an enscribe file causing trouble writing to the SQL backup database.
pku...@fnb.co.za
Hi Doug;
Thanks for your response. Yes I am reffering to DSM/TC. The bacvkup
routines were written on a "K" series long ago by a programmer, and I
inheritted all these configs. The only reson I ever used the Tedit
file for was to check if files written to tape, and if the backup
completed succesfully. MC kept record where files were for restore.
I'm not very familiar with the code to be honest, so I'm trying
diffirent things in the code but haven't found a solution as yet. I
will paste in the config that actually creates the file.
[#DEF CREATE_EDIT_FILE_ ROUTINE |BODY|
#FRAME
[#PUSH
ARG_
FILENAME_
RESULT_
ERROR_
WRITE_ERROR_
WRITE_DATA_
WRITE_DATA_
]
#SET RESULT_ 0
#SET ERROR_ 0
[#IF [#ARGUMENT /VALUE ARG_/ FILENAME /SYNTAX/] |THEN|
#SET FILENAME_ [#SHIFTSTRING /UP/ [ARG_]]
]
[#IF [#FILEINFO /EXISTENCE/ [FILENAME_]] |THEN|
#SET ERROR_ 0
#PUSH TEMP_FILENAME_ TEMP_NUM_ DOT_ DONE_
== #SET ERROR_ [#PURGE [FILENAME_]]
#SET TEMP_NUM_ 1
#SET DONE_ 0
#SET TEMP_FILENAME_ [FILENAME_]
#SET DOT_ [#CHARFINDR TEMP_FILENAME_ [#CHARCOUNT
TEMP_FILENAME_] .]
#SET DOT_ [#COMPUTE [DOT_]+2]
#CHARDEL TEMP_FILENAME_ [DOT_]
#CHARINS TEMP_FILENAME_ [DOT_] [TEMP_NUM_]
#CHARINS TEMP_FILENAME_ [DOT_] [TEMP_NUM_]
[#LOOP |DO|
#SET ERROR_ [#RENAME [FILENAME_] [TEMP_FILENAME_]]
[#CASE [ERROR_]
| 0 | #OUTPUT RENAME operation successful
#SET DONE_ -1
| 10 | #SET TEMP_NUM_ [#COMPUTE [TEMP_NUM_] + 1]
#CHARDEL TEMP_FILENAME_ [DOT_]
#CHARINS TEMP_FILENAME_ [DOT_]
[TEMP_NUM_]
#SET ERROR_ 0
| OTHERWISE | #OUTPUT RENAME ERROR [ERROR_], ON
[FILENAME_]
#RESULT [RESULT_]
#RETURN
]
|UNTIL| [DONE_] OR [ERROR_] OR ([#COMPUTE [TEMP_NUM_] > 9])
]
[#IF [#COMPUTE [TEMP_NUM_] > 9] |THEN|
#OUTPUT Maximum number of BACKUP runs would be
exeeded...stoping here
#RESULT [RESULT_]
#RETURN
]
pku...@fnb.co.za
>
> - Show quoted text -
Hi Keith,
Thanks for replying. I'm pasting in my response to Doug.
Keith Dick
pku...@fnb.co.za
>
> - Show quoted text -
Hi;
You are right, left some of the code out.
]
]
#SET ERROR_ [#REQUESTER /WAIT/ WRITE [FILENAME_] WRITE_ERROR_
WRITE_DATA_]
== TESTING FUP CREATE
== FUP CREATE [FILENAME_],EXT (100,100)
[#IF [ERROR_] |THEN|
#OUTPUT
#OUTPUT UNABLE TO CREATE EDIT FILE: [FILENAME_], ERROR :
[ERROR_]
#OUTPUT
#RESULT [RESULT_]
#RETURN
]
#APPEND WRITE_DATA_
***********************************************************
#APPEND WRITE_DATA_ *
#APPEND WRITE_DATA_ * FNB BACKUP OUTPUT
#APPEND WRITE_DATA_ *
#APPEND WRITE_DATA_
***********************************************************
SINK [#REQUESTER /WAIT/ CLOSE WRITE_DATA_]
[#IF [#FILEINFO /EXISTENCE/ [FILENAME_]] |THEN|
#SET RESULT_ -1
#PUSH SEC_STRING_
#SET RESULT_ -1
#PUSH SEC_STRING_
#SET SEC_STRING_ [#FILEINFO /SECURITY/ [FILENAME_]]
#CHARDEL SEC_STRING_ 1 TO 4
#CHARDEL SEC_STRING_ 2
[#IF "[SEC_STRING_]" '<>' "C" |THEN|
FUP SECURE [FILENAME_], "NONC"
]
]
#RESULT [RESULT_]
#UNFRAME
]
Doug Miller
>On Jun 10, 1:06=A0pm, Keith Dick <kdic...@comcast.net> wrote:
>> pku...@fnb.co.za wrote:
>> > On Jun 9, 3:07 pm, spamb...@milmac.com (Doug Miller) wrote:
>>
>ps.com>, pku...@fnb.co.za wrote:
>>
>> >>>Hi;
>>
>> >>>I was looking at aan earlier post made by Jim Kelly that appeared to
>> >>>have a solution to my problem, unfortunately the e-mail is no longer
>> >>>vaild.
>>
>> >>>Maybe someone else can help. Once a week I run a full backup on a
>> >>>Tandem S series machine writting onto 3 x 400GIG tapes. Problems is
>> >>>that the Tedit files reaches a max number of lines just a under a
>> >>>million and the backup falls over.
>>
>> >>It's not immediately clear to me what TEdit files you're referring to, so I'm
>> >>going to assume that you're directing the output listing from the backup to a
>> >>TEdit file, and it overflows the maximum line number permitted -- which is, of
>> >>course, one reason that an Edit file isn't a good choice of file structure for
>> >>logging purposes.
>>
>> >>Is there some reason you can't/don't send the output to a spooler job instead?
I notice you didn't answer this question, so I'm going to ask it again: is
there some reason you can't, or don't, send the output to a spooler job
instead?
>>
>> >>>One solution was creating a enscibe
>> >>>file, but this seems to be problematic writting to the SQL backup
>> >>>database.
>>
>> >>By "SQL backup database" do you mean the DSM/TC media catalog? If so, please
>> >>describe what problems you encounter.
>>
>> >>>Any other ideas would be much appreciated. Maybe if the file
>> >>>can flow over into another file?
>>
>> >>Not in any way that I know of. Why not just use a spooler job?
Repeat: why not just use a spooler job?
>>
>> > Hi Doug;
>>
>> > Thanks for your response. Yes I am reffering to DSM/TC.
OK, so -- for the second time -- please describe the problems you encounter
trying to use an Enscribe file.
>> > The bacvkup
>> > routines were written on a "K" series long ago by a programmer, and I
>> > inheritted all these configs. The only reson I ever used the Tedit
>> > file for was to check if files written to tape, and if the backup
>> > completed succesfully.
You don't need to use an edit-file to do this -- *any* type of output file
that you can read later is sufficient. A spooler job would be the best. Why
not send the output to the spooler?
>> > MC kept record where files were for restore.
>> > I'm not very familiar with the code to be honest, so I'm trying
>> > diffirent things in the code but haven't found a solution as yet. I
>> > will paste in the config that actually creates the file.
[TACL routines snipped]
I think you're missing the point here. The issue is not in any way related to
how you're creating the edit file, or what you're naming it -- the issue is
that you're trying to use an edit file at all. Don't do that. It's not
well-suited to this purpose. A spooler job is *ideal*. Why are you not sending
BACKUP's output to the spooler?
Gerhard Huff
<pku...@fnb.co.za> schrieb im Newsbeitrag
news:32f83b33-9b48-4dd4...@e21g2000yqb.googlegroups.com...
Hi Philip,
if your are using the edit file only to check the outcome
of BACKUP, a simple solution would be to remove the "LISTALL"
option from the BACKUP runtime command. In that case, there
will be no lines for any good files, but only for files
that have problems, (and some overall statitics in the end;
see me example below). It should be possible to find the
call to BACKUP in your Tacl Macro(s) and remove the LISTALL
option. It will not affect the records inserted in the DSM/TC
Database.
==========================================
$data01 hugtmp 10> pak myfiles ghuff.*
PAK - File compression program - T1255G06 - (2006-11-29)
File Mode BACKUP Program - T9074G08 (23NOV2006) (AFK)
(C)2000 Compaq (C)2006 Hewlett Packard Development Company, L.P.
Drives: (\CS2.$Z2MY)
System: \CS2 Operating System: G06 Tape Version: 3
Backup options: NO AUDITED, BLOCKSIZE 8, NO IGNORE, NO OPEN, PARTONLY OFF,
INDEXES IMPLICIT
*WARNING-7147* Files created and stored via OSS and SQL/MX objects are not
supported.
*WARNING-7033* This tape can only be restored with TNS/II RESTORE (B41, C00
or
later).
Backup time: 10Jun2009 17:52 Page:
1
Tape: 1 Code EOF Last modif Owner RWEP Type Rec
Bl
$DATA01.GHUFF
TEMP *ERROR-3048* File aborted (Read error 48).
Summary Information
Disk related warnings = 0 Disk related errors = 1
Files dumped = 12 Files not dumped = 1
Total bytes: 2705328
Compressed bytes: 869202
$data01 hugtmp 11>
-----------------------------------------
The two last lines are from PAK, and will not get that with
BACKUP only. But you can always check for:
Disk related warnings = 0 Disk related errors = 1
Files dumped = 12 Files not dumped = 1
==========================================
Besides that, BACKUP still supports Edit- and Entry-Seq Files
as OUT files for its listing. Thus using an E-Seq file as
a temporary OUT file would work (make it large enough to hold
enough records). If you then still need an Edit-File, a simple
way to convert it to Edit format is SQLCI (if you got that).
Doing SQLCI COPY, you can produce an Edit file; e.g.:
SQLCI
>>COPY <entry-seq>, <edit-file>;
Unlike other tools, especially BACKUP, SQLCI will number
the EDIT lines by 0.001; in other words you get line numbers
like this:
0.001 >>fileinfo *;
0.002 CODE EOF LAST MODIF OWNER RWEP
TYPE REC BL
0.003 $DATA01.HUGTMP
0.004 MYFILES 1729 869204 17:56 5,2 OOOO
0.005 SQLCIOUT O 101 0 18:10 5,2 OOOO
0.006 >>exit
0.007
0.008 End of SQLCI Session
Using such in increment (and SQLCI or TEDIT) you can store more
than 100,000 records into an EDIT Files. BACKUP number its files
1,2,3,4 and hits 99999 eventually.
Alternatively, if you have the old Tandem tool LOCATE, you could directly
seach in the E-Seq file for things like "dumped =" or "*Error" etc.
For Edit Line numbers, I remember that the maximin LINE Number
is 99999 or more precisely 99999.999; that is not the same as
"Number of Lines" in the file. With smaller increments you can
have way more lines. However, the original EDIT and
EDIT/VS were unable to handle files with more than 100,000
lines due to internal limits (and API used).
More recent tools like TEDIT and SQLCI can deal with more than
100,000 lines but cannot exceed the max line number 99999.999
Regards
Gerhard
Keith Dick
>
> I think you're missing the point here. The issue is not in any way related to
> how you're creating the edit file, or what you're naming it -- the issue is
> that you're trying to use an edit file at all. Don't do that. It's not
> well-suited to this purpose. A spooler job is *ideal*. Why are you not sending
> BACKUP's output to the spooler?
I'm not sure, but I have a feeling that the system he is working with includes some programs that read the Edit file to see the result of the backup, hence he may not be able to just switch to the spooler, since then the other programs wouldn't see the listing they need to read.
This is only a guess. It would help if the original poster said what the constraints are.
Doug Miller
>Doug Miller wrote:
>>
>> I think you're missing the point here. The issue is not in any way related to
>
>> how you're creating the edit file, or what you're naming it -- the issue is
>> that you're trying to use an edit file at all. Don't do that. It's not
>> well-suited to this purpose. A spooler job is *ideal*. Why are you not
> sending
>> BACKUP's output to the spooler?
>
>I'm not sure, but I have a feeling that the system he is working with includes
> some programs that read the Edit file to see the result of the backup, hence
> he may not be able to just switch to the spooler, since then the other
> programs wouldn't see the listing they need to read.
Even so, it's not rocket science to find the job in the spooler, and read it
there...
>
>This is only a guess. It would help if the original poster said what the
> constraints are.
Indeed.
Phil
> <pku...@fnb.co.za> schrieb im Newsbeitragnews:32f83b33-9b48-4dd4...@e21g2000yqb.googlegroups.com...
>
> - Show quoted text -
Hi Gerhard;
Thank you very much, removing the unrequired "Listall" cut down the
lines in the TEDIT file to such an extent that I don't think I will
run into the limit anytime soon. Once again, thank tou.
Philip
Phil
Hi Doug;
Thank you for the advice and taking the time to respond. Someone
suggested removing the "Listall" from the command. Listall is not
required and never used, and indeed made up over 80% of the TEDIT file
lines. Your suggestions are deifnately noted and will be considered in
the future.
Thanks
Philip
Phil
>
> - Show quoted text -
Hi Keith;