Introduction:


You must create one �global� configuration file. In this file, you code statements to customize the application to suit your installation's needs. This document refers to such statements as either configuration statements or global configuration statements. There are many configuration statements. Some configuration statements, such as VTAM_ACB, are always required while others may or may not be required, depending on the platform and/or selected functions.  Further more, most global configuration statements have reasonable defaults.  


A.   What to name  global config file and where to save it?
B.   File characteristics.
C.   Coding rules and syntax.
D.   Global configuration statements (table).
E.   Description of global configuration statements.


A. What to name the global config file and Where to save it:

        
You may give it any name and save it where ever you want as long as you
      follow these guidelines



VSE Platform:

     
Save the global configuration member in a suitable sublibrary.






       Choose any suitable
member_name.member_type.
       The default for
member_name.member_type is GLOBAL.IBCCFG.
      
THERE IS ABSOLUTELY NO DEFAULT FOR  LIB.SUBLIB!



 



     You must pass
LIB.SUBLIB(member_name.member_type) to
      the application as follow:

      // EXEC IBCMAIN,PARM='LIB.SUBLIB(GLOBAL.IBCCFG)',DSPACE=2M

      If you wish to implicitly pass the default
member_name.member_type
       (GLOBAL.IBCCFG)
, then code the JCL card as follows:

     
// EXEC IBCMAIN,PARM='LIB.SUBLIB',DSPACE=2M

     
But this is rather cryptic. We suggest you explicitly pass
     
member_name.membe_type even if it happens to be the default.














B. File characteristics:

Must be Fixed, 80-byte record format.  Case insensitive.  All statements are up-shifted before processing.


C: Coding Rules and Syntax:

1) A blank line is treated as a comment.
2) A line whose first non-blank character is an asterisk, *,  is also treated as a comment.
3) One configuration statement per line. A2E and E2A are exceptions. These two configuration statements
     allow multiple values per line.
3) Side comments are acceptable, as long as they are separated from the value by at least 2 blanks.
4) Each configuration statement has a minimum abbreviation. Once the parameter is recognized, everything
    to the left of the equal sign (=) is ignored. For example, AD THE BIG GUY = xyz,scope=* and
    Admin (finance dept) = xyz,scope=* are, as far as the application is concerned, identical.
5) Duplicate configuration statements, if any, are ignored. The last-encountered configuration statement
    determines the actual value used.   ADMIN, USER, HOST, TCP_HOST, A2E, E2A, TAPE-DRIVE,
    and FTP_LIBR_MEM_TYPE statements are exceptions. These statements accumulate, rather than
     replace, values.
6) Configuration statements apply to all platforms, unless explicitly stated otherwise.
7) Generally speaking, all SWITCHES should be the very first statements in your configuration file,
     especially the security switch, SWITCH_SECURITY. HOST and USER statements are ignored, if you
     specify SWITCH_S = EXTERNAL.


D. Global Config Statements (table):

The following is a table of all valid global configuration statements:



















































































E.  Description of global configuration statements:

SWITCH_Security interface


Purpose:     Determines who authorizes USER/HOST logins/logouts (security exit function code 0, 4, and 8 only).  The security exit is
                ALWAYS invoked for file authorization (function 12, 16, 20 or 24).  These functions are not controlled by this switch at all.

                 Coding SWITCH_S = LOCAL basically tells the application to use the tables generated by USER and HOST config
                 statements. If the correct ID is found, login proceeds.

                 Coding SWITCH_S = EXTERNAL, on the other hand, instructs the application to invoke the security exit.  It is up to the
                 security exit to accept (by returning 0 code) or reject (by returning non-zero code) the login. The application, in this case,
                 does not build HOST/USER tables, and, in fact, rejects HOST/USER config statements.

Default:           LOCAL.
REQUIRED:    NO
Example:        SWITCH_S  = LOCAL 

SWITCH_Tape overwrite expired

Platform: VSE only.

