SCT Translation Utility

Non-Standard Method

There is a need to be able to translate values using the SCT DBD dictionary. This utility will do those translations. While it is probably the simplest way, it has performance considerations. If a program is to do several thousand translations, the long method will be much more efficient.

The module to use is SCTSRCH. It uses 5 arguments, the first two being constants. These five arguments are:

  1. System Number (e.g., '001' for SIS, '002' for FRS, '003' for HRS and '005' for LMS)
  2. Element Number (e.g., 'FG054 for FRS Department Code translation)
  3. Code to be Translated (15 bytes)
  4. Translated Value (50 bytes)
  5. Return Code. "0" is normal. Any other value indicates a problem. The REMARKS section of the Cobol program XSTRAN contains the meaning of these return codes.

Example

A program wants the department name for department codes in the FRS system. FRS is system 002. Department code is element FG054. Three variables need to be defined for code to be translated, translation value and return code. For example: 


   HDEPTCD           W           015 A
   HDEPTNAME         W           050 A
   HRTNCD            W           001 a

The sample program code would look something like the following: 


  HDEPTCD = '01311'
  %SCTSRCH '002' 'FG054' HDEPTCD HDEPTNAME HRTNCD

If HRTNCD is 0, then HDEPTNAME will contain the translation of Department Code 01311.

JCL Considerations

This routine requires that 2 DD statements be added to your JCL. The first DD statement is always the same, namely: 


//DTFILE   DD    DSN=AUP08V.ZSS.xxxx.DTFILE,DISP=SHR

where xxxx is PROD, TEST, INST or INST2, as appropriate.

The second DD statement depends on the SCT system being accessed. It should be: 


//XDFNNN   DD    DSN=xxx,DISP=SHR

where xxx is the name of the DBD (XDF) file for the system being accessed. For example, the production version of this file for FRS is AUP08V.ZSS.PROD.XDF002, while the install version for SIS is AUP07V.SIS.INST.XDF001 and is AUP03V.HRS.INST.XDF003 for HRS. For all systems in production, the name is AUP08V.ZSS.PROD.XDFnnn, where nnn is the SCT system number. For install and base versions, the files follow current naming standards (i.e., AUP07V.SIS for SIS, AUP02V.FRS for FRS and AUP03V.HRS for HRS). Note that the DDName is always the same, namely, XDFNNN.

Limitations

One of the biggest limitations here is that translations for only a single system can be done. This is a limitation of the underlying SCT translation program rather than in the Easytrieve Plus implementation. The same DDName is always used, so only a single XDF file can be referenced, limiting translations to that SCT system.

Technical

The SCTSRCH Easytrieve Plus module accesses an underlying Cobol program called SCTTBL. This, in turn, calls an SCT-supplied module called XSTRAN. The SCT translation process requires that data translations be opened for each element to be translated in order to provide a link to the extracted translations. All opens must be done before any translations can occur. In addition, once all translations are complete, the translation process must be closed or the calling program may abend. To bypass these technicalities, the SCTTBL module opens the translation process each time it is invoked, translates the value and then closes the process. This involves extra overhead, and can have a significant impact on program performance if a lot of translations are performed.

The XSTRAN program accesses the specified XDF file to get element length and translation length. It then accesses the specified DTFILE to do the actual translation.