> From stsci Mon Dec 17 06:37:53 1984
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA15814; Mon, 17 Dec 84 06:37:48 mst
> Date: Mon, 17 Dec 84 06:37:48 mst
> From: stsci (Space Telescope )
> Message-Id: <8412171337.AA15814@lyra.noao.UUCP>
> To: tody
> Subject: VMS .dir files
> Status: R
>
> Doug,
>
> Had some questions on how you handle directory files, especially in VMS.
> The filename mapping stuff takes a ".DIR" file on VMS and strips it off
> for IRAF. Is there a need to go the other way, and if so, how do you do
> it ? Do you keep a flag that says that a particular file is a DIRECTORY_FILE?
> The reason I ask, is that ZFINFO is supposed to tell whether a file is
> a directory file. Before, for VMS, zfinfo just looked for the ".DIR"
> extension. I have since modified it to do an additional check on files
> with null extensions, if it doesn't find the file in the 1st place.
> (since testing the single directory bit in the file header on VMS takes
> about 100 lines of code!!) I guess my overall question here is do you map
> the names back, somehow, for the case of zfinfo, or should I just keep my
> extra little check in there in case a file with a null extension comes in?
The directory files are unique in the filename mapping scheme because they
have no extension in IRAF form, as when listing a directory (this is controlled
by the extension mapping string in config.h). This is necessary for
compatibility with UNIX and to ease pathname generation, e.g., "a/b/c" is
easy to generate if directory filenames are returned as "a", "b", etc.,
but no so easy if they are "a.d", "b.d", and so on. If we used the second
form with the ".d" extension, and tried to add the ability to generate the
extension on UNIX via an FSTAT call on each file, listing a directory on UNIX
would be prohibitively expensive. If we put the ".d" extension explicitly
in the directory name on UNIX, then it would have to appear explicitly in
all UNIX pathnames and other directory file references.
For these and other reasons, it seemed that the simplest solution was to
omit the extension for directory references. Directory files are almost always
referenced in a context where it is known that the file is a directory,
hence the kernel can add the extension if it needs to. Normally the kernel
will receive a directory filename with a null extension. ZFINFO should
definitely make an explicit check to see if a file is a directory, rather
than merely looking at the filename. As far as I can remember, all other
kernel primitives know if they are dealing with a directory file. Note that
ZFACSS was recently modified to add the DIRECTORY_FILE file type, used when
checking for the existence of a directory file (the new filetype tells the
kernel to add the ".dir" extension).
The high level code does not maintain any flags telling which files are
directory files. In no case is a directory extension appended, except in
a machine dependent name entered by the user.
> Also, re filename mapping, it seems that filenames without extensions
> (including
> directory files once they've been mapped on VMS) don't get listed correctly
> by the directory task in /pkg/system/. It seems to be a problem with
> /sys/clio/fntgfn.x, but I'm not sure - I'll see if I can locate it and fix it.
> It does the following:
>
> Files --> File
> Makefile --> Makefi
> README --> READM
The function of FNTGFN is to expand filename templates, i.e., read VFN's from
a directory or directories using DIROPEN, select all filenames which match a
pattern, returning a list of filenames as output. It is unlikely that this
code could perturb a filename in the manner described. I recommend writing
an SPP test program which calls DIROPEN to verify that VFN's are being read
from the directory correctly, before doing anything to FNTGFN. The latter
package should be machine independent.
By the way, the DIRECTORY task has bugs (machine independent) which are
annoying, but should not affect the basic operation of the routine.
These will be fixed eventually with a new version of DIRECTORY, but this
is not a high priority item at present.
> Other than that, things are coming along; the system and help packages are up
> and running standalone, and the CL is coming along -- we had to backtrack a
> little and redo the old fixes for VMS...
>
> Jay.
> From stsci Mon Dec 17 13:58:50 1984
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA22347; Mon, 17 Dec 84 13:58:44 mst
> Date: Mon, 17 Dec 84 13:58:44 mst
> From: stsci (Space Telescope )
> Message-Id: <8412172058.AA22347@lyra.noao.UUCP>
> To: tody
> Subject: iraf
> Status: R
>
> Doug,
> I hope you didn't get that last letter. I got hugh up on. Any way, I have a
> couple of iraf questions. I will start with the simple one first.
> How long should
> EOF last in the terminal driver?? Currently I return EOF once for each time it
> is typed. THis could be changed to only happening at beginning of line, or so
> that EOF is given for every call to zgetty after the first EOF is typed.
Treat EOF like a character, except that EOF is not returned if there is any
data left to return. An input line, delimited by EOF but not newline, is
returned as a line of text not delimited by newline, followed by EOF in the
next read. The next read after that will return the next line of text from
the terminal, i.e., EOF does not "stick".
> Also I got my problem fixed with task definitions. I had a tp = tp + TASKSIZ
> instead of tp = tp + TASKSIZ * BPI. We had to changed to this format since
> TASKSIZ * BPI is different from the actual size of the task structure in
> VMS. I changed all of the tp++ and tp + 1 to this format. Also I decided to
> use a macro instead to get to the next task structure so I didn't run into
> the problem again.
Right, I recognize that as one of the more subtle bugs that Jim discovered
working with the prototype version of the system. Sorry that the bugfix did
not get into the version of the CL that you received.
> Now for a couple of problems. The cl currently gets up on its own, but will
> not talk to any subprocesses. What happens is that it sends the one piece
> of data to the subprocess, and then the subprocess kind of takes off and reads
> millions of bytes of data instead of just 4 (internal length of data package).
> It apears from the debugs that I get that zardpr is not being used to get
> the data??? I don't know if you have seen this before.
You might have a look at the UNIX version of ZFIOPR. This driver contains
support for debugging IPC. Debugging IPC with the OS debugger is difficult
or impossible. I instead put a debugging switch in the driver (an external
variable named debug_ipc, settable with the debugger before or during
execution), which causes debugging information to be printed during task
execution. There is also a "-C" flag on the UNIX IRAF Main which causes
the task to run standalone in CONNECTED mode, using the IPC driver, but packs
and unpacks char data so that I can run in IPC mode from a terminal.
Installing something similar in the VMS IPC driver would make it easier to
debug problems involving IPC.
If ZARDPR is not being called to read from CLIN it may be because the integer
entry point address of ZARDPR, as returned by ZLOCPR, is not being passed
correctly to the IRAF Main by the ZMAIN.
I am not sure what the 4 byte quantity referred to is. The 4 byte record
header used in the UNIX IPC driver is peculiar to UNIX and is not necessary
on a system which supports record level IPC i/o. UNIX pipes are byte streams,
causing record boundaries to be lost, and I had to use the 4 byte header to keep
records intact across the pipe. All knowledge of the 4 byte record header
is concentrated into the UNIX IPC driver. The high level code merely
calls ZARDPR, ZAWRPR, and ZAWTPR to read and write headerless records.
> Opps got hung up on again...
> Another problem I had was with the -c flag. It seems that irafmain redirects
> i/o to the null device on task startup and shutdown. After redirecting
> STDOUT and STDERR, it sets them with fseti so that they are no longerT
>
> Hung up again...
> redirected, but does not swap the fd's back again. Then on task shutdown, it
> does through and closes the users files that weren't kept and manages to
> close the redirected stdout and stderr because they were copeid into a file
> descriptor greater than last_fd. Have you seen this before??. This also
> may be my problem with subprocess also.
> fred.
>
The STDOUT and STDERR streams are redirected to the null file during
process startup when in CONNECTED mode (when process is spawned by CL).
Redirection is effected with FREDIR and cancelled with CLOSE, not FSETI.
FSETI is used to set the redirect flag in FIO if the stream has been
redirected remotely by the CL.
The redirection to dev$null during startup and shutdown is a new wrinkle
added to the IPC protocol since the Sys.Int.Ref.Man was written. What
happens is:
cl spawns subprocess
subprocess runs IRAF Main
Main redirs STDOUT,STDERR -> dev$null
cl sends envlist (sequence of
SET statements)
cl sends chdir curdir
cl sends "_go_"
Main cancels redirection
The CL (actually, etc$propen.x) must send the "_go_" command to the subproc
to tell it that process startup is complete. Output is discarded during
startup to avoid deadlock due to two processes writing to the IPC at the
same time.
Redirection is cancelled when the "_go_" is received by closing the affected
files. The FD's are swapped back at CLOSE time. If the redirection during
startup is not being cancelled it is probably because the Main is not seeing
the "_go_" command.
> From stsci Thu Dec 20 09:05:22 1984
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA05472; Thu, 20 Dec 84 09:05:17 mst
> Date: Thu, 20 Dec 84 09:05:17 mst
> From: stsci (Space Telescope )
> Message-Id: <8412201605.AA05472@lyra.noao.UUCP>
> To: tody
> Subject: help db
> Status: R
>
> Doug,
>
> Jay here; having a bit of trouble with the help database. Running help
> standalone, I can do a mkhelpdb on lib$root.hd and it gets all the way to
> the end before dying. It seems to die when it tries to make the root/index
> entry, though I'm a little shaky on what's actually going on there.
>
> Does it read back the entire help db and then try to make a full index ?
> If so, then the problem is probably in our binary file driver. That's what
> it looks like to me, anyway. Any ideas, suggestions on where to look?...
I could help more if I knew more about how it is dying. On UNIX one usually
gets a fault which can be caught by the debugger, after which one does a
stack trace to find out where the crash occurred. The most common cause of
faults are memory violations of various flavors. Unfortunately any bugs
having to do with memory violations are usually hard to track down, because
the fault is often not remotely related to the bug which caused memory to be
overwritten. In the event of a memory violation of unknown origin I usually
take the brute force debugging approach, i.e., I first find out what region
of memory is getting clobbered and then repeatedly rerun the program, doing
a binary search for the code which is causing memory to be clobbered by
setting breakpoints in time sequence. This always works but requires intimate
knowledge of the code and a good debugger. Probably you should try to avoid
this and check the low level routines first.
From what you are saying it sounds like the problem is most likely in
hdb_make_rhd() in helpdb.x. I agree that the most likely cause of the problem
is the binary file driver. During compilation compiled help directories are
appended to the help database. This is done as follows:
NOTE is called to note the one-indexed XCHAR offset at which
the next segment will be written. FIO keeps track of this
itself (not the kernel) hence this should not be the problem.
WRITE is called twice to append the two parts of a compiled help
directory to the output file. Since output is buffered there
may or may not be a corresponding call to ZAWRBF.
This sequence is repeated for each help directory in the system. When the
tree has been exhausted the file position is NOTEd and used to compute the
length of the data area. HDB_MAKE_RHD is then called to make the root
help directory, taking the following FIO operations:
SEEK to the beginning of the data area. This will lead to a file
fault to the file buffer containing the seek offset, i.e.,
ZARDBF will be called to read in a file buffer somewhere back
toward the beginning of the file. This is something to check
since it is a random access and most or all file accesses thus
far tested have been sequential.
READ is called to read in the entire data area. The resulting kernel
level operations are likely to be the following:
- ZAWRBF to flush the buffer at the end of the file
- a sequence of ZARDBF calls to read the file buffers
containing the data segment (which is large, about 70KB).
- for each ZARDBF there will be one or more calls to AMOVC,
which is optimized in assembler calling the VAX MOVC3
instruction (check that).
The memory allocation routines are absolutely crucial to all of this (and to
the whole system), and are another possible source of trouble. In particular,
you might check ZRALOC, which is rarely used but is definitely used here.
The things to check are the pointer (if the buffer moves, is the returned
pointer a pointer to XCHAR) and the data alignment (if the buffer moves, the
buffer contents should be simply copied as a byte array with no byte shifts;
the high level code will shift the data to correct any alignment problems).
> Also, the help tasks like lroff, mkhelpdb, and hdbexamine - can they be
> run from under the CL ? I can't seem to get them to work there , so I'm
> just running them standalone...
>
> Jay
>
These tasks are available in the package SOFTOOLS and are nothing special.
They should run just like any other task. It is misleading because the
source is in pkg$help and the task declarations are in pkg$softools.
I will put a comment in the README.
--Doug
> From stsci Thu Dec 20 11:32:09 1984
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA06285; Thu, 20 Dec 84 11:32:02 mst
> Date: Thu, 20 Dec 84 11:32:02 mst
> From: stsci (Space Telescope )
> Message-Id: <8412201832.AA06285@lyra.noao.UUCP>
> To: tody
> Subject: file name mapping
> Status: R
>
> Doug,
> I am running into a couple of small problems. I am trying to use VFNDEL
> from xc. I have a file name t_rcardimage.x. I generate t_rcardimage.r and
> then t_rcardimage.f. At this point t_rcardimage.f maps to tj8rcarde.for
> which I would guess is correct. I then delete the entry for t_rcardimage.r
> the mapping for t_rcardimage.f then changes to t_widsout.r. Have you
> seen this before? Also from the cl if i delete a file in a directory and
> then try to do a directory listing of that directory I get:
> "Cannot open file drb4:[...]zzfnmap.zvf". May question is does the
> filename mapping still have the mapping file open for write or read_write
> access?? VMS has a tendancy to lock files against read if someone else is
> writing it.
> fred.
Fred--
This one is a bug in the high level code. The filename mapping code could
not delete files with long filenames properly. There were two independent
bugs, for which I have included fixes below. I have tested this on UNIX
after compilation with the VMS file parameters in config.h (that's the best
I can do without going to a lot of trouble).
The bug was such that file deletion of a file with a long filenames will have
corrupted your zzfnmap.zvf mapping file (the first long filename will have
been overwritten). After the bug fix, however, the mapping file will again
be readable and can probably be patched up with a rename or something.
FIO knows whether or not the OS locks files opened for writing, as is the case
for VMS. If the file is locked by another process FIO will wait for it to
become available. FIO is careful to open the mapping file for as brief a time
as possible to minimize contention problems. Care is taken to avoid deadlock
between concurrent processes in cases such as a rename where it may be
necessary to open two different mapping files (what a pain that was...).
This sort of thing should not be a source of problems unless there is a bug.
See fio$doc/vfn.hlp if you want to know the nasty details.
By the way, if a file such as "t_rcardimage.x" should appear as "t_rcarde.x"
in a directory listing, that is a sign that FIO could not find an entry for
the file in the mapping file. You reported something like this a while back.
Let me know if the problem should recur.
--Doug.
[1] VFNMAP.X line 115, old ......................................:
define FN_VFN Memc[M_FNMAP($1)+($2*2-2)*LEN_FN]
define FN_OSFN Memc[M_FNMAP($1)+($2*2-1)*LEN_FN]
[1] VFNMAP.X line 115, new
define FN_VFN Memc[M_FNMAP($1)+(($2)*2-2)*LEN_FN]
define FN_OSFN Memc[M_FNMAP($1)+(($2)*2-1)*LEN_FN]
[2] VFNMAP.X line 729, old ......................................:
# entire MFD is written to the mapping file.
checksum = vvfn_checksum (Memi[mfd+1], (len_file - 1) * SZ_INT)
ntrys = ntrys + 1
[2] VFNMAP.X line 729, new
# entire MFD is written to the mapping file. Note that the
# file will contain garbage at the end following a file
# deletion (the file list gets shorter but the file does not).
# Compute checksum using only the valid file data, since that
# is how it is computed when the file is updated.
len_file = LEN_MFD - (MAX_LONGFNAMES - M_NFILES(mfd)) *
(SZ_FNPAIR / SZ_STRUCT)
checksum = vvfn_checksum (Memi[mfd+1], (len_file-1) * SZ_INT)
ntrys = ntrys + 1
Re: file not closed when filename mapping --
I fixed the same bug in the version here, so you won't see it next time
around.
> From stsci Wed Jan 2 06:42:10 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA26294; Wed, 2 Jan 85 06:42:05 mst
> Date: Wed, 2 Jan 85 06:42:05 mst
> From: stsci (Space Telescope )
> Message-Id: <8501021342.AA26294@lyra.noao.UUCP>
> To: tody
> Subject: file i/o
> Status: R
>
> Doug,
> We had a problem with the interaction between iraf file i/o and the
> zroutines. The problem seems to be with the asynchronousity. If we do the
> same thing as unix everything flys, but if we make it asychronous, it falls
> apart. The file name mapping works just fine, and so have our tests with it
> running asychronously [[synchronously?]]. Is it possible that the iraf fio
> plays with the buffer before the operation has completed??
The FIO code was written to call ZAWTBF after every i/o request, before using
the buffer, but this mode of operation has never been tested since UNIX is not
asynchronous. My feeling is that it is not worthwhile to test this mode of
operation until FIO supports more than one buffer per file. The current
interface still supports only one buffer internally, so you have to wait on
every i/o operation in any case, and having asynchronous primitives does not
make much difference (I just use very large buffers when I want it to go fast).
Unless you can find the bug in FIO without spending a lot of time, it might
be best to leave this until I modifiy FIO to support multiple buffers,
at which time the bug will certainly disappear. For the moment it is
sufficient to test the asynchronous features of the zroutines outside FIO.
> Has anything happened with the new process caching. We do the impression
> (oops got) that there would be more changes in the cl. Something about having
> a bunch of processes loaded but not having the nesting and always being at
> the cl prompt? You had mentioned something about this before, and we were
> wondering if it might have got lost somewhere in getting the tape.
All of the process caching code is brand new, written to use the new process
control code accessed via LIBC. The CL process cache code is a package
contained wholly within the file "prcache.c". This version supports nesting
of calls from one process to another (although deadlock will occur if the
cache fills up). The newest parts of the CL are the files "prcache.c",
"main.c", and "bkg.c".
> Also with the text i/o the file size may not represent the actual size
> (in characters) of the file, due to VMS standard record files. Will this
> be a problem. Any Iraf created files will have the correct size since
> they are stream_lf.
> Fred & Jay
This is ok, the file size need be known accurately only for binary files.
For text files the file size is not used for anything serious (see the
description of FSTT_FILSIZE in the manual page for ZFIOTX).
Glad to hear that the filename mapping code is working well. It is crucial
to the port, and I was concerned about bugs since it is such a complex
package.
Doug
Fred and Jay:
Answers to recent questions follow. Is the system ready yet for me to
look at over the modem? When you get it to a state where you feel it is
working fairly well, I would like to fire it up and try a few things.
Doug.
> From stsci Thu Jan 17 08:30:15 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA10600; Thu, 17 Jan 85 08:30:03 mst
> Date: Thu, 17 Jan 85 08:30:03 mst
> From: stsci (Space Telescope )
> Message-Id: <8501171530.AA10600@lyra.noao.UUCP>
> To: tody
> Status: R
>
> Doug,
>
> Here is a list of bugs, changes, suggestions, etc. compiled during
> the port of IRAF to VMS.
>
> Some of the bugs have the bug fixes listed here; others were too
> elusive and/or time-consuming to try to figure out at this time. When you
> get the latest, greatest VMS version of IRAF, what changes we made will
> certainly be there; we'll probably send along RCS files as well so you could
> easily update some of your files. However, most of the changes are
> just a few lines here and there.
>
> We await any comments or any bug fixes you have there...
>
> Jay and Fred
Thanks a lot for the bug reports. I will wait and install these bug fixes
during the upcoming system integration period when I get the new VMS version
of the system back from you guys.
I have been working on some of the more subtle bugs here and will send you
a bug list and/or code updates at some point. I have a few hard to catch
bugs to track down yet before this will be worthwhile.
> P.S.
> We were discussing using mapped sections such as sdas
> uses for static files. There is one major difference in the way that
> iraf and sdas handle static (image) files. In the sdas routine
> a pointer is passed back to where the image resides in memory. This
> is due to the way the mapped sections work in VMS. In Iraf the zroutine
> is given a pointer to where the data is to reside, so we have to do
> a memory copy for each image reference, and may not be more efficient
> than just writing to or reading from disk. Can you see any easy
> way around this problem, or maybe an additional flag to zopnsf which
> indicates that a pointer is to be passed back from zardsf or zawrsf
> for the data rather than a passing in a pointer to where the data is to
> be read to or written from? (fred)
My impression from a glance at the VMS system services was that the create
and map section function could be broken into smaller functions. The idea
was that ZARDSF, when requested to read/map file segment A onto memory
segment M, could unmap M (from the paging file) and remap it onto A.
A subsequent ZARDSF on the same M would unmap from file segment A and
remap onto file segment B. ZCLSSF would unmap file segment B (etc.)
and remap onto the paging file. When using the static file driver, the
high level system code will see to it that M is always aligned on a virtual
memory page boundary and is an integral number of pages.
Will that work? If not something can be done, but at least conceptually
it makes sense to me, and it would eliminate artifical distinctions between
the two types of i/o.
> From stsci Tue Jan 22 12:44:59 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA22373; Tue, 22 Jan 85 12:44:51 mst
> Date: Tue, 22 Jan 85 12:44:51 mst
> From: stsci (Space Telescope )
> Message-Id: <8501221944.AA22373@lyra.noao.UUCP>
> To: tody
> Subject: vfn mapping
> Status: RO
>
> Doug,
> We are having a problem with degenerate directory names. It appears that the
> filename mapping handles degenerate filenames, but no directory names
> contained within the path to that file. Is this correct? I would guess that
> the translation should be done in vfn_translate some where.
> fred.
The mapping file is not used for directory names for performance reasons.
First, OS filenames are not mapped at all. An OS filename is any filename
for which ZFXDIR returns an OS directory prefix (the test is necessarily
machine dependent). Pathnames containing directory names are parsed by
VFN_TRANSLATE, extracting successive directory names. Each directory name
is processed through VFN_ENCODE to map illegal characters, then through
VFN_SQUEEZE to make it fit in an OS filename. It is possible that multiple
directory names will map to the same internal name.
It is possible to modify the mapping code to use the mapfile for long
directory names, but I would prefer to make everyone use short names.
Is the problem with names in the system you got from us? We will change
the directory names if so. Long directory names will also lead to problems
with truncation of pathnames, hence should be avoided in any case.
> From stsci Wed Jan 23 10:40:52 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA05645; Wed, 23 Jan 85 10:06:56 mst
> Date: Wed, 23 Jan 85 10:06:56 mst
> From: stsci (Space Telescope )
> Message-Id: <8501231706.AA05645@lyra.noao.UUCP>
> To: tody
> Status: RO
>
> DIFFERENCES /MERGED=1/OUTPUT=DISK$USER1:[IRAF.FRED]DOUG.TXT;1-
> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;5-
> DISK$USER1:[IRAFX.SYS.FIO]VFNTRANS.X;4
>
> Also, back to the static file driver. There are a number of hitches with
> mapping the file into the user's buffer. One problem with mapped sections
> is that we may run into the working set limit or paging file limit when
> mapping a file. Another is that the buffer pointer must point to a virtual
> address which has not been "created", so the pages in the user's buffer
> must be freed. The users buffer must be on a virtual page boundry.
> Also remote files cannot be used in a mapped section due
> to DECNET and RMS restrictions. Also in writting an image out to disk, the
> create mapped section cannot be into the users buffer, since the data would
> be lost, So a memory copy would be necessary. Also should a mapping be
> undone after a wait, so that the buffer can be reused, and what should
> be done about requests which overlap in some of the pages? Do you see any
> easy ways around these? In sdas a pointer to where the data is to be read
> or written is returned. This removes the problems of page overlap, memory
> copies, and page allignment.
> fred.
I think I need to go into more detail on the scheme I had in mind for the
static file driver, including more information on how FIO works. The file
i/o zroutines are designed to be called only by FIO under carefully controlled
circumstances.
FIO works internally by "paging" file segments the size of a FIO buffer into
the FIO buffer. A file is a series of logical pages, each the size of the
FIO buffer, which is in turn an integral number of disk blocks in size.
FIO guarantees that these logical pages will not overlap; if this were not
the case, ordinary i/o would not work properly, let alone static file i/o.
A "file fault" occurs when i/o is done to a file segment not currently
mapped into a FIO buffer. If the file is open for RW access the file segment
will be read into the FIO buffer. This is true for both reads and writes.
A write causes the file segment to be faulted into the buffer, followed by
modification of the buffer contents. Nothing is actually written to the
file until another file fault occurs, causing the modified buffer to be updated
on disk. There is one exception to this scheme: when a write occurs which
would write the entire file segment, the read is skipped to save i/o.
All of the above discussion concerns only FIO, and is independent of whether
the file is a static file, an ordinary disk file, a DECNET file, or whatever.
A static file is by definition a file which does not change in size while
i/o is in progress. At open time file space has already been allocated and
the system knows exactly where the file blocks are, making optimization
possible. A static file is never created by ZOPNST. It either already
exists or is preallocated by ZFALOC.
FIO buffer space for a static file is allocated before i/o occurs (before
any sections are mapped) by the MEMIO procedure VMALLOC, which ensures that
the buffer is allocated on a virtual memory page boundary. VMALLOC calls
ZMALOC to allocate a conventional buffer larger than necessary, computes
the offset of the first page boundary, and returns a pointer to that page
to the caller. On VMS, VMALLOC would therefore allocate a potentially
large segment of storage in the paging file. The paging file space would
probably be freed very shortly therafter, but it is possible to run out
of space in the paging file if very large buffers are to be allocated.
The virtual page count limit of the process must be large enough to
accommodate the buffer, but since no i/o will be incurred the working set
size should not matter. If I understand VMS correctly, the principal
expense in allocating a large, say 1 MB buffer will be the expense of
initializing the associated 16 pages of process page table space. This will
likely incur several page faults (to fault in the pages of the page table),
plus .1 second or so to initialize the page table entries.
The initial operations required to map an entire section into memory for FIO
are thus the following:
open calls ZOPNST to assign a channel for the section file
VMALLOC calls ZMALOC to allocate a buffer the size of the section
(i.e., the size of the pixel storage file). Pages are
initially allocated from the system paging file.
The next operation will almost certainly be a ZARDST to "fault" the file
into the FIO buffer, which is probably the size of the entire image. ZAWTST
would be called next to get the status of the read. No further FIO faults
would be incurred while accessing the image, since all of the data is
effectively accessible in memory. Eventually ZCLSST or possibly ZAWRST,
ZAWTST, ZCLSST would be called when the file is closed.
I see the functions of the static file i/o routines in terms of VMS system
service calls as follows:
ZOPNST Assign file to a channel.
ZARDST Unmap buffer pages with $DELTVA. Map buffer pages onto
new section with $CRMPSC.
ZAWRST Call $UPDSEC to update the section on disk. Do non unmap
pages as they may be reused. If the pages are not mapped
(very unlikely) perform a map and copy operation or just
return ERR.
ZAWTST Static file i/o is not really asynchronous. Just return
status.
ZSTTST Easy.
ZCLSST Unmap all sections associated with the file. It may be
necessary to remap sections back onto the paging file to
keep the VMS memory allocator happy, but it is not necessary
for IRAF reasons since file buffer space is freed when the
file is closed.
Response to specific questions:
> The users buffer must be on a virtual page boundry.
Alignment on virtual page boundaries is not a serious problem; the
current VMALLOC procedure already does so.
> Also remote files cannot be used in a mapped section due to DECNET and
> RMS restrictions.
The static file driver scheme works well here because it makes it possible
to access files via DECNET if we wish to do so, by copying the data rather
than mapping it. This would be slow if the entire image were being mapped,
but might be worthwhile in some cases, since the software would at least
function.
> In writting an image out to disk, the create mapped section cannot be into
> the users buffer, since the data would be lost, So a memory copy would
> be necessary.
The buffer is mapped by a ZARDST call onto the section file, hence no
copy operation is necessary. ZAWRST merely updates any modified pages.
> Also should a mapping be undone after a wait, so that the buffer can
> be reused..
I/o to mapped sections would not be asyncronous. The wait primitive would
only return a status value. Pages would be unmapped only at close time
and when the buffer is faulted (in a FIO sense) onto another section.
> what should be done about requests which overlap in some of the pages?
FIO does not permit such overlaps. FIO divides a file into a series of
logical pages the size of a FIO buffer. All i/o is initiated on logical
page boundaries. The FIO buffer is an integral number of disk blocks in
size.
If there are serious problems with the scheme I have described (e.g.,
because it does not fit the real VMS) then let me know and there are probably
things we can do. For example, VMALLOC could have a special kernel routine
instead of calling ZMALOC, and might only allocate virtual space without
mapping it, not using the VMS memory allocator at all to avoid conflicts.
> From stsci@aquila.noao Wed Jan 30 11:21:12 1985
> Received: from aquila.noao.UUCP by lyra.noao.UUCP (4.12/4.7)
> id AA00912; Wed, 30 Jan 85 11:21:09 mst
> Received: by aquila.noao.UUCP (4.12/4.7)
> id AA21711; Wed, 30 Jan 85 07:28:33 mst
> Date: Wed, 30 Jan 85 07:28:33 mst
> From: stsci@aquila.noao (Space Telescope )
> Message-Id: <8501301428.AA21711@aquila.noao.UUCP>
> To: tody@lyra.noao
> Subject: fortran hex values
> Status: RO
>
> Doug,
> We have just run into a non-protable problem. In VMS fortran hex values look
> like '111111'x and in unix fortran they look like x'111111'. Neither compiler
> will accept the other. (oops portable above). Do you know which is supposed to
> be standard??. The other way around it would be to run all fortran files
> through the cpp on our end, so that we can use ifdefs as you can under unix.
> fred.
The Fortran standard permits only decimal integer constants. The octal and
hex forms noted are both nonstandard exceptions and cannot be used in portable
Fortran code. There are many other things just like this, e.g., ! comments,
byte, integer*N, logical*N, etc. datatypes, nonstandard intrinsic functions,
do while, identifiers which are nonalphanumeric or which are longer than
six characters, continuation longer than a few lines, inclusion of character
in common blocks, use of normal data statement to initialize data in common
blocks, passing an integer*2 to a function which expects an integer
or vice versa, use of ichar for byte operations, and so on. A simple
preprocessor like cpp is a big help but will not solve problems like the !
comments and identifiers longer than six chars, and I don't think it does
anything about octal, hex, character, etc. constants.
> ZGTENV (new kernel procedure)
I changed the specifications trivially to make it consistent with the
other kernel procedures. See the code in the new version of IRAF I recently
sent you on tape. I also modifed TTY to permit device unit specs etc in
device names. The ZMKDIR primitive has not been specified because it is not
yet proven that we need it (I started to add it for making subdirectories
off UPARM in the CL).
From stsci Fri Feb 15 06:37:12 1985
Received: by lyra.noao.UUCP (4.12/4.7)
id AA15277; Fri, 15 Feb 85 06:37:06 mst
Date: Fri, 15 Feb 85 06:37:06 mst
From: stsci (Space Telescope )
Message-Id: <8502151337.AA15277@lyra.noao.UUCP>
To: tody
Subject: IRAF things...
Status: RO
Doug,
Got the tape read on to VMS with rtar; had to make some small mods to read
from tape. Seems the C lib read() function can't handle it. We found all
the different files and new files, and are remaking the entire system.
Some thoughts and questions:
> 1. Fred was wondering whether there exists some documentation on XC and Mklib
> other than what's in the source files.
There is no additional documentation at present. XC is however much
like the UNIX cc and f77 commands.
> 2. In much of the GIO, FIO, IMIO source files, you have 2 conventions for
> include files, namely include "gio.h" and include <gio.h>. This works
> fine in UNIX because you have linked files to iraf$lib/, but on VMS this
> means we have to have 2 copies of the .h files. We are taking it upon
> ourselves to change all the "fio.h", "gio.h" etc. to <fio.h>, <gio.h>,...
> It makes more sense to us, and to IRAF in general, it seems. Is this
> okay with you?
I agree that it is best to avoid links for portability reasons, but sometimes
they make things much easier. Regarding the "file" and <file> problem, I agree
that it is desirable to have only one copy of an include file (and of course
the link provides this on UNIX). To eliminate the possibility of error on VMS
we will have to get rid of the "file" references, but only in cases where the
named file is global, i.e., referenced in more than one directory. Whenever
possible I use local include files rather than global ones to reduce the
coupling between different parts of the system, and this should not be changed.
This problem with eliminating the local copy of a global include file is
that the package source is no longer self contained. When a package is
listed or moved the included file may be omitted.
Include files are not the only linked files. There are also linked libraries
and executables. In all cases I have tried to restrict the number of links
to 2 to make it obvious where the second entry is. The use of links for
libraries and executables can be eliminated by use of file moves or copies,
e.g., with a "make install" in the package Makefile (see pkg$cl/). This
solution works fine for executables, but there are problems with libraries.
Probably the best solution is to modify Mklib to permit library names like
"lib$libsys.a".
> 3. Some of the VOPS routines have .s versions as well as .x ones. The
> Makelib files don't always use the .s files, but they're there. We've
> been converting your .s files to VMS .mar files (added to the filename
> mapping pairs), and using them instead of the .x files, updating the
> Makelib files appropriately. Some of the .s files (e.g. /vops/AK/aadd*.x)
> are simply output from the fortran compiler, possibly w/ a few things
> taken out.
Sounds good. It seems to me that we can have both the unix and vms assembler
sources in the same directory with the filename mapping selecting the file to
be used when the extension is mapped (on VMS, the UNIX files should appear
as "file\.s" in directory listings). Assembler sources which appear in
directories but which are not referenced in the Makelib are garbage and
should probably be deleted. In some cases, e.g., AADD, there may be no
advantage in having a VMS assembler version since the VMS Fortran compiler
is better than the UNIX one.
> By the way, we changed the IPC routines on VMS to use shared memory regions
> instead of mailboxes. This was due to lots of problems we had with ^C
> interrupts and the mailbox I/O. Shared memory regions helped a lot,
> but are still prone to the problems occasionally. Your latest changes
> dealing with interrupts look they will help us a lot too. In any event,
> the shared memory IPC is much faster and seems a lot more reliable than
> mailboxes.
>
> Jay and Fred
The bug fixes I made should help a lot but do not yet fully solve the problem.
Also, in the UNIX IPC driver I had to disable interrupts while writing a record
to ensure that the data structures would not be corrupted. You might need to
do something similar.
What is your schedule for converting to VMS version 4.0? We are still
running 3.7, and should coordinate the conversion to 4.0 between the
observatories. The 8600 will run 4.0, and should arrive sometime in May.
We should convert to 4.0 sometime before then.
Do not waste time trying to get the new GIO stuff working yet. We are still
actively working on the many pieces of the graphics subsystem and it is not
yet completely installed nor user tested. The GIO/NSPP kernel should be
completed later this week or next and then we will complete the installation.
I can send you a tape containing only the affected files at that time if you
wish.
Doug
> From stsci Wed Mar 6 14:00:12 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA29984; Wed, 6 Mar 85 13:59:45 mst
> Date: Wed, 6 Mar 85 13:59:45 mst
> From: stsci (Space Telescope )
> Message-Id: <8503062059.AA29984@lyra.noao.UUCP>
> To: tody
> Subject: IRAF
> Status: RO
>
> Doug,
>
> Jay here... IRAF VMS is coming along. Having some difficulties dealing with
> 4.0 though, asI'm sure Peter has told you about. The filename mapping
> stuff in particlular - we're keeping it as 3.x filenames even though
> it would be possible to convert to the nice longer ones in 4.0.
> But then it's not possible to go back very easily. W Something we have
> to think about some more and which Peter may talk with you about.
At some point we should reconfigure the system to use the long filenames.
This requires reloading the system with RTAR, editing the filename parameters
in the <config.h> file, and recompiling the system. Any system dependent
makefiles or VMS .com files you guys have added would also have to be changed.
I am considering renaming some files in the directories for the core system
to minimize these sorts of problems, allowing us to get the basic system up
and running and then use the system to handle the filename mapping required
for the applications directories. This does not solve the Make problem unless
we add an IRAF Make to the SOFTOOLS package, which is probably the thing to do.
> Your ideas on using mapped sections for the VMS static file driver look
> okay, thou and should work, with some slight mods,
> but we haven't gotten around
> to it yet (may be lots of line noise here...).
> Also some other enhandcements
> are in the queue for VMS, time allowallowing...
>
> Had a question re Help and Help dtaatabases.
> In SDAS, we have 2 choices for
> Help under IRAF - 1) use 1 big Help db with IRAF and SDAS help combined, or
> 2) have a separate SDAS help db. I've done some simple tests with 2
> separate dbs and it doesn't look to good. If you've run help in IRAF and
> then turn around and specify a new db, does the new database get read
> in entirely? One can envision an SDASHELP script that does:
> set helpdb=sdas$sdas.db
> help ...
> set helpdb=dev$help.db
> But this method can be terribly slow if you go back and forth between IRAF
> and SDAS help and requires a separater task , SDASHELP, to invoke it.
>
> Maybe I'm not don't fully understand the details of the
> helpdb stuff...would it be
> possible to have a couple of helpdb's loaded in memory at the same time, or
> a list of helpdb's to search in the event of a 'help'.? Or, should we
> just use one huge helpdb for IRAF and SDAS and avoid all these problems??
Jay
I think the best solution is for each system to have one big help database
for all packages. I see no problem with this, but the current help database
facilities are probably not up to the task and will have to be replaced
eventually possibly with a DBIO based version.
> From stsci Sat Apr 6 07:52:33 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA07328; Sat, 6 Apr 85 07:52:27 mst
> Date: Sat, 6 Apr 85 07:52:27 mst
> From: stsci (Space Telescope )
> Message-Id: <8504061452.AA07328@lyra.noao.UUCP>
> To: tody
> Subject: Mapped sections on VMS
> Status: RO
>
> Doug,
>
> Finally got around to implementing a static file driver for VMS using mapped
> sections. Your ideas were partially used here, as well as the stuff I threw
> together for the IPC driver using shared global sections. However, there
> are 2 problems which don't want to be solved very easily.
>
> 1. When closing a static file (mapped section file), the pages must
> be unmapped. Since they are mapped within the IMIO via VMALLOC,
> I can't unmap them at the Z-routine level because of the way ZMALOC
> works (puts the count in the longword ahead of the returned buffer
> address). So the pages must be unmapped before the call to ZCLSSF.
>
> However, I have not been able to get this to work. That is, even
> unmapping the pages and then closing the file doesn't work very well
> This may be due to some incompatabilities between the $CRMSPC
> ssystem
> service and the LIB$GET_VM() routine used by ZMALOC to get virtual
> memory. Seems that using the $CREVTA (create virt address space)
> doesn't work too well with the LIB$GET_VM - in fact, DEC warns about
> using them together, since they don't communicate with each other.
>
> The effect of this is that the image file remains open until your
> executable image exits - the close doesn't really close...
>
> The only way I see around this is to rewrite ZMALOC/ZRALOC/ZMFREE
> to use $CREVTA/$DELVTA and then hope for the best, or possibly
> use another idea you had, of having a special Z-routine for a
> allocating virtual memory on page boundaries w/out mapping it...
> maybe that would work, as long as the pixel-file buffers were
> unmapped before the call to ZCLSSF.
I thought the memory allocation might be a problem, in which case the best
solution is probably to add two new kernel procedures (sigh) to be used to
allocate and free pages of virtual memory independently of the ZMALOC allocation
facilities. The pages would initially be unmapped and would not get mapped
until a ZARDSF call was made. Since we would then be able to package the
virtual memory allocator and static file driver together in a self contained
unit, we should be able to do whatever needs to be done to make it all work.
If this looks reasonable I will have to generate some specifications for the
kernel procedures and work out the details of the high level code (not a big
task).
> 2. If you open an image file w/ READ_WRITE access, any changes made
> to the buffer will be made in the file, whether or not a call to
> ZAWRSF is made. This is the way mapped sections work on VMS and
> I haven't found a way around it yet. This could be a potentially
> major obstacle...
I don't see any problem here. If FIO writes into a buffer opened on a file
with read write access, the file is expected to be modified. The only
difference between this and normal i/o is that the write may occur sooner
and cannot be cancelled, but there is no software in the system which depends
upon such subtle semantics.
> Peter probably talked to you a few times about device specifications within
> IRAF, possibly of the form set stdimage=(iis,image_unit_2) or something of
> the sort. Support for this is definitely needed at some higher level than
> the kernel. For the line printer driver, I had to play all kinds of games to
> map the printer names without having to recompile the ZFIOLP source and relink
> the system package. Basically, I used some VMS means to find out where
> iraf$dev/ was and then read a file called "lprtable.vms" which had things like
>
> qms LCA0
> printronix SYS$PRINT
>
> By setting printer=qms for example, 'qms' would be looked up in termcap and
> satisfy all that stuff, then at the ZFIOLP level, qms would be mapped to
> the VMS queue LCA0.
>
> For things like this, it would be nice to have some system-dependent device
> mapping table that is read at a level higher than the kernel, that would
> map a device-type (for termcap/graphcap/printcap/...)
> into an OS/system-dependent
> name or queue_name. For example:
>
> qms LCA0
> deanza ABC0: (i.e. some VMS device name)
> ...
>
> I know it's easy in UNIX to have these tables built into the kernel, so all
> you do is a 'make' and IRAF is remade. In VMS, this is not so easy, and we
> would like to be able to distribute executables. Also, our RCSMake hasn't
> worked since VMS V4.0 came along -- we're using Mklib and DCL command
> procedures everywhere.
>
> I think this kind of device mapping would not be hard and would make it easy
> to add devices without remaking part of the system.
I agree that a runtime table lookup would be nicer in some cases than a
compiled table. I suspect however that the structure and contents of the table
may be too machine dependent to be worth trying to standardize. The easiest
solution may be to have the kernel read the table, rather than IRAF. In that
case it may be more appropriate to put the table in the OS directory, rather
than in DEV. It would not be difficult to call to the ZFIOTX primitives
directly to read such a table.
Some information can now be included in the device specification in the
CL environment. Peter mentioned a syntax such as
deanza!unit=2
or some such. Anything can follow the ! and is assumed to be system
dependent. The high level code will ignore the ! and all that follows
in the termcap and graphcap access, but will pass the full string on to
the kernel to parse as it wishes.
> From stsci Thu May 9 05:41:11 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA17243; Thu, 9 May 85 05:41:06 mst
> Date: Thu, 9 May 85 05:41:06 mst
> From: stsci (Space Telescope)
> Message-Id: <8505091241.AA17243@lyra.noao.UUCP>
> To: tody
> Subject: IRAF
> Status: RO
>
> Doug,
>
> Jay here; have had a hell of a time trying to login to your system, though I
> think it's a problem with our phone system - which means you're probably
> having trouble getting in to ours as you did before.
I have been having lots of trouble getting modem access, but have not tried
it for a week or so. The next test will be trying to send this mail.
> In any event, a few items/questions...
>
> Peter talked to you about the filename mapping and using actual VMS names in
> the CL. We initially thought it was a filename mapping problem, but you were
> right in that it is already handled quite well. The problem, as we quickly
> discovered, is that most of the tasks which open files, handle lists of files
> and templates. The template matching code is the problem with respect to
> VMS names, since things like "[a-zA-Z0-9]*" can be used as a filename, and
> using a VMS name like [iraf.jay.cl]file.dat is processed as a template.
> I don't see a real easy way around it - Peter's suggestion about quoting all
> OS-dependent entities with !'s may be the answer, meaning VMS names would
> be ![iraf.jay.cl]file.dat! on the command line... Sorry if you went about
> the filename mapping code looking for this non-existent bug... If !'s are
> used, some higher-level decoding must be done, but I'm not sure exactly where,
> probably in the template stuff and the filename mapping...
I see the problem now and of course you are right, the template expansion code
is at fault. It is not out of the question to consider changing the logical
directory metacharacter to something less troublesome, e.g., one of "!@%^".
It should be a character which satisifes the following criteria:
not routinely used in filenames on any of our target systems
not an operator character when "lexmodes=yes"
Unfortunately the $ fails criteria number one. Let me know what you think of
such a change and I will discuss it with my group in a meeting on Wednesday.
It is not too late to make such a change if it will make life significantly
easier on VMS.
> Sometimes (a lot less now than before) we have a situation where a connected
> subprocess gets astray and is running while we are back at the CL, i.e. doing
> a 'prcache' shows a state of 'R' for the process. 'Flprcache' can't kill it,
> and on logout, the CL will hang forever for what is seemingly a running
> process. Is there a way we can just kill these guys off, especially on
> logout? Seems to
> me that connected subprocesses should never be asynchronous anyway, so being
> in this state is really an error, though maybe there are future ideas I'm not
> aware of. In any event, sometimes an interrupt at a certain time can put a
> subprocess in this sort of state and making logging out hang the process, and
> the user will need to type ^Y to get out on VMS. Have you seen this type of
> occurence on Unix, and if so, have you any ideas on how we might combat this
> portably? If you don't see it there, we can just do some "#if vms" sections
> in the CL to make sure subprocesses die on logout, but I'm hoping for a more
> portable method.
We also sometimes get hung processes with state R (apparently running). This
happens rarely but is evidently a bug in the system independent code, which
I will fix eventually. I may not be able to prevent processes from getting
into such a state, but I should be able to make the system detect such a state
and recover automatically.
- Doug
13 April 85
> From stsci Thu May 23 06:16:18 1985
> Received: by lyra.noao.UUCP (4.12/4.7)
> id AA11890; Thu, 23 May 85 06:16:14 mst
> Date: Thu, 23 May 85 06:16:14 mst
> From: stsci (Space Telescope)
> Message-Id: <8505231316.AA11890@lyra.noao.UUCP>
> To: tody
> Subject: major portability problem in fortran
> Status: R
>
> Doug,
> We have run into a snag up here. The problem is with fortran integer
> constants. We currently have iraf moved over to the Sun and I was working
> at getting it up and running. It seems that all integer constants are
> passed as I*4. This causes problems for functions that expect I*2 values
> (xpp character constants). Due to the byte ordering the value which
> gets to the other end is the high bytes rather than the low bytes of the
> I*4. This problem would also exist going from I*2 to I*4. Do you know
> of any easy (portable) way to type cast constants in fortran. The other
> method I considered was putting he character constants into the string
> array that gets created by either rpp or xpp (I can't remember which). This
> would solve the problem for xpp characters, but would not solve any
> problems for xpp routines expecting short parameters and getting an I*4
> constant.
> fred.
>
1. Discussion
I knew this would be a problem but could see no easy way to address the
problem until we had access to a non-DEC machine with the bytes in an integer
reversed. It is considered an error in SPP if the programmer declares an
argument as I*2 and passes an I*2, or vice versa. Similar problems occur if
the mismatched types are int and long or int and bool, or if a procedure is
passed the wrong number of arguments. Such bugs will go unnoticed on a DEC
machine because of the architecture (or Fortran implementation). The first
port of IRAF to a non-DEC machine will require finding all such bugs.
I had always planned that my group would do this kind of debugging, but have
no objection if you wish to push ahead and find the bugs for us. The rule is
that an integer constant appearing in an argument list must be declared as
an integer argument in the called procedure. If a short, char, or long is
required than an explicit type coercion must be used, e.g., "(a,long(1),b)".
A character constant, e.g., 'a', is defined as an operand of type char.
It is up to the programmer to use explicit type coercion where necessary to
match the datatypes of actual and dummy arguments. In the case of the
character constant I expected that we would have to add a switch to the
preprocessor to automatically add a call to a I*2 coercion function when
a character constant is used as an argument to a procedure. Of course
Fortran does not define such a function since I*2 is itself non standard
Fortran. The VAX/UNIX Fortran compiler does not provide such a function,
but then none is required since I*2 and I*4 are interchangeable as arguments
on the VAX. Compilers for machines where this is not the case would hopefully
provide such functions. The AOS compiler does, but I never checked the
UNIX implementation on non-Dec machines. It does not surprise me if the
SUN/UNIX Fortran compiler omits the INT2 and INT4 (or whatever) intrinsic
functions.
My plan if the host compiler did not provide INT2 and INT4 intrinsic functions
was for the compiler to generate a Fortran temporary variable of the necessary
type. This will always work but requires care to implement in the current
preprocessor due to the complications of statement labels, error checking, etc.
If the time has come then I can do this or perhaps you would like to have a
go. An easier, but less attractive solution might be to add the intrinsic
functions to the Fortran compiler itself and report the extension to SUN.
If this were done the Fortran generated for 'a' would be 'int2(97)' when the
paren level is greater than zero, skip the INT2 otherwise.
In retrospect I think it would have been better to define character constants
as integer rather than char values. It is not too late to make such a change
to the language definition but doing so will introduce bugs into existing code.
Since we have not already debugged such code, this is not a great problem.
Rather than find such bugs at run time, I would do a pattern search of the
entire system looking for occurrences of ' within parens, then examine each
such occurence interactively. We should really do this ourselves for our
own code, rather than having you guys do it.
2. Conclusions
Having thought all this through, I think the best course of action is the
following:
[1] Change the SPP language definition to define a character constant as an
integer, rather than char value, e.g., 'a' would be exactly equivalent
to 97 in all contexts.
[2] Modify XPP to declare and initialize hidden Fortran I*2 and I*4
intermediate variables whenever the coercion functions "short", "char",
or "long" appear in SPP code within the body of a procedure.
It would be best for NOAO to do this since we are responsible for the code
which is causing the problem. There is a big merge coming up with the
installation of VMS IRAF at NOAO, and that would be an appropriate time to
address the problem. If you cannot wait and wish to forge ahead, feel free
to do so, but please keep notes on the changes required (I would expect there
will be only a few dozen such occurrences).
3. Other
We are in the process of submitting a request to NSF to purchase a SUN
system for delivery this fall to Tucson. I plan to port IRAF to the SUN,
including special performance enhacements for disk access and an interface
for the Sky Warrior array processor. Anything you guys (or JPL) do in the
interim will of course help make this easier.
The JPL port to the JUPITER running the ISI version of 4.2BSD UNIX has run
into serious problems with the ISI Fortran compiler, which turns out to be
untested and quite buggy. An AOS port has also begun, with Steward doing
most of the work. I would like to eliminate this type of bugs from the system
before these sites really attempt to bring the system up.
By the way, in the process of trying to compile IRAF on the JPL system we
found two bugs in the SPP compiler, both caused by the wrong number of
arguments to a procedure. One was in XPP (xppcode.c) and can be found with
LINT. The other was in RPP in the file "rpprat/errchk.r", in the call to the
procedure GNBTOK. Presumably you have already found both of these problems
since you have already succeeded in compiling the system.
Other bugs were found in OSB in the same port. Some of the ACHT procedures
had bugs, the Makelib file had a bug. In OS in the ZCALL file, "pointer to
function" was being used where "function" was required; the UNIX/C compiler
does not complain about such usage. If you have not already found these
I can supply notes (they will be fixed on the next tape you receive in any
case).
> From stsci Thu Jul 11 05:33:23 1985
>
> Doug, a few short notes...
>
> 1. XPP
>
> The 'lexyy.c' file for the new XPP (output of 'xpp.l') causes the VMS C V1.5
> compiler to bomb of a symbol table overflow, so we're still using the old
> XPP. I tried the C V2.0 compiler (on our 8600) and it fixes this problem,
> but spouts out other warnings; I'll have to check them out when it gets
> installed on our machine. This is just a warning; I don't know which
> version you're running.
I have had the V2.0 C compiler installed on the 8600 and that is what I will
be using when I recompile the CL etc., hope it does not give serious problems.
> 2. RPP
>
> The file '...imdis/cv/load.x' causes RPP to stop somewhere and say it's
> got a storage overflow. I split the file into 2 files (load1.x and load2.x)
> and things work okay. Don't know if you have this problem, too.
Just want to make sure you know (I already told Peter) that the CV code is
preliminary and will be changed significantly. I am not happy with it yet
and it will be reworked considerably before being installed (ideally the
display interface subroutines Starlink is working on would come along in time
to prevent a third major revision). On the other hand, either the old display
using the IMIO interface or the new CVL (to eventually replace "display" and
inherit the same name) are both infinitely faster than the infamous SDAS image
load code I have been hearing about. PLEASE SPEED THAT THING UP!! I have
been overhearing comments from the astronomical community about how slow "IRAF"
is, following the recent SDAS/IRAF demo. People do not understand that IRAF
and SDAS are quite different things, or that SDAS is not using IRAF yet for
anything having to do with image display or vector graphics.
The IRAF image load software runs 12 clock seconds on an unloaded 750, and
should run twice as fast as that on a 780 with its faster cpu and faster,
asynchronous i/o system (512 square by 16 bit image). Note that only standard
hight level IRAF interface software is being used and the DISPLAY program is
a sophisticated program with lots of fancy options. This proves that is it
possible to have features and speed, too.
> 3. VMS Kernel
>
> I wrote an assembler version of the str*() routines for VMS last year to
> remove dependencies on the VMS C libraries (str.mar). There are 2
> "phantoms" in there that have been known to cause access violations at
> randomly spaced intervals and disappear when you try to throw in extra
> code to debug them. The two lines containing the 'DECB' instruction should
> be changed to 'DECL' instead; subtracting 1 from an address can have strange
> effects when only the low-order byte is changed! This is an old phantom
> which has finally been killed, but as we all know, phantoms have brothers...
>
> Jay
Unless it can be demonstrated that the assembler versions of the string
routines are a good deal faster than the C versions in LIBC, I do not plan
to use them. I will look at the /mach output for the C versions before
deciding. If the assembler versions used (already use?) the VMS string
instructions that would be different.
distrib
>
Mageia
>
6
>
armv5tl
>
media
>
core-release
>
by-pkgid
>
30819c093f498f9dfa6444d2407d0521
>
files
>
5391
