search

hercules-390 / hyperion

Hercules 390
Other
246 stars 69 forks source link

Can we integrate TCPNJE to mainstream #274

Open ivan-w opened 5 years ago

ivan-w commented 5 years ago

TCPNJE device allows communication for NJE capable spool/job submission/file transfer between hosts over network with unreliable latency. (RSCS, JES2, JES3, POWER). Can we integrate this to current SDL Hyperion ? --Ivan

ivan-w commented 5 years ago

This is a patch by Peter Coghlan that implements it..

PeterCoghlan commented 5 years ago

Ideally, I would like to support a single version of TCPNJE that works with any Hercules variants. There are already discrepancies between the DEVHND structure as defined in production Hercules and in "regular" Hyperion so this is already difficult as no provision was ever made for detecting different versions of DEVHND. Nevertheless, I have included some kludgy hash ifdefs to take account of the different version of DEVHND in Hercules 3.x and "regular" Hyperion, as well as to deal with another hidden landmine present in all recent Hyperion variants.

More recently, SDL Hyperion has introduced another change to DEVHND which as far as I can see is like the previous changes, undetectable (as well as undocumented, unless I just can't find where it is documented). Compared to "regular" Hyperion, the tenth element of DEVNHD has changed from type DEVSF (which is typedef void) to type DEVHF (which previously existed as void and apparantly was not used for anything - I think but seems to now have been changed to type BYTE). To me, this means that in "regular" Hyperion, the halt function in DEVHND does not return a value but in SDL Hyperion, it does return a value. However, as far as I can see, SDL Hyperion never checks the value returned from the halt function anyway, so why have it return a value at all? Can we not just put this back the way it was and avoid yet another new and apparantly unnecessary incompatibility?

While unraveling the above mystery, I downloaded the latest and greatest SDL Hyperion to make sure the updates I was making to TCPNJE to work around the issue would work with it. I found I could no longer compile SDL Hyperion at all on my platform of choice (VMS), where I develop TCPNJE because the ability to not have OPTION_DYNAMIC_LOAD defined has been completely removed.

At this point I just gave up. I can't support what I can't compile.