[hercules-390] Building Hercules for TK4-

[[e-mail] [hercules-390]]

I've built the 4.0 version of hercules using the cmake detailed on this list process and made a simple instruction execution mod in general2.c. I'd like to do the same mod in the hercules build used in TK4-.


I can see the source in the TK4- distribution but not the build instructions. I know the build is different from the "version" output and my build seems to lack some of the automation features in TK4-


How do I rebuild the TK4- version?

[[e-mail] [hercules-390]]

(signed) Bill Rowe
https://olduino.wordpress.com/ https://olduino.wordpress.com/

[Vince Coen [e-mail] [hercules-390]]

The version of Hercules in TK4 is a special, constructed by Jurgen to
support features within TK4.

It is not as far as I know available in source form also the spinaker
series - v3.13 and Hyperion v4 and may be the version of it from Fish
may well have later features but that said I cannot compile without
errors/warning any version of Hyperion although the Fish version seems
to have less (warning and errors) but not low enough for me to feel safe
using it and yes have reported this as a bug on the Fish github site but
no response yet.


Vince

Post by ***@yahoo.com [hercules-390]
I've built the 4.0 version of hercules using the cmake detailed on
this list process and made a simple instruction execution mod in
general2.c.  I'd like to do the same mod in the hercules build used in
TK4-.
I can see the source in the TK4- distribution but not the build
instructions.  I know the build is different from the "version" output
and my build seems to lack some of the automation features in TK4-
How do I rebuild the TK4- version?
------------------------------------------------------------------------
------------------------------------------------------------------------

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

but that said I cannot compile without errors/warning any
version of Hyperion although the Fish version seems to have
less (warning and errors) but not low enough for me to feel
safe using it

Eh?! There shouldn't be *ANY* errors or warnings! (except maybe a couple of benign warnings when using gcc, but with clang the build s/b squeaky clean)

and yes have reported this as a bug on the Fish github site
but no response yet.

I must have missed it. What's the issue#?

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]

Post by Vince Coen ***@gmail.com [hercules-390]
and yes have reported this as a bug on the Fish github
site but no response yet.

I must have missed it. What's the issue#?

NEVER MIND! I found it.

It's issue #144: "Build failure on Mageia v6 X64", and yes, I did see it, and yes you are right, I haven't had time to respond to it yet.

But I will. (Soon)

[Vince Coen [e-mail] [hercules-390]]

Thanks,

Currently use thee Hercules from TK4 and playing with v3.13 but have
also issues.

The best one so far as when starting TK4 having run the DASD program for
checking the volumes with a  -3 which found problems with some of the
volumes.

Then run TK4 unattended which reports various problems with yep, the
volumes and these are exactly the one's reported with the DASD utility.
See :-

