Extracting data from Enscribe file

[Sabarinathan Sundaresan]

Dear All,
I am new bee to this technology, I am working on a project where I need to pull data from Enscribe file to flat file, any help on this is greatly appreciated.

Best Regards and Thanks,
Sabarinathan Sundaresan

[wbreidbach]

If you just want to copy an Enscribe file 1:1 to a flat file, FUP would be the correct tool. If you want to do something else you need to explain that more specific.

[Shiva]

Hi Sabari,

Do you mean from Tandem to Windows PC? Is that what you mean by a FLAT file? Only with more information on what you want to accomplish, any answer would be useful to you.

Let us know what you exactly what to do.

[Sabarinathan Sundaresan]

Thanks to all,
I want pull they data from Enscribe file and share with other interface team in a flat file in formatted form. Like Below,

Student_Name|Student_AGE|Student_Mark
XXXXXXXX | 26 | 100

[Shiva]

Okie, so in a windows PC. You can just do an SFTP or FTP whichever is available in your platform. FTP can get you .txt files but SFTP's .TXT files have the carriage return value to be a bit different. So you can use .doc, .docx or .xls or even .csv - But since you say 'in a formatted form' you don't want to just share the ENSCRIBE file just like that. In that case, you can write an ENFORM to produce comma separated values, with the fields in ENSCRIBE file which you want the interface team to look at. But for that you need the DDL and other details.

Hope this helps. Let us know if you require more details.

[Shiva]

As a second thought, you can even Connect - Direct it, if it is available in your system. Or you can mail it too (depends on the mailbox capacity as much as of the size of the file you want to send). But for any of these, the first step looks like you have to write an ENFORM to pick out the fields you want your interface team to look at. Decide on them and write one. Transferring files to a windows server location is not going to be really difficult.

[wbreidbach]

Am Freitag, 20. März 2015 18:04:51 UTC+1 schrieb Shiva:
> As a second thought, you can even Connect - Direct it, if it is available in your system. Or you can mail it too (depends on the mailbox capacity as much as of the size of the file you want to send). But for any of these, the first step looks like you have to write an ENFORM to pick out the fields you want your interface team to look at. Decide on them and write one. Transferring files to a windows server location is not going to be really difficult.

If you want to share the data that flat file might have the problem of synchronizing the contents. If anything is changed in the original file, everybody needs a new version of the flatfile. I agrre, that ENFORM would be the best tool to create such a file but you need the ddl description.
There are some ways to avoid tha synchronizing problem:
The oldest version is using ENABLE. ENABLE creates a Screen Cobol program that can be used to access and maintain the Enscribe file using a 6530-emulation. This is a very simple way but requires the ENABLE product on your system.
Another way would be loading the data into an SQL table. If you have ODBC or the much better ODBC/MX installed on your system, this table can be accessed using standard products like MS Access, MS Excel and so on. You just need SQL/MP or SQL/MX and ODBC.

[Sabarinathan Sundaresan]

On Friday, 20 March 2015 22:32:48 UTC+5:30, Shiva wrote:
> Okie, so in a windows PC. You can just do an SFTP or FTP whichever is available in your platform. FTP can get you .txt files but SFTP's .TXT files have the carriage return value to be a bit different. So you can use .doc, .docx or .xls or even .csv - But since you say 'in a formatted form' you don't want to just share the ENSCRIBE file just like that. In that case, you can write an ENFORM to produce comma separated values, with the fields in ENSCRIBE file which you want the interface team to look at. But for that you need the DDL and other details.
>
> Hope this helps. Let us know if you require more details.

Dear All,
Thanks, I able to transfer the files using ftp.Since my table has 70+ columns the buffer size is 130 byte , I unable to pull all values. i am trying with Convert ... can you help me on this.

[Sabarinathan Sundaresan]

On Friday, 20 March 2015 22:32:48 UTC+5:30, Shiva wrote:

> Okie, so in a windows PC. You can just do an SFTP or FTP whichever is available in your platform. FTP can get you .txt files but SFTP's .TXT files have the carriage return value to be a bit different. So you can use .doc, .docx or .xls or even .csv - But since you say 'in a formatted form' you don't want to just share the ENSCRIBE file just like that. In that case, you can write an ENFORM to produce comma separated values, with the fields in ENSCRIBE file which you want the interface team to look at. But for that you need the DDL and other details.
>
> Hope this helps. Let us know if you require more details.

