Titus Aguilar

Thank You Mickey. We used big-endian. Our server is an RHEL 8.5 s390x GNU/Linux. Still, the values should just flip positions if the endianness is the issue. But the values appear to be just slightly off. For COMP-1 with value +1234, z/OS shows x'434D2000' vs x'449A4000' in zLinux. For -1234, z/OS = x'C34D2000' vs x'C49A4000' in zLinux, The z/OS hex values are unconverted EBCDIC if that help clarify. [edit] The posted values matches the zLinux values I got albeit in Big-endian. Thanks! Titus

Thank You Mickey. We used big-endian. Our server is an RHEL 8.5 s390x GNU/Linux. Still, the values should just flip positions if the endianness is the issue. But the values appear to be just slightly off. For COMP-1 with value +1234, z/OS shows x'434D2000' vs x'449A4000' in zLinux. For -1234, z/OS = x'C34D2000' vs x'C49A4000' in zLinux, The z/OS hex values are unconverted EBCDIC if that help clarify. Thanks! Titus

Hi Simon, Do you mind providing the 2 companies offering commercial support? My client is looking for support for GC3.2. Thanks! Titus

Hi, I'm working on a modernization project. We are attempting to offload some batch jobs from z/OS to GC 3.2 in Linux with as little coding change as possible. We ftp the EBCDIC data in binary format and handle all conversion in the zLinux side. Fun project :-( For Binary (COMP, COMP-4, COMP-5) and Packed Decimals (COMP-3) fields, I found that the hex values are identical in zOS EBCDIC and zLinux ASCII. That's good. COMP-1 and COMP-2 fields on the other hand are not matching. Is that expected? Or...

Hi, I'm working on a modernization project. We are attempting to offload some batch jobs from z/OS to GC 3.2 in Linux with as little coding change as possible. We ftp the EBCDIC data in binary format and handle all conversion in the zLinux side. Fun project :-( For Binary (COMP, COMP4, COMP5) and Packed Decimals (COMP-3) fields, I found that the hex values are identical in zOS EBCDIC and zLinux ASCII. That's good. For COMP-1 and COMP-2 on the other hand are not matching. Is that expected? Or is there...

Hello Simon, The GC 2.0 fork team wont commit to merging their enhancements to GC3.2 and future versions. As such, the client has decided to forgo the forked version and use the GC3.2 base instead for product support and continuity reasons. This meant that we have to work on the data conversion component from z/OS EBCDIC to Linux ASCII. Turns out, the fork solution was aimed at getting around the need for packed data expansion when processing EBCDIC data in ASCII. It's quite a novel solution actually...

Oh wow. What a blast from the past. Ashton-Tate dBase and Clipper! Of all the languages I programmed on, I love Clipper Summer 87 the best. Simple. Straight to the point. Almost like the original Python.

Thank you Simon. Will check with the dev team who created the fork. And will definitely reach out to you on the fork review as soon as possible! TIA... Cheers! Titus