OPENMPE Archives

June 2004

OPENMPE@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:
Olav Kappert <[log in to unmask]>
Reply To:
Olav Kappert <[log in to unmask]>
Date:
Thu, 3 Jun 2004 20:17:57 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (108 lines)
Jeff:

I would like to see them in the CI.

On a side note, I would like to thank Jeff for all his efforts in
keeping the list up-to-date with current development plans, his
participation on this list, his developed scripts, and above all his
interest in MPE.

Thanks Jeff.

Olav Kappert.

Vance, Jeff H (Cupertino) wrote:

>Hi all,
>
>Based on the tactical SIB '04 results, vCSY has agreed to add to the CI
>three new functions: SPOOLINFO, DEVINFO, and VOLINFO.  Collectively
>these items received 1,380 total votes (which would put the group in 4th
>place) and 223 individual votes (which would be 1st place by almost
>double the new 2nd place item 'ftpusers and ftpaccess'). So, many people
>voted a few votes each for these three items.
>
>The ballot description for these three items explicitly states that the
>new functions are to be integrated into the CI in a manner similar to
>FINFO and JINFO.  We are willing to do that; but, integrated into the CI
>means a patch, and though the patch will certainly target 7.5 and
>probably (maybe?) 7.0, it probably will not target 6.5.  The absence on
>6.5 being to conserve R&D and MPE Support resources.
>
>Assuming most of the tactical SIB items are not backported to 6.5, do
>you still wish to see these functions integrated into the CI, or would
>it be more useful to do it another way? We could, as a group, define the
>many CI variable names and types (string, int, bool) which apply to each
>function, and then vCSY could write a program to return the desired
>piece of information via the predefined variable.  This approach does
>not require a patch and would work on 6.5 as well as the newer MPE
>releases.  But this approach implies a process create each time the
>function is invoked, thus, could not be used in break mode, and it is
>less "natural" to invoke.
>
>Examples:
>
>Built-in functions:
>
>1.0  while devinfo(1,'FreeSpace') < limit do ...
>2.0  setvar x spoolinfo('o1234','aborted')
>3.0  if volinfo('myUserVol','NumVolumes') < N then ...
>4.0  echo Dev Ownership: ![devinfo(16,'owner')]
>
>
>Program "functions"
>1.1  xeq devinfo 1 freespace
>     while hpDEVINFOfreespace < limit do
>        ...
>        xeq devinfo 1 freespace
>     endwhile
>
>2.1  xeq spoolinfo o1234 aborted
>     setvar x hpSPOOLINFOaborted
>
>3.1  xeq volinfo myUserVol NumVolumes
>     if hpVOLINFOnumvolumes < N then ...
>
>4.1  xeq devinfo 16 owner
>     echo Dev Ownership: !hpDEVINFOowner
>
>
>So, is it worth trading some ease of use, performance, and flexibility
>to have these "functions" available on all releases, or do you still
>prefer them to be integrated in the CI?
>
>Note: JINFO and PINFO have an optional 3rd parm which holds the returned
>status. When present, the status parm suppresses the display of CI
>errors and warnings, and prevents CIERROR from being set.  Production
>quality scripts should pass the status parm to handle cases like the job
>terminating, etc.; however, this makes the integrated functions less
>simple to use.
>
>Same examples:
>
>1.2  setvar x devinfo(1,'freespace',cierror)
>     while cierror = 0 do
>        ...
>        setvar x devinfo(1,'freespace',cierror)
>     endwhile
>
>2.2  setvar x spoolinfo('o1234','aborted',status)
>     if status = 0 then
>        # okay to use x
>
>3.2  setvar x volinfo('myUserVol','NumVolumes',hpcierr)
>     if hpcierr = 0 and hpVOLINFOnumvolumes < N then ...
>
>4.2  setvar x devinfo(16,'owner',status)
>     if status = 0 then
>        echo Dev Ownership: !x
>        ...
>     endif
>
>
>Thanks for your feedback,
> Jeff Vance, vCSY
>
>
>

ATOM RSS1 RSS2