IBM Support

II08373: OEM BUGS IN UTILITIES (IEBCOPY,IEBGENER,IEBEDIT,IEBCOMPR, IEBIMAGE,IEBDG,IEHINITT,IEHLIST,IEHMOVE,IEHPROGM,VMA,IKJEHDS1)

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

 

APAR status

  • INTRAN

Error description

  • This INFO APAR lists known third-party (OEM) problems in DFP &
DFSMS UTILITIES Components: 5695DF114,5695DF116,566528446,
566528407,566528449,566528447,566528444,566528441,566528437,
566528448,566528438,566528405,566528406.  Where possible, OEM
fix numbers are listed. This is by no means a complete list
but will be updated as new information is reported & verified.
-Incorrout, IEBCOPY MODs on to the end of the Sysprint Dataset
rather than starting at the beginning of a file after customer
applied DFP R330 maintenance from 9208 ==> 9403.
-The problem was caused by BMC Data Packer's Non-VSAM
Compression Utility. Vendor is working on a fix as of 12/07/94
~
-ABEND0C4 in IEBCOPY + X'E04' IEBSCN
-This was caused by MIMS EDIF and OEM fix is SD35367
.
-ABEND706 RC04 MSGCSV016I MSGCSV028I
-This was caused by an OEM Interface Program SYNCGENER
which customer was not aware was installed.  He modified the
program to resolve the problem.
12/94
-IEBCOPY - Incorrout, IEBCOPY runs successfully but there is
no input written to SYSPRINT....Add'l symptom ABENDA00 RC01
-This was caused by OEM PDSFAST which was renamed IEBCOPY and
was linkedited outside of SMP/E.  Our IEBCOPY was renamed
OLDCOPY.  The problem was resolved when customer set-up SMP/e
to relink maintenance to IEBCOPY to OLDCOPY.
- IEBGENER ABEND837 RC08 MSGIEC028I for Module IFG0551H
with BLP in JCL. No errors if SL
- This problem was caused by OEM product TLMS. They had supplied
customer with code for tape processing and the code for NL tapes
was bad. He was given good code, and all worked fine.
IEBGENER was processing a dataset when the message
MSGIEB351I RC12 read I/O error wrong length record was
caused by an OEM program PDSMON not enqueueing on the
dataset he was processing. The problem was corrected
by applying a new release of PDSMON that does enqueues
on the dataset.
03/95
- IEBGENER  MSGIEA705I (FREEMAIN) ABEND378 RC14 RSN14
Caused by OEM EPIC Product.
- PDSFAST called by ADRDSSU or SMP/E receives msgpdf221a and
msgpdf250I and
- IEBCOPY called by ADRDSSU or SMP/E Receives following
Msgieb1057I VL GETMAIN REQUESTED 1M to 250K BYTES. OBTAINED 0K
Issued by iebcopy. Problem storage was not being released by
module PWLDIR of the MAZDA Corp. The fix for this problem is
Z40630 it issues a freepool for the x'1008' bytes that was
gotten when the open was issued for dataset (dcb buffers).
Additional symptom: Msgieb133I Minimum requested storage not
available.
Iehinitt is Called by OEM product CA1's TMSTPNIT requires
apar OW09351 to correct a Abend0c4 in IEHINITT.
IEBCOPY
After a copy or copymod of a pds using iebcopy at apar OW07578
for DFSMS, or OW09384 for DFP, and a OEM product PMO,from
Legent is a fix that must be applied to PMO. The fix number is
QJ42937 and it applies for both DFSMS and DFP. The symptom is
that after the copy or copymod with a RC0, the modules can not
be accessed via ISPF, or the application, although they appear
to be in the library.
*
IKJEHDS1 (The main module to process the LISTDS command):
  IKJEHDS1 issues a RACHECK SVC routine (SVC 130) in the
  HISTROUT routine to indicate that a dataset is protected
  by a RACF generic profile which is also included under the
  security = RACF display for a LISTDS HISTORY command.
  The OEM product ( ACF2 ) converts the parameter list into
  a SAF RACROUTE AUTH call to process the request.  The
  RACHECK caller ( IKJEHDS1 ) requests that a profile be
  built in CSA.  The address of the profile is returned in
  REG1. The ACF2 SAF code built the profile in CSA and
  returned it to the ACF2 RACHECK intercept module.
  PROBLEM:  The ACF2 RACHECK module (Release 6.1) did not
           return the profile address in REG1 to IKJEHDS1
           for freemain and the profile never got freed.
  RESOLVE:  CA APAR - TA2310C.
.
  Problem:  ABEND0C4 in IKJEHDS1 at offset of X'1ABA' for DFSMS
            R1B0 while performing a LISTDS (data set name) HI
            function.   He was getting a 31 bit address back
            and the program is in 24 bit mode.
  Resolve:  CA TOP SECRET APAR - GO81635
            (version 5)
