Card Format:
1 - 7
Constant 'MSKPRT '.
8 - 10
Mask (SHD) Number.
12 - 80
Blank.
Control card example:
MSKPRT 001
MSKPRT Jobstream
**
VSE
**
* $$ JOB JNM=MSKPRT,CLASS=F
*** $$ PRT CLASS=V
// JOB MSKPRT
// EXEC PROC=MAGECLIB -pvt. libs & DLBL's for dictionary
// ASSGN SYS006,SYSIPT
// ASSGN SYS007,SYSLST
// EXEC MSKPRT,SIZE=(AUTO,20K)
MSKPRT mmm
/*
/&
* $$ EOJ
z/OS
**
//MSKPRT JOB CLASS=_,MSGCLASS=_
**//STEP1 EXEC PGM=MSKPRT
//STEPLIB DD DSN=MAGEC.LOADLIB,DISP=SHR
* * * * * * * * DD's for dictionary files
//SYSOUT DD SYSOUT=W
//SYS007 DD SYSOUT=W
//SYS006 DD *
MSKPRT mmm
/*
//
PC
**
Edit, as necessary, the control cards found in your local drive (LCLDRV) in the file named:
\MAGMF\MSKPRT.RDR
At the prompt, enter:
MSKPRTEX
#
TBLLIST
##
List MAGEC Lookup Tables
The batch utility program TBLLIST may be used to produce a hardcopy listing of any MAGEC Lookup Table(s) from the MAGEC (cont.)
TBL file. It accepts a control card to indicate which Table(s) are to be listed. More than one control card may be (cont.)
input to any one run.
##
TBLLIST Control Cards
Columns
Description
Card Format:
1 - 8
Constant 'TBLLIST '.
9 - 11
Starting Table Number. (must be numeric)
12
Constant ' - ' or blank.
13 - 15
Ending Table Number. (must be numeric or blank)
Control card example:
TBLLIST 001-999
TBLLIST Jobstream
**
VSE
**
* $$ JOB JNM=TBLLIST,CLASS=F
*** $$ PRT CLASS=V
// JOB TBLLIST
// EXEC PROC=MAGECLIB pvt libs & DLBLs for dictionary
// ASSGN SYS006,SYSIPT
// ASSGN SYS007,SYSLST
// EXEC TBLLIST,SIZE=(AUTO,20K)
TBLLIST xxx-yyy
/*
/&
* $$ EOJ
z/OS
**
//TBLLIST JOB CLASS=_,MSGCLASS=_
**//STEP1 EXEC PGM=TBLLIST
//STEPLIB DD DSN=MAGEC.LOADLIB,DISP=SHR
* * * * * * * * DD's for dictionary files
//SYSOUT DD SYSOUT=W
//SYS007 DD SYSOUT=W
//SYS006 DD *
TBLLIST xxx-yyy
/*
//
PC
**
Edit, as necessary, the control cards found in the file named:
\MAGMF\TBLLIST.RDR
At the prompt, enter:
TBLLISTX
#
APUNLOAD
##
Unload an Application
The APUNLOAD jobstream is used to unload a complete MAGEC application for transporting or transmitting to another MAGEC (cont.)
system whether on the same CPU or on another. It is not necessary for the two systems to be operating in the same (cont.)
environment as one another. You may copy an application developed and running on a DOS/VSE WESTI MAGEC system to an (cont.)
z/OS CICS system, for instance. Unless you have seriously violated the recommended standards for developing (cont.)
applications there should be no coding changes required, just a "re-compile" on the target system.
To copy an application from one system to another you must do three steps:
APUNLOAD Unload it from the source system.
**APLOAD Load it onto the target system.
MMPCREAT Regenerate and compile on target system.
When you unload an application from the source system it is not removed from that system. Unloading is simply a process (cont.)
of reducing all the pertinent Dictionary data, including Customization Algorithms, Data Definitions, and Documentation, (cont.)
into 80-column card images which may be transmitted via RJE or passed from one system to another via a disk file or (cont.)
queue file or "link" in order to enable loading onto the other system. The same application will then operate on both (cont.)
systems. Transferring applications from ASCII to EBCDIC and vica-versa are supported since any "packed", binary, or (cont.)
hexadecimal fields are automatically decoded for transfer. It is also possible to rename an application as it is being (cont.)
loaded to the target system.
##
Portability
In order to ensure the "Portability" of your applications you must avoid using any techniques in your Customization (cont.)
which will not work the same way on any potential target system. For instance, if you are developing applications on a (cont.)
MAGEC CICS system which are to be used also on a MAGEC WESTI system, then you must not use CICS-only commands in your (cont.)
Customization (ie: SERVICE RELOAD, EXEC CICS, etc.) since they will not work the same way under WESTI. MAGEC provides (cont.)
"service routines" in the generated MMP's to handle all necessary commands; your Customization coding should PERFORM (cont.)
those built-in routines so that MAGEC can resolve the differences between environments.
The APUNLOAD jobstream consists of one step:
APUNLOAD
Unload an application definition or other dictionary data.
##
Verifying Output
A tabular statistical report is produced which indicates what types of dictionary data (and how many records of each) (cont.)
were unloaded. This report can be matched to a similar report produced by the APLOAD program when the data is loaded to (cont.)
the target system.
##
Control Cards
There are nine possible control cards accepted into the APUNLOAD utility program. They are:
Card 1
APLOAD control card - APUNLOAD simply passes this card on to the output stream where it will be found by APLOAD at the target system.
Card 2
APUNLOAD control card - indicates the MSK # (application identity) to be unloaded and also allows you to skip the (cont.)
unloading of some of the Dictionary files, if desired. A value of "NULL" may be used here when you wish to unload (cont.)
dictionary data (i.e. library members, default code, error messages, lookup tables, data definitions, domains, etc.) (cont.)
without unloading any particular application
Card 3
ERR number card - indicates a range of MAGEC ERR file records which are to be unloaded with the application. There may be more than one of these cards.
Card 4
TBL number card - indicates a range of MAGEC TBL file records to be unloaded along with the application. There may be more than one of these cards.
Card 5
Library Member card - indicates the name of a library member (usually a copybook) to be unloaded along with the application.
Card 6
Default Code card - indicates that a Default Algorithm is to be unloaded along with the rest of the Dictionary data.
Card 7
Data Definition card - indicates a Data Class whose entire definition is to be unloaded
Card 8
Domain card - indicates a Domain or range of Domains to be unloaded
Card 9
RENAME card - if present this card must immediately precede the APLOAD card (card 1). It enables you to unload an (cont.)
application and to have it reloaded under a different application name (MMP number or MBP number).
Control card 1 and 2 must be the first two cards into APUNLOAD. They are both required cards. The other cards are (cont.)
optional, they enable you to copy over your "copybooks" or Library routines from the source system and to copy over any (cont.)
ERR or TBL file entries which are needed for the application being unloaded. *You can unload multiple applications in a (cont.)
single run of APUNLOAD by using multiple control cards 1 and 2.* If you omit card 1 and only input card 2, APUNLOAD (cont.)
will automatically generate a card 1 for you.
The copybooks for the Elements accessed by your application (both from the primary Data Class, and from joined Data (cont.)
Classes) will automatically be copied for you, you need not code a control card to unload them. The DIT definitions for (cont.)
them will be unloaded, as well.
The APLOAD control card is not actually used by the APUNLOAD program, it is simply placed into the output stream so (cont.)
that APLOAD will be able to identify which application is to be loaded. It serves as one of the many "cross-checks" (cont.)
built into the APUNLOAD/APLOAD process to ensure that data is copied accurately from the source to the target system. (cont.)
That is very important when RJE communications are involved but it is also important even when transferring an (cont.)
application between two systems running on the same CPU.
In order to accommodate transferring from EBCDIC to ASCII (as in IBM mainframe to PC) and vice-versa, the APUNLOAD (cont.)
program will expand all binary and packed numeric data to zoned-decimal; the APLOAD program will convert it back. This (cont.)
is because the character conversion algorithms in most "link" packages would corrupt binary or packed data in the (cont.)
translation.
##
Pseudo JCL into APUNLOAD
In the DOS environment it is sometimes useful to have APUNLOAD put its output onto the POWER punch queue with a (cont.)
disposition=I so that it is immediately "turned around" as an input "reader queue" stream. To support that, APUNLOAD (cont.)
will accept pseudo JCL in its input stream and will convert it into real JCL and pass it through to the output stream. (cont.)
If disposition=I is specified on the POWER punch control card then the punched output will immediately execute. The (cont.)
punched output would be an APLOAD execution to load the unloaded application. You might use the job class or a (cont.)
different PROC defining the Dictionary files and system libraries to direct the APLOAD to load onto one system or (cont.)
another.
next: util13.md.txt