Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!newsfeed.direct.ca!imci2!news.internetMCI.com!newsfeed.internetmci.com!howland.reston.ans.net!blackbush.xlink.net!rz.uni-karlsruhe.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!saph2.physik.uni-bonn.de!juengst
From: juengst@saph1.physik.uni-bonn.de (Henry G. Juengst)
Newsgroups: comp.unix.misc,comp.unix.bsd.misc
Subject: Re: How to delete files within C programs
Date: 12 May 1996 18:59:39 GMT
Organization: Institut fuer Strahlen- und Kernphysik
Lines: 232
Sender: juengst@saph2.physik.uni-bonn.de (Henry G. Juengst)
Distribution: world
Message-ID: <4n5cer$33m@news.rhrz.uni-bonn.de>
References: <Oum-El-Kheir.Benkahla-3004961724540001@mac-ugm-3.imag.fr> <4mr76q$t8i@news.rhrz.uni-bonn.de> <4mu7is$sro@web.nmti.com> <4mv2r7$ld3@news.rhrz.uni-bonn.de> <4mvsjp$nhn@web.nmti.com>
Reply-To: juengst@saph1.physik.uni-bonn.de
NNTP-Posting-Host: saph1.physik.uni-bonn.de
Xref: euryale.cc.adfa.oz.au comp.unix.misc:22658 comp.unix.bsd.misc:1021
In article <4mvsjp$nhn@web.nmti.com>, peter@nmti.com (Peter da Silva) writes:
>In article <4mv2r7$ld3@news.rhrz.uni-bonn.de>,
>Henry G. Juengst <juengst@saph1.physik.uni-bonn.de> wrote:
>> Normally the number of bits is given by the width of the data bus.
>
>For an operating system, which is a piece of software, the number of
>bits is given by the programming model. Since there are fast and
>efficient algorithms for extended length integer arithmetic, the
>only important restriction for an operating system is the address
>space, and how the address space is managed.
>
>It's not simply that VMS requires a 32 bit address space. If that was
OpenVMS/AXP 6.x uses 64-bit address pointers. 6.2 is more than one
year old. 7.0 is the current version (SDK). VAXes are old hardware
architecture (with some nice features) and it makes no sense to talk
about limits of old hardware if there is modern hardware available.
>> But you should not ignore the real
>> problems between the unixes. There are too many different unixes
>> which are not compatible at all.
>
>It's the code, not the O/S.
Right. But you have so much problems with VMS that I think it must be
your code. If you have problems with your "vertical market application"
you should rewrite it.
>the "UNIX envelope", Henry. There's damn few variances in the UNIX family
>that don't fall under one or the other of those alternatives.
"damn few variances" ? Nice joke.
>> >porting obstacle there is, followed by endianness. NT does the same thing...
>> >buying compatibility now in exchange for porting nightmares tomorrow. They
>> >both make the world look like, well, a VAX. The problems UNIX programmers
>> >have fought with and the good ones have solved are still ahead for you.
>
>> I do not see any reason to make a program memory dependent (ignoring MS
>> world).
>
>Neither do I, but in my experience that's one of the biggest porting obstacles
>in real-world all-the-world's-a-VAX code.
You have real problems if you see all-the-world's-a-VAX code.
>
>> Endianness is also no problem.
>
>That's why people write code with ifdefs for endianness all over the place.
Well known in unix code.
>
>> The start of this discussion was that ...
>
>The start of this discussion was that you decided to take some random
>message and start bashing UNIX in comp.unix. If you don't want to get as
>good as you deal out, then don't come in and stir up trouble.
How can you know that I 'decided to take some random message'? This is
simply not true. It was the special message where someone told another
person "Very simple solution, use the 'unlink' system function to delete
files", which was not my opinion. Nothing more.
>
>As for DEC, it's intuitively obvious that you write to a serial port
>with QIOW$? That string manipulation is in a library called "edit"?
QIO functions are useful, but you do not need them to write to a serial
port. String manipulation is part of the standard library.
>Or let's look at VMS. How to you remove a print job again? I can't
>keep track of whether it's DELETE QUEUE/JOB or DELETE /QUEUE or DELETE
>JOB. It wouldn't surprise me to find it's now SET JOB/NOPRINT. Half the
>commands in VMS are hidden under SET somewhere, including their remote
>terminal program (SET HOST).
Especially for you (quoted VMS help, callable via 'HELP'):
DELETE
The DELETE command performs the following functions:
o Delete one or more files from a mass storage disk volume (see
File).
o Delete the definition of a queue characteristic previously
established with the DEFINE/CHARACTERISTIC command (see
/CHARACTERISTIC).
o Delete one or more print or batch jobs. The jobs can be in
progress or waiting in the queue (see /ENTRY).
o Delete a form (for printer or terminal queues) previously
established with the DEFINE/FORM command (see /FORM).
o Remove an entry from the break-in database (see /INTRUSION_
RECORD).
o Delete key definitions that have been established by the
DEFINE/KEY command (see /KEY).
o Delete a print or batch queue created by the INITIALIZE/QUEUE
command, and deletes all the jobs in the queue (see /QUEUE).
o Delete one or all symbol definitions from a local or global
symbol table (see /SYMBOL).
Additional information available:
file /CHARACTERISTIC /ENTRY /FORM /INTRUSION_RECORD
/KEY /QUEUE /SYMBOL
DELETE
/ENTRY
Deletes one or more print or batch jobs. The jobs can be in
progress or waiting in the queue. The /ENTRY qualifier is
required.
Requires manage (M) access to the queue, or delete (D) access to
the specified jobs.
Format
DELETE/ENTRY=(entry-number[,...]) [queue-name[:]]
Additional information available:
Parameters Qualifier
/LOG
Examples
DELETE
/ENTRY
Examples
1.$ PRINT/HOLD ALPHA.TXT
Job ALPHA (queue SYS$PRINT, entry 110) holding
.
.
.
$ DELETE/ENTRY=110 SYS$PRINT
The PRINT command in this example queues a copy of the file
ALPHA.TXT in a HOLD status, to defer its printing until a SET
ENTRY/RELEASE command is entered. The system displays the job
name, the entry number, the name of the queue in which the job
was entered, and the status. Later, the DELETE/ENTRY command
requests that the entry be deleted from the queue SYS$PRINT.
2.$ SUBMIT/AFTER=18:00 WEATHER
Job WEATHER (queue SYS$BATCH, entry 203) holding until 14-DEC-1994
18:00
$ SUBMIT/HOLD/PARAMETERS=SCANLINE DOFOR
Job DOFOR (queue SYS$BATCH, entry 210) holding
.
.
.
$ DELETE/ENTRY=(203,210)/LOG
%DELETE-W-SEARCHFAIL, error searching for 203
-JBC-E-NOSUCHENT, no such entry
%DELETE-I-DELETED, entry 210 aborting or deleted
The SUBMIT commands in this example queue the command
procedures WEATHER.COM and DOFOR.COM for processing as batch
jobs. WEATHER.COM is queued for execution after 6:00 P.M.
DOFOR.COM is queued in a HOLD status and cannot execute until
you enter a SET ENTRY/RELEASE command. Later, the DELETE/ENTRY
/LOG command requests that the system delete both these entries
from the queue and display a message indicating that the
entries have been deleted.
The job WEATHER (entry 203) has completed by the time the
DELETE/ENTRY/LOG command is entered. Thus, entry 203 no longer
exists. Note that a message indicates that there is no entry
203 in the queue. The job DOFOR (entry 210) is in a HOLD status
when the DELETE/ENTRY/LOG command is entered. Thus, the system
deletes entry 210 from the queue and displays a message to that
effect.
3.$ PRINT CHAPTER8.MEM
Job CHAPTER8 (queue SYS$PRINT, entry 25) pending on queue SYS$PRINT
.
.
.
$ SHOW QUEUE SYS$PRINT
Printer queue SYS$PRINT, on PARROT::PARROT$LPA0, mounted form DEFAULT
Entry Jobname Username Status
----- ------- -------- ------
24 CHAPTER7 SMITH Pending
25 CHAPTER8 SMITH Pending
$ DELETE/ENTRY=25
The PRINT command in this example submits the file CHAPTER8.MEM
to the printer queue SYS$PRINT. Later, user Smith needs
to edit the file again before printing it. Using the SHOW
QUEUE command, Smith verifies that the job is still pending
and that the entry number for the job is 25. Smith then
enters the DELETE/ENTRY command to delete the job from the
queue.
Enjoy 'lprm'. Or was it 'cancel'?
Your statement about 'SET' is not true.
Peter, if you have fundamental problems with VMS concepts I recommend
not to start a discussion about it (perhaps in comp.os.vms).
>
>--
>Peter da Silva (NIC: PJD2) `-_-' 1601 Industrial Boulevard
>Bailey Network Management 'U` Sugar Land, TX 77487-5013
>+1 713 274 5180 "Har du kramat din varg idag?" USA
>Bailey pays for my technical expertise. My opinions probably scare them
Henry
--
juengst@saph1.physik.uni-bonn.de [131.220.161.1] (Internet)
omni:.de.uni-bonn.physik.saph1::juengst (DECnet/OSI, phase V)
saph1::juengst [26.358] (DECnet, phase IV)
Any opinions in this mail are my own.