Brian, This is very generous. Thank you! Many folks here wouldn't see it though as you sent to the newsgroup rather than the listserv, so I'm passing it on via this reply.
In article <[email protected]> you wrote: > Let me start off by saying that I am a CICS Systems Programmer, but I enjoy > deep-diving into all aspects of the mainframe. My assembly knowledge is > mostly self-taught, and I've been writing assembler for almost 8 years. I'm > sure there is still plenty of room for improvement. I unfortunately (or maybe > fortunately) did not start my career in the 'golden age' of the mainframe. I > feel that that the resources and knowledge base for low-level system > programming are sparse. For example, learning how to write native 3270 was a > major challenge. > On my own time, I worked on a data collection tool that will transport CICS > data from CICS regions to a data collector STC through shared 64-bit storage > pools. Each remote address space will attach to a shared storage pool and > store information. To acquire access to a 64-bit shared area, the program > must be authorized. Since this is not an option for CICS tasks, the CICS task > calls an authorized PC routine to acquire access. One access has been > acquired, a CICS task can write to the storage area in problem state. > The started task hosts a service provider as an authorized PC routine and a > data writer. The data writer stores the records in the 64-bit pools to DASD > and submits a job to copy the DASD datasets to tape for long-term storage > when the DASD dataset is full (or when the STC is shutdown). > I do not work for an ISV, so I have no concern with sharing my work. However, > I spent an enormous amount of my own time on nights and weekends (before I > had kids). So, I completely understand why people are unwilling to freely > shared their code. The code works as intended, but is nowhere near production > quality. I'm hoping that sharing this code will also provide constructive > criticism and enhance my knowledge and code. The premise of the tool was > based off a well-known ISV monitoring product, but uses modern features to > transport the data. > Since I am a CICS Systems Programmer, I also wanted to write something that > behaves like CICS. The tool attaches and detaches subtasks that run > independently, supports a basic API that is mirrored from CICS (XCTL, START, > RETURN, SEND MAP, RECIEVE MAP, etc.) There is also a 3270 interface if > someone is interested. > Here are a few modules that I think are the most interesting and show > examples for shared 64-bit storage, PC hosting, PC calls, attaching and > detaching subtasks, and various system level processes. The tool is called > Scribe. > Here is a public folder on my Google Drive. > https://drive.google.com/open?id=1evL9RKDUOGNml-RGL83o0K7sW4xVsRQu > SCRIBE.txt > This is the jobstep program for the STC service provider and data writer. It > calls several routines to initialize the environment, establish the necessary > components for the PC routine, dispatch a subtask for data storage, and > communicate with the system console. This is the only non-reentrant program. > SCRBAUTH.txt > Authorized PC routine. This program executes in the STC and is invoked by the > remote address space with a linkage area describing the remote address space > and the request type The request types indicate if the request is for sharing > memory objects associated with the storage pool or freeing shared memory > areas already acquired. Each storage pool will consist of several memory > objects. > The tool keeps an 'access list' table of all acquired storage objects for > each address space. If the address space has already acquired the storage, > the request is ignored. I tried using the REQUEST=LIST function of IARV64 to > remove the need of the 'access list' table, but it did not work as I > expected... it was probably a user issue. > SCRBDSPI.txt > Subtask initialization. Attaches and detaches tasks. > SCRBDSPT.txt > Subtask termination. Before the subtask is detached, it cleans up and > necessary storage and removes itself from the kernel chain. > SCRBINLE.txt > Language Environment driver. Initalizes LE and branches to a COBOL program > (or other LE conforming programs). > SCRBINJB.txt > Reads a PDS member to build a table for job grouping for different storage > pool. > SCRBINDT.txt > Reads a PDS member to build the storage pool directory. > SCRBINCL.txt > Acquires the shared 64-bit areas for each storage pool. > SCRBWRTR.txt > There is a data writer for each storage pool. The data writer 'chases' the > data as it is written to the memory objects and stores the data to a DASD > dataset. The writer intercepts E37 and B37 abends, submits a job to the > internal reader, allocates a new DASD dataset, and continues writing. > SCRBSERV.txt > The program runs in the remote address spaces (CICS regions) to make calls to > the service provider (PC routine) for attaching and detaching the shared > 64-bit storage pools. > SCRBCICS.txt > Writes information to the shared 64-bit storage pools. When a memory object > of a pool is exhausted, it will then write to the next memory object. When > all memory objects are exhausted, it will wrap back to the first memory > object and overlay. > SCRBWTOD.txt > Generic WTO driver. Invoked with a linkage area describing the WTO > identifier, and a series of parameters. The program searches the message > table for an identifier match and replaces the symbolic keywords with linkage > parameters passed by the caller. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [email protected] (919) 531-5637 Cary, NC 27513 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
