Overview of ALCS/GI Debugger Architecture

ALCS/GI Debugger Architecture

• ALCS/GI Debugger is designed to work in Client – Server architecture

• The server component of the debugger is referred as ZAS

• Server component is installed in the zOS host• ALCS/GI is the client component which is

installed in PC • Client and server components communicate

over TCP/IP

ALCS/GI Debugger Architecture

ZAS Server

ALCS

MVS Services

ALCS/GI Client

MVS PC

ZAS Datasets

ZAS Server

• ZAS is started as a separate TCB when ALCS is bought up

• ZAS will be shutdown automatically when ALCS is bought down

• ZAS interacts with ALCS by internally triggering monitor ECBs using standard ALCS user exits

• ZAS interacts with MVS using authorized SVC calls

ZAS Interface with MVS

MVS Services

MVS

• RACF authentication• Memory management• TCB control• TCP/IP communication

ZAS Server

Interface with MVS

ZAS Interface with MVS

• ZAS uses core memory carved out from MVS

• APF authorization required for ZAS Load Library and SVC Load Library

• RACF Security update for ZAS libraries• SYS1.PARMLIB changes to make SVC

changes permanent• Port number to be reserved for each ALCS

system

ZAS Datasets

MVS

ZAS Datasets

• User ID table• Source-view dataset• Macro panel dataset• Trace dataset

ZAS Server Read / Write ZAS data set

ZAS Datasets

• Trace Terminal Table (TTT) – User terminal information

• CMSTPFCT & CMSTPFSF – Have the Source view control file and structure file

• PANELSFP & PANELSFT – Panels for ALCS application macros to be used in ALCS/GI

ZAS Interface with ALCS

ALCS

MVS• Start / shut-down ZAS Server• Load / Unload ALCS programs• Trace setup / commands• Input / output messages• Services to view core / file etc.

ZAS Server

Interface with ALCS

ZAS Interface with ALCS

• The main ZAS module – ZAS#ALCS – is available in the LOADLIB provided by us

• USERMODs provided for the changes done in ALCS monitor routines

• Changes done in ALCS exits are provided to be incorporated in customer place

• Changes required in ALCS startup JCL to start ALCS/GI also provided

ZAS User interface

• A TCB will be created when the user log-in• This user TCB will be detached when the user

session completes• User TCB invoked for every request from that

user• Terminal Control Area (TCA) describes the

status of the TCB• The User Trace Terminal Table (TTT) has

terminal information for all users of ALCS/GI• TTT is a common table referred by all TCA

ZAS User interface

ZAS Server

USER0001 C ………TCMD…………TMS1..

USER0002 C ………TCMD…………TMS1..

USER0003 D ………TCMD…………TMS1..

………….. D …….…TCMD………….TMS1.

Trace Terminal Table (TTT)

USER1

TCB

TCA<<<<<ZAS_TCA>>>>

USER2

TCB

TCA<<<<<ZAS_TCA>>>>

ALCS

ZAS terminals

• ALCS/GI client has four terminals– Two unique terminals that can be traced (TMS1 &

TMS2)– One command terminal (TCMD)– One terminal for asynchronous trace (TASY)

• ZAS server map each of these terminals to an internal “pseudo” terminal

• The “pseudo” terminal will be used by ZAS to interface with ALCS

ZAS pseudo terminals

ZAS Server

ALCS

TMS1

TMS2

TASY

TCMD

TTM1

TTM2

TTAS

TCMD

Asynchronous trace terminal

Command Terminal

Message Terminals

ZAS Trace Terminals ALCS/GI Terminals

ZAS pseudo terminals

ZAS Server

ALCS

TMS1

TMS2

TASY

TCMD

TTM1

TTM2

TTAS

TCMDOne CRI required

Two CRI’s required

ZAS Trace Terminals ALCS/GI Terminals

Two CRI’s required

One CRI required

Updates to ALCS monitor programs