*
  ABEND322 was received when using IEBGENER to create a backup
  copy of a non-labeled tapes with VOL=SER=###nnn specified.
  This problem is circumvented by changing the VOL=SER=###nnn
  to VOL=SER=X##nnn where 'X' is any alphabetic character.
  RESOLVE:  CA product TLMS APAR - T903705.
*
  Abend047 executing IDCAMS with DCOLLECT option, TSO RECEIVE
  and finally failing in IEBCOPY.  Found that there was an OEM
  product that was turning off JSCBAUTH bit resulting loss of
  authorization to issue SVC107 (MODESET).  The OEM product
  is PROSMS Version 3.4.1 ( the known fix is PR341P13 ).
IEBCOPY Receives abend0c1 when upgrading from MVS R4.3.0 to
  MVS R5.2.0 and has OEM TMS from CA at R5.0. This is
  resolved by upgrading to TMS R5.1 which supports Dynamic
  lpalib loading.
IEHINITT was being invoked to initialize tape and
  received msgIOS000I NCA. It was found that the customer had
  CA's TMS system and the this problem was corrected by two
  fix's from CA's fix numbers are GA87355 and GA87326.
                                                      .
  MVS/ESA 5.2.2  DFSMS 1.3  IEBCOPY
  Customer is using IEBCOPY and is noticing through ISPF
  that some of the directory entries have blank members (not
  on all)and he gets I/O errors (customer had no msgs to give
  me to search on). BUT when customer uses IEBCOPY to copy the
  ENTIRE library to another library the "missing" members show
  up intact.  This error is corrected by a fix from ca for
  OEM product Program Managment Optimizer (PMO) rel 4.2
  The fix number is QJ42937.           HGL 01/21/97

Local fix

  • ERROR DESCRIPTION:
This INFO APAR lists known third-party (OEM) problems in DFP &
DFSMS UTILITIES Components: 5695DF114,5695DF116,566528446,
566528407,566528449,566528447,566528444,566528441,566528437,
566528448,566528438,566528405,566528406.  Where possible, OEM
fix numbers are listed. This is by no means a complete list
but will be updated as new information is reported & verified.
-Incorrout, IEBCOPY MODs on to the end of the Sysprint Dataset
rather than starting at the beginning of a file after customer
applied DFP R330 maintenance from 9208 ==> 9403.
-The problem was caused by BMC Data Packer's Non-VSAM
Compression Utility. Vendor is working on a fix as of 12/07/94
~
-ABEND0C4 in IEBCOPY + X'E04' IEBSCN
-This was caused by MIMS EDIF and OEM fix is SD35367
.
-ABEND706 RC04 MSGCSV016I MSGCSV028I
-This was caused by an OEM Interface Program SYNCGENER
which customer was not aware was installed.  He modified the
program to resolve the problem.
12/94
-IEBCOPY - Incorrout, IEBCOPY runs successfully but there is
no input written to SYSPRINT....Add'l symptom ABENDA00 RC01
-This was caused by OEM PDSFAST which was renamed IEBCOPY and
was linkedited outside of SMP/E.  Our IEBCOPY was renamed
OLDCOPY.  The problem was resolved when customer set-up SMP/e
to relink maintenance to IEBCOPY to OLDCOPY.
- IEBGENER ABEND837 RC08 MSGIEC028I for Module IFG0551H
with BLP in JCL. No errors if SL
- This problem was caused by OEM product TLMS. They had supplied
customer with code for tape processing and the code for NL tapes
was bad. He was given good code, and all worked fine.
IEBGENER was processing a dataset when the message
MSGIEB351I RC12 read I/O error wrong length record was
caused by an OEM program PDSMON not enqueueing on the
dataset he was processing. The problem was corrected
by applying a new release of PDSMON that does enqueues
on the dataset.
03/95
- IEBGENER  MSGIEA705I (FREEMAIN) ABEND378 RC14 RSN14
Caused by OEM EPIC Product.
- PDSFAST called by ADRDSSU or SMP/E receives msgpdf221a and
msgpdf250I and
- IEBCOPY called by ADRDSSU or SMP/E Receives following
Msgieb1057I VL GETMAIN REQUESTED 1M to 250K BYTES. OBTAINED 0K
Issued by iebcopy. Problem storage was not being released by
module PWLDIR of the MAZDA Corp. The fix for this problem is
Z40630 it issues a freepool for the x'1008' bytes that was
gotten when the open was issued for dataset (dcb buffers).
Additional symptom: Msgieb133I Minimum requested storage not
available.
Iehinitt is Called by OEM product CA1's TMSTPNIT requires
apar OW09351 to correct a Abend0c4 in IEHINITT.
IEBCOPY
After a copy or copymod of a pds using iebcopy at apar OW07578
for DFSMS, or OW09384 for DFP, and a OEM product PMO,from
Legent is a fix that must be applied to PMO. The fix number is
QJ42937 and it applies for both DFSMS and DFP. The symptom is
that after the copy or copymod with a RC0, the modules can not
be accessed via ISPF, or the application, although they appear
to be in the library.
*
IKJEHDS1 (The main module to process the LISTDS command):
  IKJEHDS1 issues a RACHECK SVC routine (SVC 130) in the
  HISTROUT routine to indicate that a dataset is protected
  by a RACF generic profile which is also included under the
  security = RACF display for a LISTDS HISTORY command.
  The OEM product ( ACF2 ) converts the parameter list into
  a SAF RACROUTE AUTH call to process the request.  The
  RACHECK caller ( IKJEHDS1 ) requests that a profile be
  built in CSA.  The address of the profile is returned in
  REG1. The ACF2 SAF code built the profile in CSA and
  returned it to the ACF2 RACHECK intercept module.
  PROBLEM:  The ACF2 RACHECK module (Release 6.1) did not
           return the profile address in REG1 to IKJEHDS1
           for freemain and the profile never got freed.
  RESOLVE:  CA APAR - TA2310C.
