[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mumps-l
Subject:    Re: <NOTOPEN> errors after upgrade
From:       "Michael S. Simpson" <MichaelSim () WORLDNET ! ATT ! NET>
Date:       1997-12-25 5:08:46
[Download RAW message or body]


Rainy days wrote:

> We are running M/SQL - VAX V6.9-F.8 (maint-07) on a VAXcluster (VMS
> V6.1).
> After a minor upgrade to this M/SQL version (from F.6), one of our VMS
> batch
> jobs has started erroring out with a <NOTOPEN> error.  The output
> device (a
> print queue) is hardcoded in the Mumps routine, and I have checked
> that the
> device setup is fine.  In fact, all still works fine except in batch
> mode.
>
> What is curious to me (being a systems person), is that each job runs
> fine
> if you run them individually, and they all run fine if you execute the
> entire
> file from the DCL prompt.  The only time it errors is if the file is
> submitted
> batch.  The file contains only a few lines; they execute a couple of
> Mumps
> routines like this: $M routine_name.  If I change this to: $M and
> then:
> D ^routine_name, it will run fine when submitted as a batch job.  So
> that is
> what I have done for now.  Anyway, what I guess this boils down to is
> this:
> What is the difference as far as Mumps is concerned between whether a
> job is
> executed from VMS with a "$M routine_name", or executed by going into
> Mumps
> and then executing a "D ^routine_name"?  Armed with an answer to that
> I can
> figure out what may be wrong with my upgrade.
> -Although there have been NO other problem in testing and 3 days of
> use.
>
> Sorry if this is confusing, but M is not my field, so it's hard for me
> to
> be clear about this.  Thanks for any responses!
>
> Bill Monday
> wam@upi.uhcolorado.edu

   Bill,

First, I am not a VMS guru so this is sheer brainstorming (guessing) on
my part, but when you submit the job, are you submitting it as the
DSMMGR?  We have found it easier to submit jobs this way as opposed to
submitting them through the system god, because of permissions and such
within DSM.  When you are inside DSM your permissions (and DSM
variables) are set depending how you logged in.  Outside, it depends on
who submitted the job as to what permissions they get in DSM and within
DSM the DSMMGR is god, even above SYSTEM.

I don't know if this helps at all, but good luck.

Mike Simpson

[prev in list] [next in list] [prev in thread] [next in thread]