[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Digital Fortran |
| Notice: | Read notes 1.* for important information |
| Moderator: | QUARK::LIONEL |
|
| Created: | Thu Jun 01 1995 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1333 |
| Total number of notes: | 6734 |
1193.0. "XABPRODEF vs XABPRODEF1 - FORTRAN or SDL issue?" by GIDDAY::GILLINGS (a crucible of informative mistakes) Sun Feb 23 1997 23:46
This question was "sort of" asked back in 1990 in the old FORTRAN
conference:
1396 COMICS::TURPIE 11-OCT-1990 1 xabprodef1 ?
The FORSYSDEF.TLB has a module called $XABPRODEF which defines 2
record structures - XABPRODEF and XABPRODEF1. Now, XABPRODEF is
only 1 byte long, whereas XABPRODEF1 is 88 bytes long (=XAB$C_PROLEN).
When working with XABs, it seems "natural" to me to write something like:
STRUCTURE /FULLXAB/
UNION
MAP
RECORD/XABDEF/XAB
END MAP
MAP
RECORD/XABDATDEF/XABDAT
END MAP
MAP
RECORD/XABFHCDEF/XABFHC
END MAP
MAP
RECORD/XABPRODEF/XABPRO
ENDMAP
END UNION
END STRUCTURE
The declare an XABPRO with:
RECORD /FULLXAB/proxab
Now, to use the record:
CALL LIB$MOVC5(0,0,0,XAB$C_PROLEN,proxab) ! Clear XAB as XABPRO
proxab.xab.xab$b_bln=XAB$C_PROLEN ! set length
proxab.xab.xab$b_cod=XAB$C_PRO ! fill as XABPRO
However, because "XABPRODEF" is only one byte long, and the other XABs
are only 80 bytes long, the record is too short, causing the LIB$MOVC5
call to corrupt some memory. Changing the definition to "XABPRODEF1"
corrects the size of the structure and hence fixes the corruption.
I'm not sure if this is a FORTRAN only thing. There doesn't appear to
be an analogous problem with Pascal. There is no mention of XABPRODEF
or XABPRODEF1 in the RMS manual.
John Gillings, Sydney CSC
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1193.1 | | QUARK::LIONEL | Free advice is worth every cent | Mon Feb 24 1997 09:49 | 18 |
| Pascal doesn't use the VMS-supplied SDL definitions, they wrote their own. This
has advantages and disadvantages, as John Reagan will be quick to point out.
If you look at SYS$LIBRARY:STARLET.REQ, you'll see evidence of XABPRODEF1
there.
The strange layout is the result of the way the VMS engineers wrote the SDL
(or converted it from MDL). They don't mind because it works fine for BLISS
and MACRO, each of which have a "flat namespace" for the definitions.
At this point I don't know what could be done about it - I would expect that
there's lots of code which uses the current definitions. You've figured
out how to deal with it.
I suppose we could add some text in the User Manual warning people about this,
but the only good it would do us is to be able to point to it when people
complain after the fact.
Steve
|
| 1193.2 | | TLE::REAGAN | All of this chaos makes perfect sense | Mon Feb 24 1997 16:31 | 27 |
| Correct. Every single time that OpenVMS has a release, I translate
the RMSUSR module from STARLETSD.TLB. I then hand-edit the XABPRODEF
and others back into the variant-record XAB$TYPE that you know and
love. If the RMS changes were small, the hand-edit isn't too
difficult, other times I've spent entire afternoons doing the
conversion. Peek inside the various Pascal kits and you'll find:
Directory PAS3$:[PASCAL.KITBUILD.VAX.V51KIT.SAVESET_C_FILES]
RMSUSR.PAS_VAX_V50;1
173/174 21-JUL-1988 16:35:28.26
RMSUSR.PAS_VAX_V54;1
174/174 26-AUG-1991 15:14:54.81
RMSUSR.PAS_VAX_V60;8
178/180 2-NOV-1994 14:15:01.96
RMSUSR.PAS_VAX_V61;9
179/180 2-NOV-1994 14:15:11.57
Total of 4 files, 704/708 blocks.
It sure is a pain in the *** sometimes... It also has the bad effect
of having the compiler allocate all XAB blocks the same size (the size
of the largest one, 100 bytes for the KEYXAB) eventhough the user turns
around the puts a smaller XAB$C_xxxLEN value into the XAB block. It
could be lots of wasted space if you don't watch out.
-John
|