Re: LE-compliant assembler program with 'instance-storage'.
In [EMAIL PROTECTED], on 03/06/2008 at 09:57 AM, Fred van der Windt [EMAIL PROTECTED] said: This poses no problems in most situations but sometimes we would like to maintain a 'state' in a program that is saved between different calls to the program within a transaction. Isn't there an additional problem in CICS with pseudoconversational transactions? I suspect that your code will have to be CICS aware. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE-compliant assembler program with 'instance-storage'.
On Thu, 6 Mar 2008 09:57:00 +0100, Fred van der Windt [EMAIL PROTECTED] wrote: This poses no problems in most situations but sometimes we would like to maintain a 'state' in a program that is saved between different calls to the program within a transaction. This would be similar to COBOL WORKING-STORAGE variables (as opposed to COBOL LOCAL-STORAGE variables that behave exactly like the temporary variables on the LE stack in the assembler programs) that are saved between different calls to the program under the same transaction instance while different transactions instances under CICS have there own copy of this storage. I don't know how to achieve this behaviout in a LE-compliant assembler module... Why not simply have your LE compliant assembler module call a COBOL subprogram that saves the data in its WORKING-STORAGE Static linkage. The data in the WORKING-SToraGE should persist for the life of the Enclave. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE-compliant assembler program with 'instance-storage'.
Why not use LE heap storage? Do a call to CEECRHP to create a heap, then call CEEGTST to allocate an element in the heap. Save the address of the element in one of the two LE-provided user fields (call CEE3USR). This heap storage is accessible by all programs in the run unit, and persists across subroutine calls. I know about CEE3USR but never really understood how one could safely use that field. After all, if I can come up with the idea to store my anchor in that field somebody else might do it too. And then one of us is in trouble. Probably both of us... Is there a 'best practice' for the use of this field...? It would be a convenient place to anchor an application-owned tree of control blocks if it wasn't for the risks described above... ad /ad I was waiting for that 8-) We are well aware of LE services: we use them a lot in COBOL and Assembler programs. We would be interested in other classes but are stationed in the Netherlands and could never fill a classroom. A collegue of mine wants to follow some Assembler courses but IBM in the Netherlands keeps cancelling them because there just isn't enough interest in these courses... So if you ever do any in this part of the world: I've got one or two customers for you... - ATTENTION: The information in this electronic mail message is private and confidential, and only intended for the addressee. Should you receive this message by mistake, you are hereby notified that any disclosure, reproduction, distribution or use of this message is strictly prohibited. Please inform the sender by reply transmission and delete the message without copying or opening it. Messages and attachments are scanned for all viruses known. If this message contains password-protected attachments, the files have NOT been scanned for viruses by the ING mail domain. Always scan attachments before opening them. - -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: LE-compliant assembler program with 'instance-storage'.
Fred van der Windt wrote: I have a question about LE-compliant assembler programs: at our shop we only write LE-compliant assembler programs.The programs must be able to run in every environment used in the company: MVS batch, IMS and CICS. Programs created using the LE-provided macros (CEEENTRY, CEEDSA, CEEPPA et al) normally allocate extra space on the LE-stack for temporary variables. They cannot contain a WSA (Writable Static Area) because that would make them non-reentrant and makes it impossible to use them in a CICS transaction. This poses no problems in most situations but sometimes we would like to maintain a 'state' in a program that is saved between different calls to the program within a transaction. This would be similar to COBOL WORKING-STORAGE variables (as opposed to COBOL LOCAL-STORAGE variables that behave exactly like the temporary variables on the LE stack in the assembler programs) that are saved between different calls to the program under the same transaction instance while different transactions instances under CICS have there own copy of this storage. I don't know how to achieve this behaviout in a LE-compliant assembler module... I looked at PSECTs but I am not sure if this is the solution to this problem or how to use them in a mixed language environment (COBOL, PL/I and assembler). Can anybody give nme a clue how I can create and manage my 'instance-storage'? Thanks, Fred! Why not use LE heap storage? Do a call to CEECRHP to create a heap, then call CEEGTST to allocate an element in the heap. Save the address of the element in one of the two LE-provided user fields (call CEE3USR). This heap storage is accessible by all programs in the run unit, and persists across subroutine calls. The related services are avaialable to all your high level and LE-compliant Assembler programs. ad Sounds like you could use these classes at your place: Using LE Services in z/OS - 3 days; multilingual (Assembler, COBOL, PL/I, C); check out: http://www.trainersfriend.com/Language_Environment_courses/m512descr.htm and this would seem to be useful: Secrets of InterLanguage Communication in z/OS (3.5 days); multilingual; check out: http://www.trainersfriend.com/Language_Environment_courses/m520descr.htm /ad Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Classes in Europe (was: Re: LE-compliant assembler program with 'instance-storage'.)
Fred van der Windt writes: I know about CEE3USR but never really understood how one could safely use that field. After all, if I can come up with the idea to store my anchor in that field somebody else might do it too. And then one of us is in trouble. Probably both of us... Is there a 'best practice' for the use of this field...? It would be a convenient place to anchor an application-owned tree of control blocks if it wasn't for the risks described above... Well, it has to be agreed upon in the design: who owns field-1 or field-2; Also note that one of the fields could point to an array of pointers to storage, each belonging to specific programs. In any case, agreement in design is paramount. Realize that the user fields are per enclave, not global among all LE users in the system: each enclave gets a pair of user fields to share among its mainline and subroutines. --- And also: We are well aware of LE services: we use them a lot in COBOL and Assembler programs. We would be interested in other classes but are stationed in the Netherlands and could never fill a classroom. A collegue of mine wants to follow some Assembler courses but IBM in the Netherlands keeps cancelling them because there just isn't enough interest in these courses... So if you ever do any in this part of the world: I've got one or two customers for you... I know you're in the Netherlands. No problem. We've taught our LE class in Denmark and Sweden in the past. We would love to come teach in Holland. We don't need large enrollment numbers; we charge by the class day and include expenses. Let's take this discussion off-list and see what we can put together. --- Martin also writes: Steve, looks like I need that class too. Again, let's take this off-list; but anyone else in Europe on the list interested in exploring this, please drop me a line. We might easily have enough to justify several classes in various cities. Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