• Following members of the ALCS control programs are updated for ZAS– DXCGTH – new user exit USRENBK is introduced– DXCINT – new user exit USRUTSK1 is introduced– DXCPGM – new user exit USRENBK is introduced– DXCCEXIT – Macro changed to introduce above new

user exits– DXCINTP – needs to be reassembled to make the

new user exits available for use

• The user mod required to update above members are provided in the installation file

Updates to ALCS user exits

• USRCOM4 – ROUTC/SENDC user exit– Message output sent to ALCS/GI terminals

• USRENBK – Program ENTER/BACK exit– Programs entered is check for source view trace

• USRTERM – ALCS termination– ALCS/ZAS was terminated when ALCS is coming

down

• USREXT – EXITC macro service extension– Clean-up ECB belonging to ALCS/GI

Updates to ALCS user exits

• USRGTIS – Instruction trace exit– Used to identify line in the source for the instruction

being executed during source view trace

• USRSVC – User requested monitor call– New SVC monitor call used for ALCS/ZAS– Monitor call number – 135

• USRUTSK1 – ALCS startup exit– Used to bring up ALCS/ZAS when the ALCS is

brought up

ALCS/ZAS Global trace

• ZASTRACE is a started task – Started when the first ALCS system is brought up with

ALCS/ZAS– The task can be stopped at any time from MVS console

• Records flow of control about users session– Messages from and to PC– Messages from and to ALCS– Function call / returns inside ALCSZAS module

• Data written to memory– A sample JCL is provided to dump data from memory to

a dataset

ALCS/GI Client

• ALCS/GI client installer is a standard windows installation file

• ALCS/GI can be configured to communicate with different ALCS systems

• ALCS/GI communicates with ZAS over TCP/IP

• ALCS/GI uses FTP to read files for Source View trace or any other files required

ALCS/GI Client

ALCS/GI Client

Menu bar and Tool bar

Source view trace

ECB Graphical view

ALCS/GI Terminal

ALCS/GI Installation requirement

Operating System Windows 2000 or Windows XP

Hard disk space 20 – 25 MB

Installation Type The install is a standard InstallShield process. An administrator must customize one INI file for the company and place them in a central location before other users install.

Folders Usage During the install, access is needed to the following folders:

C:\Program Files\TPF Software\ALCSGI

C:\Windows\System32

C:\Program Files\Common Files\TPF Software Shared

After the install, read/write access is needed to

My Documents\TPF Software\ALCSGI

(and subfolders). This is for normal operation of the application.

ALCS/GI Installation requirement

Registry Usage During the install, read/write access is needed both to

HKEY_CLASSES_ROOT

(for registering objects and applications) and to

HKEY_CURRENT_USER\Software\TPF Software\alcsgi

(for application data).

After the install, read/write access is needed to

HKEY_CURRENT_USER\Software\TPF Software\alcsgi

(and child keys). In addition, adequate read access is needed to

HKEY_CLASSES_ROOT

in order to access the applications and objects registered during installation. This is for normal operation of the application.

Dependencies Applications: Installation of zIDE is required.

Web or LAN: ALCS/GI dynamically reads from a central repository of configuration settings (INI files); therefore, a Web server or LAN location where the INI files are stored is required. A Web server is recommended for speed and ease of use.

ALCS/GI Installation requirement

Admin Rights The install requires Admin rights or sufficient security to install in the folders

C:\Windows\System32

C:\Program Files

C:\Program Files\Common Files

and in the Windows Registry areas normally required for an install.

Firewall, Router We connect to the zOS system server. Both FTP and TCP/IP are used. If the application is used outside the company (working from home), a VPN or Citrix-type solution is required.

Other DLLs Besides our DLLs stored in the folders

C:\Windows\System32

C:\Program Files\Common Files\TPF Software Shared

C:\Program Files\TPF Software\alcsgi

we do not depend on other DLLs except normal Windows DLLs.