programs. You can also leave the tests in your program and provide an UPSI constant in your COMRG macro that would always satisfy the tests.

∙The MVS macro instruction TIME provides the system date (Julian or

Gregorian) in a user work area. The date is in packed decimal digits, such as X′19980323′. For details, see the section ªGETIME Macroº on page 278. If

you modify the partition date with a //DATE card in the VSE JCL, you may have to simulate this option under MVS because only a single date is maintained for the entire MVS system.

∙In MVS, you can obtain the job name by using the EXTRACT macro and coding the parameter FIELDS=TIOT. You obtain the address of the TIOT (task input,output table) through this macro. This job name is located in the first eight bytes of the TIOT.

∙A less desirable technique would read the variable data from the operator console upon request.

If any other data is required from the COMRG macro, solutions will then have to be approached through manual procedures on an individual basis.

COMRG and MVCOM Macros

The VSE COMRG macro places the address of the communication region in register 1. The MVCOM macro modifies the user program communication bytes and the UPSI byte in the communication region. MVS does not have similar macros because it does not have a communication region (refer to the section 13.2.1.3, ªCommunication Regionº on page274).

LOAD Macro

The VSE LOAD macro causes the control program to bring in the phase specified in the first parameter and returns control to the calling phase. After execution of the macro, the entry-point address of the called phase is returned in register 1.

The MVS LOAD macro causes the control program to bring the load module containing the specified entry point into virtual storage if a usable copy is not available in virtual storage. The entry-point address of the load module is returned in register 0.

If the application program invokes the loaded program only once, you may substitute the MVS LINK macro for the VSE LOAD and CALL macros. The LINK macro must be used to invoke the SORT utility program.

If you do not want the application program to invoke the loaded program (a table, for example), you should use the MVS LOAD macro. In addition, the application program must reconcile the fact that the VSE LOAD will return the address in register 1 and MVS LOAD in register 0.

In either case, if the VSE program used the COMRG macro to determine the load point, it is not required because MVS automatically manages load module placement in storage.

Example:

(VSE)

LOAD

PROGB

LOAD the phase

LR

15,1

pass address

CALL

(15),parm1,parm2

invoke PROGB

Chapter 13. A s s e m b l e r 277

Page 300 Page 302
Page 301
Image 301
IBM OS/390 manual Load the phase, 15,1 Pass address, Call, 15,parm1,parm2 Invoke Progb
Page 300 Page 302

OS/390 specifications

IBM OS/390, a versatile operating system, was a cornerstone in enterprise environments and played a pivotal role in mainframe computing. Released in the mid-1990s, OS/390 combined the strengths of IBM's MVS (Multiple Virtual Storage) with new features and enhancements, targeting scalability, reliability, and performance in demanding business applications.

One of the key features of OS/390 was its robust support for multiple users and processes. The system allowed thousands of concurrent users to access applications and data, ensuring high availability and minimizing downtime—a critical requirement for many large organizations. This scalability was supported through various enhancements in memory management and processor scheduling, enabling optimal resource allocation across diverse workloads.

OS/390 was known for its superior workload management capabilities. The Workload Manager (WLM) component allowed administrators to define service policies, specifying how system resources would be allocated according to the priority of tasks. This ensured that critical business processes received the necessary resources while less critical tasks were managed more flexibly.

Another significant characteristic of OS/390 was its commitment to security. The operating system provided comprehensive security features, including user authentication, data encryption, and auditing capabilities. This focus on security was vital for organizations handling sensitive data, ensuring compliance with regulations and safeguarding against unauthorized access.

OS/390 also supported advanced technologies that facilitated integration and development. The system included features like the IBM CICS (Customer Information Control System) for transaction processing and IMS (Information Management System) for database management. These technologies allowed organizations to build robust, high-performance applications tailored to specific business needs.

The ease of network integration was another strength of OS/390. With the advent of the Internet and global connectivity, OS/390 systems could easily interface with various network protocols, enabling businesses to operate in a connected world. This inclusion paved the way for many organizations to expand their capabilities and offer new services, driving digital transformation.

In conclusion, IBM OS/390 represented a significant advancement in mainframe technology, combining scalability, security, and robust workload management. Its rich feature set and support for critical enterprise applications solidified its role as a vital component of many organizations' IT infrastructures, ensuring they could meet their operational challenges head-on while supporting future growth. As technology continues to evolve, the legacy of OS/390 remains influential in the realm of computing.
Top Page Image Contents