Conference acadmy::tpas_notes

    When linking a test program against the TPAS object library
    to resolve the call to TPAS_CALC_TRNSFR_PRC warnings appear
    as a result of undefined symbols.

    The BOPS system is built using an MMS procedure which currently
    contains no warning messages and we would prefer not to introduce
    any. Is there any way we can get around this? The link output is
    shown below:-

%LINK-W-NUDFSYMS, 2 undefined symbols:
%LINK-I-UDFSYM,         APPIX$PPCS_END_LIST_BOM
%LINK-I-UDFSYM,         APPIX$PPCS_FIND_PART
%LINK-I-UDFSYM,         VMH$FIXEDQ_UR (Weak Reference)
%LINK-I-UDFSYM,         VMH$FIXEDQ_UW (Weak Reference)
%LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VM (Weak Reference)
%LINK-I-UDFSYM,         VMHDEB$TRACE_FREE_VMLIST (Weak Reference)
%LINK-I-UDFSYM,         VMHDEB$TRACE_GET_VM (Weak Reference)
%LINK-I-UDFSYM,         VMHDEB$TRACE_RET_VMH (Weak Reference)
%LINK-W-USEUNDEF, undefined symbol APPIX$PPCS_END_LIST_BOM referenced
        in psect $CODE offset %X0000010F
        in module TPAS_GET_PART file APPLIC_2:[BOPS.LIB_DEV]TPAS_LOGIC.OLB;1
%LINK-W-USEUNDEF, undefined symbol APPIX$PPCS_END_LIST_BOM referenced
        in psect $CODE offset %X00000122
        in module TPAS_GET_PART file APPLIC_2:[BOPS.LIB_DEV]TPAS_LOGIC.OLB;1
%LINK-W-USEUNDEF, undefined symbol APPIX$PPCS_FIND_PART referenced
        in psect $CODE offset %X00000532
        in module TPAS_GET_PART file APPLIC_2:[BOPS.LIB_DEV]TPAS_LOGIC.OLB;1
%LINK-W-USEUNDEF, undefined symbol APPIX$PPCS_FIND_PART referenced
        in psect $CODE offset %X00000547
        in module TPAS_GET_PART file APPLIC_2:[BOPS.LIB_DEV]TPAS_LOGIC.OLB;1

    Regards
    Martin Brook, BOPS Development

Martin,


    >> Is there any way we can get around this? 

	The way to get around this is to install PPCS, even if you 
	don't use it in TPAS to get the part. 

	What I can do is post this as a PCR. Then change the TPAS_GET_PART,
	one using only AMPS and another using both AMPS and PPCS. Supply 
	two object libraries in the kit. Then in INSTAL check to see if 
 	PPCS is installed. If it does exist then download the object 
	library with PPCS. If it doesn't exist then download the object 
	library that doesn't call PPCS. That would be scheduled 
	for a later release.

        Lois

Martin,


     DATA DEFINTIONS:
	I got that on my to do list. If pull the new  TPAS_USER_GUIDE.DOC
	and look in the glossary, the definitions are posted there. They
	are also in the DATA_ELEMENTS_DEFINITIONS and TPAS_II_DATA_MODEL
	both found in AWARD::TPAS$PUBLIC.
	Also, in the user doc on pages 2-7 through 2-11 is a defintion
	of the sending and receiving data elements.
	The sizes and data values can also be found the the TPAS_II_PHYSICAL
	appendix H for the sending data and appendix I for the receiving
	data.

     LOGICAL DEFINTIONS:
	The definitions of the logicals names can be found in the
	User Uoc on pages 2-11 through 2-14. Also, in the TPAS_LOGICALS.COM
	is a defintion. These logicals are defined when doing the KITINSTAL.
	The answers update TPAS_LOGICALS.COM. This command stream can be
	changed manually at any time.
	Another place for defintions of the logicals can be found in
	APPENDIX W in the TPAS_II_PHYSICAL design document. This can be found
	in the kit, loaded into [TPAS.DOC] as well as in the TPAS$PUBLIC
	area.
	

     ERROR_CODE:
	TPAS_CALC_TRNSFR_PRC.COB had both SQLERR and VMSERR defined
	as COMP-1 in the linkage section. COMP-1 is a 4 byte, 32 bit,
	real number. In BASIC a 4 byte (32 bit) field can be defined as
	either a SINGLE REAL or a  LONG INTEGER. A real number in
	COBOL can only be defined as COMP other wise the S9VS9 fields
	get packed. I suppose I could have used S9(9) COMP - but I have 
	had lots of problems sending unpacked numbers with COBOL that I 
	chose to use COMP-1.
	Checking error though, I would depend on the ERROR_STATUS field to 
	capture the error, as this is correct and the VMSERR codes we send
	back are not always correct. See notes 55,55.1,56 and 56.1

