"cut" utility for VMS
Stanley F. Quayle
script. I pulled down the GNU source, but it uses that horrible
shell script configuration stuff...
--Stan
----------
Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 Fax: +1 614 868-1671
8572 North Spring Ct. NW, Pickerington, OH 43147
Preferred address: st...@stanq.com http://www.stanq.com
Jordan Henderson
Stanley F. Quayle <st...@stanq.com> wrote:
>Has anyone ported the Unix "cut" program to VMS? I need it for a DCL
>script. I pulled down the GNU source, but it uses that horrible
>shell script configuration stuff...
>
Really, using cut like you would in Unix is very un-VMS like. What
you really want is that every VMS command (and all of your programs
as well) to support a much superior, very regular /SELECT_COLUMN
qualifier.
I suggest a syntax like the following:
/SELECT_COLUMN=(LIST:<col-expr>,SEPARATOR=c)
Where the LIST qualifier takes a <col-expr> which is the same as in Unix
'cut' and the optional SEPARATOR arg is a character to break columns on.
Hmmmm... maybe I should have waited until Sunday to make this recommendation.
You could also use gawk or perl, both are available for VMS, to do cut
operations in a pipeline, but this is very un-VMSish.
>
>--Stan
>
>----------
>Stanley F. Quayle, P.E. N8SQ +1 614-868-1363 Fax: +1 614 868-1671
>8572 North Spring Ct. NW, Pickerington, OH 43147
>Preferred address: st...@stanq.com http://www.stanq.com
>
-Jordan Henderson
jor...@greenapple.com
jam...@beast.dtsw.army.mil
in <3AC3FF54.10643.15D8791@localhost>:
> Has anyone ported the Unix "cut" program to VMS? I need it for a DCL
> script. I pulled down the GNU source, but it uses that horrible
> shell script configuration stuff...
How about the "cut" in the Perl Power Tools set? Unix utilities written
in Perl. See http://language.perl.com/ppt/.
Ed James ed.j...@telecomsys.com
TeleCommunications Systems, Inc. voice 410-295-1919
2024 West Street, Suite 300 800-810-0827 x1919
Annapolis, MD 21401-3556 fax 410-280-1094
Jim Agnew
jim
Jim Agnew
Jim
David Mathog
>Has anyone ported the Unix "cut" program to VMS? I need it for a DCL
>script. I pulled down the GNU source, but it uses that horrible
>shell script configuration stuff...
You want Pat Rankin's EXTRACT program, available from
http://www.goatley.com/fileserv/fileserv-software.html
It's a veritable Swiss army knife when it comes to record/column
operations. It will even TAIL a long stream-lf file (unlike
VMS's own TYPE/TAIL.)
EXTRACT
General purpose file extraction utility. Selects records from the
beginning, middle, or end of one or more files and optionally performs
various modifications before writing them out.
format:
EXTRACT 'options' file,...
EXTRACT /RECORD=([START=m,END=n,COUNT=k]) file,...
EXTRACT /HEAD=k file,...
EXTRACT /TAIL=k file,...
Regards,
David Mathog
mat...@seqaxp.bio.caltech.edu
Manager, sequence analysis facility, biology division, Caltech
Stanley F. Quayle
> You want Pat Rankin's EXTRACT program, available from
>
> http://www.goatley.com/fileserv/fileserv-software.html
>
> It's a veritable Swiss army knife when it comes to record/column
> operations. It will even TAIL a long stream-lf file (unlike
> VMS's own TYPE/TAIL.)
This is perfect! Thanks, everyone, for your suggestions. I have now
coded my solution.
Ben Sego
> In article <3AC3FF54.10643.15D8791@localhost>,
> Stanley F. Quayle <st...@stanq.com> wrote:
> >Has anyone ported the Unix "cut" program to VMS? I need it for a DCL
> >script. I pulled down the GNU source, but it uses that horrible
> >shell script configuration stuff...
> >
>
> Really, using cut like you would in Unix is very un-VMS like. What
> you really want is that every VMS command (and all of your programs
> as well) to support a much superior, very regular /SELECT_COLUMN
> qualifier.
>
> I suggest a syntax like the following:
>
> /SELECT_COLUMN=(LIST:<col-expr>,SEPARATOR=c)
>
> Where the LIST qualifier takes a <col-expr> which is the same as in Unix
> 'cut' and the optional SEPARATOR arg is a character to break columns on.
>
> Hmmmm... maybe I should have waited until Sunday to make this recommendation.
Wait, maybe we should ask Christof Brass what he thinks! :-)
B.S.
Christof Brass
Thanks for passing over ...
Firstly I have to admit that I'm not sure that this "very un-VMS
like" isn't irony (I suppose it is). Secondly I have to make
clear that functionality of a program per se isn't an OS
dependent topic though the way it used and some OS dependent
features are of course.
I don't understand why waiting until Sunday could be of any
help.
Although I think that basically an output modifying qualifier
would be the best way to go the definition proposed isn't what
shows the important difference: if the user has to count
character columns the case is lost (then having another program
will do the trick sufficiently). The point is to be able to
refer to the content generated by the program e.g. the filename
column of a DIRECTORY output. If the output of a shell script is
to be cut at a certain character position I offer to write a
simple TPU script which can be used to trim the length of each
line in the output file.
Anyway I wonder why this is necessary and what the circumstances
of this task are.
Stanley F. Quayle
> of this task are.
Here's what my resulting code looks like (after renaming the
wonderful EXTRACT program to CUT):
$! Get the list of CW club ID's
$ cut /columns=(3:12) CFFE$COMMERCIAL_BACKUP:COMMERCIAL.SENDING -
/output=cffe$scratch:comm_upload_1.tmp
$ search cffe$scratch:comm_upload_1.tmp "927358" -
/out=cffe$scratch:comm_upload_2.tmp
$ sort cffe$scratch:comm_upload_2.tmp -
cffe$scratch:comm_upload_3.tmp
$ uniq cffe$scratch:comm_upload_3.tmp -
cffe$reports:comm_upload_cw.rpt
$!
$! Get the list of NACHA club id's
$ cut /columns=(1:5,42:51) -
CFFE$COMMERCIAL_BACKUP:COMMERCIAL.SENDING -
/output=cffe$scratch:comm_upload_1.p
$ search cffe$scratch:comm_upload_1.tmp "+5200" -
/out=cffe$scratch:comm_upload_2.tmp
$ cut /columns=(6:15) cffe$scratch:comm_upload_2.tmp -
/out=cffe$scratch:comm_upload_3.tmp
$ sort cffe$scratch:comm_upload_3.tmp -
cffe$scratch:comm_upload_4.tmp
$ uniq cffe$scratch:comm_upload_4.tmp -
cffe$reports:comm_upload_nacha.rpt
File COMMERCIAL.SENDING is a concatenation of files in two formats.
The task is to extract a list of identification numbers that start
with "927358". Other fields in the files can also contain those
digits.
The CW format always has the ID in columns 3-12 of all records. I
sort the list by ID and then eliminate duplicates.
NACHA ID records always have a "+5200" starting in column one. The
ID number starts in column 42. I then sort and un-dup the result.
It's ugly, but it does exactly what I need done. And I was able to
move it into the production environment on Friday.
At least I didn't use "PIPE" ;)
Christof Brass
I don't understand why this is ugly, but anyway I don't
understand in the first place why you renamed "extract" to "cut"
because "extact" seems to describe what will happen more
closely. Doesn't "cut" mean to break something into pieces?
Which is done but most of the pieces aren't important only the
short string which is extracted.
I also don't understand "uniq". I don't have this program. And I
wonder if it is really necessary because SORT/NODUPLICATES
should do the trick.
Why do you use different names for the temporary files? If I
understand the script correctly each temporary name is used
twice as output and will therefore generate a second version.
Why not only using one temporary name?
Basically I would also suggest not to use the concatenated file
but instead the different format files sparately.
Congratulations for moving it into the prod env.
Stanley F. Quayle
> understand in the first place why you renamed "extract" to "cut"
Because we already a totally unrelated "extract" program kicking
around. Also, the Unix-types will find "cut" to be more familiar.
> I also don't understand "uniq". I don't have this program. And I
> wonder if it is really necessary because SORT/NODUPLICATES
> should do the trick.
It's another escapee from Unix. My copy of it is dated January 14,
1995, written by Jason Mathews.
As for SORT/NODUPLICATES. Gosh, there was a SORT option I didn't
know about. I've made the change in the production version. Thanks.
> Why do you use different names for the temporary files? If I
> understand the script correctly each temporary name is used
> twice as output and will therefore generate a second version.
I like to keep intermediate files around if something dies. Disk is
cheap. I clean up all the files at the end. (Which is not shown.)
> Why not only using one temporary name?
I'd need a minimum of two, since I'm doing at least three steps.
Unless I wanted to mess with version numbers.
> Basically I would also suggest not to use the concatenated file
> but instead the different format files sparately.
Yeah, except the file's already bundled together by another process.
I'm intercepting it just before it goes to the IBM mainframe. I do
this processing as a double-check, which I then email to the
mainframe people -- they want to make sure the file's "okay" before I
FTP it.
> Congratulations for moving it into the prod env.
Got to earn my keep somehow. :)
Christof Brass
[SNIP]
> > Why do you use different names for the temporary files? If I
> > understand the script correctly each temporary name is used
> > twice as output and will therefore generate a second version.
>
> I like to keep intermediate files around if something dies. Disk is
> cheap. I clean up all the files at the end. (Which is not shown.)
>
> > Why not only using one temporary name?
>
> I'd need a minimum of two, since I'm doing at least three steps.
> Unless I wanted to mess with version numbers.
Normally the current version number is used for input and a new
version number is generated for output. I suppose if you use
only one temporary name you wouldn't have to mess with version
numbers.
[SNIP]
John Santos
Hmm... curious lacunae* in Christof's database: Legos, Mechanos,
and now April Fools' Day...
He is a bot! The best I ever have seen! Congratulations, Andrew,
but we're on to you now.
*I've always wanted to use that in a post...
>
> Although I think that basically an output modifying qualifier
> would be the best way to go the definition proposed isn't what
> shows the important difference: if the user has to count
> character columns the case is lost (then having another program
> will do the trick sufficiently). The point is to be able to
> refer to the content generated by the program e.g. the filename
> column of a DIRECTORY output. If the output of a shell script is
> to be cut at a certain character position I offer to write a
> simple TPU script which can be used to trim the length of each
> line in the output file.
>
> Anyway I wonder why this is necessary and what the circumstances
> of this task are.
Good question. I think most such needs are the result of the
lack of a suitable API. For example, parsing the output of
"$ show device/mounted" to extract the names of all the disks so
they can be dismounted in sys$system:shutdown.com, because there
is no wild-card support in f$getdvi, or parsing the output of
"$ show device" to determine the merge or copy percentage of a
shadowed disk.
You have some program that produces the information you need
buried in a mass of output, usually a text file. You need to
extract columns, perhaps with or following some tag, to get
what you want. If the program could provide you with just
the information you want, and nothing else, in a form suitable
for manipulation (i.e. as symbols or logical names), then you
wouldn't need this.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Christof Brass
>
> On Sat, 31 Mar 2001, Christof Brass wrote:
[SNIP]
> > I don't understand why waiting until Sunday could be of any
> > help.
>
> Hmm... curious lacunae* in Christof's database: Legos, Mechanos,
> and now April Fools' Day...
Okay, thanks, if "lacunae" is the same as "lucuna" in my English
dictionary: something missing - I didn't think about 1st of
April.
> He is a bot! The best I ever have seen! Congratulations, Andrew,
> but we're on to you now.
>
> *I've always wanted to use that in a post...
>
[SNIP]
> Good question. I think most such needs are the result of the
> lack of a suitable API. For example, parsing the output of
> "$ show device/mounted" to extract the names of all the disks so
> they can be dismounted in sys$system:shutdown.com, because there
> is no wild-card support in f$getdvi, or parsing the output of
> "$ show device" to determine the merge or copy percentage of a
> shadowed disk.
Understood and agreed. This is another argument why a general
output formatting logic should be there for every command and
lexical function which produces output.
In between the task has been explained by the initial poster and
it is clear now that individual extractions are necessary for
several commands as opposed to a general trimming of the
complete output.
> You have some program that produces the information you need
> buried in a mass of output, usually a text file. You need to
> extract columns, perhaps with or following some tag, to get
> what you want. If the program could provide you with just
> the information you want, and nothing else, in a form suitable
> for manipulation (i.e. as symbols or logical names), then you
> wouldn't need this.
Exactly. I asked about the task because I wrongly assumed that
several commands produced different output into one file which
should have later be trimmed. I learned from this situation that
for character/line based output there should be qualifiers to
tell the program what to output and in what order.
> --
Robert Deininger
<JO...@egh.com> wrote:
> Good question. I think most such needs are the result of the
> lack of a suitable API. For example, parsing the output of
> "$ show device/mounted" to extract the names of all the disks so
> they can be dismounted in sys$system:shutdown.com, because there
> is no wild-card support in f$getdvi, or parsing the output of
> "$ show device" to determine the merge or copy percentage of a
> shadowed disk.
There's no wild card in f$getdvi, but there is f$device, which gives the
same effect. It's pretty well hidden. I parsed SHOW DEVICE output for
years until I discovered it.
--
Robert Deininger
rdein...@mindspring.com
John Santos
I'd forgotten all about that. Even used it myself (in a .com I execute
many times a day...) OOPS. I wonder why they haven't used it in
sys$system:shutdown.com? (It's still there in VMS 7.2.) Which leads to
a story... One former co-worker added a bunch of his favorite commands
to sylogin.com, including "open" as a synonym for "show device/file".
Took us years to discover why all the disks always needed rebuilding
after a reboot of that system. (shutdown.com would just proceed without
dismounting any disks if the "open" failed.) There must be a lesson in
there somewhere.
Brian Schenkenberger, VAXman-
$ HELP LEXICAL F$DEVICE
Lexicals
F$DEVICE
Returns the device names of all devices on a system that meet the
specified selection criteria.
Note that the device names are returned in random order.
Format
F$DEVICE([search_devnam],[devclass],[devtype], [stream-id])
That's hidden?
--
VAXman- OpenVMS APE certification number: AAA-0001 VAXman(at)TMESIS(dot)COM
city, n., 1. a place where trees are cut down and streets are named after them.
Arne Vajhøj
> Good question. I think most such needs are the result of the
> lack of a suitable API. For example, parsing the output of
> "$ show device/mounted" to extract the names of all the disks so
> they can be dismounted in sys$system:shutdown.com, because there
> is no wild-card support in f$getdvi, or parsing the output of
> "$ show device" to determine the merge or copy percentage of a
> shadowed disk.
You are ofcourse talking about pre-VMS 5.4 systems !?
(since SYS$DEVICE_SCAN and F$DEVICE was added in 5.4, if I remember
correct)
Arne
Paul Repacholi
> Good question. I think most such needs are the result of the lack
> of a suitable API. For example, parsing the output of "$ show
> device/mounted" to extract the names of all the disks so they can be
> dismounted in sys$system:shutdown.com, because there is no wild-card
> support in f$getdvi, or parsing the output of "$ show device" to
> determine the merge or copy percentage of a shadowed disk.
Can you call the DCL lexicals from a program? Yes, you would have to
set up their parameter blocks etc, but a lot of the 'everyday' stuff
that is not quite right for a COM procedure would be a LOT easier with
the ability to use the code that is already there... Tough if you are
running without DCL as a CLI though...
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
jam...@beast.dtsw.army.mil
in <3AC5C72A.20238.8526790@localhost>:
<snip>
> $ uniq cffe$scratch:comm_upload_3.tmp -
> cffe$reports:comm_upload_cw.rpt
> $!
> $ uniq cffe$scratch:comm_upload_4.tmp -
> cffe$reports:comm_upload_nacha.rpt
<snip>
> The CW format always has the ID in columns 3-12 of all records. I
> sort the list by ID and then eliminate duplicates.
Check out the /NODUPLICATES qualifier of SORT. It gets rid of records
with duplicate keys. Does that cover what you remove with uniq?
Where did you get uniq?
Thank you very much,
John E. Malmberg
"Stanley F. Quayle" <st...@stanq.company> writes:
>
> As for SORT/NODUPLICATES. Gosh, there was a SORT option I didn't
> know about. I've made the change in the production version. Thanks.
If you are using SORT/NODUPLICATES, you may want to see if the use
of /STABLE is also desired.
-John
wb8...@qsl.network
Personal Opinion Only
Robert Deininger
>
> $ HELP LEXICAL F$DEVICE
>
> That's hidden?
Ever hear the phrase "hidden in plain sight"?
When you're looking for a wildcard argument in f$getdvi, this seems to be
an odd rock to look under. Lots of folks miss it.
--
Robert Deininger
rdein...@mindspring.com
POWERS, John
definitely *not* desired - quite the opposite. To quote the last
paragraph from HELP SORT /DUPLICATES FULL_DESCRIPTION...
The /STABLE and the /NODUPLICATES qualifiers are mutually
exclusive.
- John
From: malm...@encompasserve.org [mailto:malm...@encompasserve.org]
>
> In article <3AC64BF9.6180.A5943D1@localhost>,
> "Stanley F. Quayle" <st...@stanq.company> writes:
> >
> > As for SORT/NODUPLICATES. Gosh, there was a SORT option I didn't
> > know about. I've made the change in the production version. Thanks.
>
> If you are using SORT/NODUPLICATES, you may want to see if the use
> of /STABLE is also desired.
>
< -John
-- Cheers, John
- Note This message represents my opinions and nothing else, not the
opinion of SEMA, my family, or the cricket club - though my dog Meg did
nod in agreement whilst I was typing. If you have any problems then
please complain to her (or me, but not SEMA, my family or the CC).
___________________________________________________________________________
This email is confidential and intended solely for the use of the
individual to whom it is addressed. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
Sema.
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited.
If you have received this email in error please notify the Sema UK
Helpdesk by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________
Arne Vajhøj
> In article <009F9E74...@SendSpamHere.ORG>, sys...@SendSpamHere.ORG wrote:
> > $ HELP LEXICAL F$DEVICE
> >
> > That's hidden?
>
> Ever hear the phrase "hidden in plain sight"?
>
> When you're looking for a wildcard argument in f$getdvi, this seems to be
> an odd rock to look under. Lots of folks miss it.
$ HELP LEXICAL
and reading all the lexical names makes it rather obvious to
investigate F$LEXICAL.
The problem is only with people who knows about F$GETJPI and do not
think of looking around for other "interesting" lexicals.
If I were Compaq, then I would add an examle to F$GETDVI using F$DEVICE
and an example to F$DEVICE using F$GETDVI (it could be the same example
!),
then everybody should be able to find it.
Arne
Bob Koehler
> Can you call the DCL lexicals from a program? Yes, you would have to
> set up their parameter blocks etc, but a lot of the 'everyday' stuff
> that is not quite right for a COM procedure would be a LOT easier with
> the ability to use the code that is already there... Tough if you are
> running without DCL as a CLI though...
Which lexical? I don't recall anything available from a lexical that
isn't available from a native API, although some translation may be
needed.
----------------------------------------------------------------------
Bob Koehler | Computer Sciences Corporation
NASA GSFC Flight Software | Federal Sector, Civil Group
| please remove ".aspm" when replying
Tim Llewellyn
Bob Koehler wrote:
> In article <87u248x...@prep.synonet.com>, Paul Repacholi <pr...@prep.synonet.com> writes:
>
> > Can you call the DCL lexicals from a program? Yes, you would have to
> > set up their parameter blocks etc, but a lot of the 'everyday' stuff
> > that is not quite right for a COM procedure would be a LOT easier with
> > the ability to use the code that is already there... Tough if you are
> > running without DCL as a CLI though...
>
> Which lexical? I don't recall anything available from a lexical that
> isn't available from a native API, although some translation may be
> needed.
>
yeah, lexicals are a subset of RTL/system services.
Maybe there is the odd exception but I can't think of it now.
--
Tim Llewellyn, OpenVMS Infrastructure, Remarcs Project
MedAS at the BBC, Whiteladies Road, Bristol, UK.
Email tim.ll...@bbc.co.uk. Home tim.ll...@cableinet.co.uk
I speak for myself only and my views in no way represent those of
MedAS or the BBC.
Dave Greenwood
>
>
> Bob Koehler wrote:
>
> > In article <87u248x...@prep.synonet.com>, Paul Repacholi <pr...@prep.synonet.com> writes:
> >
> > > set up their parameter blocks etc, but a lot of the 'everyday' stuff
> > > that is not quite right for a COM procedure would be a LOT easier with
> > > the ability to use the code that is already there... Tough if you are
> > > running without DCL as a CLI though...
> >
> > isn't available from a native API, although some translation may be
> > needed.
> >
>
> yeah, lexicals are a subset of RTL/system services.
>
> Maybe there is the odd exception but I can't think of it now.
F$EDIT and F$ELEMENT come to mind...
Dave
--------------
Dave Greenwood Email: Green...@ORNL.GOV
Oak Ridge National Lab %STD-W-DISCLAIMER, I only speak for myself
Mark Berryman
>
> Tim Llewellyn <tim.ll...@bbc.co.uk> wrote:
> >
> >
> > Bob Koehler wrote:
> >
> > > In article <87u248x...@prep.synonet.com>,
> > > Paul Repacholi <pr...@prep.synonet.com> writes:
> > >
> > > > Can you call the DCL lexicals from a program? Yes, you would have to
> > > > set up their parameter blocks etc, but a lot of the 'everyday' stuff
> > > > that is not quite right for a COM procedure would be a LOT easier with
> > > > the ability to use the code that is already there... Tough if you are
> > > > running without DCL as a CLI though...
> > >
> > > Which lexical? I don't recall anything available from a lexical that
> > > isn't available from a native API, although some translation may be
> > > needed.
> > >
> >
> > yeah, lexicals are a subset of RTL/system services.
> >
> > Maybe there is the odd exception but I can't think of it now.
>
> F$EDIT and F$ELEMENT come to mind...
F$EDIT is available to any program by calling BAS$EDIT in the Basic RTL.
F$ELEMENT is available to any program by calling STR$ELEMENT.
Mark Berryman
Shane....@healthnet.com
You can retrieve the name of the calling command procedure using a lexical,
but not an API call. That is the only one that comes to mind, though.
Shane
koe...@encompasserve.org (Bob Koehler) on 04/03/2001 07:38:38 AM
Please respond to koe...@encompasserve.org (Bob Koehler)
To: Info...@Mvb.Saic.Com
cc:
Subject: Re: Christof a bot (was: "cut" utility for VMS)
In article <87u248x...@prep.synonet.com>, Paul Repacholi
<pr...@prep.synonet.com> writes:
> Can you call the DCL lexicals from a program? Yes, you would have to
> set up their parameter blocks etc, but a lot of the 'everyday' stuff
> that is not quite right for a COM procedure would be a LOT easier with
> the ability to use the code that is already there... Tough if you are
> running without DCL as a CLI though...
Which lexical? I don't recall anything available from a lexical that
isn't available from a native API, although some translation may be
needed.
----------------------------------------------------------------------
Shane....@healthnet.com
IIRC, there's alternatives to those in the STR$ library.
Shane
Dave Greenwood <green...@ornl.gov>@feda01.fed.ornl.gov (Dave Greenwood)
on 04/03/2001 08:11:42 AM
Please respond to Dave Greenwood <green...@ornl.gov>
Sent by: green...@feda01.fed.ornl.gov (Dave Greenwood)
To: Info...@Mvb.Saic.Com
cc:
Subject: Re: Christof a bot (was: "cut" utility for VMS)
Tim Llewellyn <tim.ll...@bbc.co.uk> wrote:
>
>
> Bob Koehler wrote:
>
> > In article <87u248x...@prep.synonet.com>, Paul Repacholi
<pr...@prep.synonet.com> writes:
> >
> > > Can you call the DCL lexicals from a program? Yes, you would have to
> > > set up their parameter blocks etc, but a lot of the 'everyday' stuff
> > > that is not quite right for a COM procedure would be a LOT easier
with
> > > the ability to use the code that is already there... Tough if you are
> > > running without DCL as a CLI though...
> >
> > Which lexical? I don't recall anything available from a lexical that
> > isn't available from a native API, although some translation may be
> > needed.
> >
>
> yeah, lexicals are a subset of RTL/system services.
>
> Maybe there is the odd exception but I can't think of it now.
F$EDIT and F$ELEMENT come to mind...
Dave
Bob Koehler
>
> F$EDIT and F$ELEMENT come to mind...
>
These are simple character processing functions which can be built from
the native abilities of any high level language, most high level
language's libraries, and/or STR$ routines.
Bob Koehler
>
> You can retrieve the name of the calling command procedure using a lexical,
> but not an API call. That is the only one that comes to mind, though.
>
> Shane
>
Mikes sense. That data is only really known within the CLI and the CLI$
routines don't go there.
Arne Vajhøj
> >
> > Maybe there is the odd exception but I can't think of it now.
>
> F$EDIT and F$ELEMENT come to mind...
True, but it is usually very easy to do similar operations
in any HLL.
Arne
Jan Vorbrueggen
> You can retrieve the name of the calling command procedure using a lexical,
> but not an API call. That is the only one that comes to mind, though.
No, you can do it programatically. It is undocumented, but very unlikely to
change (a relink may be required).
Jan
Shane....@healthnet.com
I'd be very interested in the detail of that, if you have it to hand, and
wouldn't mind. I have a use for just such a routine right now.
Shane
Jan Vorbrueggen <j...@mailhost.neuroinformatik.ruhr-uni-bochum.de> on
04/05/2001 07:25:40 AM
Please respond to Jan Vorbrueggen
<j...@mailhost.neuroinformatik.ruhr-uni-bochum.de>
To: Info...@Mvb.Saic.Com
cc:
Subject: Re: Christof a bot (was: "cut" utility for VMS)
Bill Pedersen
information from a mass of text as the result of some command or application
which does not have a good API.
But I think the specific example is a bit misdirected as you can find the
information in question by using F$DEVICE("*","DISK). And then F$GETDVI to
determine if it mounted.
--
Bill Pedersen
CCSS Corporation
www.CCSScorp.com
831-336-2708
"John Santos" <JO...@egh.com> wrote in message
news:1010401125010...@Ives.egh.com...
John Santos
> While I agree there are times that it useful to be able to extract
> information from a mass of text as the result of some command or application
> which does not have a good API.
>
> But I think the specific example is a bit misdirected as you can find the
> information in question by using F$DEVICE("*","DISK). And then F$GETDVI to
> determine if it mounted.
>
Time-warp??? Several others pointed this out, at which point I
realized that I in fact use F$DEVICE in my own command file to
show free disk space, a command file I use several times a day...
Good thing computers never forget anything.
So, it was a bad example. (But I checked - on AlphaVMS V7.2-1,
sys$system:shutdown.com still writes the output of "$show device/mounted"
to a temp file and parses it...)
BTW, calling Christof a bot was an April Fool's joke. I hope you
didn't take any offense ;-)
Christof Brass
[SNIP]
> BTW, calling Christof a bot was an April Fool's joke. I hope you
> didn't take any offense ;-)
[SNIP]
Never mind. I was a little bit stubborn in fighting agains the
UNIXfication of VMS ;-(