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

Conference clusta::acms

Title:	ACMS comments and questions
Notice:	This is not an official software support channel. Kits 5.*
Moderator:	CLUSTA::HALLAN

Created:	Mon Feb 17 1986
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4179
Total number of notes:	15091

4094.0. "Not_cached, error from form request/hang cma_dump??" by KERNEL::PULLEY (Come! while living waters flow) Wed Jan 29 1997 07:16

Hi,

(This looks frightenly like an earlier note or two, but I'm slightly lost).
My customer is using a fron end of OpenVMS VAX v6.2, ACMS v4.1, DECforms
v2.1b, and DECthreads v2.12-296.
Back end is VAX VMS v5.5-2, ACMS v4.0, DECforms v1.4-12.
(Not sure exactly what version the forms are all built on).

I think he has a sungle threaded user written agent.
I've tryed puting acms$cma_user_agent "Y" in the login.com of the process
running the agent, but didn't change things.
This might be an oddity though.
While testing on two separate days, I found that I got exactly the same
submitter id up to lccv01::00040033-00000000- in the audit.
Both last fields were different though.
They seem to increase quite quickly, like from 00040033 the next one was
0005001b.
Is that quite possible/usual?

They get problems, I think everyone does, when having to cache an image
for the first time.
When the image file is there though, whether it's copied manually, or cached
by the failing atempt, it works.

Two slightly different symptoms, both give the audit extracted below from
the back end.
1. Hangs the agent process, and on interupt plus $ exit, gives a cma_dump.
2. Gives the screen error:-
An error was returned from a DECforms request
and then returns to the previous screen.

Nothing in swlup on front and back, or in front ends audit.
Forms$trace, (gave two files), looked for two forms, but didn't mention
the image it seems to want to cache.
Analy/image of that image after it's been cached only has two symbols:
$$abs$$;  forms$ar_form_table.
I couldn't see any errors in the forms$trace files.
The process quotas seem ok, haven't tryed things like changing ctlpages or
procsectcnt yet, should I?
On the front end ctlpages=100, procsectcnt=32.

Cutout of audit on the back end:-
************************************************************
Type   : LOGIN     Time   : 27-JAN-1997 11:36:03.15
User   :              Term   :  
Sub    : LCCV01::00040033-00000000-DB126FC0-009AEFA2 
Text   : Submitter authentication request for 
application BAT_APPL
************************************************************
Type   : LOGIN     Time   : 27-JAN-1997 11:36:03.46
User   : ACMS_SYSTEM  Term   : RTA1: (LCCV01::) 
Sub    : LCCV01::00040033-00000000-DB126FC0-009AEFA2 
Text   : Successful submitter authentication for 
application BAT_APPL of submitter LCCV01::ACMS_SYSTEM
************************************************************
Type   : LOGIN     Time   : 27-JAN-1997 11:37:09.49
User   :              Term   :  
Sub    : LCCV01::00040033-00000000-DB126FC0-009AEFA2 
Text   : Submitter authentication request for 
application DIS_APPL
************************************************************
Type   : LOGIN     Time   : 27-JAN-1997 11:37:09.85
User   : ACMS_SYSTEM  Term   : RTA1: (LCCV01::) 
Sub    : LCCV01::00040033-00000000-DB126FC0-009AEFA2 
Text   : Successful submitter authentication for 
application DIS_APPL of submitter LCCV01::ACMS_SYSTEM
************************************************************
Type   : TASK      Time   : 27-JAN-1997 11:38:09.65
Appl   : DIS_APPL 
Task   : TASK7322 
User   : ACMS_SYSTEM 
ID     : LCCV01::00040033-00000004-DB126FC0-009AEFA2 
Sub    : LCCV01::00040033-00000000-DB126FC0-009AEFA2 
Text   : Task canceled in Step DISPLAY_FORM_INITIAL in Task TASK7322 in Group DIS_ORDER_MANIP 
An error was returned from a DECforms request
%ACMSCACHE-E-NOT_CACHED, Error while attempting to cache file
_ANGV01::$1$DIA4:[LIV.DIS.ACMS]DIS_FORM_7322.EXE;6
************************************************************
End Report  27-JAN-1997 14:23:26.47

Thanks for any suggestions,
Steve.

T.R	Title	User	Personal Name	Date	Lines
4094.1	More info.	KERNEL::PULLEY	Come! while living waters flow	`Thu Jan 30 1997 11:31`	44
	Hi, The back end is DECnet phase IV, whereas the front end is phase V. $ mc ncl NCL>sho impl Node 0 at 1997-01-27-10:12:57.500+00:00Iinf Characteristics Implementation = { [ Name = OpenVMS VAX , Version = "V6.2 " ] , [ Name = DECnet/OSI for OpenVMS , Version = "DECnet/OSI for OpenVMS Version V6.3-ECO06 8-NOV-1996 17:59:16.03" ] } The ACMS logicals look like this:- $ show log acms* (LNM$SYSTEM_TABLE) "ACMS$ADB_CACHE" = "SYSDSK:[ACMS.ADB.ACMS$CACHE.]" "ACMS$AUDIT_LOG" = "SYS$ERRORLOG:ACMSAUDIT.LOG" "ACMS$AUDIT_OBJECT_ID" = "........�..1N�...LCCV01::......." "ACMS$DIRECTORY" = "$1$DIA0:[ACMS.ADB]" "ACMS$EDIT" = "SYS$COMMON:[SYSEXE]ACMSEDIT" "ACMS$ESC_RTN_IN_FORM" = "Y" "ACMS$FORMS_CACHE" = "SYSDSK:[ACMS.ADB.ACMS$CACHE.]" "ACMS$MULTIPLE_SUBMITTER_PLATFORMS" = "N" "ACMS$NOTICE" = "SYS$SYSDEVICE:[ACMS]ACMS_NOTICE.TXT" "ACMS$SYSDISK" = "$1$DIA0:" "ACMSAAF" = "SYS$COMMON:[SYSEXE]ACMSAAF.DAT" "ACMSDDF" = "SYS$COMMON:[SYSEXE]ACMSDDF.DAT" "ACMSQDF" = "SYSDSK:[ACMS.ADB]ACMSQDF.DAT" "ACMSUDF" = "SYS$COMMON:[SYSEXE]ACMSUDF.DAT"
4094.2		OHMARY::HALL	Bill Hall - ACMS Engineering - ZKO2-2	`Fri Jan 31 1997 12:38`	14
	The forms have to be built on the lowest version number of DECforms. DF V1.4 will not understand a V2.x form file. The caching of the form is done by ACMS (in VFSHR) and then the file spec is passed to DECforms. We have seen an isolated case where a partial form gets copied and then DECforms attempts to use it and it's no good. It seems to happen when there is more than 1 agent trying to copy the file at the same time. You can check the size of the form and compare it to the original. Bill
4094.3		KERNEL::PULLEY	Come! while living waters flow	`Mon Feb 03 1997 11:24`	15
	I'll check out that >1 agent trying to cache at the same time. I took a look at the image which is meant to be the form image. In both the cached copy, and the original image, they had:- image format major id: 02, minor id: 05 I don't know if that means they are the same version of forms, or if I'm just looking in the wrong place in the image. In the forms$trace files, it said it was trying to convert, but didn't mention that image at all. Might be because it hung that time--I'll perhaps see if I can try it again. The file seems to get cached OK and is the same size as the original. Steve.
4094.4		IFDL::RICE		`Tue Feb 04 1997 10:11`	35
	You can only tell what version the .FORM file was built on by doing a dump of the actual file. For example; A V1.4 .FORM looks like: $ dump/record=count=1 FORMS$DEMO_TM_FORM.FORM Dump of file FORMS$DEVEL_ROOT:[DEM.OBJ]FORMS$DEMO_TM_FORM.FORM;1 on 4-FEB-1997 10:03:34.13 File ID (10432,253,0) End of file block 14 / Allocated 16 Record number 1 (00000001), 159 (009F) bytes, RFA(0001,0000,0000) 20797261 6E694220 736D726F 66434544 00140001 FFFFFFFF 00000407 0000009F ................DECforms Binary 000000 352D342E 31562073 6D726F66 43454400 1BFFFFFF FFFFFFFF FFFFFFFF 6D726F46 Form.............DECforms V1.4-5 000020 FFFFFFFF FFFFFFFF FFFFFFFF 02050401 FFFFFFFF 34392D37 2E335620 5344202C , DS V3.7-94.................... 000040 FFFFFFFF FFFFFFFF 5E0703FF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF .......................^........ 000060 010000 1392FFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................................ 000080 A V2.1 .FORM looks like: $ dump/record=count=1 FORMS$DEMO_TM_FORM.FORM Dump of file FORMS$DEVEL_ROOT:[DEM.OBJ]FORMS$DEMO_TM_FORM.FORM;1 on 4-FEB-1997 10:05:13.53 File ID (9781,12,0) End of file block 15 / Allocated 16 Record number 1 (00000001), 159 (009F) bytes, RFA(0001,0000,0000) 64656E67 696C4120 736D726F 66434544 001C0001 FFFFFFFF 00000407 0000009F ................DECforms Aligned 000000 4544001B FF6E0903 02000102 00001498 01FFFFFF 6D726F46 20797261 6E694220 Binary Form..............n...DE 000020 FFFFFFFF FFFFFF30 31312D39 2E335620 53442030 2D312E32 5620736D 726F6643 Cforms V2.1-0 DS V3.9-110....... 000040 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................................ 000060 FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF ................................ 000080
4094.5	Some more info.	KERNEL::PULLEY	Come! while living waters flow	`Wed Feb 05 1997 11:09`	30
	Here's an updte straight from the customer. I'm not sure what the difference is between 1, and 4. They are looking into what's different about this form from the others, as I think it's only this one that fails. It's smaller than some that succeed. Is it worth trying a higher version of DECthreads? We have tried some tests and found the following. 1. f/end on latest version of O/S and Layered products and b/end on Previous versions (5.5-2, etc). Result Form errors. 2. f/end and B/end on latest versions of O/S and Layered products. Result Form errors. 3. f/end and B/end on latest versions of O/S and Layered products and form recompiled on system with latest Development versions of O/S and Layered products. Result Form caches. 4. F/end on latest version of O/S and layered product and b/end on previous version and form recompiled on system with previous Development versions of O/S and Layered products. Result Form errors. We tried point 3 a number of times by deleting the form and recaching, and was successful every time. Does this indicate a problem in the Forms-rt for version 2.1b ?
4094.6		IFDL::RICE		`Thu Feb 06 1997 10:47`	7
	From what you're saying in .5 it would appear to be a form conversion problem in DECforms V2.1, i.e., it cannot figure out how to use the DECforms V1.4 form in V2.1. There could be a real problem there that noone else has seen. We'd need the .IFDL that reproduces the problem and possibly more if the DECforms trace doesn't show the error occuring during the Enable calls conversion step. -Tim
4094.7		KERNEL::PULLEY	Come! while living waters flow	`Thu Feb 06 1997 12:37`	8
	Well they've just tryed, front and back ends on latest versions--(VMS v6.2, ACMS v4.1, DECforms v2.1b)--and the image built on v1.4 placed on both machines, I.e., where it would be cached to, and where it should be cached from. That was fine--no error. So it looks like convertion plus caching. I'll see what I can do in terms of getting info in like ifdl...
4094.8		IFDL::RICE		`Thu Feb 06 1997 12:43`	6
	I don't see how it can be both and I thought we were talking about .FORM files and not images? If you can't reproduce this in a non-distributed environment then the IFDL is useless. The problem would have to be with something to do with the distributed aspects. -Tim
4094.9		KERNEL::PULLEY	Come! while living waters flow	`Fri Feb 07 1997 06:18`	11
	I don't know. It's a file with a .exe on the end that satisfys analy/image that is being cached. So I've thought of it as an image file. Admittedly .0 talks about building forms. I didn't intend it to mean a .form file, just to mean that they'd got from an .ifdl to an .exe, and I'm not really a form person, so can't always remember exactly how you could take ifdl and produce something runnable. Anyway--reproduceable--I'll try.
4094.10		CLUSTA::HALL	Bill Hall - ACMS Engineering - ZKO2-2	`Fri Feb 07 1997 07:17`	30
	An IFDL is translated to a .FORM file, which can be used at run-time. The binary of the form can be extracted to an object format and linked with other form objects to produce a .EXE. This .EXE is not a runable image but is instead a shareable image (produced by LINK/SHARE). A .FORM file is read into memory and then closed. This form stays in memory until it is no longer is use (meaning the last user that used it has exited ACMS). A .EXE is paged into the process by VMS as needed. A .EXE is never released, since VMS does not provide a mechanism for this, so the image remains as long as the process remains. The application specifies whether the form to be used is a .FORM or .EXE. The filespec is sent on the call for the exchange step. The VFS code will copy the appropriate image to the local system and will then pass the local filespec to DECforms. The form has to be translated by the lowest version in use. Since you are using DECforms V1.4, this means that the backend system must have the forms as translated by V1.4 on that system in order for them to be used. DECforms V1.4 does not understand the format of a DF V2.x form file. When DECforms does the enable, and form file is older than the current version (say V1.3) is has to do a conversion of the form into the current format. DF V1.4 cannot convert a DF V2.x form. Bill