Figure out the redundnat software.

[DB2 Guy]

Hi,

This question is not really for a Forum though just trying my luck.

I have joined in a new shop and there are some software I figure out are kind of redundant. For example

1. they had been using Fusion Software which is used to send the files to different servers inside the company. This can be achieved with the native FTP also. I am in talks with the infrastructure team on this to know the charges being paid for this software and the CPU utilization of the existing jobs. If removing those with FTP is cheaper, it'd would make sense to remove Fusion.
   
   Said that, do you think there should be different approach for such a task.
2. They use a lot of 'zip software' on mainframes. Not sure why they had been using so many of them while they also have PKZIP, which can possibly replace any other option.

Said all that, do you think such further software can be identified, which possibly are not used in years, doing similar tasks by the application team ?

[Robert Sample]

Replacing Fusion Software with FTP sounds like it is an option. However, a full analysis of the costs involved will require someone determine how much it would cost to find all the Fusion Software executions in jobs and replacing them with FTP. This could be a very expensive task since it requires people time to manually review things.

z/OS does not have any easy way to identify unused software. At a previous employer, I wrote a system that analyzed the weekly SMF 30 records, extracted the executed programs, and updated a data base (actually a VSAM data set) with execution counts for the week. After a year or two of running this system, we could identify the unused programs fairly accurately. Remember that programs may be executed daily, or weekly, or biweekly, or monthly, or quarterly, or annually -- so getting rid of a program that has not been used since January 2018 may mean your company loses the ability to print 1099 statements (which the IRS would not be happy about).

Are you sure about the company having PKZIP? PKZIP for mainframes is not a free product -- and hence not all sites have it available! Mainframes will have tar and pax and much of the time gzip (gzip was in the Ported Tools package for a long time and hence not installed as part of Unix System Services; I'm not sure if it still is) but not PKZIP (unless it is purchased).

[DB2 Guy]

Thanks Robert.

Replacing Fusion Software with FTP sounds like it is an option. However, a full analysis of the costs involved will require someone determine how much it would cost to find all the Fusion Software executions in jobs and replacing them with FTP. This could be a very expensive task since it requires people time to manually review things.

Yes, I also consider that as an option and I just hope there is no "user case" which I miss when I do the analysis. As you said it's going to be a big task. If the licensing is huge and the CPU utilization is more it might be worth.

How can I guesstimate the CPU utilization of FTP Jobs compared to existing Fusion Jobs? Any direction on that? I can get the CPU utilization of Fusion Jobs from existing Jobs but what is the good number of Jobs of FTP to compare a "replaced Fusion Job with FTP" from CPU (MSU) utilization point of view?

[DB2 Guy]

z/OS does not have any easy way to identify unused software. At a previous employer, I wrote a system that analyzed the weekly SMF 30 records, extracted the executed programs, and updated a data base (actually a VSAM data set) with execution counts for the week. After a year or two of running this system, we could identify the unused programs fairly accurately. Remember that programs may be executed daily, or weekly, or biweekly, or monthly, or quarterly, or annually -- so getting rid of a program that has not been used since January 2018 may mean your company loses the ability to print 1099 statements (which the IRS would not be happy about).

Thanks. Even the mainframe infrastructure support would not have these details with them? I thought, they might keeping an eye on it?

Are you sure about the company having PKZIP? PKZIP for mainframes is not a free product -- and hence not all sites have it available! Mainframes will have tar and pax and much of the time gzip (gzip was in the Ported Tools package for a long time and hence not installed as part of Unix System Services; I'm not sure if it still is) but not PKZIP (unless it is purchased).

Yes, I am sure as I 've seen the PKZIP PROC being called in Jobs.

[Robert Sample]

How can I guesstimate the CPU utilization of FTP Jobs compared to existing Fusion Jobs? Any direction on that? I can get the CPU utilization of Fusion Jobs from existing Jobs but what is the good number of Jobs of FTP to compare a "replaced Fusion Job with FTP" from CPU (MSU) utilization point of view?

This can be tricky. The SMF record types 118 and 119 record FTP information (among other things); the 118 is the "old-style" record that has been deprecated and is being replaced by the 119 record type. However, neither record type records CPU time for the FTP -- starting date / time and ending date / time of the FTP, yes. But CPU time, no. So assuming you're looking at batch jobs, you have to match the type 30 records to the type 119 records to be able to capture CPU time.

[DB2 Guy]

This can be tricky. The SMF record types 118 and 119 record FTP information (among other things); the 118 is the "old-style" record that has been deprecated and is being replaced by the 119 record type. However, neither record type records CPU time for the FTP -- starting date / time and ending date / time of the FTP, yes. But CPU time, no. So assuming you're looking at batch jobs, you have to match the type 30 records to the type 119 records to be able to capture CPU time.

If I pick up the CPU seconds shown in SYSOUT of the test FTP-job for a file and test Fusion-Job for the same file transfer, will that be a good guess? I usually asked this to the support team of my companies but as FTP would be a new Job, I doubt they would help me here.

[Robert Sample]

Yeah, you don't need a value precise to microseconds -- just use the job output CPU time.

[DB2 Guy]

I have some more information which I got from our infrastructure team:

1. FTP uses 9.11MIPS/hour on average. Fusion uses 3.73MIPS/hour on average. This is based on data from 4/25 to 5/14 and is for PROD LPAR1/2.
2. FTP does not have automatic retry capabilities. If it cannot connect, it fails.

Does that mean that chances of having FTP in place of Fusion are slim? I did not get the licensing fee for Fusion yet though, may be there is some hope.

For point 2 above, I searched and found that there is this option:

Code: Select all

//MYFTP  EXEC FTP,PARM='IP=xx.xx.xx,RETRY=03'

And there is this documentation, but 'am still readin git: http://www-01.ibm.com/support/docview.w ... wg27011275

Do you have any suggestion, please?

[enrico-sorichetti]

for what reason are You concentrating on Fusion VS. FTP
did You ever consider that Fusion might implement more facilities than FTP ?

[DB2 Guy]

did You ever consider that Fusion might implement more facilities than FTP ?

Yes I did. There are just 2 use-cases I could identify for the Fusion in our shop:

1. Send files across as is.
2. Append the timestamp to the file name and send it across.

Other than that there is no other use-case I've seen and no stake holder has reported it yet. Yes, when the receiving server is not available it does not fail and shows a message in SYSOUT. But will it "retry", don't know. I'm checking on that.

On the other hand, we have the following facilities on our disposal for file transfer:

• FTP
• SFTP (we've USS)
• Fusion
• Connect: Direct

Two of them are pay-for-products (Fusion and C: D). Though possible but I've ruled out Fusion to Connect: Direct replacement - as I can not make all the receiving servers to run as nodes under C: D, that will be too huge a change. Thinking that, I thought may be FTP can be a good choice as a replacement but yes it's just an idea at the moment - I've some success and some failure. And as Robert has said before, a full analysis of the costs involved will require me to determine how much it would cost to find all the Fusion Software executions in jobs and replacing them with FTP, that's another side of it.

I am trying to figure out if it really worth the shot - your point is valid and I did consider that if we are really using a facility not covered by vanilla FTP and if the software exist only to transfer the files. Its maintenance is also a pain, for example - in Fusion, they had been using separate COBOL programs every time they want to append timestamp to the file to be sent, which can easily be done using EZACFSM1 before FTP. I am not sure why did they pick up a program to append timestamp and asking about it around does not get you an answer!