Exspans Systems Inc Logo home
 
Forum
Sign up Calendar Latest Topics
 
 
 


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

Member
Registered:
Posts: 89
Reply with quote  #16 
Multiple Instances of Address Spaces represented by one SSID definition
        i. Currently one SSID represents one address space. There may be multiple address spaces running the same product, but each address space will have its own SSID definition.
        ii. A multiple instance feature would allow one SSID definition to represent multiple address spaces. For example, consider WebSphere.
        iii. The WebSphere control region starts and stops its servant regions. Of course, AutoMan can start, stop, monitor, and otherwise automate a WebSphere control region (one SSID). HOwever, a WebSphere control region manages its associated servant regions (one or more address spaces with the same name). This prevents AutoMan from being able to start and stop servant regions, but that should not prevent AutoMan from being able to monitor and automate the servant regions. One SSID definition would need to represent multiple servant regions since WebSphere may start one or more. AutoMan would need to be able to recognize when the WebSphere control region was starting or stopping a servant region. For example, AutoMan would be able to detect that a servant is being shutdown, then if the shutdown was taking too long, AutoMan could cancel a hung servant region.

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #17 
I've been sitting on the above suggestions for several years and they may be no longer relevant. For the ones worth discussion, we probably need to split them out as separate forum topics.
I have more, but I need to head home.

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #18 
SSID sections with transition qualifications
        i. In a more or less perfect world, a SSID's life transitions from DOWN to STARTING to UP to HALTING and back to DOWN, in that order. Of course, in the real world, stuff happens, people change their mind, etc. For example, you request that a SSID be started, but before it is completely up, you find that you need to abort the startup. AutoMan may need to use a different command (i.e., the normal stop command will not work until the SSID is completely up) to abort the startup.
        ii. SECTION [ section_name ] From=(current_state1,…) To=target_state [ StatusCode=(status_code1,…) ] [ ReasonCode=(reason_code1,…) ] [ other_qualifications ]
        iii. INITiate CMD(…) | RUN(…)
        iv. ON MSG events
        v. ON COMMAND events
        vi. ON SYSOUT (a.k.a. TEXT) events
        vii. ON JOBS schedule events
        viii. ON condition events
        ix. AT events
        x. ON enf-events
        xi. ON AutoMan-events
        xii. TERMinate CMD(…) | RUN(…)
        xiii. ENDSECTION

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #19 
AutoMan Report Writer
        a. AutoMan could record significant events
                i. Events could be stored in either journal/log or database
                ii. What is considered significant should be customizable
        b. Canned/customizable reports
                i. SSID availability, uptime, downtime, history, etc. reports
                ii. JOBS history, duration, early/late reports

__________________
zboxassist
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #20 
The use of a LOAD PARMS command to replace everything has always worked for me. The compilation is so fast that it only takes the blink of an eye to replace the whole of my parameter set. The use of LOAD and UPDATE for individual components is only something I have used when developing new scripts. You want to be careful about adding so much to the language that complexity makes errors creep in. Once a set of scripts is developed they tend to be quite static in a production environment. Commands like UPDATE are for people who have not been diligent in their development environment.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #21 
I agree. In production, scripts are rarely changed. In development, it is so quick, you just replace/update everything with LOAD PARMS. Perhaps if your environment was huge with many hundreds of SSIDs, then LOAD PARMS might take a significant amount of time.


__________________
zboxassist
0
Zamin

Avatar / Picture

Member
Registered:
Posts: 67
Reply with quote  #22 
I have more than 60 SSIDs a huge lot of messages, including private applications ones and hundreds of schedule items and I do not find the LOAD PARMS takes a lot of time. I get the impression the language translator is quite efficient.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #23 
I agree. I'll guess that it would take a Fortune 500 sized company with many hundreds of SSIDs, 10s of thousands of messages, etc. before the language translator would be noticeably slow.
__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #24 
Another possible new feature: XCF ARM Support.

