Using system symbols to back-up your HFS or ZFS files on z/OS

On z/OS, your WebSphere Application Server cells, node agents and server information is stored in HFS (Hierarchical File Systems) or ZFS (z/OS File Systems).  ZFS is the new direction that IBM is wanting users to go with, but a lot of folks are still using HFS.

On my systems, I use the ADRDSSU utility to back-up my file systems daily, and I put a date in the output file name.  Now, putting the current date or time in an output dataset name is not an intuitive option on a z/OS system....but there is a TCP/IP installation and configuration utility that can be used for system symbol substitution, EZACFSM1.

This utility, EZACFSM1, can be placed as a surrounding job for your backup JCL

//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT    DD SYSOUT=(A,INTRDR),DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)
//SYSIN     DD DATA,DLM=@@


all your ADRDSSU jobs can go between STEP0100 and the end delimiter of @@

@@

So what we have is basically a shell where we can enter our backup JCL. I put every file system to be backed up in a separate job so that they all run at the same time.  The jobs entered between the SYSIN  DD DATA,DLM=@@ and the ending @@ will have system symbols substituted for variables in the JCL.  See example below:

//BUSYSAS  JOB (XXXX,9350),'J LANG',
//    CLASS=S,
//    MSGCLASS=G,SCHENV=SYSA,

//    NOTIFY=JLANG1
//STEP0100 EXEC PGM=EZACFSM1
//SYSOUT    DD SYSOUT=(A,INTRDR),DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)
//SYSIN     DD DATA,DLM=@@
//BUSYSAD JOB (DDC06),'JLANG1    ',CLASS=S,MSGCLASS=G,NOTIFY=&SYSUID,
//     SCHENV=SYSA
//*
//DUMP1     EXEC  PGM=ADRDSSU
//SYSPRINT  DD    SYSOUT=*
//OUT       DD    DSN=&&TEMP,DISP=(,PASS),
//          SPACE=(CYL,(800,10),RLSE)
 DUMP OUTDD(OUT) ALLDATA(*) SHARE OPT(4) TOL(ENQF)  -
 DATASET (INCLUDE(OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS))
/*
//REST1     EXEC  PGM=ADRDSSU
//SYSPRINT  DD    SYSOUT=*
//IN        DD    DSN=&&TEMP,DISP=(OLD,DELETE)
 RESTORE DATASET (INCLUDE(OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS)) INDD(IN) -
 TOL(ENQF) -
 RENAMEU(OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS, -
 OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS.D&LYYMMDD)
/*
//DUMP2     EXEC  PGM=ADRDSSU
//SYSPRINT  DD    SYSOUT=*
//OUT       DD    DSN=&&TEMP,DISP=(,PASS),
//          SPACE=(CYL,(800,10),RLSE)
 DUMP OUTDD(OUT) ALLDATA(*) SHARE OPT(4) TOL(ENQF)  -
 DATASET (INCLUDE(OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS.D&LYYMMDD))
/*
//*   DELETE THE 'COPYTO' (NEWNAMED) FILE
//DELETE1   EXEC  PGM=IDCAMS
//SYSPRINT  DD    SYSOUT=*
//SYSIN DD *
  DELETE   OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS.D&LYYMMDD
/*
//*
//REST2     EXEC  PGM=ADRDSSU
//SYSPRINT  DD    SYSOUT=*
//IN        DD    DSN=&&TEMP,DISP=(OLD,DELETE)
//OUT       DD    DSN=OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS.D&LYYMMDD,
//          SPACE=(CYL,(800,10,1),RLSE,CONTIG),DISP=(,CATLG),
//          DSNTYPE=HFS
 RESTORE -
 DATASET (INCLUDE(OMVS.SYSA.WAS71.SYSADM.CONFIG.HFS.D&LYYMMDD)) -
 INDD(IN) TOL(ENQF) REPLACE
/*
@@

In the JCL listed above......2 jobs will be submitted.....the first, BUSYSAS (In Blue) will prepare the JCL for BUSYSAD by replacing the &LYYMMDD symbol with the current local date.  The symbols table can be displayed so you can see what options you have available for use.  In order to display the system symbols....you can add a REXX script, SYMDEF to your system REXX library (see below)

SYMDEF:

/* REXX *** */                                                          
SAY 'JOBNAME  = 'MVSVAR('SYMDEF','JOBNAME')                             
/* GMT TIME */                                                         
SAY 'YYMMDD   = 'MVSVAR('SYMDEF','YYMMDD')                             
SAY 'DAY      = 'MVSVAR('SYMDEF','DAY')                                 
SAY 'HR       = 'MVSVAR('SYMDEF','HR')                                  
SAY 'JDAY     = 'MVSVAR('SYMDEF','JDAY')                                
SAY 'MIN      = 'MVSVAR('SYMDEF','MIN')                                 
SAY 'MON      = 'MVSVAR('SYMDEF','MON')                                 
SAY 'SEC      = 'MVSVAR('SYMDEF','SEC')                                 
SAY 'HHMMSS   = 'MVSVAR('SYMDEF','HHMMSS')                              
SAY 'WDAY     = 'MVSVAR('SYMDEF','WDAY')                                
SAY 'YR2      = 'MVSVAR('SYMDEF','YR2')                                 
SAY 'YR4      = 'MVSVAR('SYMDEF','YR4')                                 
/* LOCAL TIME */                                                        
SAY 'LYYMMDD  = 'MVSVAR('SYMDEF','LYYMMDD')                             
SAY 'LDAY     = 'MVSVAR('SYMDEF','LDAY')                                
SAY 'LHR      = 'MVSVAR('SYMDEF','LHR')                                 
SAY 'LJDAY    = 'MVSVAR('SYMDEF','LJDAY')                               
SAY 'LMIN     = 'MVSVAR('SYMDEF','LMIN')                                
SAY 'LMON     = 'MVSVAR('SYMDEF','LMON')                                
SAY 'LSEC     = 'MVSVAR('SYMDEF','LSEC')                                
SAY 'LHHMMSS  = 'MVSVAR('SYMDEF','LHHMMSS')                             
SAY 'LWDAY    = 'MVSVAR('SYMDEF','LWDAY')                               
SAY 'LYR2    = 'MVSVAR('SYMDEF','LYR2')                                 
SAY 'LYR4    = 'MVSVAR('SYMDEF','LYR4')                                 
/* ADD YOUR OWN SYMBOLIC VARIABLES HERE */                              
SAY 'SYSR2    = 'MVSVAR('SYMDEF','SYSR2')                               

