HP3000-L Archives

November 1996, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Larry Byler <[log in to unmask]>
Reply To:
Larry Byler <[log in to unmask]>
Date:
Mon, 4 Nov 1996 22:42:55 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
Mel Rees ([log in to unmask]) wrote:

: We are having a problem with MPEix 5.5 and backreferenced ENV=
: parameters on a file equation.  The following fails on 5.5 but works
: fine on 5.0 and earlier.  If anyone has any idea or can verify this
: please let me know.

:      This Fails:

:       :file myenv=myenv.pub.acct
:       :file mylp;dev=lp,1;env=*myenv

:     This works:
:
:       :file mylp;dev=lp,1;env=myenv.pub.acct

: The first example does not put an ENV entry in the spoolfile.  These
: are not LAN based printers, they are attached to a DTC 16ix.  We use
: the backreferences to reduce the size of file equations and to allow
: us to switch device types easily (ie. Type 26 to Type 18).

I have verified Mel's problem, and it's my fault.  Three times.  The first
is for forgetting that MPE doesn't really mean Disallow File Equations in
foptions if you explicitly specify a back referenced file (as in *myenv).
                                                                 ^
The second is for blindly extending the DFE option to a new FLABELINFO
call in the environment file processor (before the ENV file FOPEN).
FLABELINFO *does* enforce DFE when you specify it.  Use a file equation,
and FLABELINFO fails with FSERR 404 (BACKREFERENCED FILE IS NOT ALLOWED).
This aborts the ENV file load.

The third, and worst, offense is for not testing this aspect of ENV file
processing.

The only question then, is why doesn't the ENV failure result in an FOPEN
error?  Good question.  I checked further, and found that the particular
error code I returned (an existing one used for FGETINFO failure -- well
it was the same idea, I didn't expect a failure, and I didn't want to invent
a new code in this creaky old interface) is translated into "no error"(!)
status by the file system.  That treatment was there before I started
meddling; I have no idea who decided to do things that way, nor why.

As for where this leaves Mel and others similarly situated, I'm afraid I
don't have a ready workaround.  It appears to be easy to apply a binary
patch to remove the DFE test from FLABELINFO.

I have opened SR 4701-339614 to track this problem.

-Larry "hairshirt size XL please" Byler-

ATOM RSS1 RSS2