Purpose:  Enable/disable expired tape volume over-write. Applies only to NON-TMS (FM? N), non-blank, standard labeled output tapes.

              If enabled (SWITCH_T = YES), the file gets written as the FIRST file on the volume, thus erasing previous file(s).
              If disabled (SWITCH_T = NO), on the other hand, the file gets written (STACKED) after the last file on the volume.

Default:              Enabled.
REQUIRED:       no
Example:           SWITCH_TAPE = NO  


SWITCH_Vsam files support


Purpose:          Enable/disable VSAM file transfers.
Default:           Enabled.
REQUIRED:    no
Example:         SWITCH_VSAM ACCESS METHOD  = YES 


SWITCH_General activity trace


Purpose:  Enable/disable internal activity tracing.  The enabled status is useful for debugging purposes only.  If turned on,
              huge amounts of data is generated to the SYSLST (VSE).

Default:         Disabled.
REQUIRED:  no
Example:      SWITCH_G  = YES 

SWITCH_Wto activity to console

Purpose:  Enable/disable internal activity tracing to system console. The enabled status is useful for debugging purposes only.
              A large number of WTO's is generated if this switch is turned on.

Default:            Disabled.
REQUIRED:     no
Example:          SWITCH_W  = YES 

SWITCH_User interface trace


Purpose:  Enable/disable user activity tracing.  The enabled status is useful for debugging purposes only.
              If turned on, huge amounts of data is generated to the SYSLST (VSE).

Default:              Disabled.
REQUIRED:        no
Example:            SWITCH_U  = YES 



SWITCH_Dbase trace activity

Purpose:  enable/disable VSAM DBase activity tracing. The enabled status is useful for debugging purposes only.
              If turned on, huge amounts of data is generated to the SYSLST (VSE).

Default:            disabled.
REQUIRED:     NO
Example:          SWITCH_DBASE TRACE  = YES 



SWITCH_IP

Purpose:           enable/disable TCP/IP stack support.
Default:            disabled.
REQUIRED:     Yes, for TCP/IP File transfer and FTPservers.
Example:           SWITCH_IP = YES 

SWITCH_FTP_SERVER_SUPPORT

Purpose:         enable/disable FTP server function.
Default:          disabled.
Example:         SWITCH_FTP_SERVER_SUPPORT  = YES  


SWITCH_FTP_SERVER_UID_PWD_FOLD

Purpose:           enable/disable User ID and password folding.
Default:            YES
Example:  SWITCH_FTP_SERVER_UID_PWD_FOLD  = YES  


SWITCH_FTP_SERVER_PORT

Purpose:  enable/disable the PORT command. Be careful: Most FTP clients use the PORT command for communications.
              If you disable it, these clients will not work. You may disable PORT if you know that all clients talking to this FTP server
               use the PASV command.

               If you are not sure what this means, then please enable the PORT command.

Example:  SWITCH_FTP_SERVER_PORT = YES  * enable PORT command.   



Default LOGMODE

Purpose:  Provide a global VTAM logmode for file transfer sessions. It must be suitable for LU6.2 sessions. You can, however,
              override it on a host per host basis if you code the appropriate host configuration (host profile) file.

DEFAULT:  none.
Example:    DLOGMODE (global default APPC logmode) = IBMRDB 


Vtam acbname

PURPOSE:  Tells the application about ACBNAME that represents this application. It must not exceed 8 bytes.
DEFAULT:  IBCFTF
Example:     VTAM ACBNAME (prod copy) = IBCFTF


USER

Purpose:  Identify the user IDs who are allowed to logon to the application, including the FTP server function. User ID and Password
               must not exceed 8 bytes, each.

REQUIRED: Not required if your security switch (SWITCH_S) is set to EXTERNAL. IF SWITCH_S = LOCAL, then you must code it.

EXAMPLE:  USER = MAGIE,PWD=BABY
                  USER = BART,PWD=SYMPSON


ADministrator

Purpose:  Identify your administrators and their scopes. The Admin ID must not exceed 8 bytes. The scope must be terminated
               with a * (means ignore whatever follows). The percent char "%" means ignore this character.

              Administrators must be defined as users as well.  See USER configuration statement.

