[hercules-390] Hercules ALS values (Architecture Level Sets)

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

Another question for the developers.

I'm working on revamping Hercules's facilities support implementation and in the 'archlvl.c' source file I'm seeing:


#define ALS0 0x01 /* S/370 */
#define ALS1 0x02 /* ESA/390 */
#define ALS2 0x04 /* Z/ARCH */
#define ALS3 0x08 /* ARCHLVL 3 */


and:


/*-------------------------------------------*/
/* Architecture Level Table (archtab) */
/*-------------------------------------------*/
static ARCHTAB archtab[] =
{
#if defined( _370 )
/* S/370 - ALS0 */
ARCHLVL( _ARCH_370_NAME, ARCH_370, ALS0 )
ARCHLVL( "370", ARCH_370, ALS0 )
ARCHLVL( "S370", ARCH_370, ALS0 )
ARCHLVL( "S/370", ARCH_370, ALS0 )
ARCHLVL( "ALS0", ARCH_370, ALS0 )
#endif
/*
Note that XA and XB are not offered, and
neither is G3 (debut of relative/immediate).
*/
#if defined( _390 )
/* ESA/390 - ALS1 */
ARCHLVL( _ARCH_390_NAME, ARCH_390, ALS1 )
ARCHLVL( "ESA", ARCH_390, ALS1 )
ARCHLVL( "ESA390", ARCH_390, ALS1 )
ARCHLVL( "S/390", ARCH_390, ALS1 )
ARCHLVL( "S390", ARCH_390, ALS1 )
ARCHLVL( "390", ARCH_390, ALS1 )
ARCHLVL( "ALS1", ARCH_390, ALS1 )
#endif
#if defined( _900 )
/* z/Arch - ALS2 */
ARCHLVL( "ESA/ME", ARCH_900, ALS2 )
ARCHLVL( "ESAME", ARCH_900, ALS2 )
ARCHLVL( "ALS2", ARCH_900, ALS2 )
/* z/Arch - ALS3 */
ARCHLVL( _ARCH_900_NAME, ARCH_900, ALS3 )
ARCHLVL( "zArch", ARCH_900, ALS3 )
ARCHLVL( "z", ARCH_900, ALS3 )
ARCHLVL( "ALS3", ARCH_900, ALS3 )
#endif
{ NULL, 0, 0 } // (end of table)
};


and:


/*--------------------------------------------------*/
/* FACTAB struct (Facility Table) */
/*--------------------------------------------------*/
struct FACTAB
{
const char* name; /* Facility Name */
const int bitno; /* Bit number */
const BYTE mode; /* Mode indicator */

#define S370 0x01 /* S/370 feature */
#define ESA390 0x02 /* ESA/390 feature */
#define ZARCH 0x04 /* ESAME feature */
#define Z390 (ZARCH|ESA390) /* Exists in ESAME only,
but is also indicated
in ESA390 */
[...etc...]


and:


static FACTAB factab[] =
{
/* Facility Default Mandatory Supported Group */
#if defined(_FEATURE_ESAME_N3_ESA390)
FACILITY( N3, ESA390|ZARCH, NONE, ESA390|ZARCH, ALS1|ALS2|ALS3 )
#endif

#if defined(_FEATURE_ESAME)
FACILITY( ESAME_INSTALLED, ESA390|ZARCH, NONE, ESA390|ZARCH, ALS2|ALS3 )
FACILITY( ESAME_ACTIVE, ZARCH, ZARCH, ZARCH, ALS2|ALS3 )
#endif

#if defined(_FEATURE_DAT_ENHANCEMENT_FACILITY_1)
FACILITY( IDTE_INSTALLED, Z390, NONE, Z390, ALS2|ALS3 )
FACILITY( IDTE_SC_SEGTAB, 0, /*ZARCH*/ NONE, 0, /*ZARCH*/ ALS2|ALS3 )
FACILITY( IDTE_SC_REGTAB, 0, /*ZARCH*/ NONE, 0, /*ZARCH*/ ALS2|ALS3 )
#endif

#if defined(_FEATURE_ASN_AND_LX_REUSE_FACILITY)
FACILITY( ASN_LX_REUSE, 0, /*Z390*/ NONE, Z390, ALS2|ALS3 )
#endif

[...etc...]



My question is, what the heck is an ALS? (Architecture Level Set)

Is that an IBM thing or a Hercules thing?

As best as I can tell its only purpose is to somehow indicate which archlvl (archmode) architectures each facility table entry is valid for. But if so, then why do we have a separate "Supported" column? What is supposed to be the difference between the "Supported" column and the "Group" column? Couldn't we just have one or the other and get rid of the other? It's very confusing to me!

Help!

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

On Fri, 2017-12-15 at 13:04 -0800, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Another question for the developers.
I'm working on revamping Hercules's facilities support implementation
  #define ALS0  0x01  /* S/370     */
  #define ALS1  0x02  /* ESA/390   */
  #define ALS2  0x04  /* Z/ARCH    */
  #define ALS3  0x08  /* ARCHLVL 3 */
  /*-------------------------------------------*/
  /*    Architecture Level Table (archtab)     */
  /*-------------------------------------------*/
  static ARCHTAB archtab[] =
  {
  #if defined( _370 )
    /* S/370 - ALS0 */
    ARCHLVL( _ARCH_370_NAME, ARCH_370, ALS0 )
    ARCHLVL( "370",          ARCH_370, ALS0 )
    ARCHLVL( "S370",         ARCH_370, ALS0 )
    ARCHLVL( "S/370",        ARCH_370, ALS0 )
    ARCHLVL( "ALS0",         ARCH_370, ALS0 )
  #endif
  /*
      Note that XA and XB are not offered, and
      neither is G3 (debut of relative/immediate).
  */
  #if defined( _390 )
    /* ESA/390 - ALS1 */
    ARCHLVL( _ARCH_390_NAME, ARCH_390, ALS1 )
    ARCHLVL( "ESA",          ARCH_390, ALS1 )
    ARCHLVL( "ESA390",       ARCH_390, ALS1 )
    ARCHLVL( "S/390",        ARCH_390, ALS1 )
    ARCHLVL( "S390",         ARCH_390, ALS1 )
    ARCHLVL( "390",          ARCH_390, ALS1 )
    ARCHLVL( "ALS1",         ARCH_390, ALS1 )
  #endif
  #if defined( _900 )
    /* z/Arch - ALS2 */
    ARCHLVL( "ESA/ME",       ARCH_900, ALS2 )
    ARCHLVL( "ESAME",        ARCH_900, ALS2 )
    ARCHLVL( "ALS2",         ARCH_900, ALS2 )
    /* z/Arch - ALS3 */
    ARCHLVL( _ARCH_900_NAME, ARCH_900, ALS3 )
    ARCHLVL( "zArch",        ARCH_900, ALS3 )
    ARCHLVL( "z",            ARCH_900, ALS3 )
    ARCHLVL( "ALS3",         ARCH_900, ALS3 )
  #endif
    { NULL, 0, 0 }          // (end of table)
  };
  /*--------------------------------------------------*/
  /*       FACTAB struct (Facility Table)             */
  /*--------------------------------------------------*/
  struct FACTAB
  {
    const char*  name;             /* Facility Name  */
    const int    bitno;            /* Bit number     */
    const BYTE   mode;             /* Mode indicator */
  #define S370    0x01            /* S/370 feature   */
  #define ESA390  0x02            /* ESA/390 feature */
  #define ZARCH   0x04            /* ESAME feature   */
  #define Z390    (ZARCH|ESA390)  /* Exists in ESAME only,
                                     but is also indicated
                                     in ESA390       */
  [...etc...]
  static FACTAB factab[] =
  {
 
/*        Facility          Default  Mandatory  Supported     Group  
*/
  #if defined(_FEATURE_ESAME_N3_ESA390)
  FACILITY( N3,              ESA390|ZARCH, NONE,  ESA390|ZARCH,
ALS1|ALS2|ALS3 )
  #endif
  #if defined(_FEATURE_ESAME)
  FACILITY( ESAME_INSTALLED, ESA390|ZARCH, NONE,  ESA390|ZARCH,
ALS2|ALS3 )
  FACILITY( ESAME_ACTIVE,    ZARCH,        ZARCH,
ZARCH,        ALS2|ALS3 )
  #endif
  #if defined(_FEATURE_DAT_ENHANCEMENT_FACILITY_1)
  FACILITY(
IDTE_INSTALLED,  Z390,         NONE,  Z390,         ALS2|ALS3 )
  FACILITY( IDTE_SC_SEGTAB,  0, /*ZARCH*/  NONE,  0,
/*ZARCH*/  ALS2|ALS3 )
  FACILITY( IDTE_SC_REGTAB,  0, /*ZARCH*/  NONE,  0,
/*ZARCH*/  ALS2|ALS3 )
  #endif
  #if defined(_FEATURE_ASN_AND_LX_REUSE_FACILITY)
  FACILITY( ASN_LX_REUSE,    0,
/*Z390*/   NONE,      Z390,               ALS2|ALS3 )
  #endif
  [...etc...]
My question is, what the heck is an ALS? (Architecture Level Set)
Is that an IBM thing or a Hercules thing?

ALS is an IBM thing.  I have seen it mostly used within the context of
VM.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
As best as I can tell its only purpose is to somehow indicate which
archlvl (archmode) architectures each facility table entry is valid
for.  But if so, then why do we have a separate "Supported"
column?  What is supposed to be the difference between the
"Supported" column and the "Group" column?  Couldn't we just have one
or the other and get rid of the other?  It's very confusing to me!

"Supported" identifies in which Hercules architecture modes the
facility is supported.  "Group" identifies in which level sets the
facility exists.  While mostly they are the same, ALS2 and ALS3 are
different level sets but are supported by Hercules internally with the
same architecture mode.

Both values are needed for this distinction.

Note, without updates to the individual instructions to validate the
facility is enabled, only the STFL(E) list is affected.  Hercules will
execute the instruction regardless of the enabled or disabled
facilities if the instruction is enabled during the build by featxxx.h.

It could be viewed that manipulation of the architecture level concept
is missing the run-time detection of enabled or disabled facilities by
the function executing the instruction.

Note that there are facilities enabled or disabled by archlvl that are
not reported by STFL(E).  These are Hercules specific facilities, and
they do actually inspect the run-time state.  An example is the ability
to use the SIGP change-architecture order to enter S/370 (from which
you can not get out because this order is not supported in S/370
itself).

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

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

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
My question is, what the heck is an ALS? (Architecture Level Set)
Is that an IBM thing or a Hercules thing?

ALS is an IBM thing. I have seen it mostly used within the context
of VM.

Thank you for taking the time to respond, Harold. I appreciate that.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
As best as I can tell its only purpose is to somehow indicate
which archlvl (archmode) architectures each facility table entry
is valid for. But if so, then why do we have a separate
"Supported" column? What is supposed to be the difference between
the "Supported" column and the "Group" column? Couldn't we
just have one or the other and get rid of the other? It's very
confusing to me!

"Supported" identifies in which Hercules architecture modes
the facility is supported. "Group" identifies in which level sets
the facility exists. While mostly they are the same, ALS2 and
ALS3 are different level sets but are supported by Hercules
internally with the same architecture mode.

I saw that, yes. ESAME is ALS2 and z/Arch is ALS3, even though ESAME is the same thing as z/Arch. Very confusing.

Both values are needed for this distinction.

Yes, I can see that, but I'm questioning the wisdom of even bothering to MAKE that distinction. Why? We treat them the same because they actually ARE the same. ESAME is just z/Arch before z/Arch was called z/Arch. Just different names for the same thing. Thus ALS2 is logically the same as ALS3 given that, as you point out (and as I noticed myself), we treat them the same. Both map to z/Arch.

So why even BOTHER to introduce a distinction between the two when doing so only adds confusion and doesn't make a damn bit of difference code-wise? It makes no sense to me.

Note, without updates to the individual instructions to validate
the facility is enabled, only the STFL(E) list is affected.
Hercules will execute the instruction regardless of the enabled
or disabled facilities if the instruction is enabled during the
build by featxxx.h.

Yes, I noticed that myself as well, and such (IMHO incorrect) behavior should be considered a bug that should be fixed IMHO:

"Facilities support needs auditing / improved #71"
https://github.com/Fish-Git/hyperion/issues/71
(opened 11 days ago)

It could be viewed that manipulation of the architecture level
concept is missing the run-time detection of enabled or disabled
facilities by the function executing the instruction.

Hence the creation of Issue #71 mentioned above.

Note that there are facilities enabled or disabled by archlvl
that are not reported by STFL(E). These are Hercules specific
facilities, and they do actually inspect the run-time state.
An example is the ability to use the SIGP change-architecture
order to enter S/370 (from which you cannot get out because
this order is not supported in S/370 itself).

Already knew about that too. BUT...

The Hercules-specific STFLE bits themselves are FUBAR (F**ked Up Beyond All Recognition):

"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73
(opened 10 days ago)


Jan really screwed the pooch on that one (which is so unlike him).

Thanks again for responding Harold. I appreciate it.

['Norman Hollander on Desertwiz' [e-mail] [hercules-390]]

IMHO, a lot of the ALS business was marketing thing. It was meant to keep a customer

moving forward on Hardware and thereby Operating Systems. The newest hardware

Z14 has a ALS that allows you to run z/OS 2.3 or zVM 6.4. BUT, you supposedly can’t

run new OSes on older machines with different ALS. And vice versa. So z/OS 1.13 won’t

run on a Z14, nor can z/OS 2.3 run on a z10. So, fork over more $$$ for new hardware and

the OS that runs on it. Now, some may disagree, and will find some instructions were meant

for higher ALS. These instructions typically supported new hardware functions, and the

software that supports it. I can only remember that ALS inhibited OS/390 2.10 on native hardware;

but it ran fine on zVM with 2.10 as a guest. Go figure


zN



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Saturday, December 16, 2017 12:48 PM
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] Hercules ALS values (Architecture Level Sets)
[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
My question is, what the heck is an ALS? (Architecture Level Set)
Is that an IBM thing or a Hercules thing?

ALS is an IBM thing. I have seen it mostly used within the context
of VM.

Thank you for taking the time to respond, Harold. I appreciate that.

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
As best as I can tell its only purpose is to somehow indicate
which archlvl (archmode) architectures each facility table entry
is valid for. But if so, then why do we have a separate
"Supported" column? What is supposed to be the difference between
the "Supported" column and the "Group" column? Couldn't we
just have one or the other and get rid of the other? It's very
confusing to me!

"Supported" identifies in which Hercules architecture modes
the facility is supported. "Group" identifies in which level sets
the facility exists. While mostly they are the same, ALS2 and
ALS3 are different level sets but are supported by Hercules
internally with the same architecture mode.

I saw that, yes. ESAME is ALS2 and z/Arch is ALS3, even though ESAME is the same thing as z/Arch. Very confusing.

Both values are needed for this distinction.

Yes, I can see that, but I'm questioning the wisdom of even bothering to MAKE that distinction. Why? We treat them the same because they actually ARE the same. ESAME is just z/Arch before z/Arch was called z/Arch. Just different names for the same thing. Thus ALS2 is logically the same as ALS3 given that, as you point out (and as I noticed myself), we treat them the same. Both map to z/Arch.

So why even BOTHER to introduce a distinction between the two when doing so only adds confusion and doesn't make a damn bit of difference code-wise? It makes no sense to me.

Note, without updates to the individual instructions to validate
the facility is enabled, only the STFL(E) list is affected.
Hercules will execute the instruction regardless of the enabled
or disabled facilities if the instruction is enabled during the
build by featxxx.h.

Yes, I noticed that myself as well, and such (IMHO incorrect) behavior should be considered a bug that should be fixed IMHO:

"Facilities support needs auditing / improved #71"
https://github.com/Fish-Git/hyperion/issues/71
(opened 11 days ago)

It could be viewed that manipulation of the architecture level
concept is missing the run-time detection of enabled or disabled
facilities by the function executing the instruction.

Hence the creation of Issue #71 mentioned above.

Note that there are facilities enabled or disabled by archlvl
that are not reported by STFL(E). These are Hercules specific
facilities, and they do actually inspect the run-time state.
An example is the ability to use the SIGP change-architecture
order to enter S/370 (from which you cannot get out because
this order is not supported in S/370 itself).

Already knew about that too. BUT...

The Hercules-specific STFLE bits themselves are FUBAR (F**ked Up Beyond All Recognition):

"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73
(opened 10 days ago)

Jan really screwed the pooch on that one (which is so unlike him).

Thanks again for responding Harold. I appreciate it.

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

Post by 'Norman Hollander on Desertwiz' ***@desertwiz.biz [hercules-390]
IMHO, a lot of the ALS business was marketing thing. It
was meant to keep a customer moving forward on Hardware
and thereby Operating Systems.

[...]

Post by 'Norman Hollander on Desertwiz' ***@desertwiz.biz [hercules-390]
So z/OS 1.13 won’t run on a Z14, nor can z/OS 2.3 run on
a z10. So, fork over more $$$ for new hardware and the OS
that runs on it.

[...]

Post by 'Norman Hollander on Desertwiz' ***@desertwiz.biz [hercules-390]
I can only remember that ALS inhibited OS/390 2.10 on
native hardware; but it ran fine on zVM with 2.10 as a
guest. Go figure...

That unfortunately doesn't actually surprise me all that much. Not that IBM engages in such chicanery but rather that *any* company does.

What's worse is that we the customers feel helpless to do anything about it and let them to get away with it as a result.

Anyway, thanks for the response, Norm.

['Norman Hollander on Desertwiz' [e-mail] [hercules-390]]

Fish-

The customer always has the choice not to upgrade their hardware and

related operating systems. But then they may be giving some wiz-bang

feature they perceive they must have. I’m sure you’ll find that the current

version of Db2 (yes, lower case now), or CICS require 2.3 or z/OS. IBM does

keep you moving along but creating Out of Service Dates. Meaning, unless

you pay big bucks, you cannot get fixes for your systems if they have “expired”.

May not be an issue. But I’ve had several manufacturer guaranties expire shortly

after the expiration date. Maybe best to lease hardware and upgrade on a regular

basis. Maybe that’s why IBM is pushing their “current” clouds
 Service Bureaus

may have a certain appeal


Happy Holidays Fish, and have a fantastic 2018!

zN



From: hercules-***@yahoogroups.com [mailto:hercules-***@yahoogroups.com]
Sent: Monday, December 18, 2017 5:47 AM
To: hercules-***@yahoogroups.com
Subject: RE: [hercules-390] Hercules ALS values (Architecture Level Sets)

IMHO, a lot of the ALS business was marketing thing. It
was meant to keep a customer moving forward on Hardware
and thereby Operating Systems.

[...]

So z/OS 1.13 won’t run on a Z14, nor can z/OS 2.3 run on
a z10. So, fork over more $$$ for new hardware and the OS
that runs on it.

[...]

I can only remember that ALS inhibited OS/390 2.10 on
native hardware; but it ran fine on zVM with 2.10 as a
guest. Go figure...

That unfortunately doesn't actually surprise me all that much. Not that IBM engages in such chicanery but rather that *any* company does.

What's worse is that we the customers feel helpless to do anything about it and let them to get away with it as a result.

Anyway, thanks for the response, Norm.

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

Fish wrote:

[...]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The Hercules-specific STFLE bits themselves are FUBAR (F**ked Up
"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73
(opened 10 days ago)
Jan really screwed the pooch on that one (which is so unlike him).

RESET!

After having looked at this issue more closely recently I've discovered a subtlety in Jan's design that I hadn't noticed before. Bottom line: Jan apparently did NOT screw the pooch on this one. It only appeared as if he did..

My sincerest apologies to Jan.

But Hercules's implementation of facilities support *is* screwed up and does need a lot of work.

Most of that probably isn't Jan's fault though. He just didn't explain too well (or did he?) the ramifications of his new design, resulting in, over time, more and more new code to support new facilities being introduced into our codebase that failed to implement proper runtime support as per his new design.

A few comments in the code or a new document better explaining his design and the requirements that go along with it would have been helpful however.

Nevertheless the bulk of issue #73 is not Jan's fault and I apologize to him for being so harsh. Issue #73 has been closed and marked invalid:

https://github.com/Fish-Git/hyperion/issues/73

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

On Mon, 2017-12-18 at 05:32 -0800, ''Fish' (David B. Trout)'

[...] 

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
The Hercules-specific STFLE bits themselves are FUBAR (F**ked Up
   "Hercules-specific facility bits SNAFU #73"
   https://github.com/Fish-Git/hyperion/issues/73
   (opened 10 days ago)
Jan really screwed the pooch on that one (which is so unlike him).

After having looked at this issue more closely recently I've
discovered a subtlety in Jan's design that I hadn't noticed before.  

Care to share what this subtlety is?

Harold

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

[...]

Post by Harold Grovesteen ***@tx.rr.com [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
After having looked at this issue more closely recently
I've discovered a subtlety in Jan's design that I hadn't
noticed before.

Care to share what this subtlety is?

Well, I suppose it's not so much a subtlety as it is an oversight on my part. I didn't study ALL related code closely enough.

I'll let my GitHub Issue comments explain:


"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73

[Ivan Warren [e-mail] [hercules-390]]

Le 12/18/2017 à 7:56 PM, ''Fish' (David B. Trout)'

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Well, I suppose it's not so much a subtlety as it is an oversight on
my part. I didn't study ALL related code closely enough.
"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73

Hey Fish !

Again (sorry if I'm repeating myself) but...

What is it that's broken that needs fixing ?

--Ivan

(Call me or ping me and I'll call you back if you want).



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

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

[...]

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Well, I suppose it's not so much a subtlety as it is an
oversight on my part. I didn't study ALL related code
"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73

Hey Fish !
Again (sorry if I'm repeating myself) but...
What is it that's broken that needs fixing ?

Facilities support needs auditing / improved
https://github.com/Fish-Git/hyperion/issues/71

[Ivan Warren [e-mail] [hercules-390]]

Le 12/18/2017 à 11:38 PM, ''Fish' (David B. Trout)'

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Well, I suppose it's not so much a subtlety as it is an
oversight on my part. I didn't study ALL related code
"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73

Hey Fish !
Again (sorry if I'm repeating myself) but...
What is it that's broken that needs fixing ?

Facilities support needs auditing / improved
https://github.com/Fish-Git/hyperion/issues/71

Hey Fish !

Replied about this on GITHUB (according to my understanding)

--Ivan



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

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

And I replied to YOUR reply according to MY understanding! :)
--
"Fish" (David B. Trout)
Software Development Laboratories
http://www.softdevlabs.com

-----Original Message-----
Sent: Monday, December 18, 2017 5:58 PM
Subject: Re: [hercules-390] Hercules ALS values (Architecture Level
Sets)
Importance: High
Le 12/18/2017 à 11:38 PM, ''Fish' (David B. Trout)'

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

Post by Ivan Warren ***@vmfacility.fr [hercules-390]

Post by '\'Fish\' (David B. Trout)' ***@gmail.com [hercules-390]
Well, I suppose it's not so much a subtlety as it is an
oversight on my part. I didn't study ALL related code
"Hercules-specific facility bits SNAFU #73"
https://github.com/Fish-Git/hyperion/issues/73

Hey Fish !
Again (sorry if I'm repeating myself) but...
What is it that's broken that needs fixing ?

Facilities support needs auditing / improved
https://github.com/Fish-Git/hyperion/issues/71

Hey Fish !
Replied about this on GITHUB (according to my understanding)
--Ivan
[Non-text portions of this message have been removed]