Exspans Systems Inc Logo home
 
Forum
Sign up Calendar Latest Topics
 
 
 


Reply
  Author   Comment   Page 1 of 4      1   2   3   4   Next
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #1 
I think it would be nice to allow wildcards in selected AutoMan console commands.
For example, z/OS allows:
D A,RMF*
It would be nice if AutoMan allowed:
F AUTOMAN,DISPLAY SSID(RMF*)

__________________
zboxassist
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #2 
I don't think I have any SSIDs that match on names like that, except RMF and RMFGAT.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #3 
I've worked in shops that had many CICS regions that all began with CI*, multiple DB2 subsystems that all began with DB*, etc.In those shops, having pattern matching/wildcards would be nice. Other shops, not so much.
__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #4 
In my AutoMan startup script, I switch the CMDCONS to an internal console is to guarantee commands issued by AutoMan come from an active console. My reason: I would start AutoMan from my “personal” sysprog console. Then later, I would go home, but I would shut down my console before leaving. When my console became inactive, then some AutoMan issued commands would start to fail.

Based on that, a nice feature would be an automatic switching of the CMDCONS from an inactive console to the first active console in a customer supplied list of console ids in a parm member/option.

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #5 
P.S. Or perhaps a better solution-- an option for AutoMan to switch CMDCONS from an inactive console to an active console in the current AUTOACT console group or in a user specified z/OS console group.
__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #6 
The wildcard has been added to the list of things to consider for V3.3. Aside from the addition of file allocation and writing the majority of that version is dedicated to language interpretation improvements. The console can be switched at any time by programmed command, but the idea of having a console group, or list of eligible consoles, is appealing. Other things that are being considered for that version are LOAD SSID and LOAD CONFIG commands. Those are complicated by the potential interdependency on each other.

This is in fact a good time to suggest upgrades and improvements, because the eventual feature set of V3.3 is not decided yet.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #7 
The SSID and CONFIG members are so interdependent you might consider adding some mechanism to ensure they are always loaded together. Here are several possible ideas:

1. LOAD SSID command would first unload/delete current CONFIG definitions, then load the new SSID definition member. If SSID loaded successfully, then ask you if you want to to re-load the previous CONFIG definition member, load a new CONFIG definition member, or not load a CONFIG definition member.
2. Allow a LOAD SSID statement in CONFIG definition, so that when CONFIG is reloaded, it's corresponding SSID definition is automatically reloaded.
3. Allow a LOAD CONFIG statement in SSID definition, so that when SSID is reloaded, it's corresponding CONFIG definition is automatically reloaded.
4. Merge SSID and CONFIG definitions into a single SSID member with two sections. First section would be the SSID definitions and the second section would be the CONFIG definitions.

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #8 
Obviously, options 2 and 3 need to be mutually exclusive otherwise you could have a infinite definition loop.
__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #9 
They are interdependent, yet SSIDs can be used without CONFIGs. CONFIGs cannot be used without SSIDs. If no new CONFIG was to be used, then it is not a big deal to do some sort of resolution, but such resolution would be a waste of effort if new CONFIGs were also to be loaded. The interdependency of the message processor with SSIDs is also a major consideration, and the main reason that the decision on how to perform LOAD and UPDATE was deferred. Having gone down the path of separate definitions we do not really want to change horses and do it in a majorly different way. I would like it better if the people who asked for it were better communicators about what their desires are. A LOAD SSID would effectively replace all of them, and thus invalidate all the current CONFIGs. An UPDATE could add new ones or replace old ones, but not delete those not referenced. As a LOAD potentially invalidates all CONFIGs, they could be deleted and a new LOAD CONFIG requested. The alternative is a LOAD command of some sort, whose syntax requires both a SSID and a CONFIG member.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #10 
I have no issue with making a backup copy of my SSID/CONFIG definition members, updating them, then wholesale re-loading them (i.e., I don't really have a need for an UPDATE command). I think allowing an UPDATE command for SSID and CONFIG definitions would be really tough because there is so much possible interdependence within a SSID member, within a CONFIG member, and between SSID and CONFIG members. While an UPDATE command might be possible, I would vote to keep things simple, and just allow complete reload.

My personal preference would have been option 4 (to merge SSID and CONFIG definitions into one member), but as it is pointed out, it is really not practical. It is too big of a change to expect existing customers to tolerate. Also that large of a change would have a correspondingly large change in AutoMan coding that simply would not be worth it. For what it is worth, I did forget to mention that the second section with the CONFIG definitions should be optional.


__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #11 
Another possible new feature:

Message rule processing - I think that for the vast majority of customers, a message will typically match only one rule, therefore after the first successful match, scanning for additional matches would usually be a waste of time. AutoMan should try to take advantage of that
        a. MSGID and SSID message rules could be assigned a level and a priority
                i. MSGLVL - perhaps a range from 0 to 7 would be sufficient.
                ii. MSGPRIO - perhaps a range from 0 to 7 would be sufficient.
                iii. MSGID rules should have a default level and priority that the customer can set with a parmlib option
                iv. SSID rules should have a separate default level and priority that the customer can set with a parmlib option. A separate default would allow the customer to control the general order of MSGID rules vs. SSID rules.
                v. There should be built-in default level and priority values
                        1) For MSGID perhaps a default MSGLVL of 2 and MSGPRIO of 2
                        2) For SSID perhaps a default MSGLVL of 5 and MSGPRIO of 2. This would cause MSGID rules to generally match before SSID rules. However, I cannot think of any universal reasons to favor MSGID rules over SSID rules, so these defaults may not be the best choice for the majority of your customers.
        b. Order of processing message rules
                i. By level from lowest to highest
                ii. Then within a level by priority from lowest to highest
                iii. Then within a level and priority by order of definition - I'm not sure which is defined first MSGID rules or SSID rules, but that should not matter a whole lot since the customer could use MSGLVL and MSGPRIO to control the order.
        c. When a rule matches, the associated GAL code is executed. When that GAL code exits, message rule processing skips remaining rules at the current MSGLVL, and continues processing rules at next level
                i. There probably needs to be a new GAL statement to set/override the current MSGLVL and/or MSGPRIO. However, you probably do not want to allow reducing the MSGLVL or MSGPRIO, in order to avoid the possibility of endless scan loops.

I would allow, but ignore, MSGLVL and MSGPRIO keywords on RMSGID and SYSOUT processing MSG statements. I cannot think of a good use of these keywords in those environments.


__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #12 
DASD configuration manager
        a. Manages Metro and Global Mirror configuration
        b. Monitors I/O path health
        c. Hyperswap manager
                i. Single System
                ii. Multi-System (AutoMan would have to synchronize hyperswap across all systems)

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #13 
New event sources
        a. ENF event monitor
                i. DASD events?
                ii. Address space events?
        b. EREP/LOGREC event monitor
        c. z/OS Health Checker event monitor
        d. VTAM Primary/Secondary Program Operator

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #14 
New SSID status and reason codes/descriptions
        i. Probably over 95% of most SSIDs can be appropriately represented using the states DOWN, STARTING, UP, HALTING, FAILED, and UNKNOWN. However, there is a small number of SSIDs that need more states. For example, in order to shutdown JES2, OMVS does not need to be fully shutdown, but rather just shutdown FORKINIT. Rather than adding new states, I think allowing user defined status and reason codes/descriptions to complement the current set of states would work.
        ii. The SSID actions should be able to set the status and reason codes
        iii. New status and reason codes qualification keywords for the various types of events

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #15 
New event sources could be monitored as part of a SSID definition
        [ ON MSG event_definition ] …
        [ ON COMMAND event_definition ] …
        [ ON SYSOUT (a.k.a. TEXT) event_definition ] …
        [ ON JOBS event_definition ] …
        [ ON condition event_definition ] …
        [ AT schedule_expression event_definition ] …
        [ ON ENF event_definition ] …
        [ ON AUTOMAN event_definition ] …

__________________
zboxassist
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!