Re: Logical device for openVMS implemented

[email protected] wrote on 10-SEP-2003 15:04:01.45

>> From: "Jacob (=Jouk) Jansen" <[email protected]>
>> To: <[email protected]>
>> Cc: <[email protected]>
>> Sent: Wednesday, September 10, 2003 2:20 PM
>> Subject: Re: [gs-code-review] Logical device for openVMS implemented
>
>>  Do you have a better idea how to reach the Decode/Unicode. file from the
>> installation directory GS_LIB as it use to be?
>
>Please look how GS_LIB_DEFAULT is defined and used in unix-gcc.mak and other
>makefiles.
>IMO VMS makefiles should do same.
>I don't know whethet this idea is better or worse, but it gives an
>uniform behavior on various platforms. He had hard discussions about it,
>and I can't say that I'm completely happy with this decision.
>However the decision has been made.
 Presently on OpenVMS GS_LIB_DEFAULT is defined as GS_LIB. On other systems
GS_LIB_DEFAULT contains a hard-codes search list. In principle for these
other systems is coded within gs what is included in the VMS inteaction with
filesystem. By opening GS_LIB:<filename> all directories are searched. This
is much more effecient than the software emulation of gs.
Another advantage is that the "resource" path's are not hard-coded in the
executable. This should be a feature for other platforms too.
This will ensure that the makefiles do not need any editing before running
them.


>Particularly on Unix and Windows gs ever tries to open
>gs/lib/Decoding/Unicode
>and fails, then succeeds with gs/resource/Decoding/Unicode.
The idea is that VMS can do both directories in one step. which is much more
effient. Note that the functionality is exactly the same. Only "who did it"
is different.

>Ray had an idea to improve this with defining GS_RESOURCE in parallel to
>GS_LIB.
>My idea was to move most gs/lib/*.ps files to gs/resource/ProcSet/*,
>and move gs/lib/gs_init.ps into gs/resource/gs_init ,
>and remove gs/lib at all. IMO the latter is closer to Adobe implementations.
>In any case, this problem is general for all platforms,
>and a platform-dependent fix isn't a good way.
No, but why use a software emulation when the OS does it more efficient.

>> >2. You coded :
>> >
>> >    logical = getenv( buffer );
>> >
>> >At this moment the buffer contains a file name prefix.
>> >You consider it as a name for environment variable,
>> >which (I guess) you assume to substitute the prefix.
>> >This behavior is too different from one on other platforms.
>> >Can you explain a reason why the GS behavior must be so different ?
>> The reason is that on OpenVMS one can open a file
>GS_LIB:[directory]file.name
>> where GS_LIB is a logical (cf. unix environment) while the program opening
>> this file does  not know at all that it is a logical.
>
>The statements above look self-contradicting.
>I understand "the program opening this file does  not know at all that it is
>a logical"
>so that the operating system resolves a logical device automatically.
true

>I insufficiently know VMS to know ehether it is true, but it looks for me to
>be highly probable.
>But if it is true, your code appears excessive, and I'm not sure whether it
>is fully conforming.
The problem is the dual syntax.

>Contrary, there may exist a programming practice, in which ALL
>applications should resolve logical devices by own means.
>In this case your code may be conforming, but you should refer to this
>practice
>in comments and in GS documentation, because it is not usual in GS practice.
It is very common on OpenVMS. OpenVMS cannot run without.




>> However there may be 2 different
>> syntaxes and the above statement on logical = getenv( buffer ) is to
>> determine which syntax should be used.
>
>This is also inobvious, and I can't guess what syntaxes do you refer,
>and what is the logics of the recognition. Please add comments to code.
 on on which the definition ends on .]
 all the others are in the other group.


>> >3. (2) requires a clear explanation and change to GS documentation.
>> >Actually I strongly against such change.
>> Nope. since this GS_LIB was always used on VMS. It can be defined as
>> previously, but then the Resource/subdirs cannot be accessed.
>
>If your logics of the GS_LIB interpretation differs from other platforms,
>it must be reflected in GS documentation.
 Note that this GS_LIB logical stuff is already in gs for more than 7 years.
My patch is only an extentions to cope with subdirectories. The logical
names for directories is common practice on OpenVMS and should be known by
all people who seriuosly maintain an openVMS box.

 However, if it is not well documented: Which file should contain this info?
 
                 Jouk


Bush : All votes are equal but some votes are more equal than others.

>------------------------------------------------------------------------------<

  Jouk Jansen
		 
  [email protected]

  Technische Universiteit Delft        tttttttttt  uu     uu  ddddddd
  Nationaal centrum voor HREM          tttttttttt  uu     uu  dd    dd
  Rotterdamseweg 137                       tt      uu     uu  dd     dd
  2628 AL Delft                            tt      uu     uu  dd     dd
  Nederland                                tt      uu     uu  dd    dd
  tel. 31-15-2782272                       tt       uuuuuuu   ddddddd

>------------------------------------------------------------------------------<