EXIT 0                                                                  

Now, executing the SYMDEF REXX script will produce a symbols report:

Note: If local date and time are needed, these are preceded by an “L”.

JOBNAME  = JLANG1

YYMMDD   = 070627

DAY      = 27

HR       = 14

JDAY     = 178

MIN      = 12

MON      = 06

SEC      = 52

HHMMSS   = 141252

WDAY     = WED

YR2      = 07

YR4      = 2007

LYYMMDD  = 070627

LDAY     = 27

LHR      = 09

LJDAY    = 178

LMIN     = 12

LMON     = 06

LSEC     = 52

LHHMMSS  = 091252

LWDAY    = WED

LYR2    = 07

LYR4    = 2007

SYSR2    = T7YTA2

This technique can be used for any job where you would like to have a date/time included in the output dataset name without having to change it every time......the substitution is done automatically by the EZACFSM1 utility.

Happy programming!!!

WebSphere z/OS - Clearing JSP cache......

Sometimes during development.....I have found the need to use an embedded java server page...in several java server pages....to have a consistent look and feel. (see below)

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta http-equiv="Cache-control" content="no-cache">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
<title>A Java Server Page</title>
</script>
</head>
<body>
<%@ include file="Header.jsp" %>

So let's say that this include file (Header.jsp) is in a java server page named NewCust.jsp. If we were to make a change to the Header.jsp file...and only the Header.jsp file.......WebSphere V7.1 currently would not realize that this file has been changed.  Since we want NewCust.jsp to be recompiled......its data has not changed..so WebSphere will use is currently compiled copy.  This will result in the changes made to Header.jsp not showing up in the NewCust.jsp.

There are two things that we can do in this instance:

1) Make a benign change to all of the java server pages that include the Header.jsp...so that their changed dates will be updated....this will force a compile in WebSphere Application Server.

2) Clear the WebSphere java server pages compiled cache.  This too will force WebSphere to re-compile all of the java server pages when they are accessed...at least the ones we remove from the cache.

To find the cache folder.....you will need to go to the OMVS, Unix System Services....and locate the cache folder.

/cellRoot/AppServer/profiles/default/temp/appNodeName/serverName/applicationName/applicationWARFileName/_NewCust.class

