The FTP function provided with the GuardIEn client uses the Microsoft WinInet library which does not support TLS encryption (often called FTPS). 

For the next Release 8.8 service pack, the GuardIEn client DLL has been modified to use the libCurl library that supports SSL/TLS encryption. 

FTP is used in the GuardIEn client for:

- Transferring transaction (.trn) files between the toolset and encyclopaedia server for upload/download tasks
- Transferring XOS files between the client and the XOS file server(s)
- Transferring XOS minor version files between the client and encyclopaedia server

If the server supports or requires TSL encryption, then the client will automatically negotiate the encryption.

If you would like to participate in beta testing TLS encryption for the GuardIEn FTP client functions, please contact us.

If you apply the following PTFs to the Gen 8.6 host encyclopaedia, invoking code generation from GuardIEn fails with an abend caused by a missing TIRCSSTR module:

- z/OS COBOL Generators and z/OS Runtimes upgrade to COBOL V6.2, C/C++ V2.2, and Db2 V12 (LU01883-LU01889 and LU01908)

The cause is that there is a change to the Gen generators that requires this new module but it is located in CEHBPLD1 not the usual CEHBPLD0 dataset and by default the GuardIEn JCL for invoking the generators does not include CEHBPLD1 in the STEPLIB.

The solution is as follows:

1) Edit the GEN.PROCLIB member GDSETPRM and add in a new variable after GENLOAD:

// SET GENLOAD=&GENPREF..CEHBPLD0
// SET GENLOAD1=&GENPREF..CEHBPLD1


2) Edit the GEN.PROCLIB member GDGNSTEP and add GENLOAD1 into the STEPLIB after GENLOAD:

//        DD DISP=SHR,DSN=&GENLOAD 
//        DD DISP=SHR,DSN=&GENLOAD1

IET is delighted to announce the availability in Release 8.8.3 of significant new component for GuardIEn called the Remote Processing Daemon.

The GuardIEn Remote Processing Daemon (RPD) provides integrated file transfer and remote processing services for GuardIEn as an alternative to using standard remote or secure shell and FTP utilities. It is especially useful for sites where a suitable and/or secure remote shell product is not installed or configured or where current use of insecure protocols like FTP is discouraged or not available. Note that use of the RPD is optional, and existing support for FTP/SSH utilities is still available.
 
GuardIEn uses file transfer services for:

• Transferring transaction (.trn) files between the toolset and encyclopaedia server for upload/download tasks
  
• Transferring XOS files between the client and the XOS file server(s)
  
• Transferring XOS minor version files between the client and encyclopaedia server
  
• Transferring remote installation (.rmt) files from a GuardIEn CSE server to a remote build server
  
• Submitting MVS batch jobs from a GuardIEn CSE server
  
• Transferring HE-XGen and Remote processing .trn and .ctl files from the HE to the CSE server
  

• Processing XOS migrates and builds on a file server
  
• Processing installs and other SU steps on a remote build server
  

• The RPD Listener executes as a service on the GuardIEn and/or remote server and processes requests issued from the client. The RPD listener is a multi-threaded application to provide a high level of concurrency and availability.
  
• The RPD client resides on the requesting machine and sends processing requests to the RPD Listener. The client is embedded within the GuardIEn client and server executables and is also available as a command line interface (CLI) standalone program to enable script integration.
  

Release 8.8.3 and Release 8.7.7 are now available to download. 

You can view the release notes here: https://www.iet.uk/Download/RelNotes.htm

IET recommend that you install the service pack to obtain the latest fixes and new features.

One of the major advantages of Gen is the ability to generate code for multiple target environments. Many customers have switched platforms over the life of their applications, for example from MVS/COBOL to UNIX/C or EJB/Java.

If external code is developed in external action blocks then it fairly obvious that the EAB source code needs to be modified when generating for a different target environment. But what about the inline code?

Adding inline code statements to a Gen action diagram is a useful alternative to coding external action blocks, but care has to be taken when switching environments or developing multi-platform code.

When inline code is developed, you specify on the statement what language the inline code should be generated for and optiionally further restrict the statement to specified OS, DBMS and even TP Monitor. 

However if the action block code is then generated for a different target environment, the inline code statements that do not match the specified environment are ignored. This means that the inline code is not executed, and unless there is some check further on in the action block, you might not ever be aware that the code is not executed.

To help with this potential issue, a new VerifIEr check (IET169) has been developed which will report on action blocks that contain inline code that does not match a specified environment

Release 8.8 Service Pack 2 and Release 8.7 Service Pack 6 are now available to download. You can view the release notes here: https://www.iet.uk/Download/RelNotes.htm

IET recommend that you install the service pack to obtain the latest fixes.

xTrace Release 2.6.5 is now available to download.

A significant enhancement introduced in this release is a change to the xTrace runtime and source code post-processor that almost eliminates the runtime overhead associated with trace support when the application is executed without the user wishing to actively trace the code. 

This enhancement makes it feasible to always generate the code with trace enabled for development environments without the trade-off of the increased CPU consumption due to the additional trace logic in the generated code.

Starting a trace session merely involves starting the xTrace Monitor client to immediately be able to trace through the application rather than having to regenerate the code with trace with the time and effort that this involves.

The GuardIEn Implemented PADs feature provides a mechanism for storing the action block statements extracted from the generated source code as part of a system update generation step.

If you use Minor Versions in GuardIEn, there is no need to also use Implemented PADs, but we have noticed that some projects may not have disabled the use of Implemented PADs (or even be aware of their existance) when they enabled Minor Version support.

It is recommended that you consider disabling the use of Implemented PADs and cleanup the PAD folder if you use Minor Versions. They are disabled by setting the MAXPUPAD project property to a value of 0.

Release 8.8 Service Pack 1 is now available to download. You can view the release notes here: https://www.iet.uk/Download/RelNotes.htm

IET recommend that you install the service pack to obtain the latest fixes.

Rapdie 2.0 will be retired on 1st June 2022. It is recommended that you plan to upgrade to Release 3.0 prior to this date.