Conference clusta::acms

    
    	The logical has to be defined in whatever process is doing the
    	actual DECforms work, and it has to be defined prior to the 
    	first call to DECforms.
    
    	Bill
    

>>    	The logical has to be defined in whatever process is doing the
>>    	actual DECforms work, and it has to be defined prior to the 
>>    	first call to DECforms.
    
Hello  Bill,

  The logical was define System wide before starting the ACMS System and any
  other process using DECforms but the problem still exist...

  The customer wants to move from VAX to Alpha next week, and this problem
  must be fixed before he can do it.

  best regards


      Arie.
    

    
    	They have to be doing something wrong.  It really does work.
    	I'd suggest they insert a SYS$TRNLNM call into their code
    	and verify that the code can see the logical.
    
    	Bill
    

Hi,

Regarding rep .4

We spoke with the customer and try again to define the logical name at
system level (/exec), as we understand this should enable all who need this
logical to know about it. This was done before the ACMS even started. 

Now, after the logical definition, start the ACMS, start the Cobol/DECforms
program that call the ACMS task, see that he is in the task, see that he go
to the EXCHANGE step and --- fail again with the same error.

Any ideas ?  How to verify that the ACMS know about the logical (without 
changing the working tasks) ?

Thank's
- Amir

    
    	Please verify that the customer is really running ACMS V4.1.
    
    	ACMS V4.0 did not use that logical.  The error is being returned
    	by DECforms when an asynchronous request (which is what ACMS
    	uses) comes into DECforms and it's one time initialization has
    	not been called.
    
    	Bill
    

>>    	Please verify that the customer is really running ACMS V4.1.
    
>>    	ACMS V4.0 did not use that logical.  The error is being returned
>>    	by DECforms when an asynchronous request (which is what ACMS
>>    	uses) comes into DECforms and it's one time initialization has
>>    	not been called.
    
>    	Bill
    
From ACMS/SHOW SYSTEM -->  V4.1-0

From Anal/image sys$system:forms$dispatch.exe --> V2.1-010 
-- Is it the correct DEC Forms version : 2.1B ?

From Anal/image sys$system:acmscp.exe --> V4.1-0 14-OCT-1995

From sho log ACMS$CMA*  -->  ACMS$CMA_USER_AGENT  "Y" (System & EXEC).

Is it working in your environment ?

Maybe there are some more changes between your environment and the customer...

Hope to get a fix soon...

  
  best regards


     Arie.

  Hello Bill,

  The customer tried some more tests :

    1. Call FORMS$DISABLE before calling the ACMS Task.
       Same prblem, same error message.

    2. Calling the ACMS Task from seperate COBOL program NOT using DECforms :
       No problem - runs o.k.


    Still need your help.


  best regards


      Arie.

    
    	The logical has to be defined as a PROCESS logical.
    
        (from the ACMS V4.1 Release Notes)
    
    	Due to changes made in the ACMS and DECforms products, any
    	agent that enables DECforms must define a process logical
    	before any ACMS SI calls are made. The logical ACMS$CMA_
    	USER_AGENT must be defined as having a value of "Y", "y",
    	"T", "t", or 1 as in the following example:
    
    	$ DEFINE/PROCESS ACMS$CMA_USER_AGENT "Y"
    
    
    
    	If this is an agent that runs in a procedure server, the logical
    	has to be defined in the application definition in the
    	'SERVER LOGICALS are' clause.  This is the only way to create
    	a process level logical name in a server.
    
    
    	This is the code in ACMSHR that does the work:
    
    ; P 0233  2     status = $TRNLNM( TABNAM = %ASCID'LNM$PROCESS_TABLE',
    ; P 0234  2                       LOGNAM = %ASCID'ACMS$CMA_USER_AGENT',
    ;   0235  2                       ITMLST = user_agent_itmlst );
    
    
    
    	Bill

>    1. Call FORMS$DISABLE before calling the ACMS Task.
>      Same prblem, same error message.

ACMS has to have a chance to initialize DECforms before anyone else uses it in
the process.  If you don't allow ACMS to do the initialization, you'll get this
error.

-Tim

Hi,

Regarding rep .8 and .9

I just would like to verify your answers, and understand them.


1. The way to define the logical is in the "server logical are..." clause ?

2. Why isn't the forms$disable enough ?

3. How does the logical help us ?

4. What change from previous versions that force us to use the logical  ?