The portion of this path that will be specific to your particular installation, node, application and war file name....they are highlighted in red above.

In this directory....you will see your particular jsp compile class...preceded with an underscore.  In our example _NewCust.class.  You can simply remove this file to force a recompile.

Happy coding!!!!

Manually turning off Global Security - z/OS

Security is a tricky item.  Having created hundreds of application servers and Deployment Manager cells, occasionally it has been necessary to manually turn off security.  Normally, this happens when first setting up security, whether it be the local z/OS security system, or connecting to an LDAP server...sometimes the set-up has an error and your cell/server will not start, or you are unable to login.  This article will cover what is needed to manually turn off security so you can start your cell or server and login to correct the situation.

WebSphere files on z/OS are stored in ascii format.  The z/OS system is ebcdic...so the first order of business will be two utility scripts to convert ascii to ebcdic and ebcdic to ascii.

One last note on these scripts....the left and right brackets [ ] are not ebcdic characters....so when you enter them....you need to turn on HEX and make the left bracket [ a x'AD' and the right bracket ] a x'BD'

The following script will convert ascii to ebcdic: (script name 2e)

#!/bin/sh
if [ $# -ne 1 ]; then
  echo "Usage : 2e fileName"
  echo "Output: fileName.E"
  exit 10
else
  iconv -f ISO8859-1 -t IBM-1047 $1 > $1.E
fi

Example:
$ 2e myasciiFile

Output:
myasciiFile.E

The following script will convert ebcdic to ascii: (script name 2a)

#!/bin/sh
if [ $# -ne 1 ]; then
  echo "Usage : 2a fileName"
  echo "Output: fileName.A"
  exit 10
else
  iconv -f IBM-1047 -t ISO8859-1 $1 > $1.A
fi

Example:
$ 2a myebcdicFile

Output:
myebcdicFile.A

These scripts should be saved in a location in z/OS Unix and that location needs to be added to your PATH environment variable. So if you have saved them to /usr/lpp/scripts Then you can either place this directory in your .profile file on the PATH variable or you can export a new PATH variable.

$ export PATH=$PATH:/usr/lpp/scripts

They also need to be executable, so using chmod:

$ cd /usr/lpp/scripts
$ chmod 755 2e 2a

Okay, now the preliminary work is out of the way...we can look at where the security switch is set.  For standalone servers the location of the configuration files is:

/mountPoint/AppServer/profiles/default/config/cells/
     cellName/

The location for the Deployment Manager configuration files is:

/mountPoint/DeploymentManager/profiles/default/config/
     cells/cellName

The mountPoint and cellName locations above were named by you when the server was created. Inside of these directories will be a file named security.xml.  Remember, this file is store in ascii format so using the scripts we created earlier, let's convert it to ebcdic.

$ 2e security.xml

You will now have a file that you can view as well as edit. The file name will be security.xml.E.

Using the USS editor, open the file.

$ oedit security.xml.E

On the second line of this file, over to the right...there will be a variable enabled="true" . In order to turn off global security, change the true to false...then save the file. Now we have our ebcdic file with the correct values, but we need it in ascii format. We need to execute the 2a script:

$ 2a security.xml.E

Now we have a file named security.xml.E.A that we need to rename security.xml.  Before we do this, we should save the original file...just in case.

$ cp security.xml security.xml.ORIG

Now we can rename or move our ascii file with security turned off.

$ mv security.xml.E.A security.xml

For our last item, we need to make sure the permission bits, the owner and the group ownership on the new file are the same as the original file.  Using the chown, chgrp and chmod commands....make the security.xml file the same as security.xml.ORIG.

You now should be able to start your server or deployment manager and using the Administration Console correct any problems with your security set-up.

These types of errors don't happen that often...but when they do, it is always good to know how to manually turn security off so that the server or cell can start.

Good luck.

Directing Application dumps in WebSphere for z/OS

Sometimes when you have an application that produces a dump, you run the risk of depleting your space in the Unix System Services, USS, file system and having this affect other applications.  In order to redirect your WebSphere dumps to a pre-allocated file system, you can do the following:

In the WebSphere Admin Console...go to...

Environment -> WebSphere variables

Add a new environment variable at the Cell or Server level which ever is the highest.  The name of the variable will be _CEE_DMPTARG and the value will be the new HFS or ZFS you allocated and mounted.....i.e. /home/websphere/dumps.

Save the configuration and stop and re-start the cell and or servers.