latest proposed tweaks to Encode Makefile.PL
OK, the enclosed patch assumes that we'll owrk around the MMK
problem by fixing MMK rather than tweaking the various Makefile.PL's
out there. Does this rendition seem OK to send in? (I only have a few
minutes before heading off for holiday shopping sprees...)
The notable difference here is the names of the various variables
introduced is now $_files. As I mentioned this works ok on
NT, and VMS. It also work on OSF/1 (aka Tru64) where I obtain:
All tests successful.
u=1.3 s=1.25 cu=120.35 cs=37.1167 scripts=274 tests=21062
Enjoy:
--- ext/Encode/Makefile.PL.orig Fri Dec 22 14:53:14 2000
+++ ext/Encode/Makefile.PL Fri Dec 22 15:05:02 2000
@@ -1,4 +1,5 @@
use ExtUtils::MakeMaker;
+use File::Spec::Functions;
my @tables = qw(iso8859 EBCDIC Symbols);
WriteMakefile(
@@ -33,18 +34,30 @@
sub postamble
{
- return '
+package File::Spec::Functions;
-Encode$(OBJ_EXT) : iso8859$(OBJ_EXT) EBCDIC$(OBJ_EXT) Symbols$(OBJ_EXT)
+my $iso8859_files = catfile(qw(Encode ascii.enc)) . " " .
+catfile(qw(Encode iso8859*.enc)) . " " . # * glob OK?
+catfile(qw(Encode cp1250.enc));
+my $EBCDIC_files = catfile(qw(Encode cp1047.enc)) . " " .
+catfile(qw(Encode cp37.enc)) . " " .
+catfile(qw(Encode posix-bc.enc));
+my $Symbols_files = catfile(qw(Encode symbol.enc)) . " " .
+catfile(qw(Encode dingbats.enc));
-iso8859.c : compile Makefile
- $(PERL) compile $@ Encode/ascii.enc Encode/iso8859*.enc Encode/cp1250.enc
+package MY;
+ return "
+
+Encode\$(OBJ_EXT) : iso8859\$(OBJ_EXT) EBCDIC\$(OBJ_EXT) Symbols\$(OBJ_EXT)
+
+iso8859.c : compile $self->{'MAKEFILE'} $iso8859_files
+ \$(PERL) compile \$\@ $iso8859_files
-EBCDIC.c : compile Makefile Encode/cp1047.enc Encode/cp37.enc Encode/posix-bc.enc
- $(PERL) compile $@ Encode/cp1047.enc Encode/cp37.enc Encode/posix-bc.enc
+EBCDIC.c : compile $self->{'MAKEFILE'} $EBCDIC_files
+ \$(PERL) compile \$\@ $EBCDIC_files
-Symbols.c : compile Makefile Encode/symbol.enc Encode/dingbats.enc
- $(PERL) compile $@ Encode/symbol.enc Encode/dingbats.enc
+Symbols.c : compile $self->{'MAKEFILE'} $Symbols_files
+ \$(PERL) compile \$\@ $Symbols_files
-'
+"
}
End of Patch.
Peter Prymmer
[PATCH: perl@8211] directory depth typo in one win32 Makefile
Hi, I have been testing a way to generalize the new Makefile.PL for the Encode module, primarily some tweaks for VMS along the lines of those proposed in: http://www.xray.mpe.mpg.de/mailing-lists/vmsperl/2000-12/msg00127.html I thought that I'd try that Makefile.PL out on a particularly challenging perl build platform: namely nmake and MSVC on NT 4. The good news is that that patch (see above URL) to Encode's Makefile.PL seems to allow for the build of the binary dll form of Encode on NT. The bad news is that I am a bit bewildered by the extension handling in the NT Makefiles and cannot offer a comprehensive patch to add Encode to NT's list of dynamic_ext's at this time, although working with analogs of the other ext/ modules ought to yield results. Other bad news is that with MSVC I did seen these warnings whilst test building Encode and my not yet ready for prime time Makefile.PL patch: - cl -c -nologo -Gf -W3 -Od -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT - DPERL_MSVCRT_READFIX -Od -MD -DNDEBUG-DVERSION=\"0.01\" -DXS_VERSION=\"0.01 \" -I..\..\lib\CORE Encode.c Encode.c Encode.xs(59) : warning C4013: 'PerlIOBuf_pushed' undefined; assuming extern ret urning int Encode.xs(274) : warning C4013: 'PerlIO_unread' undefined; assuming extern retur ning int cl -c -nologo -Gf -W3 -Od -MD -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT - DPERL_MSVCRT_READFIX -Od -MD -DNDEBUG-DVERSION=\"0.01\" -DXS_VERSION=\"0.01 \" -I..\..\lib\CORE encengine.c encengine.c "Running Mkbootstrap for Encode ()" ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 644 Encode.bs - So that may portend a possible linking problem assuming that the dll form of Encode gets built by nmake. At any rate, at last I come to the reason for this message: Whilst doing a vanilla nmake/MSVC build of the perl@8211 kit I noted this failure toward the end of the nmake win32/Makefile: -- Creating library ..\..\lib\auto\Storable\Storable.lib and object ..\..\lib\au to\Storable\Storable.exp ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 755 ..\..\lib\auto\Storable\Storable.dll ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e cp Storabl e.bs ..\..\lib\auto\Storable\Storable.bs ..\..\miniperl -I..\..\lib -I..\..\lib -MExtUtils::Command -e chmod 644 ..\..\lib\auto\Storable\Storable.bs cd ..\..\win32 cd ..\ext\Filter\Util\Call ..\..\..\miniperl -I..\..\..\lib Makefile.PL INSTALLDIRS=perl The name specified is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: '..\..\..\miniperl' : return code '0x1' Stop. -- And it looks like there was a directory depth typo in the win32/Makefile that was not present in the makefile.mk employed by dmake users, but which this patch is intended to correct (warning uni diff with ^M characters to be extracted and applied carefull to a DOS endl file): --- win32/Makefile.orig Wed Dec 20 10:52:47 2000 +++ win32/Makefile Fri Dec 22 14:28:17 2000 @@ -989,9 +989,9 @@ $(FILTER_DLL): $(PERLEXE) $(FILTER).xs cd $(EXTDIR)\Filter\Util\Call - ..\..\..\miniperl -I..\..\..\lib Makefile.PL INSTALLDIRS=perl + ..\..\..\..\miniperl -I..\..\..\..\lib Makefile.PL INSTALLDIRS=perl $(MAKE) - cd ..\..\..\win32 + cd ..\..\..\..\win32 $(ERRNO_PM): $(PERLEXE) $(ERRNO)_pm.PL cd $(EXTDIR)\$(*B) End of Patch. With that perl builds but fails one test: io/utf8FAILED test 19 Failed 1/25 tests, 96.00% okay FWIW (if it even matters) the build and test were done on a FAT file system not (NT|HP)FS. Peter Prymmer
Re: perl@8211: Encode encounters MakeMaker trouble on VMS
On Fri, 22 Dec 2000, Peter Prymmer wrote: > > I'm sure an octothorpe would help, but it's unclear to me whether this > > really is a warning of the "uh oh, something's wrong but continuing" vs. > > just plain chattiness. In the first case, it should be picked up as an > > error, in the second the warning should be excised from the code. > > Hmm,,, taking a closer look: > > $ search [.lib]encode.t warn > %SEARCH-I-NOMATCHES, no strings matched > > It appears that what you are seeing is something from the .pm module: > > $ sea [-.lib]encode.pm warn > optional lexical warning (category utf8) is given. > be UTF-8, an optional lexical warning (category utf8) is given. If > warn "Loading $file"; > > In the loadEncoding() routine. (Curious: why don't I see the warning?) That is to say that you should ignore my # octothorpe suggestion as I didn't realize where the warning was generated at the time that I read that you were having problems with it. For some silly reason I thought that perhaps it was in t/lib/encode.t itself, but it is not. Peter Prymmer
Re: perl@8211: Encode encounters MakeMaker trouble on VMS
On Fri, 22 Dec 2000, Charles Lane wrote: > Well, I was also building perl@8211. Maybe the difference was that I had > applied the piping code patch that I recently posted. That could be the difference as I have not yet had a chance to apply your patch. > What do you see when running t/lib/encode.t from a command-line Perl? I > get the warning messages sent to the terminal or STDERR. When run from the command line it looks like: $ perl lib/encode.t ok 1 ok 2693 $ Though with that many tests (partly my fault :-( it was tough to see. Somewhat more rigourously: $ perl lib/encode.t > enc.out $ perl -ne "print if $_ !~ /^ok \d+\n$/" enc.out 1..2693 > I'm sure an octothorpe would help, but it's unclear to me whether this > really is a warning of the "uh oh, something's wrong but continuing" vs. > just plain chattiness. In the first case, it should be picked up as an > error, in the second the warning should be excised from the code. Hmm,,, taking a closer look: $ search [.lib]encode.t warn %SEARCH-I-NOMATCHES, no strings matched It appears that what you are seeing is something from the .pm module: $ sea [-.lib]encode.pm warn optional lexical warning (category utf8) is given. be UTF-8, an optional lexical warning (category utf8) is given. If warn "Loading $file"; In the loadEncoding() routine. (Curious: why don't I see the warning?) Peter Prymmer
Re: perl@8211: Encode encounters MakeMaker trouble on VMS
Peter Prymmer wrote: > On Fri, 22 Dec 2000 [EMAIL PROTECTED] wrote: >> Seems that someone put a >>warn "Loading $file"; >> in Encode.pm just to let us know when a file is loaded. Bleah. >> Is it just me (and test.com) that doesn't like modules spitting out >> gratuitous messages? > Hmm... I did not see that with perl@8211. Does adding an octothorpe help? > I.e.: > > warn "# Loading $file"; Well, I was also building perl@8211. Maybe the difference was that I had applied the piping code patch that I recently posted. What do you see when running t/lib/encode.t from a command-line Perl? I get the warning messages sent to the terminal or STDERR. I'm sure an octothorpe would help, but it's unclear to me whether this really is a warning of the "uh oh, something's wrong but continuing" vs. just plain chattiness. In the first case, it should be picked up as an error, in the second the warning should be excised from the code. -- Drexel University \V--Chuck Lane ==]-->*<---[=== (215) 895-1545 _/ \ Particle Physics FAX: (215) 895-5934 /\ /~~~[EMAIL PROTECTED]
Re: perl@8211: Encode encounters MakeMaker trouble on VMS
On Fri, 22 Dec 2000 [EMAIL PROTECTED] wrote: > Peter Prymmer <[EMAIL PROTECTED]> writes: > > On Wed, 20 Dec 2000, Craig A. Berry wrote: > > > >> At 01:39 PM 12/20/2000 -0800, Peter Prymmer wrote: > >> >%MMS-F-GWKNOPRN, There are no known sources for the current target > >> >MAKEFILE. > >> >%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE8064. > >> > > >> >Craig - did you not mention that you had a MM_VMS.pm or Makefile.PL fix > >> >for this particular problem? > >> > ... > >> > >> The third issue doesn't seem to occur with MMS but only with MMK. If you > >> have foo$(obj_ext) in a source list for one dependency and foo.c as the > >> target in another dependency, it doesn't figure out the implicit action, in > >> this case compiling foo.c to get foo.obj. You end up getting a "sources > >> unknown" error for foo.obj. > > I did some mucking about with MMK this morning; there's one routine in > particular that is the source of all of our problems: > Fill_In_Missing_Sources. I think I have a patch for it...good enough > to build MMK, Perl, Encode, and some test cases. It recurses through > the suffix list, looking for explicit and implicit rules that will yield > the target file, perhaps using a `chain' of implicit rules with intermediate > files. I'll post the diff here, on the Madgoat list, and on www.crinoid.com > a little later today. > > (as a side note, I'm not surprised that there are these problems; there's > some very complex stuff going on inside of MMK) BTW There is one other bug in MMK that bothers me: A source file with a timestamp in the future renders a project unbuildable. This differs from the MMS behavior which issues a warning then goes ahead with the rule to update the file that depends on the source but thereafter MMS concerns itself with the timestamp on the derived file (say a .C is timestamped in the future then the .OBJ gets built and in checking dependencies for the resultant .EXE it pays attention to the timestamp on the .OBJ not on the .C). > After making the changes in ext/Encode/Makefile.PL (except for the > extra dependancies, don't need them with a fixed MMK) then the build > works fine. > > But I am getting a test failure for lib/encode.t, the usual one (test > 2694 out of 1..2693) that results from having extraneous test output. > > Seems that someone put a >warn "Loading $file"; > in Encode.pm just to let us know when a file is loaded. Bleah. > Is it just me (and test.com) that doesn't like modules spitting out > gratuitous messages? Hmm... I did not see that with perl@8211. Does adding an octothorpe help? I.e.: warn "# Loading $file"; Peter Prymmer
Re: VMS::Queue example ?
At 12:55 PM 12/22/00 +0100, Martin Zinser wrote:
>Hello!
>
> I just started to play around with VMS::Queue and may be I'm just
>dense
>(most probably even since I've got a bad cold). I try
>something like this:
>
>use VMS::Queue;
>%entry_cond = {jobname=>"BATSER"};
>@entries = VMS::Queue::entry_list(\%entry_cond);
>for ($i==0;$i<=$#entries;$i++) {print $entries[$i], "\n"};
>
>\%entryprop = VMS::Queue::entry_info($entries[0]);
>print \$entryprop{"jobname"},
>foreach $prop (keys(%entryprop)) { printf "%s: %s\n", $prop,
>\$entryprop{$prop};}
The docs are misleading for some of the calls. entry_info returns a hash
reference, which was what I was trying to indicate in the summary, but it
really isn't at all clear. (Plus it's syntactically meaningless...)
Change that to:
$entryprop = VMS::Queue::entry_info($entries[0]);
print $entryprop->{JOBNAME};
and I think you'll find it works better.
I'll update the docs and see about getting a new version on CPAN soon.
(And, FWIW, I found out why none of the VMS modules show up on
search.cpan.com--that might get fixed soon)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
[PATCH MMK3.8-1] dependancy fixups
About the most complex thing I use MMK for is building Perl and its associated extensions. I've run across two cases where MMS handles a DESCRIP.MMS with no problem, but MMK has difficulties. In both cases, implicit rules are implicated. Since Perl builds use automated procedures to create DESCRIP.MMS files (or makefiles, on Unix), it's generally not useful to "edit DESCRIP.MMS" as a workaround...such editting will be detected and the DESCRIP.MMS regenerated. And the authors (mostly on Unix systems) of the software are not particularly sympathetic about making changes to accomodate "broken utilities". So, first let me describe some test cases...these are greatly simplified from the original problematic DESCRIP.MMS, and they certainly not what you would write yourself. But they do exercise the problems. Example 1: A.C does an #include of B.C --- A.OBJ : B.C .C.OBJ : CC $(MMS$SOURCE) --- MMS results:CC A.C (Unix make does the same) MMK results CC B.C ---error message about A.OBJ not being updated What's happening here is that MMK is interpreting the implicit rule .C.OBJ as applying even if the .C and the .OBJ have different "stem" names, and that B.C should be used to create A.OBJ. This is at odds with the usual interpretation of makefiles. The first line of Example 1 DESCRIP.MMS merely states that A.OBJ should be rebuilt if it is older than B.C (not that B.C is used in the rebuilding). The rest of DESCRIP.MMS gives an implicit rule for building a file x.OBJ from x.C. We don't need to use a /OBJ=... on the compile because the implicit rule only applies to .C and .OBJ files with the same "stem" filename. Example 2A: Building .OBJ from .XS with missing intermediate file .SUFFIXES .OBJ .C .XS A.OBJ : (some other junk) .C.OBJ : CC $(MMS$SOURCE) .XS.C : PERL (blah) $(MMS$SOURCE) >$(MMS$TARGET) MMS/make results: PERL (blah) A.XS >A.C CC A.C MMK results:no source file A.C This situation can also occur when we have an explicit rule for building A.C: Example 2B: Building .OBJ from .XS with missing intermediate file .SUFFIXES .OBJ .C .XS A.OBJ : (some other junk) .C.OBJ : CC $(MMS$SOURCE) A.C : A.XS PERL (blah) $(MMS$SOURCE) >$(MMS$TARGET) What's happening is that after attempting to apply the implicit .C.OBJ rule, MMK isn't looking further to see if there is an explicit or implicit rule that would allow it to build A.C if one does not already exist. All of the above examples are easily made to work with simple changes, but (especially in the case of automatically generated DESCRIP.MMS files) it really would be better if MMK would "do the right thing". So here's a patch to MMK 3.8-1 to (a) not use dependancy files when processing implicit rules and (b) recurse through implicit rules until a source file or explicit rule is found that will allow building the target. Nearly all of the changes are in the routine Fill_In_Missing_Sources. There's a minor change in scan_rule_list because we need to find an appropriate rule even if the source file for that rule doesn't exist (yet). Please give this patch a good thorough workout; the two largest packages I've used it on were MMK itself and Perl+extensions. In particular, I haven't done any testing with CMS because I don't have CMS on my system. To put this in proper perspective, these are subtle problems with an overwhelmingly excellent piece of software. diff -uBb misc.c-orig misc.c --- misc.c-orig Fri Dec 22 08:04:38 2000 +++ misc.c Fri Dec 22 08:05:54 2000 @@ -627,8 +627,11 @@ char trgnam[MMK_S_FILE], tmpsfx[MMK_S_SFX], fspec[MMK_S_FILE], *cp; unsigned int status; int pass, passmax, check_cms, trgnamlen, maybes, i; +int nofileok; maybes = 0; +nofileok = (generalize & 0x10) != 0; +generalize = generalize & 0x0F; /* ** When there's just one rule for this suffix pair, we want to avoid @@ -641,6 +644,8 @@ ** _just_ the prefixed rules. When we call with generalize == 2, we ** want to check _just_ the non-prefixed rules. ** +** when we call with generalize +16, we don't care if the file exists. +** ** Phew! Now I understand why NMAKE doesn't have generic rules that ** work across directories. */ @@ -690,6 +695,7 @@ memcpy(fspec+r->srcpfxlen, trgnam, trgnamlen); strcpy(fspec+(r->srcpfxlen+trgnamlen), r->src); if (check_cms) status = cms_get_rdt(fspec, 0, &rdt); + else if (nofileok) status = 1; else status = file_exists(fspec, 0); if (OK(status)) break; /* d
Re: perl@8211: Encode encounters MakeMaker trouble on VMS
Peter Prymmer <[EMAIL PROTECTED]> writes: > On Wed, 20 Dec 2000, Craig A. Berry wrote: > >> At 01:39 PM 12/20/2000 -0800, Peter Prymmer wrote: >> >%MMS-F-GWKNOPRN, There are no known sources for the current target >> >MAKEFILE. >> >%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE8064. >> > >> >Craig - did you not mention that you had a MM_VMS.pm or Makefile.PL fix >> >for this particular problem? >> ... >> >> The third issue doesn't seem to occur with MMS but only with MMK. If you >> have foo$(obj_ext) in a source list for one dependency and foo.c as the >> target in another dependency, it doesn't figure out the implicit action, in >> this case compiling foo.c to get foo.obj. You end up getting a "sources >> unknown" error for foo.obj. I did some mucking about with MMK this morning; there's one routine in particular that is the source of all of our problems: Fill_In_Missing_Sources. I think I have a patch for it...good enough to build MMK, Perl, Encode, and some test cases. It recurses through the suffix list, looking for explicit and implicit rules that will yield the target file, perhaps using a `chain' of implicit rules with intermediate files. I'll post the diff here, on the Madgoat list, and on www.crinoid.com a little later today. (as a side note, I'm not surprised that there are these problems; there's some very complex stuff going on inside of MMK) After making the changes in ext/Encode/Makefile.PL (except for the extra dependancies, don't need them with a fixed MMK) then the build works fine. But I am getting a test failure for lib/encode.t, the usual one (test 2694 out of 1..2693) that results from having extraneous test output. Seems that someone put a warn "Loading $file"; in Encode.pm just to let us know when a file is loaded. Bleah. Is it just me (and test.com) that doesn't like modules spitting out gratuitous messages? -- Drexel University \V--Chuck Lane ==]-->*<---[=== (215) 895-1545 _/ \ Particle Physics FAX: (215) 895-5934 /\ /~~~[EMAIL PROTECTED]
Re: VMS::Queue example ?
Here's two of my peices of choppy code (QUEUETEST, ENTRYTEST) back from
when I was figuring out VMS::Queue myself.
Obviously, they aren't the prettiest, but they do exercise a lot of
VMS::Queue, which may help you figure it out.
Also, here's the module I was really wanting to get when I was messing
with the two examples (SUBMITJOB.PM). In it a provide to perl subs, one
to submit some random DCL to a queue, and one to submit some DCL, and
wait for it to complete. Parameters are the DCL to submit, and then
optional queue name, optional user to submit as, optionally specify a
temp file name to use, and optionally specify a log file.
I really should have coded these routines to take a sparse hash (e.g.
submitjob ({CMD=>"$ show date", LOGFILE=>'sys$scratch:foo.log'})
instead of using positional parameters, but I was still learning perl at
the time.
-- Pat
Martin Zinser wrote:
>
> Hello!
>
> I just started to play around with VMS::Queue and may be I'm just
> dense
>(most probably even since I've got a bad cold). I try
> something like this:
>
> use VMS::Queue;
> %entry_cond = {jobname=>"BATSER"};
> @entries = VMS::Queue::entry_list(\%entry_cond);
> for ($i==0;$i<=$#entries;$i++) {print $entries[$i], "\n"};
>
> \%entryprop = VMS::Queue::entry_info($entries[0]);
> print \$entryprop{"jobname"},
> foreach $prop (keys(%entryprop)) { printf "%s: %s\n", $prop,
> \$entryprop{$prop};}
>
>Which works fine in the first part (i.e. finds the correct
> queue entry for job
>BATSER), but does not give the properties of the job in
> part 2. Does
>anyone maybe have a working example using VMS::Queue to
> enlighten me?
>
> Thanks a lot, Martin
>
> P.S. OpenVMS Alpha 7.2.1, Perl 5.6.0, VMS::Queue 0.56
--
This message does not represent the policies or positions
of the Mayo Foundation or its subsidiaries.
Patrick Spinler email: [EMAIL PROTECTED]
Mayo Foundation phone: 507/284-9485
queuetest.pl
entrytest.pl
package Submitjob;
BEGIN {
use Exporter ();
use vars qw($VERSION @ISA @EXPORT @EXPORT_OK %EXPORT_TAGS);
# set the version for version checking
$VERSION = 1.00;
# if using RCS/CVS, this may be preferred
# must be all one line, for MakeMaker
$VERSION = do {my @r = (q$Revision: 1.00 $ =~ /\d+/g); sprintf "%d."."%02d" x $#r,
@r};
@ISA = qw(Exporter);
@EXPORT = qw( );
%EXPORT_TAGS = ( ); # eg: TAG => [ qw!name1 name2! ],
# your exported package globals go here,
# as well as any optionally exported functions
@EXPORT_OK = qw( &submit_job &submit_and_wait );
}
use vars @EXPORT_OK;
# non-exported package globals go here
use vars qw($status);
use strict;
use diagnostics;
use English;
use File::Copy;
use POSIX qw( &cuserid &getpid );
use VMS::Priv;
use VMS::Stdio qw ( &tmpnam );
use VMS::Process qw( &process_list &get_all_proc_info_items );
use VMS::Filespec qw( &rmsexpand &vmsify &unixify );
use VMS::Queue qw( &queue_info &submit &entry_info &entry_bitmap_decode );
use File::Spec::VMS q( catfile catdir );
#==[ submit_job ]==
#
# Submit a DCL string
#
# --- parameters ---
#
# String containing cmd file to submit (eg, my $cmd = q{$ write sys$output hi"};
# Optional string containing queue to submit to, SYS$BATCH if blank/empty
# Optional string containing name specification where command string
#will be written to
# Optional string containing log file specification
# Optional string containing user to submit job as
#
# --- return value ---
#
# Ref to entry_info() hash on success
# Throw a die() on failure
#
sub submit_job
{
my ($cmdstr, $queue, $cmdfilespec, $logfilespec, $user) = @_;
$queue = 'SYS$BATCH' if (!defined ($queue) || $queue eq '');
$cmdfilespec = &tmpnam() . ".com"
if (!defined $cmdfilespec || $cmdfilespec eq '');
$user = &cuserid() if (!defined $user || $user eq '');
$logfilespec = '' if (!defined $logfilespec);
if (cuserid() !~ m/$user/i)
{
my %privset;
tie (%privset, 'VMS::Priv');
$privset{"CMKRNL"} = 1;
die "Error $!:$^E setting needed privs" if (!defined $privset{"CMKRNL"});
}
print ("Submitting to $queue as $user with log $logfilespec\n");
print ("Commands in $cmdfilespec\n");
print ("\n$cmdstr\n\n");
my $entry =
{
"QUEUE" => $queue,
};
if ($user ne cuserid()) {$entry->{"USERNAME"} = $user;}
if ($logfilespec ne '')
{
$entry->{"LOG_SPECIFICATION"} = rmsexpand ($logfilespec);
$entry->{"NO_LOG_DELETE"} = 1;
$entry->{"NO_LOG_SPOOL"} = 1;
}
my $entryfile =
{
"FILE_SPECIFICATION" => $cmdfilespec,
};
open (OUTFILE, ">$cmdfilespec") || die ("Error $!:$^E opening $
VMS::Queue example ?
Hello!
I just started to play around with VMS::Queue and may be I'm just
dense
(most probably even since I've got a bad cold). I try
something like this:
use VMS::Queue;
%entry_cond = {jobname=>"BATSER"};
@entries = VMS::Queue::entry_list(\%entry_cond);
for ($i==0;$i<=$#entries;$i++) {print $entries[$i], "\n"};
\%entryprop = VMS::Queue::entry_info($entries[0]);
print \$entryprop{"jobname"},
foreach $prop (keys(%entryprop)) { printf "%s: %s\n", $prop,
\$entryprop{$prop};}
Which works fine in the first part (i.e. finds the correct
queue entry for job
BATSER), but does not give the properties of the job in
part 2. Does
anyone maybe have a working example using VMS::Queue to
enlighten me?
Thanks a lot, Martin
P.S. OpenVMS Alpha 7.2.1, Perl 5.6.0, VMS::Queue 0.56
