Optimizing your GDT Environment

1. Optimizing your GDT Environment

2. Optimizing your GDT Environment • Fileshare Server name used as a Global variable • Easier Operations • Getting same File Status behavior as on the Mainframe • Easier Troubleshooting • Getting records Initialized the same way as on the mainframe (TDS) • Data Integrity • The STEPMSG directive • Improved Speed

3. Optimizing your GDT Environment • Using the DELAY TABLES within FSYS01 • Improved Operations • Turning on and off your logs and flows • Improved Speed • Using –CLASS parameter with GDTBATCH on the command line • Improved Operations • Using the H_WINUID directive on the Jor setup within gdtbatch.par • Improved Troubleshooting

4. Fileshare Server name used as a Global Variable • Easier Operations • The SRVRNAME for Fileshare can be an environment variable • Enviroment variable CustFS is set to the Fileshare name. • First Character must be a ‘$’ sign and the second character must not be a ‘$’ sign • Example: In the GDTDSGEN.IN, you would have • USE is FILESHARE “$CustFS” ……. • Example: In your Work Environment Settings, • SET CustFS=$$INF01

5. Fileshare Server name used as a Global Variable • Updating GDTDSGEN.IN

6. Fileshare Server name used as a Global Variable • Updating your Environment Setting file

7. Fileshare Server name used as a Global Variable • After the TDSGEN is run, you can view the FS01.CFG file and note that INF01 is inserted as the fileshare name

8. Fileshare Server name used as a Global Variable • Setting a Global Environment variable for Fileshare that can be used in your JCL

9. Fileshare Server name used as a Global Variable • Using the Global Variable name for the fileshare in the Assign statement

10. Fileshare Server name used as a Global Variable • The JOR shows the insertion of the Global Variable for the fileshare being inserted in the Assign statement for the EMPLOYEE file

11. Getting same File Status behavior as on the Mainframe • Understand How this works on the Mainframe • If no FILE-STATUS declared and no DECLARATIVE section • Mainframe (Operating System) causes the program to immediately abort on a FILE-STATUS equal or greater than “30”

12. Getting same File Status behavior as on the Mainframe • If FILE-STATUS is declared but no DECLARATIVE section • Mainframe (Operating System) causes the program to abort immediately on a FILE-STATUS equal or greater than “30”. • If FILE-STATUS is below a “30” the FILE-STATUS will be received by the program and can be used for additional checks. • If FILE-STATUS is “30” and above, this is not returned to the program as it just aborts.

13. Getting same File Status behavior as on the Mainframe • If FILE-STATUS is declared and DECLARATIVE section is present • Mainframe (Operating System) does not check the FILE-STATUS for that file. • If FILE-STATUS is below a “30” the FILE-STATUS will be received by the program and can be used for additional checks. • If FILE-STATUS is “30” and above, the FILE-STATUS will be received and the corresponding DECLARATIVE section will be performed. The USER program is then responsible for the APPROPRIATE ACTION like CALL “ABORT”.

14. Getting same File Status behavior as on the Mainframe • History with GDT on filestatus checking • Up until about mid-year 2003, GDT software had no ability to know that a Declarative section was being used for a file • Only option prior to mid-year 2003, was to have same ability as Mainframe had when only Filestatus checking was being done or No Filestatus checking • With Net Express 3.1 and Net Express 4.0, Micro Focus enabled a bit in the File Handler which tells if a program uses a Declarative Section for File(s) • Now GDT has enabled a directive that can be set in the GDTSYS.PAR file which will enable Filestatus behavior to be the same as the Mainframe

15. Getting same File Status behavior as on the Mainframe • In GDTSYS.PAR • Under the |Files| tag • FILE-STATUS = asMainframe • Follows the full Mainframe behavior of File Status checking shown in previous slides. • FILE-STATUS = asGDT • This will follow the rules of the Mainframe only if the program is using FILESTATUS checking or not using FILESTATUS checking. • No DECLARATIVE SECTION checking is done.

16. Getting records Initialized the same way as on the mainframe (TDS) • Reason for Implementation: • Instances where a Read Random was being done to a key that did not exist • Some code was accessing fields in the record after this bad read and obtaining incorrect information

17. Getting records Initialized the same way as on the mainframe (TDS) • Resolution: • Records needed to be initialized the same way as being done on the mainframe • Handled before and file is accessed and before the first operation of a file • Handled in the TDSgen (GDTDSGEN.IN) • INITRECTYPE = LOW-VALUES record initialized with low values • INITRECTYPE = INITIALIZE record initialized based on first 01 definition following FD statement. Corresponding to COBOL Rules. • INITRECTYPE = UNSPEC keep previous behavior. Whatever is in memory!

18. Getting records Initialized the same way as on the mainframe (TDS) • Using the INITRECTYPE = LOW-VALUES in TDSgen

19. Getting records Initialized the same way as on the mainframe (TDS) • Using the INITRECTYPE = INITIALIZE in TDSgen

20. The STEPMSG directive • To show detailed information during runtime on the screen (Counters) • Depending on graphic card being used, your speed improvement will vary from 10% to 20% when this option is turned OFF. • High end graphic card, you may see the 10% improvement • Low end graphic card, you may see the 20% improvement

21. The STEPMSG directive • Top: with Stepmsg Bottom: without Stepmsg 8% improvement

22. Using the DELAY TABLES within FSYS01 • Delay Tables • Used to control the timings as to when entries are cleared from FSYS01 (h_sysjob file) • Very important in a high volume batch processing environment.

24. Turning on and off your logs and flows • Logs and Flows you can control the creation of • Saves space and improves speed

25. Using –CLASS parameter with GDTBATCH on the command line • GDTBATCH with class provided on the command line • Better control of batch processing when not using the GDT Console • Job will automatically be under control of FSYS01 • Example GDTBATCH \INFOSOL\PROD\JCL\ADDRESS.JCL –CLASS H

26. Using the H_WINUID directive on the JOR setup within gdtbatch.par • H_WINUID • Added to JORFILE setting in GDTBATCH.PAR • Adds the ComputerName you are logged on thru to the name of the JOR produced.

27. Using the H_WINUID directive on the JOR setup within gdtbatch.par