Release 8.8.4 of the IET DevOps suite (including GuardIEn and Studio Developer) will be available on 21st September. This update contains some exciting new features and enhancements that will be previewed over the next few days.

This first preview focusses on security enhancements and support for Linux.

SSL/TLS support
Many of our customers are disallowing the use of plain unencrypted FTP. The GuardIEn client and Remote Processing Deamon (RPD) now support SSL/TLS encryption. This enables you to encrypt the data exchanged between the client and server using FTPS which can often be achieved through a setting on your existing FTP server rather than having to migrate to an alternative SFTP product.

Security Token
GuardIEn can now use a security token for user authentication. An example is when multi-factor authentication is enabled that requires a time-limited code to be included in the password and subsequent authentication using a generated token rather than the time-limited password.

A new server exit can be customised to generate a security token that is then returned to the client and can be inserted into the Gen Common Format Buffer sent on subsequent flows and used for authentication instead of the password. An example is when multi-factor authentication is enabled that requires a time-limited code to be included in the password. In this scenario, the initial logon will invoke the server exit which will generate a token (for example a JSON Web Token) which is returned to the client and then sent on subsequent server calls. The Gen runtime validation would then be customised to verify the user with the token rather than the password.

Support for Linux
The IET DevOps suite now supports Linux as a server platform to coincide with the recent support for Linux as a CSE platform.

Increased number of jobcard lines
The number of jobcard header lines supported by GuardIEn has been increased from 4 to 10, primarily to support long passwords in the jobcard.

Broadcom have recently published toolset PTF TSN86306 which changes the title of the Gen toolset from "CA Gen" to "Gen". 

This affects the GuardIEn toolset interaction since when it automatically starts the toolset for the checkout of a subset, GuardIEn 'finds' the toolset executable based on  the window title and a change is needed to take into account the new window title.

The next service packs for GuardIEn 8.7.8 and 8.8.4 will include support for this change, but if you apply the PTF prior to these service packs being available, then you can request a temporary fix from IET.

We wish you a very Merry Christmas and a Happy New Year. Instead of posting cards, we are making a donation to our wonderful local hospice Dorothy House.

   

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.