--
21:22:49 HHC00414I 0:0152 CKD file dasd/hasp00.152: cyls 411 heads 19
tracks 7809 trklen 13312
21:22:49 HHC00363W 0:0152 CCKD file dasd/hasp00.152: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0152 CCKD file dasd/hasp00.152: forcing check level 1
21:22:49 HHC00368W 0:0152 CCKD file dasd/hasp00.152: free space errors
detected
21:22:49 HHC00377I 0:0152 CCKD file dasd/hasp00.152: free space rebuilt
21:22:49 HHC00414I 0:0191 CKD file dasd/mvscat.191: cyls 1114 heads 15
tracks 16710 trklen 56832
21:22:49 HHC00363W 0:0191 CCKD file dasd/mvscat.191: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0191 CCKD file dasd/mvscat.191: forcing check level 1
21:22:49 HHC00368W 0:0191 CCKD file dasd/mvscat.191: free space errors
detected
21:22:49 HHC00377I 0:0191 CCKD file dasd/mvscat.191: free space rebuilt
21:22:49 HHC00414I 0:0248 CKD file dasd/mvsdlb.248: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0248 CCKD file dasd/mvsdlb.248: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0248 CCKD file dasd/mvsdlb.248: forcing check level 1
21:22:49 HHC00368W 0:0248 CCKD file dasd/mvsdlb.248: free space errors
detected
21:22:49 HHC00377I 0:0248 CCKD file dasd/mvsdlb.248: free space rebuilt
21:22:49 HHC00414I 0:0148 CKD file dasd/mvsres.148: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0148 CCKD file dasd/mvsres.148: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0148 CCKD file dasd/mvsres.148: forcing check level 1
21:22:49 HHC00368W 0:0148 CCKD file dasd/mvsres.148: free space errors
detected
21:22:49 HHC00377I 0:0148 CCKD file dasd/mvsres.148: free space rebuilt
21:22:49 HHC00414I 0:0160 CKD file dasd/page00.160: cyls 698 heads 12
tracks 8376 trklen 8704
21:22:49 HHC00363W 0:0160 CCKD file dasd/page00.160: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0160 CCKD file dasd/page00.160: forcing check level 1
21:22:49 HHC00368W 0:0160 CCKD file dasd/page00.160: free space errors
detected
21:22:49 HHC00377I 0:0160 CCKD file dasd/page00.160: free space rebuilt
21:22:49 HHC00414I 0:0161 CKD file dasd/page01.161: cyls 698 heads 12
tracks 8376 trklen 8704
21:22:49 HHC00363W 0:0161 CCKD file dasd/page01.161: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0161 CCKD file dasd/page01.161: forcing check level 1
21:22:49 HHC00368W 0:0161 CCKD file dasd/page01.161: free space errors
detected
21:22:49 HHC00377I 0:0161 CCKD file dasd/page01.161: free space rebuilt
21:22:49 HHC00414I 0:0240 CKD file dasd/pub000.240: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0240 CCKD file dasd/pub000.240: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0240 CCKD file dasd/pub000.240: forcing check level 1
21:22:49 HHC00368W 0:0240 CCKD file dasd/pub000.240: free space errors
detected
21:22:49 HHC00377I 0:0240 CCKD file dasd/pub000.240: free space rebuilt
21:22:49 HHC00414I 0:0241 CKD file dasd/pub010.241: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0241 CCKD file dasd/pub010.241: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0241 CCKD file dasd/pub010.241: forcing check level 1
21:22:49 HHC00368W 0:0241 CCKD file dasd/pub010.241: free space errors
detected
21:22:49 HHC00377I 0:0241 CCKD file dasd/pub010.241: free space rebuilt
21:22:49 HHC00414I 0:0270 CKD file dasd/pub001.270: cyls 960 heads 12
tracks 11520 trklen 35840
21:22:49 HHC00364W 0:0270 CCKD file dasd/pub001.270: forcing check level 1
21:22:49 HHC00414I 0:0271 CKD file dasd/pub011.271: cyls 960 heads 12
tracks 11520 trklen 35840
21:22:49 HHC00363W 0:0271 CCKD file dasd/pub011.271: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0271 CCKD file dasd/pub011.271: forcing check level 1
21:22:49 HHC00368W 0:0271 CCKD file dasd/pub011.271: free space errors
detected
21:22:49 HHC00377I 0:0271 CCKD file dasd/pub011.271: free space rebuilt
21:22:49 HHC00414I 0:0280 CKD file dasd/pub002.280: cyls 1772 heads 15
tracks 26580 trklen 47616
21:22:49 HHC00364W 0:0280 CCKD file dasd/pub002.280: forcing check level 1
21:22:49 HHC00414I 0:0281 CKD file dasd/pub012.281: cyls 1772 heads 15
tracks 26580 trklen 47616
21:22:49 HHC00363W 0:0281 CCKD file dasd/pub012.281: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0281 CCKD file dasd/pub012.281: forcing check level 1
21:22:49 HHC00368W 0:0281 CCKD file dasd/pub012.281: free space errors
detected
21:22:49 HHC00377I 0:0281 CCKD file dasd/pub012.281: free space rebuilt
21:22:49 HHC00414I 0:0290 CKD file dasd/pub003.290: cyls 1114 heads 15
tracks 16710 trklen 56832
21:22:49 HHC00363W 0:0290 CCKD file dasd/pub003.290: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0290 CCKD file dasd/pub003.290: forcing check level 1
21:22:49 HHC00368W 0:0290 CCKD file dasd/pub003.290: free space errors
detected
21:22:49 HHC00377I 0:0290 CCKD file dasd/pub003.290: free space rebuilt
21:22:49 HHC00414I 0:0291 CKD file dasd/pub013.291: cyls 2047 heads 15
tracks 30705 trklen 56832
21:22:49 HHC00363W 0:0291 CCKD file dasd/pub013.291: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0291 CCKD file dasd/pub013.291: forcing check level 1
21:22:49 HHC00368W 0:0291 CCKD file dasd/pub013.291: free space errors
detected
21:22:49 HHC00377I 0:0291 CCKD file dasd/pub013.291: free space rebuilt
21:22:49 HHC00414I 0:0149 CKD file dasd/smp001.149: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0149 CCKD file dasd/smp001.149: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0149 CCKD file dasd/smp001.149: forcing check level 1
21:22:49 HHC00368W 0:0149 CCKD file dasd/smp001.149: free space errors
detected
21:22:49 HHC00377I 0:0149 CCKD file dasd/smp001.149: free space rebuilt
21:22:49 HHC00414I 0:014A CKD file dasd/smp002.14a: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00414I 0:014B CKD file dasd/smp003.14b: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00414I 0:014C CKD file dasd/smp004.14c: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00414I 0:0131 CKD file dasd/sort01.131: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00364W 0:0131 CCKD file dasd/sort01.131: forcing check level 1
21:22:49 HHC00414I 0:0132 CKD file dasd/sort02.132: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00364W 0:0132 CCKD file dasd/sort02.132: forcing check level 1
21:22:49 HHC00414I 0:0133 CKD file dasd/sort03.133: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00363W 0:0133 CCKD file dasd/sort03.133: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0133 CCKD file dasd/sort03.133: forcing check level 1
21:22:49 HHC00368W 0:0133 CCKD file dasd/sort03.133: free space errors
detected
21:22:49 HHC00377I 0:0133 CCKD file dasd/sort03.133: free space rebuilt
21:22:49 HHC00414I 0:0134 CKD file dasd/sort04.134: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00364W 0:0134 CCKD file dasd/sort04.134: forcing check level 1
21:22:49 HHC00414I 0:0135 CKD file dasd/sort05.135: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00363W 0:0135 CCKD file dasd/sort05.135: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0135 CCKD file dasd/sort05.135: forcing check level 1
21:22:49 HHC00368W 0:0135 CCKD file dasd/sort05.135: free space errors
detected
21:22:49 HHC00377I 0:0135 CCKD file dasd/sort05.135: free space rebuilt
21:22:49 HHC00414I 0:0136 CKD file dasd/sort06.136: cyls 203 heads 20
tracks 4060 trklen 7680
21:22:49 HHC00363W 0:0136 CCKD file dasd/sort06.136: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0136 CCKD file dasd/sort06.136: forcing check level 1
21:22:49 HHC00368W 0:0136 CCKD file dasd/sort06.136: free space errors
detected
21:22:49 HHC00377I 0:0136 CCKD file dasd/sort06.136: free space rebuilt
21:22:49 HHC00414I 0:0140 CKD file dasd/work00.140: cyls 560 heads 30
tracks 16800 trklen 19456
21:22:49 HHC00363W 0:0140 CCKD file dasd/work00.140: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0140 CCKD file dasd/work00.140: forcing check level 1
21:22:49 HHC00368W 0:0140 CCKD file dasd/work00.140: free space errors
detected
21:22:49 HHC00377I 0:0140 CCKD file dasd/work00.140: free space rebuilt
21:22:49 HHC00414I 0:0170 CKD file dasd/work01.170: cyls 960 heads 12
tracks 11520 trklen 35840
21:22:49 HHC00363W 0:0170 CCKD file dasd/work01.170: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0170 CCKD file dasd/work01.170: forcing check level 1
21:22:49 HHC00368W 0:0170 CCKD file dasd/work01.170: free space errors
detected
21:22:49 HHC00377I 0:0170 CCKD file dasd/work01.170: free space rebuilt
21:22:49 HHC00414I 0:0180 CKD file dasd/work02.180: cyls 886 heads 15
tracks 13290 trklen 47616
21:22:49 HHC00363W 0:0180 CCKD file dasd/work02.180: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0180 CCKD file dasd/work02.180: forcing check level 1
21:22:49 HHC00368W 0:0180 CCKD file dasd/work02.180: free space errors
detected
21:22:49 HHC00377I 0:0180 CCKD file dasd/work02.180: free space rebuilt
21:22:49 HHC00414I 0:0190 CKD file dasd/work03.190: cyls 1114 heads 15
tracks 16710 trklen 56832
21:22:49 HHC00363W 0:0190 CCKD file dasd/work03.190: cdevhdr
inconsistencies found, code 0001
21:22:49 HHC00364W 0:0190 CCKD file dasd/work03.190: forcing check level 1
21:22:49 HHC00368W 0:0190 CCKD file dasd/work03.190: free space errors
detected
21:22:49 HHC00377I 0:0190 CCKD file dasd/work03.190: free space rebuilt
--

