Xtract™ FAQ’s

  1. Problems with the number of devices.Starting with Release 4.0, Xtract supports up to 9999 devices, but the default is 2048. This is explained in the README.TXT file included in the installation package, and typically installed in the .\PALLAS International\Lead Time\Xtract subdirectory. Xtract needs to GETMAIN 560 bytes of memory for each device. To avoid problems in memory constrained environments, the following approach was adopted:
    • The DEFAULT number of devices and groups is still 2048.
    • The MAXIMUM number of devices and groups is now specified in the JCL PARM field. For example: //STEP1 EXEC PGM=XTRACT,PARM=8192 will allow for a maximum of 8192 devices and groups.
    • If a JCL PARM field is NOT specified, the default of 2048 applies .
    • In memory constrained environments, it is possible to decrease the default, also by using the JCL PARM field. For example: //STEP1 EXEC PGM=XTRACT,PARM=256Note that the current release of Lead Time supports up to 4096 logical volumes for a single control unit.
  2. Problems with the number of OUTxxx DD statements.The most common Xtract runs generate two kinds of data sets.• SYSPRINT, where reports are written
    • OUTnnn data sets, where the input for LEADTIME is written.XTRACT 4.1 and previous releases, one OUTnnn data set was written for each LCU to which the specified devices belonged. Thus, if a single LCU was included, it sufficed to specify a DD with DDNAME OUT001 in the JCL. If two LCUs were included, OUT002 had to be specified as well, and so on. If the necessary number of OUTnnn DD’s were not included, the user would get the message: OUTnnn DATA SET CANNOT BE OPENED.In this case, the best way to avoid mutiple iterations of this problem, and to determine which DDs were needed was to refer to the SYSPRINT data set, the second page, containing the “Device activity report”. The leftmost column contains the device number while the next column contains the LCU the device belongs to. This allows to determine the number of different LCUs, and hence the number of OUTnnn DDs needed. So if 69 different LCUs are encountered, DDs OUT001 to OUT069 must be specified in the JCL.

    This mechanism was perfectly adequate to handle controllers like the IBM 3830 or the Amdahl 6880-G2, because those controllers included a single LCU. However, modern controllers have a large number of devices configured, and in most cases include multiple LCUs. The objective of Xtract is to generate input for Lead Time, and Lead Time works at the controller level. So, if a controller includes multiple LCUs, several OUTnnn data sets had to be merged within Lead Time. This can be a cumbersome process. Under Xtract 4.1 and lower, there was a limited way to address this problem by specifyingLCUGRP=NO. With this specification, a single output data set (OUT001) was used, regardless of the number of LCUs.

    However, this approach does not address the case where a configuration included multiple controllers, some of them including multiple LCUs. Assume, for instance, a DASD configuration including six controllers: – Amdahl Controller, LCUs 15, 16, 17, 18. – EMC Controller, LCUs 1A, 1B, 1C, 1D. – HDS Controller, LCUs 09, 0A, 0B, 0C. – IBM Controller, LCUs 30, 31, 32, 33. – STK Controller, LCUs 27, 28, 29, 2A. – IBM 3830 Controller, LCU 6A. As six controllers are present, six Lead Time runs must be executed.

    Under Xtract 4.1 and previous releases, this configuration could be handled in two different ways:

    • Specify all devices to Xtract, and let Xtract generate one dataset per LCU (in this case resulting in 21 data sets (OUT001 to OUT021), then merge appropriately the resulting 21 data sets to execute the desired six Lead Time runs.
    • Execute six Xtract runs, one per controller, specifying LCUGRP=NO, each generating the input for one Lead Time run.

    The new Xtract 4.2 release simplifies this process by allowing the user to specify which LCU(s) belong to which controller, using CNTRL keywords. Under Xtract 4.2, the hypothetical configuration mentioned above could be defined as follows:

    • CNTRL CLCUS=(15,16,17,18)
    • CNTRL CLCUS=(1A,1B,1C,1D)
    • CNTRL CLCUS=(09,0A,0B,0C)
    • CNTRL CLCUS=(30,31,32,33)

    This would result in six output data sets (OUT001 to OUT006), one for each Lead Time run. However, the question becomes: In which OUTnnn data set will I find the LEADTIME input for a given controller? This depends on which LCU is encountered first in the SMF input stream, and is in practice virtually unpredictable. Xtract 4.2 solves this problem by allowing the user to identify each controller with a unique name which will be also used as the DDNAME. In this case, the above configuration would be defined as follows:
    • CNTRL CLCUS=(15,16,17,18),ID=AMDAHL
    • CNTRL CLCUS=(1A,1B,1C,1D),ID=EMC
    • CNTRL CLCUS=(09,0A,0B,0C),ID=HDS
    • CNTRL CLCUS=(30,31,32,33),ID=IBM
    • CNTRL CLCUS=(27,28,29,2A),ID=STK

    For this Xtract run, six output DDNAMEs would need to be specified: //AMDAHL DD … //EMC //HDS //IBM //STK //IBM3830 Obviously, the syntax for the operand of the ID keyword s the same as for the JCL DDNAME. Note also that LCUGRP=NO is not accepted in a CNTRL run. Please refer to the Xtract manual and to the Readme.txt file included with each new Xtract release for additional keywords and rules for the CNTRL specification.

  3. By default, Xtract does not process data generated on Saturdays and Sundays.To change the default, you must specify SATURDAY=YES and/or SUNDAY=YES.
  4. When processing GTF information, if you want to work at volume level only, do not specify MAXDSX=0 as it will likely cause Xtract to fail.Use ALLOC=NO instead.
  5. A WORK DD statement is needed when using PROCESS=GTF.You need to specify DSN=…, VOLSER=…, UNIT=…, DCB=…, BLKSIZE=… Good blocksizes are 23476 for a 3380 or 27998 for a 3390.
  6. Using the keywords ST1, ND1, ST2, ND2, Xtract lets you specify the RMF intervals you want to process.For instance, ST1=0900, ND1=1059, ST2=1400, ND2=1459 specifies that you want Xtract to process RMF intervals starting between 9.00 am and 10.59 am, as well as those starting between 2.00 pm and 2.59 pm.

    The SMF dump program IFASMFDP also allows the user to specify periods to be selected. There is one important difference, however. In the case of the SMF dump program, the time refers to the moment the record was written to the SMF data set.

    A misunderstanding of this fact may lead to frustrating consequences as in the following example:

    RMF intervals are 1 hour long and start on the hour. The user wants to examine the activity between 2 pm and 3 pm, and specifies this to IFASMFDP.

    IFASMFDP dumps all records that were written to the SMF data sets between 2 pm and 3 pm. RMF records written” between 2 pm and 3 pm (more exactly, a few seconds after 2 pm) are the ones describing the RMF interval ending at 2 pm, i.e., the 1 pm to 2 pm interval.

    Xtract is executed with ST1=1400 and ND1=1459 and does not find any applicable RMF records.

    In summary, it is important to remember that Xtract processes all RMF intervals that started during the specified period (or periods), while IFASMFDP dumps the records which were written during the specified period.