.
  Problem:  ABEND0C4 in IKJEHDS1 at offset of X'1ABA' for DFSMS
            R1B0 while performing a LISTDS (data set name) HI
            function.   He was getting a 31 bit address back
            and the program is in 24 bit mode.
  Resolve:  CA TOP SECRET APAR - GO81635
            (version 5)
*
  ABEND322 was received when using IEBGENER to create a backup
  copy of a non-labeled tapes with VOL=SER=###nnn specified.
  This problem is circumvented by changing the VOL=SER=###nnn
  to VOL=SER=X##nnn where 'X' is any alphabetic character.
  RESOLVE:  CA product TLMS APAR - T903705.
*
  Abend047 executing IDCAMS with DCOLLECT option, TSO RECEIVE
  and finally failing in IEBCOPY.  Found that there was an OEM
  product that was turning off JSCBAUTH bit resulting loss of
  authorization to issue SVC107 (MODESET).  The OEM product
  is PROSMS Version 3.4.1 ( the known fix is PR341P13 ).
IEBCOPY Receives abend0c1 when upgrading from MVS R4.3.0 to
  MVS R5.2.0 and has OEM TMS from CA at R5.0. This is
  resolved by upgrading to TMS R5.1 which supports Dynamic
  lpalib loading.
IEHINITT was being invoked to initialize tape and
  received msgIOS000I NCA. It was found that the customer had
  CA's TMS system and the this problem was corrected by two
  fix's from CA's fix numbers are GA87355 and GA87326.
                                                      .
  MVS/ESA 5.2.2  DFSMS 1.3  IEBCOPY
  Customer is using IEBCOPY and is noticing through ISPF
  that some of the directory entries have blank members (not
  on all)and he gets I/O errors (customer had no msgs to give
  me to search on). BUT when customer uses IEBCOPY to copy the
  ENTIRE library to another library the "missing" members show
  up intact.  This error is corrected by a fix from ca for
  OEM product Program Managment Optimizer (PMO) rel 4.2

  ABEND0C4 iebioe + 1786 UW33451 is caused by PDSFAST calling
  IEBCOPY with a GETMAIN above the 16M line.  The fix number
  for PDSFAST is EWF1733.                   HGL 05/23/97
.
.

Problem summary

  • 



Problem conclusion


    

  • 



Temporary fix


    

  • 



Comments


    

  • 



APAR Information




    

  • APAR number
    II08373
    • 

  • Reported component name
    V2 LIB INFO ITE
    • 

  • Reported component ID
    INFOV2LIB
    • 

  • Reported release
    001
    • 

  • Status
    INTRAN  
    • 

  • PE
    NoPE
    • 

  • HIPER
    NoHIPER
    • 

  • Special Attention
    NoSpecatt
    • 

  • Submitted date
    1994-12-07
    • 

  • Closed date
    • 

  • Last modified date
    1997-05-23
    • 





    

  • APAR is sysrouted FROM one or more of the following:
    

    • 

  • APAR is sysrouted TO one or more of the following:
    

    • 



Fix information


    



Applicable component levels


    








      
              
                            

              

              [{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19N","label":"APARs - OS\/390 environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":null,"label":null},"Product":{"code":"SG19O","label":"APARs - MVS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"","label":""}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"001","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]
              

                                                                    

          
 
        

      

    

      

        

          

            
Document Information


            

            


                        

            Modified date:
            

            23 May 1997
            

            
                      

        


        

        


      

    

  



    

  

  
    
            

          
Page Feedback