Yes the system has been shutdown correctly both before running dasd

Ohh, program was CCKDCDSK -3


Just love it when I get these type of issues  - OK, NOT :)

Interestingly when run with -4 -f produces loads of trk[nnnn] recovered
offset 0x2826de len nnnn

But when rerun does the same so does not look if its fixing anything. Is
it something to do with working on non-compressed volumes. If so why is
it working on them if so?



Vince

[...]

Post by Vince Coen ***@gmail.com [hercules-390]
and yes have reported this as a bug on the Fish github
site but no response yet.

I must have missed it. What's the issue#?

NEVER MIND! I found it.
It's issue #144: "Build failure on Mageia v6 X64", and yes, I did see
it, and yes you are right, I haven't had time to respond to it yet.
But I will. (Soon)

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

cyls 411 heads 19 tracks 7809 trklen 13312
cdevhdr inconsistencies found, code 0001
forcing check level 1
free space errors detected
free space rebuilt
cyls 1114 heads 15 tracks 16710 trklen 56832
cdevhdr inconsistencies found, code 0001
forcing check level 1
free space errors detected
free space rebuilt

<snip; etc,etc,etc...>


How large are you dasd image files? What does 'ls' show?

If they are truly compressed CCKD volumes (as opposed to uncompressed CKD volumes), then the size of the dasd image files are limited to less than 4GB.. Once they reach that limit then you start having weird problems such as the ones you're currently experiencing.

Until Hercules 64-bit CCKD can be created, you will have to closely monitor the size of your CCKD dasd image files, and once they begin to approach 4GB in size, you need to create a new shadow file for that/those volume(s) via the sf+devn (or sf+*) command (and then update your Hercules configuration file appropriately as well too).

Is it something to do with working on non-compressed volumes?

You cannot(?) run CCKD utilities against non-CCKD volumes (or at least you shouldn't be able to! If you can, then that's a bug!)

If so why is it working on them if so?

Because of a bug perhaps?

[[e-mail] [hercules-390]]

In that case 'Houston we have a problem'


Yes these are al,l at least as far as I know all uncompressed file from the TK4 distribution.




As the utility worked on them without reporting a problem for doing so then yes, I guess that is a significant bug.


Now the problem is how do I fix it ?


It is a pity that there is not a similar utility for doing the same for uncompressed files and as per erquest here is a ls -la on the dasd directory:


---

[***@applewood dasd]$ du -sh
528M .
[***@applewood dasd]$ ls -la
total 540216
drwxr-xr-x 2 vince vince 4096 Sep 1 18:17 ./
drwxr-xr-x 46 vince vince 4096 Sep 4 19:56 ../
-rw-r--r-- 1 vince vince 50622011 Sep 3 21:22 cbt000.340
-rw-r--r-- 1 vince vince 53835543 Sep 3 21:22 cbt001.341
-rw-r--r-- 1 vince vince 46081741 Sep 3 21:22 cbt002.342
-rw-r--r-- 1 vince vince 27277301 Sep 3 21:22 cbtcat.343
-rw-r--r-- 1 vince vince 2634736 Sep 3 23:33 hasp00.152
-rw-r--r-- 1 vince vince 13046195 Sep 3 23:32 mvscat.191
-rw-r--r-- 1 vince vince 18663006 Sep 3 23:32 mvsdlb.248
-rw-r--r-- 1 vince vince 17548846 Sep 3 23:14 mvsres.148
-rw-r--r-- 1 vince vince 7516088 Sep 3 23:14 page00.160
-rw-r--r-- 1 vince vince 5653466 Sep 3 23:14 page01.161
-rw-r--r-- 1 vince vince 18455492 Sep 3 21:24 pub000.240
-rw-r--r-- 1 vince vince 3721010 Sep 3 21:22 pub001.270
-rw-r--r-- 1 vince vince 22270682 Sep 3 21:22 pub002.280
-rw-r--r-- 1 vince vince 18163278 Sep 3 21:22 pub003.290
-rw-r--r-- 1 vince vince 1115868 Sep 3 21:22 pub010.241
-rw-r--r-- 1 vince vince 1485216 Sep 3 21:22 pub011.271
-rw-r--r-- 1 vince vince 22749321 Sep 3 21:22 pub012.281
-rw-r--r-- 1 vince vince 23349944 Sep 3 21:22 pub013.291
-rw-r--r-- 1 vince vince 815275 Sep 3 23:13 smp001.149
-rw-r--r-- 1 vince vince 638608 Sep 3 21:22 smp002.14a
-rw-r--r-- 1 vince vince 180270 Sep 3 21:22 smp003.14b
-rw-r--r-- 1 vince vince 1797253 Sep 3 21:22 smp004.14c
-rw-r--r-- 1 vince vince 138143 Sep 3 21:22 sort01.131
-rw-r--r-- 1 vince vince 241209 Sep 3 21:22 sort02.132
-rw-r--r-- 1 vince vince 57278 Sep 3 21:22 sort03.133
-rw-r--r-- 1 vince vince 424453 Sep 3 21:22 sort04.134
-rw-r--r-- 1 vince vince 163564 Sep 3 21:22 sort05.135
-rw-r--r-- 1 vince vince 615838 Sep 3 21:22 sort06.136
-rw-r--r-- 1 vince vince 46002332 Sep 3 21:22 src000.348
-rw-r--r-- 1 vince vince 45706459 Sep 3 21:22 src001.349
-rw-r--r-- 1 vince vince 44402400 Sep 3 21:22 src002.34a
-rw-r--r-- 1 vince vince 6310976 Sep 3 21:22 srccat.34b
-rw-r--r-- 1 vince vince 369030 Sep 3 21:22 work00.140
-rw-r--r-- 1 vince vince 2977099 Sep 3 21:22 work01.170
-rw-r--r-- 1 vince vince 2188136 Sep 3 21:22 work02.180
-rw-r--r-- 1 vince vince 45806135 Sep 3 21:22 work03.190

