Jeff
I concur with Olav. I would like to see them in the CI and also would echo
in the strongest possible way T H A N K Y O U !!!!!
"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."
Zelik
-----Original Message-----
From: OpenMPE Support Group [mailto:[log in to unmask]] On Behalf Of Olav
Kappert
Sent: Thursday, June 03, 2004 8:18 PM
To: [log in to unmask]
Subject: Re: SIB: CI functions
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
>
>
>
|
