HFS sharing and rolling product upgrades
Hello,
How do you gradually roll changes to CICS, MQ and DB2 versions that change
these products' HFS dataset one system at a time?
We currently share our BPXPRMxx member between two LPARs running in Sysplex
with SYSPLEX(YES).
Our CICS guys want to upgrade the CICS version one LPAR at a time (a reasonable
request), and that means that they want to change the CICS HFS pointed to by
the /usr/lpp/cicsts/cicsts32 mount point, but only on one system.
In other words they want to do something like this:
BPXPRMxx:
MOUNT FILESYSTEM('OMVS.&CICSVER.CICS32')
MOUNTPOINT('/usr/lpp/cicsts/cicsts32')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
Where &CICSVER resolves to RSU1109 on SY1 LPAR and to RSU1110 on SY2 LPAR.
I don't think this is possible, but I do want to provide them the option to
roll the change one LPAR at a time, prefferably without making changes to CICS.
Is there a way where we can support that?
Regards,
Nofar Spalter
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
Nofar, what you want to do is completely possible and in fact we do exactly
that:
/* The following file supports CICS*/
MOUNT FILESYSTEM('CICS.&SYSNAME..&CICSLVL..ZFS')
MOUNTPOINT('/$SYSNAME/cicsts')
TYPE(ZFS) MODE(RDWR) SYSNAME(&SYSNAME) UNMOUNT PARM('NORWSHARE')
The only thing you need to change is to add an extra period after &CICSVER:
BPXPRMxx:
MOUNT FILESYSTEM('OMVS.&CICSVER..CICS32')
MOUNTPOINT('/usr/lpp/cicsts/cicsts32')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
Mary Anne
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Nofar Spalter
> Sent: Thursday, October 27, 2011 3:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: HFS sharing and rolling product upgrades
>
> Hello,
> How do you gradually roll changes to CICS, MQ and DB2
> versions that change these products' HFS dataset one system at a time?
> We currently share our BPXPRMxx member between two LPARs
> running in Sysplex with SYSPLEX(YES).
> Our CICS guys want to upgrade the CICS version one LPAR at a
> time (a reasonable request), and that means that they want to
> change the CICS HFS pointed to by the
> /usr/lpp/cicsts/cicsts32 mount point, but only on one system.
> In other words they want to do something like this:
>
> BPXPRMxx:
> MOUNT FILESYSTEM('OMVS.&CICSVER.CICS32')
> MOUNTPOINT('/usr/lpp/cicsts/cicsts32')
> TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
>
> Where &CICSVER resolves to RSU1109 on SY1 LPAR and to RSU1110
> on SY2 LPAR.
>
> I don't think this is possible, but I do want to provide them
> the option to roll the change one LPAR at a time, prefferably
> without making changes to CICS.
>
> Is there a way where we can support that?
>
> Regards,
> Nofar Spalter
Have you looked at & considered: "Mounting file systems using symbolic links"?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb2b0/7.14
The commands to use would be something like:
cd /usr/lpp/cicsts
mkdir RSU1109
mkdir RSU1101
ln -s '$SYSSYMR/&CICSVER' cicsts32
Now, I don't use UNIX sysplex filesystem sharing, but I think you could do a
mount similar to:
MOUNT FILESYSTEM('OMVS.&CICSVER.CICS32')
MOUNTPOINT('/usr/lpp/cicsts/&CICSVER.')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
Question: Is a period missing? Wouldn't you need 'OMVS.&CICSVER..CICS32' ???
Or was it a typo on your part?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
>
> Nofar, what you want to do is completely possible and in fact we do
exactly that:
>
>
> /* The following file supports CICS*/
> MOUNT FILESYSTEM('CICS.&SYSNAME..&CICSLVL..ZFS')
> MOUNTPOINT('/$SYSNAME/cicsts')
> TYPE(ZFS) MODE(RDWR) SYSNAME(&SYSNAME) UNMOUNT PARM('NORWSHARE')
>
>
> The only thing you need to change is to add an extra period after
&CICSVER:
Mary Anne -
Is this working because you have a SYSPLEX root rather than just general
roots?
In our shop we do not have a SYSPLEX root nor do we have SYSPLEX(YES) coded
in BPXPRMxx, so I am not sure that your process would work for us. We mount
each set of HFS/zFS files inside the OMVS.ROOT dataset shipped by IBM. So I
am not sure if the $SYSNAME would be valid for us.
Lizette
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
We use symbolic links extensively for this purpose. In the configuration files
for each platform we put a path statement with the platform name in it:
/CICS/platform1
/CICS/platform2
We create a directory /CICS/
Then we create symbolic links in that directory for each platform that points
to the CICS release to use for that platform
/CICS/platform1 >> /CICSVxRy
/CICS/platform2 >> /CICSVqRz
We mount the zFSes for each release on a different directory
/CICSVxRy has CICS.VxRy.ZFS
/CICSVqRz has CICS.VqRz.ZFS
When we want to change the release we only have to change the directory that
the symbolic link points to.
If you want to discuss you can contact me off list.
Thanks,
Jon
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of
McKown, John
Sent: Thursday, October 27, 2011 8:24 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: HFS sharing and rolling product upgrades
> -Original Message-
> From: IBM Mainframe Discussion List
> [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Nofar Spalter
> Sent: Thursday, October 27, 2011 3:19 AM
> To: IBM-MAIN@bama.ua.edu
> Subject: HFS sharing and rolling product upgrades
>
> Hello,
> How do you gradually roll changes to CICS, MQ and DB2 versions that
> change these products' HFS dataset one system at a time?
> We currently share our BPXPRMxx member between two LPARs running in
> Sysplex with SYSPLEX(YES).
> Our CICS guys want to upgrade the CICS version one LPAR at a time (a
> reasonable request), and that means that they want to change the CICS
> HFS pointed to by the
> /usr/lpp/cicsts/cicsts32 mount point, but only on one system.
> In other words they want to do something like this:
>
> BPXPRMxx:
> MOUNT FILESYSTEM('OMVS.&CICSVER.CICS32')
> MOUNTPOINT('/usr/lpp/cicsts/cicsts32')
> TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
>
> Where &CICSVER resolves to RSU1109 on SY1 LPAR and to RSU1110 on SY2
> LPAR.
>
> I don't think this is possible, but I do want to provide them the
> option to roll the change one LPAR at a time, prefferably without
> making changes to CICS.
>
> Is there a way where we can support that?
>
> Regards,
> Nofar Spalter
Have you looked at & considered: "Mounting file systems using symbolic links"?
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/bpxzb2b0/7.14
The commands to use would be something like:
cd /usr/lpp/cicsts
mkdir RSU1109
mkdir RSU1101
ln -s '$SYSSYMR/&CICSVER' cicsts32
Now, I don't use UNIX sysplex filesystem sharing, but I think you could do a
mount similar to:
MOUNT FILESYSTEM('OMVS.&CICSVER.CICS32')
MOUNTPOINT('/usr/lpp/cicsts/&CICSVER.')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
Question: Is a period missing? Wouldn't you need 'OMVS.&CICSVER..CICS32' ???
Or was it a typo on your part?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone *
john.mck...@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or
proprietary information. If you are not the intended recipient, please contact
the sender by reply e-mail and destroy all copies of the original message.
HealthMarkets(r) is the brand name for products underwritten and issued by the
insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance
Company(r), Mid-West National Life Insurance Company of TennesseeSM and The
MEGA Life and Health Insurance Company.SM
--
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at
http://bama.ua.edu/archives/ibm-main.html
This e-mail may contain confidential or privileged information. If
you think you have received this e-mail in error, please advise the
sender by reply e-mail and then delete this e-mail immediately.
Thank you. Aetna
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
Lizette, I see where that is confusing. I should have taken out the sysname stuff and just answered his question with the CICSLVL substitution. We do have a sysplex root, but I don't think that is what makes this work. In your case, I think it would work if you had our symbolic in /SYSR51/usr/lpp/cicsts which is $SYSNAME/cicsts. MA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
If you run multiple releases of CICS on a single image, you might want to
change that slightly:
cd /usr/lpp/cicsts
mkdir cicsts32-RSU1109
mkdir cicsts32-RSU1110
mkdir cicsts41-RSU1109 #assuming there is an RSU1109 for CICS/TS 4.1
mkdir cicsts41-RSU1110 #similar to above
ln -s '$SYSSYMR/cicsts32-&CICSVER.' cicsts32
ln -s '$SYSSYMR/cicsts41-&CICSVER.' cicsts41
What might be even more interesting would be if the
release-to-use-on-this-image of CICS were in &CICVER and the RSU for that
release was in &CICSRSU. Now, if you run multiple versions/RSUs on one image,
make some more static symbols. One for the desired RSU for each CICS release.
Examples: &RSUCV32 and &RSUCV41.
mkdir CICSTS32-RSU1109
mkdir CICSTS32-RSU1110
mkdir CICSTS41-RSU1109
mkdir CICSTS41-RSU1110
ln -s '$SYSSYMR/&CICSVER.-&CICSRSU.' local
ln -s '$SYSSYMR/CICSTS32-&RSUCV32' cicsts32
ln -s '$SYSSYMR/CICSTS41-&RSUCV41' cicsts41
and then use /usr/lpp/cicsts/local instead of /usr/lpp/cicsts/cicsts32. That
gets you the recommended CICS version and RSU for this z/OS image. If you use
/usr/lpp/cicsts/cicsts32, you get the desired RSU for release 3.2 on this z/OS
image. If you use /usr/lpp/cicsts/cicsts41, you get the desired RSU for release
4.1 on this z/OS image.
In BPXPRMxx:
MOUNT FILESYSTEM('OMVS.&CICSRSU..&CICSVER.')
MOUNTPOINT('/usr/lpp/cicsts/&CICSVER.-&CICSRSU.')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
If you wanted to, you could simply have one MOUNT for every existant CICS-RSU
that you have
MOUNT FILESYSTEM('OMVS.RSU1109.CICSTS32')
MOUNTPOINT('/usr/lpp/cicsts/CICSTS32-RSU1109')
TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
and duplicate the above for each CICS/RSU combination you have.
In IEASYMxx:
SYMDEF(&CICSVER='CICSTS32')
SYMDEF(&CICSRSU='RSU1110')
SYMDEF(&RSUCV32='RSU1110')
SYMDEF(&RSUCV41='RSU1109')
Now, combine this with some nifty catalog SYMBOLICRELATE type ALIASes, you
could do:
DEFINE ALIAS(NAME('CICSTS.rest.of.dsn') -
SYMBOLICRELATE('&CICSVER..rest.of.dsn'))
But I hear your complaint. "Oh, damn! I have to do a LISTCAT and then code up
all those DEFINEs. What a PITA!" I agree. So why bother? Do it the easy way.
Install Dovetailed Technologies set of "free to download and use" Co:Z
products. They are excellent and did I mention you can download and use them
FOR NO COST or signed license? You don't even need to fill out a form to be
approved. Did you know that the JZOS currently distributed by IBM with their
Java was originally from Dovetailed? Brilliant people. Nice people, too! (Hi,
Kirk!) So, once you've installed at least the dataset pipes portion of Co:Z,
you can run a simple UNIX shell script to create the DEFINE ALIAS commands for
you!
catsearch cicsts*.** |\
cut -d '.' -f 2- |\
sort -u |\
while read i;do
echo " DEFINE ALIAS(NAME(CICSTS.$i) -"
echo " SYMBOLICRELATE(&CICSVER..$i))";
done>idcams.sysin
cat >idcams.jcl
Re: HFS sharing and rolling product upgrades
John,
Thanks for your kind words. Much of what we offer owes large success to
pesky users who send us feedback and suggestions :-)
Your example reminds me that eventually we would like to add an "idcams"
shell command, which would allow:
catsearch cicsts*.** |\
cut -d '.' -f 2- |\
sort -u |\
while read i;do
echo " DEFINE ALIAS(NAME(CICSTS.$i) -"
echo " SYMBOLICRELATE(&CICSVER..$i))"
done | idcams
Of course, if you like batch, this would easily run under COZBATCH :-)
FWIW, you may have noticed that there is a com.ibm.jzos.AccessMethodServices
class that provides a callable IDCAMS interface from Java.
Cheers,
Kirk Wolf
Dovetailed Technologies
http://dovetail.com
PS> consider using awk to build job to do the whole thing in a pipeline
without temp files.
*Something* like:
catsearch cicsts*.** |\
cut -d '.' -f 2- |\
sort -u |\
awk '
BEGIN {
print "//JOBNAME JOB (ACCT),PGMR,CLASS=A,MSGCLASS=H";
print "//IDCAMS EXEC PGM=IDCAMS";
print "//SYSPRINT DD SYSOUT=*";
print "//SYSIN DD *";
} {
print " DEFINE ALIAS(NAME(CICSTS.",$1,") -";
print " SYMBOLICRELATE(&CICSVER..",$1,"))";
} END {
print "//"
}' |\
submit -j
On Thu, Oct 27, 2011 at 9:08 AM, McKown, John wrote:
> If you run multiple releases of CICS on a single image, you might want to
> change that slightly:
>
> cd /usr/lpp/cicsts
> mkdir cicsts32-RSU1109
> mkdir cicsts32-RSU1110
> mkdir cicsts41-RSU1109 #assuming there is an RSU1109 for CICS/TS 4.1
> mkdir cicsts41-RSU1110 #similar to above
> ln -s '$SYSSYMR/cicsts32-&CICSVER.' cicsts32
> ln -s '$SYSSYMR/cicsts41-&CICSVER.' cicsts41
>
> What might be even more interesting would be if the
> release-to-use-on-this-image of CICS were in &CICVER and the RSU for that
> release was in &CICSRSU. Now, if you run multiple versions/RSUs on one
> image, make some more static symbols. One for the desired RSU for each CICS
> release. Examples: &RSUCV32 and &RSUCV41.
>
> mkdir CICSTS32-RSU1109
> mkdir CICSTS32-RSU1110
> mkdir CICSTS41-RSU1109
> mkdir CICSTS41-RSU1110
> ln -s '$SYSSYMR/&CICSVER.-&CICSRSU.' local
> ln -s '$SYSSYMR/CICSTS32-&RSUCV32' cicsts32
> ln -s '$SYSSYMR/CICSTS41-&RSUCV41' cicsts41
>
> and then use /usr/lpp/cicsts/local instead of /usr/lpp/cicsts/cicsts32.
> That gets you the recommended CICS version and RSU for this z/OS image. If
> you use /usr/lpp/cicsts/cicsts32, you get the desired RSU for release 3.2 on
> this z/OS image. If you use /usr/lpp/cicsts/cicsts41, you get the desired
> RSU for release 4.1 on this z/OS image.
>
> In BPXPRMxx:
>
> MOUNT FILESYSTEM('OMVS.&CICSRSU..&CICSVER.')
> MOUNTPOINT('/usr/lpp/cicsts/&CICSVER.-&CICSRSU.')
> TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
>
> If you wanted to, you could simply have one MOUNT for every existant
> CICS-RSU that you have
>
> MOUNT FILESYSTEM('OMVS.RSU1109.CICSTS32')
> MOUNTPOINT('/usr/lpp/cicsts/CICSTS32-RSU1109')
> TYPE(HFS) MODE(READ) AUTOMOVE(INCLUDE,*)
>
> and duplicate the above for each CICS/RSU combination you have.
>
> In IEASYMxx:
>
> SYMDEF(&CICSVER='CICSTS32')
> SYMDEF(&CICSRSU='RSU1110')
> SYMDEF(&RSUCV32='RSU1110')
> SYMDEF(&RSUCV41='RSU1109')
>
> Now, combine this with some nifty catalog SYMBOLICRELATE type ALIASes, you
> could do:
>
> DEFINE ALIAS(NAME('CICSTS.rest.of.dsn') -
> SYMBOLICRELATE('&CICSVER..rest.of.dsn'))
>
> But I hear your complaint. "Oh, damn! I have to do a LISTCAT and then code
> up all those DEFINEs. What a PITA!" I agree. So why bother? Do it the easy
> way. Install Dovetailed Technologies set of "free to download and use" Co:Z
> products. They are excellent and did I mention you can download and use them
> FOR NO COST or signed license? You don't even need to fill out a form to be
> approved. Did you know that the JZOS currently distributed by IBM with their
> Java was originally from Dovetailed? Brilliant people. Nice people, too!
> (Hi, Kirk!) So, once you've installed at least the dataset pipes portion of
> Co:Z, you can run a simple UNIX shell script to create the DEFINE ALIAS
> commands for you!
>
> catsearch cicsts*.** |\
> cut -d '.' -f 2- |\
> sort -u |\
> while read i;do
> echo " DEFINE ALIAS(NAME(CICSTS.$i) -"
> echo " SYMBOLICRELATE(&CICSVER..$i))";
> done>idcams.sysin
> cat >idcams.jcl < //JOBNAME JOB (ACCT),PGMR,CLASS=A,MSGCLASS=H
> //IDCAMS EXEC PGM=IDCAMS
> //SYSPRINT DD SYSOUT=*
> //SYSIN DD *
> EOJ
> cat >null.jcl < //
> EOJ
> cat idcams.jcl idcams.sysin null.jcl | submit -j
> #end of script
>
> Feel free to use TSO and REXX or ISPF EDIT to do the same. But I doubt that
> it will be quite as easy as I've shown above. That took me about 5 minutes
> to write an debug. Repeat the above script for each CICS release high level
> qualifier, if they don't all start with the characters 'cicsts...' . If you
> repeat the script, you might (most likely will) get some duplicate aliases.
> But that should be OK. You could probably work the RSU into the DSN similar
> to what was done in the UNIX aliases.
>
>
>
>
> --
> John McKown
>
Re: HFS sharing and rolling product upgrades
On Thu, 2011-10-27 at 16:09 -0500, Kirk Wolf wrote: > John, > > Thanks for your kind words. Much of what we offer owes large success to > pesky users who send us feedback and suggestions :-) > > Your example reminds me that eventually we would like to add an "idcams" > shell command, which would allow: > > catsearch cicsts*.** |\ > cut -d '.' -f 2- |\ > sort -u |\ > while read i;do > echo " DEFINE ALIAS(NAME(CICSTS.$i) -" > echo " SYMBOLICRELATE(&CICSVER..$i))" > done | idcams > > I would love that! I guess that I could create an "idcams" UNIX command using REXX and an ADDRESS TSO to run the actual IDCAMS command. But that offends my sense of elegance. > Of course, if you like batch, this would easily run under COZBATCH :-) > FWIW, you may have noticed that there is a com.ibm.jzos.AccessMethodServices > class that provides a callable IDCAMS interface from Java. Nice. But I'd get strung up by my privates if I ran Java on the z at work (despite this, I have 1.4.0, 1.4.2, 1.5, 1.6, and 1.7 beta installed). We have reduced our z9BC to use a group capacity of 35 MSUs. Management wants it down to a max of 30 MSUs by year end to save more on license fees. I would say more, but it would be unwise. And I'm a techie who doesn't understand business. > > Cheers, > > Kirk Wolf > Dovetailed Technologies > http://dovetail.com > > PS> consider using awk to build job to do the whole thing in a pipeline > without temp files. Neat. I use awk a bit, but it's not my language of choice. I'm a Perl person. But I tend to avoid much beyond simple scripting due to CPU constraints. > *Something* like: > -- John McKown Maranatha! <>< -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HFS sharing and rolling product upgrades
On Thu, 27 Oct 2011 16:09:49 -0500, Kirk Wolf wrote: > >PS> consider using awk to build job to do the whole thing in a pipeline >without temp files. >*Something* like: > Hardly any need for awk. sh can do much the same (untested): catsearch cicsts*.** | cut -d '.' -f 2- | sort -u | while read name; do cat
Re: HFS sharing and rolling product upgrades
That submits one job per DEFINE ALIAS. My solution and the awk solution submits a single job with multiple DEFINE commands. A matter, in my eyes, of "elegance". I use that word a lot. I prefer "elegant" solutions. I'm still in the "CPU is precious" camp. Which is important here because we want to decrease software license costs. Which we can only do by decreasing CPU usage (MSUs). We've pretty much eliminated any "excess" software and don't pay any maintenance which is not required in order to continue running critical software. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -Original Message- > From: IBM Mainframe Discussion List > [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Paul Gilmartin > Sent: Thursday, October 27, 2011 7:22 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: HFS sharing and rolling product upgrades > > On Thu, 27 Oct 2011 16:09:49 -0500, Kirk Wolf wrote: > > > >PS> consider using awk to build job to do the whole thing in > a pipeline > >without temp files. > >*Something* like: > > > Hardly any need for awk. sh can do much the same (untested): > > catsearch cicsts*.** | > cut -d '.' -f 2- | > sort -u | > while read name; do cat < //JOBNAME JOB (ACCT),PGMR,CLASS=A,MSGCLASS=H > //IDCAMS EXEC PGM=IDCAMS > //SYSPRINT DD SYSOUT=* > //SYSIN DD * > DEFINE ALIAS(NAME(CICSTS.$Name) - > SYMBOLICRELATE(&CICSVER..$Name)) > // > end-of-job > done | > submit -j > > (sh does not require '\' after '|' and awk does not require > ';' at end of line.) > > (But this ignores the fact that sh _probably_ writes > here-documents to temp > file and reads them back.) > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