---


Using tk4.cnf (hercules) config file containing :


#
# TK4- DASD
#
0152 3330 dasd/hasp00.152
0191 3390 dasd/mvscat.191
0248 3350 dasd/mvsdlb.248
0148 3350 dasd/mvsres.148
0160 3340 dasd/page00.160
0161 3340 dasd/page01.161
0240 3350 dasd/pub000.240
0241 3350 dasd/pub010.241
0270 3375 dasd/pub001.270
0271 3375 dasd/pub011.271
0280 3380 dasd/pub002.280
0281 3380 dasd/pub012.281
0290 3390 dasd/pub003.290
0291 3390 dasd/pub013.291
0149 3350 dasd/smp001.149
014a 3350 dasd/smp002.14a
014b 3350 dasd/smp003.14b
014c 3350 dasd/smp004.14c
0131 2314 dasd/sort01.131
0132 2314 dasd/sort02.132
0133 2314 dasd/sort03.133
0134 2314 dasd/sort04.134
0135 2314 dasd/sort05.135
0136 2314 dasd/sort06.136
0140 3350 dasd/work00.140
0170 3375 dasd/work01.170
0180 3380 dasd/work02.180
0190 3390 dasd/work03.190




The files for the CBT tapes both source and execs are not listed.


Vince

['\'Fish\' (David B. Trout)' [e-mail] [hercules-390]]

Post by ***@gmail.com [hercules-390]
In that case 'Houston we have a problem'

<snip>


Who the heck are you talking to? Some CONTEXT would be nice! (*)


_________

(*) If replying via Yahoo's crappy web interface, you need to click on "show message history" at the bottom of the input area. That will insert the text of the person you are replying to. Without that, we can't know who the heck you are responding to, making it virtually impossible to follow the conversation.

If replying via email, you need to manually "quote" the text of the person you are replying to (prefix what they said with '>' greater than signs, which is typically done automatically by your email client).

[Gregg Levine [e-mail] [hercules-390]]

Hello!
Anybody Fish. Don;t get your tailfins in a not here. He's complaining
that his main fuel cells are running flat or even showing a definite
undervotlage. Besides, you're right as usual.
-----
Gregg C Levine ***@gmail.com
"This signature fought the Time Wars, time and again."


On Wed, Sep 5, 2018 at 10:34 PM, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]

Post by ***@gmail.com [hercules-390]
In that case 'Houston we have a problem'

<snip>
Who the heck are you talking to? Some CONTEXT would be nice! (*)
_________
(*) If replying via Yahoo's crappy web interface, you need to click on "show message history" at the bottom of the input area. That will insert the text of the person you are replying to. Without that, we can't know who the heck you are responding to, making it virtually impossible to follow the conversation.
If replying via email, you need to manually "quote" the text of the person you are replying to (prefix what they said with '>' greater than signs, which is typically done automatically by your email client).
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com
------------------------------------
------------------------------------

The following is being sponsored Lion Prides Sleep during the Day a
big cat club.

[pricgren [e-mail] [hercules-390]]

Is it something to do with working on non-compressed volumes.

Vince,

Are you saying that TK4- supplied uncompressed CKD DASD images?
That doesn't sound right.
The TK4- DASD files I have are *much* smaller than the real volumes were.
Check the sizes of your files - are they really hundreds of megabytes each?

(Windows says my uncompressed 3350 volumes (not from TK4-) are 319,201
KB each.)

Cheers,
Greg P.

[[e-mail] [hercules-390]]

I am totally confused.


They sit in directory dasd with filename ending in .nnn as against another version of the OS ending in .cckd


So I 'assumed' that they are not in cckd format being in mind that when I ran CCKDCDSK with -3 they report very minor error if at all but when run with -4 I get a long stream of issues, i.e., :


-- lots cut but similar to - ------

HHCCU301I mvscat.191: trk[2792] recovered offset 0xc6bc04 len 11088
HHCCU301I mvscat.191: trk[2793] recovered offset 0xc6e754 len 10847
HHCCU300I mvscat.191: 1594 trk images recovered
HHCCU500W mvscat.191: recovery not completed, file opened read-only
---


However when running the system I get errors (in log/3033.log) reported when hercules starts IPL such as (for mvscat.191) :


21:22:49 HHC00414I 0:0191 CKD file dasd/mvscat.191: cyls 1114 heads 15 tracks 16710 trklen 56832
21:22:49 HHC00363W 0:0191 CCKD file dasd/mvscat.191: cdevhdr inconsistencies found, code 0001
21:22:49 HHC00364W 0:0191 CCKD file dasd/mvscat.191: forcing check level 1
21:22:49 HHC00368W 0:0191 CCKD file dasd/mvscat.191: free space errors detected
21:22:49 HHC00377I 0:0191 CCKD file dasd/mvscat.191: free space rebuilt



Which implies that what ever the Hercules utility CCKDCDSK did Hercules still is not happy with the volume.


So possibly there is a problem with the utility program not reporting that the volume is not in the right format OR it is not fixing problems.


I should point out that after MVS is SHUTDOWN and Hercules terminated along with the terminal program (under Linux) then a fresh terminal program started with hercules run again (all using sudo) then the reported error/s re-appear.


So what ever Hercules is reporting is NOT fixed/rebuilt unless it is only in RAM etc.


Vince

[Kevin Monceaux [e-mail] [hercules-390]]

Post by pricgren ***@yahoo.com [hercules-390]
Check the sizes of your files - are they really hundreds of megabytes each?

No, the largest in the list he posted was:

53835543 cbt001.341

So about 52MB. That's similar to the size of my cbt001.341 volume, which
Linux's file command reports to be a:

Hercules compressed CKD DASD image file, 30 heads per cylinder, track
size 19456 bytes, device type 3350

[[e-mail] [hercules-390]]

Thanks. The TK4- source files do seem to be included in the distribution i downloaded in the directory hercules/source. as Hercules_for_TK4-_Update_08.tgz. It's just not obvious how to do the build.

My builds are done with the files from https://github.com/hercules-390/hyperion https://github.com/hercules-390/hyperion and the cmake instructions from a thread on this board: https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348 https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348
I get some error messages but nothing that stops the build. I'm only using the linux/arm version on a raspberry Pi but it seems solid.

