[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1660.0. "Transfer of CLI routines to 3.0" by COPCLU::VAGN (Vagn Eisensee @DMO) Mon Oct 26 1992 15:48

      After some hours experimenting with the new way of including code level 
      integrated routines I give up and ask for help. I thought you just needed 
      to transfer information from the 2.4 version of OASDF.BLI to the module 
      OA$SCT$SDF. This works fine for the modules with no parameters, but I 
      cannot figure out what to enter in the forms when the routine is called    
      with 2 parameters, (or the rest of the commad line) as in the following 
      example:
      
      On version 2.4 the the integration worked as follows:
      
      Routine name OAX$LOCK, coded in Pascal
      
      OASDF.BLI table entry:   <'OAX$LOCK',OA$SDF_LOCK>,
      
      Entry for OAX$LOCK in SITELINK24.COM:
      
      $ wo "! "
      $ wo "! VMS Lock management functionality in ALL-IN-1"
      $ wo "! "
      $ wo "OA$BUILD:OAX$LOCK"
      $ !
      
      Examles of calling oax$lock from script level:
      
      GET OA$FUNCTION = "OAX$LOCK LOCK " #TAVLE OBSREG.FIL[#KEY]
      GET OA$FUNCTION = "OAX$LOCK UNLOCK " #TAVLE OBSREG.FIL[#KEY]
           
      Questions for the transfer to version 3.0:
       
      1.  I use a syntax 2 routine address - the old style - because of 
          the way oax$lock is called from scripts. Is this OK? 
      	  However the routine address IS NOT OA$SDF_LOCK which you might 
          expect because of the OASDF entry. What is OA$SDF_LOCK? It 
          cannot be found in the object part of the code.
      	  And is OA$SDF_LOCK at all relevant to the new integration?
      
      	  If you use OA$SDF_LOCK as routine address OAX$LOCK does not 
          appear as a CLI function. This is understandable since it is 
          not a global symbol in the routine.
      
      2.  If you use OAX$LOCK as the routine address oax$lock appears as 
          a CLI function. but it does not work, and you end up at VMS 
          level if you try to execute it.
      
      	  Is the routine address OAX$LOCK?
      
      	  How do you fill in the information about parameters?
      
      3.  Do you need to reprogram your routine if it worked OK with 
          version 2.4?
      
      
      Regards  
      
      Vagn

T.R	Title	User	Personal Name	Date	Lines
1660.1		PAJERO::RHOTON	John Rhoton @TNO - DTN 871.7947	`Mon Oct 26 1992 16:24`	27
	Re: .0 Hi Vagn, I don't know anything about OAX$LOCK or OA$SDF_LOCK but it would look like the V2.4 implementation involved: 1) SDF table entry of Function OAX$LOCK, Routine OA$SDF_LOCK 2) Routine in OASDF.BLI called OA$SDF_LOCK which calls a routine in OA$BUILD:OAX$LOCK.???. I will assume this routine is called OAX$LOCK. 3) Routine OAX$LOCK in OA$BUILD:OAX$LOCK.??? that is linked to the main image via SITELINK. If this is the correct interpretation of the scenario then you need to: 1) Make an entry in the SDF table of Function OAX$LOCK, Syntax-2 routine OA$SDF_LOCK. 2) Extract the routine OA$SDF_LOCK from OASDF.BLI and place it in its own module (e.g. OA$SDF_LOCK.BLI). Recompile it and make an additional entry in SITELINK for this module (so you would have two entries in SITELINK - one for the jacket routine and one for the real routine). 3) Relink ALL-IN-1. I hope I understood the problem correctly, John
1660.2	Routine in OASDF is missing	COPCLU::VAGN	Vagn Eisensee @DMO	`Tue Oct 27 1992 08:48`	20
	Hi John Nice to hear from you! Yes I started off thinking like you in .1 - > 2) Routine in OASDF.BLI called OA$SDF_LOCK which calls a routine in > OA$BUILD:OAX$LOCK.???. I will assume this routine is called OAX$LOCK. However this routine does not exist and the lock function works anyhow. I just did an extra test to be absolutely sure. Therefore I guess there must be some sort of a default "jacket" routine taking over when you only do the table entry in oasdf.bli. Could this be the case? And if so, is there a similar facility in version 3.0 or do I have to do some coding? If I have to code my problem is that I did not do the OAX$LOCK stuff, and my bliss coding is long ago and very limited. Vagn
1660.3	Routine must be there somewhere	IDNTCR::RHOTON	John Rhoton @TNO - DTN 871.7947	`Tue Oct 27 1992 11:03`	9
	The routine OA$SDF_LOCK needn't be in OASDF.BLI but it must be in the image somewhere. Otherwise I am fairly confident that the function will not work. It might be worth relinking the image with the map option (@A1LNKDRV OPTIONS M) and searching for OA$SDF_LOCK. You might also post a pointer to the OASDF and OAX$LOCK modules if you have them on the E-net. John
1660.4	Everything works now!	COPCLU::VAGN	Vagn Eisensee @DMO	`Wed Oct 28 1992 14:11`	18
	John, now everything works exactly as you described in .1. It helped a lot when I got hold of the correct sources! Thanks for pointing me in the right direction. Another matter which has been confusing during this code level integration session is that there is a problem in the form OA$SCT$SDF in the CM library. In all translated versions of ALL-IN-1 3.0, where you have not translated CM you get a message, that you have no privileges to write when trying to use it. The reason is a mismatch between the registered privileges for a user and the checking code. Solution: change OA$Y in the Named data to CM$_Y - about 4 occurances of OA$Y. Vagn
1660.5	Known problem	CESARE::EIJS	All in 1 Piece	`Fri Oct 30 1992 08:20`	9
	Vagn, This has already been reported and known as THR-16885 (against SCM). We figured this one out when we were in Vienna for the ATS. Ciao, Simon