I currently use ARM to monitor and restart our DB2s, IRLMs, RRSs, CDBSSs, TCPIPs, CICSs, WebSpheres, NETs, LDAPs, McKinney's subsystems JQPs, VVPs, and SWITCHs.
The majority of those have ARM support built-in. For those that do not natively support ARM, I use the ARM Wrapper. Since AutoMan does not support ARM, I'll have to see if it will work with the ARM Wrapper.

__________________
zboxassist
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #25 
Considerations for ARM

When we IPL, our AutoMan is started via parm member IEASYSxx option CMD=(AM,xx), where COMMNDAM contains:
COM='D T FROM COMMNDAM'
COM='START AUTOMAN,SUB=MSTR,REUSASID=YES,LOAD=IPLOAD'

When we manually start AutoMan, we use the following command
START AUTOMAN,SUB=MSTR,REUSASID=YES

In our AutoMan proc, the default value for &LOAD is LOAD and the default value for &SYSID is set to the same value as &SYSCLONE
&LOAD is used in the following DD:
//INPUT DD DISP=SHR,DSN=SYS5.AUTOMAN.PARMS(&LOAD&SYSID)

Therefore when AutoMan is started as part of an IPL, the INPUT DD contains options to start all of SSIDs, etc.
But when AutoMan is manually started, the INPUT DD contains options to just bring up AutoMan.

By default, ARM captures the start command to use as the restart command. Therefore depending on how AutoMan was started, ARM could capture either:
START AUTOMAN,SUB=MSTR,REUSASID=YES,LOAD=IPLOAD, or
START AUTOMAN,SUB=MSTR,REUSASID=YES
Therefore AutoMan should probably have another configuration option to overrider the default ARM restart command.

__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #26 
Restarting AutoMan after a failure is on the agenda for a future release. In addition to ARM to cause a restart there are other considerations. AutoMan could start normally and end normally. It could start normally then be halted by FORCE, or the whole system could fail simply stopping all processing. We are planning a record of its starting and stopping, so that when it starts it can know which of these 3 scenarios occurred last time. We are thinking that there could be some sort of user defined function that selects the kind of processing it is to perform on restarting. So if there was a complete system failure some sort of recovery and verification process could be run, or if it was FORCEd some sort of status verification cauld be performed.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #27 
Yes, ARM only restarts the address space. The address space needs to query ARM registration return codes to determine whether the address space is being started or restarted and why, then perform recovery as needed.
__________________
zboxassist
0
automan

Avatar / Picture

Moderator
Registered:
Posts: 136
Reply with quote  #28 
The suggestion about hyperswap and mirroring is something I played with a while back, and I have version of AutoMate that displays cross-system images of dasd and devices. It is going to take a lot of work to make full service hyperswapping a reality, but AutoMan does contain all of the capabilities to make it happen. Restart is really important in that kind of environment, so has to be in place first. The recording and report writing may not be exceptionally difficult to design. Many of the pieces for that probably already exist. I need to understand the SSID sections idea better so that I don't over complicate it. Also I need to understand multiple address spaces from one SSID better.
0
zboxassist

Member
Registered:
Posts: 89
Reply with quote  #29 
Since no other forum members commented on hyperswap and mirroring, I would hold off on that project since it would take a lot of work to make it full service, unless you have other customers who want/need that. Sadly my company is phasing out their mainframes. A couple of weeks ago, I powered one down and last week, they surplused it.
__________________
zboxassist
0
rakesh

Member
Registered:
Posts: 52
Reply with quote  #30 
Hi,

I came across this situation today.

Based on event/msgid, i have do delete a dataset. But when i tried DEL option from AUTOMAN, i got error stating unexpired dataset. So, i ended up submitting IDCAMS job with option PURGE to delete it.

Wouldn'tit be good to have all the differant options we have in IDCAMS in AUTOMAN DEL too?

Atleast the major ones, like PURGE,FORCE

Thank you
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!