[[e-mail] [hercules-390]]

Hi Bill


just to clarify:

The telegram style build instructions I provided earlier in this thread are exactly what you need to build from the source in Hercules_for_TK4-_Update_08.tgz.
The MVS 3.8j system that comes with TK4- will of course run under any other Hercules distribution too (namely Fish's SDL Hyperion, the mainline Hyperion, and Roger's production grade Hercules 3.x Spinhawk versions). However, none of these versions supports all features of the integrated TK4- Hercules and the TK4- MVS 3.8j system. In general, you'll miss parts or all of the automation, the SNA 3705 devices, and, most importantly, the TCP/IP support.

Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Thanks. The TK4- source files do seem to be included in the distribution i downloaded in the directory hercules/source. as Hercules_for_TK4-_Update_08.tgz. It's just not obvious how to do the build.

My builds are done with the files from https://github.com/hercules-390/hyperion https://github.com/hercules-390/hyperion and the cmake instructions from a thread on this board: https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348 https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348
I get some error messages but nothing that stops the build. I'm only using the linux/arm version on a raspberry Pi but it seems solid.

[[e-mail] [hercules-390]]

Thanks again. I have worked my way through the build sequence but the version i get seems to identify itself as the original 4.00 rather than "for TK4-". I'll go back and re-extract from the .tgz but for the moment I'm getting:

~/mvs4mod/hercules/source4mods/Hercules_for_TK4-_Update_08: ./hercules ?
HHC01413I Hercules version 4.00
HHC01414I (c) Copyright 1999-2012 by Roger Bowler, Jan Jaeger, and others
HHC01415I Built on Sep 5 2018 at 17:41:57
HHC01416I Build information:
HHC01417I Modes: S/370 ESA/390 z/Arch
HHC01417I Max CPU Engines: 8
HHC01417I Using setresuid() for setting privileges
HHC01417I Using POSIX threads Threading Model
HHC01417I Using Error-Checking Mutex Locking Model
HHC01417I With Dynamic loading support
HHC01417I Using shared libraries
HHC01417I With External GUI support
HHC01417I With IPV6 support
HHC01417I With HTTP Server support
HHC01417I With sqrtl support
HHC01417I With SIGABEND handler
HHC01417I Without CCKD BZIP2 support
HHC01417I Without HET BZIP2 support
HHC01417I With ZLIB support
HHC01417I With Regular Expressions support
HHC01417I Without Object REXX support
HHC01417I Without Regina REXX support
HHC01417I With Automatic Operator support
HHC01417I With National Language Support
HHC01417I Machine dependent assists: (none)
HHC01417I Running on raspberrypi Linux-4.14.52+. #1123 Wed Jun 27 17:05:32 BST 2018, armv6l UP




---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Bill


just to clarify:

The telegram style build instructions I provided earlier in this thread are exactly what you need to build from the source in Hercules_for_TK4-_Update_08.tgz.
The MVS 3.8j system that comes with TK4- will of course run under any other Hercules distribution too (namely Fish's SDL Hyperion, the mainline Hyperion, and Roger's production grade Hercules 3.x Spinhawk versions). However, none of these versions supports all features of the integrated TK4- Hercules and the TK4- MVS 3.8j system. In general, you'll miss parts or all of the automation, the SNA 3705 devices, and, most importantly, the TCP/IP support.

Cheers
JÃŒrgen

---In hercules-***@yahoogroups.com, <***@...> wrote :


Thanks. The TK4- source files do seem to be included in the distribution i downloaded in the directory hercules/source. as Hercules_for_TK4-_Update_08.tgz. It's just not obvious how to do the build.

My builds are done with the files from https://github.com/hercules-390/hyperion https://github.com/hercules-390/hyperion and the cmake instructions from a thread on this board: https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348 https://groups.yahoo.com/neo/groups/hercules-390/conversations/topics/82348
I get some error messages but nothing that stops the build. I'm only using the linux/arm version on a raspberry Pi but it seems solid.

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Post by ***@id.ethz.ch [hercules-390]
Hi Bill
The telegram style build instructions I provided earlier in this thread
are exactly what you need to build from the source in
Hercules_for_TK4-_Update_08.tgz. The MVS 3.8j system that comes with
TK4- will of course run under any other Hercules distribution too
(namely Fish's SDL Hyperion, the mainline Hyperion, and Roger's
production grade Hercules 3.x Spinhawk versions). However, none of these
versions supports all features of the integrated TK4- Hercules and the
TK4- MVS 3.8j system. In general, you'll miss parts or all of the
automation, the SNA 3705 devices, and, most importantly, the TCP/IP
support.

Quite easy to add dyn75 support to spinhawk and hyperion,
for MVS3.8j TCP/IP support. I've them up and running
with J.Winter FTPD on my personal SYSGEN.

Too bad it can't be fixed definitely on the respective git
for the Jason Winter restriction on the dyn75 sources.

Anyone may be able to contact J.Winter about this problem?

Peppe.

[Harold Grovesteen [e-mail] [hercules-390]]

dyn75 was written by Jason Paul Winter and may be obtained
from http://www.mountaindesigns.com/jcc/

It is distributed under the terms of the below BSD-like
licence, which allows it to be included in projects such
as Hercules and Hercules/380 (both under the QPL licence)
without taking away the rights of others to use it in
BSD-licenced projects, and obviously as copyright holder
I can still use it in my commercial projects (such as JCC).



Copyright (c) 2003-2010, Jason Paul Winter
All rights reserved.

Redistribution and use in source and binary forms, with 
or without modification, are permitted provided that 
the following conditions are met:

Redistributions of source code must retain the above 
copyright notice, this list of conditions and the 
following disclaimer.

Redistributions in binary form must reproduce the above 
copyright notice, this list of conditions and the following 
disclaimer in the documentation and/or other materials 
provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND 
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, 
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE 
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR 
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, 
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING 
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH 
DAMAGE.

Jason Winter was contacted on this issue.  This is the license under
which it can be included within either spinhawk or hyperion.  The
historical reasons for not including either dyn75 or dyn76 (which has
the same license) has nothing to do with licensing, but decisions of
past maintainers.

Harold Grovesteen

