| |
More efficient use of SMPLTS data set
In prior releases of SMP/E, the SMPLTS data set was very large, because it was used to manage
all load modules that have a CALLLIBS subentry (load modules that exploit the link edit
autocall facility).
In SMP/E Version 3 Release 2, the SMPLTS data set is used only for load modules that both use
CALLLIBS and contain cross-zone modules.
If a load module uses CALLLIBS, but does not contain any cross-zone modules, SMP/E rebuilds
the load module from scratch during link edit operations, rather than saving a version of
the load module in the SMPLTS data set. The result is a much smaller, or possibly empty,
SMPLTS data set.
SMP/E will delete unneeded load modules from the SMPLTS data set during APPLY, RESTORE,
and CLEANUP command processing. However, because such an SMPLTS data set will not be
compatible with prior releases of SMP/E, this cleanup of existing load modules will
occur only after you use the new UPGRADE command to indicate your desire
to exploit new functions.
LINK LMODS command
The LINK LMODS command replaces the REPORT CALLLIBS command.
The LINK LMODS command provides all of the functions of the REPORT CALLLIBS command with
additional benefits.
The LINK LMODS command refreshes the content
of load modules by rebuilding them from scratch.
Any load module may be specified by name or you can use the
CALLLIBS operand to refresh only load modules that have a dependency on particular CALLLIBS.
The LINK LMODS command will perform the link edit operations
directly for the load modules, instead of producing a JCL job
to perform the link edit operations.
In addition, SMP/E will attempt recovery from out-of-space conditions
encountered during those link edit operations.
UPGRADE command
New releases of SMP/E must sometimes make changes to SMP/E data sets that
cannot be properly processed by prior SMP/E releases. SMP/E usually makes
incompatible changes only when necessary to provide new and improved
capabilities. For example, a new type of element requires a new entry type in
SMPCSI data sets and these new entry types are typically not understood or
processed correctly by SMP/E levels that have not been specifically updated to do so.
The UPGRADE command allows you to specify when SMP/E is permitted to make
incompatible changes to SMP/E data sets. SMP/E will continue to use processing that is
compatible with prior releases until you use the UPGRADE command.
This, in turn, allows you to make the
trade-off between exploiting new SMP/E functions and preserving compatibility with
prior SMP/E releases.
Easier SMP/E dialog customization
SMP/E now provides a new, easier method for customizing the SMP/E dialog panels.
Rather than modifying panel GIM@UPRM (as was done previously),
you may now use the SETTINGS option on the SMP/E Primary Option Menu, GIM@PRIM, to
enter or change the values for the dialog customization options.
The options that you specify affect how JCL jobs are generated and how temporary and
permanent data sets are allocated by the dialogs. These options will
be saved permanently in the ISPF profile pool for use later by other SMP/E
dialog processes.
When moving to a new release of SMP/E, if you
continue to use the same ISPF profile data set (as is usually the
case), then no migration actions are required to use the options
previously entered and saved.
SMP/E will no longer support customization using the GIM@UPRM
mechanism. All dialog customization formerly specified on panel GIM@UPRM,
must now be specified using the new SETTINGS option.
Java Archive (JAR) file support
The Java Archive (JAR) file format is based on the popular ZIP file format
and is used for aggregating many files into one. Although JAR can be used
as a general archiving tool, the primary motivation for its development
was so that Java applets and their requisite components (.class files,
images and sounds) can be downloaded to a browser in a single HTTP
transaction, rather than opening a new connection for each piece. This
greatly improves the speed with which an applet can be loaded onto a web
page and begin functioning. The JAR format also supports compression,
which reduces the size of the file and improves download time still
further. These attributes make the JAR file format the
preferred method to bundle Java applets and applications.
Fundamental operations on a JAR file are performed using the Java Archive
Tool provided as part of the Java Development Kit (JDK). The Java Archive
Tool is invoked using the jar command. The jar command is used to create
JAR files, view and extract the contents of JAR files, and update the
contents of JAR files. To update the contents of a JAR file means to
replace a subset of the files within the archive, add additional
files to the archive, or both.
Further discussion of the jar command and JAR files can be found in
Java Developer Connection, Using JAR Files: The Basics.
SMP/E has introduced new element types to describe JAR files and SMP/E will
replace and update such files. The ++JAR element type is used to add and
replace entire JAR files and the ++JARUPD element type is used to provide
an update for a JAR file.
To update a JAR file, SMP/E will add or replace component files within a Java Archive,
rather than replacing the entire Java Archive file. This then allows much smaller
and more granular PTFs for products that use Java and JAR files.
JAR files reside in directories within the UNIX file system and SMP/E will use the
Java jar command to update a JAR file when processing a ++JARUPD element.
Note: IBM Developer Kit for OS/390, Java 2 Technology Edition is required for
SMP/E to perform JARUPD processing. See
Java™ 2 on the OS/390 and z/OS Platforms for more information.
Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc.
in the United States, other countries, or both.
Dummy SYSDEFSD data set
During link edit operations, the SYSDEFSD DD statement
defines the location for the binder to write
IMPORT statements for all exported symbols of a DLL load module. Whenever
symbols are to be exported, the binder expects the SYSDEFSD data set, and
if it is not present, will issue a warning message (return code four) to
indicate the missing data set.
Product developers who supply DLLs, do not always want or need the IMPORT
statements associated with a DLL retained. However, in order to receive a
return code of zero from the binder during SMP/E installation, the
developer is required to provide a SYSDEFSD data set. In these instances,
the IMPORT statements are not wanted, and SYSDEFSD would be better defined
as either a temporary or DUMMY data set.
SMP/E is defining a new ddname called SMPDUMMY which will always be
allocated as 'DD DUMMY'. The product developer may now specify the
SYSDEFSD DD statement in the JCLIN input stream as any of the following:
//SYSDEFSD DD DSN=SMPDUMMY,DISP=xxx
-or-
//SYSDEFSD DD DSN=NULLFILE
-or-
//SYSDEFSD DD DUMMY
In each case, the SIDE DECK LIBRARY subentry of the LMOD entry will be set
to SMPDUMMY. When needed for processing, SMPDUMMY will be dynamically
allocated by SMP/E as a DUMMY data set.
Data collection routine for ShopzSeries (GIMXSID)
The GIMXSID service routine is used as part of the ShopzSeries offering. GIMXSID
creates a single data source required by ShopzSeries to place customized software
product and service orders. The data source created by GIMXSID, the software
inventory data, is a composite of three kinds of information as follows:
- A list of FEATUREs found in the SMPCSI data sets. The Feature List is used by
ShopzSeries to perform product requisite checking and also to prime the order
checklist when ordering a ServerPac.
- A list of the FMIDs found in the SMPCSI data sets. The FMID List is used by
ShopzSeries to scope service orders to the PTFs applicable solely to the user’s
desired configuration of target and global zones.
- A bitmap representation of the PTFs found in the specified target zones and
global zones. The PTF Bitmap is used by ShopzSeries to produce
service packages that do not contain PTFs that are already present in the user’s
configuration.
GIMZIP package extensions
The GIMZIP service routine creates portable packages of software and related materials.
In SMP/E Version 3 Release 2, users have more control over the structure of GIMZIP packages.
Large archive files within GIMZIP packages may be divided into smaller segments.
The GIMZIP service routine now enables you to specify, in megabytes, the maximum size
of the portable objects that are produced. GIMZIP will then divide large archive files
into multiple smaller physical files, thus enabling more efficient network transport
and retry operations on the packages.
In addition, subdirectories can be specified in which to group and store documentation,
samples, readme files, and other types of data within GIMZIP packages.
The subdirectory is created in the hierarchical file system, within the package
directory specified on the SMPDIR DD statement.
The RECEIVE FROMNETWORK and FROMNTS commands, as well as the GIMUNZIP Service Routine,
have been updated to support processing of packages with segmented archive files and
subdirectories that may be produced by GIMZIP.
SYSLIB allocated only when needed for assemblies
The SYSLIB concatenation is used by the assembler
during APPLY, ACCEPT, and RESTORE command processing to find macros for assembly operations.
Prior releases of SMP/E unconditionally allocated the data sets in the SYSLIB concatenation
during APPLY, ACCEPT,
and RESTORE command processing, even if no assembly operations were performed.
SMP/E Version 3 Release 2 will allocate the data sets in the SYSLIB concatenation
only if an assembly operation is to be performed by the APPLY, ACCEPT, and RESTORE commands.
This reduces SMP/E processing to allocate the data sets
and eliminates possible contention for the data sets.
Removal of REPORT CALLLIBS command
The REPORT CALLLIBS command has been
removed. The new LINK LMODS command replaces it.
Dummy SYSDEFSD data set
Module GIMUTTBL and macro GIMDFUT are no longer supplied as
part of SMP/E. During command initialization, SMP/E no longer loads GIMUTTBL and
reads it to determine which utilities SMP/E may call. SMP/E is now
allowed to call any utility program required for command execution.
The names of the utilities SMP/E may call include all of SMP/E's
default utility program names (BPXCOPY, ASMA90, IEBCOPY, IEBUPDTE,
IEWBLINK, IEWL, and IMASPZAP) and any utility program name specified
in an active UTILITY entry.
If a particular utility program is to be restricted, the z/OS
Security Server must be used to control its execution.
Contact z/OS
Send us your questions and comments.
 |
|
|
