forked from hercules-390/html
-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathhercrnot.html
1515 lines (1322 loc) · 68.3 KB
/
hercrnot.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.0//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><TITLE>
Hercules: Release Notes
</TITLE>
<LINK REL=STYLESHEET TYPE="text/css" HREF="hercules.css">
<link rel="shortcut icon" href="images/favicon.ico" />
<link rel="icon" href="images/favicon.ico" />
<style type="text/css">
dt {font-family: Arial; font-weight: bold; font-style: rounded;}
</style>
</HEAD><BODY BGCOLOR="#ffffcc" TEXT="#000000" LINK="#0000A0" VLINK="#008040" ALINK="#000000">
<h1>Hercules Release Notes and Known Issues</h1>
<a name=4.8></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.8">SDL Hyperion 4.8</a>
</h2>
<p>
<dl>
<dt>z/Architecture Vector Registers Support
<dd>
<p>
Full zVector Register support has now been coded and lightly tested and appears
to be functioning normally. Nevertheless, Vector Facility support is still considered
to be <i><u>experimental</u></i> given that this feature is brand new to Hercules
and has not been thoroughly tested.
</p>
<dt>Message-Security-Assist Extensions 5 and 7
<dd>
<p>
Message-Security-Assist Extensions 5 and 7 provide a cryptographically secure deterministic
random number generator (DRNG) and a true random number generator (TRNG) through the PRNO
instruction. On real hardware, entropy for the TRNG is obtained using sources external to
the CP. Data obtained from the TRNG is intended to be used to seed the DRNG. Both facilities
are now provided by Hercules.
<p>
However, the Hercules implementation is not based on the
algorithms described in "z/Architecture Principles of Operation" (SA22-7832-13) but on its
internal CSRNG implementation already being in use for Message-Security-Assist Extension 3.
This internal implementation relies on the host system's RNG capabilities. Most
modern host operating systems support cryptographically secure random number generation,
namely the BCrypt API as implemented on Windows and the /dev/(u)random implementations
on Linux and macOS.
</p>
<dt>Compressed CKD/FBA Dasd Hardener
<dd>
<p>
This release adds a <i>Dasd Hardener</i> function to the Compressed CKD (and FBA)
dasd support.
<p>
Prior to this release, under normal operation, not immediately committing dasd data
written by a guest OS to the emulation disk files for an unpredictable period time
might have been reasonable. On systems with large idle periods (<i>e.g.</i>, hobbyist
systems or "Shared DASD servers") however, such data might have remained uncommitted
for hours, or even days. Any interruption of the host system, or of the Hercules emulator
itself, could have resulted in loss of such uncommitted data. No mechanism existed in
those releases to ensure that all data the guest OS has written was permanently recorded
to the emulation files.
<p>
This release uses existing functions in the Compressed Dasd subsystem to build an
optional thread that periodically scans the dasd cache and flushes updated tracks to the
emulation files on a timely basis. See the <a href="cckddasd.html#cckdcommand">'cckd'
command documentation</a> for details on configuring and controlling the Dasd Hardener.
<p>
<b>NOTE:</b> Flushing the dasd data cache frequently may increase the host disk activity,
as frequently-updated tracks would be written more often in this scenario. For
largely-idle Hercules systems, this increase will likely have negligable effects. For
busy systems with activity scattered across a broad set of tracks, the data cache should
already be flushed often, albeit unpredictably. For busy systems with more-focused
activity, the high-activity tracks will be written to disk more often, which could
possibly have a measurable negative effect.
</p>
<dt>Support for 32-bit x86 Windows builds has been dropped
<dd>
<p>
Support for building 32-bit (x86) versions of Hercules for Windows has been dropped.
This is due to internal changes necessary for zVector registers support makes such
support impossible, as well as the fact that pre-built 32-bit Windows versions of
Hercules have not been offered to the community for several years now, and no one has
ever complained or asked for such support. The world has moved on to 64-bit.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.6></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.6">SDL Hyperion 4.6</a>
</h2>
<p>
<dl>
<dt>SECURITY: New "\" (backslash) SCP reply prefix to suppress echoing of reply text
<dd>
<p>
Previously, when running a guest that uses the HMC for communicating with the user,
the text for each reply was always logged to the HMC as-is:
<blockquote>
<pre>
08:35:19.528 Ubuntu 18.04.6 LTS s390x sclp_line0
08:35:19.638 s390x login:
08:56:15.453 HHC00160I SCP command: hercules
08:56:15.556 hercules
<b>08:56:15.776 Password:
08:56:17.357 HHC00160I SCP command: <i><u>hercules</u></i></b>
08:56:18.367 Last login: Sat Jan 28 11:31:16 EST 2023 on sclp_line0
08:56:48.327 Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-200-generic s390x)</pre>
</blockquote>
As this was deemed to be a security exposure when the reply contained sensitive
information such as a user's password, a new SCP command prefix was created to
prevent the echoing of the SCP reply. Beginning with this release of SDL Hercules
Hyperion, the SCP reply prefix '\' (backslash) should be used for replies that
you do not want to be written to the screen or logfile:
<blockquote>
<pre>
17:50:53.980 Ubuntu 18.04.6 LTS s390x sclp_line0
17:50:54.089 s390x login:
17:51:39.281 HHC00160I SCP command: hercules
17:51:39.389 hercules
<b>17:51:39.689 Password:
17:51:43.265 HHC00160I SCP command: <i>(<u>suppressed</u>)</i></b>
17:52:29.270 Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-200-generic s390x)</pre>
</blockquote>
As you can see, the reply is not echoed when the '\' (backslash) SCP reply prefix
is used instead. Rather, the reply text is instead replaced with the message text
"(suppressed)". This prevents the logging of sensitive information <i>(such as
passwords)</i> to the screen and logfile.
</p>
<dt>Better HMC message handling for Linux guests
<dd>
<p>
Previously, when running a s390x Linux guest, boot progress messages would appear
garbled (badly formatted) when logged to the HMC:
<blockquote><pre>
20:03:20.579 Welcome to 1mUbuntu 18.04.6 LTS 0m|
20:03:20.580
20:03:20.580 77.148546! systemd 1!: Set hostname to <s390x>.
20:03:22.494 HHC00004I Control program identification: type LINUX, name UBUNTU, sysplex 18 04 6, level 40F00
20:03:26.059 0;32m OK 0m! Reached target User and Group Name Lookups.
20:03:26.059 0;32m OK 0m! Created slice System Slice.
20:03:26.060 0;32m OK 0m! Listening on fsck to fsckd communication Socket.
20:03:26.060 0;32m OK 0m! Listening on Journal Socket.
20:03:26.060 0;32m OK 0m! Listening on Syslog Socket.
20:03:26.061 82.621379! random: systemd: uninitialized urandom read (16 bytes read)
20:03:26.061 82.621788! systemd 1!: Reached target User and Group Name Lookups.</pre>
</blockquote>
Beginning with this release of SDL Hercules Hyperion, efforts are made to more
properly parse the screen messages that Linux is issuing so that they can appear
on the HMC in a much more readable format:
<blockquote><pre>
15:17:37.374 Welcome to Ubuntu 18.04 LTS!
15:17:37.374
15:17:37.393 [ 74.041881] systemd: Set hostname to <Ubuntu180403>.
15:17:38.286 HHC00004I Control program identification: type LINUX, name UBUNTU, sysplex 18 04, level 40F00
15:17:40.303 [ 76.951718] random: crng init done
15:17:42.653 [ OK ] Started Forward Password Requests to Wall Directory Watch.
15:17:42.653 [ OK ] Created slice User and Session Slice.
15:17:42.654 [ OK ] Created slice System Slice.
15:17:42.654 [ OK ] Listening on fsck to fsckd communication Socket.
15:17:42.655 [ OK ] Listening on Journal Socket (/dev/log).
15:17:42.655 [ OK ] Listening on Journal Audit Socket.
15:17:42.655 [ OK ] Listening on LVM2 metadata daemon socket.
15:17:42.656 [ OK ] Created slice system-serial\x2dgetty.slice.
15:17:42.656 [ OK ] Listening on udev Kernel Socket.
15:17:42.656 [ OK ] Listening on Syslog Socket.
15:17:42.656 [ OK ] Reached target User and Group Name Lookups.</pre>
</blockquote>
<i><u>Please be aware</u></i> that in order for s390x Linux's messages to be
properly parsed by Hercules you should use a Hercules
<a href="hercconf.html#CODEPAGE"><code><b>CODEPAGE</b></code></a>
mapping that matches the same code page that your s390x Linux guest actually uses.
For <i>(most?)</i> s390x Linux guests this is usually code page "<b>819/500</b>".
<i>(Other code pages may also work, but probably not as well as 819/500.)</i>
</p>
<dt>NEW: "Trace to File" support
<dd>
<p>
Beginning with this release of SDL Hercules Hyperion, you can now have debug
tracing (e.g. instruction and/or CCW tracing) written to an external file
instead of it always being written to the HMC panel <i>(which is incredibly
inefficient)</i>. Tracing to an external trace file greatly decreases the
Hercules overhead involved with debug tracing, thus allowing your guest to run
<i>significantly</i> faster than otherwise when debug tracing is active.
</p>
<p>
Additionally, a much finer grained selection of information can be printed
from the resulting trace file by means of the new 'tfprint' utility. Please
refer to the 'tfprint' utility's help display for information regarding the
many options available for choosing what trace information you wish to print.
Enter "help tf" for more information regarding the "Trace to File" command
itself.
</p>
<dt>NEW: Sockdev socket punch support
<dd>
<p>
SDL Hercules Hyperion now supports socket punch devices in a manner identical to
its current support for socket printer devices, thereby allowing remote spooling
of card punch data. Simply specify the 'sockdev' option for your
<a href="hercconf.html#cardpch">Card punch</a> device in exactly the same manner
as you would for a socket printer device.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.4.1></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.4.1">SDL Hyperion 4.4.1</a>
</h2>
<p>
<dl>
<dt>CCKD compressed dasd Locate Record bug found and fixed
<dd>
<p>
A potentially serious long standing bug in Hercules's compressed CKD (i.e. CCKD/CFBA/CCKD64/CFBA64)
dasd emulation logic was recently discovered and quickly fixed. Due to the natue of the bug,
Locate Record channel commands (opcodes X'47' or X'E7') would incorrectly prematurely fail in
an unusual way causing unexpected guest behavior <i>(e.g. the guest might end up looping or hanging
waiting for the I/O to complete for example. See e.g. GitHub Issue
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/464">#464</a>).</i>
</p>
<p>
Please note however that due to the nature of this bug, damage to your emulated dasd images
<i><b><u>could never occur</u></b></i>. The bug would only cause the guest's I/O to unexpectedly
fail or never finish at all. The integrity of the actual Hercules emulated dasd image file would
remain intact. Also note that this bug existed <i>only</i> in the "CCKD" compressed dasd image
handling logic, and <i>not</i> in the regular non-compressed "CKD" dasd handling logic. Regular
uncompressed CKD dasd images were unaffected by this bug and Locate Record would behave correctly.
</p>
<dt>Real address also shown during instruction tracing
<dd>
<p>
During instruction stepping/tracing ('<code>t+</code>' or '<code>s+</code>' Hercules commands),
when the address of the instruction's operand is a virtual address, the corresponding translated
real address is now also shown when possible
(e.g: <code>HHC02326I CP00: V:20012CD8:R:7FFF3CD8:K:06=00000000 00000000 ........</code>)
</p>
<dt>Change in format of reported version
<dd>
<p>
Hercules now reports its version using the format "V.M.R.nnnnn-SDL-ghhhhhhhh"
where V.M.R is the major Version, Modification and Revision level (e.g. 4.4.1),
nnnnn is an ever increasing internal build number (to ensure strictly sequentally
ascending version strings), and hhhhhhhh is the first eight characters of the hash
of the most recent commit made to the git source code repository <i>(which identifies
<u>exactly</u> which fixes/changes are present in your build and which are not,
which is vitally important for bug reporting and problem analysis purposes).</i>
</p>
<p>
For between release development builds the format is "V.M.R.nnnnn-SDL-DEV-ghhhhhhhh"
which is identical to the new format but with the extra "DEV-" string to indicate
the build is not an official release build but rather is a privately/manually built
intermediate development build.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.4></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.4">SDL Hyperion 4.4</a>
</h2>
<p>
<dl>
<dt>New <code>-o</code>, <code>--output</code> and <code>--logfile</code> command-line options
<dd>
<p>
New command-line options are now available to make the creation of a log file much easier
and less error prone, which is important for bug reporting and problem analysis purposes.
Refer to the
"<a href="hercinst.html#arguments"><b>Command line arguments</b></a>"
section of the
"<a href="hercinst.html">Installation and Operation</a>"
web page for more information.
</p>
<dt>Unreliable operation may occur in certain circumstances when Hercules is built with some versions of the GCC compiler
<dd>
<p>
During development of Hercules Version 4.4 it was noticed Hercules would sometimes
experience unreliable operation under certain conditions when built with certain
versions of the gcc compiler. The unreliability <i><u>seems</u></i> to most typically
occur <i>(but may not be limited to)</i> when a z/Architecture or ESA/390 guest is IPLed
under a z/Architecture or ESA/390 VM (i.e. z/VM or VM/ESA). We believe the problem
has since been resolved, but are not 100% certain about that.
</p>
<p>
<i>Therefore,</i> if you plan to run an SIE operating system (e.g. VM/ESA or z/VM) as
your primary guest under Hercules, we recommend, purely as a precaution, that you build
Hercules using the <b>clang</b> compiler and <i>not</i> gcc.
</p>
<p>
Please refer to
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/437">GitHub Issue #437</a>
for the latest status regarding this particular issue.
</p>
<dt>Improvements to building Hercules on non-Windows platforms
<dd>
<p>
Significant efforts have been made to make building Hercules on non-Windows systems
(e.g. Linux) easier and more reliable. Please refer to the README for Bill Lewis's
highly recommended "<b><a href="https://github.com/wrljet/hercules-helper">Hercules-Helper</a></b>"
repository for more information.
</p>
<dt>Unresolved bug in PFPO instruction
<dd>
<p>
The PFPO (Perform Floating Point Operation) instruction contains a (minor?)
unresolved bug in its handling of the EXTENDED DFP TO LONG HFP operation
that <i><u>seems</u></i> to only occur when the value being converted has more
than 31 digits in its fractional component. Refer to
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/407#issuecomment-892830186">GitHub Issue #407</a>
for more information.
</p>
<p>
This bug is currently the only one known to exist in the PFPO instruction, but given
that a comprehensive test suite still does not exist yet for the PFPO instruction
(such a test suite is still in development), other undiscovered bugs may also exist.
Until such time as a thorough PFPO test suite can be completed, the PFPO instruction
should be considered experimental.
</p>
<dt>TXF (Transactional-Execution Facility) support is now mostly complete
<dd>
<p>
While <u>still considered experimental</u> <i>(since it is not yet 100% complete)</i>,
the Hercules implementation of the z/Architecture "Transactional-Execution Facility" feature
is largely complete and considered to be reliable. There are still a few items that
have not been implemented yet (such as tracing (i.e. PER) support), but on the whole,
extensive testing has demonstrated it to be reliable enough for most everyday purposes.
</p>
<p>
Also note that while it is still considered experimental and incomplete, any
"<code>FACILITY ENABLE 073_TRANSACT_EXEC</code>" and/or
"<code>FACILITY ENABLE 050_CONSTR_TRANSACT</code>" configuration file statements
that you may currently have in your Hercules configuration file, are now no longer
needed. Beginning with Hercules version 4.4, both facilities are now enabled by default.
</p>
<dt>Preliminary SNA support
<dd>
<p>
Significant enhancements have been made to LCS device functionality to support
the SNA protocol. Preliminary documentation regarding its configuration and use
can be found in our
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.SNA.md">README.SNA</a>
readme document.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.3></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.3">SDL Hyperion 4.3</a>
</h2>
<p>
<dl>
<dt>Improved CTCE driver functionality.
<dd>
<p>
The CTCE device driver has been enhanced and improved, including changes to
the syntax of the device statement parameters, Please refer to the
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.NETWORKING.md">Hercules
Networking README</a> as well as to the actual
<a href="https://sdl-hercules-390.github.io/html/hercconf.html#CTCE">Hercules
Configuration File</a> web page itself for more information.
</p>
<dt>New "MSGCOLOR=DARK/LIGHT" panel option
<dd>
<p>
A new <code>MSGCOLOR</code> option has been added to the existing
<a href="https://sdl-hercules-390.github.io/html/hercconf.html#PANOPT"><code>PANOPT</code></a>
configuration file statement
that will colorize non-informational Error, Warning and Debug panel messages to make them more
noticable to the user (less likely to be missed). Users are <i>strongly encouraged</i> to enable
this new option in their configuration files.
</p>
<dt>Watchdog monitoring has been reinstated.
<dd>
<p>
Previously, Hercules had an internal "watchdog" monitoring thread that would
monitor all running CPUs to make sure they were functioning properly, and if
any of them were determined to be malfunctioning, a Machine Check Interruption
for the malfunctioning CPU would be presented to the guest in a vain attempt
to allow it to continue running. This functionality was removed in version
<a href="#4.2">4.2</a> however, due to it masking/hiding otherwise serious
bugs in the Hercules emulator.
</p><p>
Version 4.3 now re-introduces watchdog monitoring for malfunctioning (hung)
CPUs and other serious internal emulator errors (such as deadlock detection),
but does not otherwise notify the guest of the problem (i.e. no Machine Check
Interruption is presented), nor is any attempt made to allow the emulator to
continue. Instead, the problem is reported to the Hercules user via fatal
emulator error messages HHC00822S and/or HHC90024S, and the emulator is then
immediately terminated with a crash dump to be forwarded to the Hercules
development team for analysis.
</p><p>
For more information regarding crash dumps ("core files" on Linux), such as
how to enable their creation and how to analyze them when they occur, please
refer to GitHub Issue #199: <i>
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/199">"How to
analyze a Linux "core" file (i.e. crash dump)"</a></i>.
</p>
<dt>EXPERIMENTAL Transactional-Execution Facility (TXF) support
<dd>
<p>
This release of SDL Hyperion includes preliminary <i><u>experimental</u></i>
support for the z/Architecture "Transactional-Execution Facility" (bits 73
and 50).
</p><p>
This support is known to be incomplete and not 100% functional yet (it still
has some problems, especially under SIE), so it is still considered to be
<i><u>highly experimental</u></i> at this stage. It seems to work well enough
to allow certain guest operating systems requiring it (such
as z/OS 2.4 for example) to successfully IPL and run though.
</p><p>
Because it is still considered to be experimental and under active development
however, it is not enabled by default. Therefore users wishing to take advantage
of it must first manually enable it in their Hercules configuration file via the
following two <a href="https://sdl-hercules-390.github.io/html/hercconf.html#FACILITY"><code>FACILITY</code></a>
configuration file statements:
</p><p><pre>
FACILITY ENABLE 073_TRANSACT_EXEC
FACILITY ENABLE 050_CONSTR_TRANSACT</pre>
</p><p>
Only when the feature has been fully completed and thoroughly tested however,
will it then be enabled by default. For the time being however, since it is
still under active development and considered to be experimental, it must be
manually enabled as described above.
</p><p>
If you decide to use it, Bug Reports would be <i>greatly appreciated</i>
by creating a NEW <a href="https://github.com/SDL-Hercules-390/hyperion/issues">GitHub Issue</a>
describing the problem along with all supporting documentation. Thank you!
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.2.1></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.2.1">SDL Hyperion 4.2.1</a>
</h2>
<p>
<dl>
<dt>CKD serial number support
<dd>
<p>
Version 4.2.1 of SDL Hercules Hyperion introduces support for assigning
serial numbers to CKD dasd devices. This is usually only a concern for
guests which care about the serial number field in the device's Node Element
Descriptor (NED) information returned by the RCD (Read Configuration Data)
CCW, such as z/VM SSI (Single System Image) configurations. For most
other guests the change is transparent.
</p><p>
The <code>dasdinit</code> utility now assigns a randomly generated serial
number for all CKD dasd images. For existing CKD dasds created with earlier
(older) versions of Hercules without serial number support, the CKD dasd's
serial number will always be zero.
</p><p>
However, if an all zero serial number is detected during Hercules's CKD
device initialization (indicating the dasd does not have a permanent serial
number), a random serial number value is generated and used instead.
Because of this, all older dasd images (created with an older version of
Hercules and thus always having an all zero serial number) will always appear
to have a completely different (unstable ever changing) serial number
each time Hercules is started.
</p><p>
To assign a permanent (stable never changing) serial number to a CKD dasd
image (including those created with older versions of Hercules) a new
dasd utility has been created called <b><code>dasdser</code></b>. Start
<code>dasdser</code> without any arguments for usage information.
</p><p>
The serial number that Hercules actually uses for a given CKD dasd
(whether internally generated or obtained from the actual dasd image file)
can also be overridden via a new
<a href="hercconf.html#ckdser"><code>ser=nnnnnnnnnnnn</code></a>
device configuration file statement option. This new option is supported
only for CKD dasd devices and not FBA dasd devices since FBA devices
don't support the RCD (Read Configuration Data) CCW opcode and thus do not
have any serial number.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<a name=4.2></a>
<hr noshade>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.2">SDL Hyperion 4.2</a></h2>
<p>
<dl>
<a name=CCKD64></a>
<dt>CCKD64 Support
<dd>
<p>
Version 4.2 of SDL Hercules Hyperion introduces support for very large
Compressed CKD (CCKD) dasd image files, called <b>CCKD64</b>, which can
be much larger than 4GB in size. More information about <b>CCKD64</b>
can be found in the
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.CCKD64.md">README.CCKD64</a>
document in the source code distribution. Detailed CCKD64 <i>file format</i>
information can be found on the
"<a href="cckddasd.html">Compressed Dasd Emulation</a>"
web page.
</p>
<dt>SIGABEND Machine Check handler on Linux builds replaced with Crash handler
<dd>
<p>
The original designed "SIGABEND" handler on Linux builds that intercepted Hercules
abends (e.g. SIGSEGV, i.e. Hercules crashes, etc) and presented a Machine Check
Interruption to the guest in an attempt to allow Hercules and the guest to continue
running (in the hope that the guest would be able to either recover from the Machine
Check or be able to gracefully shutdown) has been removed since it served no valid
purpose other than to hide/mask otherwise very serious bugs in the Hercules emulator
making it nearly impossible to find or fix them.
</p><p>
Now, if Hercules crashes (due to a SIGSEGV, etc), the guest is no longer notified
of the event (a Machine Check Interruption does not occur) and Hercules makes no
attempt to recover or otherwise continue. Instead, it attempts to issue a message
to the Hercules user informing them of the crash and then requests that the host
perform default handling of the event (which is usually to create a "core" dump file
which can then be analyzed by gdb or by some other means to determine the cause of
the crash).
</p><p>
For more information regarding Linux core files, such as how to enable their creation
and how to analyze them when they occur, please refer to the following GitHub Issue:
<i>"<a href="https://github.com/SDL-Hercules-390/hyperion/issues/199">How to analyze
a Linux "core" file (i.e. crash dump)</a>"</i> (#199).
</p>
<dt>Integrated Regina REXX support no longer provided by default
<dd>
<p>
For those who want integrated Regina rexx support in Hercules, you will
now have to explicitly request such support on your <code>./configure</code>
command by specifying the <code>'--enable-regina-rexx'</code> option. For
everyone else, integrated support for Regina rexx will <i>no longer</i> be
automatically provided by Hercules, even if it is installed in their system.
</p><p>
In other words, you can still have Regina rexx installed on your system
and use it as you normally would, but simply having it installed on your
system will now <i>no longer</i> cause Hercules to also provide integrated
support for it.
</p><p>
For more information refer to the
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.REXX.md">README.REXX</a>
document in the source code distribution.
</p>
<dt>PFPO (Perform Floating Point Operation) instruction
<dd>
<p>
Thanks to hard work of one of our developers, Hercules now has a <i>complete</i>
implementation of the PFPO (Perform Floating Point Operation) instruction.
<i>(previously we had no implementation at all!)</i>
</p><p>
Efforts are currently under way to develop a formal runtest PFPO instruction
verification test for the current implementation to prove that it fully complies
with the published architecture, but the effort has not been completed yet.
Nevertheless, the current implementation is <i>believed</i> to fully comply
with the Principles of Operation even though we can't yet prove that.
</p>
<dt>Enhanced VMFPLC2 VM/CMS tape utility
<dd>
<p>
The VMFPLC2 tape utility has been greatly enhanced and now supports the scan
and load functions, making it much easier to transfer files between the host
system and z/VM or VM/370 systems. Refer to the
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.VMFPLC2.md">README.VMFPLC2</a>
document for usage details.
</p>
<dt>System/370/390 Vector Facility has been re-disabled
<dd>
<p>
It was a mistake to enable the System/370 and System/390 Vector Facility
set of instructions in release 4.1. Hercules's implementation of the
facility only implements 26 of the required 180 instructions the facility
provides and thus is so incredibly incomplete as to be virtually unusable.
</p><p>
Given that virtually no one has ever complained about its unavailability
beforehand (and the interference it causes internally with the desired
proper functioning of the Hercules S/370 Extension pseudo-facility), it has
once again been disabled.
</p><p>
This is very likely to be a permanent setting given the extreme unlikelihood
of the facility ever being fully coded due to its unpopularity and the extreme
challenges posed by trying to code all of the missing instructions for a fully
compliant facility.
</p>
<dt>TCPIP (X'75') instruction integrated
<dd>
<p>
This instruction was developed by Jason Winter to allow the guest OS access
to the IP stack of the host OS. It is of particular importance to older
operating systems that do not support their own IP stack. It provides full
IPv4 networking capabilities to those systems.
</p><p>
Note that the TCPIP instruction doesn't fully comply with IBM's S/3x0, ESA/390
or z/Architecture specifications. For this reason it is not enabled by default.
File
<a href="https://github.com/SDL-Hercules-390/hyperion/blob/master/readme/README.TCPIP.md">README.TCPIP</a>
provides the information needed to enable the instruction.
</p>
<dt>Optional ASID parameter added to breakpoint/stepping commands
<dd>
<p>
The <code>b</code> (breakpoint) and <code>s</code> (stepping) commands
now support an optional <b><code>asid</code></b> (<b>A</b>ddress <b>S</b>pace
<b>ID</b>entifier) parameter. If specified, the breakpoint or stepping
will only occur if the instructions being executed are <i>both</i> within
the specified address range <i><u>and</u></i> are being executed by the
specified address space. If specified, the breakpoint or stepping will
<i>not</i> occur for any other address spaces even if the instructions are
within the specified address range. If the optional ASID is not specified,
breakpoints or steppings occurs normally as before (i.e. if the instruction
being executed is within the specified range).
</p><p>
For more information refer to the <code>help</code> command display
for the <code>b</code> and/or <code>s</code> commands (i.e. "help b", "help s", etc).
</p>
<dt>New PANOPT configuration file statement and command
<dd>
<p>
Release 4.2 introduces a new configuration file option called
<a href="hercconf.html#PANOPT"><code>PANOPT</code></a>
that controls how emulated device files are displayed on the screen. The
<code>NAMEONLY</code> option will display only the emulated device file's
base filename, whereas <code>FULLPATH</code> displays the device file's
full path like before.
</p>
<dt>New Diagnose F09 instruction
<dd>
<p>
Release 4.2 introduces a new Diagnose F09 instruction that is essentially
an enhanced version of the existing Diagnose F08 instruction providing
access to Hercules's internal instruction counter. For detailed usage
information please refer to the
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/211#issuecomment-497233616">
final comment</a> in GitHub Issue #211:
<a href="https://github.com/SDL-Hercules-390/hyperion/issues/211">
"Diagnose F08 Improvement"</a>.
</p>
</dl>
<!-- --------------------------------------------------------------------------------- -->
<hr>
<a name=4.1></a>
<h2>Release notes for <a href="https://github.com/SDL-Hercules-390/hyperion/releases/tag/Release_4.1">SDL Hyperion 4.1</a></h2>
<p>
<dl>
<dt>External Packages
<dd>
<p>
Select source code and associated functionality has been moved out of
the Hercules repository and into separately maintained External Package
repositories. Refer to the
<a href="https://github.com/sdl-hercules-390/hyperion/blob/master/readme/README.EXTPKG.md">README.EXTPKG</a>
document for more information.
</p>
<dt>Minimum supported Windows platform is now Windows Vista
<dd>
<p>
The new minimum supported Windows platform is now Windows Vista. All
Hercules users still running older versions of Windows should upgrade
to at least Windows Vista or greater, with Windows 7 being preferred.
</p>
<dt>The ability to define process and thread priorities has been removed
<dd>
<p>
Previously, Hercules supported various commands/statements that allowed the
tweaking of Hercules's various internal thread priorities (HERCPRIO, CPUPRIO,
TODPRIO, etc). This ability has been removed. Such statements in your
configuration file will now cause a "deprecated and ignored" warning message
instead. You should remove all such statements from your configuration file.
</p>
<dt>ARCHLVL and FACILITY command changes
<dd>
<p>
The <code><a href="hercconf.html#FACILITY">FACILITY</a></code> command was completely
redesigned and rewritten in order to more properly support and enforce the concept
of prerequisite facilities (i.e. a facility presuming/requiring some other facility).
As part of this rewrite the ARCHLVL command functionality to enable/disable/query
facilities was moved into a new separate FACILITY command such that the ARCHLVL command
now only deals with setting/querying the architecture mode. To enable/disable/query
facilities, use the new FACILITY command.
</p><p>
Additionally, the facility names used in the <code>FACILITY </code> command to
enable, disable or query a facility have also been changed. All defined facilities
now begin with a 3-digit facility bit number in addition to their abbreviated
facility name. This was done to ensure the correct facility was being enabled or
disabled due to the similarity of some facility names. For example, the previously
named "ASN_LX_REUSE" facility is now named "006_ASN_LX_REUSE". Similarly, the
previously named "PFPO" facility is now named "044_PFPO".
</p><p>
For a detailed list of the new abbreviated (short) facility names,
use the "<code>FACILITY QUERY ...</code>" command.
</p>
<dt>"ASN and LX Reuse" now defaults to enabled for z/Architecture
<dd>
<p>
The "ASN and LX Reuse" facility (STFL bit 6) is now enabled by default
for the z/Architecture mode, as it should have been all along. It is
still disabled by default for the ESA/390 architecture mode however.
</p><p>
In earlier versions of Hercules it defaulted to disabled requiring those
running z/Architecture guest operating systems to have to manually add
an <code>FACILITY ENABLE 006_ASN_LX_REUSE</code> statement to their
configuration file. Such statements are now no longer necessary.
</p>
<dt>MAXCPU and NUMCPU statements
<dd>
<p>
The combination of <a href="hercconf.html#NUMCPU">NUMCPU</a> and
<a href="hercconf.html#MAXCPU">MAXCPU</a> controls the behavior of how many
CPU engines will be configured online upon startup and how many can be
configured online later. In previous versions this was controlled via
the NUMCPU statement and the compile-time constant 'MAX_CPU_ENGS'.
</p><p>
For compatibility with previous versions of Hercules, if MAXCPU is
not specified its value defaults to NUMCPU. If neither is specified
it defaults to 1.
</p>
<dt>HTTPROOT and HTTPPORT statements are now fully deprecated
<dd>
<p>
Any <code>httproot</code> or <code>httpport</code> statements are now
rejected as invalid statements. All users still using either statement
format in their configuration files must now replace all occurrences
with <code>http root ...</code> and <code>http port ...</code> instead.
</p>
<dt>New and improved CMPSC Compression Call 2012 instruction implementation is now the default
<dd>
<p>
The default implementation for the CMPSC Compression Call instruction
is now the new cmpsc_2012 implementation. The previous legacy implementation
no longer exists. Refer to the
<a href="https://github.com/sdl-hercules-390/hyperion/blob/master/readme/README.CMPSC.md">README.CMPSC</a>
document of the source code distribution for more information.
</p>
<dt>The sequence of certain configuration file statements is important
<dd>
<p>
The <code><a href="hercconf.html#ARCHLVL">ARCHLVL</a></code>
statement (previously called <code>ARCHMODE</code> for example, defines
the initial architectural mode of the system) should generally <i>precede</i>
(come before) any <code>FACILITY</code> statements that enable or disable
a given architectural feature.
</p><p>
For example: on certain IBM operating systems the z/Architecture "PFPO
Facility" must be enabled or the system will not IPL. While at the time
of this writing Hercules does not currently support the Perform Floating-Point
Operation (PFPO) Facility, the STFLE facility bit can nonetheless be
forcibly enabled anyway via the
<code><a href="hercconf.html#FACILITY">FACILITY ENABLE BIT44</a></code>
configuration file statement. Since the facility is a z/Architecture-only
feature however, your initial architecture must either be set to "z/Arch"
beforehand, or else you need to specify the optional
<code><em>[archlvl]</em></code> parameter on your FACILITY ENABLE BIT44 statement.
This usually means your "<code>ARCHLVL z/Arch</code>" statement must come
<i>before</i> your "<code>FACILITY ENABLE BIT44</code>" statement in your
configuration file. Otherwise the PFPO Facility would not get enabled.
</p><p>
With the introduction of limited automatic LPAR-mode/BASIC-mode switching
(see next item below), <code><a href="hercconf.html#LPARNUM">LPARNUM</a></code>
statements should follow <code><a href="hercconf.html#ARCHLVL">ARCHLVL</a></code>
statements if LPAR mode is truly desired for <code>ARCHLVL S/370</code>
(which is usually not the case).
</p><p>
The <code>ARCHLVL</code> and <code>LPARNUM</code> statements are currently
the only known configuration file statements whose sequence matters. The
order of all other configuration file statements should not currently matter.
This may change in the future however, so be sure to always carefully read
through the RELEASE NOTES (this document) with each new update to Hercules.
</p>
<dt>Limited automatic LPARNUM updating when setting certain architecture modes
<dd>
<p>
When <code><a href="hercconf.html#ARCHLVL">ARCHLVL S/370</a></code> is set,
<code><a href="hercconf.html#LPARNUM">LPARNUM</a></code> is now automatically
changed to <code>BASIC</code> (which also changes
<a href="hercconf.html#CPUIDFMT">CPUIDFMT</a> to <code>BASIC</code> as well),
and when <code>ARCHLVL z/Arch</code> is set, it is then changed back to the
default <code>LPARNUM 1</code> again (which also automatically changes the
<code>CPUIDFMT</code> back to <code>0</code> as well), but only when needed.
</p><p>
That is to say, the automatic switching to and from <code>LPARNUM BASIC</code>
(and <code>CPUIDFMT BASIC</code>) and <code>LPARNUM 1</code>
(and <code>CPUIDFMT 0</code>) only occurs when needed (and only when switching
between S/370 and z/Arch). If <code>LPARNUM</code> (and
<code>CPUIDFMT</code>) are already set to the expected values they will not
be changed. When <code>ARCHLVL ESA/390</code> is set however, <code>LPARNUM</code>
and <code>CPUIDFMT</code> are never changed from their current values.
</p><p>
This new behavior was introduced to eliminate the "surprise" factor that would
otherwise occur when, if the <code>LPARNUM</code> remained set to <code>1</code>
(or some other number), not doing so causes the STIDP (Store CPU ID) instruction
to be stored in an otherwise unexpected format. In most all situations when
a Hercules user sets <code>ARCHLVL S/370</code>, they are truly expecting the
<code>LPARNUM</code> and <code>CPUIDFMT</code> to be set to <code>BASIC</code>
such that the STIDP instruction then stores the CPU ID in the expected format.
</p><p>
For the unusual case where users actually <i>do</i> want to run a System/370
Operating System within an LPAR, you will need to manually re-set your
<code>LPARNUM</code> and <code>CPUIDFMT</code> values back to their numeric
values <i><u>after</u></i> setting <code>ARCHLVL S/370</code>. That is to say,
one should always follow their <code>ARCHLVL S/370</code> statement with a
<code>LPARNUM n|nn</code> statement (and <code>CPUIDFMT</code> statement
too if needed) if LPAR mode for S/370 is truly desired.
</p>
<dt>More architecturally compliant Channel Subsystem implementation
<dd>
<p>
Hercules 4.x Hyperion's channel subsystem implementation now more closely
adheres to published and unpublished architectural specifications. It does
not precisely adhere to the complete specification but it does adhere much
more closely than ever before (and definitely more closely than the legacy
implementation still used in the older spinhawk 3.xx series of Hercules).
</p><p>
If you experience any anomalies in the behavior of your guest operating
system, verify that you are using architecurally valid/correct configuration
settings that your guest operating system expects.
</p><p>
Pay <i><u>particular</u></i> attention to your
<a href="hercconf.html#ARCHLVL">ARCHLVL</a>,
<a href="hercconf.html#LPARNUM">LPARNUM</a>,
<a href="hercconf.html#CPUIDFMT">CPUIDFMT</a>,
<a href="hercconf.html#CPUMODEL">CPUMODEL</a>,
<a href="hercconf.html#CPUSERIAL">CPUSERIAL</a>,
<a href="hercconf.html#CPUVERID">CPUVERID</a>,
<a href="hercconf.html#MODEL">MODEL</a>,
<a href="hercconf.html#PLANT">PLANT</a>
and
<a href="hercconf.html#MANUFACTURER">MANUFACTURER</a>
values since they typically have a direct impact on how
certain guest operating systems behave.
</p>
<dt>Configuration file statements and panel commands handled identically
<dd>
<p>
Most configuration file statements are now available as and processed as
panel commands. Most valid configuration file statements may now also be
entered as a panel command. Most panel commands are now also allowed as
configuration file statements. See the documentation for full details.
</p>
<dt>Improved ECPSVM Support
<dd>
<p>
Hyperion 4.x now provides a mostly complete ECPSVM CP/VM Assist
implementation. While still not 100% complete, support for many new
assists has been added and several bugs have been fixed. Refer to the
<a href="https://github.com/sdl-hercules-390/hyperion/blob/master/readme/README.ECPSVM.md">README.ECPSVM</a>
document for more detailed information.
</p>
<dt>Integrated Rexx support
<dd>
<p>
Rexx support was first added to Hercules by Jan Jaeger in 2010
and has been gradually enhanced over the years by both Enrico Sorichetti
and Jan Jaeger as well as a few other people too.
</p><p>
If you have <a href="http://www.rexxla.org">Rexx</a> installed on your
host and Hercules is built with the Rexx build option (the default for
the SDL version of Hyperion), then Rexx scripts
can be run directly from within the Hercules environment (i.e. directly
from the Hercules HMC command line via the Hercules <code>exec</code> command).
</p><p>
Rexx scripts, when run within Hercules via the 'exec' command, can
Address the HERCULES enviroment allowing you to issue Hercules commands
and retrieve the results via the builtin 'AWSCMD' Rexx function call.
</p><p>
For more information please refer to the new
<a href="rexx.html">Hercules Integrated Rexx Support</a> web page.
</p>