file diretory parse list in the mh cl 6.1

[Bob Schmid]

we are not seeing a keyed list passed in as the mh into the directory parse tcl proc as documented by the following on INFOR:

Obviously we are not interpreting correctly…can someone clear this up as

to what the following means and where it is “seen”?

T Cl6.1 Feature

Update to dirparse parameter format (12412)

Description

The dirparse parameter format has been updated for parsing a list of filenames and attributes sent to a TPS, so that a keyed list is sent into the TPS.

keylset fileNames file1.LENGTH 4567 file1.MTIME 1416347174 file2.LENGTH 322 file2.MTIME 1716347174 file3.LENGTH 8888 file3.MTIME 1416347999

{file1 {{LENGTH 4567} {MTIME 1416347174}}} {file2 {{LENGTH 322} {MTIME 1716347174}}} {file3 {{LENGTH 8888} {MTIME 1416347999}}}

There is no change for return list(filename list).

Note: This update changes the format of the Tcllist. You must modify your TPS code to get the filename list data from the list.

Topic

[Jim Kosloskey]

Just curious Bob -what are you seeing?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Bob Schmid]

message           : ‘Alcoa_test1.txtx0aAlcoa_test2.txtx0a’

running 611….not a keyed list…

Dirparse documentation a little vague ❓

[Bob Schmid]

fyi…the protocol in question if fileset ftp inbound

[Jim Kosloskey]

Did you check for getting extended information or just the file names?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Bob Schmid]

Jim…all we received was ” ‘Alcoa_test1.txtx0aAlcoa_test2.txtx0a’ ” …the typical list we would expect previous to cl 61

[Jim Kosloskey]

OK on Fileset/FTP you cannot specifiy getting extended information with the file names (like length, date/time).

So apparently you get a simple list (what we always got) instead of the keyed list described.

Frankly I consider this to be wrong. The Directory Parse UPoC should provide the same structure no matter whether extended information is requestoed or not. Moreover I think onbe should be able to find out if extended informaion was asked for.

An interesting side note. In 6.0 and perhaps 6.1 if one gets a extended list (list in the case of 6.0 – keyed list in the case of 6.1) one cannot return the same list one got it must be pared down to just file names in a simple list.

I also think this is wrong. My opinion is Cloverleaf should take back exactly what it gave me. But maybe that is just me.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Bob Schmid]

Jim

Thanks…..that cleared it up.

[James Cobane]

In 6.1.1, I don’t see the option to get the extended information on a fileset-local protocol.  There is the option for ‘List Full Directory’, but that doesn’t return a keyed list, it returns simply the filename, size, and timestamp, i.e.:

{{file1.data 14 1435343642} {file2.data 25 1435343642} {file3.data 105 1435343642}}

Without the ‘List Full Directory’ option, you get the same old file list as before.

Jim Cobane

Henry Ford Health

[Jim Kosloskey]

Ahh so the keyed list did not get deployed with 6.1.1 maybe it is in 6.1.2.

That list you see is what we get in 6.0 – broke our code.

But the keyed list will break everyone’s code as well so there is a rewrite in store for everyone. This is why I would like to get this right with one release so we don’t have to keep rewriting our code.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Max Drown (Infor)]

From R&D, the AR12412 is scheduled to CIS6.2, and there is a mistake in the release note of cis6.1.1.0.

Jim, can you please describe for me in greater detail what you mean? I’d like to submit an AR with your suggestions. Please include a use-case, too, if you don’t mind.

-- Max Drown (Infor)

[Jim Kosloskey]

Max,

I have no issue with using a list with keyed list entries for extended information like so:

{file1 {{LENGTH 4567} {MTIME 1416347174}}} {file2 {{LENGTH 322} {MTIME 1716347174}}} {file3 {{LENGTH 8888} {MTIME 1416347999}}}

This is certainly an improvement over the structure deployed in 6.0.

As long as this structure will be continued for any future enhancements. I do not know what those might be and there might never be any but the changes should not require existing code be rewritten in order to work (though noot exploit) any new enhancements. I think we are no different than any other customer in that we don’t have time to rewrite code so it will work the same way with a new release.

Thiis however does cause me in issue – the list above (with keyed list entries) nees to be able to be returned to Cloverleaf after the Dir Parse routine is completed.

I should be able to decide everything in the list is fine and return it unchanged or reduce the list to just file names and return it – either should work:

{file1 {{LENGTH 4567} {MTIME 1416347174}}} {file2 {{LENGTH 322} {MTIME 1716347174}}} {file3 {{LENGTH 8888} {MTIME 1416347999}}}

or

file1 file2 file3

Another benefit of returning the list/keyed list set is if Procs are stacked (which we do) at these UPoCs

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Max Drown (Infor)]

I submitted your suggestions to R&D.

-- Max Drown (Infor)

[Author]

Replies