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
|
Version 3.02 RELEASE NOTES
- TODO
Version 3.01 RELEASE NOTES
- Support for z990 crypto instructions is conditional on the presence of the
glibcrypt library.
If Hercules is BUILT, the development files for glibcrypt should be available.
When hercules is RUN, the runtime files for glibcrypt should be installed.
Depending on the level of glibcrypt used to *build* hercules, the associated
level of glibcrypt should also be present on the target machine. On systems
supporting shared library versioning, multiple levels of the glibcrypt
runtime libraries can be installed simultaneously, ensuring availability
of the z990 crypto instructions, regardless of the level of glibcrypt with
which hercules was initially built.
- CTC and LCS devices now ++MUST++ specify ALL addresses on the configuration
statement.
Example:
0A00.2 LCS .....
0B00.2 CTCI ....
or
0A00.4 LCS -oat hercules.oat
or
0A00-0A03 LCS -oat hercules.oat
or
0A00 LCS -oat hercules.oat
0A01 LCS
0A02 LCS
0A03 LCS
Previously (i.e. with version 3.00), only the first (even numbered) device
needed to be defined and Herc would automatically define the odd numbered
device for you. Starting with Hercules version 3.01 however, you now need
to define BOTH devices, just like you did with versions prior to 3.00.
Once again, starting with version 3.01, you **MUST** define BOTH DEVICES.
-------------------------------------------------------------------------------
Version 3.00 RELEASE NOTES
- Reminder that CTCI device handling was changed as follows:
- The CTCI-W32 protocol is deprecated. You should use the CTCI protocol
instead.
- You MUST NOT define both even/odd CTCI device pairs in your configuration
file. You should ONLY define the first even numbered device. Hercules will
automatically define the odd numbered device for you. If you define the
odd numbered device by mistake, an open error will occur on that device.
This is by design. See the README.NETWORKING document for further details.
- Hercules Dynamic Loader support: starting with version 3.00, Hercules now
contains support for the dynamic loading of certain modules upon startup on
some platforms (e.g. Linux and Windows for example). As a result of this new
feature, "Hercules" itself now no longer consists of just the 'hercules.exe'
module by itself, but rather consists of BOTH the 'hercules.exe' program AS
WELL AS whatever dynamic modules (DLLs) that accompany it.
As a result if this change, whenever you install a new version of Hercules,
you must ensure that you ALSO install the accompanying new versions of the
new dynamic modules as well. Attempting to use a version of Hercules with a
dynamic module that was not specifically built for that version will cause
loading of that dynamic module to fail.
You CANNOT mix versions of Hercules with differing versions of dynamically
loaded modules.
Ensure that your library path LD_LIBRARY_PATH is set correctly such that it
includes the directory of your Hercules executables. Especially, message
HHCCF042E will indicate that system is unable to locate necessary loadable
modules.
- ECPS:VM: Do not use ECPS:VM (See README.ECPSVM) in an AP or MP environment
in VM/370. If AP=YES or MP=YES is coded in DMKSYS and the AP/MP control
file is used to build the CP nucleus and NUMCPU is set to more than 1 in
the hercules.cnf file, any of LOK001, LOK003 or other abends will occur.
This occurs because the Hercules ECPS:VM CP Assist implementation is not
MP safe, and particularily, attemps VM dispatching without holding necessary
AP or MP locks.
- Due to the change in Hercules' "mainstor" memory allocation technique to
address a "double memory consumption" bug in Cygwin's malloc implementation,
some Windows Hercules users may experience an "out of memory" error whenever
Hercules is started with a large MAINSIZE configuration file value:
"HHCCF031S Cannot obtain nnnMB main storage"
This error will most likely occur (if it does at all) for those users who
have manually adjusted their Cygwin "heap_chunk_in_mb" Windows registry
setting value (in order to allow them to specify a large MAINSIZE value
when running Hercules). If this problem does occur (i.e. if you DO happen
to experience the above mentioned "HHCCF031S Cannot obtain main storage"
error with this new release of Hercules), then either REDUCE your "heap_
chunk_in_mb" value (yes, that's correct: REDUCE it; i.e. change it to a
SMALLER value) or else remove it altogether (so as to let it default).
Detailed explanation:
History/background: Cygwin has a built-in limit to the amount of memory
that may be allocated in one chunk. If you try 'malloc'ing more than this
limit, you will receive an "out of memory" error. Since many Hercules users
specify large MAINSIZE values in their configuration file, they sometimes
experience this problem.
The suggested workaround to this "problem" was to add a "heap_chunk_in_mb"
registry value to Cygwin's registry settings with a large enough value such
that Cygwin would then be able to satisfy Hercules' 'malloc' request for
such a large MAINSIZE value.
This worked fine until sometime around version 1.3.15 of Cygwin, at which
time they began using a different 'malloc' technique that unfortunately
causes TWICE as much Windows virtual memory to be allocated for any large
memory allocation (the technical reasons of which are explained in comments
in source member config.c where mainsize is being allocated).
In order to address this double memory allocation issue in Cygwin's malloc
implementation, Hercules was changed to use mmap to allocate its mainstor
rather than malloc (which, unlike malloc, does NOT inadvertently allocate
twice as Windows virtual storage than was requested), which did indeed re-
solve the "double memory allocation" problem.
Unfortunately however, because Cygwin's malloc and mmap logic each consume
completely different portions of Windows' virtual memory, the more memory
that is reserved for malloc usage (via using a larger "heap_chunk_in_mb"
value), the LESS becomes available for mmap usage!
Thus, while increasing your "heap_chunk_in_mb" registry value USED to HELP
[to allow you to allocate larger amounts of mainstor (MAINSIZE)], it NOW
causes the complete OPPOSITE effect: it ends up PREVENTING you from being
able to 'mmap' as much storage as you'd like to have!
Conclusion:
Therefore, if you are currently using the "heap_chunk_in_mb" registry value
setting to allow you to allocate large MAINSIZE values, then starting with
version 3.00 of Hercules you need to DESCREASE your "heap_chunk_in_mb" value
(or remove it altogether and let it default) in order to leave enough memory
remaining for Hercules (Cygwin actually) to be able to satisfy its 'mmap'
request for your desired MAINSIZE amount.
|