Lois

Lois,

    Thanks for the replies and pointers to the relevant documentation.
    (There is rather a lot of it!)


 o  LINK WARNINGS

    I put to our Project Manager, Mike Green, the option of living with
    the LINK warnings or installing PPCS. His reply was as follows:-

    >> The answer is that from a BOPS perspective, we need to have the
    >> minimum software required for BOPS to compile and link cleanly
    >> and use TPAS. Ideally this is a sub-set of the TPAS etc. kits but
    >> if the only way of doing it is to install a full application kit
    >> then so be it.

    So, until there is an alternative, we will go ahead and install
    PPCS. Do you have any tips, documentation pointers etc for doing
    this?


 o  LOGICAL NAMES

    What I was specifically looking for here were the logicals which
    are used by the TPAS_CALC_TRNSFR_PRC function. When we roll out BOPS
    (with TPAS interface) throughout Europe, as I see it, each production
    site will NOT be installing the full TPAS II kit. We will install the
    full kit on our development machine in order to resolve references to
    TPAS_CALC_TRNSFR_PRC and to build a BOPS kit. Each production site
    will access a central AMPS 2 database via proxies. Therefore, the only
    TPAS logicals required by each site will be the ones used by the
    TPAS_CALC_TRNSFR_PRC function. Is there a run-time kit available for
    this? If not, do you have any guidelines as to how we can achieve this
    without installing the full TPAS II development kit on every production
    machine.

    Also note 52.3 mentions the logical TPAS$DATA. The user guide (2-11
    through 2-14) does not list this. Do I need to define this logical?


 o  ERROR CODES

    From your reply I assume that we go ahead using the data types in
    George's RECORD definition rather than the original MAP. Is my
    assumption correct?

    >>  In BASIC a 4 byte (32 bit) field can be defined as either a
    >>  SINGLE REAL or a LONG INTEGER.
    
    In my view a SINGLE REAL and a LONG INTEGER are two completely
    different data types which just happen to occupy the same amount of
    storage (32 bits). It is for the application to decide which data
    types it needs. I am surprised you have a problem in COBOL 'sending'
    the LONG INTEGER data type. What happens with your calls to system
    services, RTL calls etc?


 o  DEC STD 095 kit

    Re: 48.9, 48.10

    I understand this kit was scheduled to be available today. Is this
    still the case? If not, do you have an update on availability?


Regards
Martin Brook, BOPS Development

Martin,

 o  LINK WARNINGS

    >> So, until there is an alternative, we will go ahead and install
    >> PPCS. Do you have any tips, documentation pointers etc for doing
    >> this?

    No tips. It's fairly easy to install and small in size.
    You can obtain it through a request to ACAD::QCA_ADMIN

 o  LOGICAL NAMES

    >> TPAS_CALC_TRNSFR_PRC function. Is there a run-time kit available for
    >> this? If not, do you have any guidelines as to how we can achieve this
    >> without installing the full TPAS II development kit on every production
    >> machine.
    There is no run time kit. I will work with the BOPs/TOLAS installation
    to determine what you will require to each of the sites. 
    There is no 'run time' kit but once we figure out what is needed maybe
    one can be created specifcally for the BOPS/TOLAS implementation sites.

    >> Also note 52.3 mentions the logical TPAS$DATA. The user guide (2-11
    >> through 2-14) does not list this. Do I need to define this logical?
    It is needed. It is where the AUDIT files get created. It is in the 
    TPAS_LOGICALS.COM. As I am modifing the user/install doc now I will 
    do this change.

 o  ERROR CODES

    >> In my view a SINGLE REAL and a LONG INTEGER are two completely
    >> different data types which just happen to occupy the same amount of
    >> storage (32 bits). It is for the application to decide which data
    >> types it needs. I am surprised you have a problem in COBOL 'sending'
    >> the LONG INTEGER data type. What happens with your calls to system
    >> services, RTL calls etc?

     You are right, they are two completely different data type.
     But when I went to select the COBOL data type I took the COMP-1
     definition instead of the S(9)9 COMP definition. It was a complete
     overlook on my part - from past history I just went to COMP-1
     In the COBOL code we receive the VMS error in the S(9) but move
     it to the COMP-1 prior to return it to the calling program.

 o  DEC STD 095 kit

    Re: 48.9, 48.10

    >> I understand this kit was scheduled to be available today. Is this
    >> still the case? If not, do you have an update on availability?

    I was pushing myself for Monday Jan 23, but unfortunately did not
    make it. I had a learning curve with creating and updating a logical
    name table and getting VMSINSTAL to create the ACLs just they way I 
    needed them. I have just complete testing the VMSINSTAL. Now that is done
    I am going back to update the INSTAL and USER documentation, as well as
    create the TPAS031.RELEASE_NOTES to be DECSTD 095 compliant.

    The changes are not immense but covers all the issues brought up in
    48 and various other notes on DECSTD 95.