On Fri, 2018-09-07 at 11:32 +0200, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]
Quite easy to add dyn75 support to spinhawk and hyperion,
for MVS3.8j TCP/IP support. I've them up and running
with J.Winter FTPD on my personal SYSGEN.
Too bad it can't be fixed definitely on the respective git
for the Jason Winter restriction on the dyn75 sources.
Anyone may be able to contact J.Winter about this problem?
Peppe.
 

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Jason Winter was contacted on this issue.  This is the license under
which it can be included within either spinhawk or hyperion.  The
historical reasons for not including either dyn75 or dyn76 (which has
the same license) has nothing to do with licensing, but decisions of
past maintainers.
Harold Grovesteen

Nice.

If I got the picture, nothing prevent from including
dyn75 in the hercules source trees.

So ... what?

Peppe.

[Non-text portions of this message have been removed]

[Harold Grovesteen [e-mail] [hercules-390]]

So this was an answer to your suggestion that Jason Winter needs to be
contacted.  He does not.  He was contacted years ago with the result I
posted.  I have the original text files provided by Jason years ago for
each module.

What is needed is someone to integrate the two modules, dyn75 and
dyn76, into the respective repositories in a manner consistent with
Hercules approaches to such things probably a configuration option to
enable or disable them and probably some other decisions like which
architecture modes.  The license files would need to be included.

Some additional work has been done on dyn75 (and maybe dyn76) that
addressed some internal issues.  Not sure who did that.  But that is
probably what needs to be added to the repositories rather than the
original source.  I believe that is what is in the TK4- Hercules
version.

I am not inclined to resurrect the reasons why this was not done in the
past, but would suggest there would be limited if any resistance
starting with Hyperion.  That is where such new things were intended to
go.  New that is to Hercules.  Can not speak for spinhawk.  I certainly
support it in Hyperion.

Just need to find a committer willing to do the integration work.

Harold Grovesteen

On Fri, 2018-09-07 at 18:26 +0200, Giuseppe Vitillaro

Post by Giuseppe Vitillaro ***@vitillaro.org [hercules-390]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Jason Winter was contacted on this issue.  This is the license under
which it can be included within either spinhawk or hyperion.  The
historical reasons for not including either dyn75 or dyn76 (which has
the same license) has nothing to do with licensing, but decisions of
past maintainers.
Harold Grovesteen

Nice.
If I got the picture, nothing prevent from including
dyn75 in the hercules source trees.
So ... what?
Peppe.
[Non-text portions of this message have been removed]
------------------------------------
------------------------------------
  http://groups.yahoo.com/group/hercules-390
  http://www.hercules-390.org
------------------------------------
Yahoo Groups Links

[[e-mail] [hercules-390]]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
What is needed is someone to integrate the two modules, dyn75 and
dyn76, into the respective repositories in a manner consistent with
Hercules approaches to such things probably a configuration option to
enable or disable them and probably some other decisions like which
architecture modes. The license files would need to be included.

Well, Harold, as long as you (or the developers at large) want to have this stuff integrated using the DIAG instruction, I'll certainly not be the one who will do this integration. Although having dyn75 implemented as an instruction (X'75') isn't exactly "nice" too, for me this still is the best possible compromise for providing access to the host's TCP/IP stack to an OS running under Hercules.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Some additional work has been done on dyn75 (and maybe dyn76) that
addressed some internal issues. Not sure who did that. But that is
probably what needs to be added to the repositories rather than the
original source. I believe that is what is in the TK4- Hercules
version.