REQUIRED: NO
DEFAULT:  If not coded, ALL users are GLOBAL administrators (i.e. all users have the scope of *.
                  The * scope is the see-and-do all scope).

Example:     ADMIN (The global dudette) = MAGIE,SCOPE=*
                  Admin (Another global dude) = BART,SCOPE=*
                  ADMIN (global admin for accounting) = ACNTUSR1,SCOPE=ACNT%U*
                  ADMIN (subset admin for accounting) = ACNTUSR2,SCOPE=ACNTUS*


HOST

Purpose:  Identify all partner (remote) hosts you want to speak with through APPC.
              This is the remote's Netname, to specific. It must not exceed 8 characters.

             All Host names coded here and on the TCP_HOST statements must be Unique.  If you want to reach a particular host
             through APPC and TCP/IP then it must have two unique names: a Netname and an IP alias name.

REQUIRED: Not required if your security switch (SWITCH_S) is set To External. IF SWITCH_S = LOCAL, then you must code it.

DEFAULT:  None.

EXAMPLES:   HOST = HONGKONG speak with our Hongkong  data center.
                     HOST = NEWYORK  and with our trading partners in Newyork. 




POWER_PWD


Platform: VSE

PURPOSE:  Grant the application unlimited access to POWER queues.

REQUIRED: You must code it if you have genned POWER with a password.

DEFAULT:  blanks (none)

EXAMPLES:  POWER_PWD = xyz



POWER_MONITOR_QUEUE

Platform: VSE
PURPOSE:   Define the queue(s) you want to monitor for automatic transfers (File Transfer function only)
REQUIRED: You must code it if you want to use the Auto-Queue Monitor
DEFAULT:   Do not monitor POWER queues.

EXAMPLES:     POWER_MONITOR_QUEUE = LST
                       POWER_MONITOR_QUEUE = PUNCH



IP_ID


PURPOSE:  Identify the TCP/IP partition (VSE) you want the application to communicate through. Applies to both file transfer
                   and FTP server components.

REQUIRED: Yes if you include TCP/IP or the FTP server support. Otherwise NO.

DEFAULT:  VSE: 00

EXAMPLES: IP_ID = 00 



IP_TIMEOUT

PURPOSE:  Define TCP/IP timeout in minutes. Applies to both file transfer and FTP server components.

DEFAULT:  10 minutes.

EXAMPLES: IP_TIMEOUT = 10  


TCP_LISTEN_PORT


PURPOSE:  Identify the port you want the file transfer component to listen at for incoming connections.

REQUIRED: Yes if you include TCP/IP support. Otherwise NO.
DEFAULT:  None.  You must choose a port.  Furthermore, you must tell all remote partners about this port if need be.  


TCP_HOST

PURPOSE:  Identifies remote internet addresses (hosts) you want the file transfer component to speak with, and assigns them
                 host names (aliases). 

                  All host names coded here and on the HOST statements must be Unique. If you want to reach a particular host through
                  APPC and TCP/IP then you must give it two unique names. One exception to �unique naming� requirements may apply
                  to multi homed hosts. In this case, you may have to duplicate the IP alias ..but not the IP address.

                  Please notice that the application�s users refer to IP hosts by names. Therefore, you have to propagate names you assign
                  here to concerned users.  Users do not have to know  actual IP addresses. Just names!


REQUIRED: YES even if SWITCH_S is set to EXTERNAL.

DEFAULT:  none.

Format:   IP_HOST = aa.bb.cc.dd,PORT=nn,NAME=cccccccc,TYPE=xx

              The first token, aa.bb.cc.dd, is the IP (internet) address of the remote IP host.
              PORT must be the port the remote host is listening at. You get this number from the remote�s host administrator.
                        It is the same value coded in the TCP_LISTEN_PORT in the remote host global configuration file.
               NAME any string of characters (up to 8).
               TYPE = XFER

EXAMPLES        IP_HOST = 172.19.73.2,PORT=314,NAME=IPNYORK,TYPE=XFER
                         IP_HOST = 192.13.41.5,PORT=66,NAME=TESTVSE,TYPE=XFER



