Operating System - OpenVMS
1830247 Members
2309 Online
110000 Solutions
New Discussion

EDIT/FDL parameter conflict

 
SOLVED
Go to solution
Jan van den Ende
Honored Contributor

EDIT/FDL parameter conflict

I'm still trying to get used, I entered my question in OPENVMS.ORG - Bug reports:

http://www.openvms.org/phorum/read.php?f=5&i=268&t=268

but actually I guess my chances are a bit better here.

Sorry for any inconvenience.

Jan.
Don't rust yours pelled jacker to fine doll missed aches.
8 REPLIES 8
Zahid Ghani
Frequent Advisor

Re: EDIT/FDL parameter conflict

Its a while since I played with RMs files but the script I used to run was someting like this:
$SET DEF DSA3601:[TEMP]
$!
$EDIT :==
$!
$ANALYZE/RMS/FDL/OUTPUT=xx.FDL xx.FIL
$!
$EDIT/FDL/NOINTERACTIVE/EMPHASIS=FLATTER/ANALYSIS=xx.FDL xx.FDL
$!
$CONVERT/FDL=xx.FDL xx.FIL xx.FIL

hope this helps...

Re: EDIT/FDL parameter conflict

Calling EDIT/FDL with /NOINTERACTIVE starts an optimization, so you can omit the /SCRIPT=OPTIMIZE.

Good luck
Juerg
Ian Miller.
Honored Contributor

Re: EDIT/FDL parameter conflict

the use of the SCRIPT qualifier and /NOINTERACTIVE conflict as
/SCRIPT=script-title

This qualifier controls whether the Edit/FDL utility begins the
session by asking a logically grouped sequence of questions to
aid you in creating the FDL file.
i.e implies /SCRIPT is for interactive use.
____________________
Purely Personal Opinion
Antoniov.
Honored Contributor

Re: EDIT/FDL parameter conflict

Jan,
reading help seems you have create FDL before use /NOINTERACTIVE

Bye
Antoniov
Antonio Maria Vigliotti
Hein van den Heuvel
Honored Contributor
Solution

Re: EDIT/FDL parameter conflict

Ha die Jan,

from the openvms.org entry...

> Optimizing RMS performance should be done regularly, especially for bigger multi-indexed files having duplicate keys, even more if records are frequently deleted.
> Do this by ANAL/RMS/output=.. for the file.

Nitpicking... It is actually the CONVERT that does the optimize. Those large files tend to converge to a static optimized state, or a predictable growth. The ANAL/RMS becomes a waste of time. Just use output from an old one and tweak the record count!

> After that. EDIT/FDL can use the analysis with the OPTIMIZE script to generate a new xx.FDL file, which can be used to CONVERT the data file to an optimized version of it.

Great advice in general, but again for those large files it will be relatively easy to do better than EDIT/FDL, using a prior optimized FDL as basis. For those large files, which supposedly have a larger impact on over system recource usage/performance it is probably worth it to spend an hour reviewing the FDL, the usage expectation, and feeding some data into a spreadsheet (vms freeware, rms tools) or into an interactive edit/fdl session. Make your best guess, and do NOT allow edit/fdl/nointer to make a near-blind-folded decision.


groetjes,
Hein.
John Gillings
Honored Contributor

Re: EDIT/FDL parameter conflict

general comment/rant

Using EDIT/FDL/SCRIPT=OPTIMIZE is actually a misnomer! It's not possible to "optimize" a file automatically, since the system has no idea what aspect of the file you want to optimize for. Do you want to optimize for disk space?, fast lookups? fast insertions? Are there many inserts and deletes? Just inserts? are they ordered or random?

By definition, you can't optimize for *everything*. Optimizing *means* sacrificing some things to benefit other things. SCRIPT=OPTIMIZE "normalizes" everything, so there are no biases. It tries to compromise all the possible axes of performance. So, in some senses, it's really the exact reverse of "optimize".

For a well behaved file, decide what you really care about and work out a good FDL that optimizes the file in that direction(perhaps starting with the output of an EDIT/FDL *INTERACTIVE* session!) Use it for your regular CONVERTs. Forget trying to generate a new FDL every time. Your CONVERT scripts will be much simpler, and you'll me more likely to *really* optimize your files, rather than dragging them back into the middle of all roads.
A crucible of informative mistakes
Jan van den Ende
Honored Contributor

Re: EDIT/FDL parameter conflict

Thnks, all of hou.

Zahid, Juerg: That does indeed give decent results

Ian: Well, eighter HELP is unclear or I was not able to distill your explanation (which obviously is correct).

Antoniov: Yes, that is what I did!

Hein: d'n spiker op zunnen kop!
( = full hit! )

John: Yeah. Optimize for what? If in these days you should try to explain to management you're spending hours at specialist's tariff to gain giga-(or even only mega-)bytes of storage which cost peanuts..
The only really counting optimization will we EXPIRIENCED (= interactive) perfomormance.


My reason for the question: I took the command straight from a slide of "RMS indexed file performance" of the performance stream at last november's bootcamp. And since we have some applications with multiple gigabyte, 6+keys, RMS files with substantial INSERTs, MODIFYs (also changing secundary duplicates=yes keys), and DELETEs, I am trying to please the user community a bit.
Don't rust yours pelled jacker to fine doll missed aches.
Ian Miller.
Honored Contributor

Re: EDIT/FDL parameter conflict

remember when trying to please the user community - no good deed goes unpunished :-)
____________________
Purely Personal Opinion