I did that for dyn75, but I never touched dyn76. From memory, the main issues were:
The original X'75' instruction was not 64-bit safe, i.e. it worked for 32-bit versions of Hercules only. I created a simple but good enough kludge doing some weird address mapping to get over this. Up to now (it's some 3-years since) I didn't hear of any problems, so, I think it's really good enough.
The X'75' instruction 64-bit support kludge was not MP safe, i.e. it caused arbitrary machine checks when used on dual CPU MVS 3.8j systems. I solved this by introducing a specific lock ("tcpip_lock") to serialize the critical part of the code (this patch is not in the current TK4 Update 08-, it will be in Update 09).
The original X'75' instruction didn't support the getpeername() and the gethostbyaddr() functions. I implemented those functions (this enhancement is not in the current TK4 Update 08-, it will be in Update 09).
It should be noted, that Jason's original software can be found on TK4- systems under TK4-.JASON, and my modifications are under TK4-.JUERGEN. So, not need to search for and evaluate old links.


It is one of the major aspects of the TK4- distribution, that it doesn't only provide a running system, but is on the other hand also an archive of the software packages used to build that system.


Cheers
JÃŒrgen

[Harold Grovesteen [e-mail] [hercules-390]]

The use of DIAGNOSE was the only way at the time the developers would
agree on the implementation of dyn75 (and dyn76) functionality.
 Functionality the community clearly wanted.  It was an ugly
compromise.  I did manage to implement dyn76 functionality under the
DIAGNOSE and commit it. I never felt this was the desirable approach.

The community wanted the instruction for multiple reasons.  In the past
the developers did not.

As things sit now, I would encourage the instruction be added to
Hyperion with a config option to enable it.  The same for dyn76.  Those
who most strongly objected are no longer participating so the past
objections are mute.

My personal philosophy was and is that the architecture is mutable and
should be made to meet the needs of those using Hercules.  Most of the
developers perceived it as static, immutable.  IBM never did.  Why
should we?

Harold

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
What is needed is someone to integrate the two modules, dyn75 and
dyn76, into the respective repositories in a manner consistent with
Hercules approaches to such things probably a configuration option

to

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
enable or disable them and probably some other decisions like which
architecture modes.  The license files would need to be included.

Well, Harold, as long as you (or the developers at large) want
to have this stuff integrated using the DIAG instruction, I'll
certainly not be the one who will do this integration. Although
having dyn75 implemented as an instruction (X'75') isn't exactly
"nice" too, for me this still is the best possible compromise for
providing access to the host's TCP/IP stack to an OS running under
Hercules.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Some additional work has been done on dyn75 (and maybe dyn76) that
addressed some internal issues.  Not sure who did that.  But that

is

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
probably what needs to be added to the repositories rather than the
original source.  I believe that is what is in the TK4- Hercules
version.

The original X'75' instruction was not 64-bit safe, i.e. it worked
for 32-bit versions of Hercules only. I created a simple but good
enough kludge doing some weird address mapping to get over this. Up
to now (it's some 3-years since) I didn't hear of any problems, so, I
think it's really good enough.
The X'75' instruction 64-bit support kludge was not MP safe, i.e. it
caused arbitrary machine checks when used on dual CPU MVS 3.8j
systems. I solved this by introducing a specific lock ("tcpip_lock")
to serialize the critical part of the code (this patch is not in the
current TK4 Update 08-, it will be in Update 09).
The original X'75' instruction didn't support the getpeername() and
the gethostbyaddr() functions. I implemented those functions
(this enhancement is not in the current TK4 Update 08-, it will be in
Update 09).
It should be noted, that Jason's original software can be found on
TK4- systems under TK4-.JASON, and my modifications are under TK4-
.JUERGEN. So, not need to search for and evaluate old links.
It is one of the major aspects of the TK4- distribution, that it
doesn't only provide a running system, but is on the other hand also
an archive of the software packages used to build that system.
Cheers
JÃŒrgen

[Giuseppe Vitillaro [e-mail] [hercules-390]]

Nice conclusion. Thanks for the interesting discussion.

I got the dyn75 patches from the TK4- setup, but from what Juergen wrote,
he had done more work on this integration.

If I got it correctly, more on the OS side, than in the
emulator side patches.

I didn't see any problem with dyn75 used from MVS3.8j running under
spinhawk-3.13, as a module which must be explicitely loaded with the
"ldmod" command, basically for running FTPD.

In this shape, as an optional loadable module, it should't be a problem
for any emulator user not willing to install a dyn75 enabled OS.

I just did few tests with hyperion and I can't even find
where I compiled the source by now ;-(

From what I've read it seems basically a question to find maintaners
willing to integrate dyn75 in the spinhawk and in the hyperion
source tree.

The OS support of the TCPIP instruction is another can
of worm, of course, I do not know in the full details.

Maybe Juergen may help to gain a better understanding about how the
emulator side patches and the OS are related, if they actually are.

Peppe.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
The use of DIAGNOSE was the only way at the time the developers would
agree on the implementation of dyn75 (and dyn76) functionality.
 Functionality the community clearly wanted.  It was an ugly
compromise.  I did manage to implement dyn76 functionality under the
DIAGNOSE and commit it. I never felt this was the desirable approach.
The community wanted the instruction for multiple reasons.  In the past
the developers did not.
As things sit now, I would encourage the instruction be added to
Hyperion with a config option to enable it.  The same for dyn76.  Those
who most strongly objected are no longer participating so the past
objections are mute.
My personal philosophy was and is that the architecture is mutable and
should be made to meet the needs of those using Hercules.  Most of the
developers perceived it as static, immutable.  IBM never did.  Why
should we?
Harold

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
What is needed is someone to integrate the two modules, dyn75 and
dyn76, into the respective repositories in a manner consistent with
Hercules approaches to such things probably a configuration option

to

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
enable or disable them and probably some other decisions like which
architecture modes.  The license files would need to be included.

Well, Harold, as long as you (or the developers at large) want
to have this stuff integrated using the DIAG instruction, I'll
certainly not be the one who will do this integration. Although
having dyn75 implemented as an instruction (X'75') isn't exactly
"nice" too, for me this still is the best possible compromise for
providing access to the host's TCP/IP stack to an OS running under
Hercules.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Some additional work has been done on dyn75 (and maybe dyn76) that
addressed some internal issues.  Not sure who did that.  But that

is

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
probably what needs to be added to the repositories rather than the
original source.  I believe that is what is in the TK4- Hercules
version.

The original X'75' instruction was not 64-bit safe, i.e. it worked
for 32-bit versions of Hercules only. I created a simple but good
enough kludge doing some weird address mapping to get over this. Up
to now (it's some 3-years since) I didn't hear of any problems, so, I
think it's really good enough.
The X'75' instruction 64-bit support kludge was not MP safe, i.e. it
caused arbitrary machine checks when used on dual CPU MVS 3.8j
systems. I solved this by introducing a specific lock ("tcpip_lock")
to serialize the critical part of the code (this patch is not in the
current TK4 Update 08-, it will be in Update 09).
The original X'75' instruction didn't support the getpeername() and
the gethostbyaddr() functions. I implemented those functions
(this enhancement is not in the current TK4 Update 08-, it will be in
Update 09).
It should be noted, that Jason's original software can be found on
TK4- systems under TK4-.JASON, and my modifications are under TK4-
.JUERGEN. So, not need to search for and evaluate old links.
It is one of the major aspects of the TK4- distribution, that it
doesn't only provide a running system, but is on the other hand also
an archive of the software packages used to build that system.
Cheers
Jürgen

[[e-mail] [hercules-390]]

Note that an alternative to both the instruction
and a diagnose is to intercept an SVC, e.g.
SVC 120, such that if registers are set a
particular way, it signifies not to pass it on to
the operating system to do a GETMAIN, but
instead to do a TCP/IP call.

That way it appears to the programmer that
the OS has just been enhanced, not the
hardware.

BFN. Paul.




---In hercules-***@yahoogroups.com, <***@...> wrote :

The use of DIAGNOSE was the only way at the time the developers would
agree on the implementation of dyn75 (and dyn76) functionality.
Functionality the community clearly wanted. It was an ugly
compromise. I did manage to implement dyn76 functionality under the
DIAGNOSE and commit it. I never felt this was the desirable approach.

The community wanted the instruction for multiple reasons. In the past
the developers did not.

As things sit now, I would encourage the instruction be added to
Hyperion with a config option to enable it. The same for dyn76. Those
who most strongly objected are no longer participating so the past
objections are mute.

My personal philosophy was and is that the architecture is mutable and
should be made to meet the needs of those using Hercules. Most of the
developers perceived it as static, immutable. IBM never did. Why
should we?

Harold

Post by ***@id.ethz.ch [hercules-390]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
What is needed is someone to integrate the two modules, dyn75 and
dyn76, into the respective repositories in a manner consistent with
Hercules approaches to such things probably a configuration option

to

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
enable or disable them and probably some other decisions like which
architecture modes. The license files would need to be included.

Well, Harold, as long as you (or the developers at large) want
to have this stuff integrated using the DIAG instruction, I'll
certainly not be the one who will do this integration. Although
having dyn75 implemented as an instruction (X'75') isn't exactly
"nice" too, for me this still is the best possible compromise for
providing access to the host's TCP/IP stack to an OS running under
Hercules.

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
Some additional work has been done on dyn75 (and maybe dyn76) that
addressed some internal issues. Not sure who did that. But that

is

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
probably what needs to be added to the repositories rather than the
original source. I believe that is what is in the TK4- Hercules
version.

The original X'75' instruction was not 64-bit safe, i.e. it worked
for 32-bit versions of Hercules only. I created a simple but good
enough kludge doing some weird address mapping to get over this. Up
to now (it's some 3-years since) I didn't hear of any problems, so, I
think it's really good enough.
The X'75' instruction 64-bit support kludge was not MP safe, i.e. it
caused arbitrary machine checks when used on dual CPU MVS 3.8j
systems. I solved this by introducing a specific lock ("tcpip_lock")
to serialize the critical part of the code (this patch is not in the
current TK4 Update 08-, it will be in Update 09).
The original X'75' instruction didn't support the getpeername() and
the gethostbyaddr() functions. I implemented those functions
(this enhancement is not in the current TK4 Update 08-, it will be in
Update 09).
It should be noted, that Jason's original software can be found on
TK4- systems under TK4-.JASON, and my modifications are under TK4-
.JUERGEN. So, not need to search for and evaluate old links.
It is one of the major aspects of the TK4- distribution, that it
doesn't only provide a running system, but is on the other hand also
an archive of the software packages used to build that system.
Cheers
JÃŒrgen

[[e-mail] [hercules-390]]

Are "TK4-.JASON / TK4-.JUERGEN" supposed to be directories ?

No, those are MVS HLQs. Start up TK4- and
then use RPF to look at datasets starting
with those values.

BFN. Paul.

[Mike Stramba [e-mail] [hercules-390]]

Post by ***@yahoo.com.au [hercules-390]

Are "TK4-.JASON / TK4-.JUERGEN" supposed to be directories ?

No, those are MVS HLQs. Start up TK4- and
then use RPF to look at datasets starting
with those values.

Ah! ... thx.

Mike

[[e-mail] [hercules-390]]

Hi Bill


when you found the source in the distribution you're nearly done: Besides the main source tree in "Hercules_for_TK4-_Update_08" you'll see there a folder named "Architecture_dependencies" in Hercules_for_TK4-_Update_08.tgz. The reason for the existence of this folder is that I was too lazy to implement any differences using preprocessor directives (#if and the like). I anyway expected this thing to be very static in the beginning (an error, as I know today) and thus I didn't expect maintainability to be an issue.


Anyway, what you need to do is: Look into the "Architecture_dependencies" folder for files prefixed with your system type and replace the respective file(s) in the main source tree with them. So, for example, 64-bit_tcpip.c replaces tcpip.c if you are doing any 64-bit build, except for OS X, in which case OSX_64-bit_tcpip.c must be used instead. The names of the files are self explaining and where more than one version exists, just use the one with the most restrictive name still matching your system. It's less than a handful of files you'll have to replace that way, mostly around the TCP/IP implementation.


Once done with updating the source tree to match your system run the usual ./autogen.sh ./configure, make, make install sequence (i.e. the pre-CMAKE style build procedure). Note that automake --add-missing may be required, depending on your system. Note also, that your mileage may vary on OS X. On Windows systems use makefile-dllmod.msvc directly with nmake, after having copied the required libraries (zlib, bzip2, pcre) from elsewhere (see README.WIN64, roughly).


Good luck!


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :

I've built the 4.0 version of hercules using the cmake detailed on this list process and made a simple instruction Hercules_for_TK4-_Update_08.tgzexecution mod in general2.c. I'd like to do the same mod in the hercules build used in TK4-.


I can see the source in the TK4- distribution but not the build instructions. I know the build is different from the "version" output and my build seems to lack some of the automation features in TK4-


How do I rebuild the TK4- version?

[[e-mail] [hercules-390]]

Thanks very much JÃŒrgen. I'll try it today.

Let me say again how impressed i am with the TK4- distribution package. How stable it's been over two years since release and how well it runs on multiple platforms. I realize it's "just" multiple copies of the binaries and a set of scripts but it's very useful and friendly.





---In hercules-***@yahoogroups.com, <***@...> wrote :

Hi Bill


when you found the source in the distribution you're nearly done: Besides the main source tree in "Hercules_for_TK4-_Update_08" you'll see there a folder named "Architecture_dependencies" in Hercules_for_TK4-_Update_08.tgz. The reason for the existence of this folder is that I was too lazy to implement any differences using preprocessor directives (#if and the like). I anyway expected this thing to be very static in the beginning (an error, as I know today) and thus I didn't expect maintainability to be an issue.


Anyway, what you need to do is: Look into the "Architecture_dependencies" folder for files prefixed with your system type and replace the respective file(s) in the main source tree with them. So, for example, 64-bit_tcpip.c replaces tcpip.c if you are doing any 64-bit build, except for OS X, in which case OSX_64-bit_tcpip.c must be used instead. The names of the files are self explaining and where more than one version exists, just use the one with the most restrictive name still matching your system. It's less than a handful of files you'll have to replace that way, mostly around the TCP/IP implementation.


Once done with updating the source tree to match your system run the usual ./autogen.sh ./configure, make, make install sequence (i.e. the pre-CMAKE style build procedure). Note that automake --add-missing may be required, depending on your system. Note also, that your mileage may vary on OS X. On Windows systems use makefile-dllmod.msvc directly with nmake, after having copied the required libraries (zlib, bzip2, pcre) from elsewhere (see README.WIN64, roughly).


Good luck!


Cheers
JÃŒrgen


---In hercules-***@yahoogroups.com, <***@...> wrote :

I've built the 4.0 version of hercules using the cmake detailed on this list process and made a simple instruction Hercules_for_TK4-_Update_08.tgzexecution mod in general2.c. I'd like to do the same mod in the hercules build used in TK4-.


I can see the source in the TK4- distribution but not the build instructions. I know the build is different from the "version" output and my build seems to lack some of the automation features in TK4-


How do I rebuild the TK4- version?

[Peter Coghlan [e-mail] [hercules-390]]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]
dyn75 was written by Jason Paul Winter and may be obtained
from http://www.mountaindesigns.com/jcc/

I have seen references to this url many times over several years
but each time I looked, I found no trace of dyn75 there.

I have since been referred to another location where the code
can be found but this does not appear to have been provided
by Jason Paul Winter so I am reluctant to post it here.

Regards,
Peter Coghlan.