Thank's
- Amir

    
    > 1. The way to define the logical is in the "server logical are..."
    clause ?
    
    	The logical has to be defined at the process level.  For a 
    	server, this means defining the server logical names in
    	the application definition.
    
    > 2. Why isn't the forms$disable enough ?
    
    	ACMS uses an undocumented async interface in DECforms.  If
    	an async call is issued and DECforms has not been initialized
    	properly, then the error is returned. All ACMS calls to
    	DECforms are asynchronous.  The published DECforms calls are
    	synchronous.  Once a synchronous call is issed, the async
    	interface can never be enabled.
    
    > 3. How does the logical help us ?
    
    	Due to the use of DECthreads in DECforms, certain calls have to
    	executed at non-AST level other DECthreads may not work properly.
    
    	If you want to use DECforms with ACMS, you have to use the logical.
    	The ACMSCP and ACMSDBG images also intialize DECforms in the same
    	way.
    
    > 4. What change from previous versions that force us to use the logical?
    
    	See # 3.  In DECforms V2.2, the use of the logical will change
    	slightly.  DECforms V2.2 will allow async calls from ACMS without
    	the initialization being done first.  But, this will put DECforms
    	into a synchronous mode which means that while ACMS is using
    	the async interface, DECforms will only allow 1 request to be
    	active at a time.  This will be documented in the release notes
    	for ACMS V4.2.
    
    Bill
    

    Hello,

    I think that there is some mis-understanding here...

    
***>    > 1. The way to define the logical is in the "server logical are..."
***>    clause ?
***>    
***>    	The logical has to be defined at the process level.  For a 
***>    	server, this means defining the server logical names in
***>    	the application definition.

There is no need to define the Logical name in the Server because the Server
is NOT using DECforms calls.

The full scenario is :

  1. User run a COBOL program (Main program).

  2. The user's Main program works directly with DECforms.
     (Enable, Recieve etc. in the MAIN program).

  3. In some menu options the Main program is calling ACMS Tasks which use
     DECforms (standard DECforms connection from the CP).
     Here he gets the problem (BLKBYREQ error).

  4. Returns from ACMS Task to the Main program DECforms Menu.
     
  When trying to call ACMS Task BEFORE any DECforms calling in the Main 
  program there is no error and everything works correctly :
  This is what Tim mentioned in his reply (.9).

    
