Frequently
Asked
Questions

IOFTech    Maintenance   Release8G       Newsletters    Doc    FAQ    Contact    Home

Last updated: Tuesday, 26-Nov-2024 13:11:27 EST

Q. What is the current release of  IOF?

A. Release 8G was officially released on October 2, 2017 with support for z/OS V2R3.  IOF maintenance provides support for V2R4 and V2R5.  Release 8G is the only release that supports z/OS versions V2R3 and higher.
 
The latest release of IOF is Release 8G. The latest spin level of  IOF Release 8G is 2024324 (November 19, 2024).

The latest release of IOF is Release 8G. The latest spin level of  IOF Release 8G is 2024324 (November 19, 2024).
IOF  provides support for JES2 data set encryption and compaction.  To get this support you can download and install the latest IOF MPI file, or download the release 8G CUMFIX file and apply all of the fixes to your current IOF 8G system.

Q. What releases of z/OS and OS/390 are supported by IOF Release 8G?

A. Release 8G with maintenance supports all versions of z/OS through V2R5.  It may run but has not been tested with OS/390. 

Q. What releases of IOF are currently supported?

A. Release 8G supports all versions of z/OS through V2R5.

Q. How do I determine the release of  IOF  I am running?

A. Enter "VERSION"  from any IOF panel. Your IOF version and level will be displayed, as well as  the version of the CLIST, HELP and ISPPLIB libraries being used.

Q. Can I run release 8G run in parallel with my current IOF release?

A. Yes. In fact, release 8G is shipped with the "IOF8G" Rexx exec which can be used to invoke release 8G in lieu of the current production version of IOF. The "$$TODO" member of the INSTALL library describes how to use "IOF8G" for testing. 

The latest MPI also includes the RUNIOF command.  RUNIOF parm is the version of IOF you want to run.  ie RUNIOF 8G3.

Q. Does IOF support the EVENTLOG data set introduced by JES2 V2R2?

A. The most important information in EVENTLOG is the completion code of each job step.  The IOF Job Summary Panel has always displayed this information, so EVENTLOG is of little use to IOF users.  But the IOF INTTEXT command will cause the EVENTLOG data set to be included on the Job Summary where it can be browsed.  Just enter INTTEXT primary command on the IOF Job Summary.

Q. When I install a new version of IOF, do I need to install a new SVC (or ESR)?

A. Probably not. The IOF SVC and optional ESR have not changed since Release 7D.  But a few customers have been running with the older version of the IOF SVC.  IOF now checks to be sure the newer version of the SVC/ESR is installed.

Q. What is an IOF spin level?

A. IOF is distributed as a single MPI file. Periodically, the MPI file is updated to apply maintenance. The new MPI version is called a spin level. Spin levels of an IOF release are the base level with maintenance applied. The fixes web page for each release shows which spin level, if any, has each fix pre-applied. The "name" of the spin level is the julian date it was built.

If you apply all maintenance in the CUMFIX file you will bring your IOF up to at least the latest spin level.  The spin level number will not be updated however.

Q. Do I need a new expiration patch when I convert to a new release of  IOF?

A. No. All  releases of IOF from 7D through 8G use the same expiration patch. The IOF installation dialog automatically copies your old expiration patch (password) from the old options data set to the new options data set.  IOF/TSO and IOF/CICS however do have different passwords.

Q. Do I need a special expiration patch to run IOF at a disaster recovery site?

A. Probably not. As long as the date portion of your normal expiration patch is valid, IOF will run with a "license" error message until the third midnight after IPL. This provides at least 48 hours of disaster testing per IPL. If your disaster test will be longer than 48 hours per IPL, call technical support for a temporary patch.

Q. How do I determine when my IOF expiration patch will expire?

A. Enter "DVAR EXPRDATE" from any IOF panel to display the date the current patch in use will expire.

A utility function that can be run in batch TSO to provide a warning when IOF is near expiration is available.  The  INSTALL library has a new job, M45DATCK,  which can be submitted daily to warn when IOF is approaching expiration.  The job can be edited to change the warning threshold, and to specify userids to be notified of any exception conditions encountered.

Q. I applied my new expiration patch, but IOF still is "expired" What is the problem?

A. There are several possible problems. The most likely problem is that you applied the patch to the wrong linklist library. IOF provides the IOFWHERE Rexx exec to help you find the module that should be patched. From ISPF Option 6, or from TSO READY, enter "IOFWHERE". The library names in which each of the IOF load modules reside will be displayed. You have to zap the "U" module in the library displayed.

Occasionally VLF or some other product that provides similar function prevents the updated load module from being loaded.

See the Virtual Help Desk for additional information.

Q.  The Energy Policy Act of 2005 mandates that DST will start on the second Sunday in March and end on the first Sunday in November.  How does this effect IOF?.

A.  IOF formats and prints dates from JES2 control blocks, but has no code that is aware of the change to or from DST.  No change to IOF is required.

Q. Does IOF support 64 bit processors?

A.  Yes, IOF runs on 64 bit processors.  IOF does not use 64 bit facilities however. 

All IOF release 8 versions run with 64 bit processors with no additional maintenance required.