Dear Friends,
Thanks for your valid input, i will try ODBC in other side along with Convert

[Sabarinathan Sundaresan]

Dear Friends,
Is there any way I can increase the ENFORM buffer size to pull lengthy row.

[wbreidbach]

Unfortunately Enform is limited to 132 characters. What you could probably do is writing the Enform-output to an unstructured file and use FUP to produce an Enscribe file with a recordlength of a multiple of 132:
fup copy <enform-output>, <enscribe-file>, recin 396, recout 396
This only works if the Enform-output is an unstructured file!!!

[Tone]

This may be a bit convoluted but might help.

Create multiple enform reports. For example, first report
contains fields 1 through 25, second report has fields 26
through 50, and third report has the rest. Then switch to
OSS and combine them to one file.

Here is an example of concatenating reports t1,t2 and t3 into t4.

$SYSTEM.TEST 13> osh
/home/user: cd /G/system/test

/G/system/test: cat t1
aaa,bbb,ccc,ddd
mmm,nnn,ooo,ppp

/G/system/test: cat t2
eee,fff,ggg,hhh
qqq,rrr,sss,ttt

/G/system/test: cat t3
iii,jjj,kkk,lll
uuu,vvv,www,xxx

/G/system/test: paste -d"," t1 t2 t3 >t4

/G/system/test: cat t4
aaa,bbb,ccc,ddd,eee,fff,ggg,hhh,iii,jjj,kkk,lll
mmm,nnn,ooo,ppp,qqq,rrr,sss,ttt,uuu,vvv,www,xxx

/G/system/test: exit

$SYSTEM.TEST 14> fileinfo t*

$SYSTEM.TEST
CODE EOF LAST MODIFIED OWNER RWEP PExt SExt
T1 101 54 24MAR2015 9:54 20,248 NUNU 14 14
T2 101 54 24MAR2015 9:55 20,248 NUNU 14 14
T3 101 54 24MAR2015 9:55 20,248 NUNU 14 14
T4 180+ 96 24MAR2015 9:55 20,248 NUNU 28 14000

You can then FTP T4 (in binary) to the external system.

[Sabarinathan Sundaresan]

Dear Team,
Thanks for your valuable inputs. I am working on your inputs.

Thanks onceagain.

[Shiva]

That was a really good tip, Tone! Thanks a lot. Noted. :)

[Keith Dick]

Shiva wrote:
> That was a really good tip, Tone! Thanks a lot. Noted. :)

The general technique of going to OSS to use some of the tools there is a good one.

This particular suggestion is missing a step or two. ENFORM cannot, as far as I know, write a report to an Edit file, and this tip assumes the reports are in Edit files. You could send the reports to a spooler holding location, then use PERUSE to copy the spooler jobs to Edit files. Then you could combine them using paste. I imagine you would want to use -d " " rather than -d "," because an ENFORM report puts spaces between its columns, not commas. You might also need to put a space at the start of the lines of reports 2 and up so that you are sure the last column of one report and the first column of the next report have the normal separation.

Another approach which I don't remember seeing anyone mention would be this:

Write one report that using / in the target list to divide report into multiple lines per record.
Send the output to an unstructured disk file.
Copy that unstructured disk file in OSS to an OSS text file, adding a newline after each n*132 characters.
Use the OSS cut command to drop out the spaces that pad each section of the combined lines to 132 characters.

I have not actually tried this approach, but I am pretty sure it will work, unless ENFORM has a limit on the total length of a line it can handle, even when it is divided into multiple output lines.

Suppose the 70 fields in the original file would require around 700 bytes if they were displayed in a single line.

Write the ENFORM report to list all of the fields in a single LIST statement, but put a / in the target list at each point where the report line would exceed 132 columns. The / makes ENFORM put the following items on the next line of the report. You put commas around it, just as if it were a field name:

LIST field-1, field-2, ... field-k, /, field-m, ... field-s, /, field-t, ... ;

Suppose for this example, the field were spread out into 7 lines.

Unless any single field is longer than 132 characters, this approach will allow you to produce a single ENFORM report that contains all of the data, but each input record's values will occupy several 132-byte segments of the output file.

Make ENFORM put the report into an unstructured file.

Use this OSS command to convert the unstructured file to an OSS text file:

dd if=/G/vol/subvol/file ibs=924 cbs=924 conv=unblock | cut "1-127 133-255 265-366 397-509 529-615 661-794 793-" >new-report.txt

This assumes the unstructured file into which ENFORM wrote the report is named $vol.subvol.file. The /G/vol/subvol/file is the way to refer to a Guardian file from OSS. The /G must be a capital G. The rest may be upper or lower case.

The value 924 is 7 times 132, the total size the 7 lines of the report occupy (this would change depending on how many lines are needed to display each input record).

The ranges after the command "cut" say which columns of the combined report line contain data you want to keep in the final file. After the dd command combines the several 132-byte segments into one line, there will be sections of the line that contain the spaces that were at the end of each of the 132-byte segments. Each of the ranges should start at 1+n*132. The end value of each range should be the start value plus the number of characters that line of the report occupies, plus 1 (to make sure the first value on the next line has two spaces between it and the last value of the previous line). In the above example, the beginning of each range is correct, but I just made up the lengths of each line to keep. You can omit the end column of the last range. That will make it take the rest of the line, and the conv=unblock in the dd command will make it trim trailing spaces from the line before sending it to cut.

Computing the ranges will be a little tedious, but you only have to do it once for a given report.

The above example sends the final result to the file new-report.txt in the current working directory. You can change that name to whatever OSS file you like.

[wbreidbach]

As I said before this can be done much more easy using FUP:
Create an unstructured file using FUP
Create an Enscribe file using FUP with a recordlenggth of 4062.
Write the complete Enform-report to the unstructuted file. The manual says that Enform writes fixed-length records of 132 per default. a shorter recordlength is possible, but it would be a fixed length anyway.
Given Keith's example the Enform report contains 7 lines for each record. The a
FUP COPY <unstr.file>, <Enscribe file>, recin 924, recout 924
would produce an Enform file containing 1 record for each record in the source file. This can be easily downloaded to a workstation using FTP with the correct parameters.

[Keith Dick]

Certainly that approach will work, though it usually would give a result with a varying amount of spaces between columns in the file, unless you happen to be able to arrange for the fields in each portion of the report line to take up the same amount of space, since the lines will be space-padded to 132 characters. Of course, those extra spaces could be removed using a cut command, or some other method, after transferring the file out of the NonStop system. So, to get the same result, about the equivalent amount of effort would be required for the approach of copying to an entry-sequenced file and the approach I suggested.

The entry-sequenced file approach is limited to a total line length of 4062, but that probably would be suitable for any ENFORM report, so that probably isn't an important difference. It might matter for other, similar problems. I think both approaches would have difficulty if any of the fields were too long to fit on a 132-character line. I don't know how often such long fields occur in real cases. An approach that moves the data to a SQL table and uses ODBC and a PC-based reporting tool to produce the report might be better able to deal with fields longer than 132 characters, though I'm not familiar with PC-based reporting tools, so maybe they wouldn't deal well with long fields, either. An approach using a PC-based reporting tool might be better for other reasons, as well.

One difference that might matter to some people is that, while using FTP to move the contents of a structured file to another system probably works, it feels a bit outside the area of what is a natural use for FTP, so I would prefer an approach that does not rely so much on a feature outside the mainstream. That probably doesn't bother most people.

The main reason I posted my approach was to show how to apply the approach Tone mentioned of making use of OSS tools with files originating in Guardian in a way a bit more suited to the original poster's problem. The approach Tone showed probably would work with the additional steps I described to get the ENFORM reports into Edit files, though trailing spaces in the values of character fields could make the line lengths of the lines in an Edit file not be all the same, so the values of the fields in the end result sometimes would not always line up in columns properly, and so would not be as suitable a result as either the approach using an entry-sequenced file or the approach I described.

[wbreidbach]

As long as OSS is availeble and the user is somewhat familiar using OSS, Keith's solution is the more flexible one.
BTW: If you need a file that can be easily transferred using FTP, copy the structured file to an unstructured file with padchar %H0a, like
fup copy <Str.file>, <unstr. file>, recin 924, recout 925, pad 10
The resulting file is a standard text file.

[Sabarinathan Sundaresan]

Thanks to Keith and wbreidbach,
I will try your methods and let me update.As of now I am testing with Tone's idea.Its working.But I needs to work with a table that has 99 columns.