"frosty" wrote
byte-at-a-time, since you write so many shell command pipelines
while doing system administration. I wish it was so easy to get D3
verbs to cooperate, at least on an un-customized system.

Frank, can you elaborate on this? What functionality would you like
to see? Sounds to me like you'd like to do this:
select pibs < 10 | listu | show.old.users > md old.user.list

That's a completely fabricated sequence, don't bother to try it, but
yes, with a little pre-processing I believe it's entirely possible.

Regarding "uncustomized" - Once again, you can wait for years for an
enhancement from the vendor which will never come, or you can have it
now with a little effort. Your choice.

T

"Frank Winans" wrote:

"Tony Gravagno" wrote
lucent and semi-feasable reply, as I'm a bit under the weather all of a sudden.

Umm, sorry I even mentioned the named common thing recently. Didn't mean to
rabble-rouse, just post a google-able warning about a pothole in the newbie 'road.'

Uncustomized -- I can do all sorts of clever things on Our D3 box, but that
matters not if they're too hard to distribute to our many client sites.
And then there's the problem of retaining mods after each future D3 vers. upgrade...
Ideally if we find 'I have a cunning plan, my lord' and it tests out ok here,
then some day we might convince RD to go and do likewise...

Frank

"Tony Gravagno" wrote
earlier verbs. I think a shell program would be the way to go, not enhancing
the existing D3 TCL preprocessor, if that was your drift. Since the names PROC
and MACRO are already taken, I think I'll call a source 'program' item for
this new shell to crunch on a 'FUGUE', as in

FE
# demo, last updated 09/08/06
(1) display hello this is the first logical
(1) line of this fugue. See (1) is in two parts.

(2) select myfile1 with name # "badname" and with weight # "0"
(3) select myfile2 with a1 # "invalid"
(4) list !2:name !3:a1


Lets you LIST any field referred to in earlier verbs. Which only makes sense if
you've got same item ids in all files concerned. Future verbs might not have this
restriction, depending on their designed purpose...

Other enhancements I'd make to traditional SORT/LIST way of getting data are
-- runtime override of left/right adjust of a file dpointer during a select
{come on, you can't tell me you all haven't written an MD A descriptor
*a0R or *a0L to let you sort a file unnaturally leftward or rightward
adjusted -- this just lets you do it without the *a0R / *a0L MD items }
-- runtime oconv or masking, or override the field width in the dict
-- implicit entries aren't specifically named in the line, but...
!1:~ which is a sequence counter on the select list of (1)
!1:T which shows total number of input items found in line (1) or
!1:L which shows total number of items processed to output in line (1)
-- a LIST-like verb SAY feeds output into !1:= logical output fields for
later use, instead of to glass/paper {presuming SAY was on line (1)}
----------------------------
The key goals here are
1) give you more access to internal operations of a typical sort/list operation
so you can track down why you're not getting the expected results with
the database you're using. This is an administrator tool, not a production
report generator; if you want page breaks, roll-on, and column headings,
you might be disappointed. BY-EXP will probably also be denied, at first.
2) avoid littering a tried-and-true application account with temp dict entries
that only the system administrator ever uses. And shelter those admin
tools from getting MD-overwritten by the next d3 upgrade's UPDATE-MD
3) get smaller output listings than traditional verbs like list-file-stats, which can
be tedious to read, even with DET-SUPP, on the larger client's boxes.
In fugue you'd maybe sort the list by account size, or worst overflow usage...
4) allow tweaks like 'format with commas 1,234,567 ' {again, what I wouldn't
give to have that in List-file-stats !} as a shell feature, not as an invasive
temporary dict entry to those beloved system / app files. Fugue has an
advantage over D3 TCL in that there's plenty of room in the item to have
fairly complicated grouping and function notation. Since a line of fugue can
concentrate on just the selection part, or on just the output part of what a
regular D3 SORT verb does, there's room to breathe.
5) collect several interesting new verbs in one package, like maybe a port of the
grep/sed commands, with their more elaborate regular expression pattern
matching than traditional D3 [] or * . You can build a better mousetrap,
but if it's not part of anybody's standard package, it won't get much use. This
way all the neat stuff is in another account, safe and sound. Except you need to
catalog the FUGUE processor in each account, I guess. I'd also advocate writing a
simplifed Update processor that just does editing, but has a small cut-n-paste
clipboard you can use to snag dictionary names into on one login session,
paste 'em at the cursor in an edit session on another session. How embarassing
to be scribbling down dict name spellings on old printouts, in this space age...
Maybe call the stripped-down editor DUH ;-)

Your first guess, that I eventually wanted to do something like
select pibs < 10 | listu | show.old.users > md old.user.list
was a good one, but that'll take some hefty verb design to manage,
if I'm seeing things right. And yes, this package will tend to fragment your overflow,
if overused. Maybe go to named common arrays instead of pointer-file lists...

Frank