Lois,

    Thanks for the reply but could you also please cover the following
    questions from my previous note. I.e:-

 o  LOGICAL NAMES

    >> What I was specifically looking for here were the logicals which
    >> are used by the TPAS_CALC_TRNSFR_PRC function.

    In other words, does TPAS_CALC_TRNSFR_PRC require ALL the logical
    names which are defined in TPAS_LOGICALS.COM? If not, could you
    list the ones which are specifically required by this function.


 o  ERROR CODES

    >> From your reply I assume that we go ahead using the data types in
    >> George's RECORD definition rather than the original MAP. Is my
    >> assumption correct?


 o  DEC STD 095 kit

    >> do you have an update on availability?

Regards
Martin Brook, BOPS Development

Martin,

 o  LOGICAL NAMES

 >>   In other words, does TPAS_CALC_TRNSFR_PRC require ALL the logical
 >>   names which are defined in TPAS_LOGICALS.COM? If not, could you
 >>   list the ones which are specifically required by this function.

     COMPILE TIME (not needed if specifing library area in link command)
          Directories	TPAS$LIBRARY	

     RUN TIME LOGICALS FOR TPAS_XCLDD.EXE:
          Database: 	TPAS$XCLDD_DB	
                        TPAS$DB
          Directories: 	TPAS$MAIL

     RUN TIME LOGICALS FOR TPAS_LOGIC.OLB:
          Database: 	TPAS$XCLDD_DB	
                    	TPAS$DB
		    	TPAS$STKRM_DB
		    	TPAS$NOR$DB
                        TPAS$AMPS       

          Directories: 	TPAS$DATA
                        TPAS$MAIL    	

          Program Decisions Logicals:
			TPAS$DISPLAY_I_ERRORS 
			TPAS$DISPLAY_W_ERRORS
			TPAS$USE_AMPS
			TPAS$AMPS_AVAILABLE  
			TPAS$BILL_TO_TYPE_CD 
			TPAS$BILL_FROM_TYPE_CD   
			TPAS$SEPARATE_OPEN   
			TPAS$SEND_LOCAL_STD  
			TPAS$CREATE_AUDIT_TRAIL 
			TPAS$CREATE_STDCST_TRAIL 



     RUN TIME LOGICALS FOR COMMAND STREAMS (WAREHOUSE):
          Database: 	TPAS$XCLDD_DB	
                    	TPAS$DB
		    	TPAS$STKRM_DB
		    	TPAS$NOR$DB
			
          Directories: 	TPAS$COM     	
			TPAS$EXE     	
			TPAS$BACKUP  
                        TPAS$TEMP    	


 o  ERROR CODES

    >> From your reply I assume that we go ahead using the data types in
    >> George's RECORD definition rather than the original MAP. Is my
    >> assumption correct?

       If this works then use it. I have not tested, but mayber George can
  	confirm.


 o  DEC STD 095 kit

    >> do you have an update on availability?

	Just announced it - ended up being the end of the week of 23 Jan
	instead of the begining. I need to take speed typing now that I am
	also doing the documentation :)


Lois

Lois,

    I have now installed PPCS and the aforementioned LINK warnings have
    gone away.

Regards
Martin Brook, BOPS Development