|
View previous topic :: View next topic
|
| Author |
Message |
SRICOBSAS
New User
Joined: 07 Dec 2015
Posts: 19
Location: India
|
|
|
|
Hi,
I am a J2EE developer and I am involved in a project for Java interfaces to z/OS JES2 job spool.
I work for a vendor company whose client has z/OS v 1.10 installed on their end with JES2 as the job subsystem environment.
Neither anyone in my team nor in my company directly interact with the client's z/OS team on a technical basis. For our projects the client provides us APIs (to retrieve info from JES2), screenshots, joblogs e.t.c with which we can decide what JES2 fields / parameters / info we need for our Java tools
I would be grateful if the z/OS experts can help me out on an issue I am stuck with (there is no one here who has knowledge of z/OS or JES2)
REQUIREMENT: I need to populate an excel file with list of all sdsf jobs and for each job:
the total CPU time consumed
total no of lines / records written AND
the actual DASD disk size they occupy
Based upon the above certain recommendations have to be made.
For the CPU time I have APIs which can give me the "ST-TIME" and "END-TIME"
A JES2 field "Rec-Cnt" gives me the total no of lines / records written
And lastly for the total job size (.i.e total size occupied by all datasets in the JES2 job) I saw "Byte-Cnt" for each dataset (JESMSGLG / JESJCL / JESYSMSG / SYSPRINT e.t.c).
PROBLEM: Total of "Byte-Cnt" does not match total of Windows disk size for all downloaded individual JES2 job datasets.
For example totalling the "Byte-Cnt" for a JES2 job log gives me 313 KB. I called another API which actually downloaded the individual datasets and totalled their Windows disk sizes. This total is 503 KB
There is another API which combines all the dataset content into 1 file (the API description is "Print data set using Open Print Data Set panel"). This combined job log is much higher in size- 607 KB
So I am facing a mismatch between the SDSF reported size and the actual Windows disk size.
Everytime I populate the Excel I cannot download the individual JES2 job datasets and calculate their Windows disk sizes. I am looking for a JES2 field / column which can give me the correct DASD disk size (should match the Windows disk sizes as and when a job is downloaded)
SOME THOUGHTS: I have the dataset record count with me. If there is a JES2 field which can give me the record length (LRECL or something like that) for all the datasets in the JES2 job then I can multiply them with the record count and try getting an accurate job size.
Would appreciate any help in this regard. |
|
| Back to top |
|
 |
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
I work for a vendor company whose client has z/OS v 1.10 installed on their end with JES2 as the job subsystem environment.
|
pretty outdate system 
| Quote: |
| ... (there is no one here who has knowledge of z/OS or JES2)... |
then Your company has no reason to handle business on a platform for which it does not have the knowledge
we reply
ON OUR OWN TIME
FOR FREE
Your organisation gets paid for its services we do not  |
|
| Back to top |
|
|
steve-myers
Active Member
Joined: 30 Nov 2013
Posts: 917
Location: The Universe
|
|
|
|
| SRICOBSAS wrote: |
... SOME THOUGHTS: I have the dataset record count with me. If there is a JES2 field which can give me the record length (LRECL or something like that) for all the datasets in the JES2 job then I can multiply them with the record count and try getting an accurate job size.
Would appreciate any help in this regard. |
It cannot be done. Each logical data set has an LRECL attribute which describes the maximum length of each logical record. However, JES2 trims trailing blanks from each logical record before it stores the record in its SPOOL data set. So each logical record potentially has a different length, so job LRECL (which does not exist, anyway) times output lines is meaningless. Each line has a 2 byte length attribute (if I remember correctly) that counts against its storage space - JES does not use UNIX style line termination characters - and most (if not all) records have a carriage control character, which your application may see, that also counts against the byte count.
Another potential problem is in data sets stored as "advanced function printing" (AFP) data sets. AFP is, roughly speaking, the IBM sort of equivalent to PDF, though it is much more complex. In these data sets each "logical record" usually amounts to one physical output page. And there may be non-printing records in the data set. |
|
| Back to top |
|
|
SRICOBSAS
New User
Joined: 07 Dec 2015
Posts: 19
Location: India
|
|
|
|
Hi All,
I figured out the problem. Issue was when the job spool datasets get downloaded on Windows there are extra spaces at the end of each line which increase the byte count. I patiently deleted all the trailing blanks from each downloaded dataset and ran a byte count on MS Word and the sizes matched with the JES2 Byte-Cnt values.
I thank Steve-Myers for several valuable inputs he had given:
JES2 trims trailing blanks from each logical record
JES2 appends a carriage control character which is 2 bytes (at the end)
JES2 stores datasets in AFP (Advanced Function Printing)
In AFP each logical record usually amounts to 1 physical output page.
I will keep all these in mind going forward
Enrico wrote: "then Your company has no reason to handle business on a platform for which it does not have the knowledge".....
I wish my management thought on the same lines. Small vendors like my company gleefully take up any small project they come across forcing their employees to upgrade their knowledge. They dont wish to invest in specialists who come at a high price.
In any case I thoroughly searched Google before I posted my topic here. Though of course I missed out checking on the simple trailing spaces thing.
Anyway requesting the moderator to close this thread. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
what look and probably are harsh comments are seldom addressed to the TS
who, as in this case is just the victim, not an active partner in crime  |
|
| Back to top |
|
|
|
|
