Table Output Under VAX VMS

This is a question for people who have installed NONMEM under theVAX VMS operating system.Jim Johnson of Glaxo has a problem with output to Table files whenthe number of characters exceeds 132. NONMEM crashes with a stackdump. Here is an example of what is being tried:$TABLE list ... NOPRINT FILE=filenameWhen the list exceeds a certain number of variables, the crash occurs.He can probably make things work by modifiying the following code, which occurs in two places in NONMEM subroutine OFILES: OPEN (UN(9),FILE=PATH(1:I-1))He thinks he will have to change these two lines as follows: OPEN (UN(9),FILE=PATH(1:I-1),RECL=32767,RECORDTYPE='VARIABLE', ORGANIZATION='SEQUENTIAL')Has anyone else encountered this problem? If so, have you tried this orsimilar changes to NONMEM source code? Is there any way to avoid thecrash without modifying the source code, for example by specifyingthese paramenters on VMS control statements or FORTRANinstallation-time defaults? (He would prefer to avoid modifying thesource code.)Please respond to me, and I'll forward your comments to Jim.

I just tried it myself and got the following error message:---REV$ @nonmem%FOR-F-OUTSTAOVE, output statement overflows record unit 9 file U1:[DAVID.NM.NT]TABOUT.DAT;1 user PC 0011F80D%TRACE-F-TRACEBACK, symbolic stack dump followsmodule name routine name line rel PC abs PC 0017A222 0017A222 0017A12F 0017A12F 001777D9 001777D9 00175DD8 00175DD8OUTPT OUTPT 337 000007BD 0011F80DFINAL FINAL 100 00000283 0010C6BBNONMEM NONMEM 108 0000023E 0011860E---I hadn't used this option before.No suggestions at this point, just confirming the problem.David Bourne

This is in response to your question about NONMEM under the VAX VMS operating system. The purpose of his endeavor is vague but I hope the following willprovide some help. Usually in VMS, the only time printing more than 132 characters on a line causesproblems is when the device used is a line printer. While writing to a file,RMS, Record Management System (the module that controls file I/O), will allowascii formatted records greater than 132 characters in length, I believe thedefault maximum length is 32k. In the past, I have printed into files, linesthat were in excess of 300 characters using a FORMAT statement that specified thelengths of the fields. However, when the number of fields that is to be printedexceeds the number specified in the FORMAT statement or the record length of thedevice, VMS will print the remaining variables on the next line using the sameformat over again or stop sending characters (depends on the device; disk,printer tape, screen, etc). I've encountered similar stack dumps or crashes with other programs the madeheavy use of ARRAYS as in NONMEM. These problems were traced to array accesserrors when an array index was a variable that was changed by the program. Ifthis is the problem then the array specifications of TEMP and TLAB in OUTPT andelsewhere may need changing (he has more fields and/or records than what thearrays can handle). I would need more information from Glaxo to be certain:specifically, the traceback of the crash (link the program using the "/TRACEBACK'option, run it until crash, save the screen dump), the NMTRAN statement used, thenumber of observations and fields in the table (the NONMEM output prior to thecrash), and the values of the array indexes from the OUTPT module during the run(may have to use the debugger or this one). AS far as the OPEN statement he inquired about. The RECORDTYPE='VARIABLE' willprefix each record with a count field containing the record length and will notappend any carriage control to it (this does not created a printable file, itwould need reformatting). I suggest using RECORDTYPE='STREAM' and addingFORM='FORMATTED' in the OPEN statement to obtain the results that I think hewants. The STREAM value allows variable length records and will add the carriagecontrol to the end of the records (adds the CR-LF characters). The FORMATTEDpart is to insure that RMS creates the proper file format (something to do withthe file header). I'm not sure but I don't think that any VMS control statements will help in thiscase. Also, any changes to FORTRAN's install-time defaults or to the run-timelibraries may affect the operations of other programs and should be approachedwith caution. In my opinion, changing the source code is probably the best option.Steve Hege

I agree with Steve. The source must be modified. We havenot done this at UOP, and this is probably because PaulWilliams has not exceeded the 132 column limit.When I create text files, I create them with CARRIAGECONTROL='LIST', RECL=nwhere "n" is the maximum record size allowed. I have nottested this with NONMEM, but it is what I would try first.Hope this helps.-- Ed

Jim Johnson says: I believe that I have solved the problem with the Output file recordlength. I modified the OPEN(UNIT(9)) statement in the OFILESsubroutine to add the statement RECL=32762. It works well!!!.