FTP_LISTEN_PORT


PURPOSE:  Identify the port you want the FTP server component to listen at for incoming   connections. 
REQUIRED: Yes if you include FTP server support. Otherwise NO.
DEFAULT:  259. Furthermore, you must tell all remote FTP clients  about this port in order to connect
    to this FTP server.  

EXAMPLES: FTP_LISTEN_PORT = 259



FTP_32K_BUFFERS

Purpose: Define number of 32K I/O buffers for each FTP Upload or Download.
Default:   8
Example FTP_32K_buffers = 32


 
FTP_LIBR_MEM_TYPE


PURPOSE:  Identify all LIBR member types you wish the FTP server to ALWAYS FTP in BINARY mode.  lease code one statement
                  per member type.  Repeat the statement for as many times as you need.

Format:         FTP_LIBR_MEM_TYPE = mem_type,RECF=rec_format

REQUIRED: Yes if you include FTP server support. Otherwise NO.

DEFAULT:  none.   

EXAMPLES:    FTP_LIBR_MEM_TYPE = OBJ,RECF=FIXED
                      FTP_LIBR_MEM_TYPE = JPG,RECF=STRING
                      FTP_LIBR_MEM_TYPE = JIF,RECF=STRING        



NUM_USER_SESSIONS

Purpose:  Define the max. number of simultaneous user (3270) sessions you wish to support.

REQUIRED: No. If not coded a default of 5 is assumed.
DEFAULT:  5           

EXAMPLES:       NUM_USER_SESSIONS = 20 support up to 20 simul. 3270 sessions.




NUM_HOST_SESSIONS


Purpose:  Define the max. number of simultaneous remote partners you wish to talk with (File Transfer Partners and FTP client
               partners). Each unique partner requires one session block while active.  

REQUIRED: No. If not coded a default of 5 is assumed.
DEFAULT:  5           

EXAMPLES:    UM_HOST_SESSIONS = 10 support up to 10 simul. host sessions.



NUM_XFER_SESSIONS

Purpose:  Define the max. number of simultaneous file transfer  conversations you wish to support.

              File Transfer component: Each active file transfer requires one block.  If you are currently sending 3 files to XYZ, and
              rcving 2 files from the same partner, then you need a total of 1 HOST session blocks, and a total of 5 XFER session blocks.
             This is why this value must be a bit larger than the value of the NUM_HOST_SESSIONS.

             The FTP server component: Each client connection requires TWO (2) blocks.


REQUIRED: No. If not coded, default of 20 is assumed.
DEFAULT:  20            

EXAMPLES:   NUM_XFER_SESSIONS = 30 support up to 30 simul. xfer sessions.



NUM_WORK_BUFFERS

Purpose:  Define the number of work buffers the application should allocate.  Each buffer is exactly 136-byters long.  These are
               mostly used for internal activity tracing and WTO purposes. If you experience too many "MSG DROPPING" then increase
               this value.

REQUIRED: No. If not coded, default of 100 is assumed.
DEFAULT:  100

EXAMPLES:       NUM_WORK_BUFFERS  = 30


NUM_END of OBJECT BUFFERS

Purpose:  Define the number of End-of-object buffers the Application should allocate.  Each buffer is exactly 136-bytes long.
             These buffers are used for operator-stared objects, end of object activities, and other purposes as well.

REQUIRED: No. If not coded, default of 30 is assumed.
DEFAULT:  30           

EXAMPLES: NUM_END_OF OBJECT_BUFFERS  = 50


NUM_SCREEN_DEPTH

Purpose:   Define the max number of screens to build while viewing dbase/History files. 
               This limit does not apply while viewing in-storage transfers (Options A, B, C, or H).

REQUIRED: No. If not coded, default of 30 is assumed.
DEFAULT:  30

EXAMPLES: NUM_SCREEN_DEPTH  = 30


NUM_LINE_PER_SCREEN

