Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

DCL Procedure fail reading ASCII file - Always get EOF

Go to solution

DCL Procedure fail reading ASCII file - Always get EOF

OpenVMS Alpha V7.2, DS20E.

Simple DCL command procedure to read a text file resulsting from a DIR/COL=1 and then create a loop to read each filename and rename it. If no rename (or copy or delete) the loop runs fine. However when a $rename command is included in the loop the procedure ignore any other instruction including ON ERROR, ON WARDING, etc. and goes to the EOF rutine. Generate the following error: "%DCL-W-SKPDAT, image data (records not beginning with "$") ignored". Processing one record at a time.

I have used this kind of loops before but the error message SKPDAT is strange in this circumstances.

Could anyone have seen this before?

Many thanks.

Angel Rosario

Included a command procedures to ilustrate the problem.

Re: DCL Procedure fail reading ASCII file - Always get EOF

By the way if the "RENAME" instruction is commented out the loop goes out and read the whole file.

What am I missing?


Trusted Contributor

Re: DCL Procedure fail reading ASCII file - Always get EOF

"%DCL-W-SKPDAT, image data (records not beginning with "$") ignored"

Hm, isn't that what you have in your comand procedure - lines not begining with "$"?

Also only the last "ON..." statement is in use and defines the action for the specified error level and more severe errors.

So if your last "ON" statement is "ON WARNING..." it is also used for ERRORS and SEVERE_ERRORS. If your last "ON" statement is for "ERROR" as in your case any warning causes a CONTINUE.

So, make sure all your DCL command lines start with a "$" and use "ON WARING..." only in your procedure if you want to take action on WARNING and more severe errors.

Honored Contributor

Re: DCL Procedure fail reading ASCII file - Always get EOF

SKPDAT means you had more data in your input stream than you had reads for, or your application punted before it got to the end of the data. The command processing for DCL went to read the next command, and it got a command that didn't start with a $. It got data.

Part of that is likely due to the odd formatting of those DCL commands. The $ is indented on many of those lines. Don't do that. The $ is in the first position on the command line.

Only one ON command works; when more than one ON is present, the last one is the winner.

Parsing the output of a DCL command is a bad idea. The format can be subject to change without notice.

Here's some DCL to process files from a directory:


READ has an /ERROR switch, and an /END_OF_FILE switch. Consider using both. (These override the last ON for this command, too.)

This particular DCL coding is risky practice:


as this DCL is an attempt to parse a filename. This parsing is how a number of folks wrote code that broke under, for instance, ODS-5. Better to use the system routines and to use f$parse here.

Always issue a CLOSE /NOLOG before issuing an OPEN, as that (defensive coding) practice means you won't get an already-open I/O channel. If a previous application punted without a CLOSE, subsequent OPEN operations can resume in mid-stream.

Do you have this AFP facility prefix registered with HP? If not, please don't use it.
Respected Contributor

Re: DCL Procedure fail reading ASCII file - Always get EOF

I would think that there is some confusion here. First, the /END_OF_FILE is a specific type of error condition which may be "overwriting" the ON_ERROR condition within the loop.

To check this, log the rename and see if there are problems there first. That may be a clue.

I second the first reply. Technically, the first character should be a "$". While you are using tabs to indent the looping code (good), I would have started with the $ and then the tab as shown below:

$ First executable line
$ Second line

Honored Contributor

Re: DCL Procedure fail reading ASCII file - Always get EOF

I can't read your code because windows thinks ".com" is executable, not text, and the local security rules won't allow it. When posting attachments, please label them as .TXT



To parse file specifications, please use F$PARSE. In this case:

$ record=F$PARSE(";",record)

will give you the filespec of the latest version, and will work for all filespecs, including ODS-5 filenames with embedded ";"

If you're worried about whitespace:

$ record=F$PARSE(";",F$EDIT(record,"TRIM"))

When generating lists of files using the DIRECTORY command, rather than /COL=1 try
/NOHEAD/NOTRAIL. As well as avoiding the header, trailer and whitespace, (so you don't have to write code to skip them), it includes the device and directory in every file specification, so your code is generalised to work across multiple directories.

Back in V1, DCL was a bit lax about presence of the "$" in command procedures. Technically it is a documented requirement at the beginning (column 1) of every executable command in a procedure. There are a few places you can still get away without it, BUT it's folly to leave it out.
A crucible of informative mistakes

Re: DCL Procedure fail reading ASCII file - Always get EOF

Guys, thank you very,very much. I'm a litlle rusty after about 10 years of no working DCL commands. You all basically had the answer.

The problem was fixed by moving the $goto loop: to the first column. I took this DCL from another example and left the tabs. I neverd did that, and will never go again.

The /NOHEADER and other ideas are extremely appreaciated. I forgot about those.

The F$PARSE is definitelly an excelente suggestion which I will implement as well as the other suggestion.

Thanks to all for your support.

We can close this.

Re: DCL Procedure fail reading ASCII file - Always get EOF

The problem was fix by moving the $GOTO instruction to the first column.

Tabs should not be used in the fashion used in this DCL procedure.

Excellent recomendation were given on this thread which are best practices for DCL procedures.

Thanks again to all.