OpenVMS Pro*C log files appearing in a single character vertical column.

Yes, we recompiled all the pro*c using included icu codes.

I have found more information and realize the problem is only when viewing the logfiles in the vms editor.  when I type the file (a dump) it displays normally.  also if I scp the file to another platform (i.e., windows) it displays normally.

The openVMS editor cannot handle UTF-8 (Either EDT/or TPU), just plain ASCII.
The file format might be a bigger issue.
Can you produce a dir/full of the file?

Here is a dir/full of one of the files with the issue.

ABCDEF_XXXX.LOG;82           File ID:  (5730,1205,0)
Size:            4/205        Owner:    [00000,XXXXXXX]
Created:     4-NOV-2009 06:00:01.00
Revised:     4-NOV-2009 22:25:05.50 (1)
Expires:    <None specified>
Backup:     <No backup recorded>
Effective:  <None specified>
Recording:  <None specified>
Accessed:   <None specified>
Attributes: <None specified>
Modified:   <None specified>
Linkcount:  1
File organization:  Sequential
Shelved state:      Online
Caching attribute:  Writethrough
File attributes:    Allocation: 205, Extend: 0, Global buffer count: 0, No version limit
Record format:      VFC, 2 byte header, maximum 0 bytes, longest 82 bytes
Record attributes:  Print file carriage control
RMS attributes:     None
Journaling enabled: None
File protection:    System:RWED, Owner:RWED, Group:RE, World:
Access Cntrl List:  (IDENTIFIER=PROD_READ,ACCESS=READ+EXECUTE)
                    (IDENTIFIER=BAN_CTRL,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
                    (IDENTIFIER=GROUPS_ACCESS,ACCESS=READ+WRITE+EXECUTE)
                    (IDENTIFIER=ORA_DBA,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL)
Client attributes:  None

Total of 1 file, 4/205 blocks.

And what does a dump/record=(start=1,count=10) ABCDEF_XXXX.LOG show?

My guess is that there are short records in this file. An editor doesn't read "line" but does read records.
With a VFC,2 Print carriage control records can exist that contain single characters (and show up a 'lines' in an editor) but dont advance the cariage (cursor). (you can specify a different count or start value).

The big difference between VMS ( & mainframes also) and unix (and like OS's) are that the they handle records
(defined chunks of data as unit of data) instead of unbounded streams of bytes.
The editor doesn't do formatting, just allow you to display & modify records.

To solve it you could try to create a different kind of file.
For unix compatibility try to create a stream-lf file either explicit in you programs or you could try implicit the the below
file description.

Try to copy/paste the following (not including the CTRL/Z, that is the character that needs to be typed there

CREATE T.FDL
IDENT   " 6-NOV-2009 13:11:41   OpenVMS ANALYZE/RMS_FILE Utility"

SYSTEM
        SOURCE                  OpenVMS

FILE
        ALLOCATION              24
        BEST_TRY_CONTIGUOUS     no
        CONTIGUOUS              no
        EXTENSION               0
        ORGANIZATION            sequential

RECORD
        BLOCK_SPAN              yes
        CARRIAGE_CONTROL        carriage_return
        FORMAT                  stream_lf
        SIZE                    0
<CTRL/Z>  (End of input)

CREATE/FDL ABCDEF_XXXX.LOG;

All files created after that (with that name SHOULD be stream linefeed files...)
Unless the are created with either explicit output format spec like VFC or
they are created with a different name and later renamed to this... then it's obviously too late.

Also in stead of using a record handler like an editor
try to use "type/page=save" and scroll with pageup & page down.

This is a different issue nothing to do with the editor, I took over the answeing, this is to stop the delete request.

This is a different issue nothing to do with the editor, I took over the answeing, this is to stop the delete request.

Hi Noci,  thanks for continuing the thread.  You are correct that it has nothing to do with the editor but everything in how the log file is being created by the pro*c w/icu coding.

Regarding the creation of the t.fdl file - where should it be located  (in my sys$login?) or in the directory where these log files get created?  thanks.

Here is my dump of one of th faulty records:

Dump of file BANNER$USER:[BANJOB]R1W8_PRSCOTT_FABCHKP_759588.LOG;1 on  6-NOV-2009 08:02:55.19
File ID (13987,1398,0)   End of file block 2 / Allocated 205

Record number 1 (00000001), 1 (0001) byte, RFA(0001,0000,0000)

                                                                      43 C............................... 000000

Record number 2 (00000002), 1 (0001) byte, RFA(0001,0000,0006)

                                                                      6F o............................... 000000

Record number 3 (00000003), 1 (0001) byte, RFA(0001,0000,000C)

                                                                      6E n............................... 000000

Record number 4 (00000004), 1 (0001) byte, RFA(0001,0000,0012)

                                                                      6E n............................... 000000

Record number 5 (00000005), 1 (0001) byte, RFA(0001,0000,0018)

                                                                      65 e............................... 000000

Record number 6 (00000006), 1 (0001) byte, RFA(0001,0000,001E)

                                                                      63 c............................... 000000

Record number 7 (00000007), 1 (0001) byte, RFA(0001,0000,0024)

                                                                      74 t............................... 000000

Record number 8 (00000008), 1 (0001) byte, RFA(0001,0000,002A)

                                                                      65 e............................... 000000

Record number 9 (00000009), 1 (0001) byte, RFA(0001,0000,0030)

                                                                      64 d............................... 000000

Record number 10 (0000000A), 1 (0001) byte, RFA(0001,0000,0036)

                                                                      2E ................................ 000000

Noci,

Actually each log file that is created by the 100's of Pro*c programs we have are all uniquely named when they are created (we append a timestamp and username and instance name to the file names for easier management), so your use of the fdl in creating a specific log file isn't feasible in this case of uniquely named files.

It was a great idea however.

Do you have any ideas on how we can force the stream_lf from inside the pro*c runtime utility?  

what is very frustrating is the the .lis files created by these pro*c programs are all stream_lf but the .log files that capture what the program is doing are not.

If you have a script that starts the Pro*c program, do you provide the logfile..?

btw, I named it t.fdl, you can keep it in a central repository (I guess there is a common directory there).
and name if stm-lf.fdl or so... ;-)

OK,
if you  have a script like


$ x:== $blah:[blah]proc_blah
$ x/log=myfile.log

then try:

$ x:== $blah:[blah]proc_blah
$ creat/fdl=where:stm-lf.fdl myfile.log
$ x/log=myfile.log

Probably the scripts are more complex, If you can post one here, I can look at it for you..
Otherwise post some relevant snippets. (it ' a few line around the start of your program...)

As a sidenote, try to prevent large directory files, it will ruin performance... (creating, and esp removing files from such a large directory).  directories containing > a few hundred files will hurt. They CAN contain thousands, but common wisdom dictates to limit the amount of files per directory.

Noci, you may be close to helping, but the comfile is a bit more complex as it is called from an oracle form and then creates another comfile that actually gets submitted to the queue.  Nonetheless, it is just a comfile, so let's do it.

the log file is assigned to sys$output so not clear on how to include my new stm-lf.fdl file.

Here is a snippet from the comfile where the logfile is being assigned:

$   WRITE COMFILE "$ OLD_ERROR = F$TRNLNM("""SYS$ERROR""")"
$   WRITE COMFILE "$ OLD_OUTPUT = F$TRNLNM("""SYS$OUTPUT""")"
$   WRITE COMFILE "$!"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG SYS$OUTPUT SYS$ERROR"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.LOG SYS$OUTPUT"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.DAT SYS$INPUT"

Here is a longer snippet:

$   WRITE COMFILE "$ OLD_ERROR = F$TRNLNM("""SYS$ERROR""")"
$   WRITE COMFILE "$ OLD_OUTPUT = F$TRNLNM("""SYS$OUTPUT""")"
$   WRITE COMFILE "$!"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG SYS$OUTPUT SYS$ERROR"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.LOG SYS$OUTPUT"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.DAT SYS$INPUT"
$   WRITE COMFILE "$!"
$   WRITE COMFILE "$! Submitted by Job Submission - ''JSTIME'"
$   WRITE COMFILE "$!"
$   WRITE COMFILE "$ JOBTORUN:=$GEN$EXE:''PROC'.EXE"
$   WRITE COMFILE "$ JOBTORUN -o ''TTIME'.lis ''UIPW'"

Then change:

$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.LOG SYS$OUTPUT"

to this:

$   WRITE COMFILE "$ CREATE/FDL=blah:stm-lf.FDL ''TTIME'.LOG"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.LOG SYS$OUTPUT"


You still need to place the stm-lf in nice place and change the blah above to point to it.
In the FDL maybe shange the allocate from 24 to 0 to preserve some space.

Okay, I tried this but the comfile that got submitted fails now so may be a simple fix:

$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG SYS$OUTPUT SYS$ERROR"
$   WRITE COMFILE "$ create/fdl=where:stm-lf.fdl ''TTIME'.LOG"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.LOG SYS$OUTPUT"
$   WRITE COMFILE "$ ASSIGN/PROCESS/NOLOG ''TTIME'.DAT SYS$INPUT"

When viewing the comfile that gets created, you see:

$ ORASID = F$TRNLNM("ORA_SID")
$!
$ ON CONTROL THEN GOTO FINISH
$! SET PROTECTION = (OWNER:RWED,S,W,G)/DEFAULT
$ ON ERROR THEN GOTO FINISH2
$!
$ OLD_ERROR = F$TRNLNM("SYS$ERROR")
$ OLD_OUTPUT = F$TRNLNM("SYS$OUTPUT")
$!
$ ASSIGN/PROCESS/NOLOG SYS$OUTPUT SYS$ERROR
$ create/fdl=where:stm-lf.fdl R1W8_PRSCOTT_FGRORGH_759608.LOG
$ ASSIGN/PROCESS/NOLOG R1W8_PRSCOTT_FGRORGH_759608.LOG SYS$OUTPUT
$ ASSIGN/PROCESS/NOLOG R1W8_PRSCOTT_FGRORGH_759608.DAT SYS$INPUT
$ SET DEF disk$user_arc:[banner.banjob]
$!
$! Submitted by Job Submission -  6-NOV-2009 10:10:18.45
$!
$ JOBTORUN:=$GEN$EXE:FGRORGH.EXE
$ JOBTORUN -o R1W8_PRSCOTT_FGRORGH_759608.lis xxxxxxxuser/yyyyyyypass
$ DEL/SYM JOBTORUN
$ MAIL/subj=R1W8_PRSCOTT_FGRORGH_759608 gen$com:job_completed.txt SMTP%"PRSCOTT@rice.edu"
$ DELETE R1W8_PRSCOTT_FGRORGH_759608.DAT;*
$ FINISH:
$!
$ DEASSIGN SYS$ERROR
$ DEASSIGN SYS$INPUT
$ DEASSIGN SYS$OUTPUT
$! DELETE R1W8_PRSCOTT_FGRORGH_759608.COM;*
$ EXIT
$ FINISH2:
$ MAIL/SUBJ=JOB_FAILED_R1W8_PRSCOTT_FGRORGH_759608 gen$com:job_failed.txt  SMTP%"PRSCOTT@rice.edu"
$ SUBMIT/NOIDENTIFY/NOPRINT/LOG GEN$COM:ERROR.COM /PARA=(NOPRINT, R1W8_PRSCOTT_FGRORGH_759608)

duh.  let me put location in ...

does the logical where exist??

Very interesting results.  there are two log files created (vms has version control).  the first one (R1W8_PRSCOTT_FGRORGH_759609.LOG;1)  has STREAM_LF record format but is an empty file.

the second one (R1W8_PRSCOTT_FGRORGH_759609.LOG;2) has the VFC record format and contains the vertical characters.  

LOL.

I thought for certain this would work based on my research.  I can't believe it doesn't retain the record format from the 1st version.  this is very puzzling.

The first one is create/fdl at work, the 2nd should have picked it up....
Here is a C-source that can convert the file for you.
  http://www.mpp.mpg.de/~huber/vmssig/src/C/VFC2CR.C

this is still an issue - the ICU/Unicode c runtime must have a parameter set somewhere that is causing the variable VFC format.

adding a rogue c program to our libraries isn't an option at this time as it wouldn't pass our change managment/audit requirements.

I've resorted to a bandaid fix (posted on one of the application vendor's listserves) - that is, I use a simple vms comfile to rewrite the logfile immediately after creation and then purge the "bad" logfile.  I run this comfile and pass the log file name as a parameter to it.  

Usage:
@LOGFILE-FIX.COM REPORT.LOG

Comfile:
LOGFILE-FIX.COM
$ ! This fixes the Banner 8 issue of Pro*C program output
$ ! being written to the log file with 1 character per line.
$ !
$ open/read infile 'P1
$ open/write outfile 'P1
$ outtext = ""
$ !
$Loop:
$ read/end_of_file=Done infile intext
$ outtext = outtext + intext
$ if f$length(intext) .ne. 1
$ then
$    write outfile outtext
$    outtext = ""
$ endif
$ goto Loop
$ !
$Done:
$ close infile
$ close outfile


So, unless someone has an idea on where to fix the c program logging mechanism when submitted in batch, I'll close this one as unsolved.

Yes, we use the decc rtl libraries.

I'm going to give this a try in our devl environment and report back.  

Adding this symbol to the login.com for the account that runs the C programs fixed the logfiles!!

thank you for your perseverance!