Purpose:  Define the max number of object entries per screen.  The abs. max is 6 and the abs. minimum is 1.
             This is really a debug switch and you should always code 6. But you can change it, just for the heck of it.

REQUIRED: No. If not coded a default of 6 is assumed.
DEFAULT:  6           

EXAMPLES: NUM_LINE_PER_SCREEN  = 6 



NUM_REPORT_PAGE_LEN

Purpose:  Define the max number of object entries per report page. The abs. max is 19 and the abs. minimum is 1.
              This is really a debug switch and you should always code 19. But you can change it, just for the heck of it.

REQUIRED: No. If not coded a default of 19 is assumed.
DEFAULT:  19           

EXAMPLES: NUM_REPORT_PAGE_LEN  = 19 


NUM_JOB_MAX_MINUTES

Platform: VSE (Job Execution Monitor, JEM, function)
Purpose:  Defines the max number of minutes to monitor job execution. The utility drops the entry from monitoring after
              this number Of minutes.

REQUIRED: No. If not coded a default of 20160 (14 days) is assumed.

DEFAULT:  20160 (14 days)            

EXAMPLES: NUM_JOB_MAX_MINUTES = 60 minutes. 



A2E

Purpose:  Modify the application�s  ASCII-to-EBCDIC translation table. 

REQUIRED: No.
DEFAULT:  Standard ASCII to EBCDIC table.
EXAMPLES:

A2E = 30:F0|31:F1|32:F2|33:F3|34:F4|35:F5|36:F6|37:F7|38:F8|39:F9 |


E2A

Purpose:  Modify the internal EBCDIC-to-ASCII translation table.
REQUIRED: No.
DEFAULT:  Standard EBCDIC to ASCII table.
EXAMPLES:

E2A = F0:30|F1:31|F2=32|F3=33|F4=34|F5=35|F6=36|F7=37|F8=38|F9=39 |




Tape drive

Platform: VSE.
Purpose:  Define the tape drives you wish this application to Consider for those tapes that are NOT under the control of
              a Tape Management System (TMS). The assignment of tape drives for TMS files is the responsibility of the TMS.

Default:  None.

Format:   TAPE = CUU=xxx,MODEL=mmmm,TYPE=tttttttt

              CUU:   The tape drive address. The value must be exactly 3 characters long.

              MODEL: specify the model such as 3410, 3420, 3480, 3490, etc. The value must be exactly 4 characters long.

             TYPE:  specify one of three key words: TAPE, TAPE-9T or TAPE-7T (for Reel tape drives), CART (3480 or 3490 devices)
                         or OTHER (for other drives). Here, you basically group multiple (and possibly different models) under the same
                        category. Needless to say, if you group different models under the same category, then you must be sure that you ask
                         the application to only use the functionality that is common to these different drives. For example, if you group 3480's
                         and 3490's (with IDRC) under CART, then you  should not specify IDRC.


            Reel tape drives:  Pease tell the application whether it is a 7-track or 9-track device Reel drives are, by default, considered
                                      to be 9-track drives. Therefore, TAPE or TAPE-9T are both accepted ways to tell the application that the
                                     drive is a 9-track device. If the drive is a 7-track drive, you must tell the application so by coding TAPE-7T
                                      in the TYPE field.

Examples:

TAPE DRIVE = CUU=380,MODEL=3420,TYPE=TAPE     (default is TAPE-T9)
TAPE DRIVE = CUU=381,MODEL=3420,TYPE=TAPE-T9  (explicit)
TAPE DRIVE = CUU=382,MODEL=3410,TYPE=TAPE-T7  (must be specified).
TAPE DRIVE = CUU=383,MODEL=3410,TYPE=TAPE-T7

TAPE DRIVE = CUU=780,MODEL=3480,TYPE=CART
TAPE DRIVE = CUU=781,MODEL=3480,TYPE=CART
TAPE DRIVE = CUU=790,MODEL=3490,TYPE=CART
TAPE DRIVE = CUU=791,MODEL=3490,TYPE=CART

