Steps to reproduce:
1. set up a jenkins build using the teamconcert plugin

2. set up a slave in a zOS V2R1 USS (unix system services) environment

3. start the build

Started by upstream project "prototype.dev" build number 1
originally caused by:
Started by an SCM change
Building remotely on hostname (z/os-02.01.00 s390x-z/os 02.01.00 z/os s390x-z/os-02.01.00 s390x-zos-02.01.00 s390x) in workspace /tmp/jenkins/workspace/prototype.dev/label_exp/s390x-zos-02.01.00
RTC : checkout...
RTC Checkout : Source control setup
RTC Checkout : Accepting changes into workspace "some_workspace(Jenkins)" ...
RTC Checkout : Deleting fetch destination "/tmp/jenkins/workspace/prototype.dev/label_exp/s390x-zos-02.01.00/workspace" before fetching ...
RTC Checkout : Fetching files to fetch destination "/tmp/jenkins/workspace/prototype.dev/label_exp/s390x-zos-02.01.00/workspace" ...
RTC Checkout : Fetching Completed

4. All of the files are loaded as ASCII instead of EBCDIC. For plain text files (source code) to be used on zOS, they have to be loaded as EBCDIC, otherwise they are not usable.

When the files are loaded as ASCII (code page: ISO8859-1), they are not readable/usable on zOS:
cat hello.c
(unreadable text, as the encoding is incorrect)

file hello.c
hello.c: binary data

They should be loaded as EBCDIC (code page: IBM-1047):
cat hello.c
#include "stdio.h"
int main () {
printf ( "Hello C World!\n" );
return 0;
}

file hello.c
hello.c: text

The workarounds are to either use iconv on USS to convert the files, or run 'scm load' as the first step of the build, to re-load the source in the correct encoding.