**>    	See # 3.  In DECforms V2.2, the use of the logical will change
**>    	slightly.  DECforms V2.2 will allow async calls from ACMS without
**>    	the initialization being done first.  But, this will put DECforms
**>    	into a synchronous mode which means that while ACMS is using
**>     the async interface, 
**>     DECforms will only allow 1 request to be
**>    	active at a time.  This will be documented in the release notes
**>    	for ACMS V4.2.

  Does it means that CP process will support only one user at a specific 
  time ?    
        
  We need a fix to this problem and the customer needs it NOW.
  The customer bought Alpha/8400 for this environment which is working perfect
  on the VAX.

	Arie.

    
    
    	Once DECforms is called synchronously, it cannot be called
    asynchronously by ACMS.  That's the way 2.1B works.
    
    	If you have a program that makes use of DECforms and then
    you want to call an  ACMS task that also uses DECforms, you'll
    have to make sure that the async (ACMS) interface is initialized
    first.  You do this by signing in, and calling ACMS$INIT_EXCHANGE_IO.
    This will intialize DECforms properly and will also allow other calls
    to DECforms from your program.  (You've already seen this as you
    described it in the paragraph after # 4 above).
    
    
  > Does it means that CP process will support only one user at a specific 
  >  time ?    
    
    	No, CP does all the right things.  CP also only uses the async
    	DECforms interface.
    
  > We need a fix to this problem and the customer needs it NOW.
  > The customer bought Alpha/8400 for this environment which is working perfect
  > on the VAX.
    
    	There is no fix, since this is not a bug.  If you code it the way
    	I described, everything will work properly.  Maybe we need to
    	document it a little more but it is difficult to describe every
    	situation a customer may encounter.
    
        Your customer will also run into the CMA time slicer problem with
    this agent.  Once you the async interface is enabled, the CMA timers
    will start to fire.  If your customer has lots of these agents, they'll
    notice a fair bit if CPU time being consumed.  The published CMA
    patches will have no effect on these timers.
    
  > We need a fix to this problem and the customer needs it NOW.
    
    Please be aware that notes is not the appropriate place to bring
    serious customer problems.  There is no guarantee that anyone will ever
    answer a question posed in there.  IPMT is the proper escalation for
    customer problems.
    
    Bill
    ACMS Engineering
    

    Hello Bill,
    
	Many thanks for your help.

***>    	Once DECforms is called synchronously, it cannot be called
***>    asynchronously by ACMS.  That's the way 2.1B works.
    
***>    	If you have a program that makes use of DECforms and then
***>    you want to call an  ACMS task that also uses DECforms, you'll
***>    have to make sure that the async (ACMS) interface is initialized
***>    first.  You do this by signing in, and calling ACMS$INIT_EXCHANGE_IO.
***>    This will intialize DECforms properly and will also allow other calls
***>    to DECforms from your program.  (You've already seen this as you
***>    described it in the paragraph after # 4 above).
    
	It means that the customer must change many programs.
    
***>    There is no fix, since this is not a bug.  If you code it the way
***>    I described, everything will work properly.  Maybe we need to
***>    document it a little more but it is difficult to describe every
***>    situation a customer may encounter.

	The customer expect upward compatibility as we always promise and
        his programs are running very well currently on the VAX.    
	The customer sees this problem as a bug because his programs stop
        working correctly when moving from one Decforms version to another... 

***>        Your customer will also run into the CMA time slicer problem with
***>    this agent.  Once you the async interface is enabled, the CMA timers
***>    will start to fire.  If your customer has lots of these agents, they'll
***>    notice a fair bit if CPU time being consumed.  The published CMA
***>    patches will have no effect on these timers.

	Is there any solution to this problem ?
        What the CP is doing regards to this problem ?
        Is the problem exist if the Main program Signout from ACMS after
        returning from the ACMS Task (This is how it works now...).

	I thought that the Patch for CMA solved this problem.
        (see notes : 3933, 4069).
     
***>    Please be aware that notes is not the appropriate place to bring
***>    serious customer problems.  There is no guarantee that anyone will ever
***>    answer a question posed in there.  IPMT is the proper escalation for
***>    customer problems.

	Bill, please try to be nice because I'm your customer and I'm trying
        to help our outside customer which is paying our salary...
        I always thought that we are all belong to the same one company...

	If it helps to esclate the problem thru IPMT I'll do it.
        Haim and Amir who started this note are from the supporting group
	and they can do it if it's going to help...
    
	I think that you have some problems in your Node because it's very
        hard to write to the Notes file : Getting "error writing" message 
        and an empty reply is opened... 
        I've tried many times before writing this reply.

	best regards

	Arie.    

    
    >	The customer expect upward compatibility as we always promise and
    >   his programs are running very well currently on the VAX.    
    >	The customer sees this problem as a bug because his programs stop
    >   working correctly when moving from one Decforms version to another... 
    
    
    	The customer will see the same behaviour on VAX if they use
    	DECforms 2.1B.  Unfortunately there is nothing we can do.  This
    	is the way this particular version of DECforms works.  DECforms
    	V2.1 and V2.1A attempted to initialize DECthreads (CMA) at AST
    	level and this caused problems with terminals hanging, channels
    	being left open, CP crashes, etc.  DF V2.1B was modified to
    	to make sure that CMA was not inited at AST level.  This required
    	that ACMS call DECforms as early as possible.
    
    	In previous versions of ACMS, DECforms was not initialized until
    	the first task that required it was called.  This meant calling it
    	at AST level.  In ACMS V4.1 and on, the CP initializes DECforms
    	as part of the mainline code before it ever gets to AST level. So,
    	the CP never sees the problem your customer is seeing.
    
    >    Is the problem exist if the Main program Signout from ACMS after
    >    returning from the ACMS Task (This is how it works now...).
    
    	Once the user signs into ACMS and does the ACMS$INIT_EXCHANGE_IO,
    	there will be no problems.  They can sign out and sign back in
    	again, make normal DECforms call, etc.  The important part is that
    	the ACMS sign in and init exchange have to be done early in the
    	program startup.
    
    >	I thought that the Patch for CMA solved this problem.
    >    (see notes : 3933, 4069).
    	
    	The patch only helps those processes that do not use DECthreads
    (like ACMSEXC, ACMSACC, procedure servers, etc).  Agents that select
    tasks that use DECforms use CMA so the timers are a necessary part
    of the way DECforms works.
    
***>    Please be aware that notes is not the appropriate place to bring
***>    serious customer problems.  There is no guarantee that anyone will ever
***>    answer a question posed in there.  IPMT is the proper escalation for
***>    customer problems.

    	The reason I brought this up is that posting a note in the
    notesfile is not an official engineering notification.  You cannot say
    to your customer that engineering has been made aware of the problem
    nor does the 'clock' start ticking on the problem.  The notesfile is a
    very informal means of sharing information among the field and
    engineering.  It is not the place to submit formal problems, that's
    what the IPMT system is for. Check the other notesfiles (like VMSNOTES)
    and you'll see the same response.  
    
    Bill
    
    
    

    Hello,

    
>>    	The customer will see the same behaviour on VAX if they use
>>    	DECforms 2.1B.  Unfortunately there is nothing we can do.  This
>>    	is the way this particular version of DECforms works.  DECforms
>>    	V2.1 and V2.1A attempted to initialize DECthreads (CMA) at AST
>>    	level and this caused problems with terminals hanging, channels
>>    	being left open, CP crashes, etc.  DF V2.1B was modified to
>>    	to make sure that CMA was not inited at AST level.  This required
>>    	that ACMS call DECforms as early as possible.
>>    
>>    	In previous versions of ACMS, DECforms was not initialized until
>>    	the first task that required it was called.  This meant calling it
>>    	at AST level.  In ACMS V4.1 and on, the CP initializes DECforms
>>    	as part of the mainline code before it ever gets to AST level. So,
>>    	the CP never sees the problem your customer is seeing.
    
Not many choices are left....

I'll start working on the workaround with the customer.

>>    	The reason I brought this up is that posting a note in the
>>    notesfile is not an official engineering notification.  You cannot say
>>    to your customer that engineering has been made aware of the problem
>>    nor does the 'clock' start ticking on the problem.  The notesfile is a
>>    very informal means of sharing information among the field and
>>    engineering.  It is not the place to submit formal problems, that's
>>    what the IPMT system is for. Check the other notesfiles (like VMSNOTES)
>>    and you'll see the same response.  

I agree.

  best regrads

     Arie.    
    
    
    

Hi,

I would like to summarized the last replies to be sure that I have it right.

To avoid the BLKBYREQ error using DF v2.1B, it is essential for ACMS to 
initialize DECforms before any thing else (especially calls to DECforms from
other programs).

To solve our customer problem we should use the workaround that Arie suggested,
call ACMS which will initialize DECforms (using dummy stuff) return to the main
program and continue as before.

Will this change in DECforms v2.2 ? 
(I saw in the release notes there are many modification using DECthread.)

Thank's
- Amir.

    
    In order to avoid the BLKBYREQ, you need to do the ACMS$SIGN_IN and
    ACMS$INIT_EXCHANGE_IO first (which is the first thing an agent program
    should do regardless of the forms product).  This will initialize
    DECforms properly and will allow the agent program to call ACMS tasks
    that use DECforms and will allow normal DECforms calls.
    
    The following chart describes how ACMS V4.2 will handle the various
    versions of DECforms and/or CMA.  At the moment, this is Internal
    Digital Use only, since this version has not yet shipped.
    

    
                  CMA Related Changes for ACMS V4.2

      /---------------------------\
      | Is CP or ACMSDBG process, |   No
      | or ACMS$DECFORMS_IN_AGENT |----------+
      | logical is defined?       |          |
      \---------------------------/          |
                   |                         |
                   | Yes                     | MULTI-USER* DECforms is not
                   |                         | needed in this process.
      +---------------------------+          |
      | LIB$FIND_IMAGE_SYMBOL     |          |
      |   (DF Init      )         |          |
      | Loads DECforms in process |          |
      +---------------------------+          |
                   |                         |
                   |<------------------------+
                   |
      /---------------------------\             If DECforms V2.2
      |                           |    No         SINGLE-USER* mode.
      |    Is CMA in process?     |----------->   Don't use threads.
      |                           |               DECforms operates in
      \---------------------------/               synchronous mode.
                   |                            If DECforms V1.4
                   | Yes                          MULTI-USER mode.
                   |
      /---------------------------\
      |                           |   No
      |   Found DF Init ?         |----------+
      |                           |          | Process is not using
      \---------------------------/          | DECforms, or DECforms
                   |                         | V1.4 is being used.
                   | Yes                     |
                   |                /----------------\
                   |                |                | Yes   Use EF wait loop
                   |                | Is CP process? |-----> to avoid AST
                   |                |                |       problems with
                   |                \----------------/       CMA Null thread.
                   |                         |
                   |                         |
      +---------------------------+          | CMA is here for some reason.
      |   Call DF Init            |          | Presumably, the customer
      | DECforms is being used    |          | needs it.
      | in MULTI-USER mode.       |          |
      +---------------------------+          |
                   |                         |
                   |<------------------------+
                   |
      +---------------------------+
      | Init ACMS CMA code:       |
      |   - create request thread |
      |   - use cma_delay loop    |
      +---------------------------+
                   |
                  DONE


       * SINGLE-USER and MULTI-USER modes are also referred to as synchronous
       and asynchronous modes.

Bottom line,  ACMS and DECforms are two separate products.  However, DECforms
has special code in it for ACMS that needs to be maintained between each version
of ACMS and DECforms.  Sure, thats crazy as has well been seen.  I wouldn't
expect you'll see that change at this point so you'll need to keep that point in
mind each time you change a version of either of these at a customer site.

-Tim