Notice that the user can ask the application to ASSIGN tape drives by entering CUU, MODEL or TYPE in the UNIT field in the file transfer definition screen (File Transfer Component) or in the File View (FTP server Component) as follows:

CUU assignment MUST be used if the drive is pre-loaded with the correct tape(s). The application does NOT issue a WTOR to the operator. This behavior is intended to aid in transferring tape files without operator intervention. Suppose, for example, that you schedule a transfer at 10:00 P.M., and you know that no one will be around. What do you do? You pre-load the CUU with the correct tape(s) and at 10:00 P.M., the application does its business.

Assigning by MODEL or TYPE, on the other hand, requires operator intervention. He must reply to a WTOR as follows:

The application issues WTOR before it tries to ASSIGN a candidate drive At this point, the operator should ready the drive (i.e., attach it, load the tape, etc, etc) and reply Go. Or he/she can reply with NEXT (the application looks for the next candidate drive, if any) or a specific CUU. In any case, a new WTOR is issued to get the operator's permission for the tape assignment to continue. Simple and totally logical (I think) stuff!

ASSIGNing tape drives by MODEL: If you have mixed configuration (say, 3480's and 3490's) , you can instruct the application to consider only a specific model by coding the model's number in the UNIT field. Therefore, if you code, for example, 3480 then only 3480 drives are considered.

ASSIGNing tape drives by TYPE, on the other hand, result in allocating mixed type drives, if you group those drives under the same category This is the best way to achieve device independence if desired



Notify

Platform: VSE only

Purpose:  used in building the Power command, BROADCAST, to notify The user, if any, when the transfer finishes.
               Notice that the node name you enter must be terminated with a COMMA.

DEFAULT:  *,        (i.e., user is on the local node)
REQUIRED:          NO
Example:               NOTIFY = *,   notice the COMMA, please.
Notes:

1)  HOST profile files (for the File transfer function) must be catalogued in the startup sublibrary.
   
2)  User Profs and FTPC members (for the FTP Server) must also be catalogued in the startup sublibrary as well. 

The sublibrary you choose is refered to here, and in other pages, as the "startup sublibrary". 
SWITCH_VSAM files support                                                               
SWITCH_General activity trace                                                            
SWITCH_Wto activity to console                                                          
SWITCH_User interface trace                                                               
SWITCH_Dbase trace activity                                                               
SWITCH_Tape overwrite expired                                                          
SWITCH_Security interface                                                                  

This switch is required for both the File transfer and FTP server components:

SWITCH_IP                                                                                         

These three switches are required for the FTP server Component.

SWITCH_FTP_SERVER_SUPPORT                                                     
SWITCH_FTP_SERVER_PORT Support                                              
SWITCH_FTP_SERVER_UID_PWD_FOLD                                         
 

Default global logmode 
Vtam acbname                                                                                     
Administrator AD
User 
HOST
NUM_User session blocks                                                                    
NUM_Host session blocks                                                                         
NUM_Xfer session blocks                                                                         
NUM_Work (136-byte) buffers                                                                 
NUM_End of object buffers                                                                     
NUM_Screens (screen depth)                                                                   
NUM_Lines (objects) per screen                                                              
NUM_Report objects per page                                                                     
A2E  ASCII to EBCDIC) 
E2A (EBCDIC to ASCII)
MDISK (VM only) 
TAPE DRIVE (VSE ONLY) 
Notify (VSE-ONLY)

The following global configuration statements are required for the TCP/IP interface:

SWITCH_IP
IP_ID
IP_TIMEOUT (in minutes)

The following two statements belong to the internal (non_FTP) file transfer component using TCP/IP stack:

TCP_LISTEN_PORT  255
TCP_HOST



The following two statements belong to the FTP server component only:

FTP_LISTEN PORT   259
FTP_32K_BUFFERS
FTP_LIBR_MEM_TYPE FTP_LIBR_MEM


The Following Two statements are required for Auto Queue Monitor Function.

POWER_PWD  blanks
POWER_MONITOR_QUEUE 

Hosted by www.Geocities.ws

1