Anonymous | Login | Signup for a new account | 2024-11-21 14:19 CET |
My View | View Issues | Change Log | Roadmap | Search |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000797 | FL5 | 2.2 Subprogram FLUC (CONV) | public | 2016-03-31 12:55 | 2016-04-07 14:29 | ||||
Reporter | Falk Reichbott | ||||||||
Assigned To | Mykhailo Moldavskyy | ||||||||
Priority | high | Severity | major | Reproducibility | always | ||||
Status | resolved | Resolution | fixed | ||||||
Platform | System z | OS | z/OS | OS Version | V1R13 | ||||
Product Version | 5.1.10 | ||||||||
Target Version | 5.1.11 | Fixed in Version | 5.1.11 | ||||||
Summary | 0000797: Read of undefined datasets in FIO.BLK() without FCRBLK does not work with CNV.PGP() | ||||||||
Description | Only if FCRBLK is used CNV.PGP() works fine in other case (if length fields collected) CNV.PGP() results in format errors or the remaining rest is to big for the rest buffer. It looks like that the total data length of a matrix don'tfit with the sum of the record length fields. Also for read.binary() the FRCBLK switch must be activated to get undefined datasets up and running with the PGP component. The same problem could be happen with all non record oriented conversion modules which using the total data length. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | |||||||||
Notes | |
(0000966) Falk Reichbott (administrator) 2016-04-04 16:53 |
The read with or without FRCBLK results in different data blocks. With FCRBLK a block is complete filled with data and the rest of an record is save for the next block. Without FRCBLK only complete records are saved in one block. There will be no rest, because the table with the length fields must be correct. Based on this it could be, that the repackaging of compressed data streams in the PGP component could have a bug. |
(0000967) Falk Reichbott (administrator) 2016-04-04 16:58 |
The block size will be expanded to the next multible of the record length greater then 64kB. This means that all blocks are filled with 37 records, if each record/block of the undefined file 1800 byte long. |
(0000968) Falk Reichbott (administrator) 2016-04-06 18:37 |
The issue is related to an error in the PGP component. In a certain situation of record length, block length, internel block size and PGP packet length (body size) a wrong behavior was implemented. The issue will be fixed with revision 5.1.11 of FLAM available in few weeks. |
(0000969) Falk Reichbott (administrator) 2016-04-07 14:29 |
Fix PGP read/info where packet end is on block end |
Issue History | |||
Date Modified | Username | Field | Change |
2016-03-31 12:55 | Falk Reichbott | New Issue | |
2016-03-31 12:55 | Falk Reichbott | Status | new => assigned |
2016-03-31 12:55 | Falk Reichbott | Assigned To | => Falk Reichbott |
2016-04-04 16:53 | Falk Reichbott | Note Added: 0000966 | |
2016-04-04 16:57 | Falk Reichbott | Assigned To | Falk Reichbott => Mykhailo Moldavskyy |
2016-04-04 16:58 | Falk Reichbott | Note Added: 0000967 | |
2016-04-06 18:37 | Falk Reichbott | Note Added: 0000968 | |
2016-04-07 14:29 | Falk Reichbott | Note Added: 0000969 | |
2016-04-07 14:29 | Falk Reichbott | Status | assigned => resolved |
2016-04-07 14:29 | Falk Reichbott | Fixed in Version | => 5.1.11 |
2016-04-07 14:29 | Falk Reichbott | Resolution | open => fixed |
Copyright © 2000 - 2024 MantisBT Team |