How to make env-vars effective on return from perl module subrtn ?

[Owen_Townsend]

How can I make env-vars set in package subrtns effective on return to
perl script ?
I have included testenv1.pl & testexport1.pm below
testenv1.pl calls subrtn exportfile in testexport1.pm to set env-var
LOGICALfilename=PhysicalFileName
- this works for Micro Focus COBOL programs with 'external' on the
select assign statements
- BUT why does it not work for $symbols referenced in the perl script ?
- I specify 'use Env;' which should make env-vars available to perl
script ?
- which works for symbols such as $HOME already set,
- but does not seem to work for $SYMBOLs set in the subrtn
- makes no sense if COBOL can get it (via getenv I assume) why not the
perl script ?

#!/usr/bin/perl
# testenv1 - perl script to test 'use Env'
# - why efective only for symbols already in env
# - why NOT for symbols added to env by script ???
use Env; use testexport1;
print("HOME=$HOME\n"); #<-- 'use Env' works for symbols already defined
exportfile("SORTIN","ar/sales.items"); #<-- subrtn adds SORTIN to env
#=====================================
# - exportfile subrtn adds $SYMBOLS to the environment
# - effective for COBOL which gets symbol defs from environment
# cobrun program <-- my COBOL programs do see $SYMBOLs set in
exportfile subrtn
#===========
# - BUT why are these $SYMBOLS not seen by perl script ? (via 'use
Env;') ?
print("DEBUG1: SORTIN=$SORTIN\n"); #<-- $SORTIN is still null ?
$SORTIN = $ENV{SORTIN}; #<-- redefine here (already done in subrtn)
print("DEBUG2: SORTIN=$SORTIN\n"); #<-- now we see it
exit(0);
#
#-----------------------------------------------------------------------
# testexport1.pm - perl subrtns to support perl scripts converted from
MVS JCL
# - see doc at: www.uvsoftware.ca/mvs2unix.htm
# - export files for Micro Focus COBOL
# - export LOGICAL-filename $SYMBOLS with
physical-filenames
#
# profile should include following so perl modules will be found
# export PERL5LIB=$UV/perlm:$PERL5LIB # perl modules 'use'd by perl
scripts
# ===================================
#
package testexport1;
use Env; Exporter;
our (@Export, @ISA);
@ISA = qw(Exporter);
@EXPORT = qw(exportfile);
#
# exportfile CUSTMAS ap/customer.master #<-- JCL/script call
# =====================================
# export CUSTMAS=ap/customer.master #<-- result
# =================================
#Note - main reason for using this function (vs coding export directly)
# is to display the DDname & DSNname on the console log
#
sub exportfile
{
$lfd=$_[0]; $lbl=$_[1]; # capture args into named variables
#
if ( "$lfd" && "$lbl" ) { ; }
else { print("exportfile requires 2 args: DDNname=$lfd,
DSName=$lbl\n");
exit(81);
}
#
$ENV{$lfd} = "$lbl"; # export LogicalName = PhysicalName
#=================== # COBOL programs need LFD in environment
#
# display lfd & lbl with filesize
$fsize = (-s "$RUNDATA/$lbl");
$fmsg = sprintf("file: %s=%s bytes=%d",$lfd,$lbl,$fsize);
print("$fmsg\n");
return(0);
}

 

[A. Sinan Unur]

How can I make env-vars set in package subrtns effective on return to
perl script ?

The code you included below is quite cluttered and I am not in the mood
to go through and reformat it right now.

However, I figure, the following Frequently Asked Question might be
relevant:

D:\Src> perldoc -q env
Found in C:\opt\Perl\lib\pod\perlfaq8.pod
I {changed directory, modified my environment} in a perl script.
How come the change disappeared when I exited the script?
How do I get my changes to be visible?

* Please revise your code to compile cleanly with:

use strict;
use warnings;

both at the script and module level before posting again.

* Please make sure lines do not wrap and there are no freestanding
remarks in the middle of the code so that others can run it by simply
copying and pasting.

Sinan

--
A. Sinan Unur <[email protected]>
(remove .invalid and reverse each component for email address)

comp.lang.perl.misc guidelines on the WWW:
http://augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html

 

[kenslaterpa]

How can I make env-vars set in package subrtns effective on return to
perl script ?
I have included testenv1.pl & testexport1.pm below
testenv1.pl calls subrtn exportfile in testexport1.pm to set env-var
LOGICALfilename=PhysicalFileName
- this works for Micro Focus COBOL programs with 'external' on the
select assign statements
- BUT why does it not work for $symbols referenced in the perl script ?
- I specify 'use Env;' which should make env-vars available to perl
script ?
- which works for symbols such as $HOME already set,
- but does not seem to work for $SYMBOLs set in the subrtn
- makes no sense if COBOL can get it (via getenv I assume) why not the
perl script ?

#!/usr/bin/perl
# testenv1 - perl script to test 'use Env'
# - why efective only for symbols already in env
# - why NOT for symbols added to env by script ???
use Env; use testexport1;
print("HOME=$HOME\n"); #<-- 'use Env' works for symbols already defined
exportfile("SORTIN","ar/sales.items"); #<-- subrtn adds SORTIN to env
#=====================================
# - exportfile subrtn adds $SYMBOLS to the environment
# - effective for COBOL which gets symbol defs from environment
# cobrun program <-- my COBOL programs do see $SYMBOLs set in
exportfile subrtn
#===========
# - BUT why are these $SYMBOLS not seen by perl script ? (via 'use
Env;') ?
print("DEBUG1: SORTIN=$SORTIN\n"); #<-- $SORTIN is still null ?
$SORTIN = $ENV{SORTIN}; #<-- redefine here (already done in subrtn)
print("DEBUG2: SORTIN=$SORTIN\n"); #<-- now we see it
exit(0);
#
#-----------------------------------------------------------------------
# testexport1.pm - perl subrtns to support perl scripts converted from
MVS JCL
# - see doc at: www.uvsoftware.ca/mvs2unix.htm
# - export files for Micro Focus COBOL
# - export LOGICAL-filename $SYMBOLS with
physical-filenames
#
# profile should include following so perl modules will be found
# export PERL5LIB=$UV/perlm:$PERL5LIB # perl modules 'use'd by perl
scripts
# ===================================
#
package testexport1;
use Env; Exporter;
our (@Export, @ISA);
@ISA = qw(Exporter);
@EXPORT = qw(exportfile);
#
# exportfile CUSTMAS ap/customer.master #<-- JCL/script call
# =====================================
# export CUSTMAS=ap/customer.master #<-- result
# =================================
#Note - main reason for using this function (vs coding export directly)
# is to display the DDname & DSNname on the console log
#
sub exportfile
{
$lfd=$_[0]; $lbl=$_[1]; # capture args into named variables
#
if ( "$lfd" && "$lbl" ) { ; }
else { print("exportfile requires 2 args: DDNname=$lfd,
DSName=$lbl\n");
exit(81);
}
#
$ENV{$lfd} = "$lbl"; # export LogicalName = PhysicalName
#=================== # COBOL programs need LFD in environment
#
# display lfd & lbl with filesize
$fsize = (-s "$RUNDATA/$lbl");
$fmsg = sprintf("file: %s=%s bytes=%d",$lfd,$lbl,$fsize);
print("$fmsg\n");
return(0);
}

I would follow Sinan's advice on using strict and warnings.
Also, do a "perldoc Env". It indicates that >>existing<< environment
variables
are tied to global variables (with suitable names).
Since "SORTIN" did not exist, it was not tied to a global variable.
You could get around this by with
use Env qw(SORTIN);
or issue an explicit call to Env::import after defining $ENV{SORTIN}.
Ken

 

[anno4000]

Read the documentation of the Env module again. Per default it only
imports environment variables that already exist when it is called.

Right. That's a documented fact. Call it as

use Env qw( SORTIN); # untested

which is also documented.

Your question is answered clearly in the documentation of the module
you're using. Why didn't you read it?

Anno

 

[Owen_Townsend]

Thanks to all above (Sinan Unar, kenslate,& anno4) for good advice.
I should have explained what I amn trying to do here.
I am converting mainframe JCL to perl scripts to run on unix/linux.
My objective was to define files for COBOL using just 1 line per file,
since there could be many files prior to each COBOL program execution.
I think now I need 2 lines per file as follows:

1. exportfile("SORTIN","ar/sales.items"); # subrtn adds SORTIN to env
#===================================== # via: $ENV{$_[0]} =
"$_[1]";
2a. use Env ("SORTIN"); # suggested by kenslate & anno4 <-- IT
WORKS
#==================
2b. $SORTIN = $ENV{SORTIN}; # OR I could use this (less overhead ?)
#======================

I think I should probably use '2b.' above as the 2nd line,
since I assume there would be less overhead.
I am fairly new to perl & I got something useful from all who replied.
I was converting JCL to Korn shell scripts & am now changing over to
perl.
If interested please see www.uvsoftware.ca/mvsjcl.htm
and I will soon have a new doc called mvsjclperl.htm.
Thanks again to all the respondents above.

Owen

 

[Stephan Titard]

Owen_Townsend escribió:

Thanks to all above (Sinan Unar, kenslate,& anno4) for good advice.
I should have explained what I amn trying to do here.
I am converting mainframe JCL to perl scripts to run on unix/linux.
My objective was to define files for COBOL using just 1 line per file,
since there could be many files prior to each COBOL program execution.
I think now I need 2 lines per file as follows:

1. exportfile("SORTIN","ar/sales.items"); # subrtn adds SORTIN to env
#===================================== # via: $ENV{$_[0]} =
"$_[1]";
2a. use Env ("SORTIN"); # suggested by kenslate & anno4 <-- IT
WORKS
#==================
2b. $SORTIN = $ENV{SORTIN}; # OR I could use this (less overhead ?)
#======================

I think I should probably use '2b.' above as the 2nd line,
since I assume there would be less overhead.
I am fairly new to perl & I got something useful from all who replied.
I was converting JCL to Korn shell scripts & am now changing over to
perl.
If interested please see www.uvsoftware.ca/mvsjcl.htm
and I will soon have a new doc called mvsjclperl.htm.
Thanks again to all the respondents above.

Owen

hi, maybe a better approach which is not confined to perl, is to dump
all the env-vars to a file, and use that file as a config file for the
*other* tool (perl in this case...)
env-vars are often over-used, and kind of dangerous if you do not use a
startup script which takes care of initializing your program whith the
only required env-vars: don't rely on profiles and such
hth
--stephan