topic Re: dnum() returns zero for a non-empty folder in SAS Programming

dnum() returns zero for a non-empty folder

Ame4s — Fri, 02 Jun 2017 18:10:36 GMT

I'm reading members of zip files. One contains many files but dnum() returns zero. How can I get it to give the correct count? And loop through the members.

filename ZIPFILE SASZIPAM "&in_dir.&fn";

filename comboxml "&in_dir.&fn2";

data contents(keep=memname) documents;

fid=dopen("ZIPFILE");

file print;

put "&fn";

put fid=;

if fid=0 then

stop;

memcount=dnum(fid);

put "memcount=" memcount;

do i=1 to memcount;

put i=;

memname=dread(fid,i);

output contents;

if index(memname,'.xml') > index(memname,'/') then do;

put "XML member";

end;

put i= memname=;

end;

rc=dclose(fid);

run;

Re: dnum() returns zero for a non-empty folder

Ame4s — Fri, 02 Jun 2017 19:01:37 GMT

It is the largest zip file and has over 70,000 files.

Re: dnum() returns zero for a non-empty folder

ballardw — Fri, 02 Jun 2017 23:07:36 GMT

I don't think I would expect the single file of ZIP format to contain the actual directory or file markers for the operating system that the external file functions such as DOPEN and FOPEN would expect to find.

Do you have enough space to extract the files from the ZIP? Or use another tool to search for the file names you want.

Re: dnum() returns zero for a non-empty folder

Ame4s — Fri, 02 Jun 2017 23:47:46 GMT

Using filename with SASZIPAM worked with other zip files to read the contents. One of them had over 50,000 files. (Many of the files are tiny.) It's just this one that doesn't work.

I was able to get VBA to read the file members but SAS won't.

It'd be much preferable to get the current tool to work than to set up something else for one file. At some point I'll have to do it if no solution is available.

Re: dnum() returns zero for a non-empty folder

ballardw — Mon, 05 Jun 2017 17:02:35 GMT

Were both Zip files created with the same software and options?

From online documents:

SASZIPAM is a tool used internally for the SAS install process. It is not supported for customer use outside the install process. While it is mentioned on non-SAS information sources and some customers have been using it on the FILENAME statement, support is not available from SAS Technical Support.

No documentation is available.

If you experience difficulties, try one or more of these options:

     1.  Do not try to read an archive file containing more 
         than one file.
     2.  Read an archive file created only by WinZip. ZIP 
         files created by other tools may produce an I/O error.
     3.  Add LRECL=32767 to the FILENAME statement.
     4.  Contact the source of your information on SASZIPAM.

Re: dnum() returns zero for a non-empty folder

Ame4s — Mon, 05 Jun 2017 17:24:07 GMT

Hello ballardw,

I don't have specific knowledge of the creation. Both files came from the same source, along with several dozen other files successfully read with the same method. The one that fails is simply the largest.

Thank you.

Re: dnum() returns zero for a non-empty folder

ballardw — Mon, 05 Jun 2017 19:56:33 GMT

The moral of the story is that the SASZIPAM engine is intended by SAS only for use in the install process. Any other use is not supported and likely not to have any fix and likely not to be an easy one.

Use of undocumented procedures or features is contra-indicated for critical operations.

Since you say this is the "largest" from "the same source" it may be that they had used Winzip for the other files but not for this set because of size. Or they changed options to allow it to handle the size. Or the original file system was different for this file and could not use WinZip. Or the longest Path descriptor doesn't work correctly for some reason. Or this is only the first file with followups to be in the same format.

I suggest contacting the source and having them describe what was different in preparing this file and check if Winzip could be used.

Re: dnum() returns zero for a non-empty folder

Ame4s — Mon, 05 Jun 2017 20:17:22 GMT

Thank you for your help.

I ended up extracting the files to read